 Register - Login |
||
 |
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - JCS - Stats - Latest Posts - Color Chart - Smilies |
|
Register - Login |
||
|
Main - Memberlist - Active users - Calendar - Wiki - IRC Chat - Online users Ranks - Rules/FAQ - JCS - Stats - Latest Posts - Color Chart - Smilies |
|
| Jul - Posts by yoshiman |
| Pages: 1 2 3 4 5 |
| yoshiman Member Level: 21     Posts: 1/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| It was me who created the pick up Peach code as can be viewed on YouTube (search for yoshielectron). The reason why Peach appears as she should is because I've bothered to include her animation pointer. One pointer indicates which gfx structure the object uses. And for animated objects you use the animation pointer otherwise you get a messed up object. |
| yoshiman Member Level: 21 Posts: 2/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| Hello everyone, James here! Actually, I do ROM hacking including swapping Mario's gfx for Peach, though that's may be too difficult... Anyway, there aren't two Peach models. Within an object structure you can set the level of transparency an object uses, though it doesn't affect all object graphics. So, after the end of the opening sequence, Peach's behaviour coding causes her to fade to completely transparent. But it's a simple matter of changing that value within the object structure so that Peach can be seen. RAM hacking does have big advantages including the use of gameshark like codes, however, ROM hacking is better in some ways. I find the N64 MIPS ASM 'easy' so that's still something I need to look at in SM64. But if you're interested, within every object structure there is a pointer to the behaviour coding, change that pointer and te object becomes something totally different. For e.g., I changed a Goomba into a chain chomp! |
| yoshiman Member Level: 21 Posts: 3/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| 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. 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. |
| yoshiman Member Level: 21 Posts: 4/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| Am I right in thinking that the lower polygon Mario is used for collision purposes or is it the original model left in? Even if there aren't any unused behaviour coding, understanding how objects are handled will allow us to create new behaviours. Say you wanted a Yoshi, which ended up in the SM64 DS version, then new behaviour coding would be needed. James S. |
| yoshiman Member Level: 21 Posts: 5/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| What I mean by a pointer in the object structure (what you call a RAM object) I mean an actual address. It seems that in the ROM you use offset to the segment which makes sense since the actual RAM addresses aren't known. In the RAM, actual address pointers are used most of the time and look like this: 800E5F20 This is a pointer to Mario's gfx struxture for the PAL SM64. This is confusing for some as it looks like a Gameshak code but it's just an aboslute address. Well, I say absolute as opposed to an offset added to a start address. In the RAM objects towards the end are pointers like above to the ASM coding, changing these alters how the obejct behaves. I'm not totally sure but it seems every object can have at least 2 behaviours, perhaps 3. Often two of the the behaviour pointers are the same with a flag to say which one to use, with a third that I need to study more. There does seem to be a lot of unused variables within each RAM object, for e.g., there are floating point values towards the end that look like size modifiers but they're at the beginning. When I did a search for the instructions to set object positions in the RAM it didn't return many values which is strange. James S. |
| yoshiman Member Level: 21 Posts: 6/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| I'm surprised how the animations are handled in SM64, there is the Peach animation stored in memory when outside the castle; she claps her hands and pats something. There are 100 frames to this animation, and many different movements for each frame so the whole animation takes up a fair amount of memory. First of all there was translation and rotation of Peach, and then the rotation of Peach's hair, dress and arms. The values look to be integers so that they need only 2 bytes as opposed to using more accurate f/p numbers that would need more bytes. Now for something strange, no surprise that rotating Peach's forearms moves her hands but rotating her upperarms does not so that you can actually split her arms in half! There also seems to be repeated rotations, such as for her hair. I'm guessing that what can be animated about an object depends on how the gfx are constructed. If it were possible to replace Mario with Peach then the animation would have to be adjusted. As Mario does different things, the data pointed to by Mario's animation pointer changes, but surely all of his animations are already loaded in memory? James S. |
| yoshiman Member Level: 21 Posts: 7/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| It's strange the problem with Peach's upperarms but I've now found the proper values to rotate her arms. Has anyone ever edited SM64 animations before-what about an animation editor? It's been a while since I've seen the ending sequence, but you can even move or rotate Peach's earrings. Of course changing Mario's animations would be a lot more difficult but it would be a challenge. James S. -------------------- Time is the key... |
| yoshiman Member Level: 21 Posts: 8/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| Yeah, the behaviour pointerss are nothing more than jumps to ASM, that is, coding stored in the RAM. But since that's copied from the ROM, it would be possible to alter how objects behave. I mean, create new behaviours, such as for Mario to ride Yoshi. James S. -------------------- Time is the key... |
| yoshiman Member Level: 21 Posts: 9/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| I can edit Mario's animation data but it gets overwritten by the game, unlike for Peach, for example. The animation pointer in Mario's object structure stays the same but the data it points to changes, so its possible new animations are loaded but I'm not so sure. James S. -------------------- Time is the key... |
| yoshiman Member Level: 21 Posts: 10/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| Yeah, the blinking eyes are also separate from an object's animation. I can easily change the textures in RAM used for things like eyes, so it shouldn't be too hard to change them in the ROM. How about Mario with Peach's eyes?! James S. -------------------- Time is the key... |
| yoshiman Member Level: 21 Posts: 11/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| Ok, I will look into it and perhaps put it on my website or this forum... I've put the results on my website but it's not good news. James S. -------------------- Time is the key... |
| yoshiman Member Level: 21 Posts: 12/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| We all know the opening sequence at the start of the game when Peach reads the letter to Mario and so on. But there are some interesting points about the objects that I would like to point out: * The Peach object turns into the pipe after Peach vanishes; couldn't a separate object be used for the pipe? * The cameraman Lakitu gfx does not include his cloud; why not? I've noticed this in the mirror room in that you can just see his cloud when you can't see Lakitu himself. James S. -------------------- Time is the key... |
| yoshiman Member Level: 21 Posts: 13/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| Ok, here are some of the variables that I've found so far for an object structure and some information that I'm putting on my website: Stored in the RAM while playing SM64 are the object structures which are simply an area of memory dedicated to each object that stores its position, rotation, and so on as well as defining how it looks. These object structures appear to be doubly-linked lists since the game was most likely programmed in either C or C++ and each object structure contains a pointer to the next and previous structure. Just think of a structure as a collection of variables bound to a particular object, each of the 240 objects that can be in a single level have this structure stored in the RAM one after another. Each structure uses 608 (0x260) bytes, so all 240 objects in a level occupy a total of 145,920 (0x23A00) bytes. The first object structure is located in RAM at address 8030B0B8 for the PAL game and 8033D488 for the NTSC game. What follows is that which I know about the variables contained within an object structure; not all variables are normally used by a single object and thus some variables will not have an effect on the object. The number in square brackets [] is the offset from the start of the object structure. Following that is an example value and then a description of how various values affect the object. (f/p) is a floating-point value. 0x?? or 0x???? are hexadecimal values. [0x00] 0x001800 Always that value, should not be changed as it marks the start of an object structure. [0x03] 0x25 Alters how the object behaves in relation to the camera. 0x25 causes the object to always face the camera as is the case of the 2D objects like trees and other objects so that it appears 3D, however it can be used with 3D objects. 0x21 is used for true 3D objects so the object isn't forced to always face the camera since rotating the camera will show other parts of the object. [0x04] 0x8030B0B8 Usually pointer to the previous object. If this is the first object, it will point to the last object. [0x08] 0x8030B578 Usually pointer to the next object. If this is the last object, it will point to the first object. [0x0C] 0x80386A20 Always equals this value, points to a structure that contains variables which affect all the objects. [0x10] 0x00000000 ? [0x14] 0x80195084 Pointer to the object's graphics structure. [0x18] 0x01 Use graphics flag: =0x00 don't display object's graphics, =0x01 do display object's graphics. [0x19] 0x01 Appears to have no effect on the object; usually equals 0x01 if [0x18]=0x01. [0x1A] 0x0000 ? [0x1C] 0x00000000 ? [0x20] 0xC4A6A000 (f/p) Some form of coordinate? [0x24] 0x4431C000 (f/p) Some form of coordinate? [0x28] 0x44EB2000 (f/p) Some form of coordinate? [0x2C] 0x3F800000 (f/p) X size modifier (scaling value). [0x30] 0x3F800000 (f/p) Y size modifier (scaling value). [0x34] 0x3F800000 (f/p) Z size modifier (sacling value). [0x38] 0x00000000 ? [0x3C] 0x80060030 Pointer to the object's animation structure; if zero, object is not animated. [0x40] 0x00000000 ? [0x44] 0x00000000 ? [0x48] 0x00010000 ? [0x4C] 0x00000000 ? [0x50] 0x00000000 ? [0x54] 0x3F751000 ? [0x58] 0xC2D2C670 (f/p) Some form of coordinate? [0x5C] 0xC444B1C0 (f/p) Some form of coordinate? [0x60] 0x8030FA58 Pointer to object ? [0x64] 0x8030F598 Pointer to object ? [0x68] 0x8030F7F8 Pointer to object ? [0x6C] 0x00000000 ? [0x70] 0x00000000 ? [0x74] 0x01 ? [0x75] 0x01 Determines if the object is active: =0x00 remove the object (the structure remains), =0x01 continue using this object. [0x76] 0x0001 ? [0x78] 0x803194B8 Pointer to object? [0x7C] 0x00000000 ? [0x80] 0x00000000 ? [0x84] 0x00000000 ? [0x88] 0x00000000 ? [0x8C] 0x0000 [0x8E] 0x0001 How much object homes in on Mario? 0x0001=Do not react to Mario. 0x2449=Rotate to face Mario. [0x90] 0x00000000 ? [0x94] 0x00000000 ? [0x98] 0x00000000 ? [0x9C] 0x00000000 ? [0xA0] 0x45A54000 (f/p) X position in level. [0xA4] 0x43C4FD52 (f/p) Y position in level. [0xA8] 0xC4480000 (f/p) Z position in level. [0xAC] 0x00000000 ? [0xB0] 0x00000000 ? [0xB4] 0x00000000 ? [0xB8] 0x00000000 ? [0xBC] 0x00000000 ? [0xC0] 0x00000000 ? [0xC4] 0x00000000 X collision rotation? [0xC8] 0xFFFFBA00 Y collision rotation? [0xCC] 0x00000000 Z collision rotation? [0xD0] 0x00000000 X object rotation. [0xD4] 0xFFFFBA00 Y object rotation. [0xD8] 0x00000000 Z object rotation. [0xDC] 0x00000000 ? [0xF3] 0x00 For ! boxes, controls its colour (does not change what it gives out; use [0x147]): 0x00=red (wing cap). 0x01=green (metal cap). 0x02=blue(vanish cap). 0x03=yellow (other item such as coins). For ordinary boxes changes the texture of its graphics: 0x00=Shifting Sands box texture. 0x01=Bob-omb Battlefield box texture. For coins selects texture to use to animate its spinning; ranges from 0x00 to 0x07. [0xFE] 0x0028 ? [0x131] 0x80 0x00=Solid object; can be punched, kicked and climbed onto its top. 0x10=Similiar to 0x40. 0x20=Cause Mario damage upon contact ([0x183] determines how much damage); can't jump on top or bounce off. 0x40=Cause Mario damage upon contact ([0x183] determines how much damage); can jump onto top and bounce off. 0x80=Can be read like a signpost and climbed onto its top. [0x133] 0x40 0x00=Solid object. 0x40=Object can be climbed. [0x147] 0x32 Message to use for signposts and Bob-omb buddies (0x00 is the first message). For ! boxes it controls what object is given after the box is broken (has no affect on the colour of the ! box unless a code is active before entering the level): 0x00=Wing cap. 0x01=Metal cap. 0x02=Vanish cap. 0x03=Koopa shell. 0x04=x1 yellow coin. 0x05=x3 yellow coins. 0x06=x10 yellow coins. 0x07=1-up mushroom (moves slowly). 0x08=Level star 1. 0x09=1-up mushroom (moves fast). 0x0A=Level star 2. 0x0B=Level star 3. 0x0C=Level star 4. 0x0D=Level star 5. 0x0E=Level star 6. 0x0F=nothing. [0x14F] 0x04 Current action. For a platform lift: 0x01=Moving straight upwards. 0x02=Turning over. 0x03=Moving straight downwards. 0x04=Moving horizontally. [0x156] 0x0033 Timer that increases until it reaches a certain value, resets to 0 and counts up again. Used by objects such as the platform lifts to decide when to change its movement type. For ! boxes it is used to delay the 'return' of the box. [0x17F] 0xFF Level of transparency for object's graphics (only affects some graphics?) 0x00=completely transparent, 0xFF=opaque. [0x183] 0x01 How many segments of damage to do Mario for objects that cause him harm; if zero enemy objects will push Mario away but not do him any harm. [0x1CC] 0x800E3B50 Pointer to behavoiur coding. [0x1D4] 0x800E3B50 Pointer to behaviour coding. [0x20C] 0x800E3B20 Pointer to behaviour related data? Hope this helps; it's far from complete. I actually did Mario riding Yoshi by changing Yoshi's behaviour to that of a Koopa shell. But of course his animation wasn't right as Mario was surfing on Yoshi! James S. -------------------- Time is the key... |
| yoshiman Member Level: 21 Posts: 14/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| Thanks for what's no doubt an NTSC address! The debug code was never found for the PAL version as far as I'm aware. But thanks anyway. James S. -------------------- Time is the key... |
| yoshiman Member Level: 21 Posts: 15/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| That's strange what you said about Mario's head; the texture commands for Mario's eyes (open, half shut, closed, etc) are always in memory or are they just for the main Mario model? You only need to change those texture commands, as I did, to give Mario Peach's eyes. But the problem is, other than Peach having one more blink texture than Mario, is Mario only has one Peach eye. James S. -------------------- We English do things a little differently...Anyone for a cup of tea while we hack?! |
| yoshiman Member Level: 21 Posts: 16/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| Actually, you can't always add/subtract to get the address for a different version; that's a common mistake. Otherwise all PAL users would be able to use the debug code if it were that simple; but there are some remains left in the PAL version such as the level select names. Mario's lives (PAL) 803094DD (NTSC) 8033B21D Difference=31D40 First object structure (PAL) 8030B0B8 (NTSC) 8033D488 Difference=323D0 See? It doesn't always work out. I've tried subtracting to get the debug code but nothing. But what you're talking about once more is totally different to what I'm referring to. If Peach's actual animation data is just a number of translations and rotations for each of her body parts then why should it be different for any other objects? The animations commands you talk about do change dynamically for Mario but does Mario's actual animation data-the translations and rotations-change dynamically too? James S. -------------------- We English do things a little differently...Anyone for a cup of tea while we hack?! |
| yoshiman Member Level: 21 Posts: 17/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| Yeah, I've tried nearby but I think the only way to find the debug in the PAL version is to trace the coding. However, I can't find in the PAL version the ASM that checks the debug flag. So it seems like it was removed from the PAL version, or certainly the one I have. James S. -------------------- We English do things a little differently...Anyone for a cup of tea while we hack?! |
| yoshiman Member Level: 21 Posts: 18/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| Thanks, VL-Tone; never before had I seen the PAL debug code yet you knew it all the time! It would have taken me much longer to find the code myself especially as the coding is different for the two versions for the ASM in the RAM: NTSC 80248BE0 3C188033 lui t8, 0x8033 80248BE4 8318D598 lb t8, 0xd598 (debug_flag) 80248BE8 1300000B beq t8, r0, 0x80248C18 PAL 8026DFA0 3C0A8030 lui t2, 0x8030 8026DFA4 814A9748 lb t2, 0x802F9748 (debug_flag) 8026DFA8 3C018030 lui at, 0x8030 8026DFAC AC20A0D0 sw r0, 0x802FA0D0 8026DFB0 1140000A beq t2, r0, 0x8026DFDC This really helps as I'm looking over the coding; I'd love to do a thread on SM64 ASM... James S. -------------------- We English do things a little differently...Anyone for a cup of tea while we hack?! |
| yoshiman Member Level: 21 Posts: 19/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| The time I notice the low-poly Mario the most is when on the mountain summit in Bob-omb Battlefield and the camera is zoomed out. Another place is when fighting Bowser you can see the low-poly Mario. As the camera zooms in the high-poly Mario 'pops' into view which should never happen had they kept with just the better model. This really complicates making changes to Mario but I think it's the best way as then the edited graphics will be available in all levels. James S. -------------------- We English do things a little differently...Anyone for a cup of tea while we hack?! |
| yoshiman Member Level: 21 Posts: 20/95 EXP: 46223 For next: 3720 Since: 12-21-07 From: London, England Since last post: 2065 days Last activity: 1949 days |
|
||
| Just to let you know, they are my codes that I created. I'm an expert at RAM hacking; there is a lot that can be done by just using Gameshark codes. I know you can't copyright codes but it would be nice to get some credit and if you created the same codes by chance then that's some chance. James S. -------------------- We English do things a little differently...Anyone for a cup of tea while we hack?! |
| Pages: 1 2 3 4 5 |
| Jul - Posts by yoshiman |
 |
Acmlmboard - 07/23/2013 b378.03 ©2000-2013 Acmlm, Xkeeper, Inuyasha, et al. |
| Query execution time: | 0.053831 seconds |
| Script execution time: | 0.077383 seconds |
| Total render time: | 0.131213 seconds |