Register - Login
Views: 99796970
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users
Ranks - Rules/FAQ - Stats - Latest Posts - Color Chart - Smilies
05-03-22 05:47:43 AM
Jul - SM64 Hacking (Archive) - SM64 Water Hex Hacking (Geeky stuff) New poll - New thread - New reply
Pages: 1 2 3 4Next newer thread | Next older thread
VL-Tone
Member
Super Mario 64 forum moderator
Level: 53


Posts: 279/621
EXP: 1136482
For next: 20637

Since: 07-27-07

From: Montreal, Canada

Since last post: 4.7 years
Last activity: 6 days

Posted on 09-23-08 04:43:50 AM Link | Quote
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
Hmm I just realized that I missed a few posts in this thread. There are interesting developments happening.

It's a shame that the 0x18 command requires a ram pointer that refers to another pointer instead of using the actual polygon data pointer as a parameter, I wonder why they choose such a convoluted method. This will make integration of water areas in the importer a much complicated affair.

Using a 0x24 object to make the water polygon is a good idea, and with the object importer you'll be able to do something like this. But, standard water/lava polygons have some particularities that the imported objects wouldn't have. The water and lava is animated, and the water texture is scrolling in a direction and speed linked to the current that's defined by some special collision commands that are used on the floor of some water areas. The current can dynamically change depending on where Mario is, and 0x24 objects wouldn't provide this nicety.

____________________
messiaen
Catgirl
Level: 68


Posts: 267/1085
EXP: 2596322
For next: 132478

Since: 11-20-07


Since last post: 8.1 years
Last activity: 7.2 years

Posted on 09-27-08 12:33:09 PM (last edited by messiaen at 09-27-08 10:59 AM) Link | Quote
It gets more messy than that! I looked at this other "water" function found in the Castle Grounds Level Mesh Geo Layout:

1800 1601 802D 104C <-- Loads two water polygons areas (under the bridge and near the start)

It seems to be a very general water function, and the "1601" is an argument which leads to a hardcoded pointer (not loaded from the checksum area but as immediate instructions) value 0x07011738.

Here is what is found at 0x11738 of Castle Grounds:

00FD8F3F 0000 0000 0701 16F8 0001 0000 0701 1718
00FD8F4F FFFF

Two more (numbered) pointers, which seems logical because there are two water area polygons loaded by the 0x18 command above. Subtracting 0x11718 - 0x116F8 = 20, so that's probably the lenght of each command. Look at the data:

0x116F8:
0001 0000 0014 000F E427 E3CA E427 FFC6
203D FFC6 203D E3CA 0001 0096 0000 0000

Hmm, are these coordinates of some type? [Rememer the water polygons are a simple rectangle]

0x11718:
0001 0000 000F 000A 0400 FFC6 0400 1FC9
2026 1FC9 2026 FFC6 0000 0096 0000 0000

The value pointed by the "Waterfall" function is 0x11750. I'll just paste everything from this point
to the end of the Bank 0x07:

Edit: It's been a long time since I read this thread, so I just realized now that this is the same data found by VL-Tone on the first post, I just found the pointers which calls them. With some ASM work, these can probably be flexibilized to create new water areas (in custom levels). Waterfall data, however, seems to be different.

____________________
Mario 64 notes @ http://sites.google.com/site/messiaen64/
Pages: 1 2 3 4Next newer thread | Next older thread
Jul - SM64 Hacking (Archive) - SM64 Water Hex Hacking (Geeky stuff) New poll - New thread - New reply


Rusted Logic

Acmlmboard - commit 47be4dc [2021-08-23]
©2000-2022 Acmlm, Xkeeper, Kaito Sinclaire, et al.

29 database queries.
Query execution time: 0.094589 seconds
Script execution time: 0.007747 seconds
Total render time: 0.102336 seconds