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.
it has to rewind to remove a frame, which makes it pause on first removed frame when we hit restore, instead of going all the way to LastPositionFrame. I tried a ton of things to fix it, and they break one of the 3 scenarios of going from the edited frame, emulating through removed was-lag frames until LastPositionFrame, and pausing there:
- autorestore
- restore manually via middle-click or the || button
- step frame by frame using wheel+RMB
wheel+RMB steps used to unpause in wrong places because paused state was disabled when it fires, so we couldn't decide whether to unpause or not based on it at the end of AutoAdjustInput(). so I'm enabling """paused""" state inside TasView_MouseWheel(), much like < and > buttons do, except they can be held to force unpause, but here you can't let go of mouse wheel since it already only fires once anyway. I'm disabling this state once tastudio has reached its INTERIM seek frame, and based on it I now can decide to unpause after AutoAdjustInput().
AutoAdjustInput() still has a tiny problem of not advancing the first removed was-lag frame when you go step by step, because it can only go one direction at a time, and it goes up as explained above, but we need it to also go down. this can be forced if we allow tastudio to seek to the CURRENT frame by loading its state and reemulating it, but I don't know if this will cause issues, and nobody is stepping through autoadjusted frames anyway, since it's meant to happen quickly and on autorestore
TODO: removing consecutive was-lag frames seems to remove them ALL!!!
inb4 all this causes other wild bugs...
remove all consecutive was-lag frames in batch like taseditor does. current frame has no lag so they will all have to go anyway
still need to fix wrong pausing
YoshiRulz