minor changes were needed on the c++ side (luckily it was only the bizhawk specific code which needed changes)
limits.h force include is a hack due to one of citra's externals relying on some implicit std header including which doesn't happen on gcc10's libstdc++
this gives us a great level of control over how we build SDL2, omitting parts we don't want, and including parts we do want, like libusb support!
windows sdl2 normally doesn't support libusb, but with some magic it can be built and linked in fairly easily, giving windows sdl2 libusb support.
libusb support in sdl2 means official GC adapter support! (resolves#1879)
linux build will be done in a later commit
Also fix up libbizhash so it builds on clang
Slight fixes to sameboy and msxhawk makefiles
Fix rcheevo submodule commit (no actual changes, just make it point to a commit upstream actually has)
SDL2 .so not yet rebuilt, need to consider how to do that
citra seems to need at least Debian 11 to build
libe_sqlite3.so seemed to have already been built with Debian 10 so not bothering touching that
libwaterboxhost.so is Rust / targets glibc 2.28 anyways, nothing needs to be done there
lots of changes needed here as core has done quite a bit of changes (which in any case has reduced needed changes in upstream for our fork, so easier merging in the future)
gl crap is better done with fancy template classes to wrap around the msabi/sysvabi runtime check (so comparing with nullptr or using it as a bool works as expected)
c# changes pending (API has changed)
also, get rid of the GBA SRAM hack where it was inserted in ROMs (gross), instead figure out the size and give melonDS a blank save of the correct size
GBA SRAM is also now in SaveRAM
also add in more memory domains (SRAM/ROM/DSi BIOS)
* Swap System.Data.SQLite with Microsoft.Data.Sqlite
Apparently this is supposed to be a kind of successor? https://learn.microsoft.com/en-us/dotnet/standard/data/sqlite/compare
* Add e_sqlite3 libs to Assets, prevent runtimes folder creation with OS tailored libs plopped in, delete System.Data.SQLite references
The main objective in this PR is to get rid of the main .NET Framework dependencies in Bizware packages. This PR doesn't do that completely per se, still having .NET Framework used for WinForms Controls, but that can easily be swapped over for whatever UI framework we use next as long as it exposes native window handles in some way.
For this PR, it does some reorganizing of Bizware, splitting Bizware.OpenTK3 and Bizware.DirectX into 3 packages based on usage; Bizware.Audio, Bizware.Graphics, and Bizware.Input. These packages in the future probably could have more functionality moved into them, but for now they are largely just a reshuffling of the Bizware.OpenTK3 and Bizware.DirectX packages.
As both SlimDX and OpenTK3 are .NET Framework, they have been removed in this PR. Their replacements are as follows:
SharpDX: DirectSound, Direct3D9
Vortice: XAudio2, DirectInput/XInput
Silk.NET: OpenAL, OpenGL
SDL2-CS / native SDL2: OpenGL context management, new gamepad backend (replacing OpenTK's role for gamepads)
native X11: New key input backend (replacing one of OpenTK's roles for keyboards)
GLControl has been replaced by custom made control which just uses SDL2 for context management.
The OpenTK input backend has been replaced with a combination of SDL2 and an OS tailored key input backend (DirectInput on Windows, X11 on Linux, and planned to be Quartz on macOS). This is just represented on the user side as "SDL2" without mentioning the key input backend. This does mean for a while DirectX will be mandatory on Windows again, until a RAWINPUT backend is written for handling key input on Windows for the SDL2 input backend.
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 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).
CasualPokePlayer