search

flibitijibibo / MonoKickstart

Kick start executable for running stand-alone distributed Mono applications
Other
73 stars 14 forks source link

System.Exception: SDL2 Platform? #4

Closed rfht closed 6 years ago

rfht commented 6 years ago

I know that *BSD is not officially supported, but I looked into if I can get this to run on openbsd. Ran into this exception which unfortunately is pretty unhelpful:

Unhandled Exception: System.Exception: SDL2 Platform? at RogueCastle.Program.Main (System.String[] args) [0x001cd] in <9e0a72020e164ca4a4be787b88f2337f>:0 [ERROR] FATAL UNHANDLED EXCEPTION: System.Exception: SDL2 Platform? at RogueCastle.Program.Main (System.String[] args) [0x001cd] in <9e0a72020e164ca4a4be787b88f2337f>:0

Could use pointers to what this is trying to tell me for next steps. Can't find anything when searching online or grepping through monokickstart and fna code base...

rfht commented 6 years ago

Is this FMOD thing going to go away with FACT by any chance? It's kind of in the way, also with Eldritch which has an otherwise opensource engine...

flibitijibibo commented 6 years ago

Sadly no; FACT is only setting out to replace FNA's implementations of XACT, SoundEffect, and Song. When devs use FMOD they're just setting FNA_AUDIO_DISABLE_SOUND=1 and writing their own audio engine instead. FMOD's pretty much always going to be a brick wall without source access :/

rfht commented 6 years ago

Okay, then extrapolating from my testing, instead 100% it's only going to be 99% of FNA games that can work on the BSD platform... :) Still plenty of playtime!

We also just got an updated mono port (https://marc.info/?l=openbsd-ports-cvs&m=151489915805168&w=2) to 5.8, but still marked as broken because the csc compiler is broken on OpenBSD, but making me hopeful that we can unbreak it by the time the games receive the FNA 18.01 update.

rfht commented 6 years ago

FYI with mesa 17 just imported to -current, FEZ' hardware instancing doesn't cause glitches anymore.

rfht commented 6 years ago

Re: Stardew Valley. When applying XNAToFNA, this line sticks out:

[XnaToFna] [MonoMod] Cannot map dependency Stardew Valley.exe -> ((PresentationCore, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35), (PresentationCore)) - not found

Maybe @0x0ade would know something about it? FYI I didn't get XNAToFNA to apply on either a Windows system or with mono on OpenBSD. grepping through /etc/mono, I don't find anything with PresentationCore. However, PresentationCore seems to be in the libs (/usr/local/lib...), but not sure how to link the 2... Sigh, so much to learn about Mono/C#...

PresentationCore seems to be an obsolete library: https://docs.microsoft.com/en-us/dotnet/framework/whats-new/obsolete-members

rfht commented 6 years ago

Never mind - I found a way to get the gog Linux version of Stardew Valley to run without the bug! Makes me think that I could probably extend this to more non-FNA MonoGame games...

rfht commented 6 years ago

I got hooked on trying how I can get things to work on OpenBSD :) - currently looking at AxiomVerge which has an awesome soundtrack. There are 2 issues: The game hangs regularly, but at different parts of the game. This occurs typically when the screen transitions - like after choosing Start Game, after the intro movie, and and when moving to another room through the tube. Any pointers what I could look into that might be related?

The other issue is that it doesn't save. This may well be because of the stub Steamwork.NET.dll. I tried creating ~/.steam/steam/userdata which didn't help, but per PCGamingWiki I would need a steam user-id in order to have a full path.

@0x0ade - do you know if the stub dll provides a user-id?

I hope everything went well at MAGfest - looked at your slides which are great! Helped me understand better what FNA does! I am also updating SDL2 on OpenBSD with enabling the GameController API which has so far been missing...

EDIT: This line here sticks out in stdout when trying save/load: (0): Void f()(): Initializing save data.

0x0ade commented 6 years ago

The stub DLL returns 0 as the user ID, effectively providing no user ID. But even then, if I had to guess, the game uses Steamworks to actually write data to the userdata path you mentioned (maybe flibit can confirm / deny this).

rfht commented 6 years ago

Ah, so this appears to be a dead end when it comes to steamworks game..., Too bad. Guess I really have to stick with gog, itch, or humble

EDIT: Salt and Sanctuary doesn't have the problem and saves just fine. The 2 games must be using different ways of saving.

rfht commented 6 years ago

Never mind Axiom Verge - I'm getting a sense that I'm fiddling with something that I'm not supposed to...

In other news: We just enabled a (temporary) workaround to have our OpenBSD SDL2 pose as Linux until FNA 18.01+ changes have trickled down, and I hope that this will allow more people to get involved in this, have fun with the games on OpenBSD, and maybe help fix remaining issues...

https://marc.info/?l=openbsd-ports-cvs&m=151536581216331&w=2

rfht commented 6 years ago

@flibitijibibo The script that I've been working on to automate has now been confirmed to work with a series of games. Before I endorse it more widely in the OpenBSD community, I just wanted to make sure that you're okay with the existence of the script since it is based on your work with FNA, and that you don't have any concerns, e.g. attribution of your related work, license, etc.

It's definitely still in development, but showing good results. You can find it here:

https://github.com/thfrwn/fnaify

In case you want a summary of what it does: It collects the names of all the libraries that a game may use from the lib64 folder and the .config files, and checks if they (and mono) exist on the system (with some differences in filenams). It informs the user if something is missing and aborts in that case. If everything is there, it changes the .config files to openbsd including filenames and moves mono libraries that exist on the system out of the way (to avoid conflicts which appear to have been an issue). Finally, it replaces the launcher script with one that calls the .exe with mono and the LD_LIBRARY_PATH set to the system's folder.

flibitijibibo commented 6 years ago

Looks good to me!

rfht commented 6 years ago

Regarding Celeste: bought it, but... FMOD. Ugh. Maybe they can run it on FreeBSD with the Linux compatibility layer.

flibitijibibo commented 6 years ago

Damn, totally forgot about FMOD - that's my mistake. (Still don't know why they haven't open-sourced the runtime like Spine did)

rfht commented 6 years ago

Does Full Metal Furies use FMOD?

flibitijibibo commented 6 years ago

Yeah, FMF uses it as well. Only now noticing that most of my current stuff is using it right now...

rfht commented 6 years ago

Too bad. I asked FMOD for developer source access (that way I could at least see what might be possible), but unfortunately they never replied.

rfht commented 6 years ago

I think with the proprietary nature of FMOD, this may in the future subvert the preservation aspect of FNA games (if the company decides to not release their libraries for new platforms, for example if they go bankrupt etc.). I've asked for some input on mastodon (https://bsd.network/@thfr/99412579035089654). Just letting you know because of your general stance in favor of free platforms from what I've read. There are other games like Eldritch that are open-source except for FMOD. I hope to find a way forward at some point.

flibitijibibo commented 6 years ago

The best route I'm aware of is to get a paid license with source access, but I dunno if they absolutely require a game to ship or if they just want the money and that's it:

https://www.fmod.com/licensing

The free license EULA seems to suggest that you can't ship standalone binaries (not that I'd know for sure, what with not being a lawyer and all):

https://www.fmod.com/resources/eula/

You'd still be fighting version mismatches though, which FMOD has tons of problems with since the ABI seems to change at the drop of a hat.