Topic: Developing FF4kster: a comprehensive editor for FF4

[Grimoire LD]

Ah right, a small little thing. In the event editor when you're activating or de-activating Underworld NPC's the program will think you are deactivating the Overworld PC variants. So it will put that in the text (the value is changed to the underworld equivalent unless you go back to that event instruction and access it), it's just something small I noticed.

[Pinkpuff]

Ah right, a small little thing. In the event editor when you're activating or de-activating Underworld NPC's the program will think you are deactivating the Overworld PC variants. So it will put that in the text (the value is changed to the underworld equivalent unless you go back to that event instruction and access it), it's just something small I noticed.

Not sure I quite understand what you mean... example?

[Grimoire LD]

Ah right, a small little thing. In the event editor when you're activating or de-activating Underworld NPC's the program will think you are deactivating the Overworld PC variants. So it will put that in the text (the value is changed to the underworld equivalent unless you go back to that event instruction and access it), it's just something small I noticed.

Not sure I quite understand what you mean... example?

Hmm, say if I set the deactivated NPC to NPC 497, it will show up as Cave Eblana Soldier, which is its Overworld equivalent (-256), meaning that the editor is confusing the Underworld NPC's for only the Overworld NPC's as far as activation and deactvation goes.

[avalanche]

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.

It seems odd, but the former.  Treat just like normal.  See attached pic.  That is extracted from the Giant's base address, F9700.  Tiles 09 and 0A in the tileset both use graphics indices 132, 133, 172, 173.  I highlighted those green.  Also the bottom half of the warp tiles at 72 and 73 use graphics indices 17C-17F.

Not sure what goes into the hole at 120, I don't recognize the graphics there.

[Pinkpuff]

That's strange, because as far as I can tell, that's exactly where it's looking currently...

  No it isn't! It's only checking if the index is less than 120. 

So I fixed it so that it only looks at 120-12F for the animated indexes... and that fixed the Giant tileset... but messed up the water in the towns...   

[Pinkpuff]

Ok, new update:

• The tilesets all look to be completely correct
• The animated tiles all seem to be animating correctly
• The Giant maps look correct except for the background. It looks as though something wonkee is going on with that particular map.

[avalanche]

Congrats Pinkpuff!  The animations make it seem so much more real, very rewarding.

[avalanche]

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").

I should have read your post through one more time, and it would have saved me some time.  The FF4.txt naming of "World Map Tile Palette Pointers" threw me.

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.

A belated thanks to Vehek for having posted the information needed here and in the older overworld thread even though I didn't realize it for too long.


 
(As usual, forgive me if this is already known.)


The row pointers and FF-terminated rows worked for me for the overworld, but the underground and moon were a little unexpected.  First of all the row pointers seem to have 256 for underground, even though there are only 128 rows in reality, right?  I don't know what is in the extra space, but the moon is definitely 512 entries after the first instead of an expected 384:
  B0200  Overworld row pointers
  B0400  Underground row pointer
  B0600  Moon row pointers

Then the FF terminator frequently doesn't occur at the end of the expected row length.  I found the underground rows all appeared 256 long and when I just chucked the extra and kept the first 128 it looked right.

As for the offset you add to those pointers, the underground and moon need a different value:
  B0680  Overworld row data base
  B4680  Underground row data base
  B6380  Moon row data base

[chillyfeez]

There is actually 256x256 space devoted to the Underworld, but much of it is just unused. you can see the whole thing if you use yousei's editor.
I think, also, there's no monster encounter set assignment for the unused sections, so if you were to expand the Underworld map, the game would somehow reference one of the "normal" sections' encounter data when it came to battle time.

The Moon, however, is legitimately smaller.

[Pinkpuff]

Kinda gives the impression that at one point perhaps they were planning to have more to the underground section of the game... like maybe four crystal-related scenarios rather than only two. For example, we know where the upper world crystals belong: Troia, Damcyan, Fabul, Mysidia... but where do the underground crystals belong? Dwarf Castle, Sealed Cave, ???, ???. The only other places of any significance there currently are the Feymarch and Sylph cave, but they hardly seem ransacked by Golbez & crew.

[chillyfeez]

Kinda gives the impression that at one point perhaps they were planning to have more to the underground section of the game... like maybe four crystal-related scenarios rather than only two. For example, we know where the upper world crystals belong: Troia, Damcyan, Fabul, Mysidia... but where do the underground crystals belong? Dwarf Castle, Sealed Cave, ???, ???. The only other places of any significance there currently are the Feymarch and Sylph cave, but they hardly seem ransacked by Golbez & crew.

Also, considering how easily Golbez's ass is kicked by D.Mist...
So, why wasn't one of the crystals kept in the feymarch for safe keeping?

[Grimoire LD]

Kinda gives the impression that at one point perhaps they were planning to have more to the underground section of the game... like maybe four crystal-related scenarios rather than only two. For example, we know where the upper world crystals belong: Troia, Damcyan, Fabul, Mysidia... but where do the underground crystals belong? Dwarf Castle, Sealed Cave, ???, ???. The only other places of any significance there currently are the Feymarch and Sylph cave, but they hardly seem ransacked by Golbez & crew.

DeathLike2 once thought that this point of "2 Dark Crystals" was clear proof of a lot being gutted, either for time's sake or for the sake of space. Since it seems like a bit of lazy story-telling that you're told about the Dark Crystals, then suddenly 2 are gone...

I agree with him completely, they definitely intended more for the Underworld at one point in production (the 3-Step Peninsula as well is proof of that).

As for why there aren't any Dark Crystals kept by the Eidolons, I feel that the Dark Crystals are likely Dwarven treasures and would be kept by Dwarves. We know there is one hidden in the Dwarf Castle and there's one in what seems like a sacred shrine of theirs with the Sealed Cave. It is likely they wouldn't have trusted it to other peoples to hold.

It's sort of part of the reason I'm procrastinating on what to do with the Underground section of Combat Boost. I'm split on the direction I want to take from there. I can delete all of the treasure rooms in the Sealed Cave easily to free up a Lot of space for two more dungeons, but here's my dilemma...

Do I have the party of Yang/Cid/Kain/Rosa/Cecil cross through an area of the Underworld where a Dark Crystal is kept before they find the Dwarf Castle? Or do I have Giott send them out first to head to the location of the new dungeon to find one of the Dark Crystals?

My thinking was to create a tunnel between the Dwarf Castle and Tomra and if the second way is approached (party of Rosa/Cecil/Rydia/Yang/Kain) create ruins underneath (or nearby?) Tomra in order to bring the crystal back to the Dwarf Castle to keep Tomra safe from Golbez's assaults.

The third Dark Crystal I already have figured out what I want to do, once Cid rescues the party with the Airship at Babil he tells the party that Giott said the crystal is in the far south-west and  (to not screw up future events) the party will be automatically taken to this new dungeon. This is to present a unique battle party with Cid and Rydia and to give reason for Rydia would feel any emotion about some guy she just me throwing himself over the railing of an Airship with a bomb strapped to him.

[Pinkpuff]

Ok so I have a bug report of my own this time:

It seems the bow and/or arrow range is not being written everywhere it needs to be. I changed the bow range for my hack such that there are fewer arrows, but I'm finding that while the first few bows work correctly, the ones that used to be arrows are not. They're working mostly correctly, they equip fine and all, but in battle, if I have such a bow equipped, my attacks come out like punches. Also their battle stats don't seem to compute correctly. Here is the code for the routine that writes the bow and arrow ranges. Let me know if you know of a spot I may have missed where it should be writing one of these:

Code: [Select]

WriteByte(&hC1BE, bow_start)
 WriteByte(&hC1BF, arrow_end)
 WriteByte(&hC246, bow_start - 1)
 WriteByte(&hC27B, bow_start)
 WriteByte(&hC27C, arrow_start - 1)
 WriteByte(&hC286, arrow_start)
 WriteByte(&hC287, arrow_end)
 WriteByte(&hC28C, arrow_start)
 WriteByte(&hC28D, arrow_end)
 WriteByte(&hC297, bow_start)
 WriteByte(&hC298, arrow_start - 1)
 WriteByte(&h19128, bow_start)
 WriteByte(&h19142, bow_start)
 WriteByte(&h1F526, arrow_start)
 WriteByte(&h1F55C, arrow_start)
 WriteByte(&h1A24, arrow_start)

WriteByte is a subroutine that takes an FF4 rom address and a value and writes that value to that address (it assumes headered).

bow_start, arrow_start, and arrow_end are exactly what they sound like; indexes of the first/last item of that nature.

[Grimoire LD]

Wow that's a blast from the past, let me check if all of the information there is covered...

Yeah, looks like it is. Battle stats aren't computing correctly? You mean it's reading it as if it is a Bow/Arrow deal rather than a stand alone weapon?

I'll need to dig deeper than to look at my old notes on this matter. This goes into unexplored territory with weapon graphics involved and those are never an easy trip; but should they be figured out there is a reward to be had for doing so.

Hmm, well going into battle and setting the Poison Arrow as a Two-Handed Weapon with a Chakram appearance displayed and acted perfectly. So Two-Handed Weapons work optimally.

Or so it looked... but the game then reads the Crossbow as ?20 Arrows? and that is added onto the Poison Arrows. The Poison Arrows switch fine with the Crossbow, but the Crossbow does what I just mentioned. That will need to be looked at...

There's a lot to record here; this could take a while. I'll edit the post when I have something of value.

  Here's some interesting information! It not only includes the Quiver Check, it also is the amount that will be placed into the Quiver.


$02/951A   20 9B 94   JSR $949B  [$02:949B]   A:0004   X:0020   Y:0000   P:envMxdiZC - Jump to Arrow Quiver Subroutine
----------------------------------------------------------------------------------------------------------------
$02/949B   B9 1B 32   LDA $321B,y[$7E:321B]   A:0004   X:0020   Y:0000   P:envMxdiZC - Load Item that is to be switched.
$02/949E   C9 61   CMP #$61   A:005A   X:0020   Y:0000   P:envMxdizC - Is it lower than 61 (shields)?
$02/94A0   90 02   BCC $02    [$94A4]   A:005A   X:0020   Y:0000   P:eNvMxdizc - If so, branch past.
-------------------------------------------------------------------------------------------------------------

---------------------------------------------------------------------------------------------------------------
$02/94A4   C9 54   CMP #$54   A:005A   X:0020   Y:0000   P:eNvMxdizc - Is it lower than 54? (Arrows)
$02/94A6   90 06   BCC $06    [$94AE]   A:005A   X:0020   Y:0000   P:envMxdizC - If so, branch past.
$02/94A8   A9 14   LDA #$14   A:005A   X:0020   Y:0000   P:envMxdizC - Load 14 into A (The 20 used for the Quiver)
$02/94AA   85 04   STA $04    [$00:0004]   A:0014   X:0020   Y:0000   P:envMxdizC - Store A in 04 (Yes, Byte 04)
$02/94AC   38    SEC   A:0014   X:0020   Y:0000   P:envMxdizC - Set Carry Flag.
$02/94AD   60    RTS   A:0014   X:0020   Y:0000   P:envMxdizC - Return

Disabling that check (What was the deal with the 20 Quiver anyhow?) Might fix the infinite arrows bug I was just having, let's take a look...

Indeed! That fixes the infinite arrow bug! That's one hurdle jumped... as always just make sure that you have the value of 54 set to whatever your Bows start!

Now let's see what's going on with the rest of the arrows...

Now I see nothing wrong from a glance oddly enough. I've turned the Poison Arrows into a Bow with the Mute Arrows and they are acting like proper Bow and Arrows. Did you change the visuals of your new Bows to that of Bows rather than Arrows? The attack of the weapons are not being added appropriately however. It seems to only read the attack power of... frankly I'm not sure. It is 21 which is neither the power of the Arrow or the Bow. The bow is 80 and the arrow is 30. This oddity is reflected in battle and out of battle. This implies another CMP that I must have missed at the time. I'll post more as I find more.

  Another miss on my part for proper decrementing of Arrow Weapons. When an Arrow outside of battle(changed into a bow) is put into another of the same Arrow (Bow) it will stack. It's likely a CMP I didn't notice because I didn't try to stack two before.


$01/C233   C9 54   CMP #$54   A:005A   X:0000   Y:0033   P:envMxdIZC - Is it Arrows or higher?
$01/C235   90 06   BCC $06    [$C23D]   A:005A   X:0000   Y:0033   P:envMxdIzC - If not, branch to return..
$01/C237   C9 60   CMP #$60   A:005A   X:0000   Y:0033   P:envMxdIzC - Is it shields or higher?
$01/C239   B0 02   BCS $02    [$C23D]   A:005A   X:0000   Y:0033   P:eNvMxdIzc - If not branch to return.
$01/C23B   38    SEC   A:005A   X:0000   Y:0033   P:eNvMxdIzc - Set Carry Flag.
$01/C23C   60    RTS   A:005A   X:0000   Y:0033   P:eNvMxdIzC - Return

Changing this to your desired start of Arrows should fix that behavior. It still does not fix the attack power. That is likely yet another check I am missing.

  I may be onto something here...

$03/A325   BD 33 20   LDA $2033,x[$7E:2033]   A:000C   X:0000   Y:0002   P:envMxdiZC - Load Right Hand Weapon
$03/A328   F0 4E   BEQ $4E    [$A378]   A:005A   X:0000   Y:0002   P:envMxdizC - If it is 00 branch to near End.
$03/A32A   C9 4D   CMP #$4D   A:005A   X:0000   Y:0002   P:envMxdizC - Is it Bows or higher?
$03/A32C   90 4A   BCC $4A    [$A378]   A:005A   X:0000   Y:0002   P:envMxdizC - If not, branch to near End.
$03/A32E   C9 61   CMP #$61   A:005A   X:0000   Y:0002   P:envMxdizC - Is it Less than Shields?
$03/A330   B0 46   BCS $46    [$A378]   A:005A   X:0000   Y:0002   P:eNvMxdizc - If not, branch to near End.
$03/A332   BD 35 20   LDA $2035,x[$7E:2035]   A:005A   X:0000   Y:0002   P:eNvMxdizc - Load Left Hand Weapon.
$03/A335   F0 41   BEQ $41    [$A378]   A:005B   X:0000   Y:0002   P:envMxdizc - If 00 branch to near End.
$03/A337   D0 41   BNE $41    [$A37A]   A:005B   X:0000   Y:0002   P:envMxdizc - If not 00 branch to End.
-----------------------------------------------------------------------------------------------------------------------

-----------------------------------------------------------------------------------------------------------------------
$03/A37A   60    RTS   A:005B   X:0000   Y:0002   P:envMxdizc - Return

This is rather interesting as it looks to check if the player has both Bows and Arrows. But why the failure? Hmm, I'll have to look through this with a proper Bow equipped to find out.

Alright, I found this for the Right Hand (Arrows in Right Hand- Bow in Left)

$03/8F41   C9 4D   CMP #$4D   A:005A   X:0000   Y:0007   P:envMxdIzc - Is it Bows?
$03/8F43   90 12   BCC $12    [$8F57]   A:005A   X:0000   Y:0007   P:envMxdIzC  - If not, branch past.
$03/8F45   C9 54   CMP #$54   A:005A   X:0000   Y:0007   P:envMxdIzC - Is it Arrows?
$03/8F47   B0 06   BCS $06    [$8F4F]   A:005A   X:0000   Y:0007   P:eNvMxdIzc - If not, branch past.
----------------------------------------------------------------------------------------------------------------------------
$03/8F49   A9 80   LDA #$80   A:005A   X:0000   Y:0007   P:eNvMxdIzc - Load 80 into A.
$03/8F4B   85 B8   STA $B8    [$00:00B8]   A:0080   X:0000   Y:0007   P:eNvMxdIzc - Store A in B8.
$03/8F4D   80 08   BRA $08    [$8F57]   A:0080   X:0000   Y:0007   P:eNvMxdIzc - Branch always (Presumably for a check later on?)
----------------------------------------------------------------------------------------------------------------------------
$03/8F4F   C9 61   CMP #$61   A:005B   X:0000   Y:0007   P:envMxdIZC - Is it Armor or Above?
$03/8F51   B0 04   BCS $04    [$8F57]   A:005B   X:0000   Y:0007   P:eNvMxdIzc - If not, branch past.



I can't tell you what it's exactly doing, but this is some sort of check to see if the item in the Left Hand is a proper bow. I imagine that the Right Hand Check should be close by and that should settle this matter outside of battle.


And here it is for the Left Hand!


$03/8F27   C9 4D   CMP #$4D   A:005A   X:0000   Y:0007   P:envMxdIzc - Is it Bows or greater?
$03/8F29   90 12   BCC $12    [$8F3D]   A:005A   X:0000   Y:0007   P:envMxdIzC - If not, branch past.
$03/8F2B   C9 54   CMP #$54   A:005A   X:0000   Y:0007   P:envMxdIzC - Is it Arrows or greater?
$03/8F2D   B0 06   BCS $06    [$8F35]   A:005A   X:0000   Y:0007   P:eNvMxdIzc - If not, branch elsewhere.
------------------------------------------------------------------------------------------------------
$03/8F2F   A9 80   LDA #$80   A:005A   X:0000   Y:0007   P:eNvMxdIzc - Load 80 into A.
$03/8F31   85 B7   STA $B7    [$00:00B7]   A:0080   X:0000   Y:0007   P:eNvMxdIzc - Store A in B7
$03/8F33   80 08   BRA $08    [$8F3D]   A:0080   X:0000   Y:0007   P:eNvMxdIzc - Branch elsewhere (Likely B7 is some sort of storage for a genuine Bow check)
-------------------------------------------------------------------------------------------------------------------


And this is finished! These same values are used in battle and this solves all of the problems mentioned!

I am glad to have finished this old undertaking and feel rather embarrassed that I left so much loose in the first place.

If you need anything clarified or such please let me know.

[Pinkpuff]

Changing the "Swing" to "Bow" did the trick for the visuals (easy detail to miss ^_^) and those extra addresses seem to have fixed the miscalculation.

Thanks so much Grimoire! Comin' through in a pinch once again like a true hero!