UI events are only sent to things when ticks happen

Is there something that doesn't work right in the latest GZDoom? Post about it here.

Moderator: GZDoom Developers

Forum rules
Please construct and post a simple demo whenever possible for all bug reports. Please provide links to everything.

If you can include a wad demonstrating the problem, please do so. Bug reports that include fully-constructed demos have a much better chance of being investigated in a timely manner than those that don't.

Please make a new topic for every bug. Don't combine multiple bugs into a single topic. Thanks!
User avatar
Gutawer
Posts: 469
Joined: Sat Apr 16, 2016 6:01 am
Preferred Pronouns: She/Her

UI events are only sent to things when ticks happen

Post by Gutawer »

I don't know exactly where this would be characterised between "bug" and "feature request", but essentially I think it's pretty unexpected behaviour that due to the way D_DoomLoop is written, menus and event handlers don't actually get events such as mouse movement as they happen, but they instead queue up until the ticker is run. Especially now that menus can be run at uncapped framerates with the game still paused, this creates an essentially arbitrary restriction that means that menus can't run as smoothly as they should be able to - 35 FPS is pretty noticeable jerky in some contexts.

It'd be better if things like menus got UI events instantly, so that they can be made as smooth as wanted.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
Posts: 49141
Joined: Sat Jul 19, 2003 10:19 am
Location: Germany

Re: UI events are only sent to things when ticks happen

Post by Graf Zahl »

The bigger question here is, why do you even need the events? The entire menu is an event driven system where you already receive the input data through the proper functions as they happen.
User avatar
Gutawer
Posts: 469
Joined: Sat Apr 16, 2016 6:01 am
Preferred Pronouns: She/Her

Re: UI events are only sent to things when ticks happen

Post by Gutawer »

My point is that the events aren't being sent with the right timings. If the engine is running at 140 FPS, and the mouse is polling at 140Hz (assumed for simplicity though obviously this is likely to be higher), this is roughly what ZScript will currently see:

Code: Select all

FRAME #1 Rendered
FRAME #2 Rendered
FRAME #3 Rendered
     Mouse Event #1 Received by ZScript
     Mouse Event #2 Received by ZScript
     Mouse Event #3 Received by ZScript
     Mouse Event #4 Received by ZScript
PLAYSIM TICK Handled
FRAME #4 Rendered 
Therefore, even though ZScript sees 4 mouse events, it can't actually handle them in a proper way that leads to 140FPS menu rendering - this is especially noticeably on a 144Hz monitor but it's still a problem on 60Hz - in ZForms it ends up meaning that if the user grabs a scrollbar, it won't update as fast as the mouse is moving.
What I'd expect to see is an event order more like this:

Code: Select all

     Mouse Event #1 Received by ZScript
FRAME #1 Rendered
     Mouse Event #2 Received by ZScript
FRAME #2 Rendered
     Mouse Event #3 Received by ZScript
FRAME #3 Rendered
     Mouse Event #4 Received by ZScript
PLAYSIM TICK Handled
FRAME #4 Rendered
I think this can just be achieved by adding this to d_main.cpp:

Code: Select all

--- a/src/d_main.cpp
+++ b/src/d_main.cpp
@@ -1215,6 +1215,7 @@ void D_DoomLoop ()
                        }
                        // Update display, next frame, with current state.
                        I_StartTic ();
+                       D_ProcessEvents();
                        D_Display ();
                        S_UpdateMusic();
                        if (wantToRestart)
I've had this in my own local compiled version of GZDoom for a few months now and I don't think it causes any issues.

Return to “Bugs [GZDoom]”