Various glitches in my nearly complete hack

asm unfortunately also has its limitations... I cannot just so change the palettes. The best I can come up with is this:



Unfortunately there's also a small bug left, when entering the room, the pegswitch shortly shows it's color before it finally gets grey. I sent you the patch per mail.

I played around with your podium idea, but items can't reach the pegswitch.

I know, possibly staircase would help even there is a space problem?

I once looked into the door problem and it is rather complex. I'd be happy if there is a HM solution. I'm not sure whether I am able to do anything here with asm...

Conn wrote:asm unfortunately also has its limitations... I cannot just so change the palettes.

If your referring to the embedded images of the submerged grey pegswitch; I wasn't suggesting a palette change.  The idea is that the pegswitch in those images is a background object, not a sprite.  So instead of a palette swap, the pegswitch sprite is removed entirely which would expose the background object that looks like a pegswitch.  Sorry I keep bringing this up.  I just want your opinion on whether or not it's a practical approach to the matter.

Conn wrote:Unfortunately there's also a small bug left, when entering the room, the pegswitch shortly shows it's color before it finally gets grey.

Is this a bug that can be fixed?

I played around with the patch you sent me, and it would appear (at least in my case) that the palette bug during room transits isn't the only issue.  The enemies in the room south of the push switch room are invisible (except for their shadows).  The bari/miri is visible while electrified, and the red bari/miri is visible after you split it in 2.  Moreover, the Stalfos in the room with the push switch are visible, but the bones they throw are not.  

Did the same bugs occur with the other palettes?  Because I'm willing to settle for the blue palette in the first image for both blue and orange pegswitches:

Btw, do the other palettes make the pegswitch appear below the water?  I ask because the image of the four different palettes is watered down which makes it hard to tell, and because the grey palette was on top of the water.

Conn wrote:I once looked into the door problem and it is rather complex. I'd be happy if there is a HM solution. I'm not sure whether I am able to do anything here with asm...

I understand.  We'll leave that one be then.   I really don't think there is a solution in Hyrule Magic.

yes, it was strange with the palette. The first time I tried I got those pics in the 4 pics posted. The second time I got different colors, like a green pegswitch. Since the palette doesn't appear to be stable I needed to make it grey then.

I think I can disable the peg sprite with a bug fix of the monsters (the sprite appearing during transition is not fixable - I need to make various checks, and these checks are done after transition - nothing I can do due to the ingame architecture), but am not sure about the bg tile.
Are you able to make it and place it below the original? SePH and Puzz do such tile editing all the time, but I never worked with HM.

The problem is, while I'm sure I can squeeze it in somewhere with yy-chr, I'm not sure I can insert it into the room unless there are unused objects. I have to be able to select them from the "Choose an Object" menu. I'm going to try though. I'm currently numbering tiles in yy-chr that appear to be unused to see if any show up in the game, and in the "Choose an Object" menu. If any tiles don't show up in the game, but they do show up in that menu; then I might be able to use them.

mh, in the end it is only a optical bug... hm editing with staircase/podest is not an option for you?

I can try to fit in a new bg tile, but the effort will be enormous. It will be a vram transfer with much tracing required where to store it, place it on the correct place, choose the correct palette and so on. Dunno whether the effort outweighs the benefit here, as there will also be the transition bug. HM would in any case be the easiest and cleanest solution :-/

Conn wrote:mh, in the end it is only a optical bug... hm editing with staircase/podest is not an option for you?

I can try to fit in a new bg tile, but the effort will be enormous. It will be a vram transfer with much tracing required where to store it, place it on the correct place, choose the correct palette and so on. Dunno whether the effort outweighs the benefit here, as there will also be the transition bug. HM would in any case be the easiest and cleanest solution :-/

If there's a way to make it look like the mockup below, and a way to make the column penetrable, then I'm all for it.  I sort of like the way this looks:


Unfortunately, this is how it actually looks:


Keep in mind, this is in my test rom.  Link won't have access to the pegswitch from where he's standing.  The boomerang or arrows would have to pass over the column in order to hit the pegswitch.

Would this be easier to accomplish?  And could it be done in a way where the properties of the column would only be changed in these two rooms?

That's all quite difficult... what I rather meant: would this hm solution be possible?



The chest surely must be moved then, but that's easy I think

That approach would defeat the purpose of what I'm trying to do with this hack  (I would have to send you a pm/email in order to tell you what that purpose is without revealing more than I want to about the hack before releasing it).  Moreover, I'd have to remove the water from the room entirely because adding water tiles that aren't within range of the "Turn on Water" header tag crashes the game.  I could probably switch the "Turn on Water" header tag to "Turn off Water," but that would require even more changes.

Anyway, this was a problem that I only wanted to address if there was and easy fix with asm.  Since there isn't one, I'd rather just leave it be.  Sorry if you put an unnecessary amount of time into this.  The last thing I want to do is inconvenience anyone.

On a positive note, I will be giving you credit for fixing the scroll and watergate bugs.  Two bugs that have annoyed me for a decade, lol.  And now I finally know how to fix them.

Thanks for the help.

Alright, I sent you a v2 which makes the pegswitch simply disappear in both screens needed. I hope it is of use and bugfree
Guess this is the best I can offer here.

I was able to help Jeimuzu out with most bugs (except those shutter doors), we corresponded via mail. While I was suggesting him to use fastrom due to the sheer amount of sprites causing massive slowdowns, he noticed some bugs due to rom expansion of Wiiq's original hack. When you applied this patch on a rom with data beyond 1 MB this was overwritten.
So I uploaded a new version of the fastrom patch which does not expand the rom, and I also merged all the bugfixes I made:
https://www.zeldix.net/t672-alttp-fastrom
Anybody running a project is advised to apply this patch to prevent slowdowns.

Also I noticed when looking into Jeimuzu's rom that the ingame header byte which shows the total rom size to the hardware system is not set properly. LunarExpand sets this byte automatically correct, maybe some of you expand the rom by hand or HM does it. Though most emulator can handle any rom addressing without having the byte set correctly, I strongly recommend to set it right (might be an issue for RH systems, like sd2snes):
The address you need to adjust is pc 00/7FD7
The correct values in dependence of rom size:
1 MB: 0A
1.5 -2.5 MB: 0B
3 - 4 MB: 0C

Reference:
http://www.smwiki.net/wiki/Internal_ROM_Header#ROM_Size
(MBit to MB calculation necessary)

So I recently finished another play through of my hack when I discovered a graphical glitch in the credits.  

This is how it looked starting with backup 1:


And how it's looked ever since:


After doing some digging, I've concluded that this bug first appeared in my very first backup.  The only thing I did for this backup was import the updated graphics using zcompress.  In other words, before my initial Hyrule Magic save.  However, my initial save in Hyrule Magic (backup 2) did make it worse.  In backup 2 I inserted my title screen changes.  I have since made a total of 28 backups, and not a single one has made it worse.  So importing the graphics caused the issue, and perhaps editing the title screen aggravated it, lol.

I was hoping to get an idea of what vicinity of the rom to look in.  I'm hoping this bug is nowhere near the title screen.

Jeimuzu wrote:So I recently finished another play through of my hack when I discovered a graphical glitch in the credits.  

After doing some digging, I've concluded that this bug first appeared in my very first backup.  The only thing I did for this backup was import the updated graphics using zcompress.  In other words, before my initial Hyrule Magic save.  However, my initial save in Hyrule Magic (backup 2) did make it worse.  In backup 2 I inserted my title screen changes.  I have since made a total of 28 backups, and not a single one has made it worse.  So importing the graphics caused the issue, and perhaps editing the title screen aggravated it, lol.

I was hoping to get an idea of what vicinity of the rom to look in.  I'm hoping this bug is nowhere near the title screen.

These kind of bugs appear because of the gfx changes to the game. Ironically it usually has to do with the title screen, but the gfx part rather than the code part. Sometimes it is even impossible to completely get rid of them, while having new gfx intact. Your bug is in the gfx area from hex address 87000 to around C0000. If the bug is indeed here it is easy to find with my hex-method of partial copy pasting original code into the hack, since no change of gfx will crash the game.

When you fix it, every press of the save in Hyrule Magic will bug it again (ironic isn't it), so you need to make the hex fix appon every HM save (or just fix it at the end).

Okay, I managed to narrow it down to two bytes within line 8A0A0.  When I restore these bytes, the bug is fixed, but two title screen tiles are corrupted.  I'm a little concerned that this might be one of those situations where I can't fix the issue at hand without breaking something else.

I changed the following bytes back to their original settings:
00/8A0A7: F7 > 7F
00/8A0AF: 00 > CF

And these are the two tiles that the edits corrupt:


Assuming this can be fixed, is there a quicker way to find the appropriate byte settings?  Let me know if you need to see the changes I've made.  I'd rather not post that here just yet.

If it is only corrupting your GFX, wouldn't it be easiest to keep a backup of your bin file and just reinsert uncorrputed GFX with Zcompress when needed? Or am I missing something here?

I'm pretty sure the only thing that needs to stay untouched in that tileset is the trademark ''TM''!



If you even add like only one pixel to the TM, you'll get bugs!

Okay, I managed to narrow it down to two bytes within line 8A0A0. When I restore these bytes, the bug is fixed, but two title screen tiles are corrupted. I'm a little concerned that this might be one of those situations where I can't fix the issue at hand without breaking something else.

I've seen this before. And we couldn't fix it before. Once one thing was fixed, the title screen was affected. Seems like your current gfx will not allow, what you did to the title screen - and the most logical reason would be, that the game ran out of space (because of what you did to the title screen - I'm not sure what you changed though).

I was able to fix the issue by restoring those two tiles, and editing the following two tiles from the "Kamigami no Triforce" graphic instead:


I imported the updated bin into an unhacked ROM to verify that it would work.  Then I just copied those changes into a recent backup via HxD.  I suspect that the code just didn't appreciate the addition of transparency in those two particular tiles.

Anyway, thanks for the help Puzzledude.  I wouldn't have discovered the cause of this issue without your assistance.

SunGodPortal wrote:If it is only corrupting your GFX, wouldn't it be easiest to keep a backup of your bin file and just reinsert uncorrputed GFX with Zcompress when needed? Or am I missing something here?

I tried your suggestion to help narrow down the culprit.  It didn't fix the issue, but you're the reason I got the idea of restoring those first two tiles, and inserting them back into the game.  So thank you.