Well, I sure neglected this, didn’t I? I have very good reasons for that, but none of which I really want to share (suffice it to say, when the in tray needs guy ropes to secure the contents, time spent looking at old multimedia titles has to be reduced).
I thought I’d jump back to the very first US release, which was one step up of the original, Hypercard based setup. As a result of its origins, it uses an early variant of the method used to store images and text scripts (off3 rather than off4 – which actually represents 300 vs 400, but that’s by the by).
Just treating this as a standard off4 is immediately problematic, as it’s quite clear that the image data is not present in the file at all, the filesize is way too small. Thinking I’d have to reverse engineer the whole thing, this is where I got stuck. Then I remembered an old trick – sometimes the demos have more debug info than the production builds, usually because they’ve been put together in a rush. Sure enough, in the marketing file that contains the purcahse info, a mysterious TMPL file was present with this info:
Offset Version (300 for now)DWRD,
Block Word Size (usually 6, can be 12 or 18)DWRD
Number of Art StripsOCNT
Strip Type (1 = RLE)DWRD
Strip Res ID DWRD
*Low Cast Member (Maps To frame 0 of strip)DWRD
High cast member DWRD
Number of FramesOCNT
Block Offset of Frame Info (0 = empty frame)UWRD
6-byte blocks (1-based indexing)LSTB
Frame Offset, or FlagsUWRD
Bounds, left DWRD
Bounds, top DWRD
Bounds, right DWRD
Bounds, bottom DWRD
Count, or Cast# DWRD
So this appears to be a long and complex list, but essentially we can take this apart step by step. The format has been designed to be more flexible than needed, and I can see why they cut a lot of this out in later versions. Each file can specify slightly different compression sizes, and make reference to multiple ‘art strips’ – which are pointers to another file in the RLEP resource list. Each list can specify different compression types, but the main one is the RLE we already know. This then points to the filename of the RLEP file with the info, and where the first frame is in the file. The rest is reasonably self explanatory, listing where the frames are, any offset for the data from the RLEP, with the flags and dimensions as before.
I haven’t yet incorporated all this into code, because I haven’t begun to look at the RLEP but it sounds very similar to the original setup, with lots of little loops. Should be fun to actually get this in, then we should eb able to browse all YDKJ 1-4 assets, and start thinking about drawing them together into an engine.