Add preliminary Unix compatibility (using Mono; resolves #1384)

[YoshiRulz]

tl;dr:

• Once you've installed the build and runtime dependencies and built the solution (see below), EmuHawk will run on Mono using libraries from Wine.
• You can play games with the keyboard (no controllers, sorry) on 9 systems in total (9 cores + NullHawk), plus one more if you build it yourself.
• You can use the Virtual Pad, savestates, and Hex Editor.

Progress will be tracked in #1430. Build instructions are in the new readme.

Before merging:

• Test everything on all the working cores (on Unix)
• Prevent anything to do with Lua from running on Unix
• See if any of the tools that didn't open have easy fixes
• Fix OpenTK X keyboard interface
• Double-check nothing breaks functionality on Windows (except YoshiRulz portability commit broke opengl display method #1384, which was fixed in 318fd36)

See also #1237, in which I make mono EmuHawk.exe not crash immediately.
This PR resolves #1384.

[vadosnaprimer]

I'm not opposed to trying N64 first, this is your project so you can start with whatever you like. I only suggested a C# core because it's native, so maybe it'd just work as soon as mono is fully set up. I don't know if N64 is currently available even in the Mac release, @Sappharad? But if you somehow manage to make it run, wow that'd be insane!

[YoshiRulz]

@vadosnaprimer There are cores written in C# in the codebase? (edit: Atari 2600?) I only changed to N64 because I have the non-libretro libraries installed (the libretro "core" was too confusing).

[YoshiRulz]

I can now play Pac-Man! Sorta!

All I did was comment out the DefaultValue attribute on A2600Settings.BackgroundColor, as you can see behind the game. What I haven't figured out is why the reflection fails in SettingsUtil.CreateSetter. With the attribute uncommented, object value = attr.Value (line 69) makes value null, causing value.GetType() (line 71) to throw a NullReferenceException.

I assume these attributes are actually being used as defaults somewhere and commenting isn't an acceptable solution? Edit: we could store the default colour as ARGB in a uint and reconstruct it when the default is read.

[vadosnaprimer]

Hahaha nice! We have 6502 and z80 implemented in C#, so cores that use them are also in C#: NESHawk, A2600Hawk, GBHawk, ZXHawk, C64Hawk, some others maybe.

[NarryG]

Useless knowledge to the rescue. Here's all the ones I know off the top of my head. There's probably a few more

C# Cores:
NESHawk
A2600Hawk
A7800Hawk
GBHawk
ZXHawk
SMSHawk
IntelliHawk
ColecoHawk
C64Hawk
Virtu
TI83Hawk

Unmanaged cores:
mGBA
VBA-Next
Mupen64Plus
Octoshock
Saturnus
PCEHawk
Bizswan
Bizlynx
QuickNES

Waterbox (magic) cores:
bsnes
snes9x
GPGX
PCFX
Sameboy
Picodrive
Virtualboy

[NarryG]

Also, those defaults are being used in the settings config, so commenting them out is going to break things as it stands.

[YoshiRulz]

Thank you for the useless knowledge! Going back to the original NES plan (but with NesHawk, which I somehow overlooked), I've immediately run into the same .dll loading issue as the unmanaged cores. That being that mono is unable to find them even when they're in the executable's directory and said directory is in LD_LIBRARY_PATH. In this case it's blip_buf.dll, required for an instance variable in NES.MagicSoundProvider.

I'll leave it there for today but I'll be back! I'm thinking sound isn't as important as playing the game, maybe there's a way to discard it (I've not yet looked).

[alyosha-tas]

blip_buf is used in most of the C# cores. It's only due to A2600's age that it isn't used there yet (though it probably should be at some point.)

It would be relatively easy to comment out all the blip_buf sound stuff though, if there is no other option.

[Sappharad]

Several years ago before I started doing native builds of cores for macOS, I had thrown together some shitty C# replacement code for blip_buf calls. At some point the portable branch was re-forked from scratch and I just compiled blip_buf as a native library instead so I could replace less code. If it's at all useful, maybe you could try and dig up the crappy C# implementation and use that. I don't know how far back you'd have to go to get it, and actually wouldn't recommend it.

Why don't you just build the library and get it over with? mono will automatically look for lib[dllnamehere].so and load it instead of the windows .dll for you. No mappings required.

[YoshiRulz]

if (unix) return; works!

@Sappharad by "just build the library" do you mean compile this? I'm afraid I know less about C than I do about C#.

[YoshiRulz]

(edit: better screenshot below)
Ghostbusters (1984) running in ZXHawk... I think...

[Asnivor]

@YoshiRulz switch the core to 128k mode and you can just press enter to start loading the game.
Be nice to see whether the core loading/playing processes are working correctly.

[YoshiRulz]

@Asnivor Who you gonna call?

Edit: it's BurgerTime!

Edit 2: Q*bert? Window title says hack, but at least it's running.

Edit 3: Yes that does say 3 a.m. in the screenshot, bbl.

[vadosnaprimer]

Man this is incredible!

[YoshiRulz]

SEEEEGAAAAAA

[YoshiRulz]

Opening TAStudio causes GDIRenderer.CreateNormalHFont to throw an EntryPointNotFoundException on the external function CreateFontIndirect from gdi32.dll. But the function exists:

> objdump -T /usr/lib/wine/gdi32.dll.so | grep CreateFontIndirect
000000000007e810 g    DF .text  0000000000000129  Base        CreateFontIndirectA
000000000007e690 g    DF .text  0000000000000171  Base        CreateFontIndirectW
000000000007e470 g    DF .text  000000000000021c  Base        CreateFontIndirectExA
000000000007e160 g    DF .text  000000000000030c  Base        CreateFontIndirectExW

From what I can tell, there are two copies for "ANSI" and "wide" strings. Would changing lines 346-347 to read:

[DllImport("gdi32.dll")]
private static extern IntPtr CreateFontIndirectW(

be a good idea? The linked docs say "wide" has been the default for CharSet.Auto since Windows XP.

[vadosnaprimer]

The firmware file is called dos1541 with no extension, and I don't know if it's safe to distribute it.

[nattthebear]

I recommend you figure out how to get as many cores running as possible in your unix build, because that's what will make users happy. Bikeshedding package maintainer bullshit? Not so much.

[YoshiRulz]

No clue know how to use it but it didn't crash:

Edit: can I only use DualGambatte after first loading Gambatte?

[Asnivor]

@YoshiRulz I believe you just need to create a bundler xml with two ROMs (using the multi-disk bundler tool for GB) then open that.

At least that's worked for me in the past (although not sure whether you need to have gambatte set as the GB core).

[vadosnaprimer]

Guide: http://tasvideos.org/forum/viewtopic.php?t=17307

[vadosnaprimer]

Re: Lua. There's this:
#1093
I dunno why the author never made a pull request.

It has its own issue related to Linux btw:
lsthiros#1

It'd really make sense to make use of this sooner or later.

[YoshiRulz]

@vadosnaprimer I'll be honest, Lua is pretty far down my list of things to port. @lsthiros is welcome to it.

[YoshiRulz]

And we have keyboard input! I think that's enough to ship, is there some kind of test suite for Windows or is it all manual?

[vadosnaprimer]

Everything is manual. If it's ready, we can merge this as a branch and ask people to actually try it out, fixing stuff in the main repo as needed, or with PRs if the fixes or improvements need to be reviewed.

[YoshiRulz]

@vadosnaprimer Got it. There certainly is a performance hit by the way: a quick test on Windows has SMB1 running at 60 fps on the 2.3 release and 19 fps on my HEAD (though I get about 30 fps on Linux, gonna credit a slightly better graphics card for that). SM64 ran at 60 fps on both, so it's not every core. I didn't check if there was a NesHawk issue in whatever commit I forked from, so it might not have been me, but I'll assume it was and apologize. Input and sound seem unaffected on Windows, and Lua still works.

[vadosnaprimer]

Yes it was a performance hit caused by emulation improvements in some in-house cores. Don't worry. Do you have anything else to clean up/finish?

[alyosha-tas]

19 fps? That sounds like some logging is happening, since NESHawk should have actually gotten a slight boost in performance.

Either that or it was built in debug mode.

EDIT: found a leftover debug line in NESHawk, maybe that fixes things for you.

[YoshiRulz]

@vadosnaprimer Oh thank goodness. Yes, I'm done (for now), I've got a list of tiny things to do that aren't Mono-related which I'll be working through once this is merged.

@alyosha-tas You added that line after I forked, but I can see you've been working on it a lot so let's leave it at "a performance hit caused by emulation improvements".

[alyosha-tas]

Anything holding up this getting merged?

I'm going to be having conflicting commits coming up and I'd prefer not to make a mess with mainform.