Multimedia loading fails with latest Gargoyle about hugo-unix

[curiousdannii]

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]

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]

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.