User Files from dwangoAC

This movie file demonstrates a hardest-possible scenario in the game Blockout and demonstrates clearing a 5x5x5 pit on the highest difficulty.

There were requests to do some taunting, so I did a taunt at the end of the Akuma battle and figured out a way to save a couple of frames in the process.

Is there any value in continuing? Despite the low rerecord count this has been about 6 hours of work, mostly deducing how evil the RNG in this game is. It turns out that the colors you will get next can only be affected by two things - the frame on which the level is started (either the frame you press start on the beginning menu or the frame on which the previous level was completed) and "missed" shot colors during the level, i.e. ones that don't touch the correct color. No other waiting or button mashing will have any impact on the RNG. This results in odd pauses prior to starting the level and intentionally firing at the wrong color, not to mention the very tedious process of testing entire levels with multiple starting states to see if future luck will be worth early bad looking results.

I've completed two levels but I'm not sure if it's worth continuing as I suspect this would be quite tedious for very little benefit. Thoughts?

The file I used in my Crazy Climber submission was unintentionally longer; I apparently botched it when I saved the movie, even though I thought I had truncated the movie to the last frame. This file now ends as soon as the arm is extended *just* far enough to reach the helicopter.

This lsnes + Gambatte movie starts Pokemon Red with an existing (corrupted) GB SRAM state that contains the player character RED, the rival name xAxA(Pk), and FF in *just* the right place to allow further exploitation. This movie file uses input suggested by Masterjun based on FractalFusion's work to execute arbitrary code, which it does very well. One minor caveat: I've discovered with help from Ilari and padz that D+U and L+R (representing bit values 128, 64, 32, and 16 respectively) are canceled out by the SGB BIOS meaning FractalFusion's payload can't be written as it contains the value 0xD3. This movie file contains a bunch of input at the end that softlocks the game in an interesting way but doesn't yet do exactly what we want it to. Still, it shows arbitrary code execution on Pokemon Red, which is good.

Because support for this filetype hasn't been added yet I've used a dummy file in this WIP (and, um, I'd ignore it if I were you, but that's just me. :) I've uploaded the real movie file to:

This lsnes + Gambatte movie starts Pokemon Red, names the player character RED, and names the rival xAxA(Pk). After getting into the game, it resets and should be truncated on the frame the reset occurs. This will allow for later hardware reset testing at movie end. I do not know if support for this filetype has been added yet so I've used a dummy file in this WIP (and, um, I'd ignore it if I were you, but that's just me. :) I've uploaded the real movie file to:

IMPORTANT NOTE: the file that is uploaded here is the wrong file and is simply a placeholder (because the parser does not understand the as-of-yet unreleased Gambatte core). The correct file can be found at:

http://acbit.net/static/tas/PokemonRedSGBdwangoACnewGambatteCore.lsmv

This is a comparison movie that completes Pokemon Red up to identifying the trainer ID using the new Gambatte SGB core in lsnes. I tried to always do everything on the very first frame possible. As was somewhat expected, this move does not synchronize on real hardware without some twiddling because the core or the process of handoff from SNES to SGB is somewhat inaccurate (by about 1 frame). Raw data dump from my testing sequence:

There's exactly 1 frame off at the beginning of the movie (i.e. I had to add 1 frame in order to allow the start button press to be recognized when playing back the dumped run on real hardware). The base movie trainer ID is 25143 per emulator; adding 1 frame before first button press causes the emulator to desync, manually playing through anyway changes trainer ID to 40964. I got it to sync further on real console by adding one frame at the very start and adding another immediately after acknowledging the grandson's name; that allowed the real console to sync until meeting Prof. Oak, late enough that the Trainer ID should have already been decided. I played through the rest manually and got trainer ID 18765.

Late in my testing, I replayed the exact same file I had tested before and for whatever reason the timing is was wrong at the very beginning. I'm not sure if I mangled the .r16m replay file somehow or if there is other saved data impacting the real hardware startup - if it's the latter it is far more concerning. Additional testing is required.

(Again, the file in this upload is the wrong one, please download the correct file from http://acbit.net/static/tas/PokemonRedSGBdwangoACnewGambatteCore.lsmv instead.)

This is a comparison movie that completes Pokemon Red up to identifying the trainer ID using the original SGB core in lsnes. I tried to always do everything on the very first frame possible. As expected, this move does not synchronize on real hardware because the core is not very accurate (likely 14 lag frames would be needed at the beginning based on past experience). I'll be doing this again on the new Gambatte core implemented by Ilari to compare the differences (loosely - I didn't actually intend to make this movie, all of this work was supposed to have happened on the new core).

This is an instance of Pokemon Yellow for SGB for use with lsnes for console verification. This is supposed to get to the point of asking if you want to save the game (but doesn't hit yes). Initial console verification tests show that this is not console sync-stable, likely due to emulator inaccuracies in lsnes.

Commodore 64 submissions are not yet accepted, so I'm uploading the actual submission to movie storage.