Water Boxes
Users browsing this thread: 1 Guest(s)

You likely should see THIS THREAD by David. Its much more complete!

​Original Post

For anyone who's interested: I've figured out parts to the water box parsing found in level command 2E:

The eternal star monument has a small pool of water in it, Looking at the corners you can see that they are set up to conceal the edges of the water box. So moving some trees (which have a pretty solid origin of reference) to the various integers in the 12 byte water box..
[Image: D3RdCLn.png]
Cryignore the position/rotation fields in the above image, these were just set to the shorts from the 2E command)
I figured out all but one of the six short 16 bit integers
[Image: 3p0Ez4y.png]

Each 12 byte water box has a layout of:
[?? ??]​ [xx xx] [zz zz] [XX XX] [ZZ ZZ] [YY YY]

While I cant' speak for the first 16 bits:
​x,X = X min and max positions
​z,Z = Z min and max positions
Y = Y position

So interchanging x,X and z,Z with the single Y gets you the four corner positions of the water box.

The first ?? 16 bits seems to be some sort of order or ID as every water box in each area has a unique value. It seems like when the ?? value is 50 or greater ( it could be lower than that threshold ) the water plane is not swimmable, but rather is some sort of haze like in HMC. otherwise swimmable boxes have ?? 0, 1, .. (but not always in the same order they are written in, which makes me think that this number is related to something like the surface area largest(0) to smallest or something about the X or Z points (Tall tall mountain seems to go in order of Y low to Y high, but JRB does not follow this)
[Image: 3ZH92KO.png]

While I haven't tried having water boxes overlap, I'm guessing doing so with swimmable boxes is probably something that would be good to avoid (although Hazy/ non swimmable boxes are often directly on top of eachother). One thing I wanted to check was the secret aquarium which has a water box you think it would (if you thought it had any, which I was unsure of):
[Image: OPYugwq.png]

​The 2E command code
​The WaterBlock constructor
Sorry if the lines change in the links above

more images
(This post was last modified: 26-10-2017, 06:08 AM by Arbys. Edit Reason: Linked to David's thread )

I did some digging on the water boxes back in april, and compiled my notes on this thread if you want to see them. 

The 0x2E command defines the collision of the water box, and the visual part is created by a geo layout 0x18 command. I do believe that the first two bytes are some sort of id variable that connects it to the visual part, though I haven't dug deep into the game's code. Most of my testing was done from trial and error.

Spoiler: Notes from thread
(Using castle grounds for example)

Defining water box collision data in level-script command 0x2E.

00 44 // Start defining water boxes
​00 02 // Number of water boxes to be loaded.
​00 00 E4 27 E3 CA 20 3D FF C6 FF AF // Water box 1 collision data
​00 01 04 00 FF C6 20 26 1F C9 FF AF // Water box 2 collision data

struct WaterBoxCollision { 
     s16 id; // id that is used to link to the visual part of water box.
     s16 x1; // x coordinate of first end-point 
     s16 z1; // z coordinate of first end-point 
     s16 x2; // x coordinate of second end-point 
     s16 z2; // z coordinate of second end-point 
     s16 y;  // y coordinate representing how tall the water box should be

if id < 0x32 
   then it is a swimmable water box. (Range: -32,768(0x8000) to 49(0x0031))
else if id == 0x32 OR id == 0xF0 
   then it is toxic haze.
   it does nothing (JRB mist).

The water boxes are drawn in-game using the geo layout 0x18 command that use the function 0x802D104C

[ 18 00 XX XX 80 2D 10 4C ]
​XXXX = Hard-coded parameter, which is used to get a segmented address to the visual data (from function 0x802D0C84)

Spoiler: Parameters to choose from
0x0400 = 07026E24
0x0401 = 07026E34
0x0501 = 07016708
0x0600 = 070790F0
0x0612 = 07079100
0x0701 = 0702B900
0x0702 = 0702B950
0x0801 = 07012778
0x0851 = 070127C8
0x1001 = 0700FA70
0x1101 = 07018748
0x1102 = 07018778
0x1201 = 0700D2CC
0x1202 = 0701139C
0x1205 = 0700D304
0x1301 = 0700E31C
0x1302 = 0700E39C
0x1601 = 07011738
0x2202 = 07028780
0x2301 = 0700FCB4
0x2302 = 0700FD00
0x2401 = 07011E08
0x2601 = 07006E6C
0x3601 = 07017124

00454DC4 / 0E0007E4 [ 18 00 16 01 80 2D 10 4C ] //  Loads the water boxes in the castle grounds level

​// 1601 = 07011738
​0000 0000 070116F8 // Water box 1
​0001 0000 07011718 // Water box 2
​FFFF // End of list of water boxes

struct WaterBox { 
     s16 id; // id that is used to link to the collision of water box.
     s16 _0x02;
     u32 quad_seg_ptr; // Segmented pointer to the water box visual data. (which I refer to as "struct WaterBoxQuad")

struct WaterBoxQuad {
     s16 visibilty; // -1 = Make all water boxes in list invisible, 0 = invisible, 1 = visible
     s16 _0x02;
     s16 rotation_speed; // negative values make it rotate the opposite way.
     s16 scale; // Number of repeats in texture
     s16 x1; // X position of vertex 1
     s16 z1; // Z position of vertex 1
     s16 x2; // X position of vertex 2
     s16 z2; // Z position of vertex 2
     s16 x3; // X position of vertex 3
     s16 z3; // Z position of vertex 3
     s16 x4; // X position of vertex 4
     s16 z4; // Z position of vertex 4
     u16 rotation_direction; // 0x00 = clockwise, 0x01 = counter-clockwise.
     u8 _0x1A;
     u8 transparency // 0x00 = fully transparent, 0xff = fully opague
     u16 texture_id // 0 = water, 1 = mist, 2 = JRB water, 4 = lava, etc.
     u16 _0x1E;
(This post was last modified: 25-10-2017, 11:59 PM by David.)

(25-10-2017, 10:09 PM)David Wrote: I did some digging on the water boxes back in april, and compiled my notes on this thread if you want to see them.

Thanks so much for the reply and pointing me to this! I will integrate these immediately.

Also, thanks for Quad64. You did a great job in setting everything up! I've realized that many of the things you put into Quad64 required research on your own behalf and I deeply appreciate that.

A little off-topic but, I was curious if you have any notes on skyboxes beyond what you found with the background geo command. I understand the usage of that command but am not entirely sure where in rom the resources are for the different options with the non-zero byte. Could it be something thats copied into ram from rom?


Thanks again for the notes David, I added in the drawing of the water boxes utilizing those addresses and lookups from the asm function.
I believe i got the WaterBoxQuad's fields properly initialized:
Spoiler: code
[Image: PwgDsj9.png]
(First water box from grounds, two in total just like the collision data)

However, I am a bit confused on the 0x020175F0 / Start water segment address. In the code above, at the end I'm effectively running the display list at 0x020175F0 and afterwards, filling the vertex buffer and putting triangles in (then it jumps out before restoring material state). I resorted to this after trying to just populate the vertex buffer and have the display list run the triangles was not what happened (unless its using quads?).

Right now when I do this I get:
[Image: Ib3CW5H.png]

I'm doing nothing with the texture ID (0=water etc,) though, is there another lookup to load those into the display list? Also, since it seems there is no Y in the visuals, I've offset the geo node by the value in collision when its parsed after the area layout but am not sure if thats right, although it matches up.

Any thoughts would be appreciated, Thanks.

(Also, That blue tint is from drawing the collision, I don't think the dp call is changing the lighting atm)
(This post was last modified: 26-10-2017, 03:26 PM by Arbys.)

Water Boxes
Users browsing this thread: 1 Guest(s)

  EN ・日本語