[REQUEST] Developer to set FPS

Discussion and feedback on Construct 2

Post » Sat Nov 09, 2013 9:11 pm

Just yesterday I had an issue with a game bugging critically because the framerate dropped too low on a device while testing and objects started moving through walls. If there were an option in the debugger to test out slower frame rates before exporting, it would have saved some hassle for me.
B
62
S
20
G
56
Posts: 1,077
Reputation: 36,021

Post » Sat Nov 09, 2013 9:15 pm

I guess if you want a preview of 30 fps, you could set time scale to 0.5.
Image ImageImage
B
172
S
50
G
183
Posts: 8,442
Reputation: 115,603

Post » Sat Nov 09, 2013 9:18 pm

Unfortunately that doesn't work for finding frame rate dependent bugs (at least in my limited experience).
B
62
S
20
G
56
Posts: 1,077
Reputation: 36,021

Post » Sat Nov 09, 2013 9:31 pm

OK, OK, I agree that the human eye can discern scene update rates well above 18 fps, and probably out to above 60 fps for most people. That was not the context of my point, which I probably didnt make very well. My comparison with PAL etc was to point out that such lower refresh rates can be wholly acceptable for viewing purposes only as long as the update rate is consistent. I dont believe that a target audience will bother persisting with a game if the playability is hurt because the frame rate varies significantly between say 35-55 every few seconds.

Almost all other software creation tools allow the developer to set the frame rate (eg GMS, Corona, Moai etc). When I previously tinkered with GMS the default was 30 and plenty of acceptable games were created using that frame rate. @Jase00 and @Brashmonkey have the right idea with a frame rate rounder Unity uses vBlankCount to limit the frame rate to 30 to preserve the quality of the drawn display, which I understand is something similar (although I have no Unity experience).

The issue of screen refresh rate compatibility with the game refresh rate is an interesting point. My screen design knowledge is limited but surely 72 Hz and 144 Hz screens seem to cope with 60 fps games even though 60 does not wholly divide into 72. Is this because the higher the screen Hz then the smaller the frame draw error? This could be noticeable to an expert eye, but I dont know how different a 30 fps game and a 60 fps game would look from each other on a 72 Hz monitor (aside from the more hesitant sprite movement etc).

This is all beside the point, however I just dont understand why it should be acceptable for C2 to make a game that will inevitably be choppy and difficult to play in a mobile browser when a potential solution is close to hand. Whether the solution is to allow the developer to set the frame rate, or if C2 could apply the same idea as used in Unity to strive for a constant frame rate, I dont really care.   

If a solution would be easy to implement then I say lets go for it @Ashley. I know that youre the expert here but I think that there are some good arguments for implementing a frame rate rounder or lower fps option. Unless this is asking for the moon on a stick (complete C2 code base rewrite) in which case I will stop asking immediately!
A big fan of JavaScript.
B
76
S
20
G
76
Posts: 2,285
Reputation: 47,554

Post » Sun Nov 10, 2013 12:38 am

[QUOTE=newt] I guess if you want a preview of 30 fps, you could set time scale to 0.5.[/QUOTE]

@newt : that will slow the speed of the game, not act like a low FPS.

A low FPs induce less calculs, if you game is programmed as a frame-rate independent game, it will not slow down by low FPS, just be less fluid, and also, in that case, low FPS can induce bugs.

The timescale is the way to slow down easily the game while not changing the FPS.
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 » Sun Nov 10, 2013 1:35 am

Its the closest thing you have... other than throwing a bunch of particle objects in with the wash.

Of course if the fps is already at 30, that wont accomplish much.
Image ImageImage
B
172
S
50
G
183
Posts: 8,442
Reputation: 115,603

Post » Sun Nov 10, 2013 8:38 am

I think it's too bad. There are PS3 games rendering at 30FPS to allow the CPU and GPU to increase qaulity physics and game logic. Then it also gives around double the time for the GPU to increase visual quality. Then because the game is tuned to play at 30fps no one really notices.

But C2 will never support it. So I suggest leaving the discussion dead :(
This was one of my first requests over a year ago. I see this request a couple of times a season. And when an official response comes in. The answer is usually along the lines. "If it's possible to render at 60fps then why bother render at anything less".

Well other have given reasons, very good points of discussions, pointed out companies like EA, Sqaure, Ubisoft Watcdogs run at 30fps.

http://ca.ign.com/articles/2013/09/27/watch-dogs-runs-at-30-frames-per-second-on-next-gen-consoles

that's right. Big next gen game. because the graphics and gameplay qaulity can be improved due to more processing time. But it's just not good enough reason :(

So I gave up.

However there is an alternative. It requires some extra build time.
* C2 only draws if there is a graphics change. Take advangtage of that.
* Grab Rojo hounds canvas.
* All sprites are invisible at all times.
* render on to rojo hounds canvas at 30fps.

because the canvas is only drawn on at the 30fs tick 1/16 or something, The C2 only renders at 30fps and you get all the logic physics quality of 60fps. Still not sure how to increase visual quality though. But i'm sure it can be done.
jayderyu2013-11-10 08:42:49
B
92
S
18
G
9
Posts: 2,455
Reputation: 15,113

Post » Sun Nov 10, 2013 11:48 am

@jayderyu

Seems like quite a frustrating work around using canvas :( It's possible that it's not a simple change to make for Ashley. I'm sure if it was, judging by how many people are requesting it, and how regularly it's come up, it would have been added by now.

My game could really do with it. A physics object is spawned, and the game just slows down just enough that things go from silky smooth to slightly jerky.
@bearboxmedia
www.bearboxmedia.com

Nintendo Wii U Developer using Construct 2
B
84
S
15
G
7
Posts: 991
Reputation: 11,231

Post » Sun Nov 10, 2013 12:09 pm

Surely this just comes down to a matter of choice. If it isn't too difficult to implement then all it does is provide the developer with more choices/options, which is generally a good thing.

If it is too difficult, or it would break the engine too much, then let Ashley say so and this topic can then be closed.zenox982013-11-10 12:10:10
If your vision so exceeds your ability, then look to something closer.
Moderator
B
137
S
31
G
87
Posts: 5,555
Reputation: 60,454

Post » Sun Nov 10, 2013 12:13 pm

I didn't say we would never support it. IMO It's a trickier subject than most people are giving it credit for.

Issues with dt at low framerates are a different problem. If the framerate is low enough to cause problems with gameplay, usually it is much lower than 30 FPS, so a framerate cap does not fix that. It's a separate problem.

Adjusting the framerate cap at runtime is a pretty difficult problem and hard to get reliably right. You'd want to figure that out on startup, but Javascript optimisation and garbage collection tends to make things a bit choppy on startup, so any measurements would be unreliable. Even so later on there might just be a single momentary blip below 60 FPS, and you probably don't want that to trip it down to 30 FPS. So then you have to draw a line somewhere, and wherever you draw the line, sometimes you'll choose 60 FPS when it should have been 30 and 30 FPS when it would have been better to choose 60. I'm not at all confident the engine would be able to choose correctly most of the time.

Other game creation tools might provide a framerate setting, but I don't think that makes it a good idea!

A screen with a refresh rate like 72 Hz doesn't play the game at 60 FPS - it plays it at 72 FPS (if the system is fast enough). A framerate independent game adapts to this seamlessly, ensuring best quality display. To be more correct, instead of talking about 60 FPS and 30 FPS we should say "vsync rate" and "half vsync rate". The engine could support a "half vsync rate" mode, but then you can't easily tell the display refresh rate in Javascript, so you have to go off some adaptive system again, which is unreliable and might pick wrong, and then you have a choppy framerate again. Also that kind of thing needs reliable high-precision timers, which aren't available everywhere.

Consoles are a different case: the hardware is known in detail in advance, so you may be able to say confidently that a game you have absolutely cannot run at vsync rate. However C2 games run everywhere from powerful desktops to weak phones. IMO a game running at half-vsync on a powerful desktop PC is both annoying and an inferior experience to a vsync-rate game. I didn't spend all that money on a ridiculous graphics card for 30 FPS :)

In short my opinion is that if a system can run a game at vsync rate, we should let it. Since there's probably not a really reliable way to detect the need for half-vsync rate and then accurately hit that, the best way to try and let it is to leave the framerate uncapped.
Scirra Founder
B
403
S
238
G
89
Posts: 24,648
Reputation: 196,133

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 3 guests