Topic: What information is known about the overworld?

[chillyfeez]

Annnnnnd we're back.

So I've been working on putting a driveable tank into TfW, and in so doing I learned a bit more about world map tile properties, specifically the first byte, as it relates to vehicle travel.
I'll dig through my copious notes and post the relevant stuff here when I have the chance.
Among what I found was the place in ROM (one byte per vehicle) that corresponds to what type of terrain a vehicle can travel over. Also, by manipulating interpretation of these bytes, apparently, airships travel as "chocobos" when in the underworld (but this can be changed, too).
This is another one of those gray areas that I can't decide if it is better suited here or on the vehicle thread, but seeing as how the concrete info I have involves world map tile properties, I'm putting it here.

[chillyfeez]

OK, I better get all of this down while it's still fresh(-ish) in my mind...

So as I said, I was working on making a driveable Dwarf Tank for TfW, which worked out splendidly, by the way. Since you can't normally use the Chocobo underground, and the Tank would only be underground, and the chocobo has a motion pattern a lot like what I wanted for the tank (sprites only move when you move, not constantly like all other vehicles, and also travels on land instead of hovering), I decided to make the Tank a special-case exception for the Chocobo.

So first of all, this - you know how if you hack the chocobo into the Underworld, it's invisible? This has nothing to do with the game's lack of ability to display the chocobo underground. No, despite the fact that there is no way in the normal game to ride a Chocobo in the Underworld, the developers decided to put in a special check in the chocobo initialization code that says:
Is the current world Overworld?
If not, skip the following code (which displays the chocobo sprites).

The code looks like this if you're in the Overworld:

Code: [Select]

$15/B3EA AD 01 17    LDA $1701  [$15:1701]; load current map
$15/B3ED D0 06       BNE $06    [$B3F5]   ; if not 00, skip the following three ops
$15/B3EF A5 AD       LDA $AD    [$00:06AD]
$15/B3F1 C9 10       CMP #$10             ; (don't know, but it's irrelevant for this discussion)
$15/B3F3 F0 03       BEQ $03    [$B3F8]   ; jump to sprite loading code (note that this is one of the ops skipped if current map is not 00)
$15/B3F8 AD 04 17    LDA $1704  [$15:1704]; load current mode of transport
$15/B3FB C9 01       CMP #$01             ; is is chocobo?
$15/B3FD F0 27       BEQ $27    [$B426]   ; if so, skip to chocobo sprite loading routine

...And like this if you're in the Underworld/moon:

Code: [Select]

$15/B3EA AD 01 17    LDA $1701  [$15:1701]; load current map
$15/B3ED D0 06       BNE $06    [$B3F5]   ; if not 00, skip to 15b3f5
$15/B3F5 4C B5 B4    JMP $B4B5  [$15:B4B5]; jump to 15b4b5
$15/B4B5 AB          PLB                 
$15/B4B6 6B          RTL                  ; end

for proof of concept, open a vanilla ROM and ride a chocobo (in the Overworld), then open Geiger's hex editor and change 1701 to anything besides 00. the chocobo will disappear. Likewise if you hack a chocobo into the underworld, then change 1701 to 00, the chocobo will appear.

You can also EA out the D0 06 at $15/B3ED in order to permanently make the chocobo visible in any world!



OK, now some stuff about vehicle travel as it relates to world map tile properties...
So we know from Yousei (and expanded on by several, including your humble narrator) that world map tile properties are stored in ROM beginning at A0A80 (ROM w/o header), and that it's 0x100 bytes per world.
Whenever a world map is loaded, those properties are loaded into EDB-FDA in RAM.
Now, the first byte of each of the two-byte tile properties contains all of the "travelability" data. Any time you try to move (press the D-Pad), the game compares the travelability of the terrain of the tile in the indicated direction against the travelability of your current method of transportation. That's right, there is a (small) table of travelability that contains an entry for each vehicle. This table is at 2AE6 (ROM w/o header) through 2AED. One byte per vehicle. 2AE6 (the entry for "no vehicle") is actually a dummy, I think, because there's a special case string of code for "no vehicle." all vehicles, though (including both chocobos), use this table to determine if they can travel on a particular piece of terrain.
By default, the table reads:

Code: [Select]

vehicle index travelability byte default value
-------------- -- ---- --
Yellow Chocobo 01 2AE7 02
Black Chocobo 02 2AE8 04
Hovercraft 03 2AE9 10
Enterprise 04 2AEA 20
Falcon 05 2AEB 20
Big Whale 06 2AEC 80
Ship 07 2AED FF

So, you see, it is possible to make the Enterprise and the Falcon subject to travel over disparate terrain rules... in case that's something you're interested in doing.
Another interesting thing about this information: there's a special case exception for how to proceed if you're in the Underworld and the "mystic silver" flag is not set. And, it can be changed separately for the Enterprise and the Falcon!
For the Enterprise:

Code: [Select]

$00/AA05 AD 04 17    LDA $1704  [$00:1704]; load current method of transportation
$00/AA08 C9 05       CMP #$05             ; is it Falcon?
$00/AA0A D0 0C       BNE $0C    [$AA18]   ; if not, skip to next check
$00/AA18 C9 04       CMP #$04             ; is it Enterprise?
$00/AA1A D0 0C       BNE $0C    [$AA28]   ; if not skip to travelability check
$00/AA1C AD 81 12    LDA $1281  [$00:1281]
$00/AA1F 29 04       AND #$04             ; check if "Yang Destroyed Cannon" flag is set (I guess after this point, the Enterprise is ready to fly underground)
$00/AA21 F0 05       BEQ $05    [$AA28]   ; if not, skip to travelability check
$00/AA23 A9 01       LDA #$01             ; if so, then for the sake of travelability check, pretend we're on a yellow chocobo
$00/AA25 4C 2D AA    JMP $AA2D  [$00:AA2D]; jump to travelability check

For the Falcon:

Code: [Select]

$00/AA05 AD 04 17    LDA $1704  [$00:1704]; Load current method of transportation
$00/AA08 C9 05       CMP #$05             ; is it Falcon?
$00/AA0A D0 0C       BNE $0C    [$AA18]   ; if not, skip to next check
$00/AA0C AD 87 12    LDA $1287  [$00:1287]
$00/AA0F 29 02       AND #$02             ; check if "Heat Shielding the Falcon" flag is set
$00/AA11 F0 15       BEQ $15    [$AA28]   ; if not, skip to travelability check
$00/AA13 A9 01       LDA #$01             ; if so, then for the sake of travelability check, pretend we're on a yellow chocobo
$00/AA15 4C 2D AA    JMP $AA2D  [$00:AA2D]; jump to travelability check

If you study the tile properties of the Underworld, you'll see that most of them are set to "Chocobo can Travel." Because, by default, there are no chocobos in the Underworld, the developers were free to use this bit for "special case airship travelability." So when the right flags are set, the Enterprise and/or Falcon can fly over extra terrain (specifically, magma).
Manipulation of this code enables us to change 1) which flag controls exapanded underworld travel (for each vehicle), as well as 2) Which vehicle to "travel as" when the specified flag is set.

For the purpose of TfW, I changed the latter of each to 04 and 05, respectively, since there will be no "application of mystic silver" in my game, but there will be a chocobo (or, more precisely, a Tank). Then I just changed the Underworld tile properties so that airships have no problem flying anywhere, but chocobos (tanks) can only travel over land.

[Bahamut ZERO]

I haven't checked Tile Layer yet, but are you using the correct tile encoding, since it's not in 4BPP SNES? The tile format is called 4BPP GBA in YY-CHR.
Or if you meant the assembled tiles, I don't have a good method for viewing them. The tileset images were made by having a program use the tile assembly data to write out the tile graphics to a file, which I then viewed in a tile viewer.

Thank you so much, Vehek! I've been trying to figure out where the hell those were hidden for quite a while!

Also of note, if you make a 4 x 4 horizontal pattern in YYCHR, you can veiw the planet Earth and Moon graphics perfectly! It makes me wonder if they too are in part related to the overworld graphics being that the planet graphic looks like it uses the same palette as the Oceans/Rivers (if so I'm slapping some continents on that badboy!).

I also noticed how the water does it's flowing effect while editing the Ocean tiles. Each  horizontal row of the grapics pixels move right at varying speeds to give it that wavey, flowing effect. Also, if you use any of the brighter blues in it's palette, they show when you're flying an airship, and it's  an eye killer.

With the info Vehek posted, I was able to port a number of world map tiles from FF5, as well as edit the ocean and recolor the castle graphics. I've attached before and after screenshots if anyone's interested.  The water probably looks better in motion, but it's pretty nice being I just did little random patterns.

[Pinkpuff]

These are unheadered offsets.
0A0000: Overworld tile assembly data
0A0200: Underworld tile assembly data
0A0400: Lunar tile assembly data

0A0600: Palette assignment data (overworld)
0A0700: Palette assignment data (underworld)
0A0800: Palette assignment data (lunar)

0A0900: Palette Data (Overworld)
0A0980: Palette Data (Underworld)
0A0A00: Palette Data (Lunar)


0E8000: Overworld subtile graphics
0EA000: Underworld subtile graphics
0EC000: Lunar subtile graphics
(4bpp linear reversed, combined with palette assignment data to make 8bpp subtiles)

I'm trying to get FF4kster to read these graphics and I'm having trouble. What does this part mean:

(4bpp linear reversed, combined with palette assignment data to make 8bpp subtiles)

Is this read differently from the graphics for, say, the ship/airship tileset?

Also the "Tile assembly data", does that work the same way as it does for "inner" tilesets?

[chillyfeez]

I donno, sorry. It's something I'll need to figure out eventually, but haven't  needed the info yet. I have to figure the "tile assembly" works somewhat differently than the location tiles, as those use two bytes per corner and include tile assignment and palette in each of those two bytes. Judging by those offsets, the tile assembly must be 0x80 bytes per corner, thus one byte per tile. Then two bytes per tile for the palette assignment table?
I won't have time to experiment with this for a few days, but I will when I get the chance if nobody swoops in before I do.

[Vehek]

It's been a long time since I worked on this, but I'll try.

I didn't keep direct notes, but reviewing the scripts I used, it looks like each block of 0x80 bytes defines a set of corners, as in one corner of each 16x16 tile. Top left, top right, bottom left, bottom right.

Is this read differently from the graphics for, say, the ship/airship tileset?

Very different. Those are planar graphics, where the bits are spread across bytes. Here, the bits are consecutive in one byte. Each nybble (4 bits) is one pixel.

Then two bytes per tile for the palette assignment table?

It's one palette byte for each 8x8 tile. You can't palette-swap mode7 tiles with map data. By the time they're sent to VRAM, they've already been assigned colors on the pixel level.

avalanche also looked into this in the past, and wrote about it in the FF4kster thread.

This probably deserves a longer tech post, but the crux is that each 8x8 graphics tile is stored in the special 4 bpp format and has 1 byte in this "palette pointers" section that you just add (or 'or', either way) to each pixel's value.  That's the final color index for each pixel, which happens to be effectively only 6-bit color index because those bytes only have certain values.  And that matches with the fact that the palettes for each world have 64 entries in them.

[chillyfeez]

So, to confirm what I think you're saying...

When in a world map, there are 256 (0x100) 8x8 tiles loaded into VRAM (which is different than locations, which only have 128 per tileset), but those tiles are palette-locked per the data at A0600, one byte per tile*

Then the table at A0000 assigns four of those 256 8x8 tiles to each 16x16 tile, one corner at a time (so all the top lefts, then all the top rights, etc). It seems, then, that there would be no way to flip vertically or horizontally, either, and no layering, right?

* I don't really know much about how SNES processes graphics, so forgive my noobiness here... I know the world map tiles use some different variant of 4bpp, wherein the 0x20 byte palettes function sort of like two independent 0x10 byte palettes. I know that bcause of experiences messing with the live RAM data. Do those palette assignment bytes actually assign two 0x10 byte metapalettes, or are there several 0x20 byte palettes that simply have common data?

[Pinkpuff]

Thank you so much for replying and explaining this! I think I get the gist of it, but I'm not 100% sure on the details, so I'd like to run through some "real" data as an example to make sure I get it:

I'm using a headered rom here, so these will be headered addresses:

So the "pixel" data should begin at E8200, correct? For me, it appears the first 32 bytes are all 00s. So if each byte encodes two pixels, then every two rows of 16 byes are essentially a tile. So the first tile is just a grid of all 00s, so let's ignore that one and move to the next tile, the one starting at E8220. We have:

Code: [Select]

34 34 34 34
43 44 43 43
34 34 44 44
43 43 43 43
34 34 34 44
43 43 43 34
34 34 34 44
44 43 43 43

So each nibble or "half-byte" is a pixel, so we can more or less just separate it out:

Code: [Select]

3 4 3 4 3 4 3 4
4 3 4 4 4 3 4 3
3 4 3 4 4 4 4 4
4 3 4 3 4 3 4 3
3 4 3 4 3 4 4 4
4 3 4 3 4 3 3 4
3 4 3 4 3 4 4 4
4 4 4 3 4 3 4 3

Next, there's a byte that gets added (or "or-ed"?) to each of these pixels? And it comes from A0800? This is the second tile, so it would use the second byte, so 10? So adding 0x10 to all of these would produce

Code: [Select]

13 14 13 14 13 14 13 14
14 13 14 14 14 13 14 13
13 14 13 14 14 14 14 14
14 13 14 13 14 13 14 13
13 14 13 14 13 14 14 14
14 13 14 13 14 13 13 14
13 14 13 14 13 14 14 14
14 14 14 13 14 13 14 13

There seem to be only two colors used in this particular instance, so we can look those up. The palette data is in a table at A0B00, correct? And looking at my code for palette reading, it should be two bytes per color. So color 0x13 would be at A0B26-7, so 52 2B, which would yield (if I did my math right):

12 Red
1A Green
0A Blue

That turns out to be sort of a lime green color. Then there's color 0x14, which would be the next two bytes, 11 23, so:

11 Red
18 Green
08 Blue

That's a similar but more medium green color. So this is I guess part of some kind of grass tile.

Anyway, is my process correct?