LBA1:Grid: Difference between revisions
Jump to navigation
Jump to search
| [checked revision] | [checked revision] |
Content deleted Content added
m Zink moved page LBA 1 grid to LBA1:Grid without leaving a redirect |
No edit summary |
||
| Line 9: | Line 9: | ||
== Specification == |
== Specification == |
||
| ⚫ | |||
{{Cleanup|It should be reformatted to use wikitext instead of <pre> tags.}} |
|||
<pre> |
|||
| ⚫ | |||
the bricks aren't directly |
the bricks aren't directly addressed but entries of the LBA1 layouts (see [[LBA1:Block_library|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 |
a grid file always contains 64*64 columns, each containing 25 bricks. to save memory, these columns are run-length encoded and indirectly addressed. |
||
=== file structure === |
|||
1) header |
|||
2) column data |
|||
| ⚫ | # header<br/>the header contains 64*64 entries a 2 bytes.<br/>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 <u>single</u> run-length encoded column. the header entries representing such empty columns just all have to point on the same column.<br /><br/>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) |
||
1) the header contains 64*64 entries á 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 |
||
# column data<br/>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).<br/>The decoded brick data has to be interpreted as collection of words (2 bytes).<br />Each word represents one brick:<br/>-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)<br />-the second byte specifies the brick within the layout. |
|||
therefore, in grid files in most of header entries you will find the hex value 00 20 which is the adress 8192 and is the first valid file adress after the header (the header has a size of 64*64=4096 entries á 2 bytes = 8192 bytes) |
|||
2) 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. |
|||
</pre> |
|||
{{providers|[[provider::Zink]] and [[provider::Omni]]}} |
{{providers|[[provider::Zink]] and [[provider::Omni]]}} |
||
Revision as of 16:01, 30 July 2021
| Grid | ||
|---|---|---|
| Extension |
GR1 |
|
| Occurence |
LBA1 |
|
| Colour |
|
|
| Programs supporting this format | ||
| References | ||
Grids define the structure of the isometric game areas. They utilize Bricks and Block libraries for terrain construction.
Specification
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.
file structure
- header
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