Tweaking and/or adding formation mold templates

[Lenophis]

Eek, so far the game doesn't like it when I try and do this. The odd thing is, I'm only doing it to see if if this test monster would even work.

In any event, this is what I did to try and expand the molds:

Code: Select all

C1/20CA: AD 00 20     LDA $2000      (group formation mould index?)
C1/20CD: 0A           ASL
C1/20CE: AA           TAX
C1/20CF: C2 20        REP #$20        (Set 16-bit Accumulator)
C1/20D1: BF 1A D0 C2  LDA $C2D01A,X  (pointer table to mould info)
C1/20D5: 18           CLC
C1/20D6: 65 10        ADC $10     
C1/20D8: 85 12        STA $12        (point to special mould index, specific enemy slot)
C1/20DA: A7 12        LDA [$12]      (get 1st two bytes, which seem to be byte panning)
                      (^ they shift the picture, but effect varies based on
                  index?)
C1/20DC: 18           CLC
C1/20DD: 69 3F AE     ADC #$AE3F

I changed the load point to $F50000. There appears to be a multiplier before it, although that might be more based on the current mold it uses.

Code: Select all

C1/2544:   A906       LDA #$06
C1/2546:   0A         ASL A
C1/2547:   AA         TAX
C1/2548:   C220       REP #$20
C1/254A:   BF1AD0C2   LDA $C2D01A,X   (Load pointer to monster formation size templates)
C1/254E:   8512       STA $12
C1/2550:   A712       LDA [$12]
C1/2552:   18         CLC
C1/2553:   693FAE     ADC #$AE3F

Changed what appears to be a multiplier to #$10, and again the load point to $F50000.

And as you may have guessed, since it's me posting it, this does not work when I tinker. This game is Anti-Leno or something.

After some attempts were causing all molds to fail, I decided to keep the pointer values the same after being copied, and then the originals work again. The new mold does not work. However, I know I'm still within the game's original parameters of VRAM, which is $4000 bytes in size. The new mold is using $3F00 bytes.

Results, encountering a formation with the new mold causes a few graphical glitches, then triggers the reset vector.

Did I overlook something?

--Edit--
I'll leave that original post there, in case something pops up about it. But for now, I'll concentrate on tweaking a currently existing one.

Right now I'm tweaking a mold, and am trying to get it two use two monster sizes:
96x96
96x72

For butchering purposes, I chose mold 12.

I changed the 00 00 08 08 to 00 00 0C 0C. That makes 96x96.
I changed the 00 01 08 08 to 00 00 0C 09. That makes 96x72.

Now, the first two values of the second monster are really throwing me off. Everytime I think I figure out how it works it turns out I'm nowhere close.

On top of that, the game is still seeming to think that it's counting on these monsters to be their original sizes, 64x64 and 64x64.

I'm really stumped here...

[Assassin]

a few years back, i tried making custom molds for people a couple times, and failed. despite, like you, staying within the VRAM limit, and just trying to tweak an existing mold.

and iirc, the exact effects of the screw-up varied by the mold index. which to this day makes no sense to me, as i'd've thought the index would be effectively ignored once the game has used it to look up a mold definition.

pardon for dousing your topic with negativity, but i wanted to let you know you're not alone in your frustration with these. if you figure out how this crap works, you'll be my hero.

[Lenophis]

I have this gut feeling that the overall problem resides somewhere in C2/Exxx, much like the drawing problems I had with the expanded spell and item names.

Good news: Expanding a current mold to a bigger size does work to a certain extent. Proof of concept:



The previous size of monster 1 in mold 12 was 64x64. Now it's 96x96. As you can clearly see, it's cutting off, perhaps because what actually does the drawing is still using the old 64x64 value.

Bad news: I haven't yet located where that drawing is. This is being addressed, hopefully a solution is found sooner rather than later.

[Assassin]

The previous size of monster 1 in mold 12 was 64x64. Now it's 96x96. As you can clearly see, it's cutting off, perhaps because what actually does the drawing is still using the old 64x64 value.

Bad news: I haven't yet located where that drawing is. This is being addressed, hopefully a solution is found sooner rather than later.

doesn't this cause the total mold to exceed the overall 16384 square pixel limit? or did you shrink the other enemy slots in it?

[Lenophis]

doesn't this cause the total mold to exceed the overall 16384 square pixel limit? or did you shrink the other enemy slots in it?

The test sets monster 1's size to 96x96, and monster 2 to 96x72. Monster's 3, 4, and 5 were removed as a result. At least I think so, I have no idea actually. There's nothing to terminate these bastards, so I'm guessing. Molds 0 and 1 can easily do those sizes anyway.
96x96 = 9216
96x72 = 6912

9216 + 6912 = 16128

256 bytes to spare. Talk about lucking out.

[Assassin]

this was one of those threads that had posts rolled back due to the Great Board Crash of 2006 (2007?). Drakkhen busted things wide open with an insight about a 4x4 grid of 32x32-pixel monster subsprites with 16 possible positions. between this and his posts in the never-appearing MagiMaster thread, it's like the crash was particularly out to get him.

anyway, the relevant commented data structures for molds are at C2/C4A4, C2/B9E7, and the already long-known C2/D01A (though i did eventually figure out what the first two bytes in each referenced sub-structure were). all of this has been in the Bank C2 disassembly on my site for 2 to 3 years, so original poster is probably aware of it. but for people who don't speak assembly and were thus avoiding the document, it's still a good way to see the data.

while it's worth reading about the C2/B9E7 structure, nobody should be editing that to make custom molds, as it has fundamental building blocks usable in every mold.

honestly, Square's 13 molds already give so many options that i doubt most hackers would need to edit them at all. EDIT: (Molds 2, 4, 9, 10, and 11 do leave free buffer space, but you'd need to relocate their data tables to expand them.)

for the record, the 96x96 and 96x72 monster combination in this thread will not work, as it can't fit simultaneously on a 128x128 grid. Drakkhen and Lenophis already know that, but figured i'd recap for people who use this topic as a reference, and didn't see it back in mid-late 2006.

also, take a look at the C2/BB70 and C2/BB92 structures. they're not directly related to molds, but they stumped me for so long up until 2008 or 2009 that i'm obligated to celebrate their deciphering.

[Imzogelmo]

Well, ya'll know that I don't do graphics.... at least usually. So I'll get the ball rolling by asking the most basic of questions:

What are molds?

I'm familiar with the green type that grow in moist showers, but outside of that I'm just scratching my head.

[Assassin]

they designate the maximum heights and widths of each of the (up to 6) monsters in a formation. they're visible in FF3usME's "Monsters Formations Editor" as colored boxes if you check "Show" (then temporarily check "Presence" for unused monsters to see theirs as well). molds also have information to say where in the video buffer each monster slot has its tiles. while monsters' ultimate display positions can be moved around with formation coordinates, their tiles themselves are stored in designated areas.

the structure that has the dimensions uses tile width and height (so pixel_dimension DIV 8), but other mold structures operate on the aforementioned "4x4 grid of 32x32-pixel monster subsprites". so you'll want that first one to have heights and widths that are divisible by 4.

FF3usME does have two of the boxes as green, for what it's worth.