Submission #7521: MarioAtWork's GB Deadeus "game end glitch" in 01:32.45

(Link to video)
Console Game Boy Emulator BizHawk 2.8
Game Version unknown Frame Count 5522
ROM Filename Deadeus - 1.2.5.gb Frame Rate 59.7275005696058
Branch game end glitch Rerecord Count 263
PowerOn Authors MarioAtWork
Game Deadeus
Submitted by MarioAtWork on 6/3/2022 12:22:09 PM

Submission Comments
WARNING: FLASHING LIGHTS
Deadeus is yet another Gameboy homebrew (you can't stop me TASing them all; they're too fun :) released in 2019 in which a small boy has a prophetic nightmare telling him that everyone will die in 3 days and that he must investigate the village to see if he is able to save them, if at all. This TAS completely ignores that dream and instead warps all the way to the credits, skipping about... a minute of glitchless gameplay (yeah, this game isn't that long anyway).

Game objectives

  • Emulator used: Bizhawk 2.8
  • Aims for fastest possible time
  • Abuses programming oversights
  • Played on version 1.2.5

Teleportation Glitch

This entire movie is based on the ability to teleport anywhere whenever which is also why this is played on version 1.2.5 given it was patched in the most recent update. I'm not entirely sure why it works but it's done by holding Select to open the map and B to close it, making the game continuously open and close it and, for whatever reason, it warps the player across the various scenes.
The reason we end the first warp early is because of the order all 101 scenes are loaded in when performing the glitch. It takes 66 'flashes' to get from the bedroom (the starting place) to the first bit of the cedits sequence. However, it takes 2 warps to get 'Outside' and then we can wrap round the screen to the area in which the 'Neighbour's House' is. This is convenient since it would take 44 warps from the bedroom to get here, leaving only 22 more to get to the credits.

slamo: Claiming for judging.
slamo: I thought this warp glitch was some kind of debug feature upon first seeing it, but after some research I think that's not the case. During screen transitions (including opening the map), the room number is temporarily incremented by one, but if the map is immediately opened again after closing it, the room number is not reverted back and ends up being incremented again. It just seems like a programming oversight to me, so it's fine.
Other than that, the optimization is about as tight as it can be. With RTA timing, this beats the record by less than a second, and the routing is not trivial. Accepting.

despoa: Processing...

Last Edited by MarioAtWork 2 days ago
Page History Latest diff List Referrers