I'm having some trouble with sprite editing. (Now sprite assembly)

[Mauron]

I'm working with Ozzie's sprite, and I have the graphics and palette available. The problem is I can't figure out how to work with the jumbled tiles it gives me.

What am I missing?

[Geiger]

Probably nothing.  Sprites are not typically stored as seen in game, but rather in all their component parts.

For example.

[Mauron]

Same idea, different enemy.

Is there an easy way to work with them in a way I can picture?

[FaustWolf]

There may be some logic to the way sprites are stored in Trigger (Geiger and Chickenlump would know more than I); it looks like that Nu can be pieced together row by row just about. Seiken Densetsu III tile storage is an absolute nightmare compared to this!

Mauron, a reference may be of some help with Ozzie:
http://www.chronocompendium.com/Term/Image:Ozzie_Sprites.gif.html

Also, could you post a 1:1 (normal zoom; should appear like the reference I linked to above) ratio screencap of the Ozzie tiles you have? It may be a quick job to assemble them and throw a grid over the assembled sprites so you can keep track of the tiles while you edit.

[Mauron]

That's the layout I've been given by default, and the closest thing to a sensible version of it.

[FaustWolf]

Alrighty, I believe the subtiles for Ozzie's sprite sheet are stored like so:


This grid will help you keep track of how all the subtiles are arranged in each frame as you assemble, so you can be sure to snap them back into the right places once you're finished editing. For example, it appears that one of Ozzie's frames is composed of subtiles 100, 101 to its right; 110 and 111 below those, etc. See the image attached to this post for what should be a very effective reference for the assembly. The game probably mirrors the first rectangle of subtiles (range 0x100 ~ 0x131) to make a complete sprite, so keep symmetry in mind as well.

I believe Ozzie's sprites are compressed in the ROM, correct? Keep in mind that if your edits create a net positive change in the post-compressed file size, pointers will have to be altered, and life will suck. To what extent do you plan to edit the sprite?

As far as tips for how to keep the post-compressed size as low as possible, that would depend very much on the compression method. Geiger, are these RLE compressed?

RLE = Run Length Encoding. That means if you've got a row of 100 pixels that are black, the ROM can store that as one black pixel and an instruction to make the next 99 pixels the same. So every time you interrupt a string of identical pixels, you're upping the post-compressed file size. I *think* that's how RLE works, at least.

[attachment deleted by admin]

[Mauron]

I believe Ozzie's sprites are compressed in the ROM, correct? Keep in mind that if your edits create a net positive change in the post-compressed file size, pointers will have to be altered, and life will suck. To what extent do you plan to edit the sprite?

Yeah, they're compressed.

For now I'm just playing around with this, so as long as I can interact with Ozzie, I'm good. Chances are I will screw up the pointers.

How does the game handle animations? Does it reference a series of sprites or something?

[FaustWolf]

I imagine so. I think everything necessary for Ozzie's animations is stored in the graphics packet you've decompressed, so the game would alternately call various combinations of subtiles from this graphics packet as needed. It works very differently for animations in environment tilesets from what I gather, but you should be looking at Ozzie's entire sprite sheet with all animations included.

[Vehek]

The only thing I really know about sprite animations is some very old information Chickenlump once posted at ACMLM.

It goes something like this

00 01 02 03 04 FF


00 - first frame of walking animation
01 - second frame of walking animation
02 - third frame of walking animation
etc
Terminated by FF, so between every FF is an animation sequence, from running to
unsheathing a sword.
So, if you wanted to change Crono's win animation to show Crono Laughing instead, it would be all too easy (I've done it)

The bytes used are sprite assembly bytes.

[justin3009]

How does the game handle animations? Does it reference a series of sprites or something?

- Like Vehek posted.  Each sprite frame is in a number 00 = regular stance and what not.  Each sprite frame has Sprite Assembly which is used to call each tiny grid chunk into an X/Y position. 

Don't think the grid is hard to understand.  It's split in half on the first 3 things of him, that's because they're mirrored.  Sprite assembly calls the sprites on the right side and mirrors them, thus takin less room for sprites.  It's rather simple once you start messing with them.  Smart idea to start with something small instead of diving into the PC's first.

[Mauron]

I had a feeling I'd need that sprite assembly stuff soon.

The grid is making sense to me, but I'm not clear on the rest of it. Where does the frame list go? How does it determine which number is assigned to the appropriate sprite assembly?

[FaustWolf]

The grid I threw over the graphics packet is for manual assembling purposes only, and probably doesn't refer to the actual values assigned to the subtiles within the ROM...unless we're incredibly fortunate. Just wanted to throw that out there in case you're going so in depth that you'll need subtile labels.

[JLukas]

Have a look at this older thread for more details on sprite assembly:

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

Ex: Schala sprite assembly at 1E2B48-1E2EDF
$28 bytes per frame, $17 total (23 frames)

[FaustWolf]

Judging from Vehek's first post there regarding sprite assembly, it would seem that I should revise the Ozzie sprite grid to start with 00 on the vertical axis instead of 01. If I can get confirmation on that, I'll revise and re-up. That way the grid will be in line with the subtile labels actually in the assembly section of the ROM.

[justin3009]

Yes.  The grids are usually 00 to 255 or FF in hex.  Maybe 254 in norma numbers.  Goes across so 00 01 etc