[WIP] .NET Core 3.0 support (resolves #1415)

[nattthebear]

DO NOT MERGE - NOT READY.

Right now, it compiles, but that's about it. Major problems/blockers:

1. OpenTK support. Seems promising, but still a WIP: [4.0] Checklist and work tracker for OpenTK 4.0 opentk/opentk#823
2. Lua support. MoonSharp seems promising, but would require a decent number of things to be rewritten
3. NET Core 3 needs to release. probably 4+ months away? Core 3.1 is out
4. SlimDX support? The project seems absolutely dead. If the things it did are important, probably better to try replacing with an alternative. DirectX now strictly optional, and only loads on Windows anyway
5. 7zip support. I assume it's not working. There don't seem to be any very good alternatives. SharpCompress replaced SevenZipSharp a while ago

[Asnivor]

A couple of possibly-related things that have come up in our work on mono compatibility.

GDIRenderer

This is going to be problematic in .netcore as it is in mono. You will probably have to wait and see how MS implements System.Drawing. But it may be GDI+ (or libgdiplus on linux) or maybe even another assembly like ImageSharp.Drawing. I guess we will have to wait and see (unless they have made a decision already that I have missed). Regardless, using DllImport("gdi32.dll") is not going to cut it. The safe bet would maybe be to rework GDIRenderer to use GDI+ along with the controls that rely on this. There are only really two custom controls that make use of this at the moment as far as I can see, HexView.cs (the experimental 'new' hexviewer) and InputRoll.cs (which I'm assuming is just TAStudio).

I've had a look at doing this myself today for the mono compatibility piece, but I really do not know what I am doing (and hence, am not getting anywhere).

SevenZipSharp

This is another thing that will not work. As discussed in IRC, SharpCompress looks like a suitable replacement. In fact, we now have this in place for mono (albeit in a fork).

You can see the implementation here.

At the moment it kinda copies the SevenZipSharp way of implementation by just dumping the source in its own folder within BizHawk.Client.Common.SharpCompress, but obviously this could just be a seperate project that builds a DLL that we reference (at the moment its easy as it is as it builds on both windows and mono/linux without too much messing around). edit: now pulling SharpCompress from NuGet --yoshi

At the moment it is only used on Unix, continuing with SevenZipSharp on Windows:
https://github.com/TASVideos/BizHawk/blob/1b5d78c57ca7357d5bb66dc80ac8390b59558e26/BizHawk.Client.EmuHawk/Program.cs#L124-L135
...but I tested it on Windows as well and didn't notice a performance hit.

It does have other benefits too. eg, support for RAR, LZIP and GZIP archives just by changing the frontend file extension filters and a couple of lines in the SharpCompressArchiveHandler.cs class. And possibly TAR as well, although SharpCompress does appear to detect *.gbc roms as tar archives, so a little more work would be needed on that. I mean, gzip, tar and lzip are not particularly important archive formats for us, but potentially with .netcore and *nix users supporting the opening of them may become more important I guess...

edit: replaced outdated links, shortened wall of text, fixed subheading markdown --yoshi

[Sappharad]

BizHawk.Client.EmuHawk.CustomControls.GDIRenderer.cs

This is going to be problematic in .netcore as it is in mono. You will probably have to wait and see how MS implements System.Drawing. But it may be GDI+ (or libgdiplus on linux) or maybe even another assembly like ImageSharp.Drawing. I guess we will have to wait and see (unless they have made a decision already that I have missed).

You did. The WinForms implementation for .NET Core 3 is available on GitHub:
https://github.com/dotnet/winforms
Note that it only supports Windows, as they originally announced. Mono still requires their separate implementation.
System.Drawing is here:
https://github.com/dotnet/corefx/tree/master/src/System.Drawing.Common/src/System/Drawing

[Asnivor]

Ok, so it will be gdiplus (and libgidplus on linux) looking at the corefx System.Drawing.Common. My point still stands though. Someone with more knowledge than me will have to do away with our existing gdi32 calls.

[YoshiRulz]

(moved to #1415 (comment), except the following which I felt didn't belong there or in #971)

Moving from Framework to Core seems to me like a change deserving of version 3.0, but it's a good opportunity to restructure things regardless. My ideas are:

• Change the directory structure of projects to better reflect their dependency tree (TODO link diagrams) done;
• Move the rest of the system cores to git submodules;
• Generate web-accessible docs from some or all projects (GitHub Pages will serve docs from (top-level)/docs on the master branch to tasvideos.github.io/BizHawk);
• Enforce tabs for indentation (and possibly more yet to be agreed upon e.g. naming conventions, spaces around operators, etc.); and
• Any other breaking changes that don't make it into 2.4.

~Given how big the diffs are going to be, it might be worth starting a new commit history (i.e. committing the ported codebase to a new branch, and also renaming masterto something like2.x`). I don't think our docs are good enough to do that currently, we would end up wasting a lot of time looking through the old branch's history.~~ moved 'em anyway, I just bookmarked the commit before

edit: I've looked into Mono's LLVM "mode" and it doesn't work. All the top search results are for Core so I assume that works.

[adelikat]

The reason that GDIRenderer exists is because GDI+ isn't going to cut it in terms of performance for TAStuido. Rather than looking into a GDI+ implementation we need to be wiring up the native rendering (opengl, directx) that the mainform is using to do the drawing.

[YoshiRulz]

edit: rebase backed up here, pre-rebase backed up here

[nattthebear]

We're moving in this direction, but this exact pull request is no longer relevant