I posted my question on the end of a thread, but I realized that it might not get noticed that way, so this is a re-post! I was reading Edgar Roman''s Gravity FAQ, and he explained the implementation of physics in a 2D platformer like so: Take the player''s position (x,y) and add the velocities (xv, yv) to the position coordinate at each iteration. It seems to me that if you simply add the velocity to the position, at "higher" velocities (like say -100 in the FAQ), the player is going to be skipping 100 pixels at each iteration, possibly missing a whole lot of collisions in the process (with platforms, projectiles, etc.) Even at lower velocities it seems easy to miss collisions with thin or small objects. However, this seems a lot easier than moving the player one pixel per iteration and calculating velocity in terms of the amount of time per iteration. I''m just doubtful about how well it works in practice - maybe the velocities never get high enough for it to be a problem? Thanks in advance if you can clear this up for me! Derek

In this case, Velocities should be decimals and not big numbers. If your max velocity is 2.5 (for example), missing missiles and so on should not be a problem.

Correct me if I''m wrong, but I believe one way to solve the ''skipping'' problem is, when after the object moves 100 pixels, store the last position in a temp var or something, and then make a vector or a line segment (I''m not sure which, sorry) netween the old position and the new position. Check for intersections on the line/vector

quote:

---

Original post by misterX
In this case, Velocities should be decimals and not big numbers. If your max velocity is 2.5 (for example), missing missiles and so on should not be a problem.

---

But how do you draw a sprite at a coordinate like 2.5, 3.7? Do you have to turn the position coordinates into integers before you draw?

2.5 = 3
3.7 = 4

Ahoyhoy... wait... what? Oh, I get it.

I have been thinking about the same problem. The problem was that you move one object at a time. How could this be a problem? Well say you have two objects. One at (2,0) and one at (0,2). They move at the same absolute speed. The first one moves to (2,4) and the second one moves to (4,2).

Since you moved them one at a time no collision was detected even though they should have hit each other. I am hoping that the game can complete a cycle fast enough so that this never becomes a problem.

The only solution I have would be to calculate the paths each object would take then check for any intersection before actually moving the objects. If you find an intersection you will have to check to see if they hit and then calculate the new path and then check the new path for intersections etc. Seems pretty nasty to me.

Another solution is to move objects one pixel at a time, and calculate the velocity not in terms of [change in position]/iteration, but rather something like how many times through the game loop per iteration.

But it''s counterintuitive, because if you do a straight conversion, higher velocities would mean slower movement and lower velocites would mean faster movement. And I''m sure it''s complicated for other reasons too.

I don''t know, does anyone who''s actually done this successfully have anything to say about this?

quote:

---

Original post by derekyu
I posted my question on the end of a thread, but I realized that it might not get noticed that way, so this is a re-post!

---

Good for you! Its often a good idea to create a new thread rather than hope people notice a new question embedded in an old thread.

Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.

One thing that you might want to bear in mind is that these problems only become issues if
a) your speeds are large relative to the sizes of your objects
*and*
b) your time steps are large relative to your speeds.

In my experience, this has generally not been the case, and in those instances where these situations might arise (a very low frame rate while falling a long distance and hence building up a large speed) can be artificially limited (for example, simulate some air resistance when falling and limit the speed).


-Justin