I'm designing a flight simulator for college and I've come up on a small problem.
The sim is working fine at the current frame rate, but if it increases alot the control keys on the keyboard become very sensitive. I’m looping through an array of booleans (this tells me which keys are being pressed).
I would like to keep the frame rate constant by adjusting the delay parameter in glutTimerFunc(…) but would this be bad programming practice?..Would it be done often?.. Or is it a total NO NO???
I am not sure what GLUtimer is( stay there and do nothing for a while?)Normally people don’t have enough time to render, but you do!
I think you can use a counter for each key to tell how many times it is pressed and released, you take action only after the counter reachs certain number. But if you define that the key must be held down to take effect, then this is not a solution.
Trying to keep the framerate constant is really a bad idea.
Instead of adjusting the speed of your program to keep animations and stuff correct you should adjust your animation and input code to keep that stuff correct.
All you have to do is to measure how much time has elapsed since the last update of the animation, or position of your aircraft, etc.
Than you move your object, but only thus far, as it should move in this time.
For example: Your aircraft is supposed to move 100 meters in 1 second. Since the last update of its position and this update 16 milliseconds (1/60 seconds) have elapsed. This means you move your object 100/60 meters.
Quite easy.
If you realy need to slow down your animation you can throw in sleep states or just busy waits. ie
gettime(t);//in ms
while( t+10>gettime(z))
Another way to handle the key board senitivity problem is that after a key is pressed, you block input for say 10 ms, ie if you pressed r, then for then if the next frame in you animation happens less then 10ms after the previous frame don’t check keyboard input, or just skip the last keypressed.
In general none of these are good ideas and you should make all movement relative to time, make sure you keep track of how long each frame took. I also believe some drivers can be synced to refresh rate of the monitor so that fps will not exceed it(i.e. not exceed 60-90 fps), although if I remember this is mostly a function of professional type cards.
Please, don’t slow down your FPS!
I actually though the problem was a little bit different.
Jan2000 has the right idea, which by another point of view can be read as follows:
If you have to go foward…
Go foward at a speed of m/s…
Since the time elapsed is Ft…
Move by (m/s)*Ft.
It is definetly better and not really difficult to do. I actually think this is EASIER than trying to keep FPS constants (and gives better results). Another nice thing is that if Ft is really little (say, you got more than 100fps) you may decide to skip a whole position calcolation and accumulate to next frame (if you are CPU limited you would benefit from this).
