SM64 Help Thread « 1 ... 28 29 30 31 32 »
Users browsing this thread: 1 Guest(s)

(09-01-2017, 12:52 AM)Gamecubed Wrote: Does anyone know how to convert .xml?

...
https://www.youtube.com/watch?v=hxLNVBd9KSo&index=10&list=PLY9TGb7t9kuFLFIub-I3IOpi6NNsIL413 Smile
If you like well-modeled and fun to play content, check out my current Super Mario 64 hack, Superstar Plumber!
It's Greeny approved!

Danks man.
Got Akira Himegawa's 10 Zelda Manga's for christmas, I can die happy now.

For my program, I have to find the polygon data of a particular level to render it. Is it possible to do that having the level script and the associated geo layout? Do they contain any pointer to where the level's mesh is located on rom? I also was wondering if polygon data of any kind is always stored as F3D commands in a display list (I'm still noob to F3D, but it's quite hard to find some good documentation).

PS: It looks like n64split already do a similar work, but it looks like it only retrieves the collision meshes instead of the model that is rendered in game. They are quite similar and I could temporarily use the collision mesh, but I would prefer to learn how to get the visual mesh, also because afterwards I would like to be able to draw 0x24 objects.

You need the debugger to find vertexes in space.

You need to get a texture of what you want the poly of's start ram adress, and find an FD 10 00 00 | XX AD RE SS whereas xx is the ram bank. if its 80 i can help you, if not its segmented and you should ask the goo shy. now find a nearbye 01 adress where his ram adress finishes in either 0, 4, 8 or C, now that you have the closest to the fd command look at the code it will be 01 XX XX XX | 80 XX XX XX. you now will copy the second part (80 XX XX XX) and copy the first line of code, paste it in hxd search and you found the vertex adress for the poly with that texture. If you dont find anything it shouldnt happen but if it does set a write breakpoint and go out and in to the level. The debug emulator will display in wich compressed block it is. (Im not sure but i think that the extended sm64 rom has everything decompressed so the last step should never happen.

WARNING: Don't take for granted that this will work. its written for F3DEX2 but i think it should work also in normal fast 3d.

Thanks, but I need to get the data procedurally and on the fly, since my program loads a level script in order to render it. So I have to take the pointers from the scripts and convert them into rom addresses if they are ram addresses or segmented addresses.

(10-01-2017, 02:21 PM)Fendoroid Wrote: Thanks, but I need to get the data procedurally and on the fly, since my program loads a level script in order to render it. So I have to take the pointers from the scripts and convert them into rom addresses if they are ram addresses or segmented addresses.

You could write the adresses for all the vertexes in a file or inside the program and use that for getting the adresses and info in the program

I've a question about warps: in most level scripts, there are some warp connections (0x26 commands) that have "warp ID from" parameter setted with values 0xF0, 0xF1, 0xF2 or 0xF3. But there is not any warp with any of these ID. Do these connect warps for when you take a star, die, or such stuff?

(13-01-2017, 03:57 PM)Fendoroid Wrote: I've a question about warps: in most level scripts, there are some warp connections (0x26 commands) that have "warp ID from" parameter setted with values 0xF0, 0xF1, 0xF2 or 0xF3. But there is not any warp with any of these ID. Do these connect warps for when you take a star, die, or such stuff?

Those warps are basically used for special cases like you mentioned. 

0xF0 is used for when Mario collects a star or a key from Bowser.
0xF1 is used for when Mario dies.
0xF2 is used in the castle lobby for entering the Wing Cap stage.
0xF3 is used in Dire Dire Docks, Metal Cap, & Rainbow Clouds to warp Mario to the castle grounds.

I haven't dug too deep into the warp system itself, so I don't really know that much about it. Here are a few things that I know so far, which might be useful for anyone who is playing around with warps.

RAM addresses:
0x8033B252 (u16) = actives warp timer if not zero
0x8033B254 (u16) = warp timer (mario warps when it reaches zero)
0x8033B256 (u16) = warp ID to use when warping

Warping to the same Level ID as the one you're currently in will NOT reload the level. You would have to dedicate 2 level ID's to the same level if you want to do that.

A cool little ASM trick you can do is look at 0x8033B256 to see if Mario died (0x00F1) or got a star (0x00F0) in the previous level, then you can execute some custom code based on what happened even before the level has even loaded by using a level script 0x11 command at the start of the levelscript.
(This post was last modified: 14-01-2017, 03:59 AM by David.)

(14-01-2017, 03:59 AM)David Wrote: ...
Thanks David!


There's something that I don't get about macro objects. I know that they are all loaded through the 0x39 command, and I can actually find the object placement list in segment 7. However, it looks like there is no information about where the list ends, or how many macro objects should be loaded. What am I missing?

(21-01-2017, 06:06 PM)Fendoroid Wrote: There's something that I don't get about macro objects. I know that they are all loaded through the 0x39 command, and I can actually find  the object placement list in segment 7. However, it looks like there is no information about where the list ends, or how many macro objects should be loaded. What am I missing?

You need to look for a preset that starts with 0x001E or 0x0000, which will end the macro list.

Spoiler: VL-Tone's notes
----------------------------------------------------------------------------
| Object format for objects loaded using 0x39 (called 0x42 objects in TT64)|
----------------------------------------------------------------------------

Each object loaded with this command is dec 10 bytes long.
[01] [1F] [01 04] [02 DF] [07 80] [00 00]

[1,2]: First 7 bits = Horizontal rotation, last 9 bits are the model/behavior preset number.
Value 1E or 00 as type will end the object list and complete the 0x39 command.
[3,4] [5,6] [7,8]: X Y and Z position in level as 16-bit signed integers
[9,10]: Behavior parameters that will override the ones from the presets.

The preset table used by these commands is found at EC7E0 in the ROM.

There are 366 of them, and the first one in the table is defined as preset 01F.

Here's the format for the table:

1F= [13 00 09 1C] [00 74] [00 00]

[1,2,3,4]: RAM segment number and offset for behavior code to be attached to this object
[5,6]: Model ID number as defined by 0x21 and 0x22 commands
[7,8]: Parameters to be fed into the behavior code, usage varies depending on which behavior
Spoiler: Macro preset list for Metal Cap level
00 4A F4 98 00 DC FF EC 00 00 // Snufit enemy
00 4A FA 9C 00 F0 02 E4 00 00 // Snufit enemy
00 5C FE 98 01 2C FF 38 00 00 // [!] Metal Cap Box
00 4A 01 68 00 C8 FB A0 00 00 // Snufit enemy
00 25 01 90 01 00 EF 34 00 00 // Coin formation
00 5C 01 2C 02 6C EB 60 00 00 // [!] Metal Cap Box
00 4A FE AC 01 04 F5 C4 00 00 // Snufit enemy
00 26 00 00 FE 3E E4 A8 00 00 // Coin formation
00 4D 03 84 01 04 F1 DC 00 00 // 1-up mushroom
00 25 00 00 FF 56 F9 84 00 00 // Coin formation
00 25 FF EC FF 2D F0 9C 00 00 // Coin formation
C0 34 FF B9 00 14 02 D0 00 7B // Signpost
00 23 00 C8 FE DD EA 20 00 00 // Red coin
00 23 03 D4 01 04 F2 9A 00 00 // Red coin
00 23 FD E4 FE A0 E8 CC 00 00 // Red coin
00 23 FE D4 01 C2 E7 A0 00 00 // Red coin
00 23 FF 38 FE 70 E5 E8 00 00 // Red coin
00 23 00 FA 01 C2 E7 00 00 00 // Red coin
00 23 02 1C FE 97 E7 3C 00 00 // Red coin
00 23 03 D4 01 04 F1 1E 00 00 // Red coin
00 6E FF EC 00 B4 08 0C 00 00 // [!] 1-up Box
00 1E // End Macro List
I made a post on smwcentral a long time ago about macro & special objects, which may or may not be helpful to you. 
Link: http://smwc.me/1207463

SM64 Help Thread « 1 ... 28 29 30 31 32 »
Users browsing this thread: 1 Guest(s)