The cursor can also escape the window, which is beneficial in multi monitor setups, when you can interact with other displays during non-gameplay. Disabling makes sense, as the user can see their cursor to interact with the menus. With relative mode enabled only during gameplay, and (presumably) disabling it when menus are open. Prime example is IME candidate window, so that the user can click on it/interact with it while entering text.Īnyways, I think that we have two (kinda) conflicting use cases for relative mode: 3D games
In some cases, it may be beneficial that the mouse exits the window when another is covering it.
CURSOR OFF IN CLIP NOTE STUDIO WINDOWS
It's unfortunate that we have to have local workarounds for Windows bugs like these. But I do remember taskbar sometimes appearing over borderless fullscreen games and windows. If a user has manually moved their window over the taskbar, they're kinda asking for relative mode not to work properly. Though some apps use non-native notifications, so those may be a problem (especially on older Windows versions).Īnother always-on-top window that was mentioned was the taskbar. So these shouldn't be an issue, and user should be instructed to enable focus assist if they want uninterrupted gameplay. (Don't have video of this because it rarely happens.)įor 2., notifications are disabled by default in Windows while playing games, with focus assist. This is somewhat fixed by having the clip rect be the client area as the SDL and Windows cursors will mostly stay in sync (with desync occurring if SDL_HINT_MOUSE_RELATIVE_SPEED_SCALE is not 1.0).Įxplained in more detail here: #4339 (comment) video.mp4 Mouse sometimes warps to center of window when relative mouse is disabledĬaused by the WinAPI SetCursorPos() sometimes not working (especially when using high pool rate - 1000Hz mouse). Though when using SDL_HINT_MOUSE_RELATIVE_SPEED_SCALE, this is still somewhat broken, for our specific use case, the scale is set to 1.0. (Relative mode is disabled here when SDL_WINDOWEVENT_FOCUS_LOST arrives.)Ĭlipping to the client area means that the SDL cursor/mouse position will be the same as the one reported by Windows, so no warp/jump will occur.
Disabling relative mode is supposed to warp the cursor to the current SDL cursor location, but this doesn't appear to work when the window is unfocused. (green = relative mode enabled, red = disabled) video.mp4 Mouse warps to center when window is unfocused By setting the ClipCursor to the client area, windows will clip the cursor in the window area that is visible on screen (as expected). If the ClipCursor rect is set off screen, Windows will ignore it. More info as to why: Mouse grab doesn't work if window is partially off-screen
Applications which require the old clipping logic (for some reason) can use to set the old rect. Which will clip to the window client area by default. The proposed fix is to remove the absurdly small clip rect logic here and have relative mode use the clipping logic in the else block. Was this revert intentional or accidental?Ĭlipping the cursor to the whole client area fixes all of the mentioned issues. Cursor clipping logic was changed so the cursor is clipped to the whole window client area in #4266, but this was silently reverted in a1fabca. These issues are caused by clipping the cursor to the center of the window when relative mouse is enabled. mouse sometimes warps to center of window when relative mouse is disabled.mouse warps to center when window is unfocused.mouse grab doesn't work if window is partially off-screen (when the center of window is off screen).
0 kommentar(er)
