DuckTales is a classic game in which Scrooge has to collect treasures from all over the world. Some of the levels are not completely straightforward, and collecting items is sometimes necessary before proceeding. His cane also doubles as an almighty pogo stick that can be used in various ways, which makes jumping a lot more fun.
This is a 13 seconds improvement over the previous movie due to a glitch that can be performed by pressing the up button on the second controller that will allow Scrooge to wrap when climbing ropes and vines.
Secondly, we looked for more input combinations like this, and there is a couple. Both official release and prototype check the second controller for pressing Up while falling to skip screen scrolling in certain situations, and Left+Right/Up+Down to filter those inputs out. The prototype also checks for A+B to enable invincibility. The checks are direct and explicit:
07:E704: LDA PlayerMovement
07:E707: AND #$04 ; check falling flag
07:E709: BEQ $E718 ; if zero, exit subroutine
07:E70B: LDA $17 ; read controller 2 state
07:E70D: AND #$08 ; check Up button
07:E70F: BNE $E718 ; if non-zero, exit subroutine
07:E711: LDA PosY ; load vertical player position
07:E714: CMP #$E0 ; subtract from 0xE0
07:E716: BCS $E719 ; if result is below zero, handle screen scrolling
07:E718: RTS ; exit subroutine
07:E719: LDY $F1 ; handle screen scrolling
If you're falling while holding Up on the second controller, and your vertical position is below a certain value, the screen won't scroll down like it does normally, you'll just keep falling until your vertical position wraps around. There seem to be extra conditions like the screen will only scroll if there's a bottom room, but this doesn't change the fact that this check is intended. So it's not a bug, but a feature.
Since this feature is not mentioned in the manual, and DuckTales is a single-player game, second controller input isn't intended for normal play.
It doesn't give the player any real advantage, so we can't call it a cheat code, but we can call it a debug code leftover judging by various factors mentioned in this post. Since we don't allow using debug codes, this movie has to be rejected.
Link to video
Temp encoding, potato quality
If i hanen't permisson to upload the temp encode, i will delete it
Currently making a route for Super Bomberman 5 200%
TASes i'm planning: aero fighters, tg3000 (again), gradius 3, bust a move, bust a move plus, gradius rebirth, smg, smg2, mp9, gh3 (wii)
That screen wrapping is really fun to watch! Yes vote.
[14:15] <feos> WinDOES what DOSn't
12:33:44 PM <Mothrayas> "I got an oof with my game!"
Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet
MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish
[Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person
MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol
Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
Joined: 1/24/2018
Posts: 306
Location: Stafford, NY
I'm going to take a guess that this has a similar cause to the Controller 2 effects seen in Mega Man 3. Both games were developed by Capcom around the same time, so it would make sense to assume the same root cause.
^ Why I don't have any submissions despite being on the forums for years now...
Which would be... a developer cheat code used for testing and debugging purposes left inside incidentally.
IIRC in Mega Man 3 the P2 pad can alter gravity of the player amongst other possibilities, which is against the rules.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
If it’s not an intended cheat code can it really be classified as a cheat?
I though we only banned them if they were intended by the devs.
[14:15] <feos> WinDOES what DOSn't
12:33:44 PM <Mothrayas> "I got an oof with my game!"
Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet
MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish
[Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person
MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol
Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
Joined: 4/17/2010
Posts: 11492
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I don't think screen-wrapping is an intended thing. But the setup for it could be intentional, which can only be found out by reading the game code.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Informations so far (edited):
- Just like we guessed it, from tcrf ducktales nesHolding Up on the second controller while falling into a non-lethal pit wraps Scrooge to the top of the screen. This is likely a debugging leftover that developers forgot to remove.
- Works as long as no U+D or L+R is pressed. This is because the game filters the inputs (always sanitize your inputs as well). Subroutine $C1AB
- Checking up to 5000 frames (second level start) with different button combinations, I didn't saw anything else.
Comparing the two different trace log:
Pressing Up on 2nd controller where otherwise screen would wrap
A:04 X:00 Y:00 S:BD P:nvUbdIzc $E70B:A5 17 LDA $0017 = #$08 ;P2 pad Up button (3rd bit)
A:08 X:00 Y:00 S:BD P:nvUbdIzc $E70D:29 08 AND #$08 ;comparing with $08 (3rd bit)
A:08 X:00 Y:00 S:BD P:nvUbdIzc $E70F:D0 07 BNE $E718 ;branch not equal to zero
A:08 X:00 Y:00 S:BD P:nvUbdIzc $E718:60 RTS (from $E354) ;ready to jump to developer code
edit2:
According to "Infidelity's Dissection of DuckTales ROM", right after this the scrolling parameters gets updated
$2F: horizontal/vertical scroll direction 00=up, 04=down
Not pressing Up on 2nd controller where otherwise screen would wrap
Joined: 4/17/2010
Posts: 11492
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Yeah but what does this check actually trigger? I doubt they explicitly make you screen-wrap, there should be some missing check somewhere.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
What I don't understand about the possibility that this is actually an intended function accidentally leftover by developers is why they made it so you have to be OFF a rope/vine (in free-fall) to make Scrooge zip to the top of the screen.
From a testing standpoint, it would have been just as beneficial to have the zip occur while simply climbing down off the bottom of the screen via a rope as it would be to occur during free-fall.
If this on-rope option was also done, why only take one of the possibilities out of the game code before release?
It's hard for me to believe that it was meant as a developer tool.
I think we're missing something here.
Is the RAM value at $0017 ONLY for storing controller 2 input, or do other things change it in the game code?
I think there is a misunderstanding about the purpose. It isn't about "allow screnwrapping", it is about "allow falling through the bottom of the screen".
As I posted above with my 3rd edit, the values around 0x0020 ~ 0x002F is used for scrolling stuffs. Here's from Infidelity's research
(Note: these are not 100% accurate!)
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
New, up to date informations about effectiveness of P2 U:
(edit: Thanks feos for helping in what to really test!)
1. Requires a vine on the bottom of the screen
If there is no vine on the bottom, you just die.
Examples: Amazon 1st row last screen, climbing down to lowest row.
Moon 2nd screen: https://imgur.com/a/jIkJy62
It doesn't matters if you climbed and jumped off from a vine previously.
2. Can be done in any X pos as long as you are on the same screen as the vine
If there is a vine on the bottom, you can go to the top of the screen after falling down from any X pos
Example: Amazon 2nd row last screen, two vines: https://imgur.com/a/qLn2sJe
If there is no vine on the bottom on the screen you are trying to do this, you will die.
Example: Amazon 3rd row last screen (to the right) has a vine, while the next screen on the left has a pit.
Example: Himalayas top row first screen (from the left) has a vine, while the next screen o nthe right has a pit.
This can be proven with cheating your X pos to FF on Amazon 3rd row next screen.
0x0720 = FF
(You can't do this otherwise, because both examples have a wall you need to get around but our Y position falls drastically, leaving us no time to get back to the "vine screen"
Regarding "make the game easier":
A: f15140 Himalayas 2nd row most left screen
It has a snowball falling down from the top. Using this trick let's the player skip that obstacle.
The previous TAS takes dmg from it and then climbs through it while invincible.
B: f24660 Final climbing race against the boss
While we are already much faster since we start with boosting off the bat, it further helps to close the gap.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Joined: 4/17/2010
Posts: 11492
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
[13:31:12] <feos> https://i.imgur.com/kzQVHPF.gif looks like a debug feature
[13:31:24] <feos> meant to be used to test screen scrolling
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
A rope/vine does not have to be on screen.
I just tested in the Himalayas in the long multi-screen drop by freezing the value at 0x0017 (p2 up press), and it appears to work for any pit that would otherwise scroll the screen down. In other words any pit that simply isn't a death pit.
The following is 13 ticks of the in-game timer, and I didn't start this until Scrooge was already a couple screens below the rope at the top of the world.
As it's only possible where screen scrolling would normally occur when Scrooge falls off the bottom of the screen, the effect of the feature would actually be best described as "preventing screen scrolling, but only while Scrooge is falling (not climbing) through a gap that would otherwise initiate screen scrolling."
If it was simply about enabling falling through the bottom of the screen and being sent to the top of the screen; it would be a desirable testing feature for ANY pit, not just the non-death/scrolling pits.
Regardless of whether the purpose is to prevent scrolling or to allow warping Scrooge to the top of the screen, the other question is why program it to only work when he's falling and not while climbing down the ropes that initiate scrolling?
It's this last part that I think I struggle with most in believing this was an intended feature. Why prevent scrolling only when falling in these few instances where it's a not a death pit, but not prevent scrolling when Scrooge is on a vine/rope? It seems a VERY limited feature to have specifically programmed, even for testing purposes. The only reason I can see this being the case is to specifically test the scrolling initiated when climbing down a vine.
Another reason why this wouldn't be a very good debug feature is the cases where using the feature can result in Scrooge being out of bounds. The feature would only have helped testers in very few situations and would have made testing more tedious in others by getting them out of bounds and forcing them to either reset the console, manually re-position Scrooge, or somehow find a way back in-bounds in order to continue testing intended game features. Testing is about breaking a game....not trying to figure out how to get back to normalcy from a broken game state.
Other considerations:
1) This may be a leftover feature that originally had an intended in-game purpose, but that reason was removed from the final product. Thus this feature may not a debugging leftover, but an unused feature.
2) This was a debug feature, but only part of the code for that feature. Meaning that what we're abusing isn't how the feature was intended to be used. This would mean that this submission is a valid use of this button combination/effect; abusing poor programming (or more accurately, poor removal of programming) to yield a result unintended by developers in normal play.
I just feel that the presence of this one snippet of assembly code that shows how the effect happens (skipping the code for screen scrolling) is not enough evidence to claim that this particular effect was intentionally included as-is for developer testing purposes.
If we had further evidence (for example, something published from any of the developers or Nintendo itself) claiming it was an accidental leftover, we could disallow use. But as we have no other evidence beyond this four line assembly code snippet, we can't make that assumption.
Joined: 4/17/2010
Posts: 11492
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
I'll need to read the manual, and look for other P2 input checks in the code.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I'm really curious about this glitch/feature so just in case it helps anything...
1)The manual says nothing about the Player 2 controller.
2) I did a bit more testing on the code at $E70D that reads 0x0017. The following code snippets are traces of $E70D and following being executed. The code is executed every frame that Scrooge is in free-fall, not just when screen transitions are happening or when he's falling through non-death gaps.
Both these tests were done with no ground gaps visible on screen during a jump. The code is not executed while Scrooge is in the rising portion of the jump, but triggers as soon as he starts his descent.
0x0640 is Scrooge's position on screen. When falling in a death pit, he dies when 0x0640 is approximately equal to a hex value of D9. Thus he never gets to the value of E0 needed to trigger the code here:
This makes me wonder if the death pits have a hitbox of sorts. If so, i'm curious if finding a way to clip through a normal floor would allow for this P2 UP thing to skip other areas of the game because the clip through the floor may not hit a death-gap hitbox.
Ultimately the main thing that holding UP on controller 2 does with this above code is skip the portion that looks to see if Scrooge is crossing the bottom limit for a screen transition. The reason he appears at the top seems to be a simple RAM rollover from 255 to 0. It still seems to me an odd thing to have intentionally coded only for these non-death gap situations.
Based on all this, it seems quite different than the gravity altering of MM3 mentioned above.
Another interesting thing I discovered while testing this: If there is a ledge at the top of the screen where Scrooge reappears after falling through the floor, Scrooge can jump back up out of the bottom of the screen and out of the pit (again, likely just RAM rollover from 0 to 255). If he enters the free-fall portion of the jump while below E0 threshold, he'll immediately trigger the screen transition (assuming UP has been released on P2 controller). The transition will not occur while he's rising up out of the pit as the code at $E70D won't be executed until Scrooge is in free-fall.
I haven't had a chance to look through a complete disassembly of the code to see if any other reads of P2 controller happen.
EDIT: Another minor bit of info. Cheating in a higher screen Y-position value into $E715 causes screen transitions to occur when Scrooge is higher from the bottom of the screen. Too high of a value can cause weird effects.
Only in the Prototype version of the game, on the P2 pad pressing A+B at the same time turns Scrooge invincible. (edit: death pits are still death pits in this mode)
Gif: https://imgur.com/pYrhu75
edit4 or whatever, trace logs:
Pressing A+B on P2 pad, only the differences:
edit5:
$0015 (0x0015) is the address for storing P2 pad first. This lasts for a frame. Later this gets copied to $0017.
0x0075 gets changed to FF which is the "invincibility status". anything other than 0 makes Scrooge flicker and invincible. setting 1 also changes the music, but it's set to 0xFF, which has the "no music change, invincibile" state.
Enabling this cheat (0x0075 = FF) will make I guess the very first object to have this property. since the title screen are objects as well, they will flicker (and be invincible :) ) on the published released ROMs as well.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Joined: 4/17/2010
Posts: 11492
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Red means "cheats are unique, not listed on any site".
UNI means "unique cheats".
The way he finds those is by scanning ROMs for what input they read. And it seems in the official release there's only this one check left. And the prototype apparently has more.
PS: http://www.thealmightyguru.com/Games/Hacking/Wiki/index.php?title=DuckTales
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Joined: 4/17/2010
Posts: 11492
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Debug leftover means that most debug features were removed before release, but not all of them, since humans tend to miss things. As the prototype shows, there were more.
I think similar branches were added to other places related to pit falling. And since Asm is quite a messy language, you can only hardcode or copy-paste things in. Then when you feel like removing the extra checks, you do a text search and edit those checks out one by one. And then you miss a few, which is why debug leftovers even exist.
Getting into walls is quite obviously a part of game development and testing. I don't think screen-wrapping was used explicitly for that, because it could be coded to happen more easily for the purpose of testing. But I think it's obvious that this one feature we have here wasn't the only one added just to test scrolling and nothing else was ever tested in a similar way.
Yeah, like controlling ducks with the second controller in Duck Hunt.
Except the game is checking a very specific input which we're sending, and then it explicitly enables screen-wrap. We can't know developers' intentions, but we can avoid explicit checks by glitching the game. This is why [1627] SNES EarthBound "check glitch" by pirohiko & MUGG in 30:42.12 was accepted:
The borderline that can be used here is not what something was meant to be used for, but how it's accessed. With SNES Earthbound, the debug menu was meant to be used for cheating during development, and not meant for regular user play. But it's exactly what that movie uses it for! Yet it's allowed because it's accessed through a glitch.
There's an argument that debug menu was allowed only because we don't know how to access it without glitching. If that is used as a borderline, then as FractalFusion said it'd put us in an impure situation when a movie gets invalidated after publication. And the problem with this is that for any game we can't be sure that there's no input combination enabling debug features. To be sure, the game code has to be exhaustively analyzed, and we can't afford that.
Yet blatantly using cheats or debug features often feels cheap, even via glitching. For example, imagine that you can get invincible for the entire game by entering a code, and you glitch yourself into this mode in level 1, playing the entire game invincible. That insolently violates our guideline about difficulties, so it'd have to be rejected in the end.
As for this game, there's no glitching involved when enabling screen-wrapping, and it's a known input combination, and it's clearly not meant for normal play since you only play this game with 1 controller.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.