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)
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.
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 )
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.
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…
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.
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.
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.
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.
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.
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.
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.)
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.
)
