search

hugoif / hugo-unix

A fork of Bill Lash's Hugo port, originally hosted at https://bitbucket.org/0branch/hugo-unix. Further info and downloads: http://www.generalcoffee.com/hugo/gethugo.html.
BSD 2-Clause "Simplified" License
7 stars 5 forks source link

Multimedia loading fails with latest Gargoyle #4

Open cspiegel opened 2 years ago

cspiegel commented 2 years ago

The Glk port, to provide graphics and sound, writes out individual PIC and SND files, as suggested by the Blorb specification, and supported by Gargoyle (and xglk should at least support PIC files).

However, it also uses Glk to open these files, but Glk doesn't provide the ability to open arbitrary files. It used to work with Gargoyle, but when I synced Gargoyle with the latest cheapglk, things broke: this is because cheapglk, as recommended by the Glk spec, adds extensions to all files opened by it. Specifically for data files, .glkdata is added, meaning files are called something like PIC0.glkdata. As such these files no longer have valid names for Gargoyle (or any other implementation which uses the suggested names).

I've got a hacky solution in a pull request: garglk/garglk#649. Part of the issue is that it requires the non-standard glkunix_stream_open_pathname function to directly open a file. This is part of the glkunix startup, not Glk itself. Since this repo is called hugo-unix, that may not matter, but it's worth pointing out. The function does exist in cheapglk, xglk, glkterm, remglk, and Gargoyle, at least.

The other thing is that, in my fix, I'm guarding this all with #ifdef GARGLK since it deviates from upstream here. However, it'd be better to get a proper upstream solution in place that works for all (Unix) Glks. If we can assume that glkunix_stream_open_pathame is OK to use, then I think my approach is no worse than the existing one. I use stdio to write out the files, to guarantee working filenames. This avoids any mangling that may be done by the Glk implementation.

My use of the hugo_path_to_game is also gnarly, and should be improved if it's going to actually be used upstream.

curiousdannii commented 2 years ago

Another option than writing and reading temp files would be to construct a blorb directly in memory. I feel like that's slightly more reliable. And for Emglken it should have higher performance as it wouldn't need to hit the FS layer so much.

cspiegel commented 2 years ago

That would definitely be an improvement. For Gargoyle I took the path of least resistance, simply fixing what was already there, but the dumping of PIC and SND files onto the filesystem is awful, for sure.

The Hugo code does "on-demand" loading of resources, though: when a resource is loaded, it generates a new ID dynamically for that particular resource, and stores it. The offset in Hugo's resource file is used as the key, effectively, so future loads will return the same ID in the same game session, but the next time you play it could be a different ID, depending on which order resources are loaded.

For that reason I'm not sure how possible it is to build a Blorb file up front and load it, and a comment in hemedia.c seems to support this:

There are two options to do resources for Glk (Gargoyle). A is guaranteed to work. B is not portable, but works for gargoyle and probably most of the other non-PDA glks. a) put each resource in a standard named filed (PIC%d or SND%d) b) build an actual BLORB file Because Hugo resources live in many files, and there is no way to know which ones they are before it's too late... I go with option A although it does tend to litter a lot of files... A smarter way would be to create the Blorb file, then recreate it every time more resources are discovered...

The last sentence there is key: recreating a Blorb as new resources are encountered... well, that's not particularly impossible, I suppose, but is a lot more work than just dumping the PIC/SND files, or building a Blorb once and being done with it. If nobody wants to do the work, I'll probably take some time, at some point, to look at it.

curiousdannii commented 2 years ago

The blorb resource numbers could be a mix of file numbers and hugo resource numbers (16 bits for each), or a hash or something. It could be altered on the fly by replacing the various arrays in giblorb_map_struct.

Anyways, I don't have time to look at this now, but maybe in the future.

cspiegel commented 2 months ago

This should be fixed in PR #7. It requires the new GLK_MODULE_GARGLK_FILE_RESOURCES extension, but will fall back to PIC and SND loading in its absence.