Topic: Developing FF4kster: a comprehensive editor for FF4

[chillyfeez]

Yeah. It's nice to have someone around who actually understands how SNES graphics work.
Wtg, avalanche!

[avalanche]

Yeah. It's nice to have someone around who actually understands how SNES graphics work.
Wtg, avalanche!

Thanks!  Now I want to look into the glowing effects like in the Tower tileset.  But I have a rather newbie problem which is that I don't have a bunch of save states or SRAMs to get me to various places in the game for arbitrary debugging.  Anybody know if there is an easy way to force loading a certain map, or is hacking an SRAM for the emulator the way to go?

[Grimoire LD]

Yeah. It's nice to have someone around who actually understands how SNES graphics work.
Wtg, avalanche!

Thanks!  Now I want to look into the glowing effects like in the Tower tileset.  But I have a rather newbie problem which is that I don't have a bunch of save states or SRAMs to get me to various places in the game for arbitrary debugging.  Anybody know if there is an easy way to force loading a certain map, or is hacking an SRAM for the emulator the way to go?

Force loading a certain map is a couple of keystrokes away with FF4kster, just use a test rom, and change the first event to loading whichever tower map you want.

[avalanche]

Now for the palette tricks!

There is a routine called every frame, like the one that updates the animated tiles graphics.  This one is at 15:C420.  It explicitly looks for tilesets by number.  Tilesets 8,A,B do one thing (Whale, Tower, Giant), and tileset 9 (Land of monsters) does another thing.  The code does some surgery to manipulate very specific color slots in specific palettes, but pulls the colors to use from tables in ROM.

All of the addresses listed below refer to lists of 8 colors, 2 bytes each.  So they are each 16 bytes.  Time is used to index all of them.  The game does something like move to the next slot every 4 frames, I believe.  Update - one of them is 16 entries long and goes twice as fast as the others.

For tilesets 8,A,B: 
14:F7D6 (ROM A79D6) -> palette 1, color 1
14:F7E6 (ROM A79E6)  -> palette 2, color 1
14:F7F6 (ROM A79F6)  -> palette 4, color 1

The following is a similar table, but instead of only updating 1 color, the entire palette is replaced, and time is used to slide the palette smoothly; starting from the appropriate point moving forward, and wrapping as necessary.  This is used for the real trippy blue-white crystal tiles.  Update - this one is 16 long and goes twice as fast.  The table is 16 long, but a sliding window of 8 are copied out to the palette.
14:F826 (ROM A7A26)  -> palette 7, all colors


For tileset 9, when the map palette is 9:
14:FBC6 (ROM A7DC6) -> palette 1, color 1
14:FBD6 (ROM A7DD6) -> palette 1, color 2   AND  palette 5, color 2
14:FBE6 (ROM A7DE6) -> palette 1, color 3
14:FBF6 (ROM A7DF6) -> palette 5, color 1

For tileset 9, when the map palette is F:
Same as above, only add 40 (hex) to all those table addresses.  They pull from tables immediately after the ones above.


 
Corrected one of the entries above.  The cycling palette table is 16 long and runs twice as fast.

[avalanche]

Ok so with regard to the 4bpp encoding of the overworld tiles, is it this?:

11. 4BPP Game Gear/Sega Master System/Wonderswan Color
  Colors Per Tile - 0-15
  Space Used - 4 bits per pixel.  32 bytes per 8x8 tile.

  Note: This is a tiled, linear bitmap format.
  Each pair represents one byte
  Format:

  [r0, bp1], [r0, bp2], [r0, bp3], [r0, bp4], [r1, bp1], [r1, bp2], [r1, bp3], [r1, bp4]
  [r2, bp1], [r2, bp2], [r2, bp3], [r2, bp4], [r3, bp1], [r3, bp2], [r3, bp3], [r3, bp4]
  [r4, bp1], [r4, bp2], [r4, bp3], [r4, bp4], [r5, bp1], [r5, bp2], [r5, bp3], [r5, bp4]
  [r6, bp1], [r6, bp2], [r6, bp3], [r6, bp4], [r7, bp1], [r7, bp2], [r7, bp3], [r7, bp4]

  Short Description:

  Bitplanes 1, 2, 3, and 4 are intertwined and stored row by row.

Or this?:

12. 4BPP Genesis/x68k
  Colors Per Tile - 0-15
  Space Used - 4 bits per pixel.  32 bytes per 8x8 tile.

  Note: This is a tiled, big Endian, linear format.
  Each pair represents one byte
  Format:

  [p1-2 r0: bp*], [p2-3 r0: bp*], [p4-5 r1: bp*], [p6-7 r1: bp*]
  [p1-2 r2: bp*], [p2-3 r2: bp*], [p4-5 r3: bp*], [p6-7 r3: bp*]
  [p1-2 r4: bp*], [p2-3 r4: bp*], [p4-5 r5: bp*], [p6-7 r5: bp*]
  [p1-2 r6: bp*], [p2-3 r6: bp*], [p4-5 r7: bp*], [p6-7 r7: bp*]

  Short Description:

  Bitplanes 1, 2, 3, and 4 are intertwined and stored pixel by pixel.

     BPP:  Bits per pixel.

     Xth Bitplane: Tells how many bitplanes deep the pixel or row is; the top layer
          is the first bitplane, the one below that is the second, and so on.

     [rC: bpD]: row number C (0-7 in a 8x8 tile), bitplane number D (starting at 1).

     [pA-B rC: bpD]: pixels A-B (leftmost pixel is 0), row number C (0-7 in a 8x8 tile),
          bitplane number D (starting at 1. bp* means it's a linear format and stores the
          bitplanes one after another bp 1 to bp Max.)

Or is it something else entirely? Or is that unknown as of yet?

I think it's the second one you listed.  I'm shocked it isn't either what the other 4 bpp ones in the game are or the first one you listed, as they are close to the hardware format.  The assembly must do some crazy stuff to get this ready for the PPU...

The first byte has the first two pixels, the low nibble is the 1st pixel, high nibble is the 2nd pixel.  No bitplanes at all.

Here's an example, with one awful palette for everything, extracted using this method:

[Vehek]

The assembly must do some crazy stuff to get this ready for the PPU...

Overworld is Mode7. Mode7 uses 8bpp tiles with no bitplanes. All it has to do is split up the nibbles and combine them with palette assignment data (ff4.txt called this the "World Map Tile Palette Pointers").

[avalanche]

The assembly must do some crazy stuff to get this ready for the PPU...

Overworld is Mode7. Mode7 uses 8bpp tiles with no bitplanes. All it has to do is split up the nibbles and combine them with palette assignment data (ff4.txt called this the "World Map Tile Palette Pointers").

Ah, yes!  I hadn't thought of the Mode7 factor.  Makes total sense.

[avalanche]

Small note regarding the event script command that tints the screen.  I think this is from Phoenix?

Code: [Select]

F9 xx Toggle screen tint xx (fast transition/slow transition)
0F/1F = normal tint
2F/3F = teal
4F/5F = purple
6F/7F = blue
8F/9F = yellow
AF/BF = green
CF/DF = red
EF/FF = black

I have a different interpretation of the bits for the parameter byte:

Code: [Select]

CCCddddd
    CCC:   color (0=normal, 1=teal, 2=purple, 3=blue, 4=yellow, 5=green, 6=red, 7=black)
    ddddd: duration, in 6 frame units
So for the first tint in the opening scene which is (F9 9A), that is yellow but 1A is the duration which means 1A*6=9C (156 decimal) screen frames.  I just counted the frames during this event in the emulator and it lines up perfectly.  Oh and I think to revert to normal, all scripts just use 00, and I'm speculating that the game remembers the duration of the last tinting and uses that when reverting, rather than looking at the parameter for that duration at all.

Related is that each unit in the E9 "Pause" command is worth 8 screen frames.

Just for those with minor OCD with regard to exact timing (coughmecough).

 
I think the tint stuff above is totally wrong... see later post.

[chillyfeez]

So if I'm reading this all correctly, then the quickest possible transition is six frames, right?
If the parameter "00" tells the game to revert using the previous dissolution duration, then 01 would be the quickest controllable amount of time to revert... Right?

[Pinkpuff]

I've uploaded the new version that includes the new information about reading tile indexes. Some of them still look... not correct... (e.g. I'm also seeing red bars in the Giant of Babil ceiling, and the Giant of Babil background looks messed up for some reason) but I think, barring the discovery of some kind of major or severe bug, or the discovery of how to fix those tiles, within the next day or two, this is the version I will submit to RHDN once I update the documentation.

[Grimoire LD]

Ah right, maybe I'm jut blind or haven't noticed it, but there is one thing still oddly missing from the dialogue editor and that's the "..." character as far as I can tell, I can't find a way to access it, I expected that ... would be turned into the single space character but it's never worked that way.

[chillyfeez]

Ah right, maybe I'm jut blind or haven't noticed it, but there is one thing still oddly missing from the dialogue editor and that's the "..." character as far as I can tell, I can't find a way to access it, I expected that ... would be turned into the single space character but it's never worked that way.

Type underscore ("_"). It might be in the readme, but I learned, I think, from Pinkpuff saying it here at one point.

[avalanche]

So if I'm reading this all correctly, then the quickest possible transition is six frames, right?
If the parameter "00" tells the game to revert using the previous dissolution duration, then 01 would be the quickest controllable amount of time to revert... Right?

The event scripts in the game only actually use 00 for reverting, there are no occurences of 01-1F.  So I am not sure what happens if you use those values.  I haven't actually seen the assembly that controls this, but I wouldn't be surprised if they just checked the top 3 bits for 0 and ignored the bottom 5 bits, but I'm just speculating there.

 
Okay so I think I could not have been more wrong. It lined up so well in my test, but that was coincidence.

The routine to implement an F9 tint instruction is at 00:E731.
I was right about the timing of reverting, but the criterion for reverting is just that it is every other use of the F9 command.  Presumably then the parameter byte there is completely unused, not even that 0 color part.

Code: [Select]

bgrsiiii
   bgr:  are the color bits you want to SUBTRACT from.  I assume 000 would appear to have no effect
   s:  indeed a speed factor.  see below
   iiii:  intensity of effect.  Again I assume 0 would appear to have no effect, and F is the most possible.
The duration is based on the intensity and speed bit.  It is (intensity * 2 + 1) frames, and multiply by 8 if the speed bit is on to slow it down.

So for the intro example of 9A, that is:  100/1/1010  subtract from Blue (so looks yellow), Slow mode, intensity of A out of a possible F.  The number of frames would be about 168 frames (decimal, compared to the 156 I said erroneously before).

So to newly answer your question chillyfeez even though I got the premise wrong earlier, is that I think you have no control over reverting whatsoever.

 
..except that global memory like this uses allows external changes. It looks like an intervening Toggle Screen Fade (cmd DA) forces the slow mode for the next revert and Load Map (FE) looks like it forces fast mode.  I'm not going to dive deep to find all such occurances, but it just took me hours to find out why the Inn scripts were asymmetric, using fast blue-tinting but slow untinting which occurs while the screen is still fully black due to the screen fade.  But it makes the sleepy-time music fit like exactly, and without that forced slow mode it was cutting off the sleep music by a little.

Some of them still look... not correct... (e.g. I'm also seeing red bars in the Giant of Babil ceiling, and the Giant of Babil background looks messed up for some reason) ...

The glowing red bars I mentioned turned out to be correct, they pulse with the palette tricks as it happens.

Just a guess based on what I saw in my code for the Giant's background.  I had the big gears working, but all the various rods and things were messed up.  Many of those are in the 130+ (hex) range, way up through at least 185 in tileset 8.  So are you using all 10 bits, and only trying to animate the ones that are 120-12F?

[Grimoire LD]

Ah right, maybe I'm jut blind or haven't noticed it, but there is one thing still oddly missing from the dialogue editor and that's the "..." character as far as I can tell, I can't find a way to access it, I expected that ... would be turned into the single space character but it's never worked that way.

Type underscore ("_"). It might be in the readme, but I learned, I think, from Pinkpuff saying it here at one point.

Geez, I feel like a dolt, I thought i tried every button combination too, haha. Well thank you very much Chillyfeez I'll keep that firmly in mind (this time).

[Pinkpuff]

Ah right, maybe I'm jut blind or haven't noticed it, but there is one thing still oddly missing from the dialogue editor and that's the "..." character as far as I can tell, I can't find a way to access it, I expected that ... would be turned into the single space character but it's never worked that way.

Chillyfeez is correct; type the underscore symbol to get an elipsis.

Also you are correct; it doesn't seem to be documented anywhere... my bad! It'll be in the readme when I upload to RHDN.

The glowing red bars I mentioned turned out to be correct, they pulse with the palette tricks as it happens.

Just a guess based on what I saw in my code for the Giant's background.  I had the big gears working, but all the various rods and things were messed up.  Many of those are in the 130+ (hex) range, way up through at least 185 in tileset 8.  So are you using all 10 bits, and only trying to animate the ones that are 120-12F?

I am, but actually I think I know where the problem might lie. Suppose something has sprite index 110. No problem. It looks at ((starting offset) + 110 * (bpp) * 8) to find the graphic data. Now, suppose instead it has sprite index 120. Ok no problem it looks at ((animated offset) + 0 * (bpp) * 8) to find the graphic data. Suppose, however, that instead it has sprite index 130. Where do I look? ((starting offset) + 130 * (bpp) * 8)? Or ((starting offset) + 120 * (bpp) * 8)? (i.e. where it would have "left off" when it took a detour for the animated sprites) Somewhere else entirely? I think could be where it's getting confused.