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
The previously resolved 8.0.0 is vulnerable according to https://github.com/advisories/GHSA-hh2w-p6rv-4g7w, so pin it to 9.0.0 for now to fix build warnings (and whatever vulnerability that is).
Once Silk.NET publishes a 2.22.1+ this can theoretically be removed.
move tasview context menu to the other side of the cursor if it's not fitting into the screen fully. of course if there's not enough space there EITHER, the user must do something about it, meanwhile best we can do is clamp location to 0. not using MouseEventArgs because we need absolute on-screen coords
other tastudio menus are small so probably fine?
- the only dialog that's meant to be used during emulation is undo history, so let it spawn at its old location in the middle of the screen. user will move it regardless of where we spawn it
- positioning of input prompts will happen later
- all config/metadata dialogs now block tastudio and spawn at the top just like open/save. user is clicking tastudio menu so it's distracting if those dialogs spawn too far away from where they're already looking. and the middle of tastudio can be indefinitely far away because it can easily occupy the entire screen (we have cores with tons of buttons, and some users like to make it as tall as the screen). so while in the middle is """consistent""", it's very annoying if you have to do a lot of consecutive edits (for example to greenzone caps, or colors). overall, top priority of smooth tas workflow, so """consistency""" with unrelated tools made for unrelated tasks is not helpful if it makes the workflow more annoying
- ensuring the dialogs spawn fully on-screen will happen later
removed unused tastudio menus and config params
- branch hover interval was added before I replicated taseditor logic, which makes branch screenshots only appear if you keep the pointer over branch number, and not if you're just moving it around. making it configurable doesn't look useful
- seek cutoff interval (how far target frame has to be to spawn seek progress bar) feels redundant because any onscreen edits won't spawn the thing anyway, and for farther seek points it's not annoying enough to change
- EmptyNewMarkerNotes is not relevant to tastudio because it never copied previous marker notes like taseditor does. currently it does nothing and nobody ever requested it even tho it's in the menu, so there's no evidence anyone ever needed it
- fun fact: I was sure autoadjust input to lag never worked but it mostly does! so it wasn't removed, instead I plan to fix it (it pauses on every added frame). it's also not saved.
- other dialogs use InputRoll so I had to remove those options from them too (tastudio is the only one that they were meant for anyway)
bump undo history to 1k. it may not be needed often but when it is, some actions are not combined (for example it adds every newly emulated frame) so you may end up unable to undo some dumb mistake than was only a few actions ago
use normal control BG color for tastudio color editor. I tried it with dark theme on linux and got no difference. if this causes issues we'll see how to fix it without randomly giving one dialog unique BG color. also removed todo since labels are good now
YoshiRulz