Scaled motion

The point behind doing a time check is to find out how much time processing the last frame took. Then define your game mechanics in terms of real time rather than in terms of units per frame. That is if you have a ball that before moved 40 pixels per frame, try defining the ball motion to be 4 pixels per millisecond. And if the last frame took ten milliseconds, advance the ball by 40 pixels. If the last frame took five milliseconds advance the ball by 20 pixels. That way the real velocity of the ball will be locked no matter if you''re running at 33 MHz or 1.13 GHz.

What about this though, say I have the velocity at .2 pixels per millisecond (or 200 pixels per second). My game loop passes through at 50ms on a 33MHz, but only takes 3ms on a 1.1GHz... So that means my ball will move faster on an AMD super processer and super slow on anything less... ?

NOOO! i just typed in a really big message and hit submit and it said invalid password or username

anyway, here goes again

what you need is to keep track of how much time it takes to render one frame
you already have that, its in your variable totaltime

now lets say each object has an XPos, YPos, XVelocity, YVelocity
inside the frame, to move objects, you will do something like this:

BallX += BallXVel * totaltime;
BallY += BallYVel * totaltime;

so if BallXVel and BallYVel were 10, and total time was 10, then the amount moved would be 10 * 10 or 100 pixels

now if you run it on a super-slow computer, it might take 50ms to render the frame
so the amount moved would be 10 * 50, or 500 pixels

in the first case scenario, in 50ms 5 frames would elapse(1 frame = 10ms)
and its moving the objects 100 pixels per frame, so in 50ms the ball would be moved 500 pixels

in the second case, 1 frame would elapse in the same amount of time, so it would move it 500 pixels in 50ms - the same amount

now this isn''t always deadly accurate, but its good enough in most cases

anyway, hope this helps, if you''re still confused let me know

Wow! I actually think I understand it. Basically on faster machines, we can see more of what's going on while ball goes from point x to point y. On slower machines we can only see the jump to that point, but the ball will ALWAYS reach that point in the same amount of time...

Awesome!!!

And if we're moving at .2 pixels per ms (200 pixels per second), the hit detection on that would be amazing, since you can pinpoint EXACTLY when the ball hits an object.

!!!

Edited by - DJ_House on October 30, 2000 4:28:36 PM

yeah, you have to be careful that on slower computers it wont miss the frame where it would have collided, or your collision detection will be screwed

Well, at that point you say that it''s below minimum requirements.

That''s true about collision detection, which is very heavy in my type of game (Alleyway/Breakout). But I can''t really think of anything (besides 3D games) that involve as much collision detection as I''m doing. For example, my next 3 games (in order are going to be:

- Space Invaders
- 1943
- Super Mario

After that I move into 3D. But like SiCrane said, there are minimum requirements for a good reason. My game simply won''t function properly on a 486.

Actually, there''s a reason I''m doing these games in a certain order:

1) Alleyway
- Basic collision detection
- Velocity and moving objects according to deltaTime

2) Space Invaders
- Shoot objects

3) 1943
- Scrolling in a single direction, which requires a
a tile engine
- High use of color keys

4) Super Mario
- Scrolling in multiple directions
- Use of clipping (ie. going down pipes)
- Destination(multi-scrolling backgrounds)
and source color keys

Since those are all of the basics, I''m going to then move into 3D, possibly OpenGL to start with. I hope to have my first 3D game done by February so I can get a co-op/intern job programming (or at least beta testing) games.

Either way, my first game is 80% complete. I''m just waiting for my artist to give me the real in-game graphics; and I still have to implement ''specials'' (like shrink the paddle), and a scoring feature.

Rewritting is a pain. I rewrote about 20% of the code from my Alleyway/Breakout game so I could use distance += velocity * time, instead of locking my frame rate.

I also plan on re-doing my brick collision algorithm. It works now, 99% of the time. But I think if I use line intersections it can become 100% accurate. All I need is to stop by my university book store and pick up some physics/algebra books.

if you want to make sure you always get the exact time when it should have hit, you can make an approximation by keeping track of the ball''s last position as well as the current and hit checking the line between them, then by comparing the distance from the last position to the hit position, the entire length traveled and the elapsed frame time, you can get a very close approximation (exact if it''s moving in a straight line).

The equation would look something like:

hit_time = last_time + (dist_to_hit / tot_dist)*last_frame_time

this should work regardless of the machine speed (assuming it only hits one object per frame, but even that can be accomodated for although it seems a bit excessive )

Brought to you by: O.G.A.P.O.
+----------------------------------------+
| Surgeon General's Warning - |
| OGAPO can cause serious mental damage |
| if taken in large doses. |
+----------------------------------------+
/* Never underestimate the power of stupid people in large groups */