Topic: Developing FF4kster: a comprehensive editor for FF4

[Grimoire LD]

Hmm, I have a fairly large bug to report, when you're scrolling around tilesets the program may randomly decide to crash, this seems to occur most often by switching various parts of tileset info. To my knowledge this did not occur in previous versions.

The scrolling cursor on the map is fixed properly though.

[avalanche]

... And doesn't Lugae shoot up into the air in human form and come back down as a skeleton? Maybe I'm just imagining that...
As for Mombomb... I know for sure that there is not a second "special size" with an alternate palette, like there is with K. and Q. Eblan.
While we're on the subject of the Eblans... Are you sure they don't flicker into their new palette? I thought I remembered that, but memory is a funny thing... Especially mine when it comes to this game, apparently (I'm sure Grimoire LD has a secret running list somewhere of everything I've thought I remembered on this forum that he showed me I was wrong about).

You are right, Dr Lugae jumps up like that. I'm pretty sure the Eblans do not flicker, but the background dims first.

MomBomb is odd anyway. The first graphic of the regular bomb shape is not one of the special monster sizes anyway. Is there a bit that says it should be pulled from the regular monster graphics? It's the one special shape that I haven't been able to pull from the ROM. My *wild guess* is that it is a special Non-special monster graphic, and maybe when it is changing to the next form it just changes the palette first and pauses a moment before changing the graphic itself.

In any case, I guess it is a mystery for the moment.

 
Here is another pretty minor thing. Anybody know why some map transitions use a letterbox crop (like town of baron) and some use a shrinking square (most everything)?

[Pinkpuff]

Hmm, I have a fairly large bug to report, when you're scrolling around tilesets the program may randomly decide to crash, this seems to occur most often by switching various parts of tileset info. To my knowledge this did not occur in previous versions.

I just can't win... 

Bug confirmed, but this one's probably gonna be a lot harder to track down...

Thanks for letting me know though.

[Grimoire LD]

... And doesn't Lugae shoot up into the air in human form and come back down as a skeleton? Maybe I'm just imagining that...
As for Mombomb... I know for sure that there is not a second "special size" with an alternate palette, like there is with K. and Q. Eblan.
While we're on the subject of the Eblans... Are you sure they don't flicker into their new palette? I thought I remembered that, but memory is a funny thing... Especially mine when it comes to this game, apparently (I'm sure Grimoire LD has a secret running list somewhere of everything I've thought I remembered on this forum that he showed me I was wrong about).

You are right, Dr Lugae jumps up like that. I'm pretty sure the Eblans do not flicker, but the background dims first.

MomBomb is odd anyway. The first graphic of the regular bomb shape is not one of the special monster sizes anyway. Is there a bit that says it should be pulled from the regular monster graphics? It's the one special shape that I haven't been able to pull from the ROM. My *wild guess* is that it is a special Non-special monster graphic, and maybe when it is changing to the next form it just changes the palette first and pauses a moment before changing the graphic itself.

In any case, I guess it is a mystery for the moment.

 
Here is another pretty minor thing. Anybody know why some map transitions use a letterbox crop (like town of baron) and some use a shrinking square (most everything)?

Hmm, I'm not sure what you mean with the map transitions there, perhaps you could give a detailed example? I've personally noticed no differences from the Town of Baron to Baron Castle to Mist Cave, they all looked identical.

[avalanche]

Hmm, I'm not sure what you mean with the map transitions there, perhaps you could give a detailed example? I've personally noticed no differences from the Town of Baron to Baron Castle to Mist Cave, they all looked identical.

If you go from the overworld into the Town of Baron, it will close using a crop on all sides down to a point, and it will reopen with what I call letterbox which is a cropping only on the top and bottom. Go back to the overworld and it will do the opposite. Or go from town into the Inn: letterbox to point mix, and reverse on the way back out.

I think each map chooses which it is opened and closed with, so the first and second halves of each map transition are what the outgoing and incoming maps, respectively, prefer.

The overworld uses the point style as do most I think.  Misty Cave uses letterbox as does Town of Baron, and the castle exterior for some quick early game examples.

I can post some screenshots later if desired. I just watched those examples in youtube videos though.

[Grimoire LD]

Hmm, it might be the emulator I'm using, what were these videos?

[avalanche]

Hmm, it might be the emulator I'm using, what were these videos?

The emulator is a good point. I'll confirm this with an emulator later today.

http://youtu.be/RmHKLW1hLmI - around 10:25 shows transition between OW and town, town and Inn. Earlier is all the intro, so between Baron interior and exterior.  I think video 2 in this series has misty cave.

[Grimoire LD]

Ah, now I see exactly what you mean. It doesn't appear to do that for me in Geiger's even in a clean rom I get the basic "close out-open" no lifting "curtains" like that video showed.

[avalanche]

Goodness, Geiger's does that for me too.  I guess I have only seen it in videos like that.  What could the difference be?  Surely that is an emulator.  Okay, I just watched a video claiming to be played on an actual SNES console, and it was only the point style too.  Maybe it's a 1.0 thing.

Well, that was easy.  Thanks Grimoire.

[LordGarmonde]

Hmm, I have a fairly large bug to report, when you're scrolling around tilesets the program may randomly decide to crash, this seems to occur most often by switching various parts of tileset info. To my knowledge this did not occur in previous versions.

I just can't win... 

Bug confirmed, but this one's probably gonna be a lot harder to track down...

Thanks for letting me know though.

I don't know if it will help, but you might be able to make sense of it. I recreated the bug several times and "debugged" it in Visual Studio 2008. The three times I checked it - using the attached sequence of events - I got three slightly different reported errors:


Unhandled exception at 0x77147225 in ff4kster.exe: 0xC0000005: Access violation reading location 0x00000060.

Unhandled exception at 0x77147225 in ff4kster.exe: 0xC0000005: Access violation reading location 0xffffffff.

Unhandled exception at 0x7714332f in ff4kster.exe: 0xC0000005: Access violation reading location 0x00000003.


I don't know to what those addresses correspond - but the one that is consistant is the one in the middle  0xC0000005.  That could just be a strictly Windows only thing (Win 7 x64) - but I figure anything that might be a clue I'm happy to seek out. If there anything you want me to test/explore specifically just let me know and I'll be happy to help if I can. In short what I found to be most reliable in producing an error consistently was:

1) Changing the layering on the 1st Sealed Cave Tile
2) Going to the Map Editor
3) Going back to the Tileset Editor and trying to reopen the Sealed Cave

Good luck Pink! You can do it! 

[Pinkpuff]

You're right, I can; and I did! And all before breakfast 

For those curious, the issue was the background pointers. The menu for the tile selector in the tileset editor is the same kind of menu object as the tile palette and even the map layout editor itself in the map editor section. The tile selector doesn't use backgrounds so it was trying to free up memory that was never allocated and then the tile properties menu would try to draw an image of itself onto this "free" memory and it would glitch out. I'm actually surprised the tile palette in the map editor didn't cause this issue as well. Anyway it should work correctly now.

So I think my next large section to tackle will be the overworld. But before that, there are a couple things that need to happen (ideally):

• Find the offsets for the rest of the maps' animated graphics
• Upload current version with animations / backgrounds / tileset editor to RHDN
• Figure out how to read the 4bpp encoding for the overworld graphics

[avalanche]

• Find the offsets for the rest of the maps' animated graphics

I think I found them!

There's a 16-byte table at 15:CB55 (ROM ACD55), one entry per tileset.  Load the appropriate byte, call it 'value'.

Then you do this weird math:   offset = (value * 256) + (value * 128)
 :edit:That is what the assembly does. I presume it can be reinterpreted as: offset = value * 16 subtiles * 24 bytes each.

Then add that to 1F:B9C0 (ROM FBBC0).  That's it!


Here's what I calculated for each, which matches with the few entries I found by hand earlier:

Code: [Select]

tileset tbl_value offset  final
------- --------- ------- -------
0       00        0       FBBC0
1       00        0       "
2       00        0       "
3       02        300     FBEC0
4       03        480     FC040
5       06        900     FC4C0
6       07        A80     FC640
7       0A        F00     FCAC0
8       0A        F00     "
9       0A        F00     "
A       0A        F00     "
B       0A        F00     "
C       0D        1380    FCF40
D       0D        1380    "
E       0D        1380    "
F       10        1800    FD3C0


I really want to look into those bits that might say whether to use a palette trick instead for animation but that will have to wait for later..

[Grimoire LD]

The fix works, and as far as I can tell, nothing else seems to be a skewed at the moment (except for the old Moon Formation AI).

[avalanche]

The addresses I posted before fix more of the animated tiles, but it is still not perfect.  I think those addresses are correct, but the way I described indexing the animated tiles is where I got it wrong.  The interesting thing is that it worked for like half the tilesets even though it was not really right. 

Anyway, I'm making major headway into how the game handles the animated tiles, but it's a slightly slower process than I'd like.

 
Update.  I spoke too soon; that first formula I gave was pretty close, there's just a tweak below.

For the hardcore enthusiasts out there, I just realized that the 2-byte tile formation data is already in the SNES background tilemap hardware format.  So the game itself only uses the unmodified tile formation data, even for animated tiles.  But what it does is copy the special animated graphics right after the normal graphics, and then overwrite the animated set every 8 screen frames.  So from its point of view, it's just a standard:

Code: [Select]

vhopppcc cccccccc
  v=vflip,  h=hflip,  o=priority,  p=palette, c=index (a full 10-bit tile index!)

So Pinkpuff, if you are using what I posted before, there are some small tweaks in order to interpret more correctly:

• Firstly, you need to use all 10 bits for the graphic tile index.  This actually adds even more non-animated tiles after the animated ones
• The animated tiles are only for those with graphic tile index 120-12F (hex).  Again, above this I think are more non-animated tiles that can be treated as normal
• And the major index is only 2 bits instead of 3 (or a mask of 0C instead of 1C).

I tested this with house, town, castle int/ext, the caves.  Even the robot gears work now and other parts that I think used to be > 130.  One tile that does still look wrong is the one that shows at the top wall of the Giant's CPU map (actually, is that long red rectangle supposed to be there? maybe it is right...).

I hope that helps, Pinkpuff!  Sometimes it just takes a few iterations to get perfect.

[LordGarmonde]

You're right, I can; and I did! And all before breakfast 

  Way to go Pink!

The fix works, and as far as I can tell, nothing else seems to be a skewed at the moment (except for the old Moon Formation AI).

  Yep - Looks Good  - but only if you finished your breakfast 

I think I found them!

There's a 16-byte table at 15:CB55 (ROM ACD55), one entry per tileset.  Load the appropriate byte, call it 'value'.

Then you do this weird math:   offset = (value * 256) + (value * 128)
 :edit:That is what the assembly does. I presume it can be reinterpreted as: offset = value * 16 subtiles * 24 bytes each.

The addresses I posted before fix more of the animated tiles, but it is still not perfect.  I think those addresses are correct, but the way I described indexing the animated tiles is where I got it wrong.  The interesting thing is that it worked for like half the tilesets even though it was not really right. 

Anyway, I'm making major headway into how the game handles the animated tiles, but it's a slightly slower process than I'd like.

Slow progress beats none at all - This game is a never-ending series of curveballs - but I can certainly say I'm impressed with your contributions so far. Keep it up! 

  I agree with this as an explanation of science - also works for trying to figure out FF4 in my opinion    https://www.youtube.com/watch?v=o1dgrvlWML4