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.
Also make it so initial loading uses the zstdstream or filestream directly instead of a memorystream with it all loaded
something of note, not really happy with how these read/write callbacks get used in practice, it seems they get spammed in small chunks
for initial loading, it's 8192 byte chunks each, which can be a LOT of callbacks, depending on core size (gpgx is ~500, MAME is ~22K)
similarly, savestates suffer a similar issue, although instead it's a ton of 4096 byte chunks (page size eh?)
The unmanaged <-> managed transitions obviously are not exactly performant, and I imagine are taking a significant portion of the time here
Perhaps some buffering strategy should come in on the native waterboxhost side to alleviate callback spam?
have it generate "leadin" and "leadout" tracks for multisession discs... this is almost certainly wrong for leadin (doesn't matter so far), leadout is probably right...
Move the various synths using the CUE SS_Base to a file, mostly just a nicer organizational change as MDS and CDI use one of these but not CUE
Misc improvements elsewhere
CasualPokePlayer