|Programs supporting this format|
Abstract: A grid file represents the geometry of a room in LBA1 (called: a cube). the threedimensional space, in which the bricks are places, has a maximum ground area of 64*64 bricks and a maximum height of 25 bricks. so there can be at most 64*64*25 bricks in the room.
the bricks aren't directly addressed but entries of the LBA1 layouts (see BL1 extension) are specified in the grid files.
a grid file always contains 64*64 columns, each containing 25 bricks. to save memory, these columns are run-length encoded and indirectly addressed.
the header contains 64*64 entries a 2 bytes.
each entry points to a point in the file, where a column is saved. a great amount of memory is saved now, because, for example, all columns containing no bricks at all can be described by a single run-length encoded column. the header entries representing such empty columns just all have to point on the same column.
therefore, in grid files in most of header entries you will find the hex value 00 20 which is the address 8192 and is the first valid file address after the header (the header has a size of 64*64=4096 entries á 2 bytes = 8192 bytes)
- column data
the column data is run-length encoded. the decoding algorithm works similar to the algorithm described in the lba1 brick file specification (you can find the c implementation of the algorithm in function "DiscretizeMapToCube" in cube.c).
The decoded brick data has to be interpreted as collection of words (2 bytes).
Each word represents one brick:
-the first byte of the word specifies the layout index. obviously the layout index A in the grid file #B always refers to the layout #A in the layout file #B (see function "InitGrille" in cube.c)
-the second byte specifies the brick within the layout.
Information provided by: Zink and Omni