Topic: Developing FF4kster: a comprehensive editor for FF4

[LordGarmonde]

Both of those are good ideas but would be a bit of an undertaking. An "undo" feature would also be awesome but again, it's gonna be a fair bit of work.

I guess that would work as a basis for: "undo" - good thinkin'! - But first thing's first:

Right now I just want to get the tile editor working, which can't happen until I get those Airship/Ship tileset offsets figured out and also figure out why the Giant tileset doesn't look quite like it should.

I in no way guarentee this to be the answer - but I think it might at least shed a little light on the Giant problem. I pulled out the individual tiles for three sets: Giant, Whale, & Tower - I put each tile side by side (rows of 3) so one row per hex assignment so I could do the only thing I know how to do: patterning!

What I generated was a table that indicates when the tile for either the Giant or the Whale (or both) matched the tile used in the Tower. My hope is that you'll be able to surmise from there how the game's curve-ball is tracking. Not surprisingly there's a good deal of overlap but out of the 127 tiles in the Tower set 65 of them are a direct match to a tile in the Whale set and 42 tiles match a tile found in the Giant set. There are several cases (27) where all three match up (jackpot??)

So that's all well and good, you look at the table to see which ones matched or didn't...based on their Hex ID. I noticed a few instances where two tiles were clearly copies of one another but they didn't share the same ID - and the offset doesn't seem predictable either. For example (all in hex):

For (G)iant, (T)ower & (Whale):   G<70> = T<6F> while...                         

G<4E> = (T<57> = W<57>)   &   G<4F> = (T<5F> = W<5F>)

Seems like another "Gee thanks, Square" kind of arrangement but if it helps then I'm happy to have done it. The whole thing with The Giant feels almost like there's a half tile set for the background and the set the game ends up using is a mix of that and the set used in the Towers

  Two quick things I forgot:
1) I got the tiles from Phoenix's FF4Tools and I wanted that to make sure that was credited properly
2) I went off of exact matches for this go-round - but there were several instances where there would have been a match but for one - that's where a good number of differences between the Tower and the Whale arise - Within those tiles you can see that 3/4 of the subtiles that make the up the tile match - it's just changing out one:

So      S1 S2   vs  S1 S2       <-- Common for the lower Whale Entries
          S3 S4        __ S4

[Grimoire LD]

Hmm, after working on a map for a good half-an hour or so things were going well, but while I was working on it though a strange "mini-map" like box opened up and I couldn't do anything anymore. I tried to hit escape to save my progress but the system crashed and I lost my work.

Any idea what might have caused this?

[LordGarmonde]

Sorry to hear that, Grimoire; that sucks 

I haven't spent enough time with the map editor to have run into that; but I'll be on the lookout - and saving frequently.

I wonder if there would be a way to map a key to save instead of backing out to the menu. It may not be possible the way things are set up - it might be the case that you have to back out of the sub-menus to update the parameters needed to be able to save them to the ROM.

Typing that out it seems to go along with what was discussed about about mapping, exports and undo - so I just wanted to throw that out since you got me thinking about it.

[Pinkpuff]

Hmm, after working on a map for a good half-an hour or so things were going well, but while I was working on it though a strange "mini-map" like box opened up and I couldn't do anything anymore. I tried to hit escape to save my progress but the system crashed and I lost my work.

Any idea what might have caused this?

I'm afraid I don't! That is pretty alarming though! Can you (or anyone else) duplicate this? If we can figure out how to trigger it I'll be able to start hunting for the cause.

[LordGarmonde]

I wrote a script (in AutoIt) to randomly move around the tileset, select a tile, and then move to the map and perform a random set of actions (between single paste and flood fill) - I ran it twice and saw the same error as referenced above. It seems to be a memory problem - when the program crashed it was using about 2GB of memory (out of 8 for my machine, so computer was still doing fine)

I've attached 3 pictures: the mini-map pop-up, the crash screen, and the debug window/memory usage showing visual studio complaining about RAM which is shown to the right. I can easily run that script again for retesting whenever you need it. Good luck!

[LordGarmonde]

Last picture showing the RAM issue:

[Pinkpuff]

Ok thanks, now I know where to look.

  Try it now

[LordGarmonde]

Ok thanks, now I know where to look.

  Try it now

    you got it! RAM use stayed constant @10,092k - ran a few cycles - no prob! 

[Grimoire LD]

Haha, that makes this the 50th version of FF4kster I've downloaded on this computer alone. I am glad to see that this problem appears to be fixed now.

[LordGarmonde]

Haha, that makes this the 50th version of FF4kster I've downloaded on this computer alone. I am glad to see that this problem appears to be fixed now.

I'm glad it turn out to be quickly fixed (<15 mins!!) - happy editing!

I in no way guarantee this to be the answer - but I think it might at least shed a little light on the Giant problem. I pulled out the individual tiles for three sets: Giant, Whale, & Tower - I put each tile side by side (rows of 3) so one row per hex assignment so I could do the only thing I know how to do: patterning!

I hit the Ship/Airship tilesets the same way - the result is more straightforward only comparing 2 rather than 3. Comparing the two tilesets they can be (mathematically) be split into subsets:

Airship = (A) + (C)   &    Ship = (S) + (C)

Where: (A) are tiles unique to the Airship set, (S) are tiles unique to the Airship set, & (C) are common to both

Specifically the common subset is comprised of the tiles  of the indices:

{01, 02, 03, 04, 05, 06, 07, 08, 09, 0A, 0B, 0C, 0D, 0E, 0F, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 1A, 1B, 1C, 1D, 1E, 1F, 20, 21, 22, 23, 24, 25, 26, 27,  28, 2A, 2B, 2C, 2D, 2E, 30, 32, 33, 35, 36, 37, 38, 39, 3A, 3B, 3C, 3D, 3E, 3F, 53, 54, 55, 56, 57, 58, 59, 5A, 5B, 5C, 5D, 5E, 5F, 6F, 7C, 7D, 7E}

& The individual sets are indexed:

{29, 2F, 31, 34, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 4A, 4B, 4C, 4D, 4E, 4F, 50, 51, 52, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 6A, 6B, 6C, 6D, 6E, 70,  71, 72, 73, 74, 75, 76, 77, 78, 79, 7A, 7B, 7F}

Of the 127 indices 76 are shared, and 51 unique. At the very least there must be some way the game differentiates referencing the unique subsets vs the common ones; but I don't yet know how.

Could you give me an idea of how for the tilesets already mapped out you build those complete tilesets from the metatile pool: that's something I don't know the specifics of (but I think I finally grasped the concept)

If I were to continue my analysis further the next step would be to split each tile in the sets in question into their 4 individual metatiles and then construct each minimum set, taking into account for each right-rotation: 

...stupid combinatorics 

[Pinkpuff]

No sweat,

A2000-A5FFF   (149E00-14DDFF)   Town Map Tile Formation Data (*4)
...

*4 -- Town Map Tile Formation Data, 2 bytes

0x0000         8x8 tile (0x00-0xFF)
0x0001:0...1   ?
0x0001:2-4      Palette Index
0x0001:5      Tile Priority (0 = behind character, 1 = in front of character)
0x0001:6      Flip tile horizontally
0x0001:7      Flip tile vertically

The priority is ignored for the sake of the editor (currently), and there are two mystery bits that may or may not have anying to do with it.

Judging by my code, bits 6 and 7 seem to be the opposite of what you'd expect; 0 = flip, 1 = leave alone (though it is entirely possible that the program is just reading in the graphics reversed to begin with or something)

Also worthy of note is that judging by the way my code is layed out it looks like it's all the top left corners of all the tiles, followed by all the top right corners of all the tiles followed by all the bottom left corners of all the tiles followed by all the bottom right corners of all the tiles so you can't just read along 16 bytes to get one tile.

[LordGarmonde]

The priority is ignored for the sake of the editor (currently), and there are two mystery bits that may or may not have anying to do with it.

I'm just sitting down to try and have another look and found some references (most likely already known)

http://wiki.superfamicom.org/snes/show/Backgrounds  &
http://wiki.superfamicom.org/snes/show/Working+with+VRAM+-+Initializing+Tiles+and+Tile+Maps

Th most promising explaination appears to be here:

http://www.ff6hacking.com/ASM/SNES%20Graphics%20Information.html

But my brain is way too fried at the moment to try and comprehend so me = 

[LordGarmonde]

 

- The more I get into this the more confused I become...

Looking at two sets, mountain and cave and just visually scanning them I can see several tiles (and I do mean full 2x2 metatile matrices) that are the same, some using the same ID some not (see FF4Tools):

Mountain:     (Rock=7B)     (Bridge L/R=6A/6B)     (Chest Open/Closed=77/78)     (Save=7F)
                            |                        |                                   |                                  |
Cave:     (Rock=58/7E)^*     (Bridge L/R=39/3A)     (Chest Open/Closed=77/78)     (Save=7F)



* Two different rock sets??? <--- I got nothin' for that one... 

I went looking into it and found the chest and save tiles at the end of cave set and another set at the beginning of the mountain set. (See pictures) I wouldn't think that these two sets aren't also sharing. I think that the chest/save group I found at FD208 is from the end of the lunar subterrane set - but even that seems illogical because the only difference between the chests in the subterrane and the chests in caves/mountains is the color.





The giant/tower has a different chest setup to accommodate the glowing effect that us Westerners can't live without apparently...

http://tcrf.net/Final_Fantasy_IV_(SNES)/Version_Differences#Graphics



Bottom line is I really can't figure out how they could get all the tilesets assembled without a bunch of explicit instructions - not that I put this past Square but I don't know what to do from here. It may just be easier to keep the map editor as it is. If you have an idea as to something to look for let me know because this is the sort of crap that really bugs me... 

[Pinkpuff]

It sucks being so close and yet so far... 

I guess for now I will leave the map editor as is and come back to the tile editor later, hopefully armed with more info by then. Particularly for the tile editor itself I want to be able to dynamically overlap those red box/arrow indicators on the tiles that actually have them. Currently they're part of the bmp images themselves, but I would like the editor to visually reflect tiles that have had their warp/event/treasure/etc properties changed. I can go through and manually separate them using the bmp images but I don't want to have to do that if it's at all possible to read the tile graphics from the ROM, especially since that's something that in principle should be happening regardless.

In the meantime I have a bunch of stuff on my ff4kster to-do list that I can work on as time permits.

[LordGarmonde]

Yeah...maybe someday...

In the meantime, there is good news - the source for FF4Tools has every tile separated and sorted - they are each .png files ~ 4-5kb each - That's what I used when I went through and did the first few tile-by-tile comparisons