Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Prevent mouse from influencing player cam in Combat Sim pause menu #530

Open
wants to merge 1 commit into
base: port
Choose a base branch
from

Conversation

ZenithMDC
Copy link

Moving the mouse in the Combat Simulator pause menu caused the player camera to snap to a new location after leaving it. This was due to the relative mouse delta not being reset when leaving the menu. But I wondered: why did this not occur during a non-Combat Sim pause? I created a couple of input frame log files to figure that out:

Combat Sim pause input log
// MPPAUSE

Hit mpPause
g_PlayersWithControl: false
inputAutoLockMouse(false);
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, -1)
(0, -1)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(-71, 11)
(-31, 16)
(-35, 20)
(-45, 26)
(-54, 29)
(-58, 32)
(-50, 31)
(-49, 36)
(-50, 41)
(-47, 38)
(-44, 37)
(-37, 56)
(-22, 69)
(-16, 89)
(-13, 84)
(-11, 85)
(-14, 83)
(-25, 88)
(-24, 78)
(-16, 98)
(-4, 112)
(0, 83)
(-2, 62)
(-3, 39)
(-4, 20)
(-3, 12)
(0, 10)
(-1, 14)
(-4, 21)
(-7, 31)
(-3, 17)
(0, 1)
(0, -4)
(3, -10)
(1, -2)
inputAutoLockMouse(true);
g_PlayersWithControl: true
(-668, 1438) <- There's the huge delta responsible for the camera snap

// MPPAUSE
Normal pause input log
// NORMALPAUSE

Hit playerPause
(0, 0)
g_PlayersWithControl: false
inputAutoLockMouse(false);
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(2, -2)
(4, -6)
(5, -7)
(5, -9)
(10, -15)
(19, -21)
(32, -30)
(44, -39)
(48, -42)
(53, -51)
(52, -51)
(39, -41)
(36, -34)
(38, -39)
(33, -41)
(34, -60)
(31, -58)
(34, -70)
(36, -67)
(35, -79)
(24, -74)
(26, -78)
(27, -67)
(25, -54)
(20, -46)
(11, -38)
(5, -25)
(3, -17)
(0, -9)
(0, -2)
(0, 0)
(0, 0)
(0, 0)
(0, 1)
(0, 1)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
inputAutoLockMouse(true);
(731, -1170) <- Another huge delta, but since g_PlayersWithControl is false, it is ignored
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
(0, 0)
Hit playerUnpause
g_PlayersWithControl: true
(0, 0)

// NORMALPAUSE

So, because a normal pause has 25 input frames of latency between the huge delta (aka the next call to SDL_GetRelativeMouseState()) and player control becoming true again, the camera snap is avoided without intervention.

Anyway, I hope my solution is okay. If not, let me know.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant