see also #2090. This can reasonably catch and handle simple load failures like all waterbox loads and some others.
Not calling the issue fixed because there is more that can be done to prevent cores from trying to load invalid savestates.
various toolbars may exist near screen edges, we don't want them to be triggered when hawk has "captured" the mouse, especially in fullscreen. I considered taking into account when hawk window is partly offscreen but it's hard to expect anyone would play that way - normal scenario is fullscreen, so screen edges are automatically pushed away from. dialogs covering hawk are even less likely to remain during mouse capture, so we don't care about mouse appearing on them.
The core as it is is a very poor choice for Genesis. Much worse compatibility, very noticeably worse audio, and it's not like GPGX is hurting badly in the performance department. It's also very outdated compared to upstream (making these problems much worse than if it was updated). It was only in BizHawk to handle 32X games to begin with (as there aren't many options for 32X to begin with), with Genesis fallback support (without user selectability!) just tacked on "because we can."
Perhaps with a core update it could be more reasonable to allow users to select this, but for now, nope.
Closes#4251, #4250, #4235
demos still sync btw
horizontal mouse was calibrated for my machine, dunno about others. for me 1-pixel relative movement results in 272-pixel deltas, so I divide it inside the core for now
when the global sensitivity option is there, I'll drop sensitivity syncsettings and rely on client ones that I'll configure to match default dsda sensitivity.
upstream uses a hotkey toggle instead but vanilla didn't have it. even "always run" itself was just a vanilla bug. I don't want to have a special on-the-fly input for autorun toggle, hopefully user either wants to always run + occasional mouse movement, or only run using the proper button
this allows to properly set available range which makes demos sync again (aside from weapon switching that I broke)
when importing demos we now force shorttics (even tho some source ports can record demos with longtics depending on compatibility level but importing those is for the later time)
There's 3 approaches here, of which only 1 appears to work more or less correctly
1. Use XFixes "pointer barriers." Introduced in XFixes version 5.0 (end of 2010), these effectively allow 1:1 mapping with Windows ClipCursor, giving behavior BizHawk wants.
2. Use XGrabPointer, with the confine_to argument set to the presentation panel. This mostly works, however, it changes how some events operate and for whatever reason prevents Mono from responding to mouse buttons. This approach can be used with 1. too for a simple warp of the mouse cursor over to wherever the window is.
3. Use Mono's internal CaptureWithConfine function. This is just internally using XGrabPointer with the confine_to argument. Somehow it makes mouse buttons work, but it ends up working too well as it can respond to the menu bar somehow, and interacting with such or the right click menu cancels the grab (seems to be internal Mono code doing such in this case here?).
Note a lot of weirdness with previous code came down to testing being in a VM and mouse integration being enabled. That apparently just prevents any kind of mouse warping from happening so nothing appeared to work correctly. Disabling such allows these approaches to work as above, also makes relative mouse values sane (previous values with mouse integration were completely bonkers).
TODO: Need to check if this works on XWayland (maybe it does?). Also need to refresh mouse capture on window resize and move (needed in general for both Windows and Linux)
Morilli