LBA1:Block library: Difference between revisions

From LBA File Information
Jump to navigation Jump to search
[checked revision][checked revision]
Content deleted Content added
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..."
 
No edit summary
 
(4 intermediate revisions by 2 users not shown)
Line 1: Line 1:
{{Infobox format
{{Infobox format
| extension = BL1
| extension = BL1
| occurence = LBA1
| lba1 = true
| colour = D6E8B4
| colour = D6E8B4
| defaultsort = block
}}
}}


Line 8: 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 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.


⚫
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)
⚫
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 [[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 _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 4*x*y*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 4*x*y*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]]}}

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

Latest revision as of 15:57, 30 July 2021

Block library
Extension

BL1

Occurence

LBA1

Colour
Programs supporting this format
References

Find entries of this type


Block libraries organize Bricks in groups, that are easier to manage during Grid editing.

Specification[edit]

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 ambiguous, 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[edit]

  1. header pointing on data entries each data entry contains dimension entries and index data
    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. dimension entries
    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. index data
    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.


Information provided by: Zink and Omni

Retrieved from "https://lbafileinfo.kaziq.net/index.php?title=LBA1:Block_library&oldid=2366"