Sign in to follow this  
CosmoKramer

movement independant of computer speed - ?

Recommended Posts

Once I wrote a 'cool' (I thought it was cool anyway) graphics demo in openGL. It involved a bunch of balls bouncing off the walls of a square room, and off eachother. It ran really smoothly and I was quite impressed with it, so I sent it to my brother to show him what a good coder I was :) He emailed me back and told me it sucked. I couldnt understand why he said that until a few weeks later when I went to his house and tried it for myself. It turned out that his computer was a lot faster than mine, so the balls were bouncing around way faster then they should have been. In fact some were bouncing so fast that the collision detection method that I was using broke down, and objects were passing through eachother and even getting stuck in the walls. He was right, it did suck. I have since learned that it is a good idea to design your demos to behave the same on different speed computers. For example if it takes 1 second for the ball to travel accross the room on my computer, then it should take 1 second on any computer, even if the computer is way faster or way slower. The only difference between the computers should be the framerate. I am still learning how to design the program like that, but thats a different story. What I want to know is: Is there any way to test wether you have properly implemented time based movement? I dont want to have to send my program to someone else to test it, for many reasons. Is there any way you can tell your processor to 'pretend' it is say, 1ghz when its really a 2.4ghz? I have tried to simulate this by just running a cpu-intense program at the same time, but this just doesnt work the way I want it to. It seems to me that this would be a very useful thing to do, and I just want to know what everyone else does, because having your game speed depend on your cpu speed is just completely out of the question. Thanks.

Share this post


Link to post
Share on other sites
I don't know how to make your CPU pretend it's slower, but if you want to be pretty sure you have implemented time based movement correctly, just set up markers in the game world say, 10 units apart, and then give the ball a speed of 2 meters per second, have the program run a timer, if it hits the 10 unit mark close enough to 5 seconds, you can be pretty sure you did it right.

Share this post


Link to post
Share on other sites
what you want to do is scale down how much each ball moves each frame by how long its been since they last moved.

so, if the last frame happened 0.01 seconds a go, you multily some constant by 0.01 and add that to the balls positon. THis way if the last frame was only 0.05 seconds ago, it still travels the same ditance.

so you want:

ball.x = ball.x_velocity * time_since_last_frame;
ball.y = ball.y_velocity * time_since_last_frame;

hope that helped!

Share this post


Link to post
Share on other sites
I think I more or less understand the concept of time-based movement, I just want some way to test that Ive done it right without needing another computer that has a different speed.

Samith, I dont really work in meters/second, or any other real units for that matter. I usually just use something like:

ball.x = ball.x_velocity * time_since_last_frame * some_constant;

where some_constant is just some number that I tinker with until things move at the speed I want. This is why Im not sure if this constant will work equally well on all machines. Should I try to use units like meters and seconds? I am not aware of any code in any game that actually tries to use real-life units like that.

Share this post


Link to post
Share on other sites
Rather than incrementally updating each frame, I prefer to keep updates locked to something like 30 frames per second, and interpolate or extrapolate positions and rotations each frame. Even if your physics are a complete hack, it will be guaranteed to remain stable and (when done correctly) execute exactly the same every time. Makes debugging some problems far easier as well.

Share this post


Link to post
Share on other sites
Quote:
Original post by CosmoKramer
I think I more or less understand the concept of time-based movement, I just want some way to test that Ive done it right without needing another computer that has a different speed.

Samith, I dont really work in meters/second, or any other real units for that matter. I usually just use something like:

ball.x = ball.x_velocity * time_since_last_frame * some_constant;

where some_constant is just some number that I tinker with until things move at the speed I want. This is why Im not sure if this constant will work equally well on all machines. Should I try to use units like meters and seconds? I am not aware of any code in any game that actually tries to use real-life units like that.


The constant will make no difference on different machines. As with the velocity, the value of the constant is not dependant on the machine your running on, only time_since_last_frame is; therefore, it will not affect the position of the ball differently on different machines.

Think of it like this:

ball.x = (ball.x_velocity * some_constant) * time_since_last_frame;

The constant simply scales the velocity.

Share this post


Link to post
Share on other sites
As far as using real life units, a lot of physics engines do that. As long as the world of the game is not extremely tiny, or extrememly large it will help a lot. For games like half life 2, where the levels are at most 500/300 meters in size, a real-life scale is perfectly acceptable. Or any racing games for that matter.

If the world is indeed a lot bigger, then you can apply a scaling factor to all your units from your world to the physics engine. Everything you pass in or out will be scaled appropriately. But it's more calcs, and really, largely unrequired.

velocity will be meters/secs, positions in meters, forces in Newton, ... a lot easier to debug. I think you should do that. YOu might find that the objects looks like they are on the moon, or under very low gravity, but it's a common problem to all computer simulations.

You are already doing a time dependent movement, and if it goes nuts on your friend machine, it could be the frame time calculations you perform that go wrong.

Make sure your calculations are actually accurate. Simply add up times between frames for about one minute, and check if it's consistent with the more basic time functions (getTime()).

there are no Turbo buttons on computers anymore, unfortunately :)

Share this post


Link to post
Share on other sites
Quote:
Original post by hh10k
Rather than incrementally updating each frame, I prefer to keep updates locked to something like 30 frames per second, and interpolate or extrapolate positions and rotations each frame. Even if your physics are a complete hack, it will be guaranteed to remain stable and (when done correctly) execute exactly the same every time. Makes debugging some problems far easier as well.


But if the end user's computer's too slow, ie it gets LESS than 30 FPS, the app will run slower than pretended.

Everything will work as expected, but it will look terrible (and annoying to play).

Share this post


Link to post
Share on other sites
Quote:
Original post by VBBR
Quote:
Original post by hh10k
Rather than incrementally updating each frame, I prefer to keep updates locked to something like 30 frames per second


But if the end user's computer's too slow, ie it gets LESS than 30 FPS, the app will run slower than pretended.


It will only be a problem if the update takes longer than 1/30th of a second, and from my experience most time is taken up by rendering. If you can't update at 30 frames/sec, then it will probably already run at 15 frames/sec using your method. If you want a little more reassurance that it's okay, I've seen of a lot of commerical games that do this (Doom3 is said to be locked to 1/60th of a second).

Share this post


Link to post
Share on other sites
Slower computer = slower frame rate, so in theory if your timing functions work ok you could just slap a sleep( x ) as the last thing in your gameloop to simulate a computer running at a slower speed.

HTH

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this