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 
Otherwise, we must wait until there is a fix for Ventura 13.1 
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.
3 Likes
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
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.
2 Likes
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:
- Install the
dotnet-sdkpackage - Clone the repo
cd <repo-root>/FrankenDrift.Runner/FrankenDrift.Runner.Gtk-
dotnet publish -c Release -f net6.0 -p:Version=0.6.1(adjust version number as relevant) - 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).
3 Likes
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.
4 Likes
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.
3 Likes
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).
2 Likes
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.
3 Likes
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.
3 Likes
Wellā¦
Showing 25 changed files with 347 additions and 51 deletions .
ā¦yeah.
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.
4 Likes
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.
3 Likes
Thanks for keeping us informed