initially I read the code wrong. `demo_compatibility` means vanilla complevel, not "demo is running". for vanilla hitting 1 would switch to first only if you have berserk, otherwise it'd stick to chainsaw (provided you have it of course). that part was working ok. but for boom compat hitting 1 swaps fist and chainsaw at all times, and that part was broken: chainsaw would not get selected even if you have it.
pass button values directly (same can be done for arti)
it'd arguably make sense to shrink, if we could downscale it with some smooth algo. this is based on the fact that on a CRT monitor you also see scanlines at fixed thickness (unless you adjust the output) and only width is variable (and depends on pixel density + size of overscan). so upscaling 240p by exactly 2 and then adjusting with made sense on the paper (and it's what we do for CRT encodes). but hawk can't default to a smooth algo, and it can't only apply it on shrink while everything is resized using point. so it's better to just never shrink and let height also be variable. that's kinda what everyone else is doing anyway.
The previous code did nothing when a new rom was loaded or the emulator was closed. Now the user at least gets the chance to try again, however much that will help.
more try = more catch. Disk errors while writing saveram are rare and probably user error, but they're unrecoverable and shouldn't crash the emulator outright.
See #4258 and #1466
The code will now consider both autosaveram and normal saveram files on load. Normal saveram is preferred unless an autosave exists that is more recent than the normal save, in which case the user is prompted to select which saveram to load.
partially reverts b62f4bc6a
see #2449
No longer hides the submenu, and toggling individual columns updates the
whole-player checkbox, which is now tri-state.
Same for the "Show Keys" item.
And after all that, Mono doesn't distinguish Indeterminate :P
they say the code should be so verbose that you won't need comments. indeed comments that restate the same thing that the code is doing are considered sloppy, because code will change and comments will become outdated. but if a comment is describing the logic of decision making or some unintuitive quirk, they're perfectly fine. so in a few places I go crazy with comments because the decision made there took a long time and a lot of changes, so it kinda summarizes the best result. that's it, no elaborate description of the change itself here... because I put it into that comment instead XD
SuuperW