That time again..
BlitzMax Forums/BlitzMax Programming/That time again..
| ||
| I'm really struggling to find the perfect timing system for my games. The games all involve some degree of physics simulation and I have heard delta time is not the best for this kind of system. Fixed interval timing was suggested so I tried the following example... http://www.blitzbasic.com/Community/posts.php?topic=70516 The problem is when I drag the window in windowed mode the update starts to get very backed up. Also if I set the refresh rate to something higher than the processor can handle (simulating a crappy computer) it also starts to get backed up and eventually goes out of control. I was also looking at http://www.gaffer.org/game-physics/fix-your-timestep/ but i don't quite understand the stuff with the accumulator. I'm wondering if there are any other resources I should be looking at in regards to this? or any suggestions in general? |
| ||
| Also if I set the refresh rate to something higher than the processor can handle (simulating a crappy computer) it also starts to get backed up and eventually goes out of control. You've made a mistake somewhere. The system which HrdNutz demonstrates is the same theory as the one you later link to on gaffer.org. The accumulator stuff really isn't hard, but I'm not sure I can explain it better than he does. It's really just fixing the interval between updates and rendering as often as you can. If you can render ten times for every one update, you do, and if you need to update twice (or more) before rendering then you do that instead. The accumulator is only there because you can't do 2 and a bit updates, because the timestep is fixed. So you just keep the remainder in the accumulator because otherwise, it would go out of step if you threw away the left over time. |
| ||
| Simply said, the Accumulator does nothing else than accumulate the error (realtime -> fixed time) up till it has accumulated enough "error time" to do another step then and compensate the error. |
| ||
| Well it sounds like I'm on the right path - I just need to kepp messing with it. So how does Flip (1,0,-1) factor into this? I have been using the default (which is -1 is guess). Does it make sense to use 0 (as soon as possible ) if you are using a fixed timed method? EDIT - I was just messing with flip on Hickory and changing it to 1 made everything run so much smoother and eliminated the tearing in window mode as well! What gives?? |
| ||
| I have found that Flip 1 is needed to remove tearing on my iMac, the -1 setting does sync to the framerate but it doesn't remove tearing. Also there is not really any perfect timing system. To do fixed step you still need a fixed amount of `time` in which to process the logic, which the computer has to AT LEAST be able to do even if it doesn't have any time to draw graphics, but ideally there'd be enough time left after the logic is done to render the screen at a decent rate. The idea is that objects keep moving at the right speed but the framerate might drop. You obviously can't get a very slow computer to do very fast things no matter what timing method you use. |
| ||
| This is starting to come along. One more question though- what frame rate are people using for BlitzMax games? 20-30 seems a little jittery without tweening and tweening just adds a lot of complexity to the whole draw process which at the moment is nice and simple. That and I'm not sure how to find the point to tween at if objects aren't moving in a straight line. |
   |