Frame rate affecting player jump arc?

Discussion and feedback on Construct 2

Post » Thu Jan 17, 2013 6:08 pm

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.


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? boolean2013-01-17 18:09:01
B
24
S
4
G
1
Posts: 244
Reputation: 3,462

Post » Thu Jan 17, 2013 9:07 pm

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 :)
B
87
S
18
G
9
Posts: 2,455
Reputation: 14,834

Post » Thu Jan 17, 2013 10:33 pm

Try and use *dt after all your events if you didn't ...
B
34
S
16
G
16
Posts: 2,222
Reputation: 16,564

Post » Thu Jan 17, 2013 11:08 pm

[QUOTE=jayderyu]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.[/QUOTE]

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.

[QUOTE=Whiteclaws] Try and use *dt after all your events if you didn't ...[/QUOTE]

Since this is just using the built in platform behaviour, it should be using dt anyway.
B
24
S
4
G
1
Posts: 244
Reputation: 3,462

Post » Fri Jan 18, 2013 4:16 am

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



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:



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):



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?boolean2013-01-18 06:39:26
B
24
S
4
G
1
Posts: 244
Reputation: 3,462

Post » Fri Jan 18, 2013 5:50 am

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.
New to Construct ? Where to start

Image Image
Image Image

Please attach a capx to any help request or bug report !
Moderator
B
247
S
85
G
40
Posts: 6,998
Reputation: 57,786

Post » Fri Jan 18, 2013 6:31 am

[QUOTE=Kyatric] 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 ! ^^
[/QUOTE]

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:



[QUOTE=Kyatric]
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.
[/QUOTE]

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
boolean2013-01-18 06:35:39
B
24
S
4
G
1
Posts: 244
Reputation: 3,462

Post » Fri Jan 18, 2013 7:59 am

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.
B
45
S
19
G
10
Posts: 562
Reputation: 9,543

Post » Thu Jan 24, 2013 11:05 pm

This is happening to my new project on android too. Less fps = larger jumps.
B
31
S
7
G
2
Posts: 157
Reputation: 3,735

Post » Mon Jan 28, 2013 6:09 pm

This needs to be fixed ASAP.
B
23
S
5
G
4
Posts: 29
Reputation: 3,718

Next

Return to Construct 2 General

Who is online

Users browsing this forum: gamecorpstudio, Zonacas and 6 guests