so simply sticking to newest rom sets is the safest, otherwise there's little user control, because there's no global list of all known dumps with indications which of them are bad and what to use instead.
* fix noise audio channel on SMS VDP
* Update SN76489sms.cs
also, white noise is generated by XORing bits 0 and 3, not 0 and 1, on an SMS/GG VDP
* Update SN76489sms.cs
reverting commit #7b857e7
TAStudio previously called `PlayerNumber(...)` for each visible cell with the column's name, only to determine whether its player number is odd or even.
Because that function uses regex and is potentially called extremely often, this had a noticable impact on fps.
I've decided to just cache the odd/even playernumber result in a dictionary for faster access, which while not being my preferred way of handling this at least results in a decent speedup.
* Workaround crashes in MAME's zlib decompression code (see https://github.com/TASEmulators/BizHawk/issues/3615)
* Use using block, only catch InvalidDataException (what will be thrown if the zip entry has an unsupported (likely lzma) compression method)
apparently some game had 2002 leaderboards which caused a crash when making a form for every one of them in the leaderboard list, I guess windows has a limit on the amount of forms that can be active at once?
this is a quick hack to prevent such a crash, design needs to be rethought
* Implement IBasicMovieInfo interface for IMovie
this allows parsing basic movie fields into an own class that is independent from Bk2Movie/TasMovie
This is mainly useful for the PlayMovie dialog which can now load movie information from files on disk without having to go through the entire Bk2Movie/TasMovie loading process
* don't potentially iterate input log twice
* Optimize LoadFramecount
Waterbox cores can't create files anyways, and trying to send in ? might make MAME try to make the directory anyways (which crashes due to the syscall for that being unimplemented), while "" will not do that
Cleanup this code so it plays nicer with BizHawk's "run everything on the main thread" (+ WinForms not playing nice with async methods)
Resend any game session start / achievement unlocks / leaderboard triggers if they failed. Wait for all achievement unlocks and leaderboard triggers to finish on Dispose() (mostly for catching them when user closes BizHawk)
Update rcheevos to 10.7.0
This becomes mostly apparent in the PlayMovie dialog where one zstd instance is created for every single movie, churning significant amounts of memory even though zstd isn't even used
* Nes.Core now updates the DataBus in WriteMemory()
This will fix open bus execution following write instructions.
* Properly formatted changes in previous commit
I have addressed the requested changes.
This call in `ToolManager.Restart` was to set `[{Optional.Required}Service]`
props to `null`, but the tool form would get `Close`d immediately afterwards, so
it never gets the chance to hit the `null` path if one exists. However, some
tools are written as though they keep the stale value, for example attempting to
call a cleanup function on it in their `Closed` event handler. These will now
work as intended.
`[OptionalService]`s that can't be satisfied are set to `null` by
`ServiceInjector.UpdateServices`, so clearing those isn't necessary, and
`ClearServices` has no other usages.
* Use source generator for VersionInfo
* Remove leftover hacks
* Use same fallbacks as NixHawk when Git not available
---------
Co-authored-by: YoshiRulz <OSSYoshiRulz@gmail.com>
mame won't care too much about how good the dump is, but it will warn you in orange that emulation is imperfect, and in red if it's broken. we happen to use rom status icon to inform the user about multidisk bundle, so using it for mame info feels natural, because it directly affects what users can safely submit to tasvideos. we warn them about bad dumps because it's banned for pub, so it's similar here.
This had two issues. One, relative pathing with dlls is a no-go. Our hackery with changing cwd seems to confuse lua, and while it can find the dll, it fails to load as Windows (at least) does not consider cwd for loading up dlls it appears. Secondly, people using luasockets never actually loaded up the luasockets dll, rather we were bundling it ourselves. From history it seems this was due to our lua being compiled with CLR/.NET and that didn't play nice with exceptions? Doesn't seem to be an issue anymore, but we should probably still bundle luasockets for the time being given it used in many different projects which use the same script with multiple different emulators (thus our own sockets are simply not usable).
This reverts commit 007442773a.
fixes#3268 but unfixes #3053, which should instead be fixed by something that doesn't lead to breaking other things and the author of the "fix" giving up on the project
Add in better docs for `DeltaSerializer`.
Fix C64 not remembering disk changes when swapping disks (swapping disks essentially just reset the disk previously)
denominator is determined by taking refresh attoseconts `as_ticks(numerator)` which reduces the initial 64bit value to what can be used for video
mame needs flat 60fps for screenless machines, so we use a numerator that is a multiple, while also being a tiny bit more accurate than with 1,000,000,000
The main ram previously seemed to just be a slice of the system bus between 0 - 0xbfff. this posed two problems: that area is banked, and that area could represent main ram or aux ram. main ram now represents all of the ram main ram can possible represent, ordered like how the core orders it (which the way it does it happens to be very natural in any case), and a new aux ram domain does the same thing but with aux ram
Also some other changes put in so Rider wouldn't error on building Virtu
Main changes here would be with cartridges, as it appears cartridge stating was just broken since 4ffcc9654a (that's all the way back in 1.13!!!) due to SyncStateInternal not actually getting used
a few other components also had some variables missing from states
disks are not properly savestated yet, it appears it was commented out due to an assumption that disks were write only, but this isn't the case
some other cleanups here, none of them actually affecting state quality here
* Waterbox setup has been revamped to use the latest llvm parts (llvm 16 for compiler_rt/libunwind/libcxx/libcxxabi).
* Clang is now possible to use, and is the preferred compiler (due to superior performance).
* Supported compilers are now clang 14/15/16, and gcc 12.
* Other core updates are mixed in.
---------
Co-authored-by: Morilli <35152647+Morilli@users.noreply.github.com>
vadosnaprimer