FatRatKnight's comments

As per rules of Dream Team Contest 4, I hereby submit the winning run of Rockin' Kats.
Our hero this time is clearly an acrobat. Or acrokat, maybe? Wanting to get back in time to watch his favorite Saturday morning cartoons, he abuses grapple physics. I need to learn to grapple like that if I'm ever going to get anywhere on time.

About the game

Not a game I grew up with. However, it was the DTC4 game, so here I am, trying to describe something I'm unfamiliar with.
Your character is some sort of cat (or Kat?) wearing a tie and armed with a useful spring-loaded punching glove. A fairly typical platformer, but does have basic grapple physics when you hook onto various objects and swing off them. There are five channels, the first four of which you can pick in any order, while the fifth one is opened only when you clear the first four.
The basic story is that Jill is captured (5 times!) and you must rescue her.

About the run

As a team, we... Had a hard time getting ourselves into this run. Though, judging from what the other teams did, they also had a difficult time. What with all the lag and the many ways to get through each part, it was tough just to get any willpower to TAS the game.
With the general lack of manpower, I realized we probably wouldn't stand a chance if someone doesn't keep pressing on. And I didn't bat an eye at any potential improvements, as long as it was reasonably optimized, so as to stand some chance against a competent team, by having any complete run by the deadline. I did what I could to rouse my team into making at least a few tests, so that I feel something is going on, that I'm not the only one doing the work. That did get them going, at least somewhat, but they will say I was still the one charging through the game almost single-handedly.
Well, apparently the other teams were hit with the lack of motivation harder than we were. Or, at least, harder than I was. We win primarily due to that. ... We need a different Dream Team Contest game.
As far as scripts go, I didn't develop much. Just a little something to scan the RNGs using the disassembly MESHUGGAH got. And another something to reveal what was supposed to be tile information, but I only got the palette of each 16x16 tile instead. Regardless, it was somehow enough to see the invisible platforms in two of the auto-scrolling stages, as they used a different set of colors for some reason. Finally, I made much use of a modified MtEdit, which merely tracked what frames had lag.
But at least we're through it. So, in the spirit of the Dream Team Contest, I give my cheers, even if it ended somewhat poorly for over half the teams. I hope to see this run obsoleted soon by Team 1.

MESHUGGAH's comments

First, I'm glad I had scrambled with professionals (check lineup). While we worked as a team, this submission was mostly FatRatKnight's amazing attitude's result. I enjoyed this project even this game was a piece of clap (use japanese pronouncation). I mostly did some debugging stuffs and deliberate attempts to decrease lags (mostly unsuccessfully). It worths mention that the game has MANY emulator issues, which won't be fixed in the near future, therefore I don't motivate you to improve it, unless you are good at vomitting. Also take a look at FatRatKnight's awesome subtitles, at least I enjoyed them =)
Possible improvements (this notes regards to FCEUX 2.1.5 old PPU, newer versions won't sync due emulator issues)
  • You need to plan very carefully your route because hex-editing in improvements will make the game out of sync (you have something like ~1000 frames where you can avoid out of sync, it depends a lot on how you abused the emulator indirectly (by playing the game).
  • You can change the lag pattern after the 7th frame (notice we intentionally ignored this to avoid accusations of abusing the emulator) by inserting different input that doesn't changes the menu handling (for example holding B earlier than you would need to at "fast-text"). You can adapt this through-out the whole run, with the combination of reducing/extending various inputs on various frames. This can be only done on some special conditions (due to emulator issues).
  • The Chapter 2 auto-scroll section can be improved with grappling on the invisible platform, similar way as in Chapter 5 auto-scroll section.
  • A further investigation of suitable RNG calls for different mid and final bosses.
  • You can skip Chapter 5 "pre-light changing" section mid-boss by going out of the screen, as Team 1 did.

DarkKobold: Congrats Team 2! Judging!
feos: Added HD encode with Authors' soft subtitles.

DarkKobold: Congrats once again to Team 2, accepting.
sgrunt: I'll take it from here.

TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 14856
Location: 127.0.0.1
Expert player (3566)
Joined: 11/9/2007
Posts: 375
Location: Varberg, Sweden
Congratulations in finshing this hard task and winning the contest! Truly a very impressive effort given the limited timeframe. I saw some things that could've been a little faster but it's not like you could've spent days optimizing each room. Really nice RNG manipulation! I didn't even know there existed a series of 25 RNG numbers where only 3 of them were even (for the bull band), and you also got perfect RNG manipulation for the first ghost dog - everything without significant waiting in between the levels. If it's not too much to ask, I'd really like to know how the RNG planning process played out. Team 1's effort in completing the task is also worth kudos. Sub 17 is respect!
feos wrote:
Only Aglar can improve this now.
MESHUGGAH
Other
Skilled player (1888)
Joined: 11/14/2009
Posts: 1349
Location: 𝔐𝔞𝔤𝑦𝔞𝔯
Aglar wrote:
Really nice RNG manipulation! I didn't even know there existed a series of 25 RNG numbers where only 3 of them were even (for the bull band), and you also got perfect RNG manipulation for the first ghost dog - everything without significant waiting in between the levels. If it's not too much to ask, I'd really like to know how the RNG planning process played out.
Thanks, it was also a result of teamworking. The subroutine $FE60 is the "base RNG seed", and we watched the RNG calls @ 0x00F1.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Editor, Skilled player (1171)
Joined: 9/27/2008
Posts: 1085
Aglar wrote:
[...] If it's not too much to ask, I'd really like to know how the RNG planning process played out.
Not too much went into it, really. First, MESHUGGAH found the RNG subroutine. I analyzed it and came up, effectively, with a set of lua functions that emulate the RNG subroutine:
Language: lua

local RT= {0,0,0, C= 0 , F= 0} -- Holds RNG related stuff --***************************************************************************** local function AddRNG(R,Rn,Val) --***************************************************************************** local r= R[Rn] + Val + R.C R[Rn]= r % 0x100 R.C = bit.rshift(r,8) end --***************************************************************************** local function RNGLoop(R) --***************************************************************************** AddRNG(R, 1 , 0x25) -- $00F3 AddRNG(R, 2 , 0x33) -- $00F4 AddRNG(R, 3 , 0x53) -- $00F5 -- RNG stuff | Carry local r= R[3] + R[1] + R.C r= r % 0x100 + R[2] + bit.rshift(r,8) R.C= bit.rshift(r,8) -- $00F2 r= r % 0x100 R.F= bit.bxor(R.F, r) -- $00F6 end --***************************************************************************** local function RNGCall(Loops) -- For 1 loop, use 0. --***************************************************************************** for i= 0, Loops do -- Loops is addr:00F0 AND with 0x0F RNGLoop(RT) end end
From that, I then used these functions to, for the most part, scan for the best RNG given all 16 possible wait-time RNGs at the title screen. What luck there was a string of 22 out of 25 good RNGs for the end boss in one possibility, with minimal wait. Unfortunately, we crashed into a pretty severe problem at the refight of that same boss. Namely, the lack of any decent RNGs within several hundred RNG-rolls. We couldn't get anything less than 8 sets of light-drops in decent time. So we took an alternate solution: Destroy those side minions. For whatever reason, destroying them prevents further light drops. Fun, no more need to manipulate that. No analysis was done for any other bosses, however. This is likely one area of improvement.
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11264
Location: RU
No one is encoding??? I am!
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.
AnS
Emulator Coder, Experienced player (723)
Joined: 2/23/2006
Posts: 682
Watched this twice after watching Team1's movie, and yet didn't get bored! The game has enough variety and tricks, and its pace isn't as slow as in some other NES platformers. Gotta admire FatRatKnight's patience for putting so much effort into solving acrobatic puzzles throughout all 5 channels. Last time I tried to TAS the game (5 years ago) I've only found enough patience to polish Channel X, and it took me same 3 weeks or so. Well, sure, some parts here looked less optimized than in Aglar's wip, but it's hard to compare because of different channels route and therefore different lag picture. So even though this run is improvable, I agree it's not wise to continue polishing it using same old tools (savestates and Frame Advance), because it would require investing too much time for increasingly smaller amounts of saved frames. Oh, and nice touch with subtitles, I wish people used them more often. There was a line in the subtitles about not using dances to avoid lag. If I remember correctly from my experience, there IS some room for dances, but it should be done very carefully. I understand that you didn't have the time for that.
FatRatKnight wrote:
Unfortunately, we crashed into a pretty severe problem at the refight of that same boss. Namely, the lack of any decent RNGs within several hundred RNG-rolls. We couldn't get anything less than 8 sets of light-drops in decent time. So we took an alternate solution: Destroy those side minions. For whatever reason, destroying them prevents further light drops. Fun, no more need to manipulate that.
That actually went pretty fast, good idea. (plus some variety for entertainment) Although maybe it would be faster to manipulate by waiting in channel select screen. Team1 did it in rather stylish manner (roulette-like choosing).
MESHUGGAH wrote:
It worths mention that the game has MANY emulator issues, which won't be fixed in the near future
Can you tell what are these issues in particular? BTW, both contestants' runs sync well on 2.1.5 and 2.1.4a (and on 2.1.6 as well), using OldPPU of course.
Senior Moderator
Joined: 8/4/2005
Posts: 5770
Location: Away
"I'm coming as fast as I can!" is so inviting itself for a "that's what she said" joke. Anyway, yes vote for one of the longest-awaited improvements. It did not disappoint.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
MESHUGGAH
Other
Skilled player (1888)
Joined: 11/14/2009
Posts: 1349
Location: 𝔐𝔞𝔤𝑦𝔞𝔯
AnS wrote:
MESHUGGAH wrote:
It worths mention that the game has MANY emulator issues, which won't be fixed in the near future
Can you tell what are these issues in particular? BTW, both contestants' runs sync well on 2.1.5 and 2.1.4a (and on 2.1.6 as well), using OldPPU of course.
FCEUX 2.1.4, FCEUX 2.1.5 and FCEUX 2.1.6 shares the same code that used for emulating games, it didn't changed. But newer versions which will have corrections/improvements/further developed code won't sync this run. The list of possible issues (didn't figured out really yet): incorrect PPU frame length (maybe 4 frames faster?), incorrect cpu cycles for sprite DMA copy (1 frames faster) and wrong RTI implementation (I'm not 100% sure about that). There are several games that suffers from this game, check out this: Wiki: ConsoleVerificationTests. Offtopic: last night feos contacted me about debugging Battletoads. I actually discovered that both games shares these kind of issues (cpu cycle dependency, and RTI in input polls). And I improved his upcoming WIP with 68 frames (the warping section) after a bit of trace log comparing and translating feos' notes from russian to english.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Brandon
He/Him
Editor, Player (190)
Joined: 11/21/2010
Posts: 913
Location: Tennessee
feos wrote:
No one is encoding??? I am!
I said I wanted to encode the submission that gets accepted. I have a feeling Team 1 will submit a run beating this shortly.
All the best, Brandon Evans
AnS
Emulator Coder, Experienced player (723)
Joined: 2/23/2006
Posts: 682
MESHUGGAH wrote:
FCEUX 2.1.4, FCEUX 2.1.5 and FCEUX 2.1.6 shares the same code that used for emulating games, it didn't changed.
Actually id did! And that's why I was surprised that Rockin' Kats sync on both 2.1.4 and 2.1.5. Try that WIP of Battletoads you mentioned, it syncs on 2.1.4 and doesn't sync on 2.1.5, because in 2.1.5 there's nasty bug caused by mapper revision. This bug was fixed in 2.1.6, so Battletoads (and probably all other runs made for 2.1.4) will sync in 2.1.6 (while not necessary syncing in 2.1.5).
MESHUGGAH wrote:
But newer versions which will have corrections/improvements/further developed code won't sync this run.
Sure, but this also applies to any other NES game. And Rockin' Kats actually appears to be more sync-stable than Battletoads.
MESHUGGAH wrote:
last night feos contacted me about debugging Battletoads. I actually discovered that both games shares these kind of issues (cpu cycle dependency, and RTI in input polls). And I improved his upcoming WIP with 68 frames (the warping section) after a bit of trace log comparing and translating feos' notes from russian to english.
Hey! These were my notes! :D Nice job with improvement, but it's still far from what could be achieved by reverse-engineering that stuff I addressed there. Huh, but where did you find RTI in input polls there?? I see standard poll procedure, nothing fancy. As for cpu cycle dependency, well, majority of NES games have this issue, don't blame RK for that.
MESHUGGAH
Other
Skilled player (1888)
Joined: 11/14/2009
Posts: 1349
Location: 𝔐𝔞𝔤𝑦𝔞𝔯
edit: Thank you for the encode feos =) Offtopic:
AnS wrote:
MESHUGGAH wrote:
FCEUX 2.1.4, FCEUX 2.1.5 and FCEUX 2.1.6 shares the same code that used for emulating games, it didn't changed.
Actually id did! And that's why I was surprised that Rockin' Kats sync on both 2.1.4 and 2.1.5. Try that WIP of Battletoads you mentioned, it syncs on 2.1.4 and doesn't sync on 2.1.5, because in 2.1.5 there's nasty bug caused by mapper revision. This bug was fixed in 2.1.6, so Battletoads (and probably all other runs made for 2.1.4) will sync in 2.1.6 (while not necessary syncing in 2.1.5).
Well actually I synced feos' Battletoads WIP 8 on both 2.1.5 and 2.1.6 (my improvement is made on 2.1.6 fceux/taseditor).
AnS wrote:
MESHUGGAH wrote:
...both games shares these kind of issues (cpu cycle dependency, and RTI in input polls). And I improved his upcoming WIP with 68 frames (the warping section) after a bit of trace log comparing...
..Nice job with improvement, but it's still far from what could be achieved by reverse-engineering that stuff I addressed there. Huh, but where did you find RTI in input polls there?? I see standard poll procedure, nothing fancy. As for cpu cycle dependency, well, majority of NES games have this issue, don't blame RK for that.
I'm not at home currently, but I wrote it on ICQ to feos about that, ask him about subroutines and memory values that I posted to him. Or wait until tomorrow. Ask in PM, please don't make more offtopic posts as I did.
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
AnS
Emulator Coder, Experienced player (723)
Joined: 2/23/2006
Posts: 682
MESHUGGAH wrote:
Well actually I synced feos' Battletoads WIP 8 on both 2.1.5 and 2.1.6
Ah, I see! You used old FCEUX 2.1.5-Interim which is basically 2.1.4. It even says emuVersion 2.10.40 in your movie, and this Rockin' Kats submission was made in interim too, good thing that this particular game syncs with official release of 2.1.5.
Skilled player (1306)
Joined: 9/7/2007
Posts: 1354
Location: U.S.
TASVideoAgent wrote:
It worths mention that the game has MANY emulator issues, which won't be fixed in the near future, therefore I don't motivate you to improve it, unless you are good at vomitting.
There are emulation issues with this game? Funny, I didnt even see any. On the side of this run, AWESOME. Its nice to see the 2005 movie finally being obsoleted. Incredibly entertaining run, and never got bored throughout the run. Heres a big Yes vote, however there may still be improvements in the run. But given how painful it is to TAS this game, this is good enough.
Skilled player (1636)
Joined: 11/15/2004
Posts: 2202
Location: Killjoy
Sonikkustar wrote:
TASVideoAgent wrote:
It worths mention that the game has MANY emulator issues, which won't be fixed in the near future, therefore I don't motivate you to improve it, unless you are good at vomitting.
There are emulation issues with this game? Funny, I didnt even see any. On the side of this run, AWESOME. Its nice to see the 2005 movie finally being obsoleted. Incredibly entertaining run, and never got bored throughout the run. Heres a big Yes vote, however there may still be improvements in the run. But given how painful it is to TAS this game, this is good enough.
They aren't visible, they are technical/timing issues.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
Editor, Experienced player (882)
Joined: 7/20/2011
Posts: 345
This run was awesome, especially given that it was done within a timelimit. I wasn't expecting it to be that entertaining, but I've never played this game. As far as improvements, we'll just have to wait and see what the others will be able to do with it. Already voted yes.
Current thoughts: Hachiemon (J) for GBA.
Experienced player (527)
Joined: 11/14/2004
Posts: 169
Location: Mirabel, Québec, Canada
FatRatKnight wrote:
Unfortunately, we crashed into a pretty severe problem at the refight of that same boss. Namely, the lack of any decent RNGs within several hundred RNG-rolls. We couldn't get anything less than 8 sets of light-drops in decent time. So we took an alternate solution: Destroy those side minions. For whatever reason, destroying them prevents further light drops. Fun, no more need to manipulate that. No analysis was done for any other bosses, however. This is likely one area of improvement.
I dumped a list of all random sequences for boss 1 and miniboss 3, based on frame delays at the title screen then random rolls: http://acmlm.cjb.net:2/emu/nes/fceux/lua/rk-rnd.txt This run waited 8 frames at the title screen, giving a perfect miniboss 3 (no splitting) almost instantly and only 3 lamp falls at boss 1 soon after, but nothing good for channel 5 (which comes at about 330 rolls here). For my team's run, we also considered using this at first but then decided to wait 6 frames instead, giving the wanted results (3 falls and no split) significantly later but with much better luck for channel 5 (7 falls and still no split). I also looked at the few other things that use random values, but most of them aren't worth manipulating: - Each bird enemy (about 10 of them in channel 2 before the miniboss, a few more in channel 5) randomizes on spawn but doesn't seem to do anything with it - The second area in channel 5 (short with skateboarding enemies) spawns enemies at random intervals, ranging from 1 to 15 frames (around 15-20 times total) - Miniboss 2 throws either a green ball or small bomb at 50% chance each (we made it only throw bombs) - Boss 2, when defeated and exploding, randomizes 232 times - The gorilla picks a random X speed (from -2 to +2) on each jump - The final boss sometimes randomizes every frame, for a 1/512 chance (1/4 then 1/128) to drop a bomb There's at least 20 seconds of known improvements (mostly from skipping miniboss 2 in channel 5), and we'll eventually redo channel 5 properly to gain about that much, but it's a definite Yes vote until then (and congrats for finishing a good/submittable run in time)!
Joined: 4/1/2010
Posts: 96
moozooh wrote:
"I'm coming as fast as I can!" is so inviting itself for a "that's what she said" joke.
I know, right? This screencap is so unintentionally suggestive:
NitroGenesis
He/Him
Editor, Experienced player (551)
Joined: 12/24/2009
Posts: 1873
You can play with my Big Eagle
YoungJ1997lol wrote:
Normally i would say Yes, but thennI thought "its not the same hack" so ill stick with meh.
Editor, Experienced player (608)
Joined: 11/8/2010
Posts: 4012
Thanks for the encode, feos. This run looks great. A really big improvement over the published movie! I'm voting Yes, and awaiting the other team's improved run.
moozooh wrote:
"I'm coming as fast as I can!" is so inviting itself for a "that's what she said" joke.
Didn't you just make one by saying that?
Player (136)
Joined: 9/18/2007
Posts: 389
Good job. There might be one more possible improvement The RNG subroutine usually overwrites values F0 through F6 exactly 16 times. This can be broken in some way, but sadly I haven't recorded it... I think it's possible by changing the weapons and causing an explosion and letting two enemies appear that advance the RNG on the same frame.
Player (116)
Joined: 5/13/2009
Posts: 700
Location: suffern, ny
Wow! Great game! Great TAS. i enjoyed it! YES vote
[19:16] <scrimpy> silly portuguese [19:16] <scrimpy> it's like spanish, only less cool
Mitjitsu
He/Him
Banned User, Experienced player (532)
Joined: 4/24/2006
Posts: 2997
Very well done, yes vote. IMO this is a horrible game choice for a dream team contest, next they'll be doing Forsaken.
Former player
Joined: 11/13/2005
Posts: 1587
How much damage does the second boss take if you grab and throw the green ball at him instead of punching him? There are also other bosses where you can grab things and throw them at the boss, but I have no idea if it does the same amount of damage as the punching or not.
Site Admin, Skilled player (1236)
Joined: 4/17/2010
Posts: 11264
Location: RU
This info was never mentioned anywhere, thogh this trick was used in some team's run (miniboss of the 1st level, as well as grabbing the candle to kill the orange).
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.
Former player
Joined: 11/13/2005
Posts: 1587
I don't think it's any kind of a trick as I always beat the bosses that way as a kid :D