Frame rate affecting player jump arc?

Hi all

I'm working on a game that is a bit of a super-meat-boy/I-wanna-be-the-guy type game, so I'm trying to keep certain events timed the same when the layout restarts and the player replays the level.

I'm using the platformer behaviour and I'm noticing that when the FPS drops, the jump arcs go all loopy. I think this is combining with the fact sometimes the browser will drop in frame rate for a moment while the player is jumping and where before they could make the jump fine, now the jump arc doubles in height, causing them to run into an enemy. I found this thread from back in October where slw666 seemed to be having the same problem, but Ashley implied it should be working fine.

I did some tests to see how much the frame rate affects the player movement. In the screenshot below I ran the same layout three times ? The first was at 60FPS, the second was around 40-45FPS and the last was sitting at about 25-30FPS. Those numbers are roughly correct based on the Chrome FPS counter. I got those frame rates by saying once the player left the layout, spawn 10000 instances of a sprite and then restart the layout and repeat.

<img src="https://dl.dropbox.com/u/20830426/jumpArcs.png" border="0">

Test Capx

If you run the capx above you might end up with different numbers, but you should still see the jump arcs changing when the frame rate drops.

I'm not much of an expert in this area, so I'm at a bit of a loss of what to do. Should the framerate be affecting the player jump arc? Is it maybe that it is working but my test is flawed?

Hmm, sounds like a problem to me. As I understand it Platformers are supposed to be frame independent. Which by your description is indeed occuring. It seems the gravity is taking effect at the same period of duration, but with less FPS momentum not incrementing as high in the same amount of time. Maybe because motion is still rendered at a per step.

I hope this problem get's fixed as it's a very critical platformer problem. Levels are entirely designed based around a dependable jumps :( Thanks for bringing this up :)

Try and use *dt after all your events if you didn't ...

It seems the gravity is taking effect at the same period of duration, but with less FPS momentum not incrementing as high in the same amount of time. Maybe because motion is still rendered at a per step.

That's what I was thinking too, and may be the same problem as the infamous quake3 jump height bug, where higher frames means gravity is applied more often.

Try and use *dt after all your events if you didn't ...

Since this is just using the built in platform behaviour, it should be using dt anyway.

So here's a funny thing, I added the following condition in:

<img src="https://dl.dropbox.com/u/20830426/c2FrameLock.png" border="0" />

This is in a version where I'm not spawning 10000 objects each test, but is more of a general test of jump accuracy.

With the frame rate locked at 60fps all three runs overlap perfectly:

<img src="https://dl.dropbox.com/u/20830426/frameLocked.png" border="0" />

Without locking at a framerate of 60, the following variations in jump height appear (remembering this is just letting chrome hover around 58-60fps without artificially hampering the fps):

<img src="https://dl.dropbox.com/u/20830426/notFrameLocked.png" border="0" />

The difference isn't much but it is highlighting the same problem - that the frame-rate jitter is causing different jump heights.

Ashley: Not being that familiar with this territory myself, is this a solvable problem? Being HTML5 is there anything that can be done code wise to correct this?

Yeah, super good news, it's only an issue with chrome.

Testing the capx in Firefox, there are a few variations but not as marked as in Chrome.

Easy solution, stop using Chrome, yeah ! ^^

Also, I'm not sure this test is valid anyway, as you're unlikely to have such a logic in a "true" game.

I'm not understanding how spawning 10k sprite is a good way to "lock" the FPS, as the loop only happens when the character is out of the screen, and the layout is supposedly restarted at this moment anyway.

If you try to use the system command FPS, you'll see the FPS drops only happens once the sprite is out of screen, and that's all.

Yeah, super good news, it's only an issue with chrome.

Testing the capx in Firefox, there are a few variations but not as marked as in Chrome.

Easy solution, stop using Chrome, yeah ! ^^

I can get it to happen in FireFox too, but it seems Firefox takes more load to get the FPS down. Here's my firefox test with more sprites:

<img src="https://dl.dropbox.com/u/20830426/firefoxTest.png" border="0" />

Also, I'm not sure this test is valid anyway, as you're unlikely to have such a logic in a "true" game. I'm not understanding how spawning 10k sprite is a good way to "lock" the FPS, as the loop only happens when the character is out of the screen, and the layout is supposedly restarted at this moment anyway.

Perhaps I didn't describe the original post properly. The problem isn't so much that if you just happen to have 300000 sprites on screen C2 starts to go wonky, it's that lower frame rates seem to have an affect on the jump arc of the platform behaviour. The purpose of spawning all the sprites and keeping them on screen was simply a way bog the browser down to lower frame rates. I wanted to see how performing the exact same action at different frame rates changed the jump path the player took.

The locking the frame rate post was separate from spawning all these sprites - That second post was what happens to the jump path when the frame rate is locked at 60. At that point, the gravity or whatever seems to be causing the variation, works out fine. It's when fps fluctuations occur that the course of the player changes. The second post was more of a real world example, the first post is what seems to be the same problem taken much more extreme (ie. forcing the game to run at around 30fps instead of 58fps).

I'm no expert at this though <img src="smileys/smiley1.gif" border="0" align="middle" />

It's because of dt I think. NOT using dt will make the jump arcs perfect regardless of framerate. Only problem is, the higher the framerate, the faster it goes (Kinda like upping the Timescale) and the lower the framerate, the slower it goes.

This is happening to my new project on android too. Less fps = larger jumps.

This needs to be fixed ASAP.

I got this as well. Happens with Chrome and Node-webkit builds, haven't tested other browsers. I'm not using *dt either.

Hello,

I found that threat and it seems not to be resolved. I have the same issue on my game.

My hero is using the platform behavior. When my fps is fine, I can jump over a wall corresponding to the jump high. BUT after testing my game on my laptop, which has a bad fps :

Chrome / Nodewebkit : I can't jump over that same wall. My jump is less high.

Firefox : I can jump over wall I shouldn't. My jump is more high.

The jump should be fps independant but it seems it is not.

So the player can definitly be blocked or pass an obtacle he souldn't if he has a bad fps. This is a HUGE issue.

Any news about that ?

Search the forum/tutorials for how to use vectors. might help