Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - LightPhoenix

Pages: 1 2 3 »
1
Final Fantasy V Research & Development / Re: Character Glow and Palettes
« on: February 20, 2013, 05:41:56 PM »
So I looked at making a "multi-color glow" a little more closely, and I was completely wrong.  It will actually require a significant amount of coding to set up multiple blink colors.  Unless I can figure an easy way to do it, I'm not going to bother; too much work for a minor effect. Sorry to get hopes up.  If anyone else wants to look into it, the code starts at C1/B216.

2
Final Fantasy V Research & Development / Character Glow and Palettes
« on: February 15, 2013, 08:21:02 PM »
Another minor thing, but could be useful.  I was screwing around with palette information mainly to create a new status.  I eventually coded up a rough FF6-style glow effect.

All character palette information (afaik) is handled by a function located at C1/B1AC.  This function is relatively straightforward.  First, it checks to see if the character is Wounded; if so it uses the default character palette.  Otherwise, it loads the class palette.  Then it runs two sets of checks; one for Status 0/1 (palette changes) and a second for Status 2 (glowing effects).  As coded, once a palette change effect is handled, the function skips to the glow effect.  In order: Stone, Zombie, Poison, Aging, Berserk.  Similarly, once a glow effect is set, the function skips to the end.  In order: Wall, Armor, Shell, Stop, Haste, Slow.  There's no reason multiple palette changes couldn't be applied with simple code changes, and some relatively simple coding could even allow multiple glow colors.

Palette information is stored at 7E/7F89,Y for each character, and is 0x20 bytes long (16 2-byte values).  Note that "glow" effects are really just changing the palette outline (at 7F8B) in a simple on/off manner.  I have a basic list of what each 16-bit value controls, but not with me: I'll update this post when I can grab the notebook.

[EDIT]My list isn't as detailed as I thought it was, but for the sake of reference:
Code: [Select]
7F8B: Outline (ie Glow)
7F8F: Eyes
7F91: Skin A (see Berserk/Zombie)
7F93: Hair A (see Old)
7F99: Skin B
7F9B: Hair B (shadow)
7F9D: Hair C (highlight)

3
This is a minor bit of information that anyone modding spells will find useful.  Again, this was just sitting around, and I figured I should share it.

The determination of what spells can be used in battle is performed whenever the equipped commands change.  This code can be found at C2/E6E0, and is relatively straight-forward.  The code loops over the character's equipped abilities, sets the level for each magic type, and then saves this data in three bytes per character (see below).  There is special handling for Red and X-Magic that sets both the White and Black magic levels.  This data is saved to 7E/053D-3F and copied to 7E/203D-3F for use in battle.

Code: [Select]
7E053D XX          1st Player Sword/White Display                                     
7E053E XX          1st Player Black/Dimen Display                                     
7E053F XX          1st Player Summon/Misc Display
(Layout borrowed from samurai goroh's FFV document)

This data is further parsed in battle menus at a beefy bit of code that starts (I think) at C2/4287.  I haven't quite deciphered it yet, but the basic mechanism of action is that the spell level (7E/203D-F) and learned spells (7E/0950) mask the spells you can't cast.

The determination of what spells can be used out of battle is contained in a three byte lookup table starting at C0/EEF4.  I have not verified everything, but the data format appears to be as follows: Spell Number/Index, Magic Type, Row * 3.  I do not know if the second and third bytes actually perform any function.  It's very simple: if the Spell Number is in this list, it can be cast outside of battle.

4
As an example of the control data, I've included the control data for the item menu below, with the instruction types and enumeration indicated in parenthesis.

Code: [Select]
C3/A73C (Item Menu Controls)
-----------------------
(Data Length)
18 01

(Use/Sort/Rare)
(00) 0F 01 40 10 00 00 00 02
(01) 0F 02 58 10 01 01 00 02
(02) 0F 03 70 10 02 02 00 03
(03) 0F 04 A8 10 03 03 02 03

(Item List)
(04) 10 01 08 4E 1A 06 20 05
(05) 10 02 78 4E 1A 07 04 06
(06) 10 03 08 5A 04 08 05 07
(07) 10 04 78 5A 05 09 06 08
(08) 10 05 08 66 06 0A 07 09
(09) 10 06 78 66 07 0B 08 0A
(0A) 10 07 08 72 08 0C 09 0B
(0B) 10 08 78 72 09 0D 0A 0C
(0C) 10 09 08 7E 0A 0E 0B 0D
(0D) 10 0A 78 7E 0B 0F 0C 0E
(0E) 10 0B 08 8A 0C 10 0D 0F
(0F) 10 0C 78 8A 0D 11 0E 10
(10) 10 0D 08 96 0E 12 0F 11
(11) 10 0E 78 96 0F 13 10 12
(12) 10 0F 08 A2 10 14 11 13
(13) 10 10 78 A2 11 15 12 14
(14) 10 11 08 AE 12 16 13 15
(15) 10 12 78 AE 13 17 14 16
(16) 10 13 08 BA 14 18 15 17
(17) 10 14 78 BA 15 19 16 18
(18) 10 15 08 C6 16 1B 17 19
(19) 10 16 78 C6 17 1B 18 21

(Scroll Up/Down)
(1A) 86 02 00 00 00 00 00 00
(1B) 86 01 00 00 00 00 00 00

(Submenu - Player Select)
(1C) 1E 01 08 60 1F 1D 1C 1C
(1D) 1E 02 08 80 1C 1E 1D 1D
(1E) 1E 03 08 A0 1D 1F 1E 1E
(1F) 1E 04 08 C0 1E 1C 1F 1F

(Scroll Right/Left)
(20) 86 04 00 00 00 00 00 00
(21) 86 03 00 00 00 00 00 00

(Unknown)
(22) 24 01 00 00 22 22 22 22

5
Hey everyone.  I have a bunch of stuff that I've researched to varying degrees that I wanted to share.  Most of it is minor but useful stuff.  However, I wanted to share my research on the FF5 menus with everyone.  I haven't seen this info readily available anywhere, although I'm sure it's been looked into before.  It's not complete by any means, but it's been sitting around for a month or two without being worked on.

Menu drawing seems to start at subroutine C2/C16A.  The chosen menu ID (MID) is one byte stored in $43.  The enumeration of menus starts at 01, not 00.  The values range from 01 to 0D; no sanity checks are run on the value, so you can crash the game changing it.  The MID is used as the index for a lookup table at C0/F5E7, which gets the address for a MVN for the menu data.  The menu data is a set of twelve addresses stored at C0/F601, grouped into three sets of four.  I've provided this data below.  Each group of three uses a separate function, as indicated in the column headers.  The numbers in the header indicate the destination in RAM (bank 7E) where the data is written to.

Code: [Select]
         | Fxn C2/C1B8         | Fxn C2/C1F7         | Fxn C2/C1A6
         | 2000 3000 4000 5000 | 7000 7080 7100 7180 | 7200 7280 7600 7500 
Menu ID  | BG1  BG2  BG3  BG4  | ???  ???  ???  ???  | Msk1 Msk2 Ctrl Sett   
--------------------------------------------------------------------------
01 Main  | 0000 0000 AD3F AD65 | 0000 0000 B816 B822 | AC86 AC98 A300 ABBA
02 Abil  | 0000 ADE3 ADF4 AE5E | 0000 B82C B82F B84F | ACCE 0000 A382 ABCB
03 Job   | 0000 0000 AEEA AF0F | 0000 0000 B85C B862 | 0000 0000 A434 ABDC
04 Equip | 0000 AF3C AF4D B02B | 0000 B868 B87A B88C | ACDA 0000 A4EE ABED
05 Stats | 0000 0000 B095 B0D3 | 0000 0000 B89A B8A0 | ACE6 0000 A598 ABFE
06 Store | 0000 B19F B1EB B237 | 0000 B8B0 B8BB B8D1 | ACF2 0000 A5A2 AC0F
07 Item  | 0000 0000 B363 B3B7 | 0000 0000 B8C9 B8D1 | ACF2 AD01 A73C AC20
08 Magic | 0000 0000 B3D6 B3F3 | 0000 0000 B8E0 B8E6 | 0000 0000 A856 AC31
09 Confg | 0000 0000 B66E 0000 | 0000 0000 B93E 0000 | 0000 0000 AA38 AC75
0A Find  | 0000 0000 B636 0000 | 0000 0000 B919 0000 | 0000 0000 AA26 AC64
0B Save  | 0000 B536 AD3F 0000 | 0000 B8FD B816 B905 | AD1F 0000 A978 AC42
0C Load  | 0000 B56A AD3F 0000 | 0000 B8FD B816 B905 | AD1F 0000 A9AA AC42
0D Name  | 0000 0000 B5F5 B620 | 0000 0000 B90F 0000 | AD10 0000 A9E4 AC53

Each address is a location in the C3 bank that indicates the data to get for use in the functions.  A value of 0000 indicates no data; this iteration of the function will be skipped.

The first set of four draws the actual windows to the background layers.  The data is a list of instructions on how to draw the menu windows.  The data format is one byte for the instruction with a number of parameter bytes following, depending on the instruction.  The lookup for number of bytes per instruction is located at C3/AD31.  There are 7 instructions, 00 through 06.  I don't know the exact differences between some instructions, but a rough guide:

Code: [Select]
00 | End of Inst. List  | 0b |
01 | Fill Current Layer | 2b | Char#, Color
02 | Draw Box           | 6b | Char#, Color, X, Y, Width, Height
03 | Draw Bordered Box  | 6b | Char#, Color, X, Y, Width, Height
04 | Draw Text          | 5b | String#, Color, X, Y, Removed (Note: Color non-functional)
05 | Change Layer       | 2b |
06 | Draw Indented Box  | 6b | Char#, Color, X, Y, Width, Height (Calls 03/02)

The second set of four I have not as of yet decoded.  The data is parsed into what seems like a longer instruction set, but I have not discovered how it works.

The third set of four control, in order, window masks one and two, menu control, and window mask settings.  See Anomie's register doc for information on the window masks.

The interesting bit is the presumptive cursor control and selection handling.  There is a two byte header indicating the length in bytes of the data set, followed by a set of eight byte instructions.  Each instruction has the following format (based on the item menu):

Code: [Select]
00 | Instruction Type
01 | Instruction Parameter
02 | Cursor Position X
03 | Cursor Position Y
04 | Up Button Parameter
05 | Down Button Parameter
06 | Left Button Parameter
07 | Right Button Parameter

The instruction set is implicitly enumerated (ie, order matters).  The Up/Down/Left/Right parameters go to the indicated instruction.  Cursor position is self-explanatory.  The instruction type and parameter indicate what to do.  In the case of a cursor selection, it indicates what to do when the accept button is pressed.  In the case of a special instruction (for example, scrolling the menu up/down), it indicates a passed parameter.

6
Final Fantasy V Research & Development / Re: A question about Job editting
« on: November 21, 2012, 02:23:52 PM »
No problem!  Actually, posting got me looking at some of my work (on expanding abilities and some other stuff) again.  Of course, in a week I'm going to be moving roughly 2700 miles to a new place.  Needless to say that's impacting my productivity.   :sad:

The Ability Expansion project has (thus far) three major components aside from general design (via expanded ROM space).  The first was to create more space for ability coding.  I don't have time to type up the full details at the moment, but the basic method was to cut/paste/re-reference essential functions into expanded ROM.  The second was to modify the animation code in C1 to allow a broader range of inputs (utilizing a lookup table based on input).  The third part was modifying the item system to create more RAM; this is basically where I was at before I stopped. 

As a side project stemming from this, I was investigating the window system.  I believe that any serious expansion (especially creating more jobs) would have to alter the menus, requiring hacking the menu system.  It's this area I've managed a couple of breakthroughs.  In retrospect I got overly focused one component, and essentially missed the forest for the trees.  It's still a work in progress, but I can at least alter window layout and rudimentary cursor behavior.  The relevant code starts at C2/C16A and most of the data is in C3.

7
Final Fantasy V Research & Development / Re: A question about Job editting
« on: November 12, 2012, 05:51:50 PM »
Sorry for the thread necromancy.

Adding additional sprites, while not trivial and would require ROM expansion, is relatively straightforward.  IMO the cleanest way to do it would be to move *all* sprite data to an expanded section and then change all the references in the code to point to the new section.  You'd also need to change the references to the number of jobs.  In fact, this approach also works well for job data, although there's more buffer room to play around with there.

The actual hard part is finding the bytes in RAM to save any additional job/ability data.  There's almost no free space in the RAM area to manage it.  Keep in mind that many areas of RAM function as temp storage, especially for battles, and get overwritten.  I was working on a couple of workarounds before life got in the way and I lost most of my free time (also why I've been absent).

The saved data for jobs/abilities is really only accessed in one place - loading the menu (ie, changing jobs/abilities).  The known abilities are essentially a function of the job/ABP combo; if you have 30 ABP in Black Mage, you know the character knows !Black L1 and L2.  Therefore, one idea I toyed with was coding a function in ROM that took the job/ABP data as an input and reconstructed the full list of known abilities in RAM used for temp battle space.  That reduces the amount of space needed in RAM for each character by 34*4 = 136 bytes (+4 if you remove the # abilities variable).  The downside to this approach is that it would require a non-trivial amount of non-trivial assembly coding.

Another approach I looked at (and favored) was reducing the number of item slots.  Item data in the RAM is right next to the job/ability data, so the resulting changes would be cleaner.  There are 256 item slots, each of which takes up two bytes (ID, quantity).  Halving the number of item slots frees up 256 bytes in RAM, more than enough for storage purposes!  The downside to this approach is that you have to change all of the references the item system, which is not an insignificant undertaking.

8
Pandora's Box / Re: Issue With Patching, Could Use Some Help
« on: October 13, 2011, 09:48:36 PM »
Thanks to everyone for the help.  It was a stupid assumption/misunderstanding on my part.  I assuming since the MD5 hash matched, that the ROM I was using did not have a header.  That was not the case, and removing the header with NRST fixed the issue.  Good call Deathlike2 and Imzogelmo, and thanks for bearing with me.

9
Pandora's Box / Re: Issue With Patching, Could Use Some Help
« on: October 13, 2011, 03:05:31 PM »
Do we have the CDC32/MD5 of the correct ROM?  I was going off the values in the readme (which match the ROM I have), but I suppose I can try some other ROMs later tonight.  I'll post the info if I find one that works.

10
Pandora's Box / Issue With Patching, Could Use Some Help
« on: October 13, 2011, 12:47:39 AM »
I was hoping to try PB, but I can't get xdelta to patch the game.  I've confirmed with NRST and the readme file that I have the correct ROM - both the CDC32 and MD5 match.  I downloaded the 2b patch from the website.  When I run either xdelta program listed in the readme, it gives me the following error: xdelta3: target window checksum mismatch: XD3_INVALID_INPUT.  I don't have much experience with the XDelta format, but I'm assuming this means the ROM is incorrect?  Any advice would be welcome, as I'm eager to see what's been done.

11
Final Fantasy V Research & Development / Re: Replacing Command Abilities
« on: December 24, 2010, 10:02:17 PM »
Complex Example 1: Dragon Sword

Pray is pretty much the most simple example you can get.  Let's look at something a little more in depth: Dragon Sword.

Let's look at the Effect Code for Dragon Sword:
Code: [Select]
C2/0AA4: 20 5F 17     JSR $175F
C2/0AA7: 20 FE 4A     JSR $4AFE
C2/0AAA: 20 A9 02     JSR $02A9
C2/0AAD: 20 C2 02     JSR $02C2
C2/0AB0: A9 0E        LDA #$0E
C2/0AB2: 20 FA 16     JSR $16FA   Queue Banner
C2/0AB5: A9 0D        LDA #$0D
C2/0AB7: 20 E1 16     JSR $16E1   Queue Ability Animation
C2/0ABA: 20 23 99     JSR $9923
C2/0ABD: A9 71        LDA #$71
C2/0ABF: 20 24 03     JSR $0324   Load Spell Parameters
C2/0AC2: 20 05 17     JSR $1705
C2/0AC5: 20 35 17     JSR $1735   Increment Effect Counter
C2/0AC8: 20 E3 98     JSR $98E3
C2/0ACB: 20 23 99     JSR $9923
C2/0ACE: A9 72        LDA #$72
C2/0AD0: 20 24 03     JSR $0324   Load Spell Parameters
C2/0AD3: 20 05 17     JSR $1705
C2/0AD6: 20 35 17     JSR $1735   Increment Effect Counter
C2/0AD9: 4C E3 98     JMP $98E3

The basics are the same as Pray, but we're actually running TWO spells.  At this point, it should be obvious why some ability commands are basically "empty."  We're actually going to call two spells - one for the HP Drain, and another for the MP Drain.  Obviously we can't do that with one ability data entry.  In fact, in this example the ONLY thing the ability data controls is targeting. 

What about the animation though?  Hopefully the reason we didn't change the input for Psych's QAA is a little more evident now.  Let's look at the animation code:

Code: [Select]
C1/98DF 20 93 9D    JSR $9D93
C1/98E2 A9 0B       LDA #$0B
C1/98E4 20 EC 96    JSR $96EC
C1/98E7 A2 09 01    LDX #$0109   Anim: DSword Dragon
C1/98EA 20 9C B6    JSR $B69C    Run Animation (#109)
C1/98ED A2 0C 01    LDX #$010C   Anim: Dsword Slash
C1/98F0 20 9C B6    JSR $B69C    Run Animation (#10C)
C1/98F3 7B          TDC       
C1/98F4 4C EC 96    JMP $96EC

So not only do we use the effect code to run two effects, we use the animation code to play two animations!

Now it should be apparent why the effect code and animation code matter; we can do more complex stuff that isn't possible with data alteration alone.



Complex Example 2: Item/Salve

Suppose we want an ability, Salve, that allows you to use one item and have it effect all targets (ala Wild Arms).  You can take a look at the Item code starting at C2/0570.  It's quite a bit more complex than either Pray or Dragon Sword.  In fact, it's more complex than many commands in the game.  Luckily, we can cheat a little bit.  There's not a lot of real estate in the C2 bank.  There's some coding work-arounds you can use to free up some, but that's beyond the scope of this post.  Since I hate the Mix command, I'm just going to use its code-space for my Salve command.  Your mileage may vary.

The start of the Item command goes like this:
Code: [Select]
C2/0570: 9C 62 7C     STZ $7C62
C2/0573: 20 23 99     JSR $9923   Get Next Effect Parameter Offset
C2/0576: 20 5F 17     JSR $175F   Get Selection
C2/0579: A6 32        LDX $32

Get Selection does what you'd think it does - it gets the information on the targets.  Instead of altering all the code, what we'll do is copy the first three commands to where Mix is, add our code afterward, and jump back to C2/0579.  As it turns out, the targeting for allies is stored in bytes 4-7 of $66.  So we'll add in our code:

Code: [Select]
C2/1125: 9C 62 7C     STZ $7C62
C2/1128: 20 23 99     JSR $9923   Get Next Effect Parameter Offset
C2/112B: 20 5F 17     JSR $175F   Get Selection
C2/112E: A9 F0        LDA #$F0
C2/1130: 85 66        STA $66
C2/1132: 4C 79 05     JMP $0579

Go ahead and add the ability using the steps above, and try it out.  Sure enough, when you use the command, the item is used on all of your allies.  We're piggy-backing on the Item command to make an "enhanced" function.  Something like this simply isn't possible with data tables alone; you need to get into the code.

12
Final Fantasy V Research & Development / Replacing Command Abilities
« on: December 24, 2010, 09:59:54 PM »
(Merry Christmas!)

There are up to six things we have to do in order to replace an ability with a new one:

1) Spell Entry
2) Animation Entry
3) Effect Code (in C2)
4) Animation Code (in C1)
5) Text
6) Job Info

As an example, I will be replacing the command "Pray" with "Psych" and giving it to a Black Mage at JLvl 4.  For simplicity, the ability will function almost exactly like the spell.  The one change will be the MP cost, which will be 0.

Note: I'll be assuming people reading this will be familiar with the basics of the data format.  All that information is on the site here.  Please feel free to share this information.

1) Spell Entry

Many abilities in the game are actually spells that are called via code (see Part 3).  In fact, the code interpreting these is for all intents and purposes identical.  We could simply copy the spell data for Psych to the ability data for Pray, change the MP cost, and skip straight to editing text.  In fact, for this simple change, that's pretty much what we're going to do.  That won't always be the case, as I'll demonstrate with a subsequent example.

So, copy the Psych data to D1/5AE8 (where the Pray ability is located), and change the MP to 0.  Easy!  You'll want to note the ability offset as well, which is 21.

2) Animation Entry

We don't just want our Psych ability to act like Psych, we want it to look like it as well.  Luckily, we're using an animation that already exists, so we don't actually have to do much here.  However, if you wanted to add a new animation, you could do so by editing the animation data table.

We do want to know the offset of our animation though; it's 35.

3) Effect Code

All abilities call a snippet of code that sets up the animation and effect.  This uses indirect addressing; there's a lookup table at C2/4A92 that is a list of addresses.  This maps to the list of command abilities, with one big caveat: subtract one from the ability number to get the offset.  I don't know why they skip ability number 00 (Nothing), but it does.  So, Pray is ability number 21, so we want entry 0x20.  Our Pray code is at C2/1169.  NOTE: If you have InstructrTrepe's function offset list, several of the addresses for the commands are wrong.  I've verified this in code and with breakpoints.  Use the lookup table to be certain.

Here's our Pray code.  I've noted the functions of each subroutine.
Code: [Select]
C2/1169: A9 21        LDA #$21
C2/116B: 20 AA 16     JSR $16AA   Load Ability Parameters
C2/116E: 20 5F 17     JSR $175F   Get Selection
C2/1171: 20 A9 02     JSR $02A9   Separate Enemy/Ally Targets
C2/1174: 20 C2 02     JSR $02C2   Count Targets
C2/1177: A9 21        LDA #$21
C2/1179: 20 FA 16     JSR $16FA   Queue Banner
C2/117C: A9 20        LDA #$20
C2/117E: 20 E1 16     JSR $16E1   Queue Ability Animation
C2/1181: 20 1A 17     JSR $171A   Get Attack Type
C2/1184: 20 35 17     JSR $1735   Increment Effect Counter
C2/1187: 4C E3 98     JMP $98E3   Run Effect

As you can see, there are three functions that take a parameter (16AA, 16FA, 16E1).  We don't need to change the ability or the banner.  Now, you may be thinking we need to change the input for Queue Ability Animation.  It makes sense, right?  Unfortunately, it's also incorrect.  We'll leave it at #20.

4) Animation Code

So why exactly did we leave the input for QAA at #20?  The detailed answer is a little complex, and not strictly necessary to understand for this basic example.  However, that parameter actually indicates the value for a lookup table at C1/8D88, which leads to the following code:
Code: [Select]
C1/9909 20 93 9D    JSR $9D93   
C1/990C A9 0B       LDA #$0B
C1/990E 20 EC 96    JSR $96EC
C1/9911 A2 D8 00    LDX #$00D8 Anim: Pray
C1/9914 20 9C B6    JSR $B69C Run Animation
C1/9917 7B          TDC       
C1/9918 4C EC 96    JMP $96EC    Continue Animations

The important lines are the LDX and subroutine $B69C.  All abilities call bits of code like this, which are animation handlers.  For Pray, this is pretty simple.  Go ahead and change that #00D8 to #0035.

5) Text

This is relatively straight-forward.  Change the ability name at E0/1237; this also changes the text for the menu and the banner.  Change the description at D1/776A, but make sure to keep it at 24 bytes (use padding if needed).  The lookup table for description addresses starts at D1/716C.

If you went on to Part 6, then pulled up the menu, you'd notice that the job level information is still indicating Chemist L4.  Interestingly, this is not text, but a byte value that indicates job and level.  This data is located at C0/F739, and uses the same ability offset.  Bytes 0-4 indicate the job number, and bytes 5-7 indicate the level.  So we go to offset 21 at C0/F75A, which is currently set at #90.  Parsing that code, it's job number 10 (Chemist) and level 4.  We're going to change that to 8A (job A, level 4).

6) Job Info

If you've made it this far, you shouldn't have a problem with this next part.  Calculate or lookup the offset for the job info table (38), go to the data, and change the learned ability to #21.  Now you're ready to go!

13
Final Fantasy V Research & Development / Re: Spell Animation Guide v0.85
« on: December 01, 2010, 06:51:03 PM »
While the first post is (IMO) a good intro to how to go about with hacking the game, a lot of the information in the original post was incorrect.  I've quoted some sections below for posterity.

Quote
I've made some significant breakthroughs with understanding how magic graphics work.  I'll be posting a more detailed breakdown when I finish everything up, but I thought this was important to share.

How does FF5 decide what magic animations to display?  Logic would dictate it's linked to the Spell Number (S#), which can be found in Jorgur's Hacking Guide here on the site.  As it turns out, this is indeed the case.  It also makes sense that it'd be some sort of lookup table, and this is also the case.

I started my search by tracing a variable I came across during my examinations of C1 Fxn A; $2722.  This variable, during the magic routine, holds S# ($2723 holds the Effect Number).  It's important to note $2722 is not dedicated; this variable holds other animation values when not being used by the magic system.  I followed this value backwards to the menu selection and forwards to a function around C1/A847, which led me to the lookup table for spell animations.

The table starts at D8/38EC, and each set of data is five bytes:

Code: [Select]
00 10 19 00 0c Fire
17 12 21 00 0d Ice
09 11 e4 00 0e Bolt
21 18 0f 00 0f Venom
21 19 0f 00 0f Sleep
21 17 0f 00 33 Toad
01 10 1a 00 19 Fire 2
17 12 6f 0d 1c Ice 2
09 11 e5 00 0e Bolt 2
05 10 1c 8e 1b Drain
2b 24 24 00 47 Break
11 15 20 00 10 Bio
04 10 1b 80 36 Fire 3
14 12 23 00 11 Ice 3
09 11 e6 00 0e Bolt 3
05 10 1d 88 1d Flare
0d 13 1f 00 1a Doom
05 12 1c 8e 1b Psych

As I mentioned, for the first 256 data sets, this follows the S# from the Hacking Guide.  There are some groups that get special handling; Sword Magic and Summons being the main two.

After this, there's a set of seven animations, 100h through 106h, for the casting animation.  That is, the burst for Black, the sparkles for White, and so on.  This is calculated from the S#, starting at C1/B54D; it's relatively straight-forward.  Otherwise, these act just like other animations; you can change any of the five bytes.  For example, setting the data at 102h (Black) from 1C 28 02 80 48 to 1C (10) 02 80 48 will make the burst red.  Changing it to (42) 28 (00) 80 48 will give it the Sword Magic animation.

This should provide an excellent start for people looking to play around with the magic system.  I hope to have a full catalog of the data up soon; I will post it when done.

14
Final Fantasy V Research & Development / Re: Spell Animation Guide v0.8
« on: November 14, 2010, 10:54:36 AM »
Yeah, no problem!

15
Final Fantasy V Research & Development / Re: FFV Sprite editing
« on: November 13, 2010, 09:55:31 PM »
Good to know!

There's a single call to C3/0002 in the bank that controls combat animations (at C1/FB9A).  I know the magic sprites start at D9/0000, and while I know how to get there from the code, I haven't delved much into the decompression.  It looked like it was 3bpp, but I don't know anything other than that.

One step closer to being able to add in our own sprites  Thanks for the info!

Pages: 1 2 3 »