FPSAnimator producing irregular frametimes

OpenGL Development JOGL Development
#1

hello,

i would like to use the FPSAnimator a little more, in order to save important cpu-time for other calculations in the game.
unfortunately the fpsanimator is giving a quite irregular framerate with a sawtooth-pattern. here are two histograms comparing the frametimes of the two animators.

regular animator:

http://www.embege.com/misc/histonofps.png

fps animator set to 60fps

http://www.embege.com/misc/histofps.png

is there any way to work around this, so that the fps animator makes every frame 1/60 second long?

#2

Quick question: In the histogram, is it frame rate, or frame duration that you’re graphing? Because if it’s frame duration, it would make sense that the spikes in the normal animator and teeth in the FPSAnimator are caused by the garbage collector. I don’t actually know why the animators would handle gc’ing differently or how to fix it, except to minimize the number of large garbage collections.

#3

it is the time between each frame measured using System.nanoTime()

i hope that there are no large garbage collections anymore in the game. only small ones happening about once every second.

#4

The FPSAnimator uses a Swing timer internally and I’m not an expert on its semantics. Have you tried using the “schedule at fixed rate” argument to the FPSAnimator constructor?

#5

thanks!
the above frametimes where with scheduleatfixedrate “true”

here is the result with scheduleatfixedrate set to “false”

http://www.embege.com/misc/histofpsnosched.png

this “feels” even worse, since the differences between the frames are much bigger

#6

i was also displeased with this. so i went on a little adventure, built my own clock based on System.nanotime(), and created my own animation driver. however, it is non-trivial to produce a steady clock and frame rate. so, eventually i just went back to FPS animator.

the problem with a fixed frame rate is that at the end of the day it involves prediction. and all that a programmer can do really is make a guess based upon how long the last frame took to process and render. of course, basing your frame delta time calculations on the last frame will get you in the ballpark, but ultimately, it’s just not going to be steady.

i wasn’t satisfied still, so i spent time looking into this issue. it’s the same everywhere in computing – for audio, for C code, everywhere. if you want to look up the technical terms, it’s referred to as DRIFT and JITTER. computers are not good at steady clock, and usually can only achieve this via buffering time. the basic process to keep two times for everything. first, you calculate what time it should be. for example if we are on frame 10 at 60fps, the time now SHOULD be ( .166666666… * 10 ) seconds. then what you do is manually adjust the page flip to the perfect time by adding delay, or going early. however, this involves latency. so if you arrive at the page flip 3 milliseconds early, you just burn some thread time then flip. even if you don’t mind the latency this creates, when i ask the thread to kick it and chill for a bit you CANNOT be assured that it will do so accurately. i found that thread sleep times vary by platform, and reliability. so, if the delay you ask for to match perfect time isn’t even reliable, what’s the point? btw, the technique described above is the same that is used for VOIP to ensure streamed audio stays together and is typically called a de-jitter buffer.

in the world of audio production, people pay big bucks to create a steady clock buy purchasing specialized hardware clocks. i’m not a games programming expert, but after spending the time i did on this subject, i found i was just fine with FPS animator because i proved to myself that the better solutions are a lot of work and aren’t really that much better.

i found that time spent pooling objects and carefully managing GC is a more practical way to get a steady rate.

btw, this is a HUGE topic in real time graphics, and audio. there is no good solution currently that is universal among platforms. in the old days, they would use the screen refresh as the clock because it’s pretty steady, but you can’t even really do that anymore.

#7

Hope I well understand all that topic … if so, I would recommend you to use time-based animation rather than frame-based it will give you smoother result even with non-constant frame rate, something like that: :

function anim(timeMillisElapsed)
{
posX=posX0+speedxPerMillistimeMillisElapsed;
posY=posY0+speedyPerMillistimeMillisElapsed;
drawAt(posX,posY);
}

or for more complex animation:

function anim(timeMillisElapsed)
{
posX=fX(timeMillisElapsed);
posY=fY(timeMillisElapsed);
drawAt(posX,posY);
}