@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.
Topic: Zelda: Remastered (Mesen HD Pack) (Read 64349 times)