It's used for having fluidness beyond the speed of either your logic or frame updates. Generally, your FPS is going to be quite variable, so you need to calculate exactly how much you want to move things based on how fast or slow the last update was. In variable timestep, you need to interpolate the logic because it is able to run at any speed. In the case of a fixed timestep, you need to interpolate the drawing, because the logic is locked into a certain speed but the drawing is not.

Like the article and the thread very much, because this is what I have been looking for.I am a newbie in game development. From the beginning, I had questions about loop: I was wondering how accurate it would be, and what will happen if one loop is delayed, and how to synchronize between different computers.

Anyway, here is some of my questions:(1) It seems sleep and timer is not recommended due to their low accuracy. But they do not cost CPU, right?In "Fixed timestep" example code of the first post, it seems it uses while loop comparing the current time to the desired time point. It is time consuming, but it is claimed by OP that it is more accurate.

Is my above understanding correct?

(2) Regarding OP's "Fixed timestep",

Update is irrelated to the variable time. So what matters is the times of updates.But render is designed to be dependent on lastUpdateTime.I do not understand why. I mean, it seems not make sense here.

1) Yeah, sleep can go wonky on some systems. If you don't use it, then your loop is going to max out your CPU, if you do then your CPU usage will only be what you need but on certain systems your frame rate will fluctuate a lot (older Windows mostly, I think). You could always include an option on which to do (for laptop users it really sucks to max the processor, your battery use goes haywire). Timer is just not the best way to do things, it specifically says its accuracy cannot be guaranteed. Would be fine for non-gamey things, though.

2) Fixed timestep is not "more accurate" than variable timestep. You should do whatever works for you. Or even just do both. Fixed timestep is very useful for stuff like physics simulations and networked games because you know everything is updating at specific intervals. Variable timestep can result in a smoother experience for very high frame rates and doesn't give you a frame of latency like fixed timestep. Neither is more accurate or more processor intensive.

In fixed timestep, your update loop is supposed to happen at even intervals every single time. This normally would force your renders to happen at exactly the same times as the updates. That means you're updating way too much or your FPS is way too low, generally. By making the renders variable (and one frame behind), you can update to any FPS with no issues, and still keep your fixed timestep.

This entire discussion has resolved quite a few of my timing issues. What I have been using for a loop trusted sleep time, which has caused me to personally lose sleep time more than once.

Ironically, the fixed timestep version listed has the potential to leave a copy of gameLoop() running. If you have a menu system start the Loop Test Demo for example and the user starts it and then closes the frame by X-ing out of the window, the loop will still be running despite the lack of visual update. The thread started has no dependency or test related to the closure of the panel.

Good point about that. I usually don't put window listeners into my games because I'm a lazy Mac OS user and don't expect closed windows to quit anything. You're right it should definitely be there in this case.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org