Zelda: Remastered (Mesen HD Pack)

[AdamDravian]

First off, this looks (mostly) amazing, and I respect all the time and effort it must've taken. Second, to explain that aforementioned "mostly" ... Well, it's the font. That font really detracts from an otherwise incredible presentation of Zelda.

[Aclectico]

I have the ROM with DAB79C84934F9AA5DB4E7DAD390E5D0C12443FA
Developmental build, too.
I put the Rom renamed at "Legend of Zelda, The (USA).nes" in the "rom" folder.
i use the patch with starting the "make.bat"
than if i start the rom with messen its only black map and link is Remastered if i go up. If i go left or right its showing the old link sprites.

There should be no need to execute a "make.bat" file. Are you trying to manually patch your ROM? If so, there is no need as the HD pack already comes with a bundled .ips file and Mesen should automatically take care of patching. If you have a clean ROM that matches the checksum, and you install using the installation steps in the README, you should be good to go.

First off, this looks (mostly) amazing, and I respect all the time and effort it must've taken. Second, to explain that aforementioned "mostly" ... Well, it's the font. That font really detracts from an otherwise incredible presentation of Zelda.

Thanks for the feedback. I'm considering changing it up a bit in a future rev level. I'll need to do some research on what would fit the following criteria:

-Easily readable
-Fits the aesthetic
-Adheres to the 8x8 (upscaled to 16x16) tile requirement without looking funny (this last one unfortunately rules out a Link to the Past style as that font has tall skinny letters that look strange with increased spacing between characters)

More to come.

[ShadowOne333]

@Aclectico did you manage to get the Automap tiles working for Remastered?
What is needed precisely for those? Just making proper 8x8 tiles for them instead of 4x4?

If you need the sole Automap tiles, you can get them from the Redux source here:
https://github.com/ShadowOne333/The-Legend-of-Zelda-Redux/blob/master/code/gfx/data_04.bin

That's the precise GFX data for the Automap tiles used in the map area, I made them into a separate GFX bin precisely for the sole reason of having everything related to Automap into a separate fully disassembled file (automap.asm + data_04.bin).

Let me know if it helped.

[sics]

Can you imagine if they had included a similar function in the NES Mini? Excellent work as always!

[julayla]

Amazing. I can't wait to try it out and play the game with a playable Zelda in there.

[mkwong98]

Amazing pack!

A few suggestions:
1. Change the caves in the caves in the overworld.png to transparent and you will be able to see Link walking down and up. Not sure how to handle hidden caves, may be adding another png with caves opened.

2. You can simplify fade to black with the brightness % option instead of having multiple images.

3. Consider adding wallpaper to the HUD and menu.

[Aclectico]

@Aclectico did you manage to get the Automap tiles working for Remastered?
What is needed precisely for those? Just making proper 8x8 tiles for them instead of 4x4?

If you need the sole Automap tiles, you can get them from the Redux source here:
https://github.com/ShadowOne333/The-Legend-of-Zelda-Redux/blob/master/code/gfx/data_04.bin

That's the precise GFX data for the Automap tiles used in the map area, I made them into a separate GFX bin precisely for the sole reason of having everything related to Automap into a separate fully disassembled file (automap.asm + data_04.bin).

Let me know if it helped.

Thanks ShadowOne333. Unfortunately, I was unable to get the Automap tiles working. It's a bit complicated to explain, so bear with me.

The first issue is that Mesen tile replacement is based in 8x8 squares while the automap seems to be based in 4x4 squares (this is the first time I have run into this problem). For example, when generating some graphic replacement content at the very first point in the Overworld, the following will result:



Associated code:
#Chr_3.png
<tile>3,000000000D00000F00000000020F0F00,0F173712,176,64,1,N,3255468369,75

If you then move North, the emulator will generate the following:



Associated code:
#Chr_6.png
<tile>6,0F00000D0D00000F000F0F02020F0F00,0F173712,176,64,1,N,3256560849,75

However, if you move West instead of moving North, Mesen generates a ".png" file and associated code that is unique from the first two. This wouldn't be a huge issue if the Overworld was limited to one 8x8 block as I could determine all of the possible combinations. However, since the Overworld is very large and all blocks have this issue, the normal process for graphic replacement did not seem realistic.

As an alternative, I know there is a setting in Mesen to allow for old graphics to show if there is no code designated for tile replacement. However, I suspect the aesthetic of mixing old and new graphics wouldn't really look ideal.

The second issue is related to the fact that a lot of the functionality of the pack relies on certain things being present in the HUD at certain times. For example, when entering and exiting Dungeons, I noticed that strange graphic glitches would sometimes occur. To understand why, I think it may help to know one of the conditions in Mesen that was used to know if a player was in a dungeon or not (KYA helped with development of this memory check):

<condition>InADungeon,memoryCheckConstant,10,>,0

Incidentally, the syntax for memory checks is as follows:
<condition>[name - text], [conditionType - text], [memory address - hex], [operator - string], [constant - hex], [mask - hex (optional)]

Using this, you would think it would be super simple to tell the game when to stop showing the Overworld background, correct? The natural thought is to simply instruct the game to stop showing the Overworld background whenever the memory address of "10" is greater than zero. However, in practice, this approach wasn't always perfect. Sometimes the Overworld would show at the title screen and sometimes strange locations of the Overworld would also show for a split second when entering a Dungeon. So, I developed another condition for the pack to use: I instructed the game to look for the Overworld grey box in the upper left hand corner of the screen with the following condition:

<condition>TitleGlitchFix1,tileAtPosition,16,24,0000000000000000FFFFFFFFFFFFFFFF,0F300012

It means that if the emulator finds a grey box at position "16,24" the condition is true. After adding this to the existing logic used to display the Overworld a lot of the glitches I was encountering seemed to be fixed. The only side effect seemed to be that the Overworld would instantly become black whenever pressing the start button to pull down the inventory screen (normal game behavior is to have the inventory screen slide down over the Overworld graphics). It seemed like an acceptable tradeoff to address all of the other glitches that I encountered.

I mention this because if the automap is implemented, one problem is that it will be dynamic by nature. As a result, there will be no longer be a reliable grey box to use as an "Overworld Check." There may be some other tile located somewhere on the screen that is unique to the Overworld. Or, there may be a more reliable memory check. However, I haven't been able to find it.

Amazing pack!

A few suggestions:
1. Change the caves in the caves in the overworld.png to transparent and you will be able to see Link walking down and up. Not sure how to handle hidden caves, may be adding another png with caves opened.

2. You can simplify fade to black with the brightness % option instead of having multiple images.

3. Consider adding wallpaper to the HUD and menu.

Thanks mkwong98!

1. I was hoping to keep the "walking up" and "walking down" in cave entrances functionality. However, as you noted, the hidden cave entrances were the problem. The default background shows hidden cave entrances as cracked walls. When the player reveals the cave, those cracks are covered up by a replacement graphic for an open cave (which is not transparent). One thought I had to address this issue was to have the open cave entrances on the very back layer and have that covered up by cracked wall graphics - basically, I would flip the order of how they are currently done. However, this turned out to be less desirable because there is a slight misalignment between interactable blocks and the large .ping file used for the Overworld whenever the screen scrolls up or down. I tried for a long time to get the alignment perfect, but it was always slightly off. For a lot of the details (like rocks that can be pushed and gravestones), it's not a huge deal. However, it's a little more of an issue when it comes to trying to cover up bombable cave entrances. A player can probably tell something is just a bit off in those areas and it makes the bombable cave entrances a little more obvious than they probably should be. In short, the lesser of two evils seemed to involve having the cracked walls on the very back layer (which excluded the possibility of showing Link walk up and down in cave entrances).

In addition, you may note that this problem only existed for some entrances. Why not retain the "walking up and down" functionality for some entrances? I decided consistency was best in the end.

Your idea of adding separate .png backgrounds for open caves vs. closed caves may be possible - However, there's one other issue I should probably mention. You may notice that Link only runs when you press a directional button. It's a little different from the functionality of the vanilla game. It's a long story, but this was a side effect of adding more frames to the running animation. Because of this, if the player isn't pressing a direction when Link is walking in and out of a cave, his idle stance would show instead. The end result would look like Link is magically levitating when coming in and out of a cave (unless a direction is being pressed). It may be possible to overcome all of these issues. But, the existing solution seemed acceptable for now.

2. The % brightness is actually used in some areas (like for Dungeon tiles depending on the room brightness). However, it is not used for the title screen. The reason is because the title screen fades to a shade of blue to indicate night time. Also, the % brightness feature is also not used for the stairway areas. This is because I couldn't get the functionality to work for quite some time. I'm not sure if it was just user error or an emulator bug, but after a couple of hours, I just decided to create a couple of separate stairway background images with varying degrees of brightness.

3. I actually gave this some thought and tried a couple of different mockups. However, they were never to my liking and I always kept coming back to the simple black. In addition, I put this one aside once I realized I didn't know of a good way to have the HUD and menu screen scroll properly over the gameplay graphics when pressing the pause button. I'm sure I could technically do it with a whole lot of "tileNearby" conditions. But, I was wary of adding even more conditions to a hires.txt file that was already quite large. If I figure out how to have the menu and hud properly scroll without dramatically increasing the size of the hires.txt file, I may consider this one. But, for now it is still on the back burner.

[KnaveMotif]

Very nice!  This has me excited for another playthrough or two.

Here is some feedback, from just a little annoying to probably not your problem:

1) Pressing Start - from the moment it starts scrolling until after pressing Start again and it stops scrolling:
     Overworld - World goes completely black including mini-map.  (Sprites (except map location) also disappear, but this part is in the original.)
     Dungeons - World does not go black, but mini-map does go black.  (Ditto about sprites.)
This is a little annoying because when in a dungeon, I like to compare the mini-map to the auto-map to see where I've missed.

2) Pressing Select - gets stuck on the note.  I had bombs, arrows (happened with & without bow), candle, & note.  A little annoying that I couldn't cycle past the note until I got the boomerang, which fixed the issue.

3) Cave mouths flicker strangely while scrolling.  This is mostly noticeable when scrolling horizontally, and barely noticeable except when cave is one that had to be revealed with a bomb, when the unrevealed image flickers as well.

4) FYI, Log Window shows 1 invalid option error, 1 error loading background & 32 condition not found errors.

5) Slightly tricky, maybe intentionally.

In the original where the terrain doesn't change, it's obvious you can go north here.

In HD, the sand at the top makes me think it's shoreline and you can't go north here.  If I'm headed to level 1 on auto-pilot, I end up at the fairy fountain.  I kinda like this little trick.

6) This one is probably not your problem.  When I first tried this patch, I got remastered graphics, but not everything was right.  Most noticeably, full & partial hearts showed terrain instead.  Turns out Mesen was applying hires.txt but not ZeldsHD.ips.  This was because my SHA-1 didn't match, and Mesen was ignoring your <supportedRom> tag on line 6.
The obvious and trivial solution was to reverse the SHA-1 hash, after which I discovered that my ROM, from 2001, had one extra bit set in the NES header compared to what you were expecting.  My ROM had mirroring set to 4-screen instead of horizontal.  (Mapper 1 uses dynamic mirroring, so this value is probably ignored by emulators.  (probably == I haven't noticed a problem on multiple emulators (without databases)))
Anyway, assuming you spelled <supportedRom> correctly, this isn't your problem.  Not sure why Mesen is using the NES header in the hash, but maybe there is a good reason.


*obvious and trivial == remembering my struggle with the Outlands patch where I had the correct hash value but the patch refused to apply anyway.  The NES header was not included in the documented hash value.  Google told me a different hash value that included the NES header, which didn't match.  Playing with this, I found I had the read-only attribute set, which was why the patch refused to apply.  Doh!

[mkwong98]

Your idea of adding separate .png backgrounds for open caves vs. closed caves may be possible - However, there's one other issue I should probably mention. You may notice that Link only runs when you press a directional button. It's a little different from the functionality of the vanilla game. It's a long story, but this was a side effect of adding more frames to the running animation. Because of this, if the player isn't pressing a direction when Link is walking in and out of a cave, his idle stance would show instead. The end result would look like Link is magically levitating when coming in and out of a cave (unless a direction is being pressed). It may be possible to overcome all of these issues. But, the existing solution seemed acceptable for now.

Ha ha, since Link's feet are not visible most of the time and he is bouncing slightly in his idle animation so I actually don't notice that until you tell me.

[Aclectico]

Very nice!  This has me excited for another playthrough or two.

Here is some feedback, from just a little annoying to probably not your problem:

1) Pressing Start - from the moment it starts scrolling until after pressing Start again and it stops scrolling:
     Overworld - World goes completely black including mini-map.  (Sprites (except map location) also disappear, but this part is in the original.)
     Dungeons - World does not go black, but mini-map does go black.  (Ditto about sprites.)
This is a little annoying because when in a dungeon, I like to compare the mini-map to the auto-map to see where I've missed.

This is a known issue but I am not quite sure how to solve. KYA came up with the logic for scrolling full screens in the Overworld. Using similar logic to have the map scroll down when pressing start may be possible, but I'm not sure how to implement.

In Dungeons, you may notice that the entire map graphics are covered by a picture layer ("Dungeon1AMap.png" is one example). The files act as a mask. This was done in dungeons for a couple of reasons - First, it was the easiest way to properly center and distance the "Level indicator text" above the maps. Also, it was the only way I could figure out how to center the indicator dots on the room boxes in the map properly. In the vanilla game, the indicator box is in the very upper left hand corner of the available 8x8 tile box. Since the indicator boxes in this pack are slightly larger than the small dot in the vanilla game, they appear to be off center. I moved each map "mask" .png file slightly over to compensate.

As a sidenote, you may also notice that the "Link" indicator icon is slightly off center (at the bottom, right of where it probably should be) in the automap dungeon map generated by the game when pressing start. I was unable to figure out how to address this issue (perhaps a .ips hack??)

2) Pressing Select - gets stuck on the note.  I had bombs, arrows (happened with & without bow), candle, & note.  A little annoying that I couldn't cycle past the note until I got the boomerang, which fixed the issue.

Sorry, I'm not sure if I understand this one. Are you saying the game wouldn't let you cycle past the flute until you got the boomerang item? If so, I never encountered that before. I wonder if the same thing happens in Zelda 1 Redux??

3) Cave mouths flicker strangely while scrolling.  This is mostly noticeable when scrolling horizontally, and barely noticeable except when cave is one that had to be revealed with a bomb, when the unrevealed image flickers as well.

This is also a known issue - I haven't figured out a fix that doesn't involve a lot of resources and I haven't exaclty figured out the reason for the flicker. But, I'm pretty sure it is a side effect of the method used to address hidden caves. The Overworld is made of one large .png file. When a player bombs a wall and reveals a hidden cave, a small graphic replacement tile is placed over that large .png file. This is all done with "tileNearby" commands. It may be possible to devise a different strategy that doesn't result in the same "flicker" side effects. Instead of replacing the cave mouth with a small graphic using a "tileNearby" command, it may be better to replace the entire background image of a given spot on the Overworld. However, this is likely to drastically increase the amount of conditions required since there are a lot of hidden cave entrances. As you may know, the pack is already quite large and I'm not sure the tradeoff would be worth it (not to mention the fact that this strategy would also probably be a lot of work).

4) FYI, Log Window shows 1 invalid option error, 1 error loading background & 32 condition not found errors.

Interesting - do you know how to find where those errors are located in the hires.txt file?

5) Slightly tricky, maybe intentionally.

In the original where the terrain doesn't change, it's obvious you can go north here.

In HD, the sand at the top makes me think it's shoreline and you can't go north here.  If I'm headed to level 1 on auto-pilot, I end up at the fairy fountain.  I kinda like this little trick.

It actually wasn't intentional, but I never thought about the fact that it may make scrolling up in this location feel more like a secret for people that haven't played the game before. I suppose I'll leave it unchanged for now.

6) This one is probably not your problem.  When I first tried this patch, I got remastered graphics, but not everything was right.  Most noticeably, full & partial hearts showed terrain instead.  Turns out Mesen was applying hires.txt but not ZeldsHD.ips.  This was because my SHA-1 didn't match, and Mesen was ignoring your <supportedRom> tag on line 6.
The obvious and trivial solution was to reverse the SHA-1 hash, after which I discovered that my ROM, from 2001, had one extra bit set in the NES header compared to what you were expecting.  My ROM had mirroring set to 4-screen instead of horizontal.  (Mapper 1 uses dynamic mirroring, so this value is probably ignored by emulators.  (probably == I haven't noticed a problem on multiple emulators (without databases)))
Anyway, assuming you spelled <supportedRom> correctly, this isn't your problem.  Not sure why Mesen is using the NES header in the hash, but maybe there is a good reason.


*obvious and trivial == remembering my struggle with the Outlands patch where I had the correct hash value but the patch refused to apply anyway.  The NES header was not included in the documented hash value.  Google told me a different hash value that included the NES header, which didn't match.  Playing with this, I found I had the read-only attribute set, which was why the patch refused to apply.  Doh!

Interesting - sounds like you may have figured out a fix on your end. Also, you are correct - I'm not sure I could speak to odd behavior from Mesen in this area. But, for those that may have similar hash issues - there are two locations in the hires.txt file where the hash value is shown. The first one is after "<supportedRom>" at the very top as you noted. The second is near the bottom of the file right after the text "#---------------Start of sound patch---------------#." If your checksum is slightly different, you could try changing both values to match what you have.

[jonathan29]

Hi, is it possible to play this on an android device?

[Jertigo]

Here is a block font I was developing for a different nes remaster. I scaled it up to 16x16 and cleaned up the edges. You are free to use it if you like. I think it fits the Zelda aesthetic pretty well.

[AirborneMuffins]

Is there a chance that this supports randomized roms?

[Aclectico]

Hi, is it possible to play this on an android device?

I have heard reports that Retroarch seems to be working for some people now. You could try, the Mesen core via Retroarch. But, you may still end up running into CPU performance issues where the device can't keep up.

Here is a block font I was developing for a different nes remaster. I scaled it up to 16x16 and cleaned up the edges. You are free to use it if you like. I think it fits the Zelda aesthetic pretty well.

That's not bad - thanks! I'll probably need to keep looking into this before making a final decision.

Is there a chance that this supports randomized roms?

I've never tried it - maybe. It would probably depend on what gets randomized. If item locations are changed, I would guess it may work fine. If something in the Overworld gets randomized, there is a chance something could get broken. To try it out, you'd probably need to randomize your ROM first, calculate the checksum, navigate to the two spots in the hires.txt file where the checksum is located, and replace the values with the randomized checksum value. Then, fire up as normal and see what happens.

[AirborneMuffins]

I have heard reports that Retroarch seems to be working for some people now. You could try, the Mesen core via Retroarch. But, you may still end up running into CPU performance issues where the device can't keep up.

That's not bad - thanks! I'll probably need to keep looking into this before making a final decision.

I've never tried it - maybe. It would probably depend on what gets randomized. If item locations are changed, I would guess it may work fine. If something in the Overworld gets randomized, there is a chance something could get broken. To try it out, you'd probably need to randomize your ROM first, calculate the checksum, navigate to the two spots in the hires.txt file where the checksum is located, and replace the values with the randomized checksum value. Then, fire up as normal and see what happens.

Just tried it and it appears to work with standard settings. Only issue seems to be that full heart sprites are being displayed as part of a cliff wall graphic.

[KnaveMotif]

This is a known issue but I am not quite sure how to solve. KYA came up with the logic for scrolling full screens in the Overworld. Using similar logic to have the map scroll down when pressing start may be possible, but I'm not sure how to implement.

What about hiding the map while scrolling (like it is now), but having the map reappear when scrolling is complete (only useful in dungeons)?

Sorry, I'm not sure if I understand this one. Are you saying the game wouldn't let you cycle past the flute until you got the boomerang item? If so, I never encountered that before. I wonder if the same thing happens in Zelda 1 Redux??

"flute"-->"note".  Then, yes, that's exactly what I'm saying.  note==what you need to buy potions

Interesting - do you know how to find where those errors are located in the hires.txt file?

Haven't tried.  Does Mesen's "Tools | Log Window" show the same thing on your PC?

Interesting - sounds like you may have figured out a fix on your end. Also, you are correct - I'm not sure I could speak to odd behavior from Mesen in this area. But, for those that may have similar hash issues - there are two locations in the hires.txt file where the hash value is shown. The first one is after "<supportedRom>" at the very top as you noted. The second is near the bottom of the file right after the text "#---------------Start of sound patch---------------#." If your checksum is slightly different, you could try changing both values to match what you have.

There is no such thing as "slightly different" with cryptographic hashes.  I was joking about reversing the hash.

October 16, 2020, 12:04:15 PM - (Auto Merged - Double Posts are not allowed before 7 days.)

Just tried it and it appears to work with standard settings. Only issue seems to be that full heart sprites are being displayed as part of a cliff wall graphic.

Sounds like you missed a step. See next 3 quotes:

6) This one is probably not your problem.  When I first tried this patch, I got remastered graphics, but not everything was right.  Most noticeably, full & partial hearts showed terrain instead.  Turns out Mesen was applying hires.txt but not ZeldsHD.ips.  This was because my SHA-1 didn't match, and Mesen was ignoring your <supportedRom> tag on line 6.

...for those that may have similar hash issues - there are two locations in the hires.txt file where the hash value is shown. The first one is after "<supportedRom>" at the very top as you noted. The second is near the bottom of the file right after the text "#---------------Start of sound patch---------------#." If your checksum is slightly different, you could try changing both values to match what you have.

... To try it out, you'd probably need to randomize your ROM first, calculate the checksum, navigate to the two spots in the hires.txt file where the checksum is located, and replace the values with the randomized checksum value. ...

[dachimiriani]

Hello, can I run this mod on the Nintendo Switch? Like, low CPU version or anything?

[Aclectico]

@KnaveMotif - I could give thought to the idea of having the map disappear then reappear after scrolling (although, most users would probably see it as a glitch). Also, as far as the item issue goes, I'm not sure what the cause may be. I'm not sure if it occurs in Zelda 1 Redux as well. If it does- I would probably need assistance with troubleshooting as well.

Also, I have received a couple of suggestions on the font issue and was interested to hear some general thoughts.

Screenshot from Jertigo:


Mockup using Sherwood Font (I am debating adding a subtle grey around the edges like Ironsword below to make the boundaries less harsh on this one): https://zeldauniverse.net/media/fonts/


Also, KYA suggested an interesting front from Ironsword here (keep in mind special characters and numbers are carryover from Sherwood and they would need to be slightly modified to better fit): http://www.zee-3.com/pickfordbros/archive/view.php?post=278

[Pleiades7]

@KnaveMotif - I could give thought to the idea of having the map disappear then reappear after scrolling (although, most users would probably see it as a glitch). Also, as far as the item issue goes, I'm not sure what the cause may be. I'm not sure if it occurs in Zelda 1 Redux as well. If it does- I would probably need assistance with troubleshooting as well.

Also, I have received a couple of suggestions on the font issue and was interested to hear some general thoughts.

Screenshot from Jertigo:


Mockup using Sherwood Font (I am debating adding a subtle grey around the edges like Ironsword below to make the boundaries less harsh on this one): https://zeldauniverse.net/media/fonts/


Also, KYA suggested an interesting front from Ironsword here (keep in mind special characters and numbers are carryover from Sherwood and they would need to be slightly modified to better fit): http://www.zee-3.com/pickfordbros/archive/view.php?post=278

The first one is clearly the best.

The problem with fancier fonts is that it goes against type. Seems like a good idea since the medieval fantasy component and "ye ole fonts" seem to go hand in hand. But in reality, it makes for a cheap cheesy looking product. I start to feel like I'm playing a Monty Python version of Zelda, and I'm sure you are not wanting that, amirite?

Fonts like the first one are cleaner and more neutral. It would be cool for a font even cleaner than that since it is a touch space aged. But the others really ruin the game.

In fact, the original Zelda font is just fine as it is. Maybe you can pass it through an xBRz filter to smooth the edges a bit. But If it ain't broke, don't fix it. Sometimes little touches go a long way and you don't want to telegraph that this is a hack too much. For me, when you play a hack, it is what you don't notice that makes these things work. A fancy font simply just doesn't ring natural and you want to make this as organic an experience for the user since you are already radically changing SO much. My 2cents.

[ShadowOne333]

@Aclectico, I see what the problem is now.

Let me ask, is it possible to have Mesen insert a new 8x8 tile if the base 8x8 tile in the game changes?
For example, if Link moves to a new area, and the 8x8 tile in Automap changes to add a new 4x4 one, could you code something in Mesen so the 8x8 tile that is currently in use gets updated to a new 8x8 tile that has the added map location? Basically replacing 8x8 tiles for each possible combination. I'm not sure if this can be done.

If not, then the only other option I can think of is making it so that whenever you walk into a new location in the Map, you uncover the whole 8x8 section of that area. It's a small countermeasure, but you could at least still implement it with new 8x8 tiles with that small con.