Fixed Timestep

Request: It’d be nice to have a fixed time step option in the app settings. This time step would be the same every tick, regardless of frame rate.



Usage: This is useful when recording video. With a fixed time step we can take a screeshot/frame capture every update call at the frame rate of the video we want to record

A fixed timestep does not work unless you can guarantee the time per frame is less than the fixed timestep, If you can guarantee this then you can just wait within a tick anyway thus fixing your time-step.

Not entirely so. In the situation I am in now, I require a fixed time step for recording video output. While recording, the application runs around 2-3 fps due to disk IO (saving PNGs). This made the regular time step really large (much larger than 1/30), and my video runs at 30fps, so when I combined all the images I’d saved, my video seemed like it was in super speed.

To fix this, I locked the time step to be 1/30 seconds. In SimpleApplication.java you can see where that the tpf (timestep) gets set in the update method which then called simple update. To lock that at 1/30, I did the following:

[java]

float tpf = 0;

if (fixedTimeStep == 0)

{

tpf = timer.getTimePerFrame() * speed;

}

else

{

tpf = fixedTimeStep;

}

[/java]

This way, whether I was getting 200fps, or 1fps, the game would only ever step forward by my given fixedTimeStep (in my case 1/30 seconds)

This also had the benefit of making my simulation not get weird due to large timesteps :slight_smile:

Note: I couldn’t just change the timestep in simpleUpdate() because my video recorder is an AbstractAppState

Note: I also couldn’t just override the update in my SimpleApplication extension because I need to call the Application update method also. So if I just overrode the update in my simpleApplication, I’d have to call super.update() to call SimpleApplication.update() which then calls Application.update(). However, I need to avoid the SimpleApplication.update()! So in my simple application, I’d need to do something like super.super.update(), which unfortunately doesn’t work in Java :frowning: To get around this I just copied the the SimpleApplication.java and made my own version

In general



I may be mis-understanding but can’t you just override the update method in your video recorder app state and always use your fixed timestep regardless of the the tpf?



Matt

Ah yes, I could do that in the recorder. IE: take a screen shot every 1/30 of a second for a nice video. However, there is the potential for the video to be slightly stuttery do to imperfections in the time steps of the game vs the time of the video recorder. For instance, if the game runs a frame at these times:

0 seconds, 0.13 seconds, 0.28 seconds, 0.5 seconds, 0.8 seconds, and 1 seconds

Then I would be capturing at the interval 0 seconds, 0.5 seconds, 0.8 seconds, and 1 second. Those would be my first frames of the video. Since they are not uniformly spaced, the video would show the game running unevenly.



Also, for my purposes, I found that the slowdown of the fps due to the image saving was also causing unwanted simulation errors, so I decided to lock the whole step.

I don’t know if this will work … You can try setting the “timer” variable in Application, by creating your own implementation that returns a constant value for TPF.

By the way, you might be able to speed up your application by having many threads do the PNG encoding. Just have some thread-safe queue that is queried on each thread and then do the encoding there. The main applications just puts raw uncompressed images onto that queue.

By the way, you might be able to speed up your application by having many threads do the PNG encoding

Thanks for the tip Momoko. I used this technique and it considerably increased my video recording speed. Though, I did have to put a memory cap on the amount of images I stored in memory at once :) A long video is definitely a ram eater!