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.
UI events are only sent to things when ticks happen
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!
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!
-
- Posts: 469
- Joined: Sat Apr 16, 2016 6:01 am
- Preferred Pronouns: She/Her
-
- 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
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.
-
- 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
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:
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:
I think this can just be achieved by adding this to d_main.cpp:
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.
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
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
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)