Framerate vs. Framerate

Why does 30 fps in any native/console game means smooth game,

and 30 fps in any Construct 2 game means slow, almost not playable game?

Maybe it's silly question, but I'm just curious

C2 is designed to run at 60 fps not 30. To get a realistic comparison stick an elephant on a motorcycle and see how fast it goes.

newt

so why 60 fps?

even next gen consoles usually play 30 fps because 60 fps is too demanding

Very very good question. Not sure what newt is getting at. C2 is obviously designed to run at variable framerates or dt wouldn't be a thing.

The short answer is 'it's the browser makers' fault and they aren't fixing it'.

It's so stupid. All html5 games are unplayable below 60fps. That's totally unacceptable.

A few months ago I filed a Chrome bug report about it. Surprise surprise, haven't heard from them.

C2's engine does not cope with rapidly changing values of dt. A browser is always trying to achieve vsync fps, and it might miss a frame which means c2 draws the next frame where the last frame should have been. Then the subsequent frame seems to get drawn with values of dt that don't exactly match, maybe because dt is never predicted it's always historical. This seems to be worst in behaviours like physics and platform...

Does this mean that chrome is a small motorcycle and the c2 engine is an elephant?

C2 is meant to run at the V-sync, however, at 30 fps, the framerate may not be stable enough, and unstable framerate is worse than stable framerate.

That and the browser might f*ck it up, why do consoles go with 30 fps is something I wonder, a console is completely fixed hardware.

Also, dt is not here to cover varying values of the fps at first, but to make games work on different refresh rates (120 fps vs 60 fps).

Here's an interesting and recent blog on managing frame rate in html5. I have no idea if c2 implements these techniques or not, or even if Ashley thinks they could be viable in the c2 engine given its stage of development. I thought it interesting because it suggests a browser-independent method of managing fps variations, especially for physics...

Can anyone translate this into English?

There are different size motorcycles, and different size riders. The elephant would be the rider. It is the game in this scenario.

The forum is the crowd at the race, and this thread is where the elephant fell off, the motorcycle crashed into the crowd, everyone died ...horribly.

That only happens because the crowd tries to make the elephant perform acrobatics whilst balanced on the under-fueled and duck-taped motorcycle....

What is with this forum and analogies.

Yeah, I have the same question:

Why on consoles (XOne, PS4) 30FPS it's working fine but in HTML5 30FPS (even 50FPS) it's not enough for a smooth gameplay?

: S

Those games on there are smaller elephants.

Why isn't it smooth? I'm pretty sure it has to do with how the browsers handle the rendering.

Independent of C2, motion still isn't buttery smooth, well at least not on my pc. Part of the issue is graphics card support, mine for instance has bugs in the driver and ati won't be making an updated driver for a ten year old card.

Here's a very simple js test where motion still isn't smooth:

viewtopic.php?f=147&t=115540&p=835995&hilit=jsfiddle#p835995

I'm pretty sure Javascript isn't to blame. I was able to get smooth motion in my now stalled wrapper experiment, in which I still used javascript, but implemented my own crude renderer on top.

Reducing the framerate doesn't fix the lack of smooth motion.

There was a discussion before of adding a 30fps mode, but it didn't work out as I recall because it wasn't smooth and had an unstable framerate.

Anyways I found this page describing a way to use a fixed framerate, so I took a gander at editing the C2 runtime to implement it.

http://stackoverflow.com/questions/1951 ... pplication

It seems to work alright, at least for me. It still has little pauses on my pc, but it's at least as smooth looking as it normally is on my pc.

These are the changes to limit the fps to 30, if anyone wants to test it.

file: \exporters\html5\preview.js

"..." is any number of lines, for this you'll want to find the line with "Runtime.prototype.tick". Bold are added lines. I prepended "rojo" to the variables I added. If it breaks, then just re-install C2 to fix it, or you could backup the file before editing it.

...

var rojoThen = cr.performance_now();

Runtime.prototype.tick = function (background_wake, timestamp, debug_step)

{

...

var rojoDelta = nowtime-rojoThen;

var rojoInterval = 1000/30;

if (rojoDelta >= rojoInterval)

{

rojoThen = nowtime - (rojoDelta % rojoInterval);

raf_time -= (rojoDelta % rojoInterval);

// Execute logic

this.logic(raf_time);

...

this.logictime += cr.performance_now() - logic_start;

}

};

The main issue is that your game is likely NOT hitting a consistent 30 fps. If the lower frame-rate is due to the CPU/GPU being taxed and having to wait longer between frames, you wont get "smooth" 30 fps, because you're getting a fluctuating fps in the first place. It's possible to schedule longer times between renders for logic, however construct doesn't have an in engine option to do this, so your "30 fps" is not really the same as a console games 30 fps, it's a 25-35 fps from overtaxed hardware. If you were to build your own renderer that skips every other frame in a properly scheduled way it'd be 'smooth' (if you could really call 30 fps smooth in the first place, something i'd argue), I've done tests with Q3D doing exactly this, and even have an option to skip rendering of specified ratios of frames. If your game is lagging to 30 fps it's unplayable because of the instability of the logic and the effect that has on frame scheduling, not because of the renderer/browser or otherwise. It's the same way any game because horrendous to play with significant drops in framerate, especially when timedelta based games make everything unstable in fluctuating fps.