Mednafen has extra aliases of enum values that we don't need here and were confusing the system. Now, NGP no longer has three different "English" options for language.
Internal Mednafen code expects MDFN_GetSettingB ("bool") to work with enum values, so long as those enums are 0 and 1, but we weren't handling that.
Fixes#2385
* Cleanup NormalizeAxes
no behaviour change yet
* Use a more sensible scaling algorithm in NormalizeAxes
* Replace AxisSpec.FloatRange with AxisSpec.Range (ints)
* Use 0..255 for GBA light sensor, and set its Mid to 0 (fixes#2323)
* Revert "mgba - try resetting sram memdomain after frame advance, so sram autodetection can progress and feed into frontend. addresses #1620, maybe not in the best way"
This reverts commit 25327b510d. We decided exposing the whole buffer would be better than dealing with a variable size memory domain.
* mGBA: Update SaveRAM mem domain to a hardcoded size.
* TAStudio import: ask before saving the bk2
* Only save cycle count at movie end; fixes#2203
* Rework the movie end cycle count warning.
* TAStudio import: allow saving even if no changes are detected
These all seem to have been made from the point of view of testing every possible value the UI allowed, and then fixing them all with as little effort as possible, with the fixes going deep in core logic instead of in the validation layer, and the fixes not making anything really "work"; just making it stop complaining.
ZWinderBuffers now require TargetFrameLength >= 1 again: A value of zero doesn't make much sense here, and didn't actually behave differently than 1.
ZWinderBuffers now require Size > 0 again: A size 0 buffer will never capture anything and has no value. If you don't want a buffer, don't make one at all. I believe that omitting some buffers might make sense for the state manager, maybe; those more familiar with all of its uses will have to chime in. If that is the case, then the state manager should not instantiate buffers it does not plan to use.
ZWinderBuffers now throw exceptions again when a single state is bigger than the entire buffer: If you're in this situation, things are phenomenally broken and your buffer is never going to capture anything successfully. Users need to fix their settings in this case; they don't need to have a completely non functional system silently claim to work while not doing anything, leaving them befuddled as to why seeking is taking forever.
YoshiRulz