Bigger Map?

So I looking to start, and I am wondering, is there any way to expand either the over world or underworld, or both. I have a lot of cool ideas, and especially with the over world, I won't have a lot of space. Is there already maybe a ASM patch for this?

Andcool wrote:So I looking to start, and I am wondering, is there any way to expand either the over world or underworld, or both. I have a lot of cool ideas, and especially with the over world, I won't have a lot of space. Is there already maybe a ASM patch for this?

You will learn that when romhacking you might have a lot of ideas, but you will soon realize that the original game has limitations, which you simply can not overcome:

The overworld is limited to areas from 00 to 3F and a mirror in dark world, going from 40 to 7F, all in hex. This is 64 small areas in both worlds, while the big area counts as 4 small ones. Not only are you limited to this and can not expand it, you also can only have squared areas (and not rectangular ones for instance). Going left from area 00 will land you on the other side, thus in area 08.

Changing this would be identical to basically make a new game or at least such a heavy programing that it basically is not doable.

There are also special additional areas, such as Master sword, under bridge, Zora, and all overlays such as fog or rain. These will either allow only sprites or nothing at all (you can not thus count them as actual areas).

The same can be said for indoors. Max limit of rooms which can be dungeons are exactly FF in hex or 256 in dec, which is 255 + room0, wihch is always Ganon room.
The rest are houses and caves. There can never be a warp or any other connection between those rooms in the 255 section and the rest to 295. The game will theoretically allow 320 though, but this is not accessible in Hyrule Magic.

Making more than 320 is not even doable in theory, since the game simply stops reading pointers after 320x3 bytes, which is hardcoded. So Nintendo did make room for additional +25 rooms (but only for houses and caves with such entrance, which is also exit). This could thus in theory be 50 houses with 2 quadrants each, since you can enter in a HM room from left or right. However you would most surely run out of entrance definitions, which are limited to 84 in hex, the rest are special things like overlays etc, so the actual number goes to 9F, and all is used.

The original game however does not use all rooms and all that are used are not neccesarily fully filled with objects. This is so due to data limit. Around 10 percent must always be empty otherwise Hyrule Magic will again fail. It will also fail if room are too filled with objects, since it will run out of space. Even if you would work in hex, it is still unclear how the game will react to this. Probably with a slow down. It is a fact though that 1 room also has a "logical" data limit, even if in hex and will otherwise make display bugs.

Or in other words, you are pretty much limited to what the original game is using. The same can be said for sprites, items (under jars), chest content/limit, special effects (internal room header), number of pushable blocks/torches, entrances (from overworld to indoors) and exits.

Working through hex can indeed expand certain things, like sprites, but again withing reasonal limit. This is however not true for overworld areas and dungeon rooms. Certainly no ASM will help here.

To sum it up, the expansion of any kind is not recomended and in the case of overworld and (for instance) entrances from overworld to dungeons you are limited to the exact number of what the original is using; while some things (like sprites, dungeon room, items etc) can indeed expand their original number (but only through hex).

For instance a fine example of data expansion is for indoor effect/tags. This is the data for gfx, pal, transit etc for one room. Original game has this severely limited to exact number of what the game is using, severely limiting the editing possibilities. But in hex (and with the HM v964) you can expand this to maximum amount of space for all rooms. So thus all rooms (even 320) can now use max room-header.

Another example are indoor items: again max expansion possible here: 2 byte pointers mean max is one 8000 banks. So working through hex can expand indoor items (things under jars) to around 16 per room for all 320 rooms, and to around 11 sprites per room for all 320 rooms. So here we can even achieve a theoretical maximum which will even render the emulators to not be able to run them without slowdowns.

But this is working with hex, which is not recomended. Any work outside the editor is considered advanced editing and not really recomended. While the expansion does not cover overworld areas or dungeon rooms (exception are those 25, but this is no good, since you can not add entrances into them).

Is this why it is not recommended to have a connecting cave/dungeon lead from the DW to the Light World?

wizzrobemaster wrote:Is this why it is not recommended to have a connecting cave/dungeon lead from the DW to the Light World?

I'd say that isn't recommended because the game would probably still think you were in the other world. The overworld would probably end up being glitched if it even loaded at all.

wizzrobemaster wrote:Is this why it is not recommended to have a connecting cave/dungeon lead from the DW to the Light World?  

The game will not allow such a connection at all, since there is a byte which tells the game in which world the character is. No matter what you do in a dungeon, the game will not swap worlds, which basically means you also can not (for instance) make a light world with double amount of areas and no dark world.

In other words entering any indoors in light world will no allow exit in dark and vice versa. The result will be a heavy gfx and sprite glitch, since the game will think it is in the light world while loading dark world sprites and gfx uppon area transit.

I have experienced this through glitching in the GBA port. if you exit a DW dungeon when entering a LW dungeon, the game still thinks you are in the LW and vise versa. Even the jars are LW and Cuccos are normal.  

Keep in mind that I am not even requesting to make this change. It is fine as it is (although an Ocarina warp point would have been nice, but the limitations prevent that from being possible).

Wasn't there a hack that had this connection?

wizzrobemaster wrote:I have experienced this through glitching in the GBA port. if you exit a DW dungeon when entering a LW dungeon, the game still thinks you are in the LW and vise versa. Even the jars are LW and Cuccos are normal.  

Keep in mind that I am not even requesting to make this change.  It is fine as it is (although an Ocarina warp point would have been nice, but the limitations prevent that from being possible).  

Wasn't there a hack that had this connection?

The game will not allow DW to LW cave, but this can be overcome with ASM, which Conn did and I already used it for the Kaizo Lite hack.

Do you have an ASM patch?

The game will not allow DW to LW cave, but this can be overcome with ASM, which Conn did and I already used it for the Kaizo Lite hack.

Oh wow... Almost forgot that Moegami had this request once. Didn't know it survived the years.

Oh wow... Almost forgot that Moegami had this request once. Didn't know it survived the years.

Yes. It is interesting, that your code is still there. Can you find it? It is listed under Requests, on the last page, in the very last thread, and in almost last post of the thread:
https://www.zeldix.net/t166p25-a-link-between-overworlds

wizzrobemaster wrote:Do you have an ASM patch?  

Dark World to Light World connection cave/dungeon, also known as
A dungeon which has an entrance in DW and LW at once.


ASM by Conn
; Alttp (US) without header,

lorom
org $02E551
jsl $0eff00    ;pc 077F00
nop

org $0eff00     ; pc 077F00
STZ $8B        ; repeat overwritten code
STZ $040B    
LDA $A2        ; load exit you've taken
CMP #$60      ; compare overworld exit1        
BNE $03  
JMP oflag  
CMP #$62      ; compare dungeon exit1        
BNE $03    
JMP dflag
CMP #$F2     ; compare overworld exit2  
BNE $03  
JMP oflag
CMP #$F3     ; compare darkworld exit2  
BNE $03  
JMP dflag      
RTL

oflag:
LDA #$00            
STA $7EF3CA ; set overworld flag
STZ $02E0     ; erase bunny mode
RTL

dflag:      
LDA #$40      ; set dark world flag
STA $7EF3CA
RTL

-----------------------------------------------
Same ASM in hex:
at 16551, (new pointer)
22 00 FF 0E EA


at 77F00, (new code= asm in hex)
64 8B 9C 0B 04 A5 A2 C9 60 D0 03 4C 24 FF C9 62 D0 03 4C 2E FF C9 F2 D0 03 4C 24 FF C9 F3 D0 03 4C 2E FF 6B A9 00 8F CA F3 7E 9C E0 02 6B A9 40 8F CA F3 7E 6B


Same hex in multiple lines to make it clearer:
64 8B 9C 0B 04
A5 A2
C9 60 D0 03 4C 24 FF
C9 62 D0 03 4C 2E FF
C9 F2 D0 03 4C 24 FF
C9 F3 D0 03 4C 2E FF
6B
A9 00 8F CA F3 7E
9C E0 02
6B
A9 40 8F CA F3 7E
6B


the connections are thus:
since moegami wanted 2 connections

light world <-----------> dark world

entr 03/ exit 60 <------> entr 05/ exit 62

entr 0D/ exit F2 <------> entr 0E/ exit F3


-----------------------------------------------
-----------------------------------------------



This is what I made in Kaizo LITE, since tower of Hera was accessible from light world and dark world, and produced a bug without this fix:


hook is at 16551 for ALTTP, but in Kaizo/Japan, this is actually at 162B5:
make JSL here:
22 00 FF 0E EA= jump to 77F00 (indeed also empty space in Kaizo)

New code at 77F00 is:
64 8B 9C 0B 04, (rewrite old code overwritten because of JSL)
A5 A2, (load exit)
C9 77, (CMP to 77= Hera exit), 77 in hex is 119 in dec= room 119 is 1st Hera room
D0 03, (if not equal, branch next 3 bytes, BNE) so go to RTL
4C 0F FF, (if equal, JMP to local address FF0F= load LW code)
6B, (RTL) return and do nothing (if not equal routine)
A9 00, (load value 00, LDA= 00 is for light world)
8F CA F3 7E, (store to RAM 7EF3CA, which holds the LW/DW info)
6B, (RTL), bunny check skipped (not needed here)

Thus:
64 8B 9C 0B 04 A5 A2 C9 77 D0 03 4C 0F FF 6B A9 00 8F CA F3 7E 6B

in multiple lines:
64 8B 9C 0B 04
A5 A2
C9 77 D0 03 4C 0F FF
6B
A9 00 8F CA F3 7E 6B


Result is: always load LW (00) when exiting Hera, no matter the initial flag (00 or 40). Also tested in-game.

Kaizo is thus:
entr 33/ exit 77 <------> entr 7B/ exit = none
since 7B is a drop down entrance,
now the JMP to oflag is 0F.

-----------------------------------------------
-----------------------------------------------


2 connections are thus:
64 8B 9C 0B 04
A5 A2
C9 60 D0 03 4C 24 FF
C9 62 D0 03 4C 2E FF
C9 F2 D0 03 4C 24 FF
C9 F3 D0 03 4C 2E FF
6B
A9 00 8F CA F3 7E
9C E0 02 (bunny reset, this can be skipped)
6B
A9 40 8F CA F3 7E
6B


1 connection is thus:
64 8B 9C 0B 04
A5 A2
C9 60 D0 03 4C 16 FF
C9 62 D0 03 4C 20 FF
6B
A9 00 8F CA F3 7E
9C E0 02 (bunny reset, this can be skipped)
6B
A9 40 8F CA F3 7E
6B

As you can see the JMP to oflag is now 16/20 (=14 bytes less)



1 connection with 1 dropdown entrance
and no bunny fix (in Kaito) is:
64 8B 9C 0B 04
A5 A2
C9 77 D0 03 4C 0F FF
6B
A9 00 8F CA F3 7E 6B


here the 77 is exit from Hera



3 connections are thus:
64 8B 9C 0B 04
A5 A2
C9 60 D0 03 4C 32 FF
C9 62 D0 03 4C 3C FF
C9 F2 D0 03 4C 32 FF
C9 F3 D0 03 4C 3C FF
C9 XX D0 03 4C 32 FF
C9 XX D0 03 4C 3C FF
6B
A9 00 8F CA F3 7E
9C E0 02 (bunny reset, this can be skipped)
6B
A9 40 8F CA F3 7E
6B


fill XX with new exit values, but the JMP to oflag is now 32/3C,

JMPs are valid if code starts at 77F00.

It is also recomended to have Moonpearl before you are able to make this transit as the bunny reset 9C E0 02 (which works) still need the additional speed reset fix and the Link-pal fix (as now Link has main sprite-pal from bunny). But like said no problems if Moonpearl (and it is logical to have it).

Puzzledude wrote:

wizzrobemaster wrote:Is this why it is not recommended to have a connecting cave/dungeon lead from the DW to the Light World?  

The game will not allow such a connection at all, since there is a byte which tells the game in which world the character is. No matter what you do in a dungeon, the game will not swap worlds, which basically means you also can not (for instance) make a light world with double amount of areas and no dark world.

In other words entering any indoors in light world will no allow exit in dark and vice versa. The result will be a heavy gfx and sprite glitch, since the game will think it is in the light world while loading dark world sprites and gfx uppon area transit.

If memory from my EG days serves, graphics glitching upon exit from this kind of a connection is really quite light, no worse than the nicer variants of Death Mountain Descent. Theoretically you could maybe remove the relevant distinct DW graphics/palettes entirely, and set them to be a copy of the LW graphics/palettes instead? which should mostly then avoid visual clashes. The result could be that the "DW" exit leads to a duplicate screen, which can however have minor gameplay-relevant differences; that then disappear if you leave the screen and return. (E.g. an entrance going in turn again to a different area than on the corresponding LW screen.)

Alternately, if the DW area were walled in (no screen transitions possible), then it could be too built to be an "extended LW" overworld area all of its own.

The only thing that the cave-entrance DW screen would have to share with its LW counterpart are probably the sprites (≈ enemies) and map position?

(But this is all thinking out loud, not tested — maybe something else would still get in the way.)

I find that idea abit too complicated and screwy to work out.
How much space can zelda 3 hold altogether without going flop and corrupting something else important ?