Chrono Trigger Sprite Insertion -- Development of a Guide

[FaustWolf]

Aaack, I'm now lightyears behind on all the developments that have taken place in this beautiful laboratory. Today I took some time off the campaign trail and managed to work a bit on a spreadsheet detailing where each CT sprite's graphics pack, palette, sprite assembly, and animation data are stored. E.g., let's say we want to change the Lavos Core into Weegee. First we'd need to know where in an unheadered ROM the Lavos Core graphics pack is located so that we may decompress it in Temporal Flux. Then we'd need to know where the sprite assembly data is located so that we can properly manipulate it, etc.

Geiger's NA Offsets Guide already tells us where everything is generally, and Vehek has detailed how sprite assembly and animation work in various threads. All that's needed to put CT sprite insertion capability into the hands of every fan is a step-by-step guide detailing the process. When the attached spreadsheet is finished it will serve as a supplement to such a guide, helping the user target individual sprites for alteration or replacement.

Currently the spreadsheet can be used to find a given sprite's starting offset in an unheadered ROM; sic Temporal Flux's decompression function on address 0x219995, for example, and the graphics pack for a Tyrano should pop out (requiring something like TileMolester to view it, of course). The spreadsheet also details palette locations, though the user will need to unhide columns F ~ M to match sprites to palettes.

I'm in the midst of listing indices for each sprite's assembly and animation pointer -- I'm just literally porting numbers from Chrono Tweaker into the spreadsheet's first worksheet. For example, Chrono Tweaker tells us that Belthasar's sprite gets the 15th Sprite Assembly Pointer and the 17th Animation Pointer. As per Vehek's observation, Chrono Tweaker mislabels the Sprite Assembly and Animation Pointer indices such that the numbers must be switched before they are listed in the spreadsheet. In other words, Chrono Tweaker literally reports that Belthasar gets the 15th Animation Pointer and the 17th Sprite Assembly Pointer, and I've re-interpreted Chrono Tweaker's listing to arrive at the conclusion that Belthasar gets the 15th Assembly Pointer and the 17th Animation Pointer.

So, yeah, that was all just as confusing for me to type as it was for you to read. There is a method to my madness, however, and it will all make sense in the end. I guess at this point I'm looking for help porting index numbers from Chrono Tweaker into this spreadsheet so that I can use the pointer indices to locate the offsets at which each sprite's assembly and animation data begin. This process in-and-of-itself could probably use its own mini-guide, and I'll get to it eventually, but if someone looking to get into the technical side of graphics hacking would like to fire up Chrono Tweaker and dive in, he or she would earn some cred toward an Architect of Kajar label. I think I left off about halfway through the NPC graphics listed in Chrono Tweaker. It should be noted that Chrono Tweaker requires a headered ROM, but that this will not make any difference with regard to the pointer indices. Once we get the indices ported we can use the pointers to find out where each sprite's assembly and animation data are stored. How exciting!

Psst...my heart is set on Hillary, but my money's on Biden. We'll all know Saturday.

[attachment deleted by admin]

[FaustWolf]

Okay, time to get this ball rollin' again. Attached is an updated version of the Chrono Trigger Unheadered Sprite Info Excel spreadsheet. Basically, what you can do with this document is say, "I want to replace the Blue Imp with a Koopa from Super Mario World, where do I start?" and find that a Blue Imp's graphics pack starts at address 0x180000; its palette starts at address 0x240648; its sprite assembly starts at 0x1E5078; and its animation data begin at 0x245A20. Uh, that's it so far. 

One thing I'm quite uncertain about is the size specification I've calculated for each sprite's graphics pack, assembly, animation data, etc. For one thing, according to my calculations the Mammon Machine has a graphics packet that is 0x3D bytes long, yet Crono has a graphics packet that weighs in at 0x7BC0 bytes. Granted, Crono has lots of frames and his graphics packet is uncompressed whereas the Mammon Machine has one frame and its graphics packet is compressed, but given the MM's size, it should have a waaay bigger graphics pack than that. Nevertheless, it's the best I can do given the info provided in Chrono Tweaker.

Also of import is the need to differentiate between enemies that share the same graphics pack. Imps and rollies are stored in the same graphics pack, for example. Consequently, the Imp, the Rolly, and the Rolly Rider are listed on the same line in this spreadsheet but each enemy makes use of separate sprite assembly, palettes, and animation, which muddles things up considerably. That will be addressed in future.

For now I'll forge on with the Sprite Insertion Guide. I've decided on an ambitious goal of replacing Crono with Slash -- though other sprites may need obliterated to make room for the Crono > Slash transition.

[Vehek]

but given the MM's size, it should have a waaay bigger graphics pack than that.

I haven't checked the sprite, but isn't most of it part of the background?

[FaustWolf]

That thought had crossed my mind -- maybe the MM "sprite packet" is just a weird placeholder and the MM itself is defined completely by background tiles.


WAIT

Why is it that I get a correct palette for Crono only when I specify 0x23FFFE as the starting address for the palette in TileMolester?

Blood pressure...rising. Geiger's NA Offsets Guide says that the character sprite palettes should start at address 0x240000, not at 0x23FFFE. Does not compute. Vehek, Geiger, and other hacking gods, any advice on this situation? I'll load a fresh ROM just to make sure I didn't accidently delete two bytes somewhere along the line.

[Vehek]

The "transparent" color isn't part of the palette data in the ROM. So, when you use the proper address, it puts the wrong color in the first, transparent color slot and all the colors get put in the wrong slot. (BTW, if you don't know, each color takes up two bytes.)

[FaustWolf]

Aha! I guess that explains a lot of the problems I've had with palettes thus far. Wild. My cursory investigation suggests that I can view sprites with the "correct" palette by always subtracting 0x2 from the values listed in the spreadsheet, so I guess I'll add another column entitled "correctional factor palette starting address" to account for that. Thanks!

[Geiger]

My cursory investigation suggests that I can view sprites with the "correct" palette by always subtracting 0x2 from the values listed in the spreadsheet, so I guess I'll add another column entitled "correctional factor palette starting address" to account for that. Thanks!

Well, technically, no you really should not do it that way.  The sprite palettes are assembled by the ROM, and that's the way you should do it also.  For example, the PC sprite palettes consist of the transparency color, the 12 character colors, and the 3 weapon colors.  The character and weapon colors do not reside together.  Other palettes are put together in a similar fashion.

(Also, the next release of Flux should make much of the sprite insertion process considerably easier.)

[FaustWolf]

I've put in a "correctional factor" column in the "Palettes" tab of the working spreadsheet, but I've kept the true offsets intact for completion's sake. The upshot as I understand it is, one needs to go with the true values as extrapolated from Geiger's offsets guide when editing palettes, but can use the "correctional factor" column for viewing in TileMolester. The point of subtracting two bytes from each palette's true starting offset is to throw some junk bytes into the first slot of the palette, where the phantom transparency would normally go in-game.

I'm slightly bothered by something though -- notice how in Vehek's sprite assembly tutorial example, Crono's sword is a nice bright purple, yet in my sprite sheet capture the sword is white and not quite as apparent? Vehek, did you color the weapon space in to highlight it, or am I still just slightly off with regard to character palettes?



Also, a major problem Vehek mentioned sometime ago:

Change the sprite data of a PC, and when you enter a battle, their sprite data (except for the palette) returns to normal settings.

Has there been any progress on this front?

[Vehek]

It's been a while since I made that example, but I probably used a savestate.
The sprite data thing doesn't matter much; I was referring to PC sprite data, which says what # graphics/sprite assembly/etc to load.

[FaustWolf]

Okay, that's encouraging if I understand correctly. So let me get this straight -- if I manually replace, say, Crono's graphics pack with Frog's, Crono's sprite assembly data with Frog's, Crono's palette data with Frog's, and Crono's animation data with Frog's, not only will Frog jump out of Crono's bed in the beginning of the game, but Frog will still be Frog in battle and not graphically revert back to Crono?

[Ozzie]

I think most of that data has pointers that you can simply swap (for testing purposes). Changing the pointers would be a bit easier than manually copying and overwriting all that data, eh? This wouldn't work for custom sprites and animations and all that, but a simple frog swap could mostly be done with pointer swapping I think (Crono's graphics pointer value changed to the same pointer Frog uses, Crono's animation data pointer changed to the same pointer value Frog uses, etc...)

[FaustWolf]

Right on -- what I'm wondering is, is such pointer swapping reverted in-battle somehow, or what exactly was Vehek referring to when he said that "PC sprite data" changes are undone upon battle initialization? I remember running into the difficulty Vehek described (replacing Crono with another character graphically, only to have that character become Crono once again in battle), but my experiments took place such a long time ago I'm not sure which data I was fooling around with.

I'm still extremely paranoid about the in-battle problem. But I should probably do the pointer switches as you suggest Ozzie, just to see what happens. That will resolve the issue of whether or not I should be worrying.

[Vehek]

I was talking about this:
24F000   24F022   DATA   N   PC sprite data (5 bytes each)   2004.04.01
Same format as NPC sprite data.

I'm not completely sure, but in battle, it basically loads graphics packet x for PC x, sprite assembly x for PC x, etc. (except for palette).

[FaustWolf]

Gotcha, thanks. I wonder if that data beginning at 0x24F022 may be related to the results of my pointer exchange between Magus and Crono? I manually replaced Crono's GFX pack, palette, sprite assembly, and animation pointers with Magus' values, and got this:

http://www.youtube.com/watch?v=qeCGUUHR9ro

The graphics pack and sprite assembly are spot-on, but the palette and animation data are most definitely not. When I first recorded the video I thought Magus' animation data was somehow getting straightened out over time, but turns out certain animations work better or worse depending on the direction he's facing in battle.

Interestingly, it would appear that the game is loading Magus with Crono's palette regardless of the value specified for Crono's palette pointer. I.e., change it to Magus' palette pointer value and you're getting Crono's palette; leave it the same as Crono's palette and you're getting Crono's palette.

[Vehek]

Did you read my animation data notes? The game checks the next animation data pointer to figure out how big the animation data is, and where in the animation data each direction begins.

I don't remember where right now, but in some places, the game uses palette # * 0x18 to get the palette. In some other places (I don't remember where either) it uses the pointer.