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

Discussion and feedback on Construct 2

Post » Thu Oct 16, 2014 1:48 pm

Here is an example showing that low or normal frame rate doesn't solve jerkiness in non webgl canvas. Maybe that's just how we need to expect non accelerated canvas to perform?

https://www.youtube.com/watch?v=tR2cess9NTw

I shift the rendering/window size in the video going from big to small. At the smallest it runs ~40fps but is the same amount of jerkiness as ~15fp
Developing Surolace, the survival role playing space game.

surolace-survival-role-playing-space-game_t116953
B
14
S
4
Posts: 303
Reputation: 1,730

Post » Thu Oct 16, 2014 1:52 pm

Another thing I experienced, that is not related directly, but is still graphic and performances related, is that a fullscreen game will be far more unstable fps wise than without being fullscreen, buuuuuuut I tested that on a computer with a 4 years old graphic driver, so I would think this is not useful in any way retrospectively. (Just to say, that without webGL, scaling the game seems to be more intensive, it was hardware accelerated as far as my browser said)
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
54
S
22
G
18
Posts: 2,123
Reputation: 17,150

Post » Thu Oct 16, 2014 9:54 pm

@Colludium - Are you making a game on a phone?

I have an average laptop that I test my stuff on (i5, integrated graphics, 4 gigs o ram, etc). I am developing a game for pc and wi u and I run 1200 physics objects at a time. I use a custom sleeping system that allows my game to have 20,000 physics objects in a level, and 100s of compound characters (12+ sprites each) with overlapping checks on all of the characters every tick. I even have physics enabled particle systems because I can. I literally have no fps problems and have no need for that many objects, so I am set. I am curious how creating one object or performing more than one collision check per tick can cause lag. It doesn't make sense.

However, I have noticed as the OP stated that the game looks perceptibly different at 40fps instead of 60fps
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,173

Post » Thu Oct 16, 2014 9:57 pm

@ Aphrodite - are you testing full screen in a browser or are you exporting the object? I have never noticed a difference between full screen and small screen unless you are upscalling via high quality and then that is just a function of how many pixels you have to draw each frame. (if you have a monitor that is 2000,2000 and you have 8 layers that force own texture... well, that is alot of stuff to render).
Image
B
33
S
11
G
2
Posts: 564
Reputation: 5,173

Post » Thu Oct 16, 2014 10:57 pm

@ruskul, - I'm developing for desktop - browser and Node. This jittering is usually very slight and manifests as a momentary hesitation, but to my eyes it stands out very pronounced indeed.

I've just posted a demo capx in the other thread here.
A big fan of JavaScript.
B
76
S
20
G
76
Posts: 2,290
Reputation: 47,564

Post » Thu Oct 16, 2014 10:58 pm

ruskul wrote:@ Aphrodite - are you testing full screen in a browser or are you exporting the object? I have never noticed a difference between full screen and small screen unless you are upscalling via high quality and then that is just a function of how many pixels you have to draw each frame. (if you have a monitor that is 2000,2000 and you have 8 layers that force own texture... well, that is alot of stuff to render).


Was not my game, I guess it was the default settings aka high quality.
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
54
S
22
G
18
Posts: 2,123
Reputation: 17,150

Post » Fri Oct 17, 2014 8:18 am

Aphrodite wrote:Another thing I experienced, that is not related directly, but is still graphic and performances related, is that a fullscreen game will be far more unstable fps wise than without being fullscreen, buuuuuuut I tested that on a computer with a 4 years old graphic driver, so I would think this is not useful in any way retrospectively. (Just to say, that without webGL, scaling the game seems to be more intensive, it was hardware accelerated as far as my browser said)

I've found this with games & other graphically intense items in general. I generally avoid fullscreen for this reason.
B
28
S
9
G
2
Posts: 154
Reputation: 2,868

Post » Fri Oct 17, 2014 11:42 pm

@Ashley are you looking into this?

It's basically made my game completely unplayable below 60fps. Even in the high 50's the input delay and dt inconsistency are really noticeable.
B
92
S
31
G
24
Posts: 3,191
Reputation: 32,709

Post » Sat Oct 18, 2014 4:29 am

Here's a log to verify that claim:

Code: Select all
dt: 0.017 | FPS: 56
dt: 0.03299 | FPS: 56
dt: 0.00999 | FPS: 56
dt: 0.016 | FPS: 56
dt: 0.016 | FPS: 56
dt: 0.019 | FPS: 56
dt: 0.024 | FPS: 56
dt: 0.01399 | FPS: 56
dt: 0.01799 | FPS: 56
dt: 0.01799 | FPS: 56
dt: 0.03399 | FPS: 56
dt: 0.017 | FPS: 56
dt: 0.016 | FPS: 56
dt: 0.03299 | FPS: 56
dt: 0.01499 | FPS: 56
dt: 0.01799 | FPS: 56
dt: 0.01799 | FPS: 56
dt: 0.016 | FPS: 56
dt: 0.01499 | FPS: 56
dt: 0.018 | FPS: 56
dt: 0.03299 | FPS: 56
dt: 0.016 | FPS: 56
dt: 0.01599 | FPS: 56
dt: 0.018 | FPS: 56
dt: 0.01599 | FPS: 56
dt: 0.017 | FPS: 56
dt: 0.01699 | FPS: 56
dt: 0.016 | FPS: 56
dt: 0.016 | FPS: 56
dt: 0.01699 | FPS: 56
dt: 0.033 | FPS: 56
dt: 0.01099 | FPS: 56
dt: 0.01499 | FPS: 56
dt: 0.016 | FPS: 56
dt: 0.01699 | FPS: 56
dt: 0.02199 | FPS: 56
dt: 0.013 | FPS: 56
dt: 0.023 | FPS: 54
dt: 0.01799 | FPS: 54
dt: 0.019 | FPS: 54
dt: 0.032 | FPS: 54
dt: 0.01499 | FPS: 54
dt: 0.01699 | FPS: 54
dt: 0.03399 | FPS: 54
dt: 0.024 | FPS: 54
dt: 0.01699 | FPS: 54
dt: 0.016 | FPS: 54
dt: 0.017 | FPS: 54
dt: 0.01699 | FPS: 54
dt: 0.016 | FPS: 54
dt: 0.01699 | FPS: 54
dt: 0.016 | FPS: 54
dt: 0.017 | FPS: 54
dt: 0.01699 | FPS: 54
dt: 0.016 | FPS: 54
dt: 0.02499 | FPS: 54
dt: 0.025 | FPS: 54
dt: 0.01699 | FPS: 54
dt: 0.017 | FPS: 54
dt: 0.01699 | FPS: 54
dt: 0.016 | FPS: 54
dt: 0.01799 | FPS: 54
dt: 0.01499 | FPS: 54
dt: 0.018 | FPS: 54
dt: 0.01599 | FPS: 54
B
92
S
31
G
24
Posts: 3,191
Reputation: 32,709

Post » Sat Oct 18, 2014 12:50 pm

I don't think it's a C2 bug, there's nothing much we could change on our end. It's a question of getting a minimal repro to pass over to browser vendors.

I tried a bit harder and came up with a new GPU-based repro, and I can get it to vary severely by drawing much larger rectangles on a mid-range laptop:
http://www.scirra.com/labs/bugs/fpstest-gputhrottle.html
(If you've viewed it before press refresh to get the latest test - should draw ~1000x1000 rectangles and aim for 45 FPS)

I can get severe dt variations from 8ms to 44ms in Chrome. That's pretty extreme and the juddering is visible on the moving black box.

I guess we just need to figure out if this is widely reproducible (i.e. is it a good demo to show to browser vendors?) and then if so use it to file a bug report with affected browsers. So, does it reproduce it for everyone else?

BTW I tried that test in IE11 and the dt variation is sometimes much smaller (22-24ms) but it still looks pretty bad on the motion. Are actual games any better or worse in IE11? (I think a bug report with a title like "Chrome does X worse than IE11" should get their attention - it's worked before :P)
Scirra Founder
B
403
S
238
G
89
Posts: 24,654
Reputation: 196,145

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 14 guests