Hey everyone, I''m having a problem with moving an object across the screen independent of frame rate. what I''m doing is taking the speed of the object and dividing by frames per second to get the pixels moved per frame. Then I multiply by the cos/sin of the angle of the line to get the pixels moved relative to the angle of the line. Something like this:

float dX, dY; int LineAngle = 30; // Degrees dX = (float)Speed / (float)fps * cos(LineAngle * PI/180); dY = (float)Speed / (float)fps * sin(LineAngle * PI/180);

The problem comes in when I do this every frame:

// the variables x and y are current positions x += dX; y += dY;

When I check the values of these numbers after even 1 frame I get a value of 1.#INF, which is NOT a good thing. Also, x and y were set to the beginning of the line at the beginning of the program and dX and dY calculate properly, because their values, when displayed, are correct. Can anyone help solve this crazy problem? -Hyren

---

"Back to the code mines... ka-chink... ka-chink..." vidgamez.iwarp.com

So, do x and y look fine right before you add dx and dy to them? If you haven't checked, I recommend doing so, to ensure that it is the addition that's breaking them.


Edited by - Kylotan on June 12, 2001 7:41:16 PM

I think you also have your order of operations wrong. Multiplication comes first, then division. So it would look like

dX = speed / (fps * cos(junk));
but it should be
dX = (speed / fps) * cost(junk);

Dog_Food, your second form is actually how the compiler interprets that statement. Associativity is left-to-right between multiplication and division, and they''re the same level of precedence. So the division does happen before the multiplication.

Hyren, I don''t think I can add more than Kylotan did without seeing more of the code.

Have you verified that the frames per second is accurate? Most of the timers available only have a resolution of .01 seconds. That means that if your frame rate would have been 100 or more then the elapsed time is going to be zero. The main reason I ask is the 1.#inf result.

Hey-

I don''t think order of operations is the problem, since it shouldn''t matter (mathematically), whether it does multiplication or division first.

My frame rate is (unfortunately) accurate at around 20 fps (really old computer that I''m working on).

As for x and y, if I add a constant value, like .5 each frame, then they increment normally. If I get some time this afternoon, I''ll post a link to the source code that is giving me problems.

-Hyren

---

"Back to the code mines... ka-chink... ka-chink..."
vidgamez.iwarp.com

Maybe You are dividing by zero.
It happens if the angle is 0 for sin or PI/2 for cosini

value/0 ==Infinitum?


delete [] Jonppe;

Remember, just cos something is mathematically correct doesn''t mean it''s the same in C, nor does it take into account the precision limitations of the computer.

Example: (10 * (20/100)) - mathematically will be 2. However, in C, the (20/100) is an integer division, which equals 0, since the integer can''t hold numbers between 0 and 1. And 0 * 10 equals 0. Hence, an unexpected result. You would have to do ((10 * 20) / 100) instead.

So, the order of operations does matter, especially where you have integers involved. Cast them all to floats, or do your multiplications first and divisions last.

Btw, make a separate variable and store (LineAngle * PI/180) in it. Examine that variable to see if it''s getting the answer you expect. You should do that calculation into a separate variable anyway, and use that variable for both the dx and dx equations, to avoid doing that multiplication and division twice each time like you currently do.