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: Judging
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.
Our rules currently allow default ram initialization states set by the emulator, defaults set by other emulators, and initialization states proven to occur. Note that these emulator defaults are not arbitrarily chosen but are based on patterns proven to work for a majority of games. I do not see a reason to modify these rules at this time.
feos: Pub.

TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 14772
Location: 127.0.0.1
This topic is for the purpose of discussing #6863: ThunderAxe31's GBC Devil Island "save glitch" in 01:56.08
Patashu
He/Him
Joined: 10/2/2005
Posts: 3999
I enjoy how you use save glitches in three different ways to do three different kinds of skips and then humiliate the final boss. It's one of those cases where the lack of the gameplay is the humour, as you work increasingly harder and harder to not have to do things. Yes vote!
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
Noxxa
They/Them
Expert player, Moderator (4131)
Joined: 8/14/2009
Posts: 4083
Location: The Netherlands
I like the creativity you applied with the different kinds of save corruption. Yes vote.
http://www.youtube.com/Noxxa <dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects. <Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits <adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Emulator Coder, Experienced player, Judge (593)
Joined: 2/26/2020
Posts: 691
Location: California
So does the game have any way to wipe save data/does wiped save data pad SRAM with FF bytes? Wondering about the legitimacy of some of this save corruption.
Judge, Skilled player (1274)
Joined: 9/12/2016
Posts: 1645
Location: Italy
CasualPokePlayer wrote:
So does the game have any way to wipe save data/does wiped save data pad SRAM with FF bytes? Wondering about the legitimacy of some of this save corruption.
No, I really don't think this game has that sort pf functionalities. If you're referring to my judgment note for your Pokemon Red "save glitch" TAS, I've also stated that there are games which are known to affect sync depending on the initial SRAM state, so that cartridges need to be formatted with external devices, in order for their TASes to be played back on console. However, your doubt is still valid, as in this submission we have the substantial difference that the uninitialized data is being specifically exploited for performing a save glitch. Regardless, I want to note that this submission relies on just 4 uninitialized bits. Not sure where to draw the line, but I think it would be weird to forbid this glitch while still allowing non-glitching TASes that run on games that are much more sensible to uninitialized SRAM bytes.
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
Emulator Coder, Experienced player, Judge (593)
Joined: 2/26/2020
Posts: 691
Location: California
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!
That sounds a lot bigger than half of a byte :P Anyways, I don't think non-save glitch TAS logic should apply. Those TASes may unintentionally desync due to the state of SRAM. Needing an external device to clear SRAM is really just a sad necessary evil for console sync. However, once we get into save glitch TASes, TASes that inherently exploit the state of save data, that is when abusing uninitialized save data should not be done. In fact... I'm just going to say the Red TAS is already somewhat guilty of this, it technically abused uninitialized save data, its only saving grace is that wiped save data is identical to the technically arbitrary pattern set by the emulator. Even then, I am wondering if that is enough to justify the choice, but I digress. Anyways, I'm just going to put a case that I think can display the issues with letting save glitch TASes use uninitialized save data. Let's say there are 2 emulators with different patterns for uninitialized SRAM. One pads it with FFs, the other pads it with 00s. Both these patterns I would argue are perfectly valid for the purpose of establishing "clean" SRAM. Now it gets dicey when these patterns are abused with save corruption. One emulator could have a better pattern for one movie, the other emulator could have a better pattern for another movie. And, I would go as far as saying movies abusing these technically arbitrary patterns the emulator sets should be considered New Game+ (and thus ineligible for Vault). Your TAS actually displays perfectly why it should, you literally unlock everything because the pattern set the emulator effectively matches a New Game+ kind of SRAM. Again, the pattern set by an emulator is effectively arbitrary, a TAS specifically abusing this should not be allowed in my opinion.
RetroEdit
Any
Editor, Player, Reviewer (164)
Joined: 8/8/2019
Posts: 131
CasualPokePlayer wrote:
Anyways, I'm just going to put a case that I think can display the issues with letting save glitch TASes use uninitialized save data. Let's say there are 2 emulators with different patterns for uninitialized SRAM. One pads it with FFs, the other pads it with 00s. Both these patterns I would argue are perfectly valid for the purpose of establishing "clean" SRAM.
I disagree with this premise. I very sincerely doubt they are equally valid. My ground here is a bit shaky because I don't know the specific examples for Game Boy but I assume they exist. My metric for deciding whether an uninitialized state is fair is whether there exist games where starting with one versus the other makes the game detect existing savedata even without the player doing any manipulation? If that's the case, I would argue this would provide evidence that a certain savedata pattern is not a regular uninitialized state for that cartridge.
CasualPokePlayer wrote:
Now it gets dicey when these patterns are abused with save corruption. One emulator could have a better pattern for one movie, the other emulator could have a better pattern for another movie. And, I would go as far as saying movies abusing these technically arbitrary patterns the emulator sets should be considered New Game+ (and thus ineligible for Vault). Your TAS actually displays perfectly why it should, you literally unlock everything because the pattern set the emulator effectively matches a New Game+ kind of SRAM. Again, the pattern set by an emulator is effectively arbitrary, a TAS specifically abusing this should not be allowed in my opinion.
(bold mine) I really don't see how you can single out savedata as technically arbitrary, when there are so many other differences that can affect emulation accuracy. I disagree with the assertion that are no better or more correct configurations, because, to my understanding, it's not like other types of uninitialized memory where it's nondetermistic based on how your console feels when you boot it up. Instead it's just whatever the manufacturer happened to ship with the cartridge. Which yes, could theoretically be inconsistent if the manufacturer was disorganized, but I would expect certain states to be considered more correct by the game. Now I might be willing to entertain an argument that different games could potentially have different standards. But this is not the same argument that the state is "technically arbitrary" and can't be relied upon at all as a baseline state. I know there are more correct save configurations for GBA emulation, to the extent that certain badly programmed GBA games will detect savedata if you setup the wrong initial state. I would imagine the same is true of Game Boy emulation. EDIT: Here's the example I'm thinking of for GBA. Funny enough ThunderAxe31 commented there.
EZGames69
He/They
Expert player, Publisher, Reviewer (3941)
Joined: 5/29/2017
Posts: 2701
Location: Michigan
haha bios go brr
[14:15] <feos> WinDOES what DOSn't 12:33:44 PM <Mothrayas> "I got an oof with my game!" Mothrayas Today at 12:22: <Colin> thank you for supporting noble causes such as my feet MemoryTAS Today at 11:55 AM: you wouldn't know beauty if it slapped you in the face with a giant fish [Today at 4:51 PM] Mothrayas: although if you like your own tweets that's the online equivalent of sniffing your own farts and probably tells a lot about you as a person MemoryTAS Today at 7:01 PM: But I exert big staff energy honestly lol Samsara Today at 1:20 PM: wouldn't ACE in a real life TAS just stand for Actually Cease Existing
Judge, Skilled player (1274)
Joined: 9/12/2016
Posts: 1645
Location: Italy
CasualPokePlayer wrote:
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!
That sounds a lot bigger than half of a byte :P
Yeah, but I'm not using the other items in this movie, and the money and exp don't affect the fight either (ultimate whip has a fixed damage).
CasualPokePlayer wrote:
Anyways, I don't think non-save glitch TAS logic should apply. Those TASes may unintentionally desync due to the state of SRAM. Needing an external device to clear SRAM is really just a sad necessary evil for console sync. However, once we get into save glitch TASes, TASes that inherently exploit the state of save data, that is when abusing uninitialized save data should not be done. In fact... I'm just going to say the Red TAS is already somewhat guilty of this, it technically abused uninitialized save data, its only saving grace is that wiped save data is identical to the technically arbitrary pattern set by the emulator. Even then, I am wondering if that is enough to justify the choice, but I digress.
Yes, that's why I said that I consider your doubt to be valid.
CasualPokePlayer wrote:
Anyways, I'm just going to put a case that I think can display the issues with letting save glitch TASes use uninitialized save data. Let's say there are 2 emulators with different patterns for uninitialized SRAM. One pads it with FFs, the other pads it with 00s. Both these patterns I would argue are perfectly valid for the purpose of establishing "clean" SRAM. Now it gets dicey when these patterns are abused with save corruption. One emulator could have a better pattern for one movie, the other emulator could have a better pattern for another movie. And, I would go as far as saying movies abusing these technically arbitrary patterns the emulator sets should be considered New Game+ (and thus ineligible for Vault). Your TAS actually displays perfectly why it should, you literally unlock everything because the pattern set the emulator effectively matches a New Game+ kind of SRAM. Again, the pattern set by an emulator is effectively arbitrary, a TAS specifically abusing this should not be allowed in my opinion.
I don't consider that as an issue. All we need to do is agree to use one standardized initial state, for fairness. If an emulator uses something different than 0xFF, reject, unless the run is not exploiting that initial data intentionally:
judgment note for #5915 wrote:
  • There is an emulator bug that causes this game to behave differently from how it should behave regarding SRAM. But this run does not rely on that emulator bug, it just happens to have encountered it. Since virtually all Bizhawk versions have this bug, it's not the author's fault. And even if the new Bizhawk release fixes it, the start of the movie will be different, causing different timings for the entire run, whitch may be impossible to resync without redoing the whole TAS from scratch. Since actual gameplay is still similar to the imaginary bugless version, the run itself is legit.
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
Clever use of save abuse, yes vote.
Experienced player (945)
Joined: 10/13/2014
Posts: 408
Location: nowhereatthemiddleofnoone
:) yes vote
GAW sms... Totally destroyed
Memory
She/Her
Site Admin, Skilled player (1514)
Joined: 3/20/2014
Posts: 1762
Location: Dumpster
Which values could it have been initialized to that would allow this TAS to work?
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Judge, Skilled player (1274)
Joined: 9/12/2016
Posts: 1645
Location: Italy
Memory wrote:
Which values could it have been initialized to that would allow this TAS to work?
I did check again, and I was wrong. The strategies used for this submission do only require two unintialized bits: SRAM domain; bit 6 of byte 0x220, and bit 3 of byte 0x221. The former bit unlocks the ultimate whip, the latter bit unlocks the gauntlet item. Previously, I incorrectly counted four bits, because I thought that the ultimate whip is unlocked by the three bits of the whip parts, but these are actually used for activating the secret bridge. However, in this submission the bridge is not used, as I warp directly inside the castle island by using the Y coordinate buffering save glitch. By the way, I'm happy to see that my submission was appreciated, but I have to note that I'm actually in favor of seeing it rejected. As a judge, I think that's important to set a borderline for the fairness of save glitches, and I really think that uninitialized SRAM data is a major no-no. But don't worry! Thanks to the Y buffering glitch I discovered, I can still beat the published run without having to rely on uninitialized SRAM bytes! I'm just waiting for the next BizHawk version to be released, since it will feature a fix for a graphical bug that happens in GBHawk and SubGBHawk during GBC BIOS... Edit: and here it is, a new TAS that doesn't use the save glitch. It's 26 frames slower than this submission. User movie #65965169748492218 Link to video Edit 2: So, I just did some tests to see how the game handles save data... The game allows for four regular save files, plus the quicksave file. In the main menu, there are five options: new game, load, copy, erase, load quicksave (if present). When you save your game to a save file, the game writes the ASCII string "GETSUFUU" followed by the player data, and it fills the unused bytes of the save file as 0x00. When you use the file erasing option from the main menu, the game will overwrite the save file with 0x00. However, this doesn't apply to the quicksave file, as that can't be selected for erasing... And this submission only used the quicksave. So, we have a situation where we can tell that the game has been clearly designed to consider empty data as 0x00 bytes, as opposed of the classic 0xFF, however the region of the SRAM used for performing the save glitch can't be erased by using in-game mechanics... So, in my opinion, we still have to come out with our own policy for deciding if allowing uninitialized SRAM data or not. Edit 3: I just found out that beside the "GETSUFUU" string, the save file also needs to have at least 1 life left, otherwise the game won't consider the save file as existing. So I guess this submission actually relies on a total of 3 uninitialized bits.
my personal page - my YouTube channel - my GitHub - my Discord: thunderaxe31 <Masterjun> if you look at the "NES" in a weird angle, it actually clearly says "GBA"
Memory
She/Her
Site Admin, Skilled player (1514)
Joined: 3/20/2014
Posts: 1762
Location: Dumpster
I am against the idea of banning relying on uninitialized sram for the purposes of a glitch. In my eyes it is not different from relying on it for general gameplay. Additionally banning it because it might be inaccurate is an extremely weak argument in my eyes. Traditionally we have allowed such things in the past and I see no reason to differ here.
[16:36:31] <Mothrayas> I have to say this argument about robot drug usage is a lot more fun than whatever else we have been doing in the past two+ hours
[16:08:10] <BenLubar> a TAS is just the limit of a segmented speedrun as the segment length approaches zero
Post subject: Movie published
TASVideoAgent
They/Them
Moderator
Joined: 8/3/2004
Posts: 14772
Location: 127.0.0.1
This movie has been published. The posts before this message apply to the submission, and posts after this message apply to the published movie. ---- [4299] GBC Devil Island "save glitch" by ThunderAxe31 in 01:56.08