adelikat
He/Him
Emulator Coder, Site Developer, Site Owner, Expert player (3587)
Joined: 11/3/2004
Posts: 4755
Location: Tennessee
WOW. I'm really excited to see what can be done with this glitch
It's hard to look this good. My TAS projects
Experienced player (948)
Joined: 9/18/2008
Posts: 154
Location: Japan
NESAtlas wrote:
Here is a new Deja Vu discovery. The Capsule Warp!
I took a look at this. It seems that the place ID ($0514) becomes 0xFF when you use the capsule on any untaken medicine. This is caused by the code $AEE1 (ROM:$1AEE1), and this probably intends to erase a medicine from the inventory. And, apparently the game sometimes executes a strange address (e.g. $3820) when you "OPEN" somewhere on this glitch (confirmed on Mesen). I haven't analyzed this game so thoroughly, but this glitch might have potential for further improvements.
Experienced player (948)
Joined: 9/18/2008
Posts: 154
Location: Japan
TaoTao wrote:
NESAtlas wrote:
Here is a new Deja Vu discovery. The Capsule Warp!
I took a look at this. It seems that the place ID ($0514) becomes 0xFF when you use the capsule on any untaken medicine. This is caused by the code $AEE1 (ROM:$1AEE1), and this probably intends to erase a medicine from the inventory. And, apparently the game sometimes executes a strange address (e.g. $3820) when you "OPEN" somewhere on this glitch (confirmed on Mesen). I haven't analyzed this game so thoroughly, but this glitch might have potential for further improvements.
When the place ID is 0xFF, the game reads out of bounds of some tables. for example: * The game reads a minimap portal list pointer 0x3247 from the table $06:9023. * The game reads a view rectangle list pointer 0x4001 from the table $02:9C00. But, reading from $3247- or $4001- is open bus access. So, I think it might be difficult to control this as you desire.
Skilled player (1832)
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
NESAtlas wrote:
Here is a new Deja Vu discovery. The Capsule Warp!
Sorry for the slightly late reply, but this is very interesting! I think (and hope!) that it can be used to save quite some time, and maybe understanding the glitch in detail opens up for additional timesaves. Hopefully someone takes it upon themselves to update the old storybook TASes :)
Joined: 3/24/2018
Posts: 1
A forum post was made on the speedrun leaderboards for this game asking about the capsule warp glitch, but I figured it would make more sense to post my findings here instead. Since the capsule warp was found, it had been used in RTA runs and it was found that one of the routes (specifically the one that warps directly into Auburn after setting up the glitch) did not work on original hardware, while it interestingly seemed to work even on flash carts such as the Everdrive N8 (I have not seen such a discrepancy between Everdrive N8 MMC3 mapper emulation and original hardware before). I decided to do some digging of my own then and found that the warp could still be done on an accurate emulator such as Mesen (and later confirmed to work on console) if the player warps to the restroom stall first, uses medrizine on self to die and respawn, and then warp to Auburn. This is now the current route used for RTA any%. I played around with the warp glitch and found that the more interesting area of discovery is not the mini-map, but rather the view port itself. Depending on where you click on the view port, the game will do nothing, throw a standard "you can't do that" or crash. But it turns out, if you click on very specific pixels, you can sometimes end up corrupting the color palette, overwrite items in the player inventory or even warp to specific locations. This setup can be done both in the doctor's office and in the room with the strapped chair, which I will refer to as the torture room. Given how early the torture room appears in the game, it also opens up for a lot of leniency when it comes to the room of error or potential readjustments that have to be done in order to make this glitch work in practice. The main selling point of this setup is that it overwrites a whole region of memory with 0x0F. This sets the whole player inventory to KEY4, sets a good bunch of the victory condition flags to 1 and also unfortunately, clears and opens inventories (such as desks and drawers) and destroys most (if not all) windows and mirrors. This is a problem because for example while you can setup the glitch and warp to the restroom stall, you can't get out of the restroom because Ace has to look into the mirror first but the mirror is broken! It also prevents the player from finding whatever items in storage necessary later on because the objects are effectively removed from the game, also preventing addresses to be learned. With that being said, some time when I played around with this I believe I managed to end up with some other item in the inventory where it wasn't just all KEY4. I have also been able to warp to a few locations, most notably the back alley with the fire exit ladder, but most of the time when that happens the game gets stuck in some kind of warp loop. The reason why this seems to happen is that the pointer to the table of interactable objects goes way out of bounds. The game has a table of pointers it uses to find where to load object data from, and that location is found from the current room index multiplied by two in said table. The game has 78 rooms (0-77), however, the capsule warp sets the room ID to 255 which is obviously way out of bounds so it loads a garbage value to use as the pointer. This pointer normally points to the first object in a room (like the coat hanging on the restroom stall door) that can be interacted with. Whenever the player uses an action on the view port, the game has to find what (if any) object the player clicked so it compares the position of the pointer with the hit box (4 bytes) of the objects and if there's a match, there are two additional bytes that tells the game what kind of object it is. The game will continue to scan for objects until it reaches a null terminator (0xFF). Of course, given that the game is reading somewhere it shouldn't be reading, it could basically go on reading random data forever until it reaches the null terminator. I believe this is why it takes so long for the game to register inputs while in the glitched state. So what is the game reading? When I looked at the disassembly, one such location seems to be the volume envelope for the triangle channel. Most of my successful attempts at setting up this part of the glitch have therefor likely been when the triangle channel is silent, although that may just be a coincidence. Here's an example of how the glitch is setup and some of the things that I've been able to do so far. Check out the time stamps for highlights as the rest of the video is just failed warp attempts. It only includes a few of the scenarios I've discovered so far: Link to video I do believe there is a golden opportunity to find a good early warp, item manipulation or even settings the flags for beating the game. On an unrelated note, this glitch can produce some completely bizarre and crazy effects so it's a bit fun to play around with.

1740259738