internally, wipe is rendered within a single "frame" so no input is processed. but we can't know from the movie which frame is wipe, so we can't insert empty frames to make imported movies work with our wipe - which has to happen across frames so we could capture every interim state of it. when exporting movies, wipe frames can be dropped based on lag info which we're currently setting for wipe only.
the way the initial lists are populated is kinda hacky because we need some separators and split the results using them. it's impossible to make sure they won't use that separator in a name in the future. maybe there's a better way than listing every available name in entire mame and finding which symbols never appear there and using them as separators (tho I admit for views I didn't even do that and relied on users running the thing).
This allows finetuning the on: conditions for each workflow and gives a better base for future work where we might want more workflows or more separation between waterbox cores.
Quicknes being in the waterbox workflow made no sense to begin with.
I've also used the cache action to cache the waterbox build which should prevent unnecessary rebuilds and improve speed slightly. I'm not really happy with the way reusable workflows work as they require re-cloning the repository and re-fetching clang, but the alternative would be copy-pasting the waterbox build action everywhere as far as I can tell.
only doom1 uses episode number in -warp, all the rest ignore it and use the first digit to set map (episode is forced to 1 for them). to detect this we now ask the core which gamemode it is (which determines it internally too).
rename complevel setting
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
Morilli