Multi-interpreters - which could handle Adrift 5 going forward?

Now that both Adrift 5 and Frankendrift are open source, I’d like to ask if it is realistic that any of the multi platform interpreters like Parchment, ElseIFPlayer, Lectrote, Gargoyle, Gelek Vanilla, ScummVM, Hunky Punk etc. could be made to run Adrift 5 games?

Or what would it take?
(for most games you don’t really need the map, music, text colors etc)

The codes can be found on Github:
Adrift 5: GitHub - jcwild/ADRIFT-5: ADRIFT: Adventure Development & Runner - Interactive Fiction Toolkit

Frankendrift: GitHub - awlck/frankendrift: Cross-platform frontend for the ADRIFT Runner
(Frankendrift is based on Adrift 5 source code but doesn’t need Infragistics libraries)

2 Likes

It’s great that they’re open source now! But that doesn’t mean that it would be straightforward to integrate into other multi-interpreters.

The first issue is that they’re .net based, and other interpreters generally aren’t. For desktop interpreters it would be easier to get .net and C/C++ code to work together, but it would be much more difficult for Parchment or other web interpreters. (I have considered it before.)

The second issue is that the user interface models probably aren’t very compatible. The other multi-interpreters can work because Glk is enough of a baseline that they can approximately support most of the features of all the formats. But if there was a console mode interpreter for Adrift then that sort of interface could be adapted to Glk.

2 Likes

It is exactly this kind of information I am after in addition to information about specific multi-interpreters so thanks!

Desktop is certainly much better than nothing, especially if they are cross platform.

I’m not a programmer so I might be misreading this but I think graphics, music and text formatting are less important. A game like Skybreak or Oct. 31st would work well without that.

Isn’t Frankendrift a console interface despite being 96% Visual Basic .net?
(Sorry again, don’t know much about programming except for c64 basic :smile: )

After taking a look at Frankendrift, yes that’s the sort of interface that would be adaptable to Glk. (At least the main window, but not any extra side windows.)

To be honest, I wouldn’t want to touch the Adrift code itself, as it’s not very accessible; the runner is an 8K line file that is not very thoroughly commented. Though considering that file isn’t in Frankendrift, maybe it’s more the interface of the runner than the actual interpreter? I don’t know…

Anyway, Frankendrift looks like a much more approachable codebase. Frankendrift.Runner looks well organised. I could see it being possible to port Frankendrift.Runner to use the Glk API rather than Eto.Forms. If that can be done then it’s probably possible to bundle it in with some of the multi-interpreters.

2 Likes

This is great news. Frankendrift has a very high compatibility because it is based on the source code unlike Fabularium. Frankendrift is at version 0.6.1 but I think that it is already completely playable minus media and formatting issues. @ArdiMaster (behind Frankendrift) might be able to give some advice at some point(?). For experimenting with multi-interpreters, the current version should be fine I think, as several games are highly playable with it.

Plugging FrankenDrift into Gargoyle would probably be the most straightforward (least un-straightforward?) since Gargoyle is, in essence, just a loose conglomerations of Glk-enabled interpreters that all happen to use the same Glk implementation. It’s very much possible to use P/Invoke to call the relevant functions from libgarglk.dll, but you’d still be increasing the install size of Gargoyle by probably 140MB or so due to bundling the .NET runtime. (And doing that is also a pain on anything but Windows.)

I have no idea if that’s possible once you add Emscripten into the mix, so attaching it directly to Parchment might not be possible for now. Also, again, the download size…

3 Likes

Blazor can run .net code in WASM, but I suspect it might be better in this case to try a VB.net to JS transpiler.

But I’m not volunteering! Too much already on my plate. But if anyone else wants to try…

1 Like

I’m completely in favor of integrating an Adrift 5 interpreter with Gargoyle. I’d worry about issues like runtime size/platform support later. Worst case, the Adrift interpreter can be disabled in certain circumstances.

That being said, I don’t know C# at all, so I’m in no position to do the work. I’m happy to do anything on the C++/build system side to support the effort, though.

4 Likes

I’d also like to see an ADRIFT 5 interpreter that is linked to standard GLK, since both Frankendrift and the ADRIFT runner are inaccessible with screen readers. Hell, I’d compile it myself, but compiling programs from source on Windows is a bit out of my comfort zone. (Mainly because I don’t know C/C++, so when the shit hits the fan, I don’t know what broke.)

At least compiling programs on Linux is easy enough.

2 Likes

Can we expect the people behind gargoyle to read this, or should I contact somebody? I would really love this to happen. The only thing I can probably help with, would be testing.

Chris is the guy behind Gargoyle :wink:

1 Like

Thanks. I know a non-IF guy who knows some C# but it might be a huge task(?) So it would be nice to know if it is worth it.

Do you know if anyone has made a survey about interpreters? I have seen some surveys were made in the IF community but I don’t know the contents.

Abstractly speaking, converting an interpreter to use Glk isn’t a really difficult task, depending on how “fancy” the screen manipulation is. For basic Glk support, at any rate, it’s not particularly hard at all. Briefly, you have to replace the input/output functionality with Glk equivalents. If the interpreter does do a lot of fancy stuff, then you also have to determine how to map that to Glk, or which parts you can just ignore.

Some difficulty lies in the fact that C# doesn’t understand C, and Glk is exposed via a C header. However, it looks like there’s a tool which can generate C# code from a C header, which should really ease the process.

To provide an anecdote, a while back I ported the old ScottFree interpreter to Glk in an afternoon. It’s surely simpler than Adrift, and I had good working knowledge of Glk, but I think a sufficiently motivated C# developer could get something working without much trouble.

1 Like

Ok, so unless there are some unforeseen problems it isn’t a huge task for an experienced C# programmer. The guy I know might not be interested so if anyone reading this wants to look at this, it would be great.

I have a functional prototype but it needs some more work before being fit for inclusion, I think.

1 Like

4 Likes

Wow, great work!

So before you shared that, I had started working on this, which was intended to be a wrapper for Glk so that we could make a generic GlkRunner project which wasn’t hard coded to any particular Glk implementation. Then just like you have Runner.Win, we could have Runner.Garglk, Runner.Spatterlight, Runner.WinGlk etc which would specify which Glk implementation DLL to load (and run any implementation specific code, like setting the window title).

I think the general dynamic loading of a Glk DLL is working, but I couldn’t figure out how to provide glk_main to the DLL. Perhaps the only thing that might actually be helpful to you would be the SetGlkDllName function.

I think we definitely do want to make it Glk-implementation-agnostic. Gargoyle is great, but I don’t think it works that well with screenreaders, whereas Windows-Glk is better in that regard. So being able to connect it to various Glk implementations, even if some custom code is still required, would be very desirable.

1 Like

That is so cool.

My favourite Adrift game in the soothingly familiar Gargoyle window. Great!

1 Like

Yeah, that would be ideal. One roadblock we might run into though is that saving and restoring is implemented fairly deep within the guts of the original Adrift source, so for now I’m relying on garglk_fileref_get_name to avoid having to rewrite that part. I don’t know how common this function is in other implementations.

I don’t think you can, really. The entire native-library-interop rigmarole needs to be initiated from the .NET side of things. For connecting to GarGlk/Gargoyle, I reimplemented the main.cpp file that is usually compiled into every Gargoyle interpreter. (WinGlk seems to be most suited for this role reversal, expecting you to provide the top-level main function altogether.)

If you’re interested, my code is currently on a separate branch on the FrankenDrift repo: GitHub - awlck/frankendrift at garglk.

Thanks, that’s very neat! I was looking at how GtkSharp supported multiple platforms and library file names, but this seems a lot more straightforward.

2 Likes

It’s becoming more common, though other implementations may call it something else instead. See Add support for the Garglk extension garglk_fileref_get_name by curiousdannii · Pull Request #36 · erkyrath/remglk · GitHub I think we’re moving towards most interpreters switching to glkunix_fileref_get_filename (even on non-*nix OSes).

1 Like