Kero Kero Keroppi 2 is a game released in Japan only. It features a frog who seems to have a really bad day: not only all his friends were kidnapped by some Wizard, but his dream of becoming a singer will never come true as he discovered that his singing skill kills. Literally. Thankfully he realised he can combine both of these problems into a single adventure by defeating Wizard's minions with his bad voice, saving his friends and becoming a local hero.
Made in FCEUX 2.2.3. This movie beats current publication by 2723 frames.
FCEUX was used instead of BizHawk due to much better performance of FCEUX in general and TASeditor in particular. While emulation accuracy is usually the main criteria when choosing an emulator, this game behaves almost the same on both emulators. BizHawk adds 3 lag frames on one of the loading screens and also times movie length on the frame next to the one with last input, while FCEUX counts the last frame the frame with the last input. This allows the run to be portable between emulators so the one with much better performance was chosen.
EZGames69 kindly provided BizHawk version 15 seconds after the movie was submitted. It can be found
here.
Tricks
Boosting
The character starts to accelerate when you press right or left and reaches a peak speed of 1.5 pixels per frames. The game tracks your position in both pixel position and subpixel fraction. There are 3 bytes total: 2 for position and 1 for fraction. When the button is released, the character decelerates and comes to a halt.
The sole reason this TAS was made is the bug with deceleration midair: when move button is released midair, it sometimes causes you to move for a speed of 2 pixels per frame for a short time. In casual play, this results in many frustrating deaths because the game has many small platforms which are hard to land on and it is natural to let go of the button to avoid overshooting... and overshoot only more.
Under TASing condition this is however easily overlooked since in a TAS you usually never let go of movement buttons.
Now, I said that releasing the button _sometimes_ increases your speed. This is where things get funny... or messy, depends on how you look at it. The boost can only happen if the lesser byte of your position has value that is between 0x00 and 0x7F. When jumping and releasing movement button, the subpixel byte gets messed up and is assigned some strange values. Furthermore, the speed has absolutely nothing to do with the boost. You can have the speed of 0.5 pixels per second but move 2 pixel per second anyway. Between the aforementioned values subpixel byte is assigned a value below 0x7F and it then ticks down by 4 every frame. When it underflows, the boost ends.
When the underflow happens, you can tap right for a frame to reset this byte above zero again and keep boosting. When the button is pressed, you move 1 pixel for that frame since 1.5 pixels per second is moving 1-2-1-2 pixels on consecutive frames.
Logically you would want to perform the boost on the earliest frame - the one with 0x00 X byte value. But the subpixel is assigned in some odd way. On my tests, it turned out that starting the boost too early causes the byte to misalign next button presses and the totaly amount of right being pressed will negate the gain of early start since frame with R pressed is at speed of 1. Of course you cannot start way too late too since you want the boost to be long.
The optimal starting frames seems to be around when X byte is 0x20. Since the boost is not set in stone, it is possible to slightly delay or start the boost earlier without losing frames, but that does not always works.
Another thing to mind is that the game is not just about boosting - we still have platforms to jump on. but since the boost is limited to airtime, we want to time the presses in such a way, so that when we can't make the boost for the duration of a single jump, we should time any landings on a frame before we underflow fraction byte and apply right button 2 frames before and a jump button on 1 frame before. That causes us to lose no frames at all.
The same is also possible to do with jumping on enemies, though one must carefully monitor the speed: when it sharply drops, it should be considered as landing and the same technique must be applied.
Impossible jumps
Now that we can move a bit faster for a lot of places, certain jumps that would need some waiting for platforms or enemies to jump onto can be made without waiting at all. This saves even more time.
Card games luck
The card games (which are basically boss stages) are challenges of pure luck during casual play. Of course since we are TASing this is something we can control.
The cards are generated when the level is started and do not change after that. So luck manipulation allows one to change layout of cards but only before the card level is actually reached.
Card games have 4 tasks:
First one requires you to find 5 chicken cards. No luck is involved since the few layouts that are present can be all cleared within minimal time.
Second one is Lucky Seven. You must find pairs of cards that are greater than the pair of cards the opponent finds. If your pair equals seven, you immediately win and get not 1, but 2 points. This is cleared really quick. This is also the only level in the game that is not faster that the current publication, although it is equally fast, not slower.
Third one is Rock-Paper-Scissors game. The cards always flip for fixed amount of flips and this amount increases by one every round. The only thing to manipulate is that if you need to select the lower card to win, it is slower by 2 frames than by selecting upper or middle one.
Fourth and final game is pair matching. You take turns with computer matching pairs. If the pair is matched, the winner keeps matching. Of course we match perfectly and never see the computer playing. This game is managed noticeably better than x2poet's publication due to much better layout with pairs being located right next to each other, allowing me to move the cursor and flip a card within a single frame.
Improvement comparison
Here is the table that compares my TAS to the current publication, x2poet's TAS. Note that x2poet's publication was done on a different version of emulator and does not syncs naturally due to different loading time in the beginning. About a hundred of empty frames in the beginning however is all it takes to sync. Other than that, I did not noticed any other differences.
The frame numbers represent the first frame after the level end when the screen totally fades to black, except the last level where the ending frame is the one with last input.
| Level | x2poet's TAS | dart193 | Section | Total |
|---|
| 1-1 | 3232 | 2989 | -243 | -243 |
| 1-2 | 6127 | 5668 | -216 | -459 |
| 1-3 | 9023 | 8347 | -217 | -676 |
| 1-B | 11490 | 10782 | -32 | -708 |
| 2-1 | 14397 | 13461 | -228 | -936 |
| 2-2 | 17292 | 16144 | -212 | -1148 |
| 2-3 | 20200 | 18823 | -229 | -1377 |
| 2-B | 22406 | 21029 | 0 | -1377 |
| 3-1 | 25313 | 23724 | -212 | -1589 |
| 3-2 | 28210 | 26419 | -202 | -1791 |
| 3-3 | 31119 | 29102 | -226 | -2017 |
| 3-B | 35845 | 33821 | -7 | -2024 |
| 4-1 | 38760 | 36500 | -236 | -2260 |
| 4-2 | 41656 | 39179 | -217 | -2477 |
| 4-3 | 44667 | 41958 | -232 | -2709 |
| 4-B | 45720 | 42997 | -14 | -2723 |
I used a small LUA script that helped me to boost at appropriate times for enough frames. It is located in my
user files
Future improvements
I was pointed out by Blazephlozard that if subpixels are carefully managed, it is possible to boost earlier and save much more time. He did a playthrough of the first level and managed to save about 45 frames but found the task to be far from trivial. I, on the other hand, was not able so understand what exactly happens there: all my tries steal a frame or two instead of gaining any.
With a lot of free time and a huge patience it is possible to manually improve every level but only with a better understanding of boost mechanics. Furthermore, LUA scripting assistance is needed and even then a careful analysis is needed.
Special thanks and mentions:
- Thanks to Spikestuff for temporary encode.
- Thanks to EZGames69 for BizHawk conversion.
- Thanks to Blazephlozard for pointing out possible improvements.
ThunderAxe31: This is the kind of game that appears bland, but actually has a lot going on under the hood regarding its mechanics.
Some new improvements have been found, however this won't be an issue for this movie for two reasons: first, because those were found after that this movie was already submitted, and second, because those improvements didn't prove this submission to be suboptimal anyhow. Additionally, I want to note that this submission aims to improve an already published movie, which was up to date with the known game knowledge available at the time.
The audience response wasn't very enthusiastic, so it's going in Vault like its precedessor. Accepting for obsoleting the
previous movie.
fsvgm777: Processing. Zinfidel is handling the encodes for this one.
If I just add an extra Right input the frame the jump starts, instead of 1.5, 1.164, 1.984... it's 1.5, 1.5, 1.672, 1.984...
This ends up being .023 subpixels better. A small amount to be sure, but it adds up, and this happened to be a weak jump; in a different spot, when on the second jump of a boost section, I had a diff of 2.277 for one frame in place of the 1.672. (It's possible chaining as many small jumps as possible during the boost section could be valuable, if these 2+ diffs happen only then)
I also tested letting go of R outside of the 20-80 area. If you oscillate R, you get very very slight subpixel increases in the diff from fd->20.
I'm using Bizhawk so I changed your Lua to use read_s8 for signed bytes so this won't work in fceux but here
https://pastebin.com/pZH2SSb6
this is the important bit:
The oscillation idea wasn't needed, because it seems like the distance you gain from it accumulates if you don't do it (like oscillating gets you 1.512 instead of 1.5, but if you hold off, you'd get 1.524, hold off again 1.536, etc). So the first frame you let go in midair, you get all of that accumulated distance regardless. I also didn't get anything out of extra Right presses after the jump.
I mainly improved the distance just by starting the boosting at 0x08 instead of 0x20. It does take more Right presses, but any frames where you can move at higher than 1.5 is worth it. This saved a few frames on every boost section.
But I think this would fall under "laboursome optimizations that can't actually be noticed under normal viewing conditions". I certainly felt laboured going at this first level for a few hours. For the strategy used, the play is not sloppy at all, and I would say it should still be published. (Though if you're not interested, a V2 is going on my eventual projects list...)
My advice for the future is to have a very readable way (through Lua) of telling how much distance you're traveling if 'xspeed' is unreliable, and when it comes to moving at speeds higher than a speed cap, don't dismiss brief bursts in favor of longer stretches, any speed increase can be useful.
