"FrankenDrift": Play ADRIFT games on Mac and Linux

Okay, I guess we need the developer to look at it. Thanks for reporting.

BTW, it was very nice of you to consider testing an Adrift game. Technically, it is possible to set it up so you play online - you just need a code from the author so the game does not count as released. I don’t know if the author would like this, but you lose the map feature and can’t do transcripts, though you can copy/paste text from the browser into a text document.

The game should also respond quickly. You can check if any of the two servers here run at decent speed for Achtung Panzer: Achtung Panzer! - Details (ifdb.org)

I sometimes suspect that the UK one only runs fast when viewed from Europe but I am not sure.

If the author is interested, I can help him with the technical setup, just tell him to talk to Denk :slight_smile: Otherwise, we must wait until there is a fix for Ventura 13.1 :frowning:
It would definitely be interesting to try!

1 Like

We are still investigating this, but it looks like the issue is likely related to the “Ban Comic Sans” setting. You may want to try disabling it if you are experiencing similar issues on macOS.


Some time ago @dfabulich proposed that I contributed to get Frankendrift running online (as part of Parchment most likely) but I never got around it. Thus I recently tried to load Frankendrift into Visual Studio 2019 but I quickly ran into problems as I am quite a novice. EDIT: Updating Visual studio to the 2022 version solved all problems :slight_smile:

So i put it aside for a while but may want to try again. However, first I have to ask @ArdiMaster and @Dannii if I can contribute in any realistic way with my limited experience?

I don’t mind “just” being a tester or similar but I can also try to improve on the programming side of things but I might need some help to at least get started. I wouldn’t like to slow you down, but to help you reach your goal faster.

So how could I contribute (if at all possible)?

I don’t think there’s much you can test right now, but maybe somebody could screenshare with you and do some pair programming?

1 Like

I made good progress, maybe about 40% of the way there. The C# side of it is mostly complete already. I’ve had a couple of weeks not in a programming mood, but I’ll try to get back to it soon. Probably the most helpful thing will be testing it once it’s ready.

1 Like

That’s great! Feel free to contact me directly when it’s ready.

I’m interested in building a package for this in NixOS/Nix. Are there build instructions for this anywhere? I saw in the repo build scripts for the windows and the mac variants, but couldn’t find anything for the Gtk version.


Hm… I don’t think I’ve ever written down packaging instructions for Linux, I’m afraid! I’ll add detailed instructions to the repo, but here’s the gist of it:

  1. Install the dotnet-sdk package
  2. Clone the repo
  3. cd <repo-root>/FrankenDrift.Runner/FrankenDrift.Runner.Gtk
  4. dotnet publish -c Release -f net6.0 -p:Version=0.6.1 (adjust version number as relevant)
  5. Package up the contents of the folder <repo-root>/FrankenDrift.Runner/FrankenDrift.Runner.Gtk/bin/Release/net6.0/publish

This produces a build that relies on a system .NET runtime (the dotnet-runtime package in NixOS).


The process is a little different with Nix haha, but your steps were enough for me to make it work. I’ve just submitted my PR for the nixpkgs repo. Great work by the way. I can’t post links but the PR is at NixOS/nixpkgs/pull/233486 on github.


So dotnet now has a native AOT mode which compiles to native code and doesn’t need a dotnet runtime. It also allows you to statically link another library. Which is what we typically do with Glk libraries! So turning those settings on may make it much simpler to get Frankendrift into Gargoyle. The final Frankendrift executable is about 80MB but having one file is a lot simpler than worrying about distributing and linking the dotnet runtime.

@cas Does Gargoyle normally statically link libgarglk on Linux/MacOS, but dynamically on Windows? I think we can handle that with conditional compilation.


Thanks for the heads-up!

When using that new method (and also tossing out the problematic reflection-based XML deserializer that is only used for parsing the iFiction record anyways), the executable comes out as a more manageable 8.57MB on Windows, dynamically linking to libgarglk.dll.

That is my understanding, yes. Not having to alter the Gargoyle build process to use dynamic libs everywhere removes a major obstacle from this project. Now “all” that is left to do is teach CMake to build a .NET project…

Edit: I have a working version on this branch here: GitHub - awlck/frankendrift at GarglkAOT. Building it requires the .NET 8 preview; I won’t be merging this to master until .NET 8 has its full release (referencing it at all breaks the project in the current non-preview version of Visual Studio).


The Windows builds I provide are shared, and the Mac ones are static, yes.

The Linux AppImage is static, but that’s not a “normal” version. Shared vs static is a compile-time option which can be set by individual distributions. Arch’s AUR package, for example, uses the default, which is shared, but Ubuntu specifies static.

I think we’ve briefly discussed shared vs static libraries for Gargoyle, and the only real reason to use shared libraries is to avoid the duplication; on Linux x86-64, there around a 15MB difference, uncompressed, of shared vs static, after installation. Not huge but not trivial (or maybe it is trivial in this day and age, I don’t know).

Anyway, since it’s selectable at build time, Gargoyle can be tailored to whatever is necessary.


I thought there must be some big libraries being linked in that weren’t really needed, but I didn’t know how easy it would be to remove them. Great to hear it was pretty simple and also had such a big impact!

1 Like

The major fly remaining in the proverbial soup here is that .NET Native AOT does not (currently?) support cross-OS compilation. That is to say, the Windows FrankenDrift executable must be compiled on a Windows machine, while the rest of Gargoyle very much does not want to be built on Windows.

1 Like

This is true, but it’s only true because I’m not at all familiar with doing development on Windows. At this point I don’t know how much work it’d be to get the build system working well on Windows, but I’d certainly accept patches to do so.

Not that I’m requesting that you (or anybody) put work into Gargoyle’s build system; just a note that Gargoyle isn’t inherently against the idea of building on Windows.



Showing 25 changed files with 347 additions and 51 deletions .


So long as we stick to Clang-for-Windows (which will accept most GNU syntax extensions but produces binaries compatible with MSVC) it’s not as much work as I had feared. Achieving full compatibility with MSVC would be neat but also probably way more work than it’s worth.


Well .NET 8 is officially released, and if you’ve been following along, work is progressing on preparing Gargoyle for Frankendrift.

But .NET 8 doesn’t yet do what will be needed for getting Frankendrift to run online, so we’ll likely be waiting till mid next year at the earliest for that.


Thanks for keeping us informed :slight_smile:

A Mac problem was reported here:
Link to review