ZDoom / gzdoom

GZDoom is a feature centric port for all Doom engine games, based on ZDoom, adding an OpenGL renderer and powerful scripting capabilities
http://zdoom.org
GNU General Public License v3.0
2.47k stars 540 forks source link

Remove 35 FPS cap from menus #2729

Closed Cacodemon345 closed 1 week ago

Cacodemon345 commented 1 week ago

This PR removes the 35 FPS cap from menus.

The changes made are:

  1. Menus are no longer capped to 35 frames per second.
  2. If there's no map being rendered at the moment, VSync is forced on and the menus are capped to the monitor's refresh rate should the VSync settings be respected.
  3. If maps are being rendered, normal vid_vsync behaviour is followed and menus are capped to vid_maxfps.
  4. The Vulkan renderer now always follows vid_maxfps settings as AMD drivers completely ignore swapchain present modes for windowed surfaces existing on FreeSync displays, instead forcing it to VK_PRESENT_MODE_IMMEDIATE_KHR, causing the actual FPS to go past vid_maxfps.
coelckers commented 1 week ago

Whatever you try to achieve here should not be enabled unconditionally if it isn't needed. If you need uncapped frame rate for some effects this should only be active if actually required.

mjr4077au commented 1 week ago

Adding animated into the MENUDEF should be enough to uncap the framerate of the menu. This was added for Blood's interpolated blood dripping. See these commits:

coelckers commented 1 week ago

I have a suspicion this is about a use case that the animated flag cannot handle - but then the solution should be to dynamically handle the flag instead of just whacking the fully intentional frame rate cap.

Cacodemon345 commented 1 week ago

The primary use case of this feature was to implement animations beyond what is possible with the Animated flag.

One example is animating selected items (i.e. fade in/out). Slapping the flag on every menu just for that is too much, and mods can't override every menu (especially Gameplay Options) for that. It also kills the purpose of the frame rate cap in the first place.

coelckers commented 1 week ago

In that case you should do this dynamically, i.e. only uncap the frame rate in cases where you need it, i.e. if you have items on the menu that require uncapping, have them set the menu to animated automatically.

madame-rachelle commented 1 week ago

How about a gameinfo flag inside of the mapinfo lump?

prof-hastig commented 1 week ago

What kind of content is designed so weirdly that it is impossible to decide whether the menu needs to run uncapped or not? I think before adding any hacks these need to be explained in a way that the best approach can be discussed. I am fairly sure there's better approaches than just globally disabling the cap.

Cacodemon345 commented 1 week ago

In that case you should do this dynamically, i.e. only uncap the frame rate in cases where you need it, i.e. if you have items on the menu that require uncapping, have them set the menu to animated automatically.

Doing it dynamically makes no sense if the intention is to continuously animate selected items back-and-forth on all menus, which some commercial games may be interested in. Besides this doesn't solve the problem of scrolling skies looking frameskippy if the menus are opened while a map is being displayed.