time scale & performance question (?)

0 favourites
  • 11 posts
From the Asset Store
An educational game for Times Table. An easy to use template for developers to build larger games
  • I was just wondering...

    imagine that a game does a number of calculations and outputs a certain fps.

    if i set the timescale to 0.5, would that improve performance?

    could i then design the game to look "normal" at time scale 0.5, and since it would now be calculating half the time per seconds, would it get better fps?

    does tick calculations even change whit time scale?.... according to my test it doesn't.

  • I was wondering the same thing. I was wondering if slowing down the timescale would influence the logic fps. No it does not. Intead it just effects the dt value. It's a pitty. I would have like to set my logic fps. I found this does wonders for mobile performance to use manual 30fps logic.

  • Not unless your logic is in an event that runs every timescaled dt seconds.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • the timescale indeed does not affect performance, since the logic still applies to render to 60 fps.

    jayderyu: "It's a pitty. I would have like to set my logic fps. I found this does wonders for mobile performance to use manual 30fps logic."

    I agree with that, it would indeed mean 2x more time to render the logic, which could be great for games that don't require a lot of precision on all platforms.

  • yup, i tested this, and indeed no matter the timescale the game runs 60 ticks per seconds.

    I'm pretty sure construct had a "force 30fps" system action no too long ago. why did they remove it? =O

  • Because it sucked.

    1: Javascript is not that fast to begin with, so running events slower doesn't really help if the cpu is already overloaded.

    2: Garbage collection is horrid.

    3: Gpu, and cpu run independently.

  • i see

    its true though, ashley always says gpu takes considerably longer than cpu, and that cpu alone, in fact, would almost never impact on fps.

    so this was really not important i guess xD

  • Because it sucked.

    1: Javascript is not that fast to begin with, so running events slower doesn't really help if the cpu is already overloaded.

    2: Garbage collection is horrid.

    3: Gpu, and cpu run independently.

    1. Ashley only implemented a rudimentary 30fps mode. He has said that he firmly believes there is no benefit from running at lower than 60fps(though many PS3/360/One/Ps4 games and companies do otherwise). And more importatantly that actually running C2 at a proper 30fps would require a large foundational change to the engine. Which he doesn't believe that 30fps is worth while.

    2. Not really any different than Java's. And Java games have well worked around that problem. So has Ashley.

    3. That's kinda the point.

    The prior request was to drop the render down 30fps. This one isn't about slowing the rendering. This discussion is about controlling the rate of logic. And from practical experimentation I found using Everytick 0.033 for logic would turn a 15fps to 60fps. Depending on the insensitivity of the logic itself. Of course overkill of gfx is still overkill on gfx.

  • All I can say is, generally the main issue will be cpu, and the only real optimization would be to use triggered events rather than every tick.

    If that logic is too much for a trigger then no amount of culling will help you.

    The problem is that there isn't always a clear way to do that.

    Well there is, but its not the easy way.

  • 30 fps logic could in theory have twice more time to be calculated, also, since C2 doesn t render the screen if nothing has changed, it effectively would make less rendering work from what I understand

  • The time scale will probably have no effect on performance.

    IIRC, 30 FPS mode was dropped simply because I couldn't get it working properly. Accurate timing in Javascript appears to be very tricky unless you just go with every vsync. With the same code some devices kept running at 60 FPS, others would get a really horrible choppy 40-45 FPS, some would get 30 FPS but still look horrible (it wouldn't hit every other vsync, it would have some ugly irregular frame pattern), still others would dip below 30 FPS and get close to unplayable framerates. It could vary between those even on different browsers on the same system. So it didn't appear to be useful, so I got rid of it. Modern budget phones are surprisingly good and can get close to 60 FPS on simple games, and it will only improve in future, so I don't think there's any need to bring it back (even if I could get it working).

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)