search

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)
29 stars 2 forks source link

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

Open BPzeBanshee opened 3 years ago

BPzeBanshee commented 3 years ago

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.

omicronrex commented 3 years ago

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.

Looking into it!

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.

This is pretty on par for the course in game maker, and common if sleep margin is set to 0 or vsync is on...

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.

That's because your computer is clocking down, so the frames are taking up more time. fps_real simply measures the free time inbetween frames - if the game was just about to hit the frame boundary, your cpu would up the clock, again increasing the fps_real again. This doesn't mean the game is running poorly, it just means yoyogames called this variable a very undescriptive name for what it actually does.