How do I limit fps?

0 favourites
  • 11 posts
From the Asset Store
Create a game inspired by great arcade classics as Operation Wolf
  • I've seen that you can't limit the fps and it's something I'd like to do, why isn't there an option to do it? Is there a way to do it with javascript or not? I don't want the game to run at more than 60 fps because it spends more battery on mobile devices, so I want to put an option for medium fps and high fps so that the player decides if You want to play with high fps and more battery drain, I don't know if there are more people who want this feature, I also feel that the game goes to more than 60 fps, it wastes unnecessary resources, I hope someone helps me and thanks in advance

  • Afaik this is one of the major limitations of working with JavaScript and a browser wrapper and by extension construct. I wouldn't expect it to go away anytime soon.

  • The only place I’ve seen anything to limit the fps is on the construct discord the user mikal made something to do that. Haven’t used it and not sure if there’s any limitations with that plug-in.

    Officially I think the devs tried to do that before but weren’t able to get anything that worked well. Maybe they will revisit it since it seems to be requested more as of late.

    I don’t think there’s anything that can be done with scripting to limit the fps. The render loop is controlled by the construct runtime and that part isn’t exposed to the scripting api as far as I can tell.

    I can think of one roundabout way to limit the fps but it’s more of a trick and doesn’t work with most of construct. The idea is the screen will only redraw if things change, so you could only move or change things every other frame or so. But as stated above that won’t work with most behaviors or other things that normally update every frame.

  • The only place I’ve seen anything to limit the fps is on the construct discord the user mikal made something to do that. Haven’t used it and not sure if there’s any limitations with that plug-in.

    Officially I think the devs tried to do that before but weren’t able to get anything that worked well. Maybe they will revisit it since it seems to be requested more as of late.

    I don’t think there’s anything that can be done with scripting to limit the fps. The render loop is controlled by the construct runtime and that part isn’t exposed to the scripting api as far as I can tell.

    I can think of one roundabout way to limit the fps but it’s more of a trick and doesn’t work with most of construct. The idea is the screen will only redraw if things change, so you could only move or change things every other frame or so. But as stated above that won’t work with most behaviors or other things that normally update every frame.

    I understand, can you help me by giving me the discord link to try or ask about this?, thanks anyway for the help

  • It's not currently possible for web content to limit the FPS in a way that correctly handles both CPU and GPU overload. For example if you want to limit to 30 FPS, but the GPU is overloaded and running at 25 FPS, it's not possible to handle that properly in JavaScript code without it descending in to a janky mess. You can code something that tries to skip frames or some such, but it won't handle cases like that properly.

    Star this Chrome issue to show support for proper FPS limiting in browsers.

    However if your only goal is to save battery on high-framerate mobile devices, AFAIK these devices already drop the framerate in power saving mode. So if that's your only reason to limit the FPS then I'd argue it's not necessary as it's already handled by the system.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • I do remember the jank encountered in previous attempts, but I think it might be possible to avoid that. Dt seems to vary a bit per frame. At 60fps it should be 0.0166 but I've seen it lower to around 0.0163 in my tests as an example. My idea is we can skip frames if dt is less than some target framerate, but instead of checking if dt<1/30, we let it be approximate with say dt<0.3. I coded up a complete test to check my idea and on my 60hz screen I was able to get this. Super janky with dt<1/30, but smooth with an approximate value for 1/30 like dt<0.03.

    It gives the high and low dt, the average dt of the last 128 drawn frames, and a little graph of the dt times for the drawn frames.

    And here's the relevant animation loop. The only remarkable part is the frame skip.

    let prevTime=0;
    function gameLoop(newTime)
    {
    	requestAnimationFrame(gameLoop);
    	newTime/=1000;
    	let dt = Math.min(0.05, newTime-prevTime); //20fps min to account for tabbing away
    	if (dt<0.3) // skip frame if dt isn't at least approximately 1/30.
    		return;
    	prevTime=newTime;
    	tick(dt);
    	draw();
    }
    requestAnimationFrame(gameLoop);

    It should work the same when cpu/gpu load causes frames to be skipped. The only thing that would need testing is how it would behave with other screens with higher refresh rates. Anyways, just an idea.

    Edit:

    0.3 is fairly arbitrary as a lower value than 1/30. dt<1/maxFPS-1/480 may work better, at least should work for refresh rates up to 240.

    dt<1/30-1/480

  • It's not currently possible for web content to limit the FPS in a way that correctly handles both CPU and GPU overload. For example if you want to limit to 30 FPS, but the GPU is overloaded and running at 25 FPS, it's not possible to handle that properly in JavaScript code without it descending in to a janky mess. You can code something that tries to skip frames or some such, but it won't handle cases like that properly.

    Star this Chrome issue to show support for proper FPS limiting in browsers.

    However if your only goal is to save battery on high-framerate mobile devices, AFAIK these devices already drop the framerate in power saving mode. So if that's your only reason to limit the FPS then I'd argue it's not necessary as it's already handled by the system.

    I understand, I'm going to stop worrying about it, I already use the dt so there's no problem

  • I do remember the jank encountered in previous attempts, but I think it might be possible to avoid that. Dt seems to vary a bit per frame. At 60fps it should be 0.0166 but I've seen it lower to around 0.0163 in my tests as an example. My idea is we can skip frames if dt is less than some target framerate, but instead of checking if dt<1/30, we let it be approximate with say dt<0.3. I coded up a complete test to check my idea and on my 60hz screen I was able to get this. Super janky with dt<1/30, but smooth with an approximate value for 1/30 like dt<0.03.

    It gives the high and low dt, the average dt of the last 128 drawn frames, and a little graph of the dt times for the drawn frames.

    And here's the relevant animation loop. The only remarkable part is the frame skip.

    let prevTime=0;
    function gameLoop(newTime)
    {
    	requestAnimationFrame(gameLoop);
    	newTime/=1000;
    	let dt = Math.min(0.05, newTime-prevTime); //20fps min to account for tabbing away
    	if (dt<0.3) // skip frame if dt isn't at least approximately 1/30.
    		return;
    	prevTime=newTime;
    	tick(dt);
    	draw();
    }
    requestAnimationFrame(gameLoop);

    It should work the same when cpu/gpu load causes frames to be skipped. The only thing that would need testing is how it would behave with other screens with higher refresh rates. Anyways, just an idea.

    Edit:

    0.3 is fairly arbitrary as a lower value than 1/30. dt<1/maxFPS-1/480 may work better, at least should work for refresh rates up to 240.

    dt<1/30-1/480

    Thank you! So I'm not going to complicate myself with this, I'm going to use the dt to make it work well regardless of the frames, just like many people use 60hz on their phones to save battery, I also think this is just a trick and doesn't really limit the fps, (correct me if I'm wrong) anyway thank you very much for taking the time to try this

  • It seems to work. It renders half as many frames per second in a consistent manner, and according to the task manager the cpu usage is cut in half more or less as well. It was made completely separate from construct though. But render loops are often similarly done, so it was meant as a possible reference if the devs should want to revisit the idea. If not, it's no worry, I'll likely use it later.

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