doesn't matter for ASCII-only strings, and `InvariantCultureIgnoreCase`
is arguably correct in some circumstances, but IMO it's more foolproof
to simply ban it
This reverts commit b2f3bb3cba.
Revert "fix removing everything"
This reverts commit a0da874431.
YEP. this "feature" is COMPLETELY, ABSOLUTELY, UNIVERSALLY fucked. sure #4184 can be "fixed" by flipping some bools, like setting MainForm.HoldFrameAdvance back to false in TasView_MouseWheel. but then there's still the problem of removing actual input if farther lag picture changed after initial removal, and I'm not going to debug that. taseditor's ONLY bug was related to erroneous detection of lag change that we were never able to consistently reproduce or figure out, and it's completely impossible to replicate identical behavior in tastudio due to crazy overhead. but even SIMULATING that behavior would involve touching that minefield of bools that control everything in insane ways. given zero requests for this feature during tastudio's decade of existence, I'm considering it too useless for all the chaos it introduces.
so instead I'm closing #4184 by disabling the "feature" that caused it
* BizHawk#4187 Add a method to the comm LUA library to allow setting ExpectContinue
* Instead of exposing ExpectContinue set it automatically based on a threshold
* [C64] Fix loading Domark cartridges that don't have a bank count that is a power of 2, and add a memory domain for the ROM image
* [C64] Fix bracket styling
- Implement the AM29F040B flash device as its own component
- Fix save data for games that use the standard EasyAPI driver
- Fix "Briley Witch Chronicles 2": the flash driver checks AutoSelect register 02 to see if the cartridge is write-protected
- Rom is stored as bytes instead of ints, saves a lot of memory
- EasyFlash now has proper hard reset and clock operations
- SaveRam deltas fixed
- closes#4157
Not sure this is the best way to fix the linked issue, but considering this is a hard crash I'd rather fix it somehow than not at all for now.
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
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
* Improve Lua REPL handling of statements
Stop printing syntax error messages when executing variable assignments etc.
* Move doc comments to interface
* Simplify pattern matching expression
* Use reference equality to test for console output
* Revert "Use reference equality to test for console output"
This reverts commit 875bc3c41e.
* Use `_messageCount` to test for console output
This reverts commit d23e771a39.
Had no effect on where in the startup a `TargetInvocationException` was thrown, so I'm guessing the attribute has no purpose anymore.
there are games that require this machine and 0 fastmem. games that require non-zero fastmem on this machine are currently not supported (HDs, CDs, and WHDs).
In practice this won't be used (since we can just hash the installed title executable directly), but might as well keep a reference C# impl in case we want to use it.
In a simple benchmark of calling `Database.CheckDatabase` 5x 10M times
(small edit on top of `BIZHAWKBUILD_RUN_ONLY_GAMEDB_INIT`),
median runtime was 46.1s w/ `Dictionary`, 44.0s w/ `FrozenDictionary`
(isolated to only swapping out the collection type used at the end of
`InitializeWork`, *not* a before/after comparison on this changeset,
also this was in Release config).
FWIW, the parse/load time increased from 0.38s to 0.74s
(again median of 5 runs in Release config, and this was a before/after
of this whole changeset).
This will now add reset and power buttons if fourscore is used (pretty sure not doing that was a bug as per comment) and ignore port0 and port1 values if fourscore is set as per movie format documentation.
On my machine (Mono) in Release config, this reduces the number of
string- and char-arrays allocated by an order of magnitude,
bringing the gamedb's total bytes allocated down by -10%.
AllStates() sorted the returned states, but this order was not used anywhere else, so I've removed it. GetStateClosestToFrame is solvable in O(n), so sorting is not required there either.
This is an O(n log(n)) -> O(n) improvement that is mostly relevant for the state history integrity checker
srl -> "official" DS rom extension (generally found in prototypes etc)
dsi -> used for DSi only games
ids -> used for iQue DS games
upstream handles all these rom extensions already
This fixes 3D Construction Kit and potentially other dsk games with more than 42 tracks on disc.
The +3 disc drive may only be able to read 41-ish tracks of standard sized data, but it appears many images have more tracks than this. 3D construction kit for example has 45 tracks in what passes for the TOC, but the last 5 of these are empty.
Make sure to scan entire directory record (some games seem to end up ending the search early with the old code)
Find "BOOT = cdrom:" with any variable amount of whitespace
This behavior "needed" for rcheevo hashing to work, since a few games (e.g. `Chinmoku no Kantai - The Silent Service (Japan)`, maybe others) have mode 2 form 2 sectors for the exe (for some reason)
Obviously we don't support IPF images right now, but with any luck we will eventually. So it makes sense to have something in place in the frontend to do core selection (when a gamedb hash is not found) based on the INFO block within the IPF file itself.
* Fixed RA hash for PlayStation games when BOOT line contains tabs where spaces are expected.
* Fixed RA hash and prevented infinite loop when PlayStation executable is in subdirectory.
there's some discrepancy between the 2 orders, because the GUI list relies on full names (of the groups) while in the code short names are used to add them to DB
build with `-p:MachineExtraCompilationFlag=BIZHAWKBUILD_DEBUG_RUMBLE`
there's nothing special about SDL2 I just can't be bothered finding the
other impls
This is most likely more correct. .net framework does not have a dedicated method for checking absolute paths, so this was most likely accidentally used instead.
-closes #4068
There's still two callsites that don't check the return value, but I'm not sure whether they can fail and what they should do if they do.
The Z80 should only be sampling the /WAIT pin during the 3rd cycle T of an IO REQ M Cycle.
Instruction timing tests verified on CPCHawk using WinAPE plustest.dsk.
Note: CPCHawk is the only core to currently use the Z80A /WAIT pin (FlagW), so other core exposure is 0.
* [CPCHawk] Start of new gate array and CRTC implementation
* [CPCHawk] Some cleanup
* [CPCHawk] More Cleanup
* [CPCHawk] More CRTC work
* [CPCHawk] More crtc work
* [CPCHawk] more CRTC work
* [CPCHawk] More CRTC work
* [CPCHawk] more crtc
* [CPCHawk] GateArray breaking changes WIP
* [CPCHawk] GA, CRTC and Screen changes
* [CPCHawk] CRTC and GateArray
* [CPCHawk] More stuff
* [CPCHawk] Progress
* [CPCHawk] Starting CRTC type abstraction
* [CPCHawk] Start CRTC status register implementation
* [CPCHAWK] Update colour palatte
* [CPCHawk] Trying to fix GA colour issues
* [CPCHawk] Actually use the Z80 /WAIT line
* [CPCHawk] Frame now running at req 19968 x6 INT
* [CPCHawk] Implement PAL16L8 as a separate device
* [CPCHawk] Border cropping SyncSetting
* [CPCHawk] Stuff
* [CPCHawk] More accurate CRT emulation
* [CPCHawk] Reset vertical timing var only when VSYNC ends in the middle of a scaline
* [CPCHawk] Allow IN port accesses to affect certain write-only devices
* [CPCHawk] Fixed high-impedence returns
* [CPCHawk] Readme update
* [CPCHawk] Update readme with Z80 timing test failures
* [CPCHawk] Update readme
Drawing a string is really having GDI+ do the drawing in software, uploading the result to a texture, then overlaying it to the render target. Since this texture is largely transparent, it needs blending. Of course, assuming the colors are all otherwise opaque, we only need to do this for the string texture draw
- setting multiple buttons to autofire actually works
- the config to respect lag in autofire is applied now
- can set meaningful axis hold / autofire
- removed last reference to "float autofire"
The documentation for these is lacking, as I've come to expect, but I'm
angry all the same.
For EmuHawk and DiscoHawk, I've pushed `$(Description)` (normally only
seen when publishing to NuGet) into `$(AssemblyTitle)`, which Windows
labels as "File description", and then explicitly set `$(Product)`.
Also `$(NeutralLanguage)` doesn't set a culture, it points any lookups
for `en-US` localisations to embedded resources, which I believe is the
default. This just makes it explicit.
broke with 8956657a34 I'm assuming. Notably this will now no longer copy the current settings over, but that might actually be more consistent with the behavior of the normal new option, so...
fixes#4056
`ControllerAdapter` ctor uses `(discs?.Length ?? 0) > 0`, but it gets
`discs` from earlier in core init; when it's later assigned to `_disks`,
empty lists are replaced with null, and other places in `NymaCore` use
`_disks != null`. The `default(int)` is to match pre-3af5b7a7f
behaviour.
in an ongoing effort to try and make the logic understandable
This should also restore default columns now when an existing tasmovie is currently loaded with column changes
and an existing bk2 is opened (which is then converted to a tasproj) (possible after 2ad7fc095c)
this allows loading the input roll settings stored in a tasproj even after it was initially `Load()`ed. This fixes those settings not getting applied when loading an existing, playing tasmovie into TAStudio.
YoshiRulz