Could Computer Be Locking My FPS?

At some point in the last few months, I noticed that my computer was running my game at a lower amount of frames per second. I was adding things here and there so I just assumed it was the extra work load. Where I used to get 60 fps, I was now getting 40. Not a huge deal. It was still playable, just not as smooth.

Then today I tried a quick demo on the forum and saw that it was also 40fps. I thought that was a weird coincidence so I loaded up a very early version of my game that had next to nothing in it and that I knew ran well and it was also at 40fps.

I took my current build to another computer and tested it there. It ran at 60 to 75 fps depending on the size of my window.

Does anyone know why I might be getting the locked 40fps on my computer? Thanks for your help.

Ben

http://www.needyourdisease.com

He said, he tested on another computer where it works normal, so it's for sure not the events in C2.

It can be a technical problem of your machine or a software problem. How you test your C2 game? In a browser or node webkit? Maybe some third party plugins where installed in Chrome (or whatever browser you use) that slow down.

What browsers (and which versions) do the computers have? Newer versions of Chrome seem to be running my games slower than before. Internet Explorer has no trouble maintaining 60 fps, but Chrome struggles unless I make the window really small or go full screen...

Quick way to check for sure: make a new project with next to nothing in it. If it runs at 40, there's an issue somewhere.

Nesteris "Also I don't see how a Construct 2 game could ever run at 75FPS since it's hard-capped at 60FPS."

if the refresh rate of the moniter is 75 Hz, the game will refresh at a 75 fps rate, same goes for 120 Hz (which was described in another thread), C2 never hard capped any game to match one frame-rate (this is also the reason dt is there too in the first place, to make sure the game runs accordingly accross platforms).

if it was really 40 fps with not a lot of variations, and the game was playable, verifying the refresh rate of the monitor will be needed, as sqiddster said, test on a new project with maybe just one thing moving to see the result.

Thank you to everyone that posted. Turns out Aphrodite was correct. The laptop I was working on had the screen refresh rate set to 40 Hz. I looked up how to change it up to 60 and my FPS went back up. Thanks again for everyone's help.

Ben

http://www.NeedYourDisease.com

http://www.facebook.com/needyourdisease

http://www.twitter.com/needyourdisease

Nesteris it just happens that most people thinks that since it caps to the refresh rate, which is 60 Hz in most cases, but it caps to the refresh rate and not 60 fps (that was why some games where the framerate independancy was not well implemented were not working as they should with 120 Hz screens).

the lack of hard cap is actually why having an 30 fps mode was impossible/really hard in the first place.

sman118 nice to know it was the issue

Nesteris

If you're interested in more information about it, I posted an article about how the FPS of a Construct project is tied to the refresh rate on the C2 wiki:

Delta Time and Refresh Rate

Collisions and Framerate

I actually ended up figuring out how it worked on accident as a result of playing with the preview.js file a ways back.

Here's part of the article:

[quote:rsozbn15]

The underlying Construct 2 engine uses something called "requestAnimationFrame" (underlying v-sync related browser timing) to attempt to peg the game tick at approximately 60 times per second, however, it usually matches the display refresh rate of the browser/computer which is nearly always 60hz except in the case of some new 120hz monitors. This means that in most cases, dt ~= 0.0167 of a second (remember that dt is the elapsed time in seconds since the previous game tick). Obviously though, cpu intensive games and other things can cause the frame-rate to fluctuate.

Construct makes use of delta-time in order to be frame-rate independent. A frame-rate independent game tries to ensure that a game behaves in the same way regardless of the actual FPS. In some older games, the movement of sprites in the game was proportional to the frame rate. This meant that if you tried to play the game on a modern system today, the high frame rate would cause everything in the game world to move extremely fast making the game virtually unplayable.

In most cases, this means that delta-time returns the actual time in seconds from the last game tick. However, if the frame-rate dips below 10 fps, Construct will cap the returned value of DT at 0.1 seconds. When this happens, the game will physically appear to slow down. As outlined in the article on delta time, Construct synchronizes the logic and rendering loop through something called requestAnimationFrame which is used internally by the browser to peg the FPS to the refresh rate of the local monitor, typically 60hz so 60fps.

I have a similar problem, and just to put it asside, my laptop has 60 hz refresh rate set...

The thing is, I developed a game and had solid 55-60 FPS and 16% CPU on Chorme and FF (lets call it "V1"), and then I decided to remake the whole thing, but whit smaller sprites (insted of 256x256 & 128x128 sprites I used 64x64 and 32x32, I also split the size of layout and window, just to optimize my game for mobile, "V2"). I added some extra events, but didn't change any project settings. When I debug the game "V2" I get 40-50 FPS and 35% CPU. I thought It must be becuse of extra events and couple of more sprites I added, but just to be sure I reopened the original version "V1" and I also got 40-50 FPS tops... What the hell could have happened?

It all happened in last month or so, I believe I had updated C2 to a newer version since, could it be a problem?