Variable step timing - Good or bad?

Game Mechanics
#1

I’ve read the Game-Loops Thread (http://www.java-gaming.org/topics/game-loops/24220/view.html) today and I’m curious about the var step timing regarding collision detection.
Let’s say I’ve got a pretty decent PC, capping the fps at 60 fps and I move a primitive like this:


x = x+0.1f*delta;
rectangle.setX(x);

Now this should run fine on most machines and it will stutter if I cap the FPS at 5 Fps.
When I now test pixel perfect collision with the 5 FPS Cap it is not possible to get the same accuracy as I get with more FPS.
Are there any tricks to solve this? Or do I need fixed step timing?

#2

First question is: why do you feel the need to cap at 5FPS?

Setting the game loop at 60FPS should be sufficient enough for most collision detection.

However if you still feel the need to check for those “in-between” areas, you could just create a rectangle that encompasses that area and check for collision that way.

#3

Actually collision on low fps should work, if you store the x and y in double.

#4

The lack of accuracy is likely just due the the fact that there is more time between updates. More time between updates means more entity movement between updates and the potential for an entity to move into and then out of collision with another entity before the game is updated. Also puzzled as to why you would want to cap the FPS at 5…

#5

Variable time steps leads to non-deterministic simulations. Personally I consider that to be undesirable. Using doubles doesn’t (really) solve anything.

#6

I know, that no one would cap at 5 FPS - I just did for testing the collision.
Thanks for your answers yet - another possibility in for me was to calculate the optimal time like 1000ms/60 for 60FPS = ~16.
Now I sum up the delta times for every update and do the update when the sum >= 16.
But I feel like wasting resources as this would render duplicate frames without changing anything.

I will try to implement fixed step timing. Anyone ever did this within the Slick Framework?

#7

Just add sleep…?

#8

well… :smiley: Actualy I also want to interpolate the drawings.

#9

If you want to keep it simple. Just render and update the simulation at 60Hz and if you slow down…so be it.

#10

This is what I’ve done with my game loop and it seems to work fine so far.

#11

In general it’s probably a good idea to add in sweeping collision or something like that, because you will have the same problem at any FPS if you have very fast objects.

#12

On the whole, it’d suggest just using a pre-exisiting physic library. Building one from scratch is alot of work.