YoYoGames / GameMaker-Bugs

Public tracking for GameMaker bugs
21 stars 8 forks source link

Having gsync enabled on monitor tanks fps randomly in IDE #5470

Open gm-bug-reporter[bot] opened 4 months ago

gm-bug-reporter[bot] commented 4 months ago

Description

I have gsync set to [ON] on my both primary and secondary displays. It is also set to Fullscreen Apps Only. The FPS will randomly tank for a couple seconds and then return to normal. Turning off gsync on my primary monitor resolves the issue. Hovering over the file menu buttons in the top left will recreate the issue every time. Also the Nvidia Beta App (replacement software for Geforce Experience), detected the beta IDE as a game and enabled my RTX HDR filter that I sometimes use on games and washed out the colors of the IDE. Not sure if that's related though.

Steps To Reproduce

  1. Turn on gsync on display.
  2. Launch project.
  3. Observer FPS drops randomly or when hovering over menu buttons.

Which version of GameMaker are you reporting this issue for?

IDE v2024.400.0.532 Runtime v2024.400.0.551

Which operating system(s) are you seeing the problem on?

Windows 10.0.22000.0

7d2ec979-4f81-4d74-a0f3-7f1b4b2a59c2

zreedy commented 4 months ago

To add context to this issue, there is a missing call to timeBeginPeriod where there is a call to timeEndPeriod which was discovered recently. The failure to call timeBeginPeriod could cause this kind of issue, but we did not have confirmation that this was an issue in the IDE before.

zreedy commented 3 months ago

Some more context to this ticket upon investigation. This issue might also be platform dependent and will need verification on Mac OS X and Linux with GSync, FreeSync, and 144Hz monitors. For Windows, the function timeBeginPeriod behaves differently starting with Win10 2004, the change in behavior might actually have a negative impact on Sleep performance jumping from an average of 2ms to 15.4ms when invoked for Sleep(1). We already buffer our "High Performance Sleep" to busy loop when the interval is <= 2ms but on 144Hz monitors this might not be enough still. In Win10 1803 a new API for creating an interrupt-driven high performance awaitable timer was introduced CreateWaitableTimerExW which offers a higher resolution and better guarantee of waking on time. Considering the overlap of these APIs and their respective Windows revisions, a more complicated fix might be required which considers employing one or both APIs.

This also raises the question of Runner behavior, games targeting 144Hz, GSync, and FreeSync monitors should be verified to perform correctly on Windows.

References and Resources: