movement independant of computer speed - ?
Author
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.
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.
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:
hope that helped!
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!
Author
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.
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.
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.
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.
Author
Oh yea. I knew that! :)
Well Im pretty sure thats what Ive been doing, more or less. So my problem must lie elsewhere...
Well Im pretty sure thats what Ive been doing, more or less. So my problem must lie elsewhere...
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 :)
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 :)
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).
Quote:Original post by VBBRQuote: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).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
