 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 - ROM Hacking - Final Destination 64 |  -  -  |
| Next newer thread | Next older thread |
| GuyPerfect Catgirl Pics or it didn't happen. Level: 60      Posts: 1016/1020 EXP: 1674412 For next: 98366 Since: 07-23-07 Since last post: 1 day Last activity: 1 min. |
|
||
Ha! And they said it couldn't be done in Vs. mode with simple GameShark codes. The usual level switch code for the North American release of the game is as follows:
800A4D09 00XX
Where XX is:
The short version of the story is that the value at 0x800A4D09 is read a number of times while loading the level, and one particular read is executed at address 0x80104C14. For whatever reason, if a 0x10 is read prior to the ensuing function call in Vs. mode, the game crashes. It likely has something to do with the Master Hand scenario's behavior, likely due to the graphics being tied to the boss's damage meter. In the event some bland, featureless level's index is loaded at this point instead (such as 0x0E, Battlefield's index), the level loads just fine in Vs. mode, but without the sparkly stars or changing background. Fortunately, N64 games tend to load code into RAM and execute from there, so it's ripe for the GameShark picking. If 0x10 is in the level index variable, the instruction at 0x80104C14 can be replaced wholesale by something else that won't break. So instead of doing what it does--loads the value from RAM--how's about it just always loads 0x0E in the event the actual level index is 0x10? The CPU instruction can be overwritten by the GameShark, and the game program will reload it from ROM before the next match, so it won't break doing it this way. There's also the matter of the music. By default, the level uses the "Master Hand is approaching" tune, which isn't the one you'd want to battle to. The tune has an index of 0x18, and the formal Master Hand battle music is 0x19. So, easily enough, a GameShark code can detect one and replace it with the other. So for the main attraction... The following code is a fix-only code that enables Final Destination to be used through the usual stage switch code. It does not, in of itself, cause Final Destination to be loaded in Vs. mode:
D0099113 0018 80099113 0019 D00A4D09 0010 81104C14 2002 D00A4D09 0010 81104C16 000E I've tested this in Project64, as seen above, and the technique was discovered using Nemu's wonderful debugger. This was mere minutes before leaving for work this morning, so I haven't tested it on the hardware yet, but that's why God invented lunch breaks. EDIT: Whooee, it works just swimmingly on the hardware. When I get home for the night I'll upload a video for the world to squee over. 
|
| GuyPerfect Catgirl Pics or it didn't happen. Level: 60 Posts: 1017/1020 EXP: 1674412 For next: 98366 Since: 07-23-07 Since last post: 1 day Last activity: 1 min. |
|
||
| Sooooo, Jul won't let me use YouTube's <iframe> style embed feature, and I don't have Flash installed, sooo... I have no idea of the rectangle below actually contains a video: If it does, enjoy the dumb little video! If not, here's a link to the corresponding page on YouTube: http://youtu.be/zgMTsdLqGH4 |
| Xenesis Amazing and Hatted Level: 83  Posts: 2203/2204 EXP: 5314013 For next: 118208 Since: 07-28-07 From: The Land of Kangaroos and Drop Bears Since last post: 1 day Last activity: 19 hours |
|
||
Heh, I think those spawn points need work in 4P mode. Still, nicely done. Now all it needs is a proper level select screen hack to display those extra stages  (Also you need to use the 'old embed code' to get Youtube videos to show up normally in jul posts, but whatever you did worked fine.) |
| GuyPerfect Catgirl Pics or it didn't happen. Level: 60 Posts: 1018/1020 EXP: 1674412 For next: 98366 Since: 07-23-07 Since last post: 1 day Last activity: 1 min. |
|
||
Originally posted by Xenesis I thought about doing something with those, but decided it was in the "level mods" category and therefore out of the scope of a fixer patch code. The stage wouldn't hurt to have some item spawn points as well. But hey, I'm not highly motivated to get on that! Originally posted by Xenesis I'm not thinking this one will happen via GameShark, unfortunately. Originally posted by Xenesis I did use the Old Embed Code. But I don't have Flash installed, so all I see is a grey rectangle telling me I need a plugin to view the content. Now if Jul would just allow <iframe>s or implement a YouTube tag of its own, we'd be in business! |
| GuyPerfect Catgirl Pics or it didn't happen. Level: 60 Posts: 1019/1020 EXP: 1674412 For next: 98366 Since: 07-23-07 Since last post: 1 day Last activity: 1 min. |
|
||
| So on a whim, I decided to look into those spawn points. Since players 3 and 4 are right on top of players 1 and 2, I hypothesized that the level only had 2 spawn points and somehow it was reusing them for additional players, but that doesn't appear to be the case. Looking into it, I dug too deep and consequently can't make a GameShark code using what I've found. In the North American ROM file, at address 0x4127FE, there's the following bytes: 62 17 E1 F2. This is a bit-packed value, with two bytes of a 16-bit, signed integer stored at bits 11-18 (high byte) and 2-9 (low byte) (bit 0 is the lowest bit, and bits are indexed in decimal). For this particular value, those bytes come out to 0xFC7C, which is two's complement for -900. This value is then converted to a float and used as Player 1's starting X coordinate on Final Destination. Changing those bytes to 62 10 01 F2 sets P1's starting X coordinate to 0.0, which while technically is in the dead center of the platform, actually refers to the left edge of the character's origin. Still, it does what you'd expect it to do. For those itching to look into it a little more, the applicable ROM bytes are loaded to RAM at address 0x800437CC and, after parsing out the bits, the integer bytes are stored at 0x8021B930 (EDIT: This is on the stack, so it might move around. I did a timed battle with default settings, P1 Link and P2 Mario, level 3). The reason I can't hijack this with a GameShark is because it happens too abruptly, and on the stack, that the GameShark doesn't have time to replace the data before it's already gone and replaced with something else. And N64 GameShark doesn't have the ability to load effective addresses from RAM like later Action Replay devices can, so it can't trace the stack. Anyhoo, changing P1's starting X to zero and loading up Final Destination with 4 players shows that P3 still starts in the same spot it does normally. What this tells me is that there are four spawn points, and it's just a matter of finding a way to move them using a GameShark to make the level a little more presentable. |
| GuyPerfect Catgirl Pics or it didn't happen. Level: 60 Posts: 1020/1020 EXP: 1674412 For next: 98366 Since: 07-23-07 Since last post: 1 day Last activity: 1 min. |
|
||
Player 3's X is initialized to -600 and Player 4's to 600. As P1 is -900 and P2 is 900, this is rather close, and not spaced very evenly. What we're looking for is a 600-unit difference between steps, meaning P3 should be -300 and P4 should be 300. The following ROM patches to the North American file will fix the Final Destination spawn points:
Either way, spacing them out at ± 300 makes all 4 players 600 units apart, which is even spacing. It's certainly better, but methinks it's a smidge too close for comfort at the start of a match: 
|
| Next newer thread | Next older thread |
| Jul - ROM Hacking - Final Destination 64 | - - |
 |
Acmlmboard - 07/23/2013 b378.03 ©2000-2013 Acmlm, Xkeeper, Inuyasha, et al. |
| Query execution time: | 0.099455 seconds |
| Script execution time: | 0.040122 seconds |
| Total render time: | 0.139577 seconds |