Not very helpful, but it has a few clues in it- We do .not. have some kind of magical data compression machine that is able to squeeze
hundreds of megabytes of mesh/texture and sound data into 96k. We merely store the
individual steps employed by the artists to produce their textures and meshes, in a very
compact way. This allows us to get .much. higher data density than is achievable with
normal data compression techniques, at some expense in artistic freedom and loading times.
- .kkrieger is not written in 100% assembler/machine language. Not even nearly. Like the
vast majority of game projects being developed today, .kkrieger was mostly written in
C++, with some tiny bits of assembler where it is actually advantageous (notably, there
are a lot of MMX optimisations in the texture generator).
- A kilobyte is, historically, defined to be 1024 (2^10) bytes, not 1000. Thus .kkrieger is
a game in 96k even though it's actually 98304 bytes.
- The concept of the texture/mesh generators was developed by fiver2. We do .not. want to
claim that the techniques we used to develop .kkrieger are new inventions. It´s rather a
selection of useful operations and their parameters to optimise the results.
Here's the first issue, look at the bottom of the article for the other linksThe Art of Demomaking by Alex Champandard
The Art of Demomaking - Issue 16 - The Final Product
12-08-1999
The Art of Demomaking - Issue 15 - Music And Synchronization
11-29-1999
The Art of Demomaking - Issue 14 - Perspective Correct Texture Mapping
11-22-1999
The Art of Demomaking - Issue 13 - Polygon Engines
11-15-1999
The Art of Demomaking - Issue 12 - Span Based Rendering
11-08-1999
The Art of Demomaking - Issue 11 - Particle Systems
11-01-1999
The Art of Demomaking - Issue 10 - Roto-Zooming
10-25-1999
The Art of Demomaking - Issue 09 - Static Texture Mapping
10-18-1999
The Art of Demomaking - Issue 08 - Fractal Zooming
10-11-1999
The Art of Demomaking - Issue 07 - Bump Mapping
10-04-1999
The Art of Demomaking - Issue 06 - Bitmap Distortion
09-27-1999
The Art of Demomaking - Issue 05 - Filters
09-20-1999
The Art of Demomaking - Issue 04 - Per Pixel Control
09-13-1999
The Art of Demomaking - Issue 03 - Timer Related Issues
09-06-1999
The Art of Demomaking - Issue 02 - Introduction To Computer Graphics
08-30-1999
The Art of Demomaking - Issue 01 - Prologue
Code: Select all
16.2 Yaz0
Yaz0 compression is reportedly used in quite a few Nintendo datafiles. I have seen it in SuperMario Sunshine's .szs files for example, and I heard that it is used in Windwaker and Majoras Mask as well. The first 16 bytes of a Yaz0-compressed data block are the data header. The first 4 bytes of the header are 'Y', 'a', 'z', '0', so you can easily see in your hex editor that there's a Yaz0 block waiting for you :-) The second 4 bytes are a single uint32 (big-endian of course) that tells you the size of the decompressed data, so you know how large your working buffer has to be. The next 8 bytes are always zero. Next comes the actual compressed data. Yaz0 is some kind of RLE compression. You decode it as follows: First you read a "code" byte that tells you for the next 8 "read operations" what you have to do. Each bit of the "code" byte represents one "read operation" (from left to right, that is, 0x80 first, 0x01 last). If the bit is 1, copy one byte from the input buffer to the output buffer. Easy. If the bit is 0, things are a little bit more complicated, RLE compressed data is ahead. You have to read the next two bytes to decide how long your run is and what you should write to your output buffer. 15 8 7 0
a b
The upper nibble of the first byte (a) contains the information you need to determine how many bytes you're going to write to your output buffer for this "read operation". if a == 0, then you have to read a third byte from your input buffer, and add 0x12 to it. Otherwise, you simply add 2 to a. This is the number of bytes to write ("count") in this "read operation". byte2 and the lower nibble of byte1 (b) tell you from where to copy data to your output buffer: you move (dist = (b < < 8) - byte2 + 1) bytes back in your outputBuffer and copy "count" bytes from there to the end of the buffer. Note that count could be greater than dist which means that the copy source and copy destination might overlap. index
16.2.1 de-compression Code
//src points to the yaz0 source data (to the "real" source data, not at the header!)
//dst points to a buffer uncompressedSize bytes large (you get uncompressedSize from
//the second 4 bytes in the Yaz0 header).
void decode(u8* src, u8* dst, int uncompressedSize)
{
int srcPlace = 0, dstPlace = 0; //current read/write positions
u32 validBitCount = 0; //number of valid bits left in "code" byte
u8 currCodeByte;
while(dstPlace < uncompressedSize)
{
//read new "code" byte if the current one is used up
if(validBitCount == 0)
{
currCodeByte = src[srcPlace];
++srcPlace;
validBitCount = 8;
}
if((currCodeByte & 0x80) != 0)
{
//straight copy
dst[dstPlace] = src[srcPlace];
dstPlace++;
srcPlace++;
}
else
{
//RLE part
u8 byte1 = src[srcPlace];
u8 byte2 = src[srcPlace + 1];
srcPlace += 2;
u32 dist = ((byte1 & 0xF) < < 8) - byte2;
u32 copySource = dstPlace - (dist + 1);
u32 numBytes = byte1 > > 4;
if(numBytes == 0)
{
numBytes = src[srcPlace] + 0x12;
srcPlace++;
}
else
numBytes += 2;
//copy run
for(int i = 0; i < numBytes; ++i)
{
dst[dstPlace] = dst[copySource];
copySource++;
dstPlace++;
}
}
//use next bit from "code" byte
currCodeByte < <= 1;
validBitCount-=1;
}
}