Replies: 2 comments 1 reply
-
Oh my goodness that's complicated. I'm not sure I can even handle that--I don't know where the animations are, for starters. |
Beta Was this translation helpful? Give feedback.
0 replies
-
Interesting writeup. What should these things eventually end up as? Ogg video? Bunch of PNGs? |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
A Guide to Liftoff.abz
The Liftoff.abz file is a collection of animations depicting various hardware components. The file contains an Animation Index followed by a contiguous block holding the Animations.
The Animations Index details which animations are contained in the file, and where to access their data. The Animations contain the actual data.
There are some gaps in my knowledge, like what the .abz suffix stands for. I'll come back and edit this post when I learn more.
The Animation Index
The file begins with the Animation Index. It is an array of index entries, one for each animation included in the file. The Animation Index tells the user where to find the data for each of the animations contained.
Each index entry is 12 bytes and contains (in order):
The offset is the animation header's location in the file, expressed as an absolute offset in bytes from the beginning of the file. The animation size is the length, in bytes, occupied by the animation data.
Unfortunately, the file doesn't track how many animations it stores.
Animation
Following the Animation Index is a block of Animation entries. Each animation is composed of
Animation Header
Each animation begins with the animation header, the neccessary data for decoding the animation. Its 30 bytes consists of, in order,
The name of the animation should give a superior description of the animation than the 4-character identifier. In practice, "sva", "svb", etc. is the common nomenclature.
What the next four bytes represent I can't decipher it from the name in the code ('OVL'). In liftoff.abz, the value is always "NONE" so no hints there.
The soundtrack IDs are used to identify music files to accompany the animations. There are two 4-character identifies to lookup audio accompaniment in a file (which file is unclear). These should trigger when the frame counts listed in the sound cues are reached.
The frame count describes how many animation frames (or cels, if you prefer to think of them that way) compose the animation. Each animation frame will have its own entry in the frame block, discussed later. Animation frames have a uniform width and height within the animation, as specified - in pixels - by the header's frame width and frame height values.
Next is the loop count. This is how many times the animation should play before terminating. All the values in the file are '1', but in implementation the games ignores this and loops the animations indefinitely.
Finally, there is the palette information. This defines the color space used by the animation. The palette size is the size, in colors, of the color space. The palette offset is the starting position of the palette in the global color space. The animation expects the palette to be exported to the global color space, occupying the range [offset, offset + size).
Palette
Immediately following the Animation Header is the Palette. It's the set of 24-bit colors which make up the color space used by the animation. The animation's header specifies how many colors are in the palette, yielding a size of: (palette colors) * 3 bytes.
Frames
After the palette comes the array of Frames which make up the animation. See the Animation Header's frame count for how many Frames are defined in the animation. Each frame is composed of a Frame Header followed by the image data.
Frame Header
The code suggests that the compression identifier is 0 for uncompressed data, and 1 or 2 if compressed using RIS's run-length encoding algorithm (RLED_img).
The size value is how many bytes of image data trail the header. If uncompressed, this should match (frame width x frame height) from the Animation Header.
Image data
The image data, in uncompressed form, should be (width x height) bytes of raw pixel data. Each pixel is an one byte index into the color palette. The offset defined for the color palette in the Animation Header is already accounted for in the pixel data.
Beta Was this translation helpful? Give feedback.
All reactions