Nice to see all the progress being made.
And thanks for considering my reports.
However... I do have a few more!
Finite Rupee Update: [Demo Quest]
All the fixes to the infinite wallet work great, and I can't find any more ways to break it.
However, it seems the fixes created a new problem with the start finite rupee counter: buying items in shops doesn't deduct rupees. You still need to have the minimum amount of rupees necessary to purchase the item in the first place, but once you purchase it, your rupees don't drain.
Everything else works: info shops, door repairs, gambling, more bombs/arrows, leave life or money... just not standard shops.
This demo is merely a quick update to the one I made for the infinite wallet. You can try the 6 different payment rooms. Go to the respawning enemy area at the right to get 10 rupees per enemy. You start without a wallet, but you can pick up wallet 1 (500 rupees) on the second screen up to see that it doesn't make a difference.
Water Damage Jig: [Demo Quest]
When swimming in water, Link remains in the water when hit by enemy fire. Alternatively, when he damages himself, he pops up as if he were on solid ground. Then, when he finally moves, he sinks back into the water.
However, if Link is on a shoreline (1 combo away from solid ground) when he damages himself, and if, after popping up to solid-ground level, he walks onto actual solid ground (including shallow water), the player loses control of him while he does a funky jig across the entire screen in the direction that he exited the water. In the process, he'll become invincible and pass through any object on the screen - even solid combos. The player only regains control of him when he re-enters water, and therein lies a game-breaking problem - if there's no water, Link will pass through every combo on the screen, even solid walls, until he exits that screen and enters the next screen. And if there is no "next screen," then he'll either appear outside the DMap, or get stuck running into the edge of the screen if it's on the edge of the actual 8x16 map.
This demo gives you each possibility by way of the red candle. I suggest working your way from the bottom to the top of the right-side shore first. Stand at the edge, fire the candle into the water, walk into the water, take the hit, rise up to ground level, then walk left back onto the land. The lowest row will show you Link walking across open land and back into water, the middle row will show you Link walking through a solid combo and back into water, and the upper row will show you Link walking through a solid combo and off the screen entirely. Likewise, you can try it vertically as well.
This bug works with both small and large Link hit boxes. However, due to the small hit box making it very hard to replicate the problem vertically, I've enabled the large hit box so you can align Link with north and south shores as easily as the east and west shores.
In 2.50.2, if Link exited to the next screen and landed in deep water, the player would regain control of him. Alternatively, if Link exited to the next screen and remained on solid ground, the player would completely lose control of him. In 2.53.0 versions, the player retains control of Link, and can try walking back to the prior screen. Of course, if there's a solid structure more than 1 combo thick, Link won't be able to return to the playable area, and may possibly be stuck outside the level.
Intriguingly, this only happens with 8-way movement enabled. Standard 4-way movement prevents him from popping up to solid-ground level in the first place. I suspect it has to do with the way he gets temporarily stuck on shorelines when entering and exiting water with 8-way movement enabled. 4-way movement doesn't have this problem.
And honestly, this lag on entering/exiting water with 8-way movement should probably be "fixed" anyway. I don't know why it's different, and I've only ever heard people complain about the hang-up.
NES Dungeon Locked Door Sensitivity: [Demo Quest]
This is a rather small inconsistency that might even be considered negligible, but I'll bring it up anyway, just in case.
WIth 8-way movement enabled, locked/boss-locked doors in NES dungeon screens won't open if Link moves toward them while facing the upper wall. To try it, walk upward into the dungeon walls on either side of the door, then press left or right to slide by it. Furthermore, stop in front of the door while still walking upward. It won't open. However, if you let go of the up arrow, then press it again, it will open - and without Link changing position. By contrast, if you walk upward into a wall or barrier on either side of a lock-block/boss-block, then press left or right to slide by it, it will open - immediately. This is consistent with small Link hit box, large Link hit box, and the Freeform Dungeon quest rule enabled or disabled.
Again, tiny issue, but it could possibly confuse newer players into thinking their key doesn't work on that particular door, so if there were a way to give the doors the same sensitivity as the lock blocks, it might be helpful to a few people.
Obviously, this isn't a problem with 4-way movement, as Link can't slide sideways.
Image Output Corruption:
I had mentioned PNG corruption. ZoriaRPG had mentioned he was working on the PNG problem. Turns out we were talking about 2 different things: he was dealing with importing tiles to ZQuest, and I was talking about screenshots and exporting tiles. So here's what I should have clarified and reported earlier:
Image output from ZC and ZQ is corrupt. This applies to ZC screenshots (F12), ZQ screenshots (Z), ZQ tilesheet exports, and ZQ "Save to File (Mapmaker)" exports of full maps. These worked in 2.50.3 RC1, but became broken as of 2.53.0 B2, and have remained broken since then (I haven't tested B1, as it was replaced so quickly, so it may have started then).
I confirmed this using all 6 image formats in each version of ZC, and each format in each version produced the same result. I only used PNG output in ZQ, as I figured the source of the problem was the same for each program, and further image format tests would be redundant. Every image from each program failed to open in both Irfanview and Photoshop.
In one instance, the screenshots did work. It was while playing Vaporvania, from the Metroidvania contest. It worked once, in B4, and as many times as I've loaded and reloaded the quest, and taken screenshots on the same screens, I've never gotten it to work again, even using the first savegame, so I'm writing it off as an unreplicable freak incident.
Regardless, I don't believe this is a matter of writing a correct image to a wrong format, as Irfanview catches incorrect image extensions and offers to rename them accordingly. Rather, they seem to be incomplete outputs in some way. These are the error messages I received from each program:
Irfanview error (all formats): [image filename] : Can't read file header ! Unknown file format, empty/damaged file or file not found !
Photoshop error (all formats except JPG): Could not complete your request because the file-format module cannot parse the file.
Photoshop error (JPG format): Could not complete your request because a JPEG marker segment length is too short (the file may be truncated or incomplete).
So, it looks like some integral parts of the files aren't being written. Hopefully there's a clue in those error messages.
I believe 2.53.0 B1/B2 was when you switched to Allegro 4.4, was it not? So perhaps it has to do with the Allegro update?