Geometry Layout Commands 1 2 »
Users browsing this thread: 1 Guest(s)

These scripts point to the display lists, with properties and displacements applied.

Drawing Layers:
00=Unused
01=Entirely Solid
02=Unused
03=Unused
04=Transparent pixels, no semi transparency. Allows perfect layering with other transparencies around it.
05=Semi transparency enabled. Layering must be handled with the order of drawn faces.
06=Semi transparency enabled. Layering must be handled with the order of drawn faces. This layer is always drawn behind layer 05, usually for shadows.






0x01 - TERMINATE GEOMETRY LAYOUT
The ending command to close.
Usage:
0100 0000






0x02 - BRANCH GEOMETRY LAYOUT
Branches the current geo layout to another area within a RAM bank.
Syntax:
0201 0000 aabbbbbb
aa- RAM Bank
bbbbbb- Address






0x03 - END BRANCH
Ends the current geometry layout branch and returns to the area following the 0x02 command.
Usage:
0300 0000






0x04 - OPEN NODE
If you don't understand nodes, this is basically like a sub-folder. Command is 4 bytes long.
Usage:
04000000






0x05 - CLOSE NODE
Used at the end of the data within the opened node. Command is 4 bytes long.
Usage:
05000000






0x0B - START GEO LAYOUT
Starts geometry layout with no parameters whatsoever. Seems to use a pre-set render area.
Usage:
0B000000






0x0E - SWITCH CASE
Loads ASM in RAM that switches between the receding display lists within the node.
Syntax:
0E00 00aa 8029DB48
aa- Number of cases/display lists, starting at 01.

Example:
0E00 0002 8029DB48
Switches between the next 2 display lists, could be used for blinking.






0x13 LOAD DISPLAY LIST WITH POSITION OFFSET
Loads display list with drawing layer and offsets the model on X/Y/Z axis. Command is 12 bytes long.
Syntax:
13aabbbbccccddddeeffffff
aa- Drawing layer
bbbb- Offset on X axis (16-bit coordinates)
cccc- Offset on Y axis (16-bit coordinates)
dddd- Offset on Z axis (16-bit coordinates)
ee- RAM Bank
ffffff- Address

Example:
1301 0000 008A 0000 0E 000A90
Loads a display list from 0xA90 in RAM Bank 0E as a solid model, and offsets it by 0x8A (138 coordinates) on the Y axis.






0x14 - BILLBOARD MODEL
Billboards the model without needing the use of 0x21 in the behaviour script. Command is (uselessly) 8 bytes long.
Usage:
1400 0000 0000 0000






0x15 - LOAD DISPLAY LIST
Loads display list with drawing layer and no other properties. Command is 8 bytes long.
Syntax:
15aa0000bbcccccc
aa- Drawing Layer
bb- RAM Bank
cc- Address

Example:
15 04 0000 04 00B090
Loads display list on layer 04 (Transparent pixels) in 0xB090 of bank 04.






0x16 - START GEOMETRY LAYOUT WITH SHADOW
Used at start of the geo layout, with shadow type, solidity, and size. Command is 8 bytes long.
Syntax:
160000aa00bbcccc
aa- Shadow type
bb- Shadow solidity (00=Invisible, FF=Black)
cccc- Shadow scale






0x18 - LOAD POLYGONS IN RAM
Used in some original objects to point to ASM in RAM, for misc. effects such as vertex rippling. Command is 8 bytes long.
Syntax:
1800000080aaaaaa
aaaaaa- RAM Address






0x1D - SCALE MODEL UNIFORMLY
Scales the receding data uniformly. Command is 8 bytes long.
Syntax:
1Daaaaaaaaaaaaaa






0x20 - START GEO LAYOUT WITH RENDER AREA
Starts the geometry layout with no shadow and a render area.
Syntax:
2000 aaaa
aaaa- Render distance?


If there are any questions or suggestions, please don't be shy. There may have been things that I didn't explain correctly, and there are definitely things that I missed.
(This post was last modified: 08-08-2017, 12:02 AM by cpuHacka101.)

I think I figured out how the 0x1D command works. It works in a percentage-like system where 0x10000 = 100%.

If you have ever looked at the vertices of the star model, then you will know that it's actually a pretty large object.

[Image: oZT1IRo.png]
(Actual size without the 0x1D command)

The geo layout of the star uses the command 0x1D to scale the model down to 25% of it's original size.

[ 1D 00 00 00 00 00 40 00 ]

Byte 2:
-- see queueRAM's post below. I read that part of the asm code wrong. --

Bytes 5 - 8:
The value to scale by. If the value is smaller than 0x10000, then the model will shrink. If the value is greater than 0x10000, then the model will grow.

Here is a little reference chart:
0x2000 = 12.5%
0x4000 = 25%
0x8000 = 50%
0xC000 = 75%
0x10000 = 100%
0x14000 = 125%
0x18000 = 150%
0x20000 = 200%


It should be mentioned that the 0x18 command is also used to load geometry through special ASM functions. Bytes 3 & 4 are parameters that get passed into the assembly function. For example, the [ 18 00 01 08 80 2D 5B 98 ] command is used to load the Wet-Dry-World painting.

ASM Functions:
0x802D5B98 - Used to load the paintings/Hazy Maze Cave pool.
0x802D1B70 - Used to load geometry with moving textures. (example: the lava floor in LLL)
0x802D1CDC - Used to load geometry for the moving quicksand in SSL.
0x802D104C - Used to load geometry for the water boxes.

Here are some notes I took over the 0x18 command used in different levels in the game:
Spoiler: notes
-- Castle grounds --
00454DB4 / 0E0007D4 [ 18 00 00 00 80 2D 01 E0 ] -- ???
00454DBC / 0E0007DC [ 18 00 16 01 80 2D 1B 70 ] --  Loads the waterfall
00454DC4 / 0E0007E4 [ 18 00 16 01 80 2D 10 4C ] --  Loads the water boxes (moving texture)

-- Inside Castle's Paintings --
Rendering a painting consists of 2 0x18 commands:
[ 18 00 00 00 80 2D 5D 0C ] --  Loads the ripple effect (same for all paintings?)
[ 18 00 XX YY 80 2D 5B 98 ] --  Loads the painting

The XX byte points to a list pointer. The pointers can be found starting at the RAM address 0x8033134C.

00 = Pointer to list containing the shiny black pool in Hazy Maze Cave. (0x8033134C)
01 = Pointer to list containing the Inside Castle's paintings. (0x80331350)
02 = Pointer to list containing the painting to the slide in Tall Tall Mountain. (0x80331354)

The YY byte is the index of the list, though this really only applies to the paintings inside the castle.

(XX == 0)
00 = Shiny black pool in HMC

(XX == 1)
00 = Bob-omb's Battlefield
01 = Cool-cool Mountain
02 = Whomp's Fortress
03 = Jolly Roger's Bay
04 = Lethal Lava Land
05 = Shifting Sand Land
06 = Hazy Maze Cave (Shiny black pool)
07 = Dire Dire Docks
08 = Wet Dry World
09 = Tiny Huge Island (Tiny painting)
0A = Tall Tall Mountain
0B = Tick Tock Clock
0C = Snowman's Land
0D = Tiny Huge Island (Huge painting)

(XX == 2)
00 = Painting leading to slide in TTM [ 07 01 2F 00 ]

-- Lethal Lava Land --
Outside volcano:
0048D830 / 0E000E80 [ 18 00 22 01 80 2D 1B 70 ] -- Lava floor

Inside volcano:
0048D900 / 0E000F50 [ 18 00 22 02 80 2D 1B 70 ] -- Lavafall
0048D908 / 0E000F58 [ 18 00 22 02 80 2D 10 4C ] -- Lava floor (water box)


-- Shifting Sand Land --
Outside the pyramid:
003FC058 / 0E0006C8 [ 18 00 08 01 80 2D 21 08 ] -- Animates the quicksand in the sand pits.
003FC060 / 0E0006D0 [ 18 00 00 00 80 2D 01 E0 ] -- ???
003FC068 / 0E0006D8 [ 18 00 08 01 80 2D 10 4C ] -- Water near palm tree
003FC070 / 0E0006E0 [ 18 00 08 51 80 2D 10 4C ] -- Deadly quicksand in the Tox-Box maze. (water box)

003FC078 / 0E0006E8 [ 18 00 08 01 80 2D 1C DC ] -- Quicksand near the pyramid
003FC080 / 0E0006F0 [ 18 00 08 02 80 2D 1C DC ] -- Quicksand near the pyramid (corners)
003FC088 / 0E0006F8 [ 18 00 08 03 80 2D 1C DC ] -- Quicksand on the outer-edges of the map.

Inside the pyramid:
003FC1D4 / 0E000844 [ 18 00 08 02 80 2D 21 08 ] -- Animates the quicksand in the sand pits.
003FC1DC / 0E00084C [ 18 00 00 00 80 2D 01 E0 ] -- ???
003FC1E4 / 0E000854 [ 18 00 08 01 80 2D 1B 70 ] -- First sand waterfall (higher up)
003FC1EC / 0E00085C [ 18 00 08 02 80 2D 1B 70 ] -- Sand conveyor belt
003FC1F4 / 0E000864 [ 18 00 08 03 80 2D 1B 70 ] -- Second sand waterfall (lower)

-- Hazy Maze Cave --
003E7158 / 0E000758 [ 18 00 00 00 80 2D 5D 0C ]
003E7160 / 0E000760 [ 18 00 00 00 80 2D 5B 98 ] -- Loads the shiny black pool.

Note: The shiny black pool in HMC uses a different pointer than the one used inside peach's castle.
HMC pool: [ 07 02 38 F0 ]
Metal Cap pool: [ 07 02 55 1C ]

-- Tall Tall Mountain --
004EBCDC / 0E000AEC [ 18 00 02 00 80 2D 5B 98 ] -- Renders the painting to the slide.
004EBCE4 / 0E000AF4 [ 18 00 00 00 80 2D 01 E0 ] -- ???
004EBCEC / 0E000AFC [ 18 00 36 01 80 2D 1B 70 ] -- Big waterfall at the top
004EBCF4 / 0E000B04 [ 18 00 36 02 80 2D 1B 70 ] -- Second waterfall (Next to the rolling log)
004EBCFC / 0E000B0C [ 18 00 36 03 80 2D 1B 70 ] -- Pool of water near the monkey/fly guy
004EBD04 / 0E000B14 [ 18 00 36 04 80 2D 1B 70 ] -- Tiny section of water below the second waterfall
004EBD0C / 0E000B1C [ 18 00 36 05 80 2D 1B 70 ] -- River stream at the base of the mountain
004EBD14 / 0E000B24 [ 18 00 36 01 80 2D 10 4C ] -- Pool of water at the base of the mountain
004EBD1C / 0E000B2C [ 18 00 00 00 80 27 61 D0 ] -- ???
(This post was last modified: 07-07-2015, 06:43 AM by David.)

That seems kinda cool, do the crystals in the Metal Cap stage also make use of 0x18? And would it be possible to use a 0x18 command for a custom texture? They're found in level scripts, heh?
Gone for a while.

(07-07-2015, 02:58 AM)David Wrote: [ 1D 00 00 00 00 00 40 00 ]

Byte 2:
The 0x1D command checks to see if this value is 0x80. If that is true, then it will skip some assembly code inside the 0x1D command. The skipped code moves geo script pointer (0x8038bd80) by 4 bytes, so setting the value to 0x80 usually just crashes the game.

Bytes 5 - 8:
The value to scale by. If the value is smaller than 0x10000, then the model will shrink. If the value is greater than 0x10000, then the model will grow.
Nice job decoding that!  I would like to clarify the second byte though.  The code tests if the most significant bit is set, and if so, stores the lower 4 bits and grabs an additional word at offset 8 (making the command C bytes long).  It passes the lower 4 bits in A2 and the additional word in A3 to proc_8037B940() which stores it in another structure (haven't chased it beyond that yet).  I have not seen any 1D commands with this bit set though.  Pseudo code, skipping some of the important parts:
Code:
GeoLayout1D() {
  u16 arg2 = 0;
  u32 arg3 = 0;
  ...
  if (command[1] & 0x80) {
     arg3 = read_u32(&command[8]);
     arg2 = command[1] & 0xF;
     command += 4;
  }
  proc_8037B940(ptr, 0, arg2, arg3, someFloat);
  ...
  command += 8;
}

As an interesting sidenote, there are two more variable length geo layout commands like that: 0A and 11.  11 is similar to 1D in that it test the most significant bit and if set expects 4 more bytes.  For 0A, if the second byte is non-zero it expects 4 more bytes.  I have seen this bit set for 11 only in the mario/menu/game over level data between 26A310-26A388 in the stock ROM.  0A is most commonly the extended variety, the extra 4 bytes being a function (and always 8029AA3C).  I'll decode these further after I get the next n64split release out.

(07-07-2015, 02:58 AM)David Wrote: It should be mentioned that the 0x18 command is also used to load geometry through special ASM functions. Bytes 3 & 4 are parameters that get passed into the assembly function. For example, the [ 18 00 01 08 80 2D 5B 98 ] command is used to load the Wet-Dry-World painting.

You can see the current version of the n64split config file for a full list of geometry 18 assembly functions, also copied here if they are of any use:
Spoiler :
  // Geo Layout 0x18 Functions
  (0x8016F670, "Geo18_8016F670"), // game over
  (0x8016F984, "Geo18_8016F984"), // game over
  (0x8016FE70, "Geo18_8016FE70"), // game over
  (0x8016FFFC, "Geo18_8016FFFC"), // game over
  (0x80176688, "Geo18_80176688"), // main menu
  (0x80177518, "Geo18_80177518"), // main menu
  (0x802761D0, "Geo18_802761D0"),
  (0x802764B0, "Geo18_802764B0"), // game over
  (0x802770A4, "Geo18_802770A4"),
  (0x80277294, "Geo18_80277294"),
  (0x802773A4, "Geo18_802773A4"),
  (0x802775CC, "Geo18_802775CC"),
  (0x80277824, "Geo18_80277824"),
  (0x80277B14, "Geo18_80277B14"), // inside castle
  (0x80277D6C, "Geo18_80277D6C"),
  (0x8029D924, "Geo18_8029D924"),
  (0x802A45E4, "Geo18_802A45E4"),
  (0x802A719C, "Geo18_802A719C"),
  (0x802B1BB0, "Geo18_802B1BB0"),
  (0x802B798C, "Geo18_802B798C"),
  (0x802B7D44, "Geo18_802B7D44"),
  (0x802BA2B0, "Geo18_802BA2B0"),
  (0x802CD1E8, "Geo18_802CD1E8"), // possibly cannon related
  (0x802D01E0, "Geo18_802D01E0"),
  (0x802D104C, "Geo18_802D104C"),
  (0x802D1B70, "Geo18_802D1B70"),
  (0x802D1CDC, "Geo18_802D1CDC"), // SSL
  (0x802D1E48, "Geo18_802D1E48"), // TTC
  (0x802D1FA8, "Geo18_802D1FA8"), // SSL
  (0x802D2108, "Geo18_802D2108"), // SSL/TTC
  (0x802D2360, "Geo18_802D2360"), // inside castle
  (0x802D2470, "Geo18_802D2470"), // RR
  (0x802D2520, "Geo18_802D2520"), // RR
  (0x802D28CC, "Geo18_802D28CC"), // cake end
  (0x802D5B98, "Geo18_802D5B98"), // TTM/HMC/inside castle
  (0x802D5D0C, "Geo18_802D5D0C"), // TTM/HMC/inside castle
  (0x8030D93C, "Geo18_8030D93C"),
  (0x8030D9AC, "Geo18_8030D9AC"),

(07-07-2015, 04:46 AM)Mr. GreenThunder Wrote: That seems kinda cool, do the crystals in the Metal Cap stage also make use of 0x18?

The crystals are loaded from a regular 0x15 command. The 0x18 commands in that geo layout seems to be only for the water/waterfalls.

(Metal Cap geo layout offset = 0x4BEB80)
004BEBE8 / 0E000208 [ 15 01 00 00 07 00 A1 60 ] -- Loads the metal crystals

I looked into the crystal's polygon script, and it's actually the 0xB7 command (Set Geometry Mode) that gives its crystallized look. Specifically setting the 19th bit from the right to 1 will do it.

0111BA6B / 0700A168 [ B7 00 00 00 00 04 00 00 ] // Set geometry mode
...
0111BAC3 / 0700A1C0 [ B6 00 00 00 00 04 00 00 ] // Clear geometry mode

It's a pretty trippy effect when you apply it to regular geometry  Bewilderment

[Image: XiJN5OY.png]
(As you can see in the far distance, I removed this crystal effect from the crystals themselves.)

The texture used by the crystals is located at the extended ROM address 0x1113103, play around with it to see what you like.
Spoiler: images
[Image: erIbhXP.png]

[Image: VNNjfmB.png]
(You can even add color!)
(07-07-2015, 04:46 AM)Mr. GreenThunder Wrote: And would it be possible to use a 0x18 command for a custom texture?

In theory, sure. My knowledge on the 0x18 commands is very shallow right now, so I can't say for sure. Like I know what some of them do, but I don't really know how they work exactly.

queueRAM Wrote:Nice job decoding that! I would like to clarify the second byte though. The code tests if the most significant bit is set, and if so, stores the lower 4 bits and grabs an additional word at offset 8 (making the command C bytes long). It passes the lower 4 bits in A2 and the additional word in A3 to proc_8037B940() which stores it in another structure (haven't chased it beyond that yet). I have not seen any 1D commands with this bit set though.

I apparently need a lot more practice with assembly, because I totally read that part wrong. I'm glad this community has some smart people in it, because I would hate to give out bad information.
(This post was last modified: 07-07-2015, 08:08 PM by David.)

I actually just tried to do it on a custom crystal model but all hell broke loose;
Spoiler: GIF
[Image: krap.gif]

Spoiler: Crystal Model
[Image: cyr.jpg]
Not quite sure why the Crytal's faces are missing maybe because I imported it as a custom object to make sure it didn't leak into the Level's polygon's data but apparently it did and uh Mario's face not sure why it's also missing... But that's at least start.
(This post was last modified: 08-07-2015, 06:24 PM by Nutta.)
Gone for a while.

Like queueRAM told you on IRC, this is happening because you don't have a matching
[ B6 00 00 00 00 04 00 00 ] // Clear geometry mode.
Put one at the end of your display list or at the beginning of the next one. You may need to overwrite another command you deem less important.

Have fun hacking!

After some assorted help from David, Jedi and queueRAM over IRC, I was able to get it work, but as a movable object unlike in the original game, turns out I forgot to add in a 0xB6 at the end of the display list.
[Image: penis.jpg]
(This post was last modified: 08-07-2015, 09:48 PM by Nutta.)
Gone for a while.

Does anyone know the method by which some display lists get assigned coordinates relative to special game objects?

If you don't know what I'm talking about, look at this picture:

[Image: Special_Object_parenting.png]

The image on the left shows all display lists imported into the scene in world space. The castle spire's geometry is actually not stored in world coordinates, but relative to a special object with id 0x65, which is why it appears in the wrong place. The image on the right demonstrates that it's coordinates should be relative to object 0x65.

Davideesk wrote some notes about these special objects, which are normally things like climbable trees in the game.

What I need to know is, how can I tell which display lists are children of which special objects? For levels like the castle grounds, it's easy to hard code this relationship, but some levels like Bowser in the Sky get pretty crazy with it. Does anyone know about this? Thanks!

(14-07-2015, 11:25 AM)Jedi Wrote: What I need to know is, how can I tell which display lists are children of which special objects? For levels like the castle grounds, it's easy to hard code this relationship, but some levels like Bowser in the Sky get pretty crazy with it. Does anyone know about this? Thanks!

Format: [01] [00 00] [74] [13 00 09 1C]
[01] - Preset ID
[00 00] - Extra Parameters (Mostly used for doors)
[74] - Model ID for Object
[13 00 09 1C] - Behavior Address for Object

65 01 00 03 13 00 2A 48

Models for objects are loaded through the level script commands 0x22 (Geometry Layout) and 0x21 (Polygon Script).

The castle tower uses the model ID 0x03, so the corresponding 0x22 command would be: [ 22 08 00 03 0E 00 06 F4 ]. The Geometry Layout for the castle tower model is located at the RAM segment 0x0E, offset 0x6F4.

Geometry Layout Commands 1 2 »
Users browsing this thread: 1 Guest(s)


  EN ・日本語