Collision of moving object with rectangular target

[Sylus101]

I'm having a terrible time with this... and I was pretty sure I'd done what I needed and I'm getting really odd results. Here's what I have at this point...

Everything is in .12 fixed point to work with the Lerp trig functions. I have a "gun" that rotates and bullets that fire with a velocity found with the negative cosLerp for x and sinLerp for y. I'm testing different bullet speeds with varied multipliers.

At the same time, I record the angle of fire (from the gun's angle) in the bullet's structure and begin to use a similar to cohen-sutherland type algorithm to check for simple rejections...

At certain points, however, I begin to check if line segments intersect with borders of the target like this for example:

Code: Select all

y = ymax; // bottom border of target...
x = x0 + divf32(y - y0, tanLerp(angle)); // find intersect x value where y = ymax...
if(x < xmax && x > xmin){//etc

The problem is that I'm getting odd intersect points. When I test the slope (tanLerp(angle)) by testing two points on the line vs. the original angle they end up differing... Any thoughts?

[elhobbs]

.12 fixed point is a fairly low precision. are you noticing higher discrepancies at certain angles? say as the angle approaches 90 degrees? tangent at 90 is undefined and the results start getting really large the closer you get to 90. you may be getting overflow/underflow on your divides.

[Sylus101]

General question... I understand what overflow is what what would underflow be? I found this from wikipedia but I don't follow... "Arithmetic underflow, in floating point arithmetic, a condition in which an intermediate result is strictly between zero and the smallest normalized number in the destination format."

[hassifa]

Depending on the variable type that you use, the actual data contained can wrap-around the constraints.
For example, an unsigned short ranges from 0 -> 65535. Now an overflow would occur when trying to increase the data to a value greater than 65535, which would then wrap back around to zero again. An underflow would be the reverse of this, which where someone tries to decrement a value to less than zero, and the data wraps back around to the 65535 value.

[Sylus101]

I'm using ints in most all cases as I can have negative angles/slopes, neg x, y values to check for, etc... I don't think I'm getting overflow/underflow (I was before I switched to the correct divf32 and mulf32 functions) and it really just seems to be some kind of general inaccuracy...

I'm finding that if I check the slope produced by any two points checked (before and after addition of velocity) vs. the slope received from tanLerp(angle) is different. Neither seem to give me the intersections I'm looking for.

I'm not sure what to do here... if I need to use the Lerp functions which work with .12 fixed point accuracy... I'm really not getting what I need. I'll double check my code to be 100% sure I'm not just missing something else but I'm beginning to think I'm going to have to just stick with checking umpteen conditions instead.

EDIT - Okay... I think I've ended up finding a pretty blaring bug in my code... (wouldn't you know it...) so I'll come back and report the findings shortly.

SOLVED - Well, I thought I had looked at everything and sure enough... I blundered something. I seem to be getting quite decent intersection now.