Game loops!

ManIkWeet · March 8, 2012, 7:42pm

This forums has serious issues with the EDIT button…

It’s not the interpolation either

Roquen · March 9, 2012, 3:22pm

Actually it can be very significant. The lines I’m talking about are ones like these:


double X = System.nanoTime();

Which when the counter get big will start to drop least sig bits (up to 11) of the input, which are the most important and keeps the high bits, which we don’t really care about.

ManIkWeet · March 11, 2012, 12:14pm

New update: when I unlimit the FPS, I still get choppy spikes, which means there’s some sort of inprecision in the tick management…
Please investigate

ManIkWeet · March 11, 2012, 3:37pm

OR there’s something wrong with canvas/bufferedstrategy…
OR interpolation still, but when printing that I see no differences

Roquen · March 11, 2012, 3:42pm

If you’re printing all the time…well that takes forever in nanotime.

(EDIT) Unless your rendering the text yourself. (not some outputstream kinda thing)

ManIkWeet · March 12, 2012, 7:47pm

first calculating the interpolation, then System.out it

Demonpants · May 11, 2012, 5:59pm

I added a pause button to the fixed timestep so you can test out catch-up behavior, and I also fixed a bug there (thanks roland for pointing it out) where the catchup was being calculated incorrectly.

wolfcall · June 2, 2012, 2:47am

I just wanted to say thanks this is exactly what I needed for a project of mine. ;D

Danny02 · June 2, 2012, 10:06am

just read this

[quote]Which counter are you referring to? If it’s the timer then it doesn’t matter, any precision lost will be so minute.
[/quote]
and got remembered to this

so boys and girls, incrementing time with floating point numbers cost lives!!

Roquen · June 2, 2012, 11:30am

I’m not sure if this is the failure in question…but I know that one problem early versions had was that the programmer didn’t understand that 1/10 of a second (the logic rate it ran at) isn’t a representable number.

wolfcall · June 2, 2012, 9:36pm

I should say thanks again because this also fixed a second problem I didn’t get to fix yet. so thanks twice over ;D ;D

Demonpants · June 3, 2012, 12:30am

Nope, Danny, I think you’re wrong. You’re not keeping a running total added, you’re keeping a total that is refreshed multiple times per second. So any lost precision is going to be completely impossible to notice. If you were adding the time every single frame to store the game time or something, I could see that being an issue. But in this case, no.

Roquen · June 3, 2012, 10:30am

You’re both right in the context you’re talking about.

The_Cure · July 31, 2012, 5:29pm

[quote=Gingerious]So I noticed when I added 15 instead of 10 to the sleep on the variable timestep, it didn’t error out on me. Did it error out on anyone else?

The error was that the time to sleep was a negative value, but it look like it’s only for the first time the loop runs. Every time after that it’s between 8 and 10. Any ideas?
[/quote]
I think i solved that error just adding Math.abs(); to the Thread.sleep calculation (making the result be always positive):

Thread.sleep(Math.abs(lastLoopTime - System.nanoTime()) / 1000000 + 10);

For now i didn’t have any problems, but i really don’t know if my solution is the correct one, and if it affects the logic behind the variable timestep loop. Maybe someone could tell me if i’m doing something stupid…

ra4king · July 31, 2012, 5:44pm

That’s because it’s supposed to be the other way around: System.nanoTime() - lastLoopTime. No need for Math.abs

Demonpants · August 4, 2012, 1:13am

I don’t think so. You’re trying to wait for 10ms, and if the last loop time was slower than that you wait for less time. See Kev explain below.

From Kev’s (since update) tutorial:

To do this we’re going to want each cycle round the game loop to take exactly 10 milliseconds. We know at what time the cycle started (lastLoopTime) and we know what time it is now, so with a small amount of maths we can sleep for the right amount of time like this:
// we want each frame to take 10 milliseconds, to do this
// we've recorded when we started the frame. We add 10 milliseconds
// to this and then factor in the current time to give 
// us our final value to wait for
SystemTimer.sleep(lastLoopTime+10-SystemTimer.getTime());
Note: GAGE Timer actually supports a “sleepUntil()” method that could be used here. However, since the SystemTimer is trying to allow us to change between timing mechanisms we should try to rely on simply sleeping for the right amount of time.

The only difference is the division, that’s because we’re using nanoTime here and Kev is only using ms.

Demonpants · August 4, 2012, 1:17am

Although actually the +10 should be there if we were shooting for 100 fps, and we’re going for 60. I should change that to 16.

SHC · November 3, 2012, 1:26am

Could you please say me what’s GAME_HERTZ? Is it the required number of updates per second?

Demonpants · November 3, 2012, 5:15am

Correct. It’s like FPS but in game updates, not frame updates.

KittenKoder · November 3, 2012, 5:35am

I can’t believe your “bad” examples, I actually see people using them in full games as well. You’d think that with all the information out there which says “don’t do it” or the throttling of your CPU would be enough. lol

I hope more people find this thread.