Crimson Echoes Sprite Editor Wanted

[RoxSilverFox]

I'd be happy to help with anything that doesn't require programs such as TF that only run on windows

[tushantin]

 :lol:I could help out. But unfortunately I have never done much with sprites, other than editing RO sprites. I guess I'm no help. @_@

[Agent 12]

Here is the challenge I gave the last guy that wanted to be a spriter  (He never was able to do it....).  It's a pretty simple concept, just grab the NPC baloons, replace them with ANYTHING, and put the NPC baloons back in the rom.  This is a very typical request that I would ask of a spriter for CE.

http://www.chronocompendium.com/Forums/index.php/topic,5381.0.html

I'm literally totally ignorant of what any of this sort of thing involves.  There's people in the forum that have accomplished this with relative ease but like I said in the other thread there's not really in documentation.  I have no idea what/if programs exist that are non windows to do this.

If you accomplish it you should write down what you did and share the wealth

Good luck!


--JP

[FaustWolf]

I've finally unloaded all my plot points for CC:DBT, so this a natural point to do some sprite insertion tutorial work. What the guide will need first is a list of what each enemy/NPC graphics packet is, and indexed into a list. I have to do some work tomorrow morning/early afternoon, and shall get to this late afternoon.

In the meantime, if someone happens to remember what offset in an unheadered CT ROM the pointers for compressed NPC/enemy graphics packets start, could you report that offset here? I'd be greatful. Is the stride for each pointer four bytes long?Are the bytes read in Little Endian order?

The pointer table start and stride is the most important thing here, because not only will they lead to all the packets, but the individual pointers will have to be changed because there's a good chance altered and recompressed graphics packets will be shorter/longer than the originals.

After we get the list of what all the enemy/NPC graphics packets contain, we'll need to work on including a sprite assembly tutorial and a palette changing tutorial. I'll intersperse these things with Chrono Cross hacking, so progress will be periodic.

[Vehek]

242015   2422E7   PTR   N   Pointers to npc and monster graphics   2003.07.07
Though actually, the pointers start at 242000, with the uncompressed PC graphics.
I suppose the pointers are in little endian. They're 3 bytes long.

The offsets guide lists the compressed packets, but doesn't really label any of them. It counts the first compressed packet as number 00.

Vargose made a guide about modifying graphics.
http://www.chronocompendium.com/Term/Editing_character_or_enemy_graphics.html

[FaustWolf]

Awesome, that's exactly what I was looking for. Vargose's guide is great for doing one enemy, but it would also be convenient to have all the graphics packets documented for later re-insertion targeting.

[FaustWolf]

Alrighty, with some palette recoloring, the Millennial Fair could be celebrated with Super Metroid missiles. Though at the current stage, they could be mistaken for...something else.


I can definitely write a sprite insertion guide, but it will take awhile. I've got all the graphics packs labeled but I'll need to get palette offsets and sprite assembly offsets (and the basic formula for sprite assembly data) down pat first. Can anyone tell me where sprite assembly pointers and palette pointers start offhand in an unheadered ROM, and what the stride is?

Also, it would seem that we're capable of using compressed graphics packs for the main characters. For example, I re-pointed Crono's graphics pack pointer to Dalton's and the game loads everything just fine -- with some sprite assembly and palette readjusting, it might be possible to fit in h*m*n *l*e*n via a compressed graphics pack unless Vehek knows a reason why we can't do so offhand. For one thing though, until I've figured out how to re-point the sprite assembly and palette data, I'm not sure if I'm running around as a jumbled-up Dalton or a jumbled-up compressed Dalton, meaning the game could be taking the literal compressed data and tossing it out without decompressing it, because it doesn't normally have to decompress data for a player character.

A curiosity though -- when I enter battle with Dalton's jumbled graphics pack assigned to Crono, Crono still looks normal in battle. Are the graphics packs for field exploration and battle separate?

Once I've finished listing the beginning offsets of each graphics pack I'll add what I've got so far as an attachment. Hopefully some creative Excel work can be used to do so quickly and with relatively little pain. HEX2DEC() and DEC2HEX() are lifesavers.

[Vehek]

I'm pretty sure it doesn't decompress compressed graphics for the PCs.
Did you make it load Dalton's graphics by changing the sprite data? IIRC, the game doesn't load the PC sprite data in battle.
Check the offsets guide for the offsets you want. Sprite assembly pointers are 3 bytes and palette pointers are 2 bytes.
The 2nd byte of the sprite data is the sprite assembly number.

[FaustWolf]

I tried to force the game to load Dalton's graphics pack by changing the very first graphics pack pointer, at address 0x242000 in an unheadered ROM. I had hoped that the game engine would automatically decompress when it encountered the compressed data, but that may require ASM hacking. I'll still check it out once I get all the necessary info; did Chrono Tweaker have some mistakes as far as sprite assembly is concerned, or was that another program?

So, where *does* the game pull battle sprites from?

[Agent 12]

IIRC there are definite bugs in Chrono Tweaker with the sprite assembly pointer. 

--JP

[FaustWolf]

Okay, just to make sure there's a backup of the GFX packet identification work I've done so far, I'm attaching it to this post. Palettes and sprite assembly info upcoming, provided I can figure the sprite assembly out. The final spreadsheet is intended to be used in conjunction with the guide.

[attachment deleted by admin]

[FaustWolf]

Okay, I'm going to celebrate the 4th by getting some more work done on this front. Vehek, it is my understanding that Chrono Tweaker gets things drastically wrong as far as modifying the actual sprite assembly data goes, but do you know if the indices CTweaker lists for each character's sprite assembly are correct? In other words, CTweaker is telling me that Melchior gets the 11th set of sprite assembly data. So should Melchior have the 11th sprite assembly pointer?

Also Vehek, you said earlier:

The 2nd byte of the sprite data is the sprite assembly number.

Does this mean that if I isolate a character's graphics pack and look at the hex, the second byte is the sprite assembly index that character gets? Not sure if I'm interpreting correctly.

[Vehek]

No to the first question. CTweaker (and the offsets guide) mislabels animation and sprite assembly pointers. Those labels should be switched.

On the second question, I'm talking about the sprite data that Ctweaker loads.

[FaustWolf]

Oooh, so the sprite assembly index and sprite palette index are merely switched? I.e., sprite assembly indices in CTweaker really tell which palette pointer the sprite gets, and palette indices actually tell which sprite assembly pointer the sprite gets?

[Vehek]

Sprite assembly index and animation index are switched.