System.Exception: SDL2 Platform?

[rfht]

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]

Sorry, I just realized this here is not the right place to ask. It's a mono issue. I'll take it there. Sorry for the noise.

[flibitijibibo]

Actually this one's on me! In a slightly different way though...

That Exception is from not recognizing the SDL_GetPlatform() result:

https://hg.libsdl.org/SDL/file/6d85907059ff/src/SDL.c#l393

So if you cheat and change the result to "Linux" it'll work using the rules I have set for Linux regarding stuff like filesystem locations (XDG_DATA_HOME, etc). I think most of my games work on *BSD if you add that hack; if you want to patch up FNA to support BSDs I'd love to have it:

https://github.com/FNA-XNA/FNA/blob/master/src/FNAPlatform/SDL2_FNAPlatform.cs

Just grep around for 'OSVersion' and you'll see all our platform paths.

[rfht]

Thanks, I'll take a look how to best cheat and have the string be linux.

I think it should be possible to add BSD support, but this will take some time... You'll hear from me if/when I come up with something!

[rfht]

Proof-of-concept works:

https://www.reddit.com/r/openbsd_gaming/comments/7mbi44/proofofconcept_fnabased_games_can_run_on_openbsd/

This will need some review and polish before I can send you patches though if you are interested...

[flibitijibibo]

Beautiful! Definitely take your time with the FNA fixes, I'm hoping the only fix on FNA's end is the storage root path but if there's more to it I can definitely start integrating that and everything else into the rest of my games (most of which will be getting updated once FACT is done, so this is coming at a really good time).

[rfht]

That would be great if this could go into the update! There are other issues; like we don't have /proc on OpenBSD... Will keep you posted.

[rfht]

Is there any reference dummy project that can be used to test patches for FNA are working as intended?

[flibitijibibo]

Not really, the surface area of the framework is really large so we just test games that we know depend on a feature we’re changing. So for stuff like StorageDevice I usually test games like Rogue Legacy and Dust: An Elysian Tail which use that feature for save data.

[flibitijibibo]

I was in the Storage stuff just now to fix one of my Mono workarounds, so I added the BSDs from SDL's list into FNA's StorageRoot check:

https://github.com/FNA-XNA/FNA/commit/36b6d225d27f3bede548a3fc673477c4fd9cf80c

That should fix the one obvious problem, the rest of the OSVersion checks are for specific paths that won't apply to anyone else (mostly macOS or GLES stuff).

[rfht]

Here a reddit post with link to pastebin of the local diff that enabled Rogue Legacy to run (when launched with mono):

https://www.reddit.com/r/freebsd/comments/7mj00w/making_fna_games_framework_accept_bsd_platforms/drvum27/

I'm working my way backwards at this point trying to figure out which changes were the necessary ones.

[flibitijibibo]

Whew, forgot how old Rogue’s main version was. I need to update fna-unstable...

The one thing I can add is the dllmap entries, I just need confirmation that openbsd/freebsd/netbsd are all different values for the ‘os’ property.

The rest looks pretty simple, just replacing the Linux binaries and adding some stuff that I added since that version shipped (way too long ago).

[flibitijibibo]

Thank you man pages:

https://linux.die.net/man/5/mono-config

https://github.com/FNA-XNA/FNA/commit/160bd84babd1a431e33e89df4fc2ff4b5d0d892c

[rfht]

By the way, game profiles are also saved in the proper location in ~/.local/share etc.

[rfht]

Capsized says it can't find type System.Diagnostics.SystemDiagnosticsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089, with system default config, as well as when passing the monokickstart monomachineconfig file via --config flag or MONO_CONFIG environment variable.

There is a matching section in both system an monokickstart's machine config, but not sure why it throws an error.

Do you have any suggestions?

Thanks!

Full error message:

$ mono NePlusUltra.exe
Couldn't find XDG_DATA_HOME.
Fall back to hardcoded ~/.local/share/Capsized/.

Unhandled Exception:
System.TypeInitializationException: The type initializer for 'System.Xml.Serialization.XmlSerializer' threw an exception. ---> System.Configuration.ConfigurationErrorsException: Type 'System.Diagnostics.SystemDiagnosticsSection, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' not found.
  at System.Configuration.InternalConfigurationHost.GetConfigType (System.String typeName, System.Boolean throwOnError) [0x0002e] in <8589a4ad38fd45fbbad159f8fef038ba>:0                                                     
  at System.Configuration.ConfigInfo.CreateInstance () [0x00011] in <8589a4ad38fd45fbbad159f8fef038ba>:0
  at System.Configuration.SectionInfo.CreateInstance () [0x00000] in <8589a4ad38fd45fbbad159f8fef038ba>:0
  at System.Configuration.Configuration.GetSectionInstance (System.Configuration.SectionInfo config, System.Boolean createDefaultInstance) [0x00022] in <8589a4ad38fd45fbbad159f8fef038ba>:0                                  
  at System.Configuration.ConfigurationSectionCollection.get_Item (System.String name) [0x00032] in <8589a4ad38fd45fbbad159f8fef038ba>:0                                                                                      
  at System.Configuration.Configuration.GetSection (System.String path) [0x00021] in <8589a4ad38fd45fbbad159f8fef038ba>:0                                                                                                     
  at System.Configuration.ClientConfigurationSystem.System.Configuration.Internal.IInternalConfigSystem.GetSection (System.String configKey) [0x00006] in <8589a4ad38fd45fbbad159f8fef038ba>:0                                
  at System.Configuration.ConfigurationManager.GetSection (System.String sectionName) [0x00005] in <8589a4ad38fd45fbbad159f8fef038ba>:0                                                                                       
  at System.Configuration.ConfigurationSettings.GetConfig (System.String sectionName) [0x00000] in <795cd6eae07449a6a8984d92df5c81a6>:0                                                                                       
  at System.Xml.Serialization.XmlSerializer..cctor () [0x000f0] in <0cdeb4637d51469c8be89e03d8897bc6>:0
  --- End of inner exception stack trace ---
  at (wrapper managed-to-native) System.Object:__icall_wrapper_mono_generic_class_init (intptr)
  at NePlusUltra.Start.Main (System.String[] args) [0x00060] in <2cdd9eda9db949c88af0348fc71b7105>:0`

[flibitijibibo]

My guess is the files in monoconfig need to have their entries updated to add the BSDs, similar to how I added them in FNA.dll.config. Machine config is probably okay but I wonder if the problem is an entry point going missing while it’s loading that type.

[rfht]

FEZ runs after compiling libmojoshader.so with -DFLIP_VIEWPORT=1. However I had to move all the libraries into the base game folder for them to be detected - lib64 or lib folder somehow were not.

[rfht]

Oh, and in contrast to Rogue Legacy it doesn't trigger abort trap/core dump on exit.

[rfht]

There's a graphics glitch where the sprites are invisible after the first scene in the house:

https://www.reddit.com/r/openbsd_gaming/comments/7mxfxr/fez_fna_game_runs_on_openbsd_with_graphical/

[flibitijibibo]

Were the kick binaries built with RPATH set? That’d be my first guess as to what’s wrong... for the rendering, usually turning various graphics options off and turning on singlethreaded mode fixes it. Interestingly it’s the fancy stuff that’s on screen, not the simple sprites...

[rfht]

I actually am not using kick binaries at the moment, but am running the .exe with e.g. mono FEZ.exe. I had tried the kick binaries, but didn't get that to work.

I'll take a look at graphics options and singlethreaded mode...

[rfht]

The glitch is gone after turning Hardware Instancing off in the game's menu.

[flibitijibibo]

Sounds about right. It was rendering the instanced stuff just fine but didn’t know what to do afterward. Pretty common since drivers don’t get to use that feature very often!

[rfht]

My hardware setup:

OpenBSD -current (amd64) on ThinkPad x230 with i5-3320M, Intel HD Graphics 4000, 16GB RAM, Mesa 13.0.6

Saw your tweet, follow them via twitrss, but don't have a twitter account myself.

[rfht]

By the way, library location can be set with LD_LIBRARY_PATH as I did in the Owlboy video.

[rfht]

I uploaded a video of how I set up "A Virus Named TOM" with the [fnaify script] (https://github.com/thfrwn/fnaify). Unfortunately the game crashed soon, but that's a first for me and may be related to the concurrent video recording. Here it is: https://www.reddit.com/r/openbsd_gaming/comments/7n7qmx/fna_first_demo_of_how_to_apply_fnaify_script/

[rfht]

FYI we just got update to mesa 17 (https://marc.info/?l=openbsd-cvs&m=151470245217755&w=2). Made me curious and I found that we had to revert back to mesa 13 earlier this year because of a modesetting bug on IVB (https://marc.info/?l=openbsd-cvs&m=150376680428764&w=2).

Maybe this will resolve issues with hardware instancing

[flibitijibibo]

FNA 18.01 now ships with the BSD checks:

https://github.com/FNA-XNA/FNA/releases/tag/18.01

All my updates/releases from now on will include BSD checks, so hopefully by the end of 2018 (admittedly a really long time) the SDL_GetPlatform hack won't be needed anymore.

[rfht]

That's awesome. Thanks for the otherwise "boring" release! I guess these experiments can serve as a demonstration that FNA can (at least in theory) work with platforms that have working mono and SDL2 libraries...

Updates:

• Dust AET works, too.
• HackNet: Can't compile XNAWebRenderer/chromiumembedded so far, looks like we are missing an event_types.h on OpenBSD platform.
• Stardew Valley: starts, but crashes when trying to save or load (and it autosaves at the beginning of every game, so I'm not getting past menu and intro). I did a mono trace and it looks like mcs is trying to compile a variably named .cs file in /tmp which doesn't exist. The trace is here if you're interested. The relevant part appears to be at line #72.

Is patreon still the place to sponsor your work, or should I wait for itch.io?

[flibitijibibo]

Stardew fails on Mono versions before... I think 4.4? Either 4.2 or 4.4 introduced fixes to the Xml namespace that fixes that particular problem.

For Hacknet, pass -disableweb to ignore all the Chromium goo. Even if XNAWR did compile you'd probably want that off anyway... man I did not enjoy throwing that lib together.

Patreon's currently the best way to keep track of me, though I don't know if I'll ever turn it back on - I'd have to find someone at Itch who wants to implement subscriptions; all the people I know are all frontend people >_<

[rfht]

Awesome, now Hacknet works!

The mono version that I have running is 4.6.2: x230$ mono --version Mono JIT compiler version 4.6.2 (Stable 4.6.2.16/ac9e222 Fri Dec 22 16:20:51 PST 2017) Copyright (C) 2002-2014 Novell, Inc, Xamarin Inc and Contributors. www.mono-project.com TLS: __thread SIGSEGV: normal Notification: kqueue Architecture: amd64 Disabled: none Misc: softdebug LLVM: supported, not enabled. GC: Included Boehm (with typed GC and Parallel Mark) x230$

Apparently mono can set a certain version with --runtime=VERSION, but I'm not sure about the effects of this. Tried it with setting v4.0.0.0 once since this is contained in some of the other games' .config files, but no change. Sounds like that should be fixable with noodling over it a little more.

[rfht]

I also looked at Tooth and Tail's libraries, but it uses fmod and I doubt that we'll get a closed source library like that onto the platform... Haven't tried running it for this reason.

[flibitijibibo]

Oh you know what, just realized that this might not be our hackport of Stardew. Is this the official Linux release? Sadly that was a MonoGame port done by somebody else, so I dunno if that’ll work. If you take a Windows build and run it through XnaToFna I think that’ll work with MONO_IOMAP=all set. @0x0ade might have a better idea about all that...

[rfht]

That might explain the unusual finding of the port compiling a .cs during runtime for save/load... I'll take a look.

[rfht]

Keeping my hands off anything steam for now. That might never work if it needs to talk to a running steam process.

[0x0ade]

Keeping my hands off anything steam for now. That might never work if it needs to talk to a running steam process.

You can stub Steamworks.NET for games which use it, such as Stardew Valley and Duck Game. I once did it some time ago - FNADroid and the DuckGame-Linux hackport already ship with this stub: https://github.com/0x0ade/FNADroid/blob/master/FNADroid/libs/managed/Steamworks.NET.dll

Regarding Stardew Valley: You'll probably be luckier with running the Windows version via XnaToFna. Based on our Linux testing, you shouldn't even need MONO_IOMAP=all.
XnaToFna itself hasn't been tested on *BSD before, but I don't see any reason why it should fail.

Quick XnaToFna setup:

1. mkdir orig, backup all libraries and binaries into the new orig directory. BmFont.dll, Lidgren.Network.dll, xTile.dll and Stardew Valley.exe are enough.
2. Download the latest stable XnaToFna.exe, then place XnaToFna, FNA and all its dependencies into the game directory.
3. mono XnaToFna.exe --force-anycpu --skip-content scans the working directory and binary directory, then patches the game.

Unless I missed anything, this will result in a copy of Stardew Valley referring to FNA.

I'm wondering if the same StardewValley.XmlSerializers-related exception gets thrown when using FNA. If that's the case, I'll take a look at the game's code.
Guessing from the stack trace, the game seems to generate the XML serializers at runtime. Either the game dirtily calls mcs itself, or there's an underlying issue with System.CodeDom and any related namespaces with mono on OpenBSD.

[rfht]

Thanks! I can confirm the stub Steamworks.NET works - with Salt and Sanctuary... Now I bought almost all of the remaining FNA games on steam that I didn't have before.

[rfht]

x230$ mono XnaToFna.exe

Unhandled Exception:
System.BadImageFormatException: Could not resolve field token 0x04000d30  
File name: 'XnaToFna'
x230$    

The Mac Version complains about missing XACT.

[rfht]

I can see about compiling XnaToFna from source... Bear with me - I'm simultaneously expanding my steam library! :)

[rfht]

I can probably just run XNAToFNA on a Windows machine and see if the result works.

[rfht]

Sorry, that was my fault for not copying FNA.dll*. Now troubleshooting why XnaToFna can't find entrypoint MOJOSHADER_glBestProfile, but that should be fixable.

[rfht]

Errors in Stardew Valley (the error reported with pastebin link above), Capsized, and Axiom Verge all mention XmlSerializer. Seems to be the pattern of where it fails...

[rfht]

Found a fix for Capsized and Axiom Verge by removing diagnostics section from /etc/mono/4.5/machine.config. Both work now, too.

[rfht]

FYI I the MacOS version of Stardew Valley to start, but it exhibits the same error when (auto)saving. Not sure if that one was FNA. Didn't get XNAToFNA to complete the Windows version yet.

[flibitijibibo]

Stardew macOS is MonoGame as well, so that one's out of our reach too. Funny that it works slightly better though.

AFAIK this list is complete so anything not on here is probably running something else:

http://www.flibitijibibo.com/index.php?page=Portfolio/Tools#01_FNA.txt

Some of my older ports may still have the MonoGame.Framework.dll name though, but it's not actually MG; I only changed the assembly name ~October 2014 after I was 100% sure that there were too many rewrites to have my code make its way back into MG. If there are any games that still use that old name let me know, I'll update/push new builds with the proper assembly name.

[rfht]

Rogue Legacy, A Virus Named TOM, Capsized, and Tooth and Tail of the games that I currently have on my HDD have the MonoGame.Framework.dll:

x230$ find . -iname "monogame*"
./roguelegacy/roguelegacy-working/data/noarch/game/MonoGame.Framework.dll
./avnt/avnt-tweaked/data/MonoGame.Framework.dll
./avnt/demo/data/MonoGame.Framework.dll
./bastion/bastion-tweaked/data/MonoGame.Framework.Net.dll
./capsized/capsized-tweaked/data/noarch/game/MonoGame.Framework.dll
./stardew-valley/macversion/package.pkg/payload/Contents/MacOS    MonoGame.Framework.dll
./stardew-valley/macversion/package.pkg/payload/Contents/MacOS/MonoGame.Framework.dll.config
./stardew-valley/macversion/package.pkg/payload/Contents/MacOS/MonoGame.Framework.dll.config.linux
./stardew-valley/linuxversion/data/noarch/game/MonoGame.Framework.dll
./stardew-valley/linuxversion/data/noarch/game/MonoGame.Framework.dll.config
./stardew-valley/linuxversion/data/noarch/game/MonoGame.Framework.dll.config.linux
./tooth-and-tail/winfiles/app/MonoGame.Framework.dll
./tooth-and-tail/winfiles/app/MonoGame.Framework.xml
./dust-aet/data/noarch/game/MonoGame.Framework.Net.dll

[flibitijibibo]

Right, AVNT... will have to dig that thing up from the grave once FACT is done. I think it's been like 3 years since I updated that poor guy.

Rogue Legacy should have a beta branch on Steam called 'fna-unstable' if you bought it from there. I thought Capsized was updated as well but maybe that was Steam only, will have to check my Humble package.

Luckily all the MonoGame.Framework.Net DLLs are total stubs and don't actually do anything, and indicates that they're on FNA.dll instead.

[rfht]

My copies of Rogue Legacy, Capsized, and Tooth and Tail are from gog. Maybe that one is behind...

[flibitijibibo]

I believe Tooth uses MonoGame on Windows for some reason... I think Andy was pretty strict on having a D3D path for that platform. We have D3D in FNA now, I should bother him about that. Linux should be FNA though, but FMOD will get in your way over there.

I gotta figure out a quick way to do GOG uploads. Steam has a quick uploader, I have contacts for Itch/Humble uploads (both of which have quick paths), GOG at the moment is just FTP access for each individual title along with the whole packaging process they have so updates tend to be very very slow.

[rfht]

I heard that GOG is not optimal for developers/publishers in some regards...

Tooth on GOG actually doesn't come with a Linux version. Since it uses FMOD, there's not a great chance to get this to work on OpenBSD outside of me signing up with FMOD for a dev account and trying to compile from source. But that doesn't scale to the platform.

[flibitijibibo]

Oh weird, last time I checked they had multiplat builds working just fine... guess I should poke them about that too.