SunGodPortal's Burning Questions

K. Thanks for the additional info. I think what was confusing me last night is that when looking at HM and comparing it with data in the ROM I was forgetting that the main blockset and room blockset are two separate entities. The room blocksets have their own indexes (assuming that's the proper term here).

Puzzledude wrote:Because it is uncapable of doing so (programing mistake or maybe deliberately done).

Ah. I kinda suspected that.

Puzzledude wrote:I can not suggest changing block types for dungeons at all, since dungeons are object based. So you don't want a lantern which you walk through - then all lanterns can be walked through. Unless you want to fill the object with other gfx and thus overhaul it completely. But you can still overhaul all dungeons without changing the block types.

I'm not sure to what extent I will actually need to change the block types for the dungeon, but I figured I would research them anyway. Curiosity, I guess. There's no such thing as too much knowledge.

I'm a little confused about something concerning the palettes. More or less, there are two questions here regarding the same thing.

Not so confusing part:
Here we see the graphic schemes window. There's four numbers that can be configured for each palette set. There are obviously way more than 4 palettes in each palette set so I'm left wondering: What determines which palettes belong to each of the numbers represented below in the palette section?



Confusing part:
Four numbers... I understand that these determine which palettes are associated with each palette set that can be assigned elsewhere in the editor, but what I don't understand is how it divides this up. There are technically 16 rows of palettes for each set of palettes (more if you divide it up based on how they are utilized in the game since most things do not utilize a full palette) and I understand that with 4 numbers that can be configured here that means that each number represents a quarter of each palette set. But how are the sets divided up?



Is it simply divided by rows? As-in, rows 0-3 might be the first number, rows 4-7 might be the second number, etc... Or is it divided up based on sections? As-in colors 0-7 of rows 0-7, colors 8-F of rows 0-7, etc. The only reason I am not automatically assuming that it is based on entire rows is because A) how they are used in game and B) in HM's palette editor (not the graphic scheme, but the actual palette editor) they are divided up into what seems to be their smallest individual components (4 colors for a shield palette, 8 colors for most sprites, etc.).

OR, have I got it all wrong and a certain number of palettes are static for all areas of the overworld and a certain number of palettes static for all dungeons with only a certain amount being configured for each area?

EDIT: It just occurred to me that the palettes that are being configured in the graphic schemes are likely not a full 16 palettes. That still leaves a lot of this up in the air though. Anyone have any suggestions as to how I can get a more complete understanding of how the palettes work in this game? In the meantime I'll try to answer whatever questions I can with whatever tests I can think of.

Anybody know where the info is to have the overworld screen fade or black out upon transitions so you don't have to worry about the GFX sets being compatible between areas? I can't seem to locate that. I remember seeing it somewhere on this site before.

Compendium page 363 and 435.
12CE3 and 12CE4, change both values to EA to always fade-out on all overworld area-transitions.
Not sure if headered or unheadered rom, since Euclid was probably using a headered rom.

Alternatively this should also work:
12CDD, change to 80. Needs testing.

Puzzledude wrote:Compendium page 363 and 435.
12CE3 and 12CE4, change both values to EA to always fade-out on all overworld area-transitions.
Not sure if headered or unheadered rom, since Euclid was probably using a headered rom.

Alternatively this should also work:
12CDD, change to 80. Needs testing.

Ah okay. Thanks. I thought I remembered it being on the site somewhere. I totally forgot that the compendium has some hex stuff too.

By the way, that giant hex doc you uploaded a while back is awesome. Some of the stuff in there gives much greater flexibility for various scenarios. Having the priest and Zelda disappear after the master sword is obtained was really bugging me since my own hack goes from the rescue scenario to the crystal phase, skipping the pendants. The beginning of the game also relies heavily on bombs so being able to automatically start with a 50 bomb max means I won't have to make the bombs infinite anymore.

I have two entrances that upon exiting have the player approximately 16 pixels in front of the door and facing the wrong way (up instead of down). They are the entrances to the cave behind the graveyard and the ice cave entrance (not the bombable one). Does anyone know what causes this?

And while I'm here, this appeared on RHDN:

rainponcho wrote:Patched SunGodPortal's Hyrule Magic version with a monologue expansion. Supposedly will work up to 1MB of text. It _looks_ like it works, at least in the editor.
https://www.sendspace.com/file/xfqeiv

http://www.romhacking.net/forum/index.php?topic=20512.20

I have two entrances that upon exiting have the player approximately 16 pixels in front of the door and facing the wrong way (up instead of down). They are the entrances to the cave behind the graveyard and the ice cave entrance (not the bombable one). Does anyone know what causes this?

Yes, it's a bug, cased by HM. I never looked into this but it's solvable with ASM tracing and then a hex edit.

Okay. This was on one of my preliminary ROMs so since there is no simple solution I think I'll just ignore this problem until it affects one of my master ROMs.