LBA1:Grid - Revision history

77.3.37.253 at 17:04, 30 July 2021

2021-07-30T17:04:23Z

← Older revision		Revision as of 17:04, 30 July 2021
Line 6:		Line 6:
	}}		}}

	Grids define the structure of the isometric game areas. They utilize [[Brick]]s and [[LBA1:Block_library\|\|Block libraries]] for terrain construction.		Grids define the structure of the isometric game areas. They utilize [[Brick]]s and [[LBA1:Block_library\|Block libraries]] for terrain construction.

	== Specification ==		== Specification ==

77.3.37.253 at 17:04, 30 July 2021

2021-07-30T17:04:14Z

← Older revision		Revision as of 17:04, 30 July 2021
Line 6:		Line 6:
	}}		}}

	Grids define the structure of the isometric game areas. They utilize [[Brick]]s and [[~~LBA 1 block library~~\|Block libraries]] for terrain construction.		Grids define the structure of the isometric game areas. They utilize [[Brick]]s and [[LBA1:Block_library\|\|Block libraries]] for terrain construction.

	== Specification ==		== Specification ==

77.3.37.253 at 16:01, 30 July 2021

2021-07-30T16:01:03Z

← Older revision		Revision as of 16:01, 30 July 2021
Line 9:		Line 9:

	== Specification ==		== 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 6464 bricks and a maximum height of 25 bricks. so there can be at most 6464*25 bricks in the room.
	{{Cleanup\|It should be reformatted to use wikitext instead of <pre> tags.}}
	<pre>
⚫	~~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 6464 bricks and a maximum height of 25 bricks. so there can be at most 6464*25 bricks in the room.

	the bricks aren't directly ~~adressed~~ but entries of the LBA1 layouts (see BL1 extension) are specified in the grid files.		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 ~~adressed~~.		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		=== file structure ===
	1) header
	2) column data

		⚫	# header<br/>the header contains 6464 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 6464=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 ~~desribed~~ by a ~~_single_~~ run-length encoded column. the header entries representing such empty columns just all have to point on the same column.

			# 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]]}}

Zink: Zink moved page LBA 1 grid to LBA1:Grid without leaving a redirect

2013-03-02T09:36:48Z

Zink moved page LBA 1 grid to LBA1:Grid without leaving a redirect

← Older revision	Revision as of 09:36, 2 March 2013
(No difference)

Zink at 09:46, 10 February 2013

2013-02-10T09:46:29Z

← Older revision		Revision as of 09:46, 10 February 2013
Line 1:		Line 1:
	{{Infobox format		{{Infobox format
	\| extension = GR1		\| extension = GR1
	\| ~~occurence~~ = ~~LBA1~~		\| lba1 = true
	\| colour = DDA0DD		\| colour = DDA0DD
	\| defaultsort = grid		\| defaultsort = grid
Line 34:		Line 34:

	{{providers\|[[provider::Zink]] and [[provider::Omni]]}}		{{providers\|[[provider::Zink]] and [[provider::Omni]]}}

	[[Category:LBA 1]]

Zink at 20:08, 9 February 2013

2013-02-09T20:08:32Z

← Older revision		Revision as of 20:08, 9 February 2013
Line 3:		Line 3:
	\| occurence = LBA1		\| occurence = LBA1
	\| colour = DDA0DD		\| colour = DDA0DD
			\| defaultsort = grid
	}}		}}

Line 34:		Line 35:
	{{providers\|[[provider::Zink]] and [[provider::Omni]]}}		{{providers\|[[provider::Zink]] and [[provider::Omni]]}}

	{{DEFAULTSORT:Grid}}
	[[Category:File formats\|Grid]]
	[[Category:LBA 1]]		[[Category:LBA 1]]

Zink: Created page with "{{Infobox format | extension = GR1 | occurence = LBA1 | colour = DDA0DD }} Grids define the structure of the isometric game areas. They utilize Bricks and [[LBA 1 block l..."

2013-02-09T17:33:42Z

Created page with "{{Infobox format | extension = GR1 | occurence = LBA1 | colour = DDA0DD }} Grids define the structure of the isometric game areas. They utilize Bricks and [[LBA 1 block l..."

New page

{{Infobox format
| extension = GR1
| occurence = LBA1
| colour = DDA0DD
}}

Grids define the structure of the isometric game areas. They utilize [[Brick]]s and [[LBA 1 block library|Block libraries]] for terrain construction.

== Specification ==
{{Cleanup|It should be reformatted to use wikitext instead of <pre> tags.}}
<pre>
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 adressed 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 adressed.

**file structure**
1) header
2) column data

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 desribed 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 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]]}}

{{DEFAULTSORT:Grid}}
[[Category:File formats|Grid]]
[[Category:LBA 1]]