Has anyone managed to get the 0x1D scaling command working on a level's geometry? This could potentially be used to extend the level boundaries much further than previously possible. I had a brief attempt at it myself, but it crashed.

(15-07-2015, 01:57 PM)Skeletons Wrote: Has anyone managed to get the 0x1D scaling command working on a level's geometry? This could potentially be used to extend the level boundaries much further than previously possible. I had a brief attempt at it myself, but it crashed.

​

The 0x1D command effects everything in the following node (Between the 0x04 & 0x05 commands). The long 0x17 command doesn't seem to like the scaling command, so you need to nest the 0x15 display list by itself like this:

Spoiler: images

​

​

How do display lists effect the level boundaries anyway? I would've thought that the game would only look at the collision map for that sorta thing, or is this something related to your importer?

For 0x02, I would recommend different terminology than 'branch' and 'jump' because they effectively mean the same thing (although branch generally being relative and jump absolute). I'd recommend 'jump' and 'jump and link' since they are absolute addresses and one variant saves the return address.

The ASM code of this command branches based on the first digit of the AA byte, but the game crashes if I try to use something other than 0x00. BB seems to be used in the code when AA != 0x00.

​

I am still trying to figure out what is going with AA in command 10. It looks like the code first masks bits 5-7 (0x70) and compares those bits with 4 different AA cases (0, 1, 2, 3) to determine how the following data is handled.
AA = 0 reads X,Y,Z as s16 and RX,RY,RZ by: (val << 15) / 180
AA = 1 reads X,Y,Z as s16 and RX,RY,RZ as s16 (although using different function)
AA = 2 reads X,Y,Z by: (val << 15) / 180 and RX,RY,RZ as s16
AA = 3 does something different, reading X,Y,Z as s16, then (val << 15) / 180 for one of the values?

I'm still unclear on what the remaining bits in AA do. I see some geo layout 0x10 commands for some enemies have the upper and lower bits (0x81) of AA set.

Someone can write some custom ASM code to make the background fade into different colors, so there is potential to make a real-time day/night cycle that doesn't make a huge impact on performance. Of course you would need to put something in the background to make it look more a little bit more interesting.

0x8033B910 contains a pointer to a struct(or is it an array of stucts?) with some settings created from the geo layout commands. Like the values from the 0x08 cmd (set screen render area) are also stored there and can also be changed on the fly.

Some of the functions defined by n64split seem to refer it as a "SceneGraphNode". Do you have any more information on that?

​Edit:​
Turns out that 0x8033B910 is a more consistent pointer than 0x8038BCA4, so we should probably use that instead.

Also wrote some custom ASM code that will change the background color in the current level. Each color value has 5 bits, so it can only go up to 0x1F (31). If anyone wants to play around with it to see how it works heres a link to the sourse: http://pastebin.com/raw/xBbgLpv0