Game loop sync (Kevglass)

Newbie & Debugging Questions
#1

I’ve been checking out your source for the 4k games, and I’m interested in this game loop technique.

		
		long lastLoopTime = System.currentTimeMillis();
		
		while (true)
		{
			int delta = (int) (System.currentTimeMillis() - lastLoopTime);
			for (int i=0;i<delta/10;i++) {
				logic(10);
			}
			logic(delta % 10);
			
			lastLoopTime = System.currentTimeMillis();
			
			draw((Graphics2D) strategy.getDrawGraphics());
			
			strategy.show();
			if (!isVisible()) {
				System.exit(0);
			}
		}

Why do you call logic() inside that for-loop, and also after the for-loop. Aren’t you calling the logic() way too often, and hence slowing down the game? Isn’t it better to calculate the delta argument to pass to logic(delta) instead of calling logic() n-times? Like this:


			int diff = 0;
			for (int i=0;i<delta/10;i++) {
				diff+=10;
			}
			logic((delta % 10) + diff);

??

Are there any better ways to keep the game logic at a static speed, independent from framerate? I’m not too familiar with this concept.

#2

What you’re looking at there is fudged collision detection (which I actually use in everything these days :)). 4K isn’t a great place to look for good coding examples btw :slight_smile:

In the game there may be moving elements which want to collide with each other that are updated by the logic based on the delta in time (change in time). However, if the logic time step gets too big two elements might move so far that they pass right though each other. Imagine a bullet and alien. The bullet is moving - if the logic which moves it was stepped with 1000ms it might jump right past the alien and never intersect with it. The way the loop is above the time step is always small - meaning that no matter how much time is passed the logic is only updated in small sections. Logic tends to be cheaper than rendering (horrible generalisation) in this sort of simple game - so it doesn’t hurt to call render often and makes the collision detection easy to implement and much more reliable.

The other way to do this which more reliable is swept collision detection when you work out the path of all the moving elements and determine where they cross based on time. However, this sort of collision is non-trivial and doesn’t really suit 4K programming (or me generally for that matter).

Incidently, your rewrite:


int diff = 0;
for (int i=0;i<delta/10;i++) {
	diff+=10;
}
logic((delta % 10) + diff);

essentially does this:


logic(delta);

which is almost certainly what I had in place originally before noticing the collision problems.

Hope this helps,

Kev

#3

Ah, ok, great explanation :slight_smile: thanks.

#4

So, ok,

Let’s say I have a Sprite (bullet) that needs to move 100 pixels every 1 second (let’s say from bottom to top of screen), and the delta is 7ms (since the last game loop), how do I calculate how much to move that sprite in that loop?

#5

with a delta of 7, surely the logic() in the loop will not get hit, and only the logic() outside will, and will get called with 7 (delta%10 where delta = 7)

in your logic code you will move the bullet 0.7 of a pixel ((pixels per second/millis in second) * delta in ms) = (100/1000) * 7

Endolf

#6

Ok, thanks.

#7

This is my favorite pet peeve these days, but that timing loop is leaking time!
The time between the two calls to System.currenTimeMillis() will be lost forever, resulting in a slightly slower running game on slow computers.

“Fixed”[1] version:

		
		long lastLoopTime = System.currentTimeMillis();
		
		while (true)
		{
                        long now = System.currentTimeMillis();
			int delta = (int) (now - lastLoopTime);
			for (int i=0;i<delta/10;i++) {
				logic(10);
			}
			logic(delta % 10);
			
			lastLoopTime = now;
			
			draw((Graphics2D) strategy.getDrawGraphics());
			
			strategy.show();
			if (!isVisible()) {
				System.exit(0);
			}
		}

[1] I am well aware that you can’t “fix” a 4k game. They were never designed to be accurate.

#8

Interesting, in my later stuff I replace:

wtih

is this appropriate? Seemed pretty elegant to me :slight_smile:

Kev

#9

I usually do this:

long now = System.currenTimeMillis();
unprocessedTime+=(int)(now-lastTime);
lastTime = now;

while (unprocessedTime>millisPerTick)
{
    tick();
    millisPerTick+=unprocessedTime;
}

Not quite as elegant, but it leaves a really useful unprocessedTime variable… To figure out how far to interpolate between the last two game ticks, just use

float delta = unprocessedTime/(float)millisPerTick;

(of course, in the real world, I don’t actually use System.currentTimeMillis…)

#10

Is that right? Would have though you’d keep millisPerTick constant and decrement unprocessedTime

but maybe I’m just not getting it (it’s early here :))

Kev

#11

System.nanoTime() ? Or another custom timer ? LWJGL ?

#12

er, yes. I’m a tool. :smiley:

(this is why no of my programs work on the first try. baaaad typos)

#13

What does tick() do?

#14

advance game logic one step.

#15

They grab on to your pets and suck thier blood :wink:

Endolf (The oh so helpfull)