controls that don't belong to any indexed player are put at index 0, which makes them appear in front of everything that's used all the time. when there's only a few of those, it's fine. but for systems with keyboards, you have to fullscreen the emulator window to even see regular inputs
I moved index 0 to the end for input display, but didn't touch the original generator, since it may affect other things I'm not sure about (and I'm not smart enough to properly change it)
from be0736be4 (+ cherry-picked ccba93440) to this commit:
- `Database` reported runtime 0.64 s --> 0.68 s
- profiled `ParseCGIRecord` mean runtime 0.190 ms --> 0.179 ms
- `GameDBHelper` 1M lookups reported runtime 1.03 s --> 0.69 s
- managed allocations (w/o the 1M lookups) 131 MiB --> 123 MiB (fewer
strings but more char[]s?)
since `CompactGameInfo` obviously can't store `Span`s, I tried with
`StringSegment`, but it made both lookups *and init* slower, thanks MS
Includes: `Range`/`Index` and other polyfilled types are now `public` in
BizHawk.Common rather than `internal` in each assembly. Not for dedup
reasons--though that's probably good too--just because it was necessary
for exposing these new `public` methods with `Range` in their params.
fixes 8645ed3bb
so the speedup isn't as big as with the broken code, but it's close
I think I'll be changing this again to use Span and I'll reprofile then
while libretro initially ported original puae (which is long dead), they switched to just pulling updates from winuae every once in a while (and renamed to libretro-uae), because it's still active and is kinda considered golden standard these days
The fallback is intended in cases where there is a misdetection for MAME ROMs, since it just goes off the archive's filename against a db. MAME ROMs will not have any sensical ROM extensions in them, and will most likely just have multiple files in it. As such, if this is actually a MAME ROM, they're pretty much guaranteed to show the choose file in archive dialog, which would confuse users. If it's not a MAME ROM, it most likely will not show this dialog and will just be loaded by the appropriate core (of course in practice this likely doesn't occur anyways, since most users likely just have their ROMs named with dat names like No-Intro etc which never match MAME's names).
- closes#4133.
This has a 50% chance of breaking something else (it either happens or doesn't), but should be more correct. Mainly, RecalculateScrollbars was called based on visible rows which depend on whether scrollbars are visible or not, but the NeedsVScrollbar calculation did not take the existence of the HScrollbar into account, leading to an off-by-one. I think.
CasualPokePlayer