Kill Bizware .NET Framework deps

[CasualPokePlayer]

Only has a WinForms dep for GraphicsControls now

Supersedes #3622

[nattthebear]

Could you build out a description for this PR? Include all of the libraries we're removing, the ones we're replacing them with, and the basic objective here.

[CasualPokePlayer]

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.

[YoshiRulz]

[...] still having .NET Framework used for WinForms Controls [...for its] native window handles [...]

If this is just IWin32Window.Handle, the existing IDialogParent abstraction covers that.

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.

The reason I split them by ~platform in the first place was so the whole project could be deleted once it was no longer needed. It's not like the frontend can selectively import just graphics or just input, and we're not publishing them, so why split them this way? Was it annoying having an interface and its implementations in separate projects?

edit: Also, is this ready to merge today? If so I'll start testing.

[CasualPokePlayer]

One of the first reasons I ended up going for this design was due to how the SDL2 input backend ended up turning out, where it ended up using DirectInput anyways potentially (and even in the future it would just go ahead and use the Windows specific RAWINPUT API).

Another reason was just due to the amount of different libraries that ended up used, if I were to split it up by each library (and maybe charitably combine SharpDX and Vortice usage in a single library), that'd still end with 3 or maybe 4? And that's tricky to even do with the cross library use of the SDL2 backend.

There is also the matter of dependencies. At the moment this doesn't mean much, as this is largely just a reshuffling of files with some cleanups, and so dependency chains are largely the same. However, the Bizware.Audio only depends on Client.Common for ISoundOutput and IHostAudioManager, interfaces which can be moved over to Bizware.Audio in the future. Bizware.Input only depends on Client.Common for IHostInputAdapter, ClientInputFocus, KeyEvent, DistinctKey, and Config, mostly stuff which could be moved over to Bizware.Input (along with a lot of other functionality with input for that matter), and Config can probably be abstracted so Bizware.Input doesn't need to be dependant on the entire Config. In the end, these two could be made to depend on at most on BizHawk.Common and nothing else.

Also yes, assuming everything works fine it could be merged. As a note, I don't have any game controllers to test with so I'm completely blind on that front.

[Morilli]

Using my PlayStation 4 controller, I can't get any button pressed to get recognized with the SDL input backend.

[CasualPokePlayer]

@Morilli Please re-try on the latest commit.

[Morilli]

Okay so apparently sometimes when connecting or dis- and reconnecting the controller too fast it can hardcrash bizhawk:

System.ArgumentException: Ein Element mit dem gleichen Schlüssel wurde bereits hinzugefügt.
   bei System.ThrowHelper.ThrowArgumentException(ExceptionResource resource)
   bei System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
   bei BizHawk.Bizware.Input.SDL2Gamepad.AddDevice(Int32 deviceIndex) in /src/BizHawk.Bizware.Input/SDL2/SDL2Gamepad.cs:Zeile 70.
   bei BizHawk.Bizware.Input.SDL2InputAdapter.SDLThread() in /src/BizHawk.Bizware.Input/SDL2/SDL2InputAdapter.cs:Zeile 88.
   bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
   bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
   bei System.Threading.ThreadHelper.ThreadStart()

I'm not sure whether this is ultimately SDLs fault or not, but it would be great if BizHawk didn't hardcrash when e.g. the controller disconnects.

Aside from that though, input now also does not work.

[CasualPokePlayer]

Seems that is due to SDL pushing an event which has a joystick with an identical instance id added, which doesn't really make sense I guess (disconnect event never occurs I guess?) should be trivial to just check if it exists and ignore the request to add it(?)

[CasualPokePlayer]

Some debug printing is in the console now, if it doesn't work, please post what gets shoved into the console.

[Morilli]

I'm getting some problems with bizhawk freezing completely which is probably also caused by some of the SDL code.
Also this part of the logging does not seem right to me:

Using SDL2 for host input (keyboard + gamepads)
Connected SDL gamepad, device index 0, instance ID 0, name PS4 Controller
Disconnecting SDL gamepad, device index 0, instance ID -1, name
Connected SDL gamepad, device index 0, instance ID 1, name PS4 Controller
Disconnecting SDL gamepad, device index 0, instance ID -1, name
Connected SDL gamepad, device index 0, instance ID 2, name PS4 Controller
Disconnecting SDL gamepad, device index 0, instance ID -1, name
Connected SDL gamepad, device index 0, instance ID 3, name PS4 Controller
Disconnecting SDL gamepad, device index 0, instance ID -1, name
Connected SDL gamepad, device index 0, instance ID 4, name PS4 Controller

[CasualPokePlayer]

The logging isn't super strange outside of disconnect and reconnecting (assuming you aren't doing that yourself), the -1 and name being blank for disconnect is more indicating you can't use device indexes for retrieving device info once it's disconnected (should be simple enough to fix anyways)

Not sure why it'd end up freezing completely, perhaps the SDL events are locking up?

[Morilli]

The freeze seemingly comes from a deadlock in Input.cs because of an infinite wait on the lock(this); I'm not sure why or when this happens but I can still occasionally reproduce this:

Logging now matches connect with disconnect nicely, so that's good.
However input still is not working.

[Morilli]

With additional logging:

...
Entering SDL event loop
Exiting SDL event loop
Entering SDL event loop
Exiting SDL event loop
Entering SDL event loop
Exiting SDL event loop
Entering SDL event loop
Exiting SDL event loop
Entering SDL event loop
Connected SDL gamepad, device index 0, instance ID 10, name PS4 Controller
Exiting SDL event loop
Entering SDL event loop
[freeze]

[kalimag]

On SDL2, the up and down direction for the analog sticks are reversed, both for digital input (left stick forward binds LStickDown) and analog input (stick forward is bound to negative axis input by default).

Win10 with a wireless Xbox One controller in case it makes a difference.

[CasualPokePlayer]

That seems to be an intentional detail in SDL2, it defines joystick Y axis the opposite way from XInput. We probably could just internally flip it back around here.

[CasualPokePlayer]

If there aren't any objections, I'll be merging this soon (I do need at least the OpenGL part merged for a core port I'm currently doing).

[YoshiRulz]

SUPER late, but can confirm gamepads work on Win10, including haptic feedback, and also everything else from this PR. I used an XBone gamepad 045E:02FF on the dev build ca756a2.

edit: And everything except haptic feedback on Linux.
edit edit: Can also confirm haptic feedback works on Linux \o/