• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

Windows Game runs at half framerate

A

AlmostOutspoken

Guest
I recently imported my GameMaker: Studio 1.4 project into Studio 2 and built it for the Windows VM platform. The game is set up to run at 60 fps in the project settings, but from the moment it launches it runs at a relatively steady 30 fps.

When I check the debug overlay, the uncapped frame rate appears to be much higher than my target, so I'm not entirely sure what's going on.

I'd be happy to provide any additional information if it helps!
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
Check the sleep margin in the Game Options. Set it to 10 if it's not already and try again.
 
A

AlmostOutspoken

Guest
That seems to have done the trick. I appreciate the support!
 
Seems like it.

Even the manual doesn't make sense



So effectively to make your game not stutter, you want to clag up the main loop by 10ms. Thus speeding up the game???

Generally when I take my foot off the accelerator, my car slows down, not speed up :p
Yes, and on top of that, making it run better on one system might make it run worse on another? I really don't understand what's going on with this sleep setting thing. Did other versions of GM suffer from these problems, too? Or is this a bandaid solution for a new problem introduced by GMS2?
 

Samuel Venable

Time Killer
Did other versions of GM suffer from these problems, too? Or is this a bandaid solution for a new problem introduced by GMS2?
The latter. However this is also a problem in GMS 1.4. GM 8.1 and below didn't have the problem. Even older versions of GMS don't have it. i.e. 1.3 and below. I can't remember what version of 1.4 introduced the sleep margin, but it was fairly recent, if I remember right.
 
Last edited:

Nocturne

Friendly Tyrant
Forum Staff
Admin
Okay, so sleep margin has always existed, only it was never exposed to the user. This was something that was exposed specifically because a few developers requested it. The default value in previous versions of GMS was 10, so (in general) leave it at 10 and don't ever touch it again and you're getting the same behaviour as always. The manual does need updating as the value of 1 is not what most people should be using and I'll see about getting that sorted.
 
Okay, so sleep margin has always existed, only it was never exposed to the user. This was something that was exposed specifically because a few developers requested it. The default value in previous versions of GMS was 10, so (in general) leave it at 10 and don't ever touch it again and you're getting the same behaviour as always. The manual does need updating as the value of 1 is not what most people should be using and I'll see about getting that sorted.
Thanks, that's what I was wondering. Why isn't the default value still ten, though? It seems to be causing a lot of problems this way...
 

Nocturne

Friendly Tyrant
Forum Staff
Admin
The sleep margin is the time that GMS will sit in a tight loop rather than sleeping so that it can correctly update the next actual frame without stutter. Slight increase in CPU overhead, but smoother experience. A lower sleep margin means that there is increased likelihood that the sleep will be inaccurate and so cause a frame stutter. To use your car analogy, it's the difference between a cold start and a start with a revved up engine. :)
 

rwkay

YoYo Games Staff
YYG Staff
High Sleep Margins mean the CPU is doing more waiting and means that battery usage will be driven higher

We are looking for a better solution that still gives flexibility, but due to the heritage of GameMaker and the expectation of being able to change the frame rate this is more tricky as it does not really fit with the way that DirectX wants to do things on a PC (it wants you to set the frame rate and leave it there).

We are working on this solution now - the best practice is to set the frame rate in Game Options and leave it there.

Russell
 

GMWolf

aka fel666
it wants you to set the frame rate and leave it there
Honestly that wouldnt be too bad. Perhaps now is the time to make the change? Im not aware of many occasions when you would want to change it dynamically anyways.
If it increases the stability and performance of games, I'm all for it.

Perhaps introduce functions to change the FPS, that would somehow re-initialize directx, for use in setting menus? (sorry, im not too fammiliar with dx, is this even possible?).
 
Last edited:

Juju

Member
Honestly, who dynamically changes the framerate? Could you roll setting a framerate into display_reset() and have it as a throw-once setting?
 

GMWolf

aka fel666
Honestly, who dynamically changes the framerate? Could you roll setting a framerate into display_reset() and have it as a throw-once setting?
I mean... Console games now use dynamic resolution just to keep framerates constant...
(BTW, I'm still baffled by howmany compromises need to be made on consoles, dedicated hardware really should perform better than that. Pretty sire Linux on a PS4 would run games faster)
 

rwkay

YoYo Games Staff
YYG Staff
PS4 os is basically Linux (at least it shares a lot of code) and you don't really know what you are talking about.....

Russell
 

GMWolf

aka fel666
PS4 os is basically Linux (at least it shares a lot of code) and you don't really know what you are talking about.....

Russell
Actually I believe its based on Free BSD.
Watched this conference by the group who got Linux to run on the ps4. They mentioned free BSD.
But from what I gather, they had to write some custom drivers to get the ps4 to run. wouldnt be suprised if those didnt run quite as well as the linux ones.
There is also a bunch of wierd things sony does (like adapting the Display port output of the gfx card to HDMI instead of just using the hdmi out, and replacing the south/north bridge with an arm cpu).

But yeah, I really dont know much about this stuff, certainly not as much as a YYG developer :)

you don't really know what you are talking about.....
Is this about the ps4 or the direct X? (im guessing ps4, either way you are correct).


So, what about the fixed FPS?
 

Samuel Venable

Time Killer
So it's official. 10 is probably in most cases the best value for the sleep margin on Windows. But what about Android? 10 for that as well or something different?
 

GMWolf

aka fel666
@rwkay - So essentially 'sleep margin' revolves around conserving battery life?

Would a tick box in Game Preferences for 'Conserve battery life' be more suitable (geared more towards mobile devices)?

For Desktop and Console environments, thrashing CPU is not really an issue. In these environments the Sleep() call could be removed altogether. I can't remember the last time someone complained about Crysis having high CPU usage.
Actually, with people streaming or recording game footage being more and more ubiquitous, I would say lowering CPU usage is increasingly important.
 

GMWolf

aka fel666
If you still run a single core system, sure. :p
Games already run or 2 to 4 threads.
GM has at least 2 Threads. Perhaps 3 with input poling and a 4th for networking?

But yeah. Right now you need a pretty beafy CPU to do this. So let's not make that problem worst.
 

GMWolf

aka fel666
Still leaves 4 to 5 cores on ten year old CPU's :p
You have a ten year old 6-8 core CPU? Nice.

But it would be nice to allow people with low end laptops, perhaps two core CPUs, to record their gameplay. Especially if the game looks like its easy to run. (Think super meat boy, for example).
Would be stupid if they couldn't because CPU was hogged by the game, for no apparent reason.
 

TheMagician

Member
I'd also vote for removing the ability to change the FPS at runtime if it gets rid of this problem.
Developing the game on one machine without problems and then have the game stutter on others is much worse.

On top of that the solution involves more battery draining which is never a good thing.

Finally I think the standard setting should be 10 if it causes so many problems at 1.
 

GMWolf

aka fel666
I'd also vote for removing the ability to change the FPS at runtime if it gets rid of this problem.
Developing the game on one machine without problems and then have the game stutter on others is much worse.

On top of that the solution involves more battery draining which is never a good thing.

Finally I think the standard setting should be 10 if it causes so many problems at 1.
Yeah, changing FPS at runtime isnt something that's used much in the first time.
I'm a for getting rid of it if it increases stability.

So long as we can set it per-export (desktop, mobile...), and that we have a way of resetting it trouh display_reset or whatever (for settings, etc).
 
Top