Objectives
- Submitting the first BizHawk
2.5 2.5.1 movie!
- Saving in a corruptous way!
- Showing off the GBC BIOS!
- Shamelessly copying the boss fight from the previous publication, without asking permission to the author!
About the game
E Mo Dao aka 惡魔島 aka Devil Island aka Devil Land aka Alcatraz Island aka Forget Everything You Know About TASing, is a GBC bootleg game by Vast Fame. The game is basically a port of the NES game Getsu Fuuma Den, but with graphics changed in order to make it similar to a Castelvania game. The pseudo-3D levels were omitted entirely. The sound engine is taken from Mega Man V, while the musics are original compositions by Yishen Liao.
Controls
Select button: quick saves the game while on the overworld. Interestingly, there are also save points, but I didn't need these.
Start button: pause the game while in a level. While paused, press A or B to select items for use, then unpause.
Unlock everything fast
In the SRAM, the data about the items unlocked is stored last (SRAM domain, bytes 0x0220-0x0229). So if you turn off the console while saving a new game file, just before the the item data is written, you can have it kept to 0xFF uninitialized bytes, which means that you have all items unlocked, and money and exp maxed. Yay!
Overworld Y buffering
In SRAM memory domain, byte 0x0211 stores the player's X position on the overworld map, byte 0x0212 stores the Y. By resetting at the right moment while saving, we can have the game saving the X position, but not the Y one. This allows for some warping trickeries on the overworld map.
Direction buffering
In SRAM memory domain, byte 0x0213 stores the direction facing. Since the game takes 1 frame when you change direction in the overworld, it's faster to sacrifice some cpu cycles for writing this byte, in some situations. Note that the uninitialized 0xFF byte counts as the direction facing downwards.
Level skip
Discovered by Noxxa. Save while walking towards a level entrance, and reset the console. After loading the game, you will be standing on top of the level entrance, without actually entering it. From there, you can just walk over it. Note that most levels have two entrances, so you have to do it twice (unless you can exploit the Y buffering trick).
The boss fight
The final boss stage can be accessed only after having unlocked a special weapon, that does require clearing 3 different stages with a boss at the end; it's basically a whip that does project an air blade. This is also the only weapon that can reasonably damage the final boss. I also used the gauntlet, an item that does temporarily double damage dealth to enemies.
Possible improvements
Nope! I dare you try.
Special Thanks
To Noxxa, for telling me about the level skip glitch, three years ago.
Suggested Screenshot
Memory: The movie’s optimization seems decent. I personally felt the movie wasn’t all that entertaining but others in the audience disagreed and enjoyed the various save glitches used.
However, the bigger question was relating to relying on a specific uninitialized sram layout to perform a save glitch. This submission uses the emulator default uninitialized sram state. Some argued that this might not be possible on an actual cart and as such it shouldn’t be allowed.
The thing one has to understand about uninitialized memory however is that there isn’t one singular valid layout.
This page by Nach has some explanations. So ultimately we can’t know which uninitialized memory layouts are valid and which aren’t without field testing which is incredibly difficult.
It was proposed to rely on the game’s delete save option which sets sram to 0x00 and assume that is the only valid sram initialization. I see this as a faulty assumption. It places too much emphasis on developer intent when developer intent is essentially impossible to prove.
So lets say that we don’t know for sure what uninitialized sram states are possible. Should we force people to avoid routes that rely on specific states altogether? No because such a thing would be impossible. Say for instance a game relies on uninitialized ram for RNG seeding purposes. It’s very possible that the specific state that the emulator uses as default is invalid and that such an RNG seed would also be invalid. Would we force TASers to find a valid uninitialized ram setup and work off that? That seems extremely inaccessible to me and unreasonable. Banning specifically glitches that rely on uninitialized ram also seems silly to me and overly restrictive.
Console verification has increased in popularity in recent years, and I do think that is really cool. However, ultimately TASing and actual hardware are at odds with each other by nature. TASing requires determinism, the environment must behave exactly the same way each time or else things wouldn’t sync. Hardware however, does not require determinism in the same manner. There is no singular true hardware experience for a large number of platforms or games. Games with disc based loads are notoriously non-deterministic, various factors can affect loads and result in inconsistent behavior.
As such, while console verification is a cool goal, it ultimately should not be a requirement for TASing. To do so would result in restrictions on console choice and game choice. Note this does not mean emulator only glitches are or should be allowed. If one were to find a cartridge with the required uninitialized sram state for this glitch, this movie would be replicable. As such I don’t think it classifies as an emulator only glitch in the traditional sense, which is where the emulator has a bug that can be potentially fixed.
Traditionally we allow techniques such as simultaneous left + right and mid-save resets which go against software intent. I’d argue this is a similar case. However, what difference is that compared to other sorts of glitches? The entire nature of TASing goes against such intents. As such I believe it should be allowed and in fact preferred if it is faster.
