Varion Icaria, on 05 December 2014 - 09:16 PM, said:
I'm still rather curious on the whole format and how it works, can you explain it better and how much more RAM it takes?
If you look at Chemical Plant Zone Act 2, the whole meta-block layout takes up 1241 bytes. 4096 bytes are allocated for meta-block layout. So, CPZ2 is only using 30% of that. And obviously, because of the nature of data compression, different levels are going to compress at different ratios.
The
level format specification from my first post lays out the entire format, but I can summarize it for you:
You have two bytes to start. One says how many rows there are for the front layout data, and the other says how many rows there are for the background layout data.
Then you have a list of words, each one for a different row, with physical and visual each having one. So for 16 rows of visual and physical layout, you will have 32 words. Each word specifies the format of the row, as well as where the row data is located. The format is as follows:
fffffppp pppppppp
f = format
p = pointer
The pointer is multiplied by 2, so data always has to start at even addresses.
Now, there are 7 formats. They are as follows:
0x00 (00000) = AST: Always specified type
0x01 (00001) = BALE: Bitwise-AND at line-end
0x02 (00010) = WOLE: Wrap once at line-end
0x03 (00011) = ZLE: Zero at line-end
0x10 (10000) = (reserved -- acts as AST)
0x11 (10001) = BALE4: Bitwise-AND at line-end 4-bit
0x12 (10010) = WOLE4: Wrap once at line-end 4-bit
0x13 (10011) = ZLE4: Zero at line-end 4-bit
AST is special, because it uses the pointer value to determine which meta-block to use. It will fill up the entire row with that value. It works great for levels like EHZ where the very top of the level uses 0 for every meta-block position.
BALE data starts with a byte to say how long the data is. 1 is always added to that value. Then the list of meta-blocks starts. At the end of the data, Sonic Boom it will do a bitwise AND operation and repeat the meta-block data endlessly. This format works well with backgrounds.
WOLE data is formatted just like BALE is. The difference is Sonic Boom will wrap this data once (meaning, it does NOT do a modulus operation, but rather does simple subtraction to repeat the data when needed). This is useful when the data is more than half the length of the level and needs repeating, even if only for a few meta-blocks at the very end.
ZLE data is formatted like BALE and WOLE, but Sonic Boom uses 0 for every meta-block position after the data ends.
4-bit formats start with a byte to specify how many nybbles will be used. Then is uses a series of nybbles (even numbered of course) to specify meta-block references. Then a list of meta-blocks for each reference is specified after the nybbles. So for example, 04 01 23 A0 B0 C0 D0 means that there are 4 nybbles, and nybbles 0 = A0, 1 = B0, 2 = C0, and 3 = D0. It cuts normal 8-bit data down to almost half the size. These formats are useful when 16 or fewer different meta-blocks are used in a row.
As for ring layout, it uses pretty much the same general format as Sonic 2, but now all 32 bits of the positions are used with some bits being moved. Doing this allows rings to be placed anywhere in the 0x8000 x 0x2000 area supported by the engine. Here's the format used for each position:
The 'xPos' word is broken up into this format:
oxxxxxxx xxxxxxxx
o = orientation
x = horizontal position
The orientation determines if this is a row or column of rings.
The following format is used for the 'yPos' word:
lllyyyyy yyyyyyyy
l = length
y = vertical position
The length determines the number of rings between 1 and 8.
This post has been edited by saxman: 06 December 2014 - 07:06 PM
00
