Topic: How do summons work?

[Pinkpuff]

Summon spells seem to work differently from the other spells in the game. The spell you see in your player's spell list is not the actual summon effect spell itself. Rather it seems to simply be something that plays a particular animation, usually involving hiding the party, then launches another spell effect (e.g. "Bahamut" is launched by "Baham"), then unhides the party.

So the things I would love to be able to know/change about these are:

• How does the summon spell (Baham) invoke the actual summon effect (Bahamut)?
• Can we change which spells count as summon spells (i.e. which ones launch summons), and can we change how many of these there are?
• Can we change which spell is launched by which summon? (e.g. Baham now launches, say, Reaction)
• How are the summon animations invoked, and in what ways can we mess with it?

[chillyfeez]

So this was an EXTREMELY long time coming, but I've found the Holy Grail.

The pointers for summoned monster image data (that is, which images are displayed when a summon spell is cast) are located at (ROM w/header) 689F0-68A11. Each pointer is two bytes long. Adding this value to D0000 gives you the location (in SNES LoROM) of the beginning of the graphic for the summoned monster.  This is one of those things we'll be smacking ourselves about for years. The pointers are in that small block of non-graphical data right in the middle of all of the monster graphic data, immediately preceding the data for summoned monster graphics. 

There are still some important pieces to work out here:
- The palette is referenced in a separate subroutine (specifically, it is picked at 029169 in LoROM), and I'm not quite sure how to change which palette is picked (there's a ton of rolling bytes preceding it, and it will take a long while to figure out exactly what needs to be changed in order to get a desired result).
- I have not yet found how the game determines the "size," or more appropriately, the sprite arrangement, so a 4x4 monster can only be replaced by a 4x4 monster (so far).
- Finally, since the pointer references a LoROM value at or above D0000, only image data that begins at 68200 (ROM w/header) can be used - D0000 through D7FFF does not exist in LoROM. The sort-of good news about this is that there is an empty block of code at 682C0 that is long enough to insert replacement images for up to three 4x4 monsters.

So, I've only hit the tip of the iceberg here, but we now know enough to be able to do this:

[Grimoire LD]

That is incredibly impressive work! Grand job Chillyfeez! I took a look at this a while back, but I didn't think my notes worth saving but something of what I found seemed to be size type, ah well. I'm sure that information will be found eventually.

That the pointers were randomly put aside right before Summoned Monster data is a bit strange. I wasn't expecting that to be the case at all. Very well done figuring that all out.

How did you find it, out of curiosity?

[chillyfeez]

I followed your lead, breakpointing last action used... actually breakpointing the next byte, last subaction used. From there it was literally days worth of following bread crumbs.
  literally days, not literally breadcrumbs. 
When a spell is cast, its ID is copied into 26D2. At a certain point, the game checks if the value at 26D2 is between 31 and 3F. If it is, then it checks if it is 3E (Asura) or greater. If not, then it subtracts 31 (I haven't looked into Asura's specific subroutine yet, though I'm sure it involves picking one of her incarnations at random - Bahamut, being after Asura, also has a separate subroutine, but it probably is very similar to what is done with the previous thirteen spells), then adds 4D and stores back into 26D2.

26D2 becomes the point of reference for the rest of the casting.
It's copied into 00E5 to determine the spell effect subroutine.
It's copied into 34C8 to determine what spell name is displayed (during casting)
It's copied into 33C5 to determine all audiovisual data - 33C5 then becomes the point of reference for the palette, graphics pointer, sprite arrangement, sound effect, and spell animation (separate from the monster summon image)

[Grimoire LD]

That is essentially what I did, but for some reason at the time I didn't have a clear grasp on what I was seeing. Only in the past few weeks have I really applied myself to understanding what I'm reading instead of skipping through until I find something that seems familiar.

All in all this is a great start, I'm glad to see this work getting underway.

[chillyfeez]

At a certain point, the game checks if the value at 26D2 is between 31 and 3F. If it is, then it checks if it is 3E (Asura) or greater. If not, then it subtracts 31 (I haven't looked into Asura's specific subroutine yet, though I'm sure it involves picking one of her incarnations at random - Bahamut, being after Asura, also has a separate subroutine, but it probably is very similar to what is done with the previous thirteen spells), then adds 4D and stores back into 26D2.

By the way, this is almost certainly why expanding the summon range has not proven successful. Making earlier spells into summons causes glitching when subtracting 31, and the game defaults to assuming later spells are Asura since they're higher than 3E.
BUT, there's space enough for three more pointers after Bahamut, so with enough clever hacking it should be possible to add on at least three more summons pretty easily. I'll go into more detail with this after I've done some more tinkering.

[Grimoire LD]

So with this do you now know the graphic pointers to the Summoned Monsters? It would be great to be able to have the player fight a summon (akin to FF4A's Lunar Ruins) like Shiva or Ramuh.

[chillyfeez]

Well, yes, sort of. Technically, that's already known.
The problem is that the graphical data for summoned monsters (that do not already appear as enemies) do not necessarily fit into any of the preset "sizes" for monsters, including the "special" sizes.
I've successfully made enemies out of chocobos and sylphs, because they are 4x4 and 2x2, respectively (this was a while ago, though - I can't quite remember the pointers used, but I found them pretty easily by counting up from Imp).
  Imp begins at 68A18 (ROM w/header), and each sprite is 18 (hex) bytes long
Shiva, Indra and Jinn (the only other three that do not appear as enemies) require quite a bit of work, and erasing the graphical data for a different monster using a program like tile layer.
I suppose if one could figure out exactly how the game translates size bytes into sprite arrangements, then they could be changed and some of the seemingly useless ones could be better employed for this purpose. Unfortunately, I'm nowhere close to being able to do this.

[Grimoire LD]

Ah, that is a slight bit of a shame. Oh well, I'm sure we'll get there eventually.

[Deathlike2]

Now only if you could tell us the probabilities of the Asura summon....

[chillyfeez]

I've been focusing pretty exclusively on the graphics so far, but I know where the Asura subroutine is. Once I'm through with my current pursuit, I'll get into the Asura probabilities. Probably not today, but within the next few days for sure.
I found the size/arrangement pointers AND the actual arrangement data late last night - including the animations (sprite changes, not the x,y movement - yet). I didn't have time to break it all down but I will this evening.
Furthermore, now that I know how the sprite arrangements of summons work, I bet I'm not far from finding the same for monsters. I'll keep you posted.

[chillyfeez]

OK, this still isn't complete, but I've got a lot more info here.

(in ROM w/header)
689f0-68a11: 2 byte pointers to summoned monster graphics (add pointer value to D0000 in SNES LoROM, or to 60200 in ROM)

6F460-6F481: 2 byte pointers to summoned monster sprite arrangement (add pointer value to D0000 in SNES LoROM, or to 60200 in ROM)

6F482-6F846: Summoned monster sprite arrangement data, each arrangement terminated by FF. Rows of sprites are numbered 0-7 in the tens place, each sprite within the row is numbered in the ones place beginning at 0 until the next row is reached. If a sprite space is left empty, add 80 (Hex) to the value.

So:

Code: [Select]

80 01 02 03 04 05 86 10 11 92 13 94 15 16 20 21
22 23 24 25 26 30 B1 32 33 34 B5 36 40 41 C2 C3
C4 45 46 D0 51 52 53 54 55 D6 FFWould look like this (where X is a sprite and a space is not):

Code: [Select]

XXXXX
XX X XX
XXXXXXX
X XXX X
XX   XX
 XXXXXIf the summon is animated, the configuration of the alternating sprites follows the first configuration, using numbers in the ones place where the original configuration left off.
So:

Code: [Select]

80 01 02 03 04 05 86 10 11 92 13 94 15 16 20 21
22 23 24 25 26 30 B1 32 33 34 B5 36 40 41 C2 C3
C4 45 46 D0 51 52 53 54 55 D6 37 38 B9 BA BB 3C
3D 47 C8 49 4A 4B CC 4D FFWould Switch between these two arrangemnets (where O is a sprite that has changed):

Code: [Select]

XXXXX       XXXXX
XX X XX     XX X XX
XXXXXXX AND XXXXXXX
X XXX X     OO   OO
XX   XX     O OOO O
 XXXXX       XXXXX those sample arrangements are supposed to look like crude smiley faces, btw. It looks fine on my computer, but my tablet changes the font and it doesn't translate well. Sorry if they look weird.

There is a TON of unused space at 6EA20-6F45F and a sizeable block at 68448-688C7. Both can be pointed to for graphical data or tile arrangements if you want to get creative!

Up next - I'm gonna see if I can figure out how the game actually controls the sprite changes (how does it flutter like sylph, make one change like Shiva, among many others, rotate between three images like Asura?)
  Ugh. Once the initial image of the summoned monster is displayed, some really complicated stuff starts happening. Not sure I'll be deciphering the animation control process anytime soon.

Also, I'll be looking again at the palettes. I wasn't paying very close attention the first time around, but I'm beginning to wonder if maybe the summons have their own palettes, separate from those used for (enemy) monsters (which, of course, would be ideal)

[Grimoire LD]

That is great news on the free space! Your documentation looks pretty defined moving forward. This is going quite well it appears.

[chillyfeez]

Yeah, it won't be very easy for Pinkpuff to include this in FF4kster, but it turns out summons are very editable when you know where to look/what to change.

[Pinkpuff]

FF4kster probably will not do much in the way of graphic editing but I'm still interested in this kind of thing for the sake of graphic/animation previews.