I've been working on a video project for a video game class I'm teaching, using footage from Night Trap.
The versions for Sega systems are stored in .SGA format, which is partially documented. I used the info at this page to write a tool that converts the video from the original Sega CD version into matching .AVI and .WAV files, and I added the footage for my video project. It looks fine, but if possible I'd like to use the higher quality footage from one of the later releases of the game. I have the Sega CD 32X and PC versions, but it looks like the 32X version is probably my best bet since the video files are basically same format at the Sega CD version, and I wouldn't have to write a whole new tool.
The problem is the video is compressed using an unknown scheme, which apparently nobody has managed to crack yet. Here's an example of the type of data seen in the video files. It's the first frame of 59392800.SGA, which is the main Night Trap title. It's a (mostly) black screen.
Data:
Code: Select all
81 04 00 58 00 00 07 08 01 01 24 14 00 00 03 00
00 FF 01 00 FF 01 01 01 01 01 01 01 01 FF 01 00
FF 01 01 01 01 01 01 01 01 FF 01 00 FF 01 01 01
01 01 01 01 01 FF 01 00 FF 01 01 01 01 01 01 01
01 FF 01 00 FF 01 01 01 01 01 01 01 01 C8 01 00
FF 01 01 01 01 01 01 01 01 00 00 00
Code: Select all
81 <-- Chunk type (Night Trap 32X Compressed Video)
04 <-- Stream number?
00 58 <-- Chunk length (88 bytes)
00 00 07 08 <-- Time indicator?
01 <-- Start column
01 <-- Start row
24 <-- Video width in tiles (36)
14 <-- Video height in tiles (20)
Code: Select all
00 00 03 00 00
FF 01 00
FF 01 01 01 01 01 01 01 01
FF 01 00
FF 01 01 01 01 01 01 01 01
FF 01 00
FF 01 01 01 01 01 01 01 01
FF 01 00
FF 01 01 01 01 01 01 01 01
FF 01 00
FF 01 01 01 01 01 01 01 01
C8 01 00
FF 01 01 01 01 01 01 01 01
00 00 00
Most of the bytes are < 128 (highest bit = 0). I'm guessing those are literal bytes, and the FFs and the C8 (highest bit = 1) are compression descriptors, but I don't know exactly what they're describing.
What's weird is that there's still a lot of repeating data. You'd think that all those strings of 01s would get compressed.
I was thinking this the compression used here is some form of RLE, but others have guessed that it's a variant of LZSS.
The max compressed size for each video frame is, if I've got it right, 8956 bytes, or 5 sectors (10240 bytes) on the disc, minus 12 bytes for header data and 1272 bytes for audio.
It'd be a lot easier to figure this out if I knew exactly what the data looked like after it's been decoded, but I can't get Night Trap 32X to run right in any emulators that allow me to view / dump the contents of the VDP or CRAM.
Can anybody offer me a hand on this?
EDIT 1:
I took some screenshots using Kega Fusion, and now I have some more info to add.
The video appears to be broken down into 4x4 pixel blocks. Each block seems to have a max of 8 different colors, which would be 3 bits per pixel. At 16 pixels per block, that would be 48 bits, or 6 bytes per block.
The frame above is 36x20 tiles, or 72x40 blocks. That's 2880 blocks. At 6 bytes per block, that's a total of 17280 bytes of uncompressed pixel data per frame.
Still haven't figured out how the data is being compressed, though.
EDIT 2:
I looked a little more closely at the blocks, and it looks like the game is using compression similar (or identical?) toMicrosoft Video-1. Each 4x4 block is subdivided into 2x2 blocks (quads), each comprised of two colors.