Time step

[bigsofty]

Well, I use the old delta time method for controlling my apps but after having a quick read of this classic timestep article, http://gafferongames.com/game-physics/fix-your-timestep/ ,  I am now wondering if maybe an interpolated method would be better.

My only worry is that this is quite an old article, that is referenced all over the net but it was written in 2006 and as my main target is now the mobile platforms I am a little concerned about the overhead of an interpolated method of game time step processing, esp. for mass movement systems like particles for example.

What method do other people use and what experience have they with scaling their time-step methods with different platforms?

[theprotocol]

I've experimented with this a lot last year. It's an extremely interesting consideration.

What I've found is that interpolation can make games feel smooth as butter, but you have to find the "sweet spot." When you interpolate the graphics, your collisions will become inaccurate to a certain extent (as your rendering method will often predict positions that end up slightly wrong compared to what really happens). You need to balance the logic execution rate against the rendering framerate, and decide how much inaccuracy you can tolerate. The question is - how loose can your rendering output be compared to game logic?

Another thing I've found is that on mobile platforms, doing floating point calculations in every frame, as required for interpolation, is quite expensive. I even played around with math libraries like Eigen and GLM that would use the iPhone's vector unit (ARM NEON), but the performance wasn't up to scratch (Eigen was slower than straight floating point computations in my iOS project). The upside is that interpolation adds smoothness to the motion, and you might want to take the framerate hit (if any - depends on how complex your scene is).

There's definitely potential to pull it off on mobile platforms though, so long as you don't have thousands of things to interpolate each frame.

[bigsofty]

It's an interesting problem, I applied an interpolated method to my particle system and it looked great on my PC but I kinda new it would have an adverse affect on my tablet version. I applied it to the tablet compile and, as expected, it actually made things look worse. As the CPU was now guaranteed to have the processing time it required to process the main game update, it actually left less time for the rendering. I slowed the main game update to 25hz and this helped the rendering update but I was now looking at methods to scale the main loop updates to match the hardware or waste CPU time.

Another alternative would be to branch the desktop and mobile version, one with interpolation and one without. But this is the kind of dev branching that I really would like to avoid.

On a slight side note, I was in the process of investigating Eigen and GLM too. Strangely enough but for now my only real boost has came from custom GLB compile command line options for hardware floats, unrolling etc...

In case it can help others, here some optimised compiler command line options for ARM based platforms...

Code (glbasic) Select Expand

-O3 -march=armv6 -marm -mfloat-abi=softfp -mfpu=vfp -ftree-vectorize -ffast-math -funsafe-math-optimizations -fsingle-precision-constant -funroll-loops 

It gave me about a 35-40% boost on my floating point routines on my little single core tablet.

As for game timing I was hoping that there was some kind of 'silver bullet' method that would overcome these problems but alas I have not found it yet.

[Kitty Hello]

A very quick way for old code is to just skip the drawing of every other frame on slow devices.

[matchy]

If ony there was a Tip Of The Month.