LBA1:Block library - Revision history

77.3.37.253 at 15:57, 30 July 2021

2021-07-30T15:57:40Z

← Older revision		Revision as of 15:57, 30 July 2021
Line 15:		Line 15:
	- the index of the layout, it belongs to (which is ambiguous, i assume, because a brick can belong to multiple layouts)		- the index of the layout, it belongs to (which is ambiguous, i assume, because a brick can belong to multiple layouts)
	- the position index of the brick within the specific layout.		- the position index of the brick within the specific layout.
	those two indices are provided by the entries of the grid file (see GR1 file extension)		those two indices are provided by the entries of the grid file (see [[LBA1:Grid\|GR1]] file extension)

	The layouts have obvious advantage in an editor because you can place logical units instead of single bricks (Little Big Architect uses layouts) though i wonder why Adeline put them into the <u>game</u>.		The layouts have obvious advantage in an editor because you can place logical units instead of single bricks (Little Big Architect uses layouts) though i wonder why Adeline put them into the <u>game</u>.

77.3.37.253 at 15:56, 30 July 2021

2021-07-30T15:56:11Z

← Older revision		Revision as of 15:56, 30 July 2021
Line 9:		Line 9:

	== Specification ==		== Specification ==
	{{Cleanup\|It should be reformatted to use wikitext instead of <pre> tags.}}
	<pre>
⚫	~~abstract~~: a LBA1 layout is a collection of bricks, positioned in a three dimensional "subspace" of specific size. ~~take~~, for example, a treasure chest: it has a ground area of 32 bricks and is 2 bricks high. so the subspace has a size of 32*2 bricks. then all bricks, that represent this chest, are packed into the treasure chest layout.

		⚫	Abstract: a LBA1 layout is a collection of bricks, positioned in a three dimensional "subspace" of specific size. Take, for example, a treasure chest: it has a ground area of 32 bricks and is 2 bricks high. so the subspace has a size of 32*2 bricks. then all bricks, that represent this chest, are packed into the treasure chest layout.
⚫	so every brick in LBA1 can be addressed by two indices:

⚫	- the index of the layout, it belongs to (which is ~~ambigious~~, i assume, because a brick can belong to multiple layouts)
		⚫	So every brick in LBA1 can be addressed by two indices:
		⚫	- the index of the layout, it belongs to (which is ambiguous, i assume, because a brick can belong to multiple layouts)
	- the position index of the brick within the specific layout.		- the position index of the brick within the specific layout.
	those two indices are provided by the entries of the grid file (see GR1 file extension)		those two indices are provided by the entries of the grid file (see GR1 file extension)

	~~the~~ layouts have obvious advantage in an editor because you can place logical units instead of single bricks (Little Big Architect uses layouts) though i wonder why Adeline put them into the ~~_game_~~.		The layouts have obvious advantage in an editor because you can place logical units instead of single bricks (Little Big Architect uses layouts) though i wonder why Adeline put them into the <u>game</u>.

	open questions: what's the purpose of the first word (16 bits) in each index entry of the brick indices.		open questions: what's the purpose of the first word (16 bits) in each index entry of the brick indices.

	the layout index and the brick index within the layout both have to be decreased by one to get the ~~_real_~~ indices. a value of zero for these indices (before decreasing) indicates an empty brick!		the layout index and the brick index within the layout both have to be decreased by one to get the <u>real</u> indices. a value of zero for these indices (before decreasing) indicates an empty brick!

	BL1 layout files are found in lba_bll.hqr		BL1 layout files are found in ''lba_bll.hqr''

	file structure		=== file structure ===

		⚫	# header pointing on data entries each data entry contains dimension entries and index data<br />the header contains up to 256 pointer entries, who define the positions of the actual data entries in the file. each data entry represents one layout.
	1) header pointing on data entries
		⚫	# dimension entries<br />the dimension entry is a row of 3 bytes, each providing the length of the subspace in x-, y-, z-direction. so the row 1,3,3 means: the subspace has a width (x) of 1, a height (y) of 3 and a depth (z) of 3.
	each data entry contains
		⚫	# index data<br />the index data contains 4 bytes of data for each brick in the layout, so it's size in bytes is 4xy*z.
	2) dimension entries
	3) index data

⚫	1) the header contains up to 256 pointer entries, who define the positions of the actual data entries in the file. each data entry represents one layout.

⚫	2) the dimension entry is a row of 3 bytes, each providing the length of the subspace in x-, y-, z-direction. so the row 1,3,3 means: the subspace has a width (x) of 1, a height (y) of 3 and a depth (z) of 3.

⚫	3) the index data contains 4 bytes of data for each brick in the layout, so it's size in bytes is 4xy*z.
	let's call these blocks of 4 bytes "brick entries".		let's call these blocks of 4 bytes "brick entries".
	the last word (last 2 bytes) of these brick entries is the actual index of the brick in lba_brk.hqr. the first word seems to be layout-specific, but i wasn't able to find out what it's used for yet.		the last word (last 2 bytes) of these brick entries is the actual index of the brick in lba_brk.hqr. the first word seems to be layout-specific, but i wasn't able to find out what it's used for yet.

	</pre>

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

Zink: Zink moved page LBA 1 block library to LBA1:Block library without leaving a redirect

2013-03-02T09:36:07Z

Zink moved page LBA 1 block library to LBA1:Block library 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:09Z

← Older revision		Revision as of 09:46, 10 February 2013
Line 1:		Line 1:
	{{Infobox format		{{Infobox format
	\| extension = BL1		\| extension = BL1
	\| ~~occurence~~ = ~~LBA1~~		\| lba1 = true
	\| colour = D6E8B4		\| colour = D6E8B4
	\| defaultsort = block		\| defaultsort = block
Line 43:		Line 43:

	{{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:01Z

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

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

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

Zink: Created page with "{{Infobox format | extension = BL1 | occurence = LBA1 | colour = D6E8B4 }} Block libraries organize Bricks in groups, that are easier to manage during Grid editing. == S..."

2013-02-09T17:20:26Z

Created page with "{{Infobox format | extension = BL1 | occurence = LBA1 | colour = D6E8B4 }} Block libraries organize Bricks in groups, that are easier to manage during Grid editing. == S..."

New page

{{Infobox format
| extension = BL1
| occurence = LBA1
| colour = D6E8B4
}}

Block libraries organize [[Brick]]s in groups, that are easier to manage during Grid editing.

== Specification ==
{{Cleanup|It should be reformatted to use wikitext instead of <pre> tags.}}
<pre>
abstract: a LBA1 layout is a collection of bricks, positioned in a three dimensional "subspace" of specific size. take, for example, a treasure chest: it has a ground area of 3*2 bricks and is 2 bricks high. so the subspace has a size of 3*2*2 bricks. then all bricks, that represent this chest, are packed into the treasure chest layout.

so every brick in LBA1 can be addressed by two indices:
- the index of the layout, it belongs to (which is ambigious, i assume, because a brick can belong to multiple layouts)
- the position index of the brick within the specific layout.
those two indices are provided by the entries of the grid file (see GR1 file extension)

the layouts have obvious advantage in an editor because you can place logical units instead of single bricks (Little Big Architect uses layouts) though i wonder why Adeline put them into the _game_.

open questions: what's the purpose of the first word (16 bits) in each index entry of the brick indices.

the layout index and the brick index within the layout both have to be decreased by one to get the _real_ indices. a value of zero for these indices (before decreasing) indicates an empty brick!

BL1 layout files are found in lba_bll.hqr

**file structure**

1) header pointing on data entries
each data entry contains
2) dimension entries
3) index data

1) the header contains up to 256 pointer entries, who define the positions of the actual data entries in the file. each data entry represents one layout.

2) the dimension entry is a row of 3 bytes, each providing the length of the subspace in x-, y-, z-direction. so the row 1,3,3 means: the subspace has a width (x) of 1, a height (y) of 3 and a depth (z) of 3.

3) the index data contains 4 bytes of data for each brick in the layout, so it's size in bytes is 4*x*y*z.
let's call these blocks of 4 bytes "brick entries".
the last word (last 2 bytes) of these brick entries is the actual index of the brick in lba_brk.hqr. the first word seems to be layout-specific, but i wasn't able to find out what it's used for yet.
</pre>

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

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