HELP C devs - Android: Blorb image & sound saving in RemGlk

If any reasonably competent C programmers out there can help me, I have an urgent request if you can take an hour or three to code in the next few days. It will further along the Android port efforts. I want to try to keep some of the “basics” in C for organization reasons and cross-platform (non-Android). For various reasons, RemGlk has become the center of my development attention - but my C code skills are rather terrible - which is why I’m asking for C programmer help.

RemGlk just had code added to recognize image files (jpg/png) in Blorb files. The very latest C code is up here:

Now here is what it has; It has an option to take as main() args[] one called “resourcedir” - and as I understand it, it merely passes that string along as a reference to what it finds in the Blorb file.

My Request

Can you fork RemGlk on Github and create a branch that saves (writes) all blorb elements into the arg[] “resourcedir” path? Right now it doesn’t write them to disk (by design) - as it expects outside code to independently do that. My request is integrated C code in RemGlk to save everything out of the blorb that it gets - sound, images, game data, like you are extracting a zip file into a directory.

Your code needs to be MIT licensed by you, the author, to fit into RemGlk’s existing license: Obvious code to save Blorb elements exists in Gargoyle and such - but you have to make sure it’s MIT licensed (or Apache license, BSD license, or Public Domain) if you copy/paste in code from elsewhere. If you do copy in code from elsewhere, please indicate where you found it.

If you are looking for a game datafile that has a lot of blorb elements, I think Alabaster.gblorb is a good one:

Once the code is finished I will do my best to maintain it as a “patch” to RemGlk for the app I’m working on. Your help would save me frustration of dong C code and keeping things at the layers of the app that I want. Thank you!

Do you care about adaptive color palettes, Z3 sound looping data, and such? Or just images and sound files?

If they are resource blobs, you could just extract them to a .bin raw file if there isn’t a standard filename convention - and even extract the game binary data itself (.z8 / .ulx etc) - I could comment out or otherwise remove that extraction later down the road if it that data proves of no use. Does that make sense? But I think the current ‘absolute need’ is the sound and image resources.

BTW - I found there are like 3 different sizes of Alabaster.gblorb to test against, the 3.4MB one seems to have 29 asset chunk counts of which 26 are resources. Thank you!

I wrote this quickly as a separate “library” since I’m not very familiar with the RemGlk codebase. It exposes a single function:

int unblorb(const char *blorb_path, const char *resource_path);

This extracts all the resources from the blorb_path and tosses them into the directory resource_path. Files are named “resource_path/chunk_name/resource_number.extension”, so for instance the main executable in a Glulx blorb is named “resource_path/Exec/0000.ulx”.

Does this work for your purposes? (The code is also a huge mess; if I get a chance I’ll go through and make it presentable.)
unblorb.h (109 Bytes)
unblorb.c (7.01 KB)

I’ll look at it shortly and let you know, thanks a lot!

This is working! Since you made it self-contained I integrated it outside of RemGlk so it isn’t linked into every individual interpreter. Compiled fine with the Android NDK 13 GCC cross-compilers. I moved the vars in the for loops to before the loop to compile to whatever non -C99 I had set. Thank you.

Quick and dirty C code follow-up request: The code Daniel Stelzer shared - how do I get the “P” in PIct path to be lowercase? And for filenames not to be 0001 with 4 padded digits but natural digits? Bonus: ‘jpeg’ with an extra character in that extension. As that’s how RemGlk generates them and want to get them matched. Thank you.

Making “Pict” and the others lowercase is easy enough. (Do you want Snd_ and the others lowercase too?) “Natural” digits and four-character extensions are a bit trickier because I was lazy and used a fixed-size buffer rather than calculating the length properly. The right approach now would be to redo it with dynamic strings and such, but I’ll probably just assume that there will never be over 99999 pictures in a single blorb and bump that number up if it ever becomes insufficient…

I’m going to assume as RemGlk moves foward the Snd will be lowercase. As it established lower on the Pict

(That one could also become “snd” or "snd ", since the tag inside the blorb file is "Snd " with the space at the end. But easy enough to change.)

I found a case where this code fails with it’s 4-digit filename assumption. City of Secrets v3 - has graphic images that start with 10000 . I think I managed to find the correct ‘4’ integer in the code and upped it to 6. But I would still prefer it use the convention of RemGlk which doesn’t use leading zero padding at all and just the dynamic string.