Castle Paintings

[David]

I looked back to my old geometry layout 0x18 command notes and figured out how to edit the paintings inside the castle; so I thought I would share some new notes on how the castle paintings work.



Setting up paintings requires at least 2 0x18 commands in the geometry layout:

[ 18 00 00 00 80 2D 5D 0C ] -- Processes Mario's position (Used for the ripple effect)
[ 18 00 XX YY 80 2D 5B 98 ]​ -- Renders a painting
The XX parameter tells the game which painting list to use (0 = HMC pool, 1 = Castle Paintings, 2 = TTM slide entrance), while the YY parameter tells the game which painting in that list to use.

Spoiler: Painting list

(XX == 0)
00 = Shiny black pool in HMC = [07 02 55 1C]

(XX == 1)
00 = Bob-omb's Battlefield = [07 02 36 20]
01 = Cool-cool Mountain = [07 02 36 98]
02 = Whomp's Fortress = [07 02 37 10]
03 = Jolly Roger's Bay = [07 02 37 88]
04 = Lethal Lava Land = [07 02 38 00]
05 = Shifting Sand Land = [07 02 38 78]
06 = Hazy Maze Cave (Shiny black pool) = [07 02 38 F0]
07 = Dire Dire Docks = [07 02 39 68]
08 = Wet Dry World = [07 02 39 E0]
09 = Tiny Huge Island (Tiny painting) = [07 02 3A 58]
0A = Tall Tall Mountain = [07 02 3A D0]
0B = Tick Tock Clock = [07 02 3B 48]
0C = Snowman's Land = [07 02 3B C0]
0D = Tiny Huge Island (Huge painting) = [07 02 3C 38]

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

Each segmented address you see in the painting list points to a C structure containing information on that painting.

Painting struct (0x78 bytes)

Offsets:
(u16) 0x00 - Index in a list?
(u8) 0x02 - List number?
(u8) 0x03 - Render texture mode? 0 for Normal paintings, 1 for shiny textures (DDD and shiny HMC pool).
(u8) 0x04 - Previous value of 0x05 [see function 0x802D3A2C]
(u8) 0x05 - Current painting collision(s) being processed** [see function 0x802D3A2C]
(u8) 0x06 - (painting->0x04 XOR painting->0x05) AND painting->0x05 [see function 0x802D3A2C]
(u8) 0x07 - Ripple flag. 0 = not rippling, 1 = infront of painting, 2 = jumped into painting
(float) 0x08 - Rotation around X-axis
(float) 0x0C - Rotation around Y-axis
(float) 0x10 - X position
(float) 0x14 - Y position
(float) 0x18 - Z position
(float) 0x1C - Current ripple height
(float) 0x20 - Ripple height (infront of painting, copied to offset 0x1C)
(float) 0x24 - Ripple height (jumping into painting, copied to offset 0x1C)
(float) 0x28 - Current ripple height multiplier
(float) 0x2C - Ripple height multiplier (infront of painting, copied to offset 0x28)
(float) 0x30 - Ripple height multiplier (jumping into painting, copied to offset 0x28)
(float) 0x34 - Current ripple pattern?
(float) 0x38 - Ripple pattern? (infront of painting, copied to offset 0x34)
(float) 0x3C - Ripple pattern? (jumping into painting, copied to offset 0x34)
(float) 0x40 - Current size of ripple wave
(float) 0x44 - Size of the ripple wave (infront of painting, copied to offset 0x40)
(float) 0x48 - Size of the ripple wave (jumping into painting, copied to offset 0x40)
(float) 0x4C - Ripple seed or timer?
(float) 0x50 - X position of ripple center
(float) 0x54 - Y position of ripple center
(u32) 0x58 - Segment address to painting F3D cmds.
(u32) 0x5C - Segment address to another segment address to ???.
(u32) 0x60 - Segment address to another segment address to the painting texture.
(u16) 0x64 - ripple painting texture offset?
(u16) 0x66 - ripple painting texture offset?
(u32) 0x68 - A segmented address. 0x07022640, 0x07021AC0. ???
(u8) 0x6C - ??? usually 0x0A or 0x14
(u8) 0x6D - Transparency while rippling.
(u8) 0x6E - Previous value of 0x6F [see function 0x802D3A2C]
(u8) 0x6F - *((float*)0x80361308) < painting->0x14 ? 1 : 0 [see function 0x802D3A2C]
(u8) 0x70 - (painting->0x6E XOR painting->0x6F) AND painting->0x6F [see function 0x802D3A2C]
(u8) 0x71-0x73 - Unused bytes
(float) 0x74 - Size of painting

** collision values are: 0x20(painting wobble left side), 0x10(painting wobble middle), 0x8(painting wobble right side), 0x4(level entrance left side), 0x02(level entrance middle), or 0x01(level entrance right side).
​So, where is the data in the ROM file and in RAM?

The painting data is loaded into memory as soon as the game boots up. You can find the list pointers starting at ROM address 0xEC34C, which is loaded into RAM at 0x8033134C. You will have to look at the level script 0x17 command to find out where segment 0x07 is loaded from.

If you have any questions or additions to the topic, please leave a reply below. I'll try to update the main post as much as I can.

[Nutta]

DOES THIS MEAN... we can stop having nonsolid boxes with a warpbox behind as paintings?

[David]

(16-08-2016, 06:21 PM)Mr. GreenThunder Wrote: DOES THIS MEAN... we can stop having nonsolid boxes with a warpbox behind as paintings?

​

Paintings should work in custom levels just fine, though I haven't tested it out yet. 

Skelux can probably come up with a simple painting editor for a future version of the SM64 Editor. For the visual part all he would have to do is modify the painting structs and add the 0x18 commands to the geometry layout for that level. The collision for the painting is a bit more complicated as there are 6 dedicated collision ID's for each painting (The black shiny pool might be an exception), but the user could just add that in themselves.

Spoiler: Painting Collision ID's (Notes by Shygoo)

A6 Painting wobble (BoB 1)
A7 Painting wobble (BoB 2)
A8 Painting wobble (BoB 3)
A9 Painting wobble (CCM 1)
AA Painting wobble (CCM 2)
AB Painting wobble (CCM 3)
AC Painting wobble (WF 1)
AD Painting wobble (WF 2)
AE Painting wobble (WF 3)
AF Painting wobble (JRB 1)
B0 Painting wobble (JRB 2)
B1 Painting wobble (JRB 3)
B2 Painting wobble (LLL 1)
B3 Painting wobble (LLL 2)
B4 Painting wobble (LLL 3)
B5 Painting wobble (SSL 1)
B6 Painting wobble (SSL 2)
B7 Painting wobble (SSL 3)
B8 Painting wobble (?)
B9 Painting wobble (?)
BA Painting wobble (?)
BB Painting wobble (BFS)
BC Painting wobble (BFS?)
BD Painting wobble (BFS?)
BE Painting wobble (WDW 1)
BF Painting wobble (WDW 2)
C0 Painting wobble (WDW 3)
C1 Painting wobble (THI t 1)
C2 Painting wobble (THI t 2)
C3 Painting wobble (THI t 3)
C4 Painting wobble (TTM 1)
C5 Painting wobble (TTM 2)
C6 Painting wobble (TTM 3)
C7 Painting wobble (?)
C8 Painting wobble (?)
C9 Painting wobble (?)
CA Painting wobble (SML 1, unused)
CB Painting wobble (SML 2, unused)
CC Painting wobble (SML 3, unused)
CD Painting wobble (THI h 1)
CE Painting wobble (THI h 2)
CF Painting wobble (THI h 3)
D0 Painting wobble (Metal cap)
D1 Painting wobble (Metal cap?)
D2 Painting wobble (Metal cap?)
D3 Horizontal level entrance (still have to label these)
D4 Horizontal level entrance ()
D5 Horizontal level entrance ()
D6 Horizontal level entrance ()
D7 Horizontal level entrance ()
D8 Horizontal level entrance ()
D9 Horizontal level entrance ()
DA Horizontal level entrance ()
DB Horizontal level entrance ()
DC Horizontal level entrance ()
DE Horizontal level entrance ()
DF Horizontal level entrance ()
F0 Horizontal level entrance ()
F1 Horizontal level entrance ()
F2 Horizontal level entrance ()
F3 Horizontal level entrance ()
F4 Horizontal level entrance ()
F5 Horizontal level entrance ()
F6 Horizontal level entrance ()
F7 Horizontal level entrance ()
F8 Horizontal level entrance ()
F9 Horizontal level entrance ()
FA Horizontal level entrance ()
FB Horizontal level entrance ()
FC Horizontal level entrance ()
FD Vertical level entrances ?

[David]

I've spent the past few hours trying to fill out the painting struct, which is updated on the main post above. I believe that I got most of it, but it still has a few unknowns that I'll look into another day. Here are my current notes including the structure, RAM & ROM addresses, and some of the ASM functions if anyone is interested.

[Kaze]

interesting finds, i remember years back i accidentally deleted my documents on this and never found the motivation to look into them again. If you want to find the warp ID it assigns, 8033b256 could be useful. (dont see those in the docs yet)

[queueRAM]

I've been working on decoding all the data in segment 02 (the font and HUD textures inflated from MIO0 block 0x108A40). There are some peculiar data at the end of the file starting at segmented address 0x020178C0 that didn't fit texture, F3D, or dialog patterns. I dug into it more and found the code that uses it and it is related to the castle paintings. It is the vertex and triangle data used to form the castle paintings mesh. Function at address 802D556C looks up the virtual address from 0x020178C0 and reads the vertex and triangle counts below. It then passes this data to functions 802D3EE4, 802D404C, and 802D44BC for loading.

The data takes the following format, offsets relative to segment 02 base (think this is at 0x81AA16 in extended ROM)

Code:

​178C0-178C1: u16 vertex count (0x009D=157)
178C2-17C6F: i16 x, y, z vertices (157*6 bytes)
17C70-17C71: u16 triangle count (0x0108=264)
17C72-182A1: u16 3x triangle indexes (264*6 bytes)
182A2-18A0D: TODO - looks like more indexes, but higher than vertex count. maybe triangle indexes?

Something like this is relatively easy to parse into OBJ format. This is what the mesh looks like:

It looks flat, but there is a small variation in the Z axis.

[ThunderAliG]

Maybe someone (Maybe supermariosan100 since he's already got paintings working in custom levels) could make a patch or tweak to add paintings into custom levels, Just a suggestion

[David]

(18-11-2016, 09:56 PM)ThunderAliG Wrote: Maybe someone (Maybe supermariosan100 since he's already got paintings working in custom levels) could make a patch or tweak to add paintings into custom levels, Just a suggestion

​

You can't really add objects/scripts on to custom levels using tweaks or patches alone. Someone would need to make a tool to edit the geometry layout scripts and collision data to add paintings into custom levels (which is not too difficult to do). 

You ask Mr. Skeletons if he could add it into a future version of the SM64 Level Editor.

[supermariosan100]

(18-11-2016, 10:36 PM)David Wrote:

(18-11-2016, 09:56 PM)ThunderAliG Wrote: ​
Maybe someone (Maybe supermariosan100 since he's already got paintings working in custom levels) could make a patch or tweak to add paintings into custom levels, Just a suggestion

​

You can't really add objects/scripts on to custom levels using tweaks or patches alone. Someone would need to make a tool to edit the geometry layout scripts and collision data to add paintings into custom levels (which is not too difficult to do). 

You can see if Mr. Skeletons could add it into a future version of the SM64 Level Editor.

​

I think Skelux should consider making this a feature in any upcoming level importer updates.
I consider it to be too time consuming to get them to work in custom stages, let alone multiple. I would love to see it included one day.

[Benedani]

Considering (I think) the painting is inside the level's geometry layout which you can find out with looking at the conversion logs, I think a tool could be easily made to add paintings. However, it would still limit it to having x amount of paintings. Someone just HAS to work on a patch to allow for more paintings if we manage to get that stuff working. Also, imagine some people (maybe even me...?) making a level editor which allows for paintings to be rendered and edited. That would be SOOOO awesome!