|
Time: Now - Date: Today - Weather: What can be seen outside. - Mood: How it feels. Answer to the universe: 42
|
Originally posted by yoshiman
One of the object variables is a pointer to the behaviour coding, for all we know there might be unused behaviours? This was how, for example, I made a ghost Peach by using the Big Boo behaviour pointer; the behaviour coding can be used in any level. But be warned, some behaviour pointers cause the game to crash if used with certain objects, this may be due to the coding finding values within the object structure that it doesn't 'like.'
I really need to look at the ASM in more detail, see how it handles the object behaviour. Compared to Ocarina of Timer and Resi Evil 2 on the N64 that I know quite a bit how the objects are handled, SM64 although simple has features that perhaps were planned to be used at one time. For example, you can rotate an object's collision idependent of the actual object rotation so you can, for e.g., read only the back or side of a signpost.
We really need to take SM64 apart, I'm sure there is something hiding...
James S.
As I've said in the other thread, if the behavior pointers are the same as those that are set by ROM level commands, you might be interested in this document: http://homepage.mac.com/qubedstudios/SM64Behaviors.txt
The behavior pointers (13XXXXXX) refer to what I've called "behavior scripts" which are a few commands that set different aspects of the behavior for a given object. Behavior scripts can, amongst other things, set the animation sequence of an object (using the 0x27 command). The 0x27 command is described in more details in this thread: http://jul.rustedlogic.net/thread.php?id=954
Other behavior commands include one to set the collision map of a single object (0x2A) and other commands can spawn sub-objects (0x1C, 0x29 and 0x2C). The 0x0C command calls ASM routines found in RAM, and this is where the real magic happens.
[0C] [00 00 00] [80 2A CC 3C]
[0]= 0C is the command byte.
[1,2,3]= Always zero, unused?
[4,5,6,7]= Offset in RAM of the ASM function.
I haven't studied much of the ASM routines that are referred by the 0x0C commands, but once we reverse-engineer most of it, we'll be able to do very interesting stuff.
Originally posted by yoshiman
I know a lot about the so-called 'RAM objects,' I'm putting a list together about the different variables that belong to a structure. From what I understand, the level details only set a few of the variables such as position and rotation, very much as is the case of Ocarina of Time. However, the level details are copied to the RAM in Ocarina of Time but this does not seem to be the case for SM64.
At which address the RAM objects are stored?
The ROM level commands are also copied to RAM in SM64, like in OOT. I guess you just didn't stumble on them.
Originally posted by HyperHacker
I doubt that's really support for planned but unused features so much as just quirks of the way it's programmed. Many games have collision maps and actual level models separate for speed reasons (the collision map can have much less detail/fewer polygons since it's invisible), so you can make them mismatch if you want.
Originally posted by yoshiman
But be warned, some behaviour pointers cause the game to crash if used with certain objects, this may be due to the coding finding values within the object structure that it doesn't 'like.'
I'd guess it's more likely the code tries to reference a part that isn't in that model.
We're still looking for the Blargg behavior script. There's still a lot of undefined and un-referenced behavior scripts so there's still hope. I also more recently found the animation command pointer for the Blargg: it's 05 00 61 6C. So not only the model is still there, but also the animation data.
Some behavior scripts are dependent on data that's only present in certain levels. Those include behavior scripts that refer to collision data found in a specific memory bank (segment), or those that refer to animation data.
While some object indeed have polygonal collision maps (levels, platforms, boxes etc.), many enemies and Mario himself don't use polygons for collision detection. Because of the complexity of the body, and the fact that it's animated, a spherical collision bubble is instead used. There's no polygon involved, it's only a matter of detecting a collision if the distance between objects is less than X. This is how most 3d games worked until more recently when more powerful and precise physics engines were implemented in games.
Just a little note, the current thread is a related to this thread: http://jul.rustedlogic.net/thread.php?id=1607 (which was trashed).
yoshiman (aka James S.) is an experienced SM64 "RAM hacker" that can bring a lot to the SM64 hacking community because of his discoveries. More on his website at http://james.boshikoopa.googlepages.com/game_codes and http://james.boshikoopa.googlepages.com/game_hacking
____________________
|
  |
|
|