Kirby - Tilt 'n' Tumble (GBC) tilt fix/accelerometer removal patch

[Titney]

This has been a long time coming, but now, thanks to infinest on the Romhacking site, there is finally a patch available to play Kirby - Tilt 'n' Tumble without the tilt sensor cart. I tried it, and it works really well. It's quite a bit easier using the D-pad than playing with the original tilt sensor in my opinion.

Patch can be downloaded or applied at:
https://www.romhacking.net/hacks/6479/

Description from the Romhacking entry:
"This patch completely removes the accelerometer from the game an replaces it with the Game Boy Colors traditional controls. Moving or “Tilting” has been assigned to the D-Pad, the camera can now be moved by holding Select and using the D-Pad. Popping the floor up and jumping is done by pressing the A button while on the ground. When flying the floor can be popped up by pressing B and you shoot by pressing A as before. Most other actions have been relegated to the B button because of a lack of buttons. The mini games have also all been updated to support traditional controls. None of the tutorial screens have been edited though, so you’ll just have to give it a try.

The game has also been converted from MBC7 to MBC5 with traditional SRAM for saving. This allows booting the game on any flash cart that supports MBC5."

 

[Deleted member 42501]

Doesn't that remove all the fun?

 

[enarky]

Huh, interesting. I thought such patches have existed since the game was released, but looking more closely they haven't made the game playable. Thanks for posting this!

 

[mrgone]

wow, didn't expect that to happen, but great work!

still got my genuine cart though...somewhere

 

[FAST6191]

Doesn't that remove all the fun?

Can't speak to this one having not yet played it but going by others over the years... yes but also no, and "it depends", also "it depends what the patch does".

I played warioware twisted on the GBA and you can still have quite a bit of fun, some things are like cheating (the patch I used was more of a press and hold to set your desired spin speed in a given direction, think winding a volume knob, so some points were much like you had stuck the thing on a nice drill and pulled the trigger making it trivial), other things were 10x harder (there was a late stage boss where you had to go left and right, mimicking a hand wave, which would be fine on the original but trying to not overcook it and move in time was a nightmare).

I imagine someone that put the effort in at this point in life, as opposed to racing to be the first for Scene points (sticking with the theme of external inputs that make emulator authors/flash cart devs cry see early Boktai/Solar Boy Django stuff vs the later that everybody is suggested to use today https://gbatemp.net/threads/boktai-solar-sensor-patch-kit.245127/ ) would have taken a bit of care to make sure the game is still vaguely playable. Some of the challenge will probably have been removed inherently as part of it but if waggle controls is more than a gimmick then you start getting into redesigning levels territory which is doable (maybe the engine is otherwise that good) but... different discussion.

 

[EvilJagaGenius]

For people trying to play this on Jagoomba Color, it doesn't work in v0.4 but it seems to work fine in v0.2. Working on a fix.

EDIT: Experimental fix is in the Github repo, for those who want to compile from source. I have some more things I want to play with before pushing a new release but I'll try not to take too long.
EDIT 2: New release out which fixes this, enjoy: https://github.com/EvilJagaGenius/jagoombacolor/releases/tag/v0.4a

 

[SaulFabre]

Sorry for bumping this thread

But...

Is it possible to make a patch that only replace the save type EEPROM to traditional SRAM, but maintaining the motion sensor usage? (only changing the save mapper?) I'd like to play this again on the Wii.

 

[FAST6191]

The areas of code handling the saving are probably quite different to the areas originally reaching out and touching the tilt but now doing buttons. If this was a GBA game you could do it in seconds but I am not sure what level of skills (minimal but probably baseline assembly) you are going to want for this. I also don't know what the emulator (be it injection or big boy real emulator) will be using to assign motion controls to it -- https://gbdev.io/pandocs/The_Cartridge_Header.html 0147 notes the header claims the relevant MBC which many things will probably use.

Though looking at https://gbdev.io/pandocs/MBC7.html it appears the EEPROM handling is a bit different to many other things so that might be a complication.

 

[infinest]

No i don't think this is possible. The accelerometer functionality requires using the MBC7 mapper.
However the MBC7 does not support having RAM inside the game cartridge and therefore no SRAM saving.
And even if the chip itself could theoretically handle it (which it can't) i doubt a lot of emulators would support it as there are no games that use it.

 

[SaulFabre]

No i don't think this is possible. The accelerometer functionality requires using the MBC7 mapper.
However the MBC7 does not support having RAM inside the game cartridge and therefore no SRAM saving.
And even if the chip itself could theoretically handle it (which it can't) i doubt a lot of emulators would support it as there are no games that use it.

Ah ok, thanks for replying

 

[Required2post]

Sorry to bump, but what would it take for this to work on the Japanese version?

 

[infinest]

Sorry to bump, but what would it take for this to work on the Japanese version?

Very much not trivial. You'd have to examine every single location at which my patch makes changes and then check if the logic is in a different location in the japanese version.
If it's just in a different location you could probably just move the changes the patch makes as well but if some logic differs in the japanese version which might be the case in some spots, it's gonna get even trickier.
Not something im particularly interested in doing tbh.