Brick
Brick | ||
---|---|---|
Extension |
BRK |
|
Occurence |
LBA1 & LBA2 |
|
Colour |
|
|
Programs supporting this format | ||
References | ||
Brick files are small images (similar to sprites) of constant dimensions, that are used to build up the isometric game environment. Brick files use run-length encoding (a form of compression).
Specification
This page may need some cleanup. It should be reformatted to use wikitext instead of <pre> tags. |
Abstract: the brick pixel data is run-length encoded and palette indexed. Details: *)***Run-length Encoding*** -the data is organized into rows -every row is formed of several "runs" a run is a sequence of pixels and defines what "comes out" in the final pixel-based image. -there are 3 forms of runs: 1. the skip run: this run defines a sequence of pixels in the final image which are NOT filled. 2. the color run: this run defines a sequence of pixels in the final image which are all set to the same color. 3. the copy run: this run defines a sequence of pixels in the final image which show no pattern an therefore are copied directly. now the actual algorithm: for all rows do read byte : number of runs for number of runs do read byte : run specification extr. lowest 6 bits of run specification : run-length run-length = runlength + 1 extr. bit #7 of run specification : color flag extr. bit #8 of run specification : copy flag if color flag is set read byte : color for run-length do fill pixel with color end for else if copy flag is set for run-length do read byte : color fill pixel with color end for else (both flags unset) for run-length do skip pixel end for end if end for end for the run-lenth is always increased by one because a run-length of zero doesn't make sense. *)***File Structure*** 0. byte : offset X 1. byte : offset Y 2. byte : width 3. byte : height following bytes: Run-length encoded data
Information provided by: Zink and Omni