The FrameDataOffset can be obtained from the first frame entry, FrameEntry0, specifically offset 8 bytes from the start of the entry:
bits 30-0: Offset to frame data
bit 31: 0=Compressed (RLE), 1=Uncompressed
Once you have this value (FrameDataOffset) you can subtract FrameLookupOffset from it to obtain the size of the frame lookup table.
Looking at DEMB1A1.bam from MISCAnim.bif you can see the following:
- The framelookupoffset is 2704 (0x00000A90)
- The framedataoffset for frameentry0 is 2956 (0x00000B8C)
- Which gives us 252 bytes for our frame lookup table (2956 - 2704)
(However, each cycle can have a variable length of frames in it and the framelookuptable is a word sized array (2 bytes long) for each frame pointer)
Reading FrameLookupTable Frame Sequence:
To get the sequences of frames that play in a cycle:
- Read each cycle entry and get the cycleindex and cyclecount.
- Take the cycleindex and multiply it by 2 to get the offset in bytes to read from start of the framelookuptable and add the framelookupoffset value. This gives us our start of the cycle sequence.
- Read cyclecount x 2 amount of bytes to get the full sequence size for this particular cycle.
Example: (cycle0)
CycleEntries start at offset 1644 (0x0000066C) which is also the start of CycleEntry0
- CycleEntry0's data is 0E00 0000
- Count of frame indices in this cycle is (0x000E) 14
- Index into frame lookup table of first frame index in this cycle is (0x0000) 0
So framelookupoffset + (0 x 2) = 2704 + (0) which is the start sequence of cycle0
we read count of frames x 2 (14 x 2) = 28 bytes and we get this data:
0000 0100 0200 0300 0400 0500 0600 0700 0800 0900 0A00 0B00 0C00 0D00
Remember each entry of this sequence is a word length or 2 bytes long (ive put a space between each word value)
the values in that sequence directly refer to which frame (frame entry->framedataoffset->convert to bitmap) to show: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13 - so we have 14 frames in this cycle, starting at frame0 and ending at frame13
Example: (cycle1)
- Cycle1's data is 0E00 0E00
- Count of frame indices in this cycle is (0x000E) 14
- Index into frame lookup table of first frame index in this cycle is (0x000E) 14
So framelookupoffset + (14 x 2) = 2704 + (28) = 2732 which is the start sequence of cycle1
we read count of frames x 2 (14 x 2) = 28 bytes and we get this data:
0F00 1000 1100 1200 1300 1400 1500 1600 1700 1800 1900 1A00 1B00 1C00
Again we have 14 frames to show, starting at frame 15 and ending at frame 28. As i mentioned above each cycle can have different amount of frames in its lookup sequence.
DEMB1G1.bam has a lot more frames, more cycles and more cycle sequences with different lengths, as can be seen in this wip screenshot from a program/utility i am writing (total column indicates no of frames in cycle animation sequence)
One oddity i noticed when looking at the data for all this, was that some frames dont appear in any cycle animation sequence. There are more frames than are actually used. in the above examples frame 14 is not used in cycle0 or cycle1, same with other bam files i have looked at - and bamworkshop also indicates this - shows all frames available, but for the defined cycles, some frames are not included. Strange? or am i missing something?
