TMNT: Return to New York (NES) Updated (v1.81)

[ShadowOne333]

I think I found the proper values for the High Jump Velocity on RTNY thanks to the data you sent me

At 0x20204, you have the following data:
[FA 00 FA C0 FA 00 FB C0]
Each pair corresponds to a turtle in this order: Leo, Raph, Mike and Don.

Applying the changes from the other addresses explained in the video first:

Code Select Expand

; 6 Frame Short Jump
0x1202D - 04->06

; Short Jump Velocity Change
0x1203C - FD->FE

; Increase Gravity
0x12605 - 54->74

And then changing the table found at 0x20204 with these values:
[F8 C0 F9 C0 F8 C0 FA C0]

That achieves the exact same Jump altitude as with the original physics on RTNY, but with the suggestions by Displaced Gamers for the better jump changes
I tested in the very first manhole and checking the jumping height with and without the changes per-turtle in this place comparing it against what bricks or part of the pipe each turtle reached:


After this, I think it's just a matter of patching in these bytes, and then copying the new sprites I sent you and you should be good for another update

[Prince Valmont]

I'm glad to see this one still getting love!
But for some strange reason, I just cannot get this hack to run in my NES Mini. I've tried their stock emulator (Clover-Kachikachi), FCEUmm Xtreme, Mesen, and Nestopia. All work great using PC emulators, but any core within RetroArch on the NES Classic Mini, and the game refuses to boot.

Has anyone else had success playing this via the Classic NES Mini?

[Uberdubie]

I'm glad to see this one still getting love!
But for some strange reason, I just cannot get this hack to run in my NES Mini. I've tried their stock emulator (Clover-Kachikachi), FCEUmm Xtreme, Mesen, and Nestopia. All work great using PC emulators, but any core within RetroArch on the NES Classic Mini, and the game refuses to boot.

Has anyone else had success playing this via the Classic NES Mini?

I've been playing this incredible hack (Version 1.8 ) on my SNES Classic/Mini using the default NES emulation that comes with Retroarch, and I can confirm it runs flawlessly.  Despite you playing on the NES version, from my understanding this means it should run fine on yours too -- most likely a bad rom and/or bad install.

[Flaviogames]

amazing work on this game, but I'll give suggestions so that the game can be even better, look for a character on the select button, or does it have another function? one thing that I didn't like about this game and that could improve is that we go through a scenario and in the end we face a boss and we have to return, then the problem comes, the enemies appear all over again, will it be like that?

[guitarpalooz]

amazing work on this game, but I'll give suggestions so that the game can be even better, look for a character on the select button, or does it have another function? one thing that I didn't like about this game and that could improve is that we go through a scenario and in the end we face a boss and we have to return, then the problem comes, the enemies appear all over again, will it be like that?

Select toggles between your main weapon and special weapons (ninja star, boomerang, etc)

[ShadowOne333]

One thing I found, which I'm not sure if was taken into account when modifying the jumping physics.
Do the modifications to the jumps allow you to actually reach certain ledges/platforms when some of the turtles are capture?

With Donatello, I find his jump to be a bit short. I haven't tested in many places throughout the game, but I am not sure if getting to a certain place in the game with only Raphael or Donatello with both Leonardo and Michelangelo captured would softlock you from reaching certain places.
Was this tested?

(I haven't tested this myself, but it's something I found when playing around with the jump changes both before and after applying the physics from Displaced Gamers into RTNY)

[guitarpalooz]

In my version, I playtested so that donatello could get through all areas, even those nonessential to game progress.  In a few spots where he couldnt make a jump, I made slight changes to the levels to allow him to progress.  If i missed any, please let me know, but it should be complete.

With Displaced Gamers video, he even shows that his exact changes prevent you from completing the game in some of the tricky jump areas.  My plan is to eventually have a short and medium jump determined by how long you hold the a button, and a double jump (spinning animation) by pressing a a second time.  I'll have leonardo mimic the physics of the original game with his double, and then try and create the different jump heights for raph and don.

Even then it might not pass playtesting, as the double jump starts at the 8th frame and you cant allow a double jump much longer than that (youd be able to skip the rope sections, especially with mike).  Then youre talking about variable gravity per turtle based on their x velo and  increasing gravity (think megaman) which would make your jump less floaty but reduce your time to do short hops.

I do wish DG would put more of a disclaimer in terms of not playtesting his changes, as mosts comments on his videos (and to me) are either 1. It's the game's fault I couldn't do it as a kid (not true!) or 2. This is now the definitive version of this game.  His changes as written make for impassable areas and softlocks from falling through the floor!

[ShadowOne333]

Ah that's good to know.
I just thought of asking since I was having problems jumping into a platform with Don, but that's fine

As for the jumping changes, I can see you're tackling it in a way to make it much more refined and polished than what Displaced Gamers did.
For what it's worth, and no disrespect to them, they sometimes just make the code but don't do extensive testing on it, but they do mention at least that it's a rough proof of concept sometimes, so that's something.

All in all, you seem to be doing quite the testing to the jump mechanics, so I'll leave you get your hands on it as you see fit, I trust you'll do a wonderful work to polish it up.

PS: I forgot to mention, but just before the table I mentioned at 0x20204, there's another one which starts around 0x201FC which has this:
[FA 00 FA 00 FA 00 FA 00]
That one table also seems to be related to jump stuff that rainponcho did through the ASM code he made, and that seems to be related to Jump Speed according to his notes:

Code (rainponcho's tables) Select Expand

; At 0x201FC
jump_speed_table:
db $fa,$00
db $fa,$00
db $fa,$00
db $fa,$00

; At 0x20204
jump_spin_speed_table:
db $fa,$00
db $fa,$C0
db $fa,$00
db $fb,$C0

Hope this helps!

[Greyfield]

Hiya Shadow,

I mentioned this to Guitarpalooz in a PM a while back, but I've been unable to get Return to New York to run on FCUEX 2.6.4 and a MisterFPGA, which mimics real hardware.  The game freezes after the intro text and before the title screen loads on both.  Seems to work fine on other emulators, like Nestopia UE, though.

My intuition is that it's not Guitarpalooz's hack itself, but RetroRain's savestate hack, which causes the same error on both the emulator and hardware.  I know that you have some experience working with the saves, mappers, and with getting your Zelda NES Redux hacks working on real hardware.  Do you have any thoughts what might be causing an issue like that?  Maybe a header or mapper issue?  The only two other things I can see are that the ROM is enlarged with the save state patch, and, using a ROM utility, that the mapper was changed from MMC1 to MMC5.  RetroRain didn't mention changing to MMC5 on that hack's page.

[ShadowOne333]

Hiya Shadow,

I mentioned this to Guitarpalooz in a PM a while back, but I've been unable to get Return to New York to run on FCUEX 2.6.4 and a MisterFPGA, which mimics real hardware.  The game freezes after the intro text and before the title screen loads on both.  Seems to work fine on other emulators, like Nestopia UE, though.

My intuition is that it's not Guitarpalooz's hack itself, but RetroRain's savestate hack, which causes the same error on both the emulator and hardware.  I know that you have some experience working with the saves and with getting your Zelda NES Redux hacks working on real hardware.  Do you have any thoughts what might be causing an issue like that?  Maybe a header issue?  No worries, if not.

I haven't looked into RetroRain's save patch yet, but if my assumption is correct, then the issue might most likely would be narrowed down to a mapper change, which most hacks tend to do.
If the new hack uses MMC5, then that might be the cause of the problem.

However, as to how to fix it, I am not that experience with mappers on NES to be able to find a reliable solution, as I got external help for that for Zelda Redux. But if that's the case, then the mapper change to MMC5 might be the culprit.

[Greyfield]

Thanks for the quick reply.  I just edited my post, after having checked the mapper.  RetroRain extended the ROM and changed it from MMC1 to MMC5, and didn't mention it in his patch description.  I'm guessing that's the problem as well, although I have no idea how to fix it either.

[guitarpalooz]

As currently structured, the hack requires expansion to gain extra space for various tweaks and fixes.  The best way to fix this would be to disassemble the base game and optimize the code to gain extra space.  Not something I have the time to do, but if someone else went down that path, I would definitely update it with my changes.

[Nintenja]

Who needs cowabunga collection? Good work.

[G30FF]

I mentioned this to Guitarpalooz in a PM a while back, but I've been unable to get Return to New York to run on FCUEX 2.6.4 and a MisterFPGA, which mimics real hardware.  The game freezes after the intro text and before the title screen loads on both.  Seems to work fine on other emulators, like Nestopia UE, though.

I am able to get the latest version of the game working just fine on my MiSTer. I am using the latest version of the NES core, and the latest release of Return to New York. No freezes, and saving works fine. You should double check that your patched rom is correct.

[Greyfield]

Hi G30FF,

I'm still having the error.  The CRC32 of the ROM I'm using is 83213CA0, while the CRC of the patched ROM is C2605489 with v1.81 of Return to New York.  My NES core is up to date.  I appreciate the continued discussion of this.  In the meanwhile, Guitarpalooz's Turtle Power hack will have to do.

[G30FF]

Hi G30FF,

I'm still having the error.  The CRC32 of the ROM I'm using is 83213CA0, while the CRC of the patched ROM is C2605489 with v1.81 of Return to New York.  My NES core is up to date.  I appreciate the continued discussion of this.  In the meanwhile, Guitarpalooz's Turtle Power hack will have to do.

Strange, since that's the same CRC of my patched ROM. Don't know how to explain that.

[ShadowOne333]

Displaced Gamers released another video talking about the input lag on TMNT NES.
There's two major points that could be implemented for this hack (or any TMNT improvement hack), the windup frames and the dropped input frame due to DMC:
https://youtu.be/f6E8YmQUkdo?t=776

The windup frames could be modified with the information given around 1/3 in the video (6:59 in the video), but the dropped input frame one seems a bit more complicated (12:55 in the video).
Basically the check for controller inputs where a loop might be required is around C502 (13:45 in the video). Modifying this routine to loop back would essentially make the response for controller input better.

This is quite interesting for sure.

[guitarpalooz]

Just had a look.  Comparing the TMNT code to what he shows from SMB3 I think changing C4E4 and C4EA to BNE to C4E0 would correct the DMC issue without waiting for the next frame.

For the animation delay, I'd be most curious in trying to eliminate the lead frames for Don and Leo without changing the speed of the attack animation.  I think in gameplay the cooldown period and animation duration are likely important to prevent you from just mowing down everything too easily.  I think this is pretty doable (remove the zero sprite from the animation) and should have some time to try it tomorrow. 

[Prince Valmont]

I've been playing this incredible hack (Version 1.8 ) on my SNES Classic/Mini using the default NES emulation that comes with Retroarch, and I can confirm it runs flawlessly.  Despite you playing on the NES version, from my understanding this means it should run fine on yours too -- most likely a bad rom and/or bad install.

I thought that as well, but I triple checked the CRC32, and it matches the one listed on the RHDN listing. I've hunted down copies from several sources that all match the CRC32. The ROM patches fine and plays flawlessly on the PC app FCEUmm. But when tried to run under the NES Classic Mini using clover-kachikachi or RetroArch (using FCEUmm or any of the other RetroArch cores), it just displays an eternal gray screen upon boot.

The patched ROM displays a CRC32 of C2605489. Does this match up with anyone else?

[Uberdubie]

I thought that as well, but I triple checked the CRC32, and it matches the one listed on the RHDN listing. I've hunted down copies from several sources that all match the CRC32. The ROM patches fine and plays flawlessly on the PC app FCEUmm. But when tried to run under the NES Classic Mini using clover-kachikachi or RetroArch (using FCEUmm or any of the other RetroArch cores), it just displays an eternal gray screen upon boot.

The patched ROM displays a CRC32 of C2605489. Does this match up with anyone else?

Mine matches the correct version, and I can confirm it works perfectly on my mini via RetroArch without any additional cores needed (just default RetroArch nes emulation).  So if you have the right version and it's all-systems-go on my end, there's no reason it shouldn't work for you.  If you tested to make sure it's not a bad rom, it's still most likely something with your classic/mini not installed/configured correctly.  Sometimes it's something as goofy as the command line not typed right, or some random setting in RetroArch accidently disables functionality.

Regardless, it should work perfectly with your setup and isn't a problem with the hack.