Skip to content

Conversation

Razish
Copy link
Member

@Razish Razish commented Mar 3, 2024

Currently the transition/fade keywords in menus will behave differently according to your FPS.
This PR makes it consistent with the original behaviour as if you had 60 FPS - which is likely what they were designed for.

You can see these in effect in SP from the main menu:

  • New (transition)
  • Controls (fade in)

Demonstration of before/after this fix from JA++ with a custom menu:
https://github.com/JACoders/OpenJK/assets/844370/e84b79f1-5da6-4f6a-99fc-f67782263605

Demonstration of fixed behaviour in existing SP menu:
https://github.com/JACoders/OpenJK/assets/844370/16814f7c-94f3-4df3-9631-275bccd461ba

@@ -7812,17 +7813,17 @@ static qboolean Item_Paint(itemDef_t *item, qboolean bDraw)
if (DC->realTime > item->window.nextTime)
{
float rx, ry, a, c, s, w, h;
item->window.nextTime = DC->realTime + item->window.offsetTime;
item->window.nextTime = DC->realTime + (item->window.offsetTime * tAdjust);
Copy link
Member Author

@Razish Razish Mar 3, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if also adjusting the debouncer is correct since we're adjusting the translation based on the current frametime / 60fps frametime.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you can be sure that most users have exactly 60 fps (vsync with most common displays) or more in the menus, thus this should only decrease the amount of tiggered updates. One could argue that this is bad for higher freqency displays, as the interpolation won't work in this case for the frames in between. Probably better to get rid of it, but I wouldn't mind if menu anmiations are capped at the defined fps.

Copy link

@bartrpe bartrpe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not the one to give a solid opinion on the good coding practice and whether solution is proper for the environment etc. buuut

I've tested the entire UI, checked the references and whether the adjustment is provided in every required variable & function and I can say it is. Checked the references to the timer, ran through call stack and reference tree, everything looks fine, every place that would need the adjustment, has it.

Copy link
Member

@ensiform ensiform left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know for sure either but does MP have the correct frametime?

@SomaZ SomaZ force-pushed the ui-framerate-dependence branch from f22d223 to 5c92179 Compare May 18, 2025 10:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants