this is mostly to workaround OOM issues with VERY large movies (>134217728 frames).
so large just the list of string references is "too big" and exceeds the .net 2GB limit.
even the on disk method fails here, as the offsets list (note, long and reference are the same size) becomes too big
this probably gives a bit of speedup for "normal" movies, as the generous 16MB growth amount would likely be plenty for the movie, although i haven't test this much
While msabi and sysv do agree what to do with floating point args for 4 floating point args (pass in xmm0-4), they dont agree what to do with mixing
msabi will choose the register corresponding with argument position. so if you have (int foo, float bar), bar will use xmm1
sysv instead will choose the first register available in the group. so with the previous example, you instead have bar using xmm0
the simple solution is to simply prohibit mixed args for now. maybe someday we could support mixing, but that's probably overkill (best use a struct at that point)
make a small dll for handling the msabi<->sysv adapter, using only assembly (taken from generated optimized rustc output) and handcrafted unwind information (c# exceptions in a callback seem to work fine in testing)
additionally, allow floating point arguments. this really only needs to occur on the c# side. msabi and sysv agree on the first 4 floating point args and for returns, so no work actually has to be done adapting these
with assembly being used, we can guarantee rax will not be stomped by compiler whims (and avoid potential floating point args from being trashed)
Fixes issues when mame sends over < 1 bounds which round down to 0 with a long cast (resulting in div by 0 exceptions)
Also fix some oopsies with incorrect function signatures.
Remove MAME string docs as they aren't really relevant anymore, as only MameGetString handles lua string handling now
reverts 8dcea2470
`PathEntryCollection.RetroSystemAbsolutePath` extension didn't like this, there
may be others, and I don't want to look through them all
The periodic callback is now used as a way to service "commands" sent from the main thread
Upon servicing a command, the mame thread will set the current command to NO_CMD then wait for the main thread allow the mame thread to continue
During this wait, the main thread may optionally set the next command (done here for STEP -> VIDEO), ensuring the next callback will service that command
A dummy "WAIT" command can be sent to trigger this waiting behavior, allowing the main thread to safely touch mame while the mame thread is frozen (important for mem accesses and probably savestates?)
A/V sync is also reworked. We can assume that 1/50 of a second worth of samples will be sent each sound callback. We can also assume 1/FPS of a second worth of time will be advanced each frame advance
So, we can just give hawk 1/FPS worth of samples every GetSamplesSync, if they are available. If we have less (probable on first few frames), we'll just give all the samples, and hope it balances out later.
* Use SameBoy submodule symlink for BSNES
* SGB memory domains
* Fix SGB saveram issues (extra data like rtc will be saved correctly now here)
* Various cleanups, avoid unneeded unsafe use, a little better EnterExit use
Co-authored-by: Morilli <35152647+Morilli@users.noreply.github.com>
YoshiRulz