Low FPS in C2 games is more crippling than it should be?

Discussion and feedback on Construct 2

Post » Sun Oct 05, 2014 1:12 pm

I think we would be better off with finding solutions to implement easily ingame setting to offer the better experience for the player first (more precise graphical options, sure we have the low quality combined with The set canvas size, but I think there are maybe other ways to reduce that fps graphical drop) rather than making sure that variation of fps is not as hard for the player (since in that case I would assume cpu lag is stable, while gpu lag is varying like crazy).

Could be just my opinion but lower fps in a long term basically means no go anyway so we should more make sure that we can alter the graphics as needed, or better, the player can alter them himself to have the experience he prefers.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
52
S
22
G
18
Posts: 2,122
Reputation: 17,093

Post » Sun Oct 05, 2014 1:18 pm

Okay, CPU lag on 30 fps isn't very noticable. GPU lag on 30 fps on the other hand destroys the gameplay with uneven lag spikes.

CPU lag:
https://dl.dropboxusercontent.com/u/705 ... gCPU30.txt

GPU lag:
https://dl.dropboxusercontent.com/u/705 ... gGPU30.txt
B
38
S
16
G
6
Posts: 537
Reputation: 7,582

Post » Sun Oct 05, 2014 2:00 pm

I think the Airscape log confirms my theory. Part of it has a dt sequence with these measurements:

31ms, 25ms, 41ms, 20ms, 31ms, 19ms, 35ms

There is variation from 19ms to 41ms - over double. This is really uneven frame scheduling and probably explains why it looks so bad, it's a totally unpredictable framerate frequency. I would expect frame-by-frame the actual CPU/GPU workloads are almost identical, unless you have significantly intensive events coded to run every other frame or every N frames. Assuming even workloads for each frame, this is probably bad scheduling by the browser.

At 37 FPS each frame is probably taking about 27ms to process, while the screen is drawn every 16.7 ms. If I write out how this is being scheduled...

Vsync 1: 16.7ms (skip)
Vsync 2: 33.3ms (render frame 1)
Vsync 3: 50ms (skip)
Vsync 4: 66.7ms (render frame 2)
Vsync 5: 83.3ms (skip)
Vsync 6: 100ms (render frame 3)
Vsync 7: 116.7ms (render frame 4)
Vsync 8: 133.3ms (skip)
Vsync 9: 150ms (render frame 5)
Vsync 10: 166.7ms (render frame 6)
Vsync 11: 183.3ms (skip)
Vsync 12: 200ms (skip)
Vsync 13: 216.7ms (render frame 7)

See how it's alternating between rendering two adjacent frames 16ms apart (e.g. render frames 3 + 4) and skipping two adjacent frames (e.g. render frames 6 and 7, which end up falling about 50ms apart!). No wonder it looks bad, that's like switching between 60 FPS and 20 FPS every few frames.

This needs to be solved on the browser side, I think. It looks like when each frame takes longer than a Vsync period to process then it starts aliasing really badly against the refresh rate. The only sensible alternative is to have the browser drop it right down to 30 FPS, which is a lower rate but at least looks predictable. I'll see if I can make a demo and file a bug report for Chrome...
Scirra Founder
B
387
S
230
G
87
Posts: 24,248
Reputation: 192,228

Post » Sun Oct 05, 2014 2:12 pm

Is there any ways to lock the max framerate? Low framerate is better than unpredictable play.
B
23
S
8
G
1
Posts: 172
Reputation: 2,780

Post » Sun Oct 05, 2014 2:41 pm

Actually maybe I was wrong:

http://www.scirra.com/labs/bugs/fpstest.html

In this minimal demo on my laptop dt is still pretty stable even after throttling it to ~45FPS. There was a bigger variation on Android though. Maybe it's system specific.
Scirra Founder
B
387
S
230
G
87
Posts: 24,248
Reputation: 192,228

Post » Sun Oct 05, 2014 3:14 pm

For me.

Before Throttle:
Image

After Throttle:
Image

FYI.
B
100
S
32
G
11
Posts: 1,552
Reputation: 21,612

Post » Sun Oct 05, 2014 7:09 pm

I'm not getting huge variation in @Ashley 's demo (It's around what @ArcadEed got), how exactly is that demo trying to throttle? If it's just spawning a lot of objects with Sine motion, it's probably CPU lag more than GPU lag.

I'm pretty sure fillrate is the limitation that tends to cause these huge inconsistencies, since reducing the window size *always* helps with it.
B
92
S
31
G
24
Posts: 3,191
Reputation: 32,679

Post » Sun Oct 05, 2014 8:07 pm

That demo does a CPU-side throttling, it just wastes CPU time to hit 45 FPS. It's a bit weird, it looks juddery but relatively smooth in Chrome stable, but in Canary when throttled it seems to look even worse.

20-24ms isn't a very big range in dt, it's probably normal. The Airscape log had a much bigger variation (19-41ms).
Scirra Founder
B
387
S
230
G
87
Posts: 24,248
Reputation: 192,228

Post » Sun Oct 05, 2014 8:12 pm

Yep, totally agree. The problem definitely lies on the graphics side. Are you still sure it's a Chrome issue?
B
92
S
31
G
24
Posts: 3,191
Reputation: 32,679

Post » Sun Oct 05, 2014 10:46 pm

interesting investigation, i have been wondering this same thing long ago...
B
23
S
6
G
3
Posts: 316
Reputation: 3,461

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: jakezinis and 4 guests