Timer minimum length
Posted: Wed Dec 31, 2014 3:25 pmHi!
Is there any specific reason why the minimum timer length is limited to 12 milliseconds?
I'm trying to write a system that would allow making games run with the highest possible frame rate the computer can reach, up to the built-in Game Editor fps limit of 512. For this to be useful, all movement and other changing values have to be balanced to the real_fps, so that all actors movements and all variables that change over time would happen at approximately the same speed regardless of if the real_fps is 30, 152, 12, ..., anything.
So far I have it working for variables that change in a linear manner over time, like basic x += 5 movement. The problems begin when the type of movement isn't linear, like in case for velocity.
When using yvelocity ++ in draw actor, simply balancing it so that instead of adding 1 it always adds (1 * the fps rate for which to balance to, for example, the basic 30) / real_fps doesn't work correctly, since the actor's position still gets updated every frame and despite balancing the amount of yvelocity increasing per second so that the velocity changes in 1 second the same amount with every fps, the amount of times the velocity updates the actor's position is not balanced to the real_fps and thus the actor will move more with higher fps and less with lower fps.
So, I started thinking I'd get around this problem by making a system that utilizes timers for when the yvelocity should get updated, and only update it n times per second, n being the fps rate for which to balance to, for example, the basic 30, again. This would work, but that's where the minimum timer length of 12 milliseconds starts making things difficult. Let's say we're balancing the velocity to fps 30, and that our current real_fps is the maximum, 512, now, for getting the yvelocity to update only 30 times per second, the timer length should be real_fps/balanceFpsTo = 512/30 = ca. 17. All good. But if the real_fps goes to a lower value, let's say 120 (which still is a lot higher than the worst case if the game really lacks, and also a lot higher than even the basic cases, it's rare for a Game Editor game to run over 100 fps), the math would become 120/30 = 4, and because of the limit, a timer that short can't be made.
Well, most of that was not important for the question, I just explained why I'd find shorter timers useful. I'm interested in why the limit 12 was chosen in the first place.
What comes to my fps balancing system, I guess I'll have to try to find some other way around the problem, or then just to limit it to only be used in games where all movement to be balanced is linear.
Thanks for taking the time to read.
Is there any specific reason why the minimum timer length is limited to 12 milliseconds?
I'm trying to write a system that would allow making games run with the highest possible frame rate the computer can reach, up to the built-in Game Editor fps limit of 512. For this to be useful, all movement and other changing values have to be balanced to the real_fps, so that all actors movements and all variables that change over time would happen at approximately the same speed regardless of if the real_fps is 30, 152, 12, ..., anything.
So far I have it working for variables that change in a linear manner over time, like basic x += 5 movement. The problems begin when the type of movement isn't linear, like in case for velocity.
When using yvelocity ++ in draw actor, simply balancing it so that instead of adding 1 it always adds (1 * the fps rate for which to balance to, for example, the basic 30) / real_fps doesn't work correctly, since the actor's position still gets updated every frame and despite balancing the amount of yvelocity increasing per second so that the velocity changes in 1 second the same amount with every fps, the amount of times the velocity updates the actor's position is not balanced to the real_fps and thus the actor will move more with higher fps and less with lower fps.
So, I started thinking I'd get around this problem by making a system that utilizes timers for when the yvelocity should get updated, and only update it n times per second, n being the fps rate for which to balance to, for example, the basic 30, again. This would work, but that's where the minimum timer length of 12 milliseconds starts making things difficult. Let's say we're balancing the velocity to fps 30, and that our current real_fps is the maximum, 512, now, for getting the yvelocity to update only 30 times per second, the timer length should be real_fps/balanceFpsTo = 512/30 = ca. 17. All good. But if the real_fps goes to a lower value, let's say 120 (which still is a lot higher than the worst case if the game really lacks, and also a lot higher than even the basic cases, it's rare for a Game Editor game to run over 100 fps), the math would become 120/30 = 4, and because of the limit, a timer that short can't be made.
Well, most of that was not important for the question, I just explained why I'd find shorter timers useful. I'm interested in why the limit 12 was chosen in the first place.
What comes to my fps balancing system, I guess I'll have to try to find some other way around the problem, or then just to limit it to only be used in games where all movement to be balanced is linear.
Thanks for taking the time to read.
