`th.delta` may sometimes be zero

[vtereshkov]

Problem occurs on Windows, but not on Linux.

[vtereshkov]

A possible cause of this issue is a different behavior of th.delta: On Linux:

2 
2 
4 
2 
2 
1 
2 
2 
2 
4 
1 
2 
1 
1 
1 
1 

On Windows:

1
0
0
0
0
0
8
0
0
0
5
0
4
2
0
0
0

It seems that the th.deltas are the same on average, but not instantly, due to the implementation of the system timer.

Having th.delta == 0 is not very good for many reasons (for example, one may want a numeric derivative like vel = (pos - prevPos) / th.delta).

Can we limit the frame rate in a tophat-based game? It could solve this issue (and also reduce the CPU load if rendering is done in a separate thread).

[vtereshkov]

My "quick and dirty" solution is twofold:

• Add a delay in window.cycle(): for round(std.clock()*1000 - start) <= 0 {/*Delay*/}.
• Use larger steps in player.move(): const steps = 10.

UPD: Not sure step 2 really has any effect.

[marekmaskarinec]

I could try detecting when player is stuck, but that is not the issue here.

I will try adding vsync to tophat and enable it by default.

[vtereshkov]

After some experimenting, I got this working on Windows. Not sure it's the best solution.

player.um.txt

(+ a delay for non-zero th.delta)

[marekmaskarinec]

@vtereshkov does this still happen to you with the frame limiter?

[vtereshkov]

I didn't see zero th.delta anymore. However, the player may still get stuck in the blocks (though quite rarely).