Closed KungFuJesus closed 1 year ago
I can reproduce this here. I'll dig in.
Ok, interestingly, this appears to be broken on real SDL 1.2 also, and not just on sdl12-compat.
Basically what's happening is they are hitting this code in i_system.c ...
if (lastmouse_warp
&& (inputEvent.motion.x == vid_center_x)
&& (inputEvent.motion.y == vid_center_y) )
{
lastmouse_warp = 0;
break; // skip PostEvent
}
And the motion values are not landing at vid_center_x and _y each time.
Here's one from the game's debug logging right after a warp:
Mouse 411,300, old 610,270, rel -199,30
See the giant relative value? It didn't land exactly at center, so the game thinks this was not the warp event, and treats it as if you moved the mouse almost to center...which is why your input looks like it keeps jerking back.
This can't really be fixed in either sdl12-compat or Doom Legacy, except to stop trying to use mouse warping to achieve this affect. Use the relative mode of Doom Legacy, which is the more-correct code path in general (and, in their SDL2 port, they should consider calling SDL_SetRelativeMouseMode(), which enables this same support directly that sdl12-compat is faking when it see mouse hiding plus mouse grabbing).
There's nothing to be done in sdl12-compat, so I'm closing this bug.
Given that this is a source port, some more investigation can probably be done to figure out why this is happening but, it seems that SDL12-compat does not behave like SDL 1.2 did in this circumstance. We seem to get weird snaps in position that make no sense. It's evident in the gameplay but also the map view. Here's video of it:
https://youtu.be/Q8JBaaYICJA