Brick: Difference between revisions
Jump to navigation
Jump to search
[checked revision] | [checked revision] |
Content deleted Content added
Created page with "{{Infobox format | extension = BRK | occurence = LBA1 & LBA2 | colour = F3F2AD }} Brick files are small images (similar to sprites) of constant dimensions, that are used to b..." |
Hi, this is Lupin, I think the width/height and offsets were in reverse order |
||
(2 intermediate revisions by one other user not shown) | |||
Line 1: | Line 1: | ||
{{Infobox format |
{{Infobox format |
||
| extension = BRK |
| extension = BRK |
||
| lba1 = true |
|||
| occurence = LBA1 & LBA2 |
|||
| lba2 = true |
|||
| colour = F3F2AD |
| colour = F3F2AD |
||
}} |
}} |
||
Line 66: | Line 67: | ||
*)***File Structure*** |
*)***File Structure*** |
||
0. byte : |
0. byte : width |
||
1. byte : |
1. byte : height |
||
2. byte : |
2. byte : offset X |
||
3. byte : |
3. byte : offset Y |
||
following bytes: Run-length encoded data |
following bytes: Run-length encoded data |
||
</pre> |
</pre> |
||
{{providers|[[provider::Zink]] and [[provider::Omni]]}} |
{{providers|[[provider::Zink]] and [[provider::Omni]]}} |
||
{{DEFAULTSORT:Brick}} |
|||
[[Category:File formats|Brick]] |
|||
[[Category:LBA 1]] |
|||
[[Category:LBA 2]] |
Latest revision as of 21:26, 4 October 2016
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[edit]
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 : width 1. byte : height 2. byte : offset X 3. byte : offset Y following bytes: Run-length encoded data
Information provided by: Zink and Omni