[Solved] Issues with FP.elapsed and timing (Not reliable at low framerates?)


(Nicole Brauer) #1

Hey,

so I have what you could call a “cutscene” timed with some music. Simply put a character moves down the screen. And what I want is that the character reaches the bottom of the screen exactly when the music stops.

I use a variable framerate and add “*FP.elapsed” to the movement code so it is time-dependent.

And this works mostly well: The character stops perfectly with the music. But some times the character takes a little longer than usualy and the music stops prior to their arrival.

I though it might be an issue with the framerate and tried setting it to something rather low (~10fps). The code is still the same as with 60fps but now the character is so far out of sync that the music stops about a minute before they reach the bottom.

I made a quick and simple test in a new project:

super(800, 600, 60, false);

counter += FP.elapsed;
trace(counter);

And then I timed when the in-game timer and my watch got to 3 seconds. And with 60fps it was pretty much the same.

But the lower the framerate (mostly notable below 20fps) the longer it took for one second to pass in-game where 3 real-life seconds would equal double or more in in-game time. (This also happens with Alarm Tweens so it’s not just FP.elapsed)

Now long story short: Is this an issue with timing in FlashPunk or is this just how it works and low framerates mess with exact timing. Or am I doing something wrong?

If this is not a bug or mistake. Is there any other way to get excact timing so I can sync up my music with the cutscene at any framerate?

(I know that the framerate shouldn’t be that low anyway, but my game can be a bit performance-heavy at times and I fear that it will mess the cutscenes up if there are some framerate drops)


(Zachary Lewis) #2

Have you tried moving the character with a Tween set to run the length of the song?


(Nicole Brauer) #3

I don’t actually move the character, I just fade the background out and then teleport the entity after the time is up. I might have explained that a bit stupidly.

I don’t think it will work, since an Alarm wouldn’t time it right either, but I will try it out in my test project.


(Nicole Brauer) #4

Quick test with VarTween (that was what you were meaning, right?):

var test:Entity = new Entity(100, 0, new Image(new BitmapData(20, 20, false, 0xffffffff)));
var tween:VarTween = new VarTween();

tween.tween(test, "y", 500, 5);

Timed at 60fps: takes about 5 seconds

Timed at 20fps: takes about 7 seconds

Timed at 10fps: takes about 8 seconds

Timed at 5fps: takes about 30 seconds


(azrafe7) #5

You can try the other way round, and see if it works.

Instead of relying on FP.elapsed (which might be clamped to maxElapsed - see Engine.onEnterFrame()), you interpolate using your sound position and its value between 0 and length.


(Nicole Brauer) #6

That with the sound position is actually a really nice workaround and could be useful.

Changing maxElapsed did seem to fix the issue. Now what interests me are the drawbacks from raising that value or for what it is there in the first place (I guess higher values affect framerate more?).

I could just put that value on 0.1 and call it a day but I get the feeling that that would not be a clever solution.


(azrafe7) #7

From the docs:

/**
 * Cap on the elapsed time (default at 30 FPS). Raise this to allow for lower framerates (eg. 1 / 10).
 */
public var maxElapsed:Number = 0.0333;

So, what I think is there for is: even if your game drops down to 13 FPS, the update step will still be processed as if you’re at 30 FPS (0.0333 == 1/30). You may notice that things will jump around a bit (and at a faked 30 FPS it’s only slightly disturbing), but you’ll not experience a sluggish slowdown (at the cost of precision).


(Nicole Brauer) #8

Ah, ok. That makes sense.

So you could say that it is a threshold where it sort of changes to a fixed framerate to not skip too much (which is why it’s not time-excact).

I will use that as my fix and keep it in mind for the future. I will mark this topic as solved since the mystery of the secret maxElapsed has been finally unraveled.