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
Gargoyle now has glkunix_fileref_get_filename: it’s not in the most recent release, but I added support in the master branch a few months ago. Up to the minute Windows builds can be downloaded from the MinGW workflow, so it should hopefully be easy to give it a test.
1 Like
This is so great Adrian - what should ADRIFT do without you? 
I posted the following part in another topic but realized it belonged here. Sorry for the confusion.
Yes, that would help a lot! Just make sure that taf-files also work and keep in mind that Adrift 4 games play very badly in Adrift 5, so ideally Gargoyle will check if the taf-file is Adrift 4 or 5. If it is Adrift 4 then it is important to use the old interpreter Scare.
So that may even help porting Frankendrift that you can ignore the part that converts Adrift 4 games into Adrift 5 games. The “4-to-5”-conversion never worked well and gives the impression that Adrift 4 games are more bugged than they are, so I really hope you will skip the conversion or at least hide it. The conversion is based on the selected Adrift 5 library used when creating games, so whenever that library is updated, the conversion will be different. If you drop the conversion, you won’t even need the library because you only use the library when creating games. The library is only needed by the Interpreter when you convert Adrift 4 games to Adrift 5.
So skip the “4-5”-conversion if possible and apply Scare on Adrift 4 games.
As you noted, the conversion requires Adrift 5’s StandardLibrary.amf file to be present. I never bothered to include that file with the FrankenDrift packages, so the conversion is effectively disabled unless someone went out of their way to download that file and put it in the right place.
But yes, at some point I’ll probably go through and tear out the conversion code altogether.
1 Like
As long as we’re on the Adrift/Blorb topic, there’s a wrinkle here that will need to be addressed.
It appears that Adrift files are not valid Blorb files. The most authoritative Blorb code (from @Zarf) fails to load them properly. This is both in gi_blorb (for Glk) as well as blorbtool.py, which uses Python’s IFF parser.
In the gi_blorb code, the failure is the condition if (nextpos > totallength), which implies that a length somewhere is being written incorrectly, causing the file to overrun. Basically, there’s an IFF chunk which specifies a size that runs beyond the end of the file.
After a quick check, it seems that the size of the whole file (i.e. of the overall FORM chunk, specified by the 4-byte value at offset 4) is written incorrectly. The value here should be the size of the file minus 8, but Adrift Blorbs have a smaller value. As an example, Anno 1700 is 880810 bytes long, but the FORM size is 880004.
The header validates as Blorb, so in Gargoyle’s case, it tries to run it as a Blorb file; but that fails when it can’t parse it. Even if/when Gargoyle supports Adrift 5, its Blorb files won’t work, as they will be considered invalid.
The Blorb specification notes that Adrift files can have either “.blorb” or “.adriftblorb” extensions. “.blorb” can’t be unilaterally associated with Adrift as that would break other game types, but if necessary, Gargoyle could add a special case for the “.adriftblorb” extension, and avoid the Blorb code for them.
An alternative would be to add custom IFF reading code to Gargoyle which short circuits as it loads chunks, stopping if it finds an Exec chunk of type ADRI… but I’m not sure how much I want to do that. It might be the only way to support the invalid Adrift files without requiring a file renaming, though.
2 Likes
This is correct. When I implemented graphics and sound into the FrankenDrift Glk port, I ended up reading in the Blorb file, fixing the length data, writing it to a new temporary file, then feeding that to giblorb_set_resource_map. Ideally we could find a solution that would somehow resolve both of these issues.
1 Like
Sorry, I don’t know if this is helpful but in the original blorb specification, Plotkin writes this:
ADRIFT 5 (see http://www.adrift.org.uk/) also uses Blorb, albeit with an extended format list.
And also this:
### 14.5: ADRIFT 5 Compatibility Issues
ADRIFT supports more media formats than Blorb, but has adopted Blorb as a packaging format. To permit this, the following chunk types may be used in ADRIFT blorbs:
For images: 'GIF '.
For sounds: 'WAV ', ‘MIDI’, 'MP3 '.
ADRIFT Blorb files should use MIME type application/x-blorb;profile="adrift". The filename suffix should be “.blorb” or “.adriftblorb”. [“A” or “AD” is unfortunately not a unique prefix when it comes to IF systems!]
And this:
- So why does ADRIFT get a bye on these format decisions?
Game authors and interpreters need to agree on what formats they will use. Z-code had no cross-platform agreement when Blorb was invented, and Glulx was created to use Blorb, so Blorb’s role for them is normative. GIF and MP3 are not going to become standard Blorb format types.
ADRIFT, in contrast, already had cross-platform interpreters when it adopted Blorb. Blorb can therefore be valuable to ADRIFT as a packaging and metadata format, while taking a descriptive role on media formats. (The alternative would be to disallow ADRIFT Blorb files, which seems silly.)
[It is worth noting, however, that IF interpreters are often ported by adapting existing IF display code. IF interpreter ports can also be based on Glk libraries and the Glk API. Both routes entail the Blorb standard media format list, to some extent. Therefore, game authors have some reason to consider sticking to those formats.]
1 Like
I think the issue is that the code which calculates the length of a FORM ignores the chunk headers and padding. So if you add 8 for every chunk and any padding, would the length be correct?
My download of Anno 1700 is different to yours… the file is 865004, and the FORM length is 864204. But that’s still a difference of 792, which is far too much for it just to be the chunk lengths and padding.
Ah, it’s hard to follow what the code is doing (VB.net is weird), but it’s also excluding the content length of the IFmd chunk. I haven’t precisely calculated everything, but I think that would make up the balance of the difference.
If I’m right, then we could programmatically correct the length of an Adrift Blorb, so that we could still detect other malformed files.
1 Like
If it is crucial, Finn Rosenløv might be able to get some information from Campbell Wild. I’m sure that Campbell will be glad to hear that you are working on an ADRIFT 5 interpreter for Gargoyle. But you would have to formulate the question as neither Finn or I are programmers.
FORM length 864204 +
FORM header 12 +
RIdx header 8 +
ADRI header 8 +
JPEG header 8 x 3 +
IFmd header and content 745 +
padding 3
= 865004!
So yes, we should be able to automatically correct the Blorb length.
I’ve raised this as a bug on the Adrift Github: Blorb FORM length is incorrect · Issue #12 · jcwild/ADRIFT-5 · GitHub
2 Likes
Would 4-5 conversions work if the file was included? Is there a reason the file couldn’t be included?
1 Like
Adrift 4 games tend to play better in SCARE than they do in the ADRIFT 5 runner (and thus in FrankenDrift)
1 Like
As @ArdiMaster said, Adrift 4 games play much better with Scare. Actually, most adrift 4 games cannot be completed when played with the Adrift 5 interpreter! Frankendrift is expected to have exactly the same problems.
So honestly, I hope you will not include the conversion or make sure that all Adrift 4 games are started with the Scare interpreter and if you really want to include the conversion you should put up a big warning sign in front of the player and recommend that they only use Frankendrift for Adrift 5 games as the game is most likely not completable using Frankendrift / Adrift 5 Runner.
[ above I have assumed that the name of the implemented interpreter in Gargoyle will still be named Frankendrift]
Ah, I’d assumed that if it was an official part of Adrift 5 that it would be mostly functional. If Scare is better then great.
1 Like
Just saw that .Net 7 allows you to run any console-based .Net code in the browser, without using Blazor. This looks promising for getting Adrift working in Parchment or Lectrote.
It would need the Glk runner to be generic not just for different .DLL based Glk implementations, but also for one that could be imported as a JSImport. So a few Glk function calls may need to be made async (using a .Net Task?)
1 Like
Unfortunately it looks like we’re going to have to wait for .NET 8 to get Adrift 5 running in the browser. So I’m going to focus now on polishing the Glk implementation for Gargoyle.
2 Likes