Legend of Zelda NES Tile Combos Q

[jojo_f]

Hi there,

I am altogether inexperienced at ROM hacking though have been enjoying the fruits of the community for many years! Since last century! Enough to familiarize with what may be necessary in creating one. Well I am finally trying my hand at making my own.

There is a lot of information available and I know it will take a lot of time to learn before implementing my coolest ideas, if that is even possible. If I am able to make something 10% as bitchin as infidelity's Legend of Link or Southbird's Mario 3 Mix, I would be very pleased with myself. Unfortunately I know I am going to have to suffer through my own impatience to see results.

So I am currently using ZeldaTech for altering Hyrule's overworld, and Dungeon Master to change the items around (no room changing yet). Thanks to snarfblam. If the results are ok I would integrate them into any future "dream hack."

Getting to the question. Viewing the available vertical tile combos within ZeldaTech, it appears MANY of them are repeated, usually in patterns of six but sometimes other numbers. What is the best way to alter these repeats so they are usable? (And please don't say there's a way in ZeldaTech or I will look very foolish.  )

Many thanks!

Edit
----
I think I have the answers I need from here.

http://www.computerarcheology.com/wiki/wiki/NES/Zelda

What a kind soul. Now to start delving. Feel free to wish me luck!

[Dr. Floppy]

Getting to the question. Viewing the available vertical tile combos within ZeldaTech, it appears MANY of them are repeated, usually in patterns of six but sometimes other numbers. What is the best way to alter these repeats so they are usable?

Yeah, the Overworld screen macros (16 x 176 pixel strips) are incredibly redundant. I'm unfamiliar with ZeldaTech; does it allow you to redesign the macros on a per-square (16x16) basis? Or just which sixteen macros are used to define each Screen?

Honestly, if you're motivated enough, my advice would be to ditch the Utilities and delve into the raw hex-code itself. Zelda 1 offers many opportunities for "jailbreaking" out of the original game's constraints. I struggled within those constraints for years before I just said fuckit & set things up so every row had its own 256 unique Macro definitions.

[jojo_f]

Thanks for your reply. ZeldaTech is a very clever program and very simple to use. Its layout editor lets you select any overworld screen and reassign "just" the sixteen macros. But like I said, after viewing them all, there are many repeats. If there were a way to edit the columns I would be very satisfied with my newcomer's project. But I suppose this is an opportunity to learn.

Honestly, if you're motivated enough, my advice would be to ditch the Utilities and delve into the raw hex-code itself. Zelda 1 offers many opportunities for "jailbreaking" out of the original game's constraints. I struggled within those constraints for years before I just said fuckit & set things up so every row had its own 256 unique Macro definitions.

This is something I could salivate over but would need some sort of GUI to work with if I didn't want to go crazy. If I am able to reassign just the redundant repeats manually I would be very happy with the possibilities and could probably do all the work with snarmblam's two programs, bar image editing.

Speaking of image editing, something that was bugging me today. I was trying some simple sprite replacements and using a few different graphics programs and noticed the tiles for Link's sprite don't line up, there is a horizontal strip one pixel high offsetting the graphics, that I suspect in itself is part of the graphics. Maybe this is something with my ROM.

[Dr. Floppy]

But like I said, after viewing them all, there are many repeats. If there were a way to edit the columns I would be very satisfied with my newcomer's project.

Yeah, if I remember right the OG only used about 125 of the 256 potential Macro definitions. If you can whip-up an image of your desired additions (as well as any replacements of Macros you don't need), I can see about adding them to the roster. (This shouldn't cause any problems with the Utility.)

Speaking of image editing, something that was bugging me today. I was trying some simple sprite replacements and using a few different graphics programs and noticed the tiles for Link's sprite don't line up, there is a horizontal strip one pixel high offsetting the graphics, that I suspect in itself is part of the graphics. Maybe this is something with my ROM.

Nah, it's something with every Zelda 1 ROM. Some NES games didn't contain special chips for separate image data, opting to instead flash it from the PRG-ROM itself (aka, "CHR-RAM"). That stuff-not-lining-up nonsense got old after about three seconds, so I converted the game to utilize CHR-ROM for my Zelda 1 hack.

[snarfblam]

I wrote a separate program to edit the vertical columns screens are made from (and was actually able to hand-compress them to significantly smaller than they originally were to make space for new columns) but somehow the program seemed to corrupt the ROM I was working with, so I shelved it.

I can share the executable and the source, but I made this over a decade ago, and my programming style was a little more... terrible back then. https://dl.dropboxusercontent.com/u/12027218/Temp/Combificator%20Incomplete.zip

Honestly, though, it would probably be easier and more flexible to re-point the data and edit it with a hex editor. There is a document floating around somewhere that documents the format of this data.

[Dr. Floppy]

Honestly, though, it would probably be easier and more flexible to re-point the data and edit it with a hex editor. There is a document floating around somewhere that documents the format of this data.

Yes! Particularly if one rerouted the data outside of the ultra-busy (and often chaotic) Bank 5.

The format uses bit-7 as the "Start of Next Macro" flag, even if the current Macro hasn't been entirely defined yet. This leads to overlap, which can be annoying to say the absolute least. Bit-6 is used as the "two-squares" flag, indicating that the Square # defined by bits 5-0 is to be added twice in succession. Thus,

Code Select Expand

C5-45-45-45-45-85-41-41-41-41

codes for two Macros, the first consisting entirely of water, and the second dry land with one square of water at the very top (assuming Square #05 is water and #01 is Land). Note how the final byte of the first Macro is the starting point of the second.

[jojo_f]

Thank you guys for sharing your knowledge!

snarfblam, I have done a limited test on your combomodifier with success! Keep in mind, this is perhaps as limited as possible but I will do more when I have free time, and see if and how screwed up it gets. Dr Floppy thank you for your offer to insert the combos. Though I need to take some baby steps into romhacking and I feel like that should be one of them. 


I would like to explore adding more water and bridges. There is only so much you can do with what is available, like a bridge only in the middle of the screen..

[Trax]

There are a few other details to consider about columns and columns groups. The Overworld Column Definitions data starts at 0x15BD8 (bank 5), 3C4 bytes in total. This is the structure of the data bytes:

..xx xxxx   Tile Code
.x.. ....   Tile is Repeated Once
x... ....   Start of a Column Definition

Each column is defined by 6 to B bytes. Set bit 6 to have the tile repeated once. Set bit 7 to set the start of a column definition. This means there's no specific pointer for each column, but only pointers for columns groups. Columns are separated into "groups", but in the original game, the groups never contain more than 9 or A columns, with maybe a few exceptions. The pointer table for Column Groups is in bank 6, at 19D0F. In this table, there are 0x10 pointers...

The apparent "overlap" of columns is not because of actual repeat of data, but because of how the pointers are selected in the tables. If you have, for example, column 24, the engine will not simply use column definition index 24. It actually selects column 4 from group 2, but because the tables that define the columns are placed one after another without interruption, you can use indexes that were not intended for the original game, and still obtain a legal column. But you could as well crash the game or display garbage...

Look at this screenshot from my Zelda editor, Sword I:

The columns on the right are separated by group. Some columns in a given group appear in the next. In the first group, the column with the cave entrance (column 09, 10th from the left) appears in the next group, as the first column...

I know there are not 0x10 columns per group, but I left it like that for future expansion. I tried to make my code behave as close as possible from the original code in the game. Because there is only A columns in group 0, column 0A (column A, group 0) is the same as column 10 (column 0, group 1). The pointer for group 0, + the index used (0A), overlaps the data of group 0 and falls into group 1, seamlessly. If the column data groups were scattered throughout the ROM, and not contiguous, this trick would never work, and you would likely get garbage if you used an illegal index...

Nevertheless, the engine is flexible in that regard. You can effectively use any of the 0x10 groups (the pointer table is already there), 0 to F, and use indexes 0 to F for each of them, which gives the full range of 00 to FF columns...

And to make things more complicated, dungeon columns have a different data structure:

.... .xxx   Tile Code
.... x...   ? (never used)
.xxx ....   Number of Times the Tile is Repeated
x... ....   Start of a Column Definition

This time, you can repeat tiles up to 7 times, but your choice of distinct tiles is restricted. The pointer table for Dungeon Column Definitions is in bank 5, at 16704, and only have A pointers. Rooms in dungeons only have C columns and each column is 7 tiles high. Interestingly, you could use bit 3 to double the number of distinct tiles that you can use, from 8 to 16, with minimal code modification.

And there's another exception: in dungeons, the passageways are screens that act like Overworld screens. They have 0x10 columns and the data structure is similar to the Overworld's.