All Screens (title, naming screen etc)

Going to back up. So the pointer for the player select screen signifies the end of the title screen data. Okay. What about the individual backgrounds, especially the title screen? I assume that backgrounds follow the same principle of ending one after, but the title screen doesn't have pointers for the other two backgrounds. Also what signifies the end of the last screen, the Nintendo screen?

Alright. So no delimiters. A pointer that signifies the start of one layer signifies the end of another. So if I wanted to increase the title screen's layer 1 size, I would change layer 2's pointer to point to 0x6639F instead of 0x6639E?

Yes, this is actually valid for screens, not layers. It is yet to be determined how the game knows on what bg the gfx is, but this seems to be in the code itself (byte/bit vise). For it is clear that the entire title screen (all layers) starts at 65D6D and ends at 661C7, and that FF is simply a gfx loading location, ie far lower right in the gfx set.

If you want to expand the data for the title screen, the pointer that points to 661C8 must point further, for instance to 661D8.

So this sounds good but what signifies the end of the last screen?

This one is easy to answer, the pointer for the Nintendo logo signifies the end for all screens. Do note: Nintendo logo is not a screen, but screens end and then (after the screens) comes the code for the logo pop-up.
I just didn't bother to find it before since I never thought this would actually be needed for the end of all screens, but it is easy to find:

Nintendo logo data starts at 66D7A.
so screens end at 66D79 with FF

66D7A= 7A ED 0C is 7A ED (since it is local).
It is just some bytes forward (tested with data corruption),
at 66D8E, you have code B9 7A ED.

So the 2 byte pointer is at 66D8F= 7A ED (tested with data corruption).

So 7A ED points to 66D7A. All screens thus end at 66D79 with an FF byte.
So screens are now at the end. And after screens comes the code for other things, and that thing is the Nintndo logo pop-up, which is no longer a "screen".

I should state that you've been a great help help. Thank you.

Sure. I was always fond of hex analysing, but I certainly can not code. So I guess for making an editor you need both.

Going to back up. So the pointer for the player select screen signifies the end of the title screen data. Okay.

Yes, the end of title screen is one byte earlier.

What about the individual backgrounds, especially the title screen?

Still needs to be determined. I'm assuming with the actual Palette byte bit vise, as it is custom for BG definitions.

I assume that backgrounds follow the same principle of ending one after, but the title screen doesn't have pointers for the other two backgrounds.

Not really. It could just be random.
You see you need to know 2 things when loading GFX onto the title: position in the gfx grid, going from 00 to FF, global grid 1 or 2= bit vise. And the PAL value. 2 bytes only.

The BG and the grid 1 from 00 to FF or grid 2 from 00 to FF should be "hidden" inside these 2 bytes bit vise. I'll look at this some more to varify it.

What about the individual backgrounds, especially the title screen?

I've analysed this some more:
BG is determined bit vise as suspected for every individual element on the title screen.

One square/pixel element has 6 bytes:
1st and 2nd bytes= location on the screen
3rd byte= horizontal or vertical element
4th byte= size of element
5th byte= location of the gfx tile in the gfx set
6th byte= palette

But now the complex part:
location starts at 00 00, but this is if element is on BG1,
if this is changed to 10 00, the element is on BG2, while still on location 00 00.
So this is bit wise= add 10 on the first byte to change BG.

similar for the gfx grid= 4 grids all together going from 00 to FF.
If grid one, then gfx, pal is for instance BD 90,
changing this to BD 91, will also load BD, but on the second grid, thus indeed on BD 01= 1BD, so BD 01 is merged with BD 90 into BD 91.

Similar for the type of element "fill/flodd" or "normal":

example:
one element code is:
00 40 00 01 BF BD

now if change to "flood" type the code is
00 40 00 41 BE BD.

This was all achieved with HM+save +hex compare, however it is very complex and will require even more examination (and that was only for title screen) and still lots its unknown. Not sure if I will look any further into this, as it might need some other method to decode it all bit vise.

Also note, if the element has a size over 00, it will need 2 more additional bytes for every size increase, since for instance the size with 2 places will load 2 gfx pixels.

Puzzledude wrote:

One square/pixel element has 6 bytes:
Bytes 1 to 2 = location on the screen
Bytes 3 to - = horizontal or vertical element
Bytes 4 to - = size of element
Bytes 5 to - = location of the gfx tile in the gfx set
Bytes 6 to - = palette

Puzzledude wrote:
But now the complex part:
location starts at 00 00, but this is if element is on BG1,
if this is changed to 10 00, the element is on BG2, while still on location 00 00.
So this is bit wise= add 10 on the first byte to change BG.

So:

seenInGame = firstByteofLocationinROM - (BG# - 1) * 0x10

and

firstByteofLocationinROM = seenInGame + (BG# - 1) * 0x10

Puzzledude wrote:
similar for the gfx grid= 4 grids all together going from 00 to FF.
If grid one, then gfx, pal is for instance BD 90,
changing this to BD 91, will also load BD, but on the second grid, thus indeed on BD 01= 1BD, so BD 01 is merged with BD 90 into BD 91.

Puzzledude wrote:
Similar for the type of element "fill/flodd" or "normal":

example:
one element code is:
00 40 00 01 BF BD

now if change to "flood" type the code is
00 40 00 41 BE BD.

This was all achieved with HM+save +hex compare, however it is very complex and will require even more examination (and that was only for title screen) and still lots its unknown. Not sure if I will look any further into this, as it might need some other method to decode it all bit vise.

Also note, if the element has a size over 00, it will need 2 more additional bytes for every size increase, since for instance the size with 2 places will load 2 gfx pixels.

I appreciate this.

Yea, it is not so complex as it looks, if you think about it, what is beyond FF. Well 100 = 0100 = 01 00 =reversed 00 01.

So now on the right of the Hyrule Magic Title screen editor you have how much space: 00 to FF = 100 in hex times 4= exactly 400 in hex or 0400 or 04 00 or 00 04.
So all locations go from 00 00 to 00 04 (=1024 gfx pixels in dec to choose from= 16 gfx sets, from which 3 are empty).

Plenty enogh space to throw in the PAL value into the second byte, but not the first, which is completely location based (from 00 to FF), but second byte is only from 00 to 04, so it "has room" for the PAL value as well.

I appreciate this

Yes, regarding the "flood" and "normal" element. Hyrule Magic was crashing a lot here and replaced the data around a lot. It is best to actually avoid the "flood" function and make all elements only "normal draw", however at least some elements are "flood" in the original.
This should be re-examined correctly, as in one point it was even giving me 5 bytes instead of 6.

And also here:
01 BF BD
41 BE BD.
seems to be bit vise on 2 bytes, which is quite complex for only a "flood type".


PS
You can also load on BG3, but only on the entirely new gfx grid= grid 5, which has only letters. Again best to leave this alone.

I found a wikipedia on flood fill. I'm going to leave it here for me and others who want to be lead to more documentation about it.

https://en.wikipedia.org/wiki/Flood_fill