omicronrex/gms_scheduler_fix

Also known as DBGHELP.DLL; Scheduler resolution fix for GM:Studio and GM8.1 (not to be confused with Debugger Helper)

Thread scheduler resolution fix for GM:Studio and GM8.1

This hack works by providing a fake dll stub that sets the thread scheduler resolution to 1ms, providing a smooth framerate across studio and 8.1 games. The games are not patched, so it's possible to use with steam and it should also be fine for speedrunning communities. If you like my work, consider buying me a coffee!~

Affected versions

• Game Maker 8.1: all versions.
• GameMaker:Studio: all versions.
• GameMaker:Studio 2: all versions before and not including 2.3.2, which provides an api for modifying the scheduler resolution and a more sensible default.

For developers

If you're making a game using 8.1 or Studio 1.4, rather than patching an existing game, consider using gmsched instead, as it's a much cleaner solution.

How to use

We've created a tool that automatically fixes issues in affected Game Maker versions: Debugger Helper

Alternatively, you can manually install by downloading DBGHELP.DLL and placing it next to the Game Maker 8.1 game or the Studio runner. Remember that some studio games are packed, so use a tool like 7z to unpack them (you should be able to see the game .exe, data.win and some miscellaneous data files). If a studio game is still packed it won't work. Or let Debugger Helper do it for you.

What is scheduler resolution?

By default, in modern Windows, the thread scheduler resolution is about 15.4ms. This means that if a program tries to skip time to save power, it'll only get invoked again in the next possible interval of 15.4 milliseconds. A coarse resolution means threads sleep very imprecisely, leading to massive frame drops and stuttering in game maker games as they fail to present frames on time. By setting a finer resolution like 1ms, we make sure the game thread is woken up on time to present every frame.

What's the catch?

The dll we're using as a hook isn't important for the games to run, so not much really. There are concerns about more power usage by the scheduler running more often, but since we're talking about games, it wouldn't really make much of a difference in the first place since this is expected for games.

Moreover, this tool does not help with 8.0 games or issues related to the infamous gm8.x "joystick bug", or out of memory crashes. If you still have problems with 8.0 and 8.1, consider patching them with gm8x_fix, as that resolves the scheduler and other issues mentioned. Additionally, Debugger Helper is capable of applying all the patches.

gms_scheduler_fix's Issues

8.0 doesn't work

8.0 doesnt work because it doesn't import dbghelp, research alternative hooks for it

Steam-enabled GMS games triggering 'Entry Point Not Found'

A recent update to my machine has led most of the GMS apps I helped develop over the last decade run into the very issue this project and it's dev-friendly gmsched tries to resolve.

While I plan on updating the games I'm involved with to use gmsched which I understand is the cleaner way to implement this, I thought I'd let you know that sticking this project's DBGHELP.DLL and running Steam-enabled EXEs (in this test case, Zenodyne R, but also tried with other projects) straight from Windows Explorer causes this window to popup:

 ---------------------------
 Zenodyne_Remake.exe - Entry Point Not Found
 ---------------------------
 The procedure entry point SymSetOptions could not be located in the dynamic link library C:\Program Files (x86)\Steam\CSERHelper.dll. 
 ---------------------------
 OK   
 ---------------------------

I looked up SymSetOptions and it looks like it's an actual function of the real DBGHELP.DLL, so I suppose a stub override like you've done with SymInitialize may well solve this and make this stub DLL good to use with Steam-enabled GM games.

Interestingly, the error does not crash the game: it appears to follow as normal, and at least going by ingame test code, Steam still responds as being loaded and ready to go. Furthermore, running the games through the given Steam shortcuts or through it's UI launch areas (ie. taskbar > Game) does not trigger the sign. It's a mild inconvenience though.

As for addressing the intended fault of GMS scheduling causing framerate issues, I notice that at least on my machine, I still get an occasional FPS drop, but only by a frame as reported in the FPS display within the first minute of running time and it's barely noticeable compared to the 2-20 FPS dips I was getting before from day to day. I also notice that fps_real still reports low numbers even with the DLL present until I set the IDE sleep margin to 15ms, which I assume is because GMS is still calculating those values based on the buggy scheduling function in the first place.

my computer shuts down every time i want to run my game

when i try to run a game with the DBGHELP.DLL set the computer shuts down, i have no idea why (i use GMS 1.4)