You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have you checked that no other similar issue already exists?
I have searched and not found similar issues.
A clear and concise description of what the bug is.
When you load a save or change maps (after beating a map normally or using the changemap command), all of your mouse movement during the screen wipe is buffered and applied at once on the first frame after the wipe finishes.
When you start a new game (either through the new game menu or using the map command), your vertical mouse movement (but not the horizontal mouse movement) is similarly buffered during the screen wipe.
I usually move the mouse a bit or more while loading a game (often unintentionally if I'm picking up the mouse in a rush to get ready for the loading game, and/or semi-intentionally because I tried to time the start of my player inputs with the game starting and did it too early), so this almost always results in my whole game view being jarringly jerked to a disorienting new angle right after the smooth screen wipe animation. It feels like a much more extreme version of what happens during brief game lag (where it does generally make sense to buffer mouse movements), which personally makes the experience of the screen wipe feel like a special case of game lag rather than an intentional experience.
I debated posting about this since it seemed like a bit of a trivial issue, but I thought it was interesting that the correct behavior was in place already specifically for horizontal mouse movements during starting a new game, and how that suggested there was already a partial fix in place for this issue that could be easily extended.
I did try to fix this so I could send a PR myself, but I haven't yet been able to find what code is responsible for blocking the horizontal mouse movement from being buffered during the wipe. I figured the simplest way to implement this fix would be to find that code and fix it to handle the other cases. (I did figure out that I could work around this by making PerformWipe trigger Mouse->Ungrab() at the start and Mouse->Grab() at the end, but it makes the mouse visible which isn't desirable and it's surely inconsistent with whatever is already blocking the horizontal mouse movement buffering sometimes.)
Steps to reproduce the behaviour.
No response
Your configuration
No response
Provide a Log
No response
The text was updated successfully, but these errors were encountered:
Actually I think what I'm noticing after a load-game screen wipe isn't just buffering of mouse movement, but buffering of all input, plus a full time skip. If you load a game, and press the fire button during the screen wipe, you'll notice two things: 1) your gun fires as soon as the screen wipe ends, and 2) the first frame or more of the weapon firing is skipped instead of being rendered. You don't see the muzzle flash of your weapon firing, and the projectile has already traveled a bit. It's very noticeable with any weapon besides fist and chainsaw. It seems that at the end of the screen wipe, the game runs for a tick or two before rendering starts. It results in some very noticeable jank right after loading a save. (It's also very noticeable if you save the game while moving, and then when you load it, the game seems to stutter instead of showing your movement smoothly after the wipe.)
Macil
changed the title
[BUG] Mouse movement buffering during screen wipes
[BUG] Input buffering and frame skips after load-game screen wipe
Aug 18, 2024
GZDoom version
4.12.2, also current git master, f671018
Which game are you running with GZDoom?
Doom 2
What Operating System are you using?
Windows 11
Please describe your specific OS version
windows 11 home
Relevant hardware info
amp cpu, nvidia gpu
Have you checked that no other similar issue already exists?
A clear and concise description of what the bug is.
changemap
command), all of your mouse movement during the screen wipe is buffered and applied at once on the first frame after the wipe finishes.map
command), your vertical mouse movement (but not the horizontal mouse movement) is similarly buffered during the screen wipe.I usually move the mouse a bit or more while loading a game (often unintentionally if I'm picking up the mouse in a rush to get ready for the loading game, and/or semi-intentionally because I tried to time the start of my player inputs with the game starting and did it too early), so this almost always results in my whole game view being jarringly jerked to a disorienting new angle right after the smooth screen wipe animation. It feels like a much more extreme version of what happens during brief game lag (where it does generally make sense to buffer mouse movements), which personally makes the experience of the screen wipe feel like a special case of game lag rather than an intentional experience.
I debated posting about this since it seemed like a bit of a trivial issue, but I thought it was interesting that the correct behavior was in place already specifically for horizontal mouse movements during starting a new game, and how that suggested there was already a partial fix in place for this issue that could be easily extended.
I did try to fix this so I could send a PR myself, but I haven't yet been able to find what code is responsible for blocking the horizontal mouse movement from being buffered during the wipe. I figured the simplest way to implement this fix would be to find that code and fix it to handle the other cases. (I did figure out that I could work around this by making PerformWipe trigger
Mouse->Ungrab()
at the start andMouse->Grab()
at the end, but it makes the mouse visible which isn't desirable and it's surely inconsistent with whatever is already blocking the horizontal mouse movement buffering sometimes.)Steps to reproduce the behaviour.
No response
Your configuration
No response
Provide a Log
No response
The text was updated successfully, but these errors were encountered: