Loading a state reinitializes the system. A frontend that loads one
every frame from power-on, as run-ahead does, keeps the game from ever
booting and shows a black screen.
Report RETRO_SERIALIZATION_QUIRK_INCOMPLETE so frontends don't rely on
states for run-ahead or netplay.
- When triggering a cache preload by writing to $7f48, update the pb register with the prepared program page
- When preloading a page, ignore all runtime checks and reload the page immediately
Although it had HIRO_GTK==3 sections, hiro/gtk/monitor.cpp was actually using
deprecated GTK+2 APIs on GTK3, and the GTK3 code was broken and wouldn't
compile.
I didn't realize that some of the Qt deprecations were already fixed in
ares. In this case, the change was handled a bit differently, always
considering the y component of scrolling even when the scroll operation
is mostly horizontal. This should work just fine, so we may as well just
adopt that behavior, especially since bsnes doesn't even currently use a
HexEdit.
Backported from ares from:
https://github.com/ares-emulator/ares/commit/ffe97222a1aabd325c301e07ba40042ea58ff081
Co-authored-by: Stefan Schlosser <[email protected]>
Qt 6 no longer allows us to poll for the status of the event loop.
However, Qt 6 does still have a processEvents function, and the version
with the timeout actually spins the event loop and returns as early as
there are no more events in it. That's basically what we want to do. We
could run this with a really huge timeout, but that would just make it
more likely that hiro freezes up, so instead let's mirror hiro/gtk3 and
use a 50ms timeout.
This does not seem to be used anywhere in bsnes, higan or ares. It's not
really possible to implement with Qt 6, which has stop exposing this
detail of the event loop. It turns out this is actually OK, since we
don't *really* need it anyway, and in the case of hiro/qt, the
replacement should be more robust anyways.
Qt 5 introduces QScreen, which can be used to implement most of the
functionality needed by Monitor, although some of it probably won't make
sense when using Wayland.
The orientation() and delta() methods of QWheelEvent were deprecated in
Qt 5.0 in favor of angleDelta(), which expresses higher-fidelity data
for devices like trackpads. In order to keep the behavior 100%
identical, the code used to calculate the orientation() and delta()
values in Qt 5.15 is inlined instead. That logic can be seen here:
https://github.com/qt/qtbase/blob/v5.15.17-lts-lgpl/src/gui/kernel/qevent.cpp#L876-L884
Following this logic, we also break the tie for orientation in favor of
vertical scrolling.
Since there is no actual HexEdit usage in bsnes, I tested it by putting
a dummy HexEdit widget inside the bsnes Presentation window. Scrolling
seemed to work as expected.
Craig