Exporting rooms into another ROM

I've asked about this in the past in other threads, but since some time has passed and the need I have for it is even greater now I figured id give it another shot.
Is there any way to copy and paste or export/import rooms from one ROM to another without it then not being compatible with HM?
I keep running into bugs that I can only assume were created by me having used many different tools on my ROM as I was learning how to hack. since then I have done a lot of work including about 40% of all of the outside areas which, I know I can copy over to another ROM with HM. However, I have also built an entire dungeon as well and I would like to not have to re-do it all even though it is just one dungeon.
I guess if push comes to shove I can always just  re-make the dungeon but I'd really rather not

@zarby89
I did notice that there is an "export as binary" and an "export all rooms" button in ZScream but not an import button, is there some way I can use that?

I am also aware of the RT (room transfer tool) but as I asked on that thread, you cant use HM on it afterwards so that doesn't help me much..

Sorry if this seems like a repeat of other questions but thanks in advance for any help.

Is there any way to copy and paste or export/import rooms from one ROM to another without it then not being compatible with HM?

I am also aware of the RT (room transfer tool) but as I asked on that thread, you cant use HM on it afterwards so that doesn't help me much..

Well, yes and no.

The answer "no" explanation:
First of all, you should know, how this works. Being compatible with HM means the data is "packed tight". So what you want is to copy "packed" data and then paste into existing "packed" data. As you can see, this will not work. And (tightly) packed data is what is causing the bugs in the first place.

The regular process is this:
use RT to change packed data into "non packed" (ie on the end of rom, ie easily accesible and easy to find and easy to copy paste). Then use another rom with non packed structure and precalculated non-changing pointers and paste it here). Now the rom is completely free of bugs, mainly because HM will not change *all* pointers if you remove one element from one room.

If you now want compatibility with HM, you should repack it though, which is not happening, since your rooms can have more data than the original rom (and they will).

The above is what I call the hex gluing method, but it has a lot of side effects. Not just indoor objects, but also sprites, items, header etc etc must be transfered the same way. So these are 7 things to move. And the user Jeimuzu found more side effect, which I also solved additionally: entire second grid of pointers must be pointer to bg3 (the second time) to load complex doors on room transit and the sprite respawning code as well, otherwise the moved indoor sprites do not respawn correctly on moved data.
--------------


The answer "yes" explanation:
You could in theory move the entire indoor data (for objects only!) from one rom to another: and thus from the "packed state" to another "packed state". This will be compatible with HM, but the same "overpacking" might occur. And if overpacking is the reson for bugs, than this will not help.
--------------



You have 2 options:
The basic one is to start with a new rom (not bugged) and first manually remove obejcts from at least 20 used HM rooms (ie make them empty). Now use rom backups: rom is copy pasted to a new version every 24 hours or before any big change is made. And only then start editing dungeons. This should not bug out.

The advanced option is the hex gluing method. This one is highly hex based, but will in the end allow you to have all 320 rooms, "unlimited" sprites, "unlimited" indoor object data (at least limited to what the CPU/emulator can handle), "unlimited" items (ie under jars), maximum room header options, ie transits (since with HM you are highly limited here and some rooms even reused) etc etc.

While viewing the rom you can clearly see, how the original authors wanted to "pack" data into 1MB. For instance with hacks, you of course need full header, ie at least to be able to have 2 staircase transits for all rooms, the original game uses a lot less here, which will eventually lead to "no room for room header" message, ie stuffed/bugged room header data. Although the HM (New) version allows for this one thing to be debugged transfered with a command "move headers".

I keep running into bugs that I can only assume were created by me having used many different tools on my ROM as I was learning how to hack.
since then I have done a lot of work including about 40% of all of the outside areas which, I know I can copy over to another ROM with HM. However, I have also built an entire dungeon as well and I would like to not have to re-do it all even though it is just one dungeon.

Your bugs are a result of rom being filled too much. You should manually remove indoor object from at least 20 used rooms and then work from here, thus removing one dungeon from the game.

Oh wow, thank you for the very detailed response. I just want to make sure I understand some things:

Puzzledude wrote:Your bugs are a result of rom being filled too much. You should manually remove indoor object from at least 20 used rooms and then work from here, thus removing one dungeon from the game.

by "indoor objects" you mean everything in the dungeon ie. walls, doors, items, sprites, floors, etc. correct? and does that include the headers?

Puzzledude wrote:Not just indoor objects, but also sprites, items, header etc etc must be transfered the same way. So these are 7 things to move.

Does RT move these as well, or would I have to go digging for this data as well and move it manually?

Puzzledude wrote: Now use rom backups: rom is copy pasted to a new version every 24 hours or before any big change is made. And only then start editing dungeons.

I actually have been doing this, almost since I started. I have about 25 backups all made at various times in development. the problem is I didn't find a lot of the bugs until recently after I had done a lot of work in the overworld and the dungeon.

Puzzledude wrote:The advanced option is the hex gluing method. This one is highly hex based, but will in the end allow you to have all 320 rooms, "unlimited" sprites, "unlimited" indoor object data (at least limited to what the CPU/emulator can handle), "unlimited" items (ie under jars), maximum room header options, ie transits (since with HM you are highly limited here and some rooms even reused) etc etc.

so based on your experience, did you ever "need" to do this in a hack to make more space? or were you always able to make cool dungeons within the limitations of the packed data?

Puzzledude wrote:Your bugs are a result of rom being filled too much. You should manually remove indoor object from at least 20 used rooms and then work from here, thus removing one dungeon from the game.

Well, I don't think the bugs are just from the dungeon editing, but it's possible I guess. Some of the bugs I'm experiencing are:

whatever this is...


the number 1 flue location is in a different dimension...


and so are these sprites? i have no idea.


plus there's a bunch of other little stuff I notice once and a while but anyway, such as while talking with zarby89 we discovered that there seems to be items and sprites that are out of buonds? and that makes it so i can even open the rom with zscream. also I've noticed sprites appeared in random spots all over the map except in the spots where i already actually place my own sprites.

There's no definitive point on a timeline of backups where I noticed theses errors, so I don't know if they were caused by dungeon editing or not, maybe you can tell me.

and some end thoughts:
so it seems to me the "Hex gluing" method is the "high-risk high reward" scenario here, it involves a lot of work, might not work and still might cause other bugs. but also will allow you to use more rooms, objects, headers, etc.

or the "safer" option is just to make sure I never go over the limit of objects and start from a new ROM, and remake the dungeon.

Does that sound right? thanks.

>>Your bugs are a result of rom being filled too much. You should manually remove indoor object from at least 20 used rooms and then work from here, thus removing one dungeon from the game.<<

by "indoor objects" you mean everything in the dungeon ie. walls, doors, items, sprites, floors, etc. correct? and does that include the headers?

By indoor objects I meant only the objects on bg1, bg2 and bg3 and no sprites, items etc.

>>Not just indoor objects, but also sprites, items, header etc etc must be transfered the same way. So these are 7 things to move.<<

Does RT move these as well, or would I have to go digging for this data as well and move it manually?

The RT moves all indoor data. Once you run the rom through the program, you can then open the rom with hex editor and search for txt room 1 and on the end of the rom everything is structured in a way, so that it is easy to find (and thus copy paste).

>>The advanced option is the hex gluing method. This one is highly hex based, but will in the end allow you to have all 320 rooms, "unlimited" sprites, "unlimited" indoor object data (at least limited to what the CPU/emulator can handle), "unlimited" items (ie under jars), maximum room header options, ie transits (since with HM you are highly limited here and some rooms even reused) etc etc.<<

so based on your experience, did you ever "need" to do this in a hack to make more space? or were you always able to make cool dungeons within the limitations of the packed data?

So far I always made it within limitations to avoid complexity (ie when you move data, a lot of side effects need to be fixed). But of course within limitations basically means you actually need to at least remove one dungeon from the rom. Like I did in Goddess of Wisdom hack. I went for intro dungeon and 7 crystal dungeons (somewhat bigger than "regular" dungeons) to fill the indoor rooms just to a correct point, which is around 20 less of what ALTTP is using. Parallel Worlds hack exceeds ALTTP for instance.

Main problem is, you will not be able to fill them exactly the way Nintendo did. This is why some rooms of the Turtle rock dungeon are practically empty and also the Pyramid site has like 3 or 4 sprites and the Death Mountain in dark world left area, has 2 sprites only (this is due to sprite limitation).

>>Your bugs are a result of rom being filled too much. You should manually remove indoor objects from at least 20 used rooms and then work from here, thus removing one dungeon from the game.<<

Well, I don't think the bugs are just from the dungeon editing, but it's possible I guess. Some of the bugs I'm experiencing are:
whatever this is...
picture of smoke comming out of the house
the number 1 flue location is in a different dimension...
and so are these sprites? i have no idea.

Thses are common bugs, as a result of multiple editing, stuffed data and HM being a buggy program and not be able to handle this tightly packed data. Unfortunately all of the above means you need to delete this rom, specially those with sprite location faults. What you see basically means you reached the sprite limit and sprites are "off screen", which can crush the rom while playing. You will eventually see the same "odd dots" as red instead of purple, ie bugged items instead of sprites. Similar with whirlpools. I for instance don't use whirlpools or overworlds items at all, since once bugged there is no way to "remove them".

such as while talking with zarby89 we discovered that there seems to be items and sprites that are out of buonds? and that makes it so i can even open the rom with zscream. also I've noticed sprites appeared in random spots all over the map except in the spots where i already actually place my own sprites.

Indeed. The problem is you have 3 overworld modes: beginning, first part (collecting pendants) and second part (collecting crystals). Plus you have light world/dark world. Nintendo made it so, that some of that is actually shared, ie you never get to dark world on part one (since you collect crystals), but first part of dark world actually has shared sprites with beginning of light world. This can mess things up for Hyrule Magic, plus sprite limit overflow can happen. The result is what you see. That kind of rom is suitable for deletion, since you can never get rid of these "off screen" sprites. They are not really off screen, the sprite code has been permanently damaged (usually due to too much data, so the data is falsly written to other hex areas).

There's no definitive point on a timeline of backups where I noticed theses errors, so I don't know if they were caused by dungeon editing or not, maybe you can tell me.

These bugs are a result of editing in general and HM not being able to handle the amount of tightly packed data, so overflows happen, which basically means "general corruption". So basically you have too much data as opposed to what the rom or HM could handle. Also note: certain bugs are just a result of bad programing of the HM, and not data overflow, such as the camera fault when Ganon or Armos pound the ground as a result of you editing monologues, since monologue values are written into the next bank and first 2 bytes there are camera shake values).

and some end thoughts:
so it seems to me the "Hex gluing" method is the "high-risk high reward" scenario here, it involves a lot of work, might not work and still might cause other bugs. but also will allow you to use more rooms, objects, headers, etc.

It's actually the oposite. Hex gluing refers only to indoor editing and is actually low risk, since a rom with this structure is highly "debugged". Main problem here is the manual work and complexity. It also was never fully tested. All the "side effects" actually mean some code was not transfered, when it should be transfered, but this involves only secondary things, like sprite respawn code and doors on transit. These are not main codes/data, so essentially this would be viewed as minor problems when playing. Yet you can also solve all those secondary problems once they are found, by tracing the code and then simply transfering it to the expanded banks as well. But still in general this is not recomended, it is more like advanced hacker's method.

or the "safer" option is just to make sure I never go over the limit of objects and start from a new ROM, and remake the dungeon. Does that sound right? thanks.

This method is standard and not really safer, since HM can easily destroy the rom for reasons unknown, but definitely this method is so much simpler and faster than the other, that it has priority. You essentially need an editor to edit games. Doing it manually in hex is somewhat of a problem.



So you need to decide based on situation:
-for instance Goddess of Wisdom hack: here I decided to edit all overworlds first and then seen that the rom is stable enough to be able to edit all indoors with backups and also make hex debuggs along the way, as well as "safe edits" where possible (there are also around 20 more empty rooms, compared to ALTTP)
-for Gates of Time hack I decided to make all overworlds and caves and houses + gfx + asm in primary rom and all dungeons in separate roms, one rom per one dungeon and then paste the dungeons into the main rom (here dungeon exceed the limits of original game and are "highly debugged" - ie the code has all the space it needs plus more, as opposed to tightly packed ALTTP dungeon code)
-editing Parallel Worlds also means constructing dungeons in separate roms and gluing them into the main rom, since the rom is incompatible with HM due to special coding by Euclid to manage the indoor limit, which he encountered in Parallel Tower (ie HM gave him the "out of data" message) - he used a custom java script to do the "hex gluing" for him, but this is only for PW
-casual roms, such as remodels or master quests: also needs standard editing

You can also go for the occasional "safe indoor editing", which basically means you never remove or add any objects or sprites etc, you only use existing ones and keep their numbers, you just change their type, position etc etc. I did this a lot in final stages of Goddess of Wisdom hack, where the rom had a lot of data, so I only moved things around never using "add" or "remove", so the hex block was intact, HM thus changed only the byte values and didn't do any data shifts.

My recomendation is that you nevertheless go for the standard method of editing on a clean rom, removing some indoor objects, ie bg objects as well as some sprites and chests to gain some space. Then work on overworlds only, since this tends to not bug, but of course no overworld items or whirlpools, no global grid changes etc. Next you insert new gfx and also asm codes. Then you go to houses and caves, dungeons are last. And even with this standard method, you will probably need occasional hex debugs, as well as an ASM person to be able to trace some never before seen bugs, to be able to fix them (of course this is valid for smaller corruption only).

Puzzledude wrote:So far I always made it within limitations to avoid complexity (ie when you move data, a lot of side effects need to be fixed). But of course within limitations basically means you actually need to at least remove one dungeon from the rom. Like I did in Goddess of Wisdom hack. I went for intro dungeon and 7 crystal dungeons (somewhat bigger than "regular" dungeons) to fill the indoor rooms just to a correct point, which is around 20 less of what ALTTP is using. Parallel Worlds hack exceeds ALTTP for instance.

Are the rooms that are not used in ALTTP ie rooms that are empty by default such as room 45, 71, 72, etc. included in that 20, or do I need remove 20 ish rooms that are used by ALTTP and that have objects in them?

Puzzledude wrote:Main problem is, you will not be able to fill them exactly the way Nintendo did. This is why some rooms of the Turtle rock dungeon are practically empty and also the Pyramid site has like 3 or 4 sprites and the Death Mountain in dark world left area, has 2 sprites only (this is due to sprite limitation).

huh that's really interesting, I never noticed that about ALTTP before but it totally makes sense.

Puzzledude wrote:Thses are common bugs, as a result of multiple editing, stuffed data and HM being a buggy program and not be able to handle this tightly packed data. Unfortunately all of the above means you need to delete this rom, specially those with sprite location faults. What you see basically means you reached the sprite limit and sprites are "off screen", which can crush the rom while playing. You will eventually see the same "odd dots" as red instead of purple, ie bugged items instead of sprites. Similar with whirlpools. I for instance don't use whirlpools or overworlds items at all, since once bugged there is no way to "remove them".

so can adding too many objects in the dungeons cause these errors in the overworld or vis versa?

Puzzledude wrote:Indeed. The problem is you have 3 overworld modes: beginning, first part (collecting pendants) and second part (collecting crystals). Plus you have light world/dark world. Nintendo made it so, that some of that is actually shared, ie you never get to dark world on part one (since you collect crystals), but first part of dark world actually has shared sprites with beginning of light world.

so can I not edit the beginning part or part 1 sprites in the dark world without corrupting data?

also, does the dark world share block data with the light world? as many of the areas are very similar. if so let's say I changed every block in the dark world to be different than their light work counterpart, would that require more space to store just like how the dungeons are crammed?

Puzzledude wrote:This can mess things up for Hyrule Magic, plus sprite limit overflow can happen. The result is what you see.

so can the same type of error that occurs from too many dungeon objects happen in the overworld as well if I add too many overworld sprites or items?

Puzzledude wrote:These bugs are a result of editing in general and HM not being able to handle the amount of tightly packed data, so overflows happen, which basically means "general corruption". So basically you have too much data as opposed to what the rom or HM could handle. Also note: certain bugs are just a result of bad programing of the HM, and not data overflow, such as the camera fault when Ganon or Armos pound the ground as a result of you editing monologues, since monologue values are written into the next bank and first 2 bytes there are camera shake values).

right right, I had heard about that camera shake bug, but I hadn't encountered it yet.

Puzzledude wrote:-editing Parallel Worlds also means constructing dungeons in separate roms and gluing them into the main rom, since the rom is incompatible with HM due to special coding by Euclid to manage the indoor limit, which he encountered in Parallel Tower (ie HM gave him the "out of data" message) - he used a custom java script to do the "hex gluing" for him, but this is only for PW

Making 2 separate ROMs sounds like a good idea, I hadn't thought to do this before because I wasn't very sure what I wanted the dungeons to look like (my strong point is defiantly the outside, all of the terrain design has come very easily to me but as for the dungeons I draw a blank most of the time except for what theme the dungeon will have   ) or what items I was going to give the player in what order. so far I have been taking a building the game as the player would encounter it approach.

I've designed both of the dark world and light world in-game maps and then I have been slowing building them using the small maps as I call them as a template, making small changes as I run into block limitations, etc. so I technically what I have now is completely playable up until after the first dungeon because I made all of the overworld that the player would see before the first dungeon, then the dungeon, and now the next section of the map that the player would see after the dungeon. and then I would make the second dungeon, and so forth. but I guess for our purposes that won't really work that well here.

Puzzledude wrote:You can also go for the occasional "safe indoor editing", which basically means you never remove or add any objects or sprites etc, you only use existing ones and keep their numbers, you just change their type, position etc etc. I did this a lot in final stages of Goddess of Wisdom hack, where the rom had a lot of data, so I only moved things around never using "add" or "remove", so the hex block was intact, HM thus changed only the byte values and didn't do any data shifts.

ohhhhh ok that's a really good idea, ill make sure to do that next time.

Puzzledude wrote:Next you insert new gfx and also asm codes.

does changing the gfx cause bugs?   that was one of the few things I thought wouldn't... then again editing monolog causes bugs so I guess I shouldn't be surprised.

Puzzledude wrote:Then you go to houses and caves, dungeons are last.

is there a difference in how the house and caves work as opposed to the dungeons?

Puzzledude wrote:My recomendation is that you nevertheless go for the standard method of editing on a clean rom, removing some indoor objects, ie bg objects as well as some sprites and chests to gain some space. Then work on overworlds only, since this tends to not bug, but of course no overworld items or whirlpools, no global grid changes etc. Next you insert new gfx and also asm codes. Then you go to houses and caves, dungeons are last. And even with this standard method, you will probably need occasional hex debugs, as well as an ASM person to be able to trace some never before seen bugs, to be able to fix them (of course this is valid for smaller corruption only).

overall, this seems like a very good plan, and ill defiantly go with this moving forward. but is there a reason i couldnt make 2 roms, one for indoors and one for out, debug the indoors one completely and then copy the outdoors stuff into the indoors ROM? since the overworld tiles are easy to copy?

Are the rooms that are not used in ALTTP ie rooms that are empty by default such as room 45, 71, 72, etc. included in that 20, or do I need remove 20 ish rooms that are used by ALTTP and that have objects in them?

The ones initially empty must remain empty and are not included in the count at all. You need to remove actual data from the rom, so used rooms need to be emptied. It's a simple calculation. Take the amount of data which is inserted into ALTTP 14 dungeons. Some used rooms of ALTTP are practically empty. The problem is if you use all quadrants of the used rooms and fill them in a fairly normal fashion, the result will be around 9 to 10 (new custom) dungeons, if all have a similar amount of rooms.

so can adding too many objects in the dungeons cause these errors in the overworld or vis versa?

This should not happen, but other bugs can occur. The only connection are the sprites. So if bugs occur indoors or outdoors regarding sprites, it can affect all sprites, no matter if in or outdoors.

so can I not edit the beginning part or part 1 sprites in the dark world without corrupting data?

You only edit the second part of the dark world (regarding sprites), you leave the other modes intact. But you edit the beginning, 1st and 2nd part of the light world regarding sprites. If you edit the 1st part of dark world sprites, you will automatically edit some mode of sprites of the light world.

also, does the dark world share block data with the light world? as many of the areas are very similar. if so let's say I changed every block in the dark world to be different than their light work counterpart, would that require more space to store just like how the dungeons are crammed?

Light and dark world are connected, which means if you make a light world, you are limited on what to do in the dark world gfx vise. A lot of things are shared like tree gfx, wall gfx etc. Which means you can not make a new tree or wall unless using new tiles (only a different gfx set is loaded instead, but the structure is the same), gfx sets are also limited. You can however make a new drawing using compatible tiles. This means you can make light and dark worlds completely different, they just must use compatible gfx sets (tree and wall gfx set). But certain gfx sets are unique to dark world, like ice, forest etc. Thus you can make light world completely different from dark world. Of course this means also turning off the Mirror warping from dark to light world, since you can then land on unwanted areas and walk out of screen. But obviously dark world must have the same global area grid as light world (ie the redistribution of small and big overworld areas).

so can the same type of error that occurs from too many dungeon objects happen in the overworld as well if I add too many overworld sprites or items?

Yes. You actually can not add too much sprites, since HM will inform you of sprite limit. It is just the programs fault if you encounter sprite or item overflow. So it basically means a "bugged code" rather than "too much sprites or items".

does changing the gfx cause bugs?  that was one of the few things I thought wouldn't... then again editing monolog causes bugs so I guess I shouldn't be surprised.

Editing gfx can cause visual bugs mainly. There was also an unknown corruption of using items in-game, like hookshot gfx while used, in the Conker hack when inserting new gfx. Those can be fixed only with a hex editor.

is there a difference in how the house and caves work as opposed to the dungeons?

Yes. By houses and caves I mean the rooms above 255. These are different and more fragile. Editing those will again bug the rom. These rooms (256-295) must not lead to the main section (0-255).

but is there a reason i couldnt make 2 roms, one for indoors and one for out, debug the indoors one completely and then copy the outdoors stuff into the indoors ROM? since the overworld tiles are easy to copy?

Of course it works into this direction as well, but only if the roms are compatible and had the same source rom. The main problem with transfering outdoors in general is that you need to transfer: 16x16 to 32x32 tile conversion definitions, 32x32 to 64x64 tile conversion definitions, overlays, as well as global area grid. Those things are not really transferable if they are not compatible (asside the tile conversions, which can be transfered via hex). Indoor rooms on the other hand can be transfered between more uncompatible roms.

Puzzledude wrote:The ones initially empty must remain empty and are not included in the count at all. You need to remove actual data from the rom, so used rooms need to be emptied. It's a simple calculation. Take the amount of data which is inserted into ALTTP 14 dungeons. Some used rooms of ALTTP are practically empty. The problem is if you use all quadrants of the used rooms and fill them in a fairly normal fashion, the result will be around 9 to 10 (new custom) dungeons, if all have a similar amount of rooms.

ah ok gotcha, so ideally I would need to remove items from 20 rooms that
use all 4 quadrants to really leave enough space.

Puzzledude wrote:You only edit the second part of the dark world (regarding sprites), you leave the other modes intact. But you edit the beginning, 1st and 2nd part of the light world regarding sprites. If you edit the 1st part of dark world sprites, you will automatically edit some mode of sprites of the light world.

ok, so there's only really 4 "sprite maps" ill call them, beginning, first, second light world, and second dark world.

Puzzledude wrote:Light and dark world are connected, which means if you make a light world, you are limited on what to do in the dark world gfx vise. A lot of things are shared like tree gfx, wall gfx etc. Which means you can not make a new tree or wall unless using new tiles (only a different gfx set is loaded instead, but the structure is the same), gfx sets are also limited. You can however make a new drawing using compatible tiles. This means you can make light and dark worlds completely different, they just must use compatible gfx sets (tree and wall gfx set). But certain gfx sets are unique to dark world, like ice, forest etc. Thus you can make light world completely different from dark world. Of course this means also turning off the Mirror warping from dark to light world, since you can then land on unwanted areas and walk out of screen. But obviously dark world must have the same global area grid as light world (ie the redistribution of small and big overworld areas).

I guess I was referring to what I call tiles here. for the sake of organization I've been calling the 8x8 sections, gfx, the 16x16 sections, blocks, and the 32x32 sections tiles. I was aware that a lot of the gfx are the same except in some cases for example like the light and dark world trees look different, but they use the same tiles and blocks but the gfx are different.
so my question is, could every 32x32 tile be different compared to its otherworldly counterpart, or are they shared in some areas as well?

Puzzledude wrote:but of course no overworld items or whirlpools, no global grid changes etc.

i wasn't really planning on using the whirlpools anyway, but when it comes time to add items in the overworld or change the global grid, what common bugs should i look for so i know if it got corrupted or not?

I guess I was referring to what I call tiles here. for the sake of organization I've been calling the 8x8 sections, gfx, the 16x16 sections, blocks, and the 32x32 sections tiles.

Nice, but actually they are all tiles. I call them: gfx/small tiles (8x8), medium tiles (16x16), big tiles (32x32).

so my question is, could every 32x32 tile be different compared to its otherworldly counterpart, or are they shared in some areas as well?

Some are shared, but all can be made "unshared", similar to indoor room header. There should be enough space if you "unshare" all main overworld areas. You thus have 8871 big tiles in total (unique). And with them you fill all areas: 64 in light world and same in dark. One small area is 16x16= 256 big tiles. So light world is 16384 big tiles, same dark world. And some more additional areas: overlays, zora, master quest. All in all there are 9F+1= 160 small areas (one big area is 4 small areas), which is 40960 big tiles. So you have 1 to 5 ratio regarding using unique tiles to draw actual overworlds.

So your question: can every big tile be different between light/dark worlds. The answer is yes, but you are limited globaly to 8871 unique big tiles in all overworld areas. So with those unique ones you need to draw everything.

i wasn't really planning on using the whirlpools anyway, but when it comes time to add items in the overworld or change the global grid, what common bugs should i look for so i know if it got corrupted or not?

Well, you do not want to change the global grid of areas. Big hacks of course do that, but very carefully. You need to first remove the sprites which are in those areas affected. For instance splitting one big area to 4 smaller ones can land a sprite in the off screen or unused area, which will crash the game. And for unknown reasons HM will put out all possible entrances (ie yellow dots) into random areas of dark world if you change the global grid of light world. So complete hacks first fix all that by removing entrances, sprites and items, change the grid and re-remove those entrances (yellow dots). It's a difficult process, but can be done and debug. For instance PW, GoT, GoW and Dark Prophecy hacks all changed the global area-grid (ie which areas are small, which big) to be able to make more unique overworlds.

Puzzledude wrote:Nice, but actually they are all tiles. I call them: gfx/small tiles (8x8), medium tiles (16x16), big tiles (32x32).

ah that's a better way, ill go with that from now on.

Puzzledude wrote:Some are shared, but all can be made "unshared", similar to indoor room header. There should be enough space if you "unshare" all main overworld areas. You thus have 8871 big tiles in total (unique). And with them you fill all areas: 64 in light world and same in dark. One small area is 16x16= 256 big tiles. So light world is 16384 big tiles, same dark world. And some more additional areas: overlays, zora, master quest. All in all there are 9F+1= 160 small areas (one big area is 4 small areas), which is 40960 big tiles. So you have 1 to 5 ratio regarding using unique tiles to draw actual overworlds.

So your question: can every big tile be different between light/dark worlds. The answer is yes, but you are limited globaly to 8871 unique big tiles in all overworld areas. So with those unique ones you need to draw everything.

right gotcha, that's what i meant.

Puzzledude wrote:Well, you do not want to change the global grid of areas. Big hacks of course do that, but very carefully. You need to first remove the sprites which are in those areas affected. For instance splitting one big area to 4 smaller ones can land a sprite in the off screen or unused area, which will crash the game. And for unknown reasons HM will put out all possible entrances (ie yellow dots) into random areas of dark world if you change the global grid of light world. So complete hacks first fix all that by removing entrances, sprites and items, change the grid and re-remove those entrances (yellow dots). It's a difficult process, but can be done and debug. For instance PW, GoT, GoW and Dark Prophecy hacks all changed the global area-grid (ie which areas are small, which big) to be able to make more unique overworlds.

that doesn't sound like too much work, I can do that.

so another thing, I was in the process of removing 20 rooms from a clean rom and I discovered a port option in HM that then brings up a menu where you can copy rooms from room to room or to another rom even, does this not work? or is it extremely buggy? I tried it on my rom to a blank one and it didn't work because it said there were too many objects and I'm guessing that's just because of the way I made the room not knowing about the restrictions. but should it work? I'm guessing not as you haven't mentioned it.

so another thing, I was in the process of removing 20 rooms from a clean rom and I discovered a port option in HM that then brings up a menu where you can copy rooms from room to room or to another rom even, does this not work? or is it extremely buggy? I tried it on my rom to a blank one and it didn't work because it said there were too many objects and I'm guessing that's just because of the way I made the room not knowing about the restrictions. but should it work? I'm guessing not as you haven't mentioned it.

I know the Port option, but I only used it to port rooms within the same rom. I never tested it or used it between roms, so no idea if this works. If it does, than this is the option to use if porting. I would have to see it through the hex code to see, what the program is actually doing when porting between 2 roms.

Puzzledude wrote:I know the Port option, but I only used it to port rooms within the same rom. I never tested it or used it between roms, so no idea if this works. If it does, than this is the option to use if porting. I would have to see it through the hex code to see, what the program is actually doing when porting between 2 roms.

alright then, ill fiddle around with it, and ill post what I find, whether it works or not, I don't know what the hex is supposed to look like but maybe ill post it and you can look at it. and thanks for the help dude I really appreciate it.

alright yeah, it seems to me that you can do much with it, I was unable to copy an unedited room from an unedited rom into another unedited rom.
it seems to me that unless the room you are copying is completely empty it won't copy or something along those lines, even if it is within the same rom. idk im not sure how it works.
oh well worth a shot

Just to answer what the export room to binary does
it export current room objects data (no other data only the tiles)
that's an option for randomizer development which i am part of it's made to be used with ASM so you can import room easily in your code like this :

Code:


org $1F8000+(08*3) ;Room Pointers
dl newRoom08 ;set pointer at position 08*3 (long pointer)
org $248000 ; Set a position in the ROM
newRoom08:
incbin yourRoom.zrd ;import room as binary


but again this is only for tiles objects i might add a way to export everything and import everything in the future