Chrono Trigger Sprite Insertion -- Development of a Guide

[FaustWolf]

We'll have a nice illustrated guide for sprite insertion sometime after Crimson Echoes is released. The goal of Kajar Labs' efforts is to make the ROM completely mod-able.

[Mauron]

I've started working on the size 1 PC sprite patch again. Right now I'm having trouble testing it.

Where is the frame has Crono facing the player on the menu?

Edit: I've modified the sprite movement command to work with the new size. This one requires some testing as well.

[FaustWolf]

I think Standing-Down is the third frame in sprite assembly if I'm remembering what Vehek told me correctly. Do you need to know where the sprite assembly frames are, or where the animation data is? I think I can find that pretty quickly.

As far as testing is concerned, I could probably whip up some appropriate sprites to replace Crono with, or if you have a patch I can try applying it to my old Crono-to-Slash ROM and see if things check out.

So, will using Size 1 player characters tend to leave less room in VRAM for enemy and NPC sprites?

[Mauron]

Could you upload the Crono-to-Slash patch you had so far? I haven't completely rewritten the routines yet, just adjusted how much data is copied.

I haven't had the chance to do enough testing, but there *may* be enough space to do this without a problem.

[FaustWolf]

Here's a patch and a savestate just before recruiting Marle, so you can test out what's going on in realtime. Slash's palette's a bit out of whack right now, which is unimportant. The first player character's sprite size has been set to 0x01 in this patch, but I haven't applied the patch you made earlier to make the game read proper sprite size value for PCs in battle.

[Mauron]

I'm having a hard time understanding how VRAM and DMA work. x_x

Anything I've tried to change screws it up in noticeable ways. >_<

[FaustWolf]

There's some docs on SNES DMA over at romhacking.net, and I could probably fish up some documentation on VRAM from elsewhere.

From what I can tell, the problem right now is that there just isn't enough space allotted in VRAM for player characters to be Size 1 sprites, like there must be some command in the game engine to write player character tiles to a certain address in VRAM, and the total space allotted per character is 4 tiles. We'd have to find some way of telling the game engine to write to different addresses in VRAM when player character sprites are called up, forcing it to allocate to 8 tiles' worth of space per player character.

However, it seems like that solution would eat up a lot of VRAM, leaving less room for environment tiles and enemy/NPC sprites. That's my rudimentary understanding anyway.

Have you had an opportunity to look at the VRAM firsthand? I can do some VRAM dumps to help visualize what's going on in memory when Slash is in the party, if that would help at all.

[Mauron]

I could use whatever you have available on VRAM. I'm starting to understand how DMA works, but I don't have as much of a handle on VRAM. Some dumps would definitely be helpful, especially if there's a way to find any chunks of empty space.

Edit: How much memory does the size 1 sprite use for its graphics?

Edit 2: It uses 80 decimal bytes. Now I need to know how many size 0 uses.

Edit 3: I've been playing around with breakpoints, and it seems there will be plenty of room for the size 1 sprites.

DMA[7]: write Mode: 1 0x7F3800->0x2118 Bytes: 256 (inc) V-Line:233 VRAM: 1800 (1,0) word
$C0/B1E6   8D 0B 42   STA $420B  [$00:420B]   A:0980   X:0000   Y:0100   D:0900   DB:00   S:06EE   P:eNvMxdIzC   HC:0140   VC:233   00   FL:65379
DMA[7]: write Mode: 1 0x7F3800->0x2118 Bytes: 256 (inc) V-Line:233 VRAM: 1880 (1,0) word
$C0/B1E6   8D 0B 42   STA $420B  [$00:420B]   A:0980   X:0000   Y:0100   D:0900   DB:00   S:06EE   P:eNvMxdIzC   HC:0140   VC:233   00   FL:65379

Those are from Crono's mom and cat.

DMA[7]: write Mode: 1 0x7F3800->0x2118 Bytes: 512 (inc) V-Line:233 VRAM: 0080 (1,0) word
$C0/B1E6   8D 0B 42   STA $420B  [$00:420B]   A:0980   X:0000   Y:0200   D:0900   DB:00   S:06EE   P:eNvMxdIzC   HC:0140   VC:233   00   FL:65376
DMA[7]: write Mode: 1 0x7F3800->0x2118 Bytes: 256 (inc) V-Line:233 VRAM: 0200 (1,0) word
$C0/B1E6   8D 0B 42   STA $420B  [$00:420B]   A:0980   X:0000   Y:0100   D:0900   DB:00   S:06EE   P:eNvMxdIzC   HC:0140   VC:233   00   FL:65376

Note the difference in VRAM addresses.

$C0/CCA3 loads $100 into the accumulator. It does this when both PCs and NPCs move.

[Vehek]

I'm not sure if that's right. Have you tried looking at savestates with vSNES?

[Mauron]

A little, but I didn't fully understand the program. How can I match sprites to VRAM locations in it?

[FaustWolf]

I'll grab some VRAM dumps and visualizations from vSNES for ya, comparing Crono's allocation with Slash's. Also, vSNES can be found here.
http://www.romhacking.net/utils/274/

Romhacking.net doesn't seem to have any documentation on SNES VRAM, only Gameboy Advance. There's some on the web scattered around, which I'll accumulate here as I find them.
http://emu-docs.org/Super%20NES/General/snesdoc.html

[FaustWolf]

Here's a few examples showing how things are stored in VRAM in comparative situations. I'm still not sure how to get the starting addresses of specific tiles yet. I can ask the creator of vSNES if necessary.

Here's what an orderly one-person party looks like. I'm actually surprised that the game engine wrote some overworld graphics in the space that should be allocated to player characters as shown in the next VRAM visualization.


Here's a multiple person party. The player characters seem to be stored one right after the other, with a little over one "row" of VRAM space allocated to the party.


Here's a one-person party consisting of a single Size 1 sprite. Notice that the hand/pointer sprite is messed up there, and Slash is all spread out. I think the Size 1 specification in the sprite header is allotting 8 tiles' worth of room for Slash, basically the whole row. When the game engine calls the hand/pointer graphic, it doesn't know to write it in unused space, instead trying to put it where it normally would.

[Vehek]

I've found how it determines where to place enemy graphics in VRAM.

(Very simplified description):
1. It takes the enemy parameter and adds one to it.
2. The new number is ANDed with 0xFE (so if the old number was even, it returns to its previous value)
3. The result is multiplied by 0x10.
4. If the enemy parameter was originally even, then 0x8 will be added.

The resulting number placed at D00,x is eventually ANDed with 0x1FF, multiplied by 0x10, and used as the VRAM address.

Here's an example with Gato:

Code: [Select]

$C0/4799 A6 C7       LDX $C7    [$00:01C7]   A:AC80 X:0000 Y:0173 P:envMxdIzC
$C0/479B BF 01 20 7F LDA $7F2001,x[$7F:21E1] A:AC80 X:01E0 Y:0173 P:envMxdIzC //The enemy parameter
$C0/479F 85 E1       STA $E1    [$00:01E1]   A:AC86 X:01E0 Y:0173 P:eNvMxdIzC
$C0/47A1 29 7F       AND #$7F                A:AC86 X:01E0 Y:0173 P:eNvMxdIzC
$C0/47A3 1A          INC A                   A:AC06 X:01E0 Y:0173 P:envMxdIzC
$C0/47A4 E2 10       SEP #$10                A:AC07 X:01E0 Y:0173 P:envMxdIzC
$C0/47A6 AA          TAX                     A:AC07 X:00E0 Y:0073 P:envMXdIzC
$C0/47A7 A5 6D       LDA $6D    [$00:016D]   A:AC07 X:0007 Y:0073 P:envMXdIzC
$C0/47A9 9D 88 0B    STA $0B88,x[$00:0B8F]   A:AC10 X:0007 Y:0073 P:envMXdIzC
$C0/47AC 8A          TXA                     A:AC10 X:0007 Y:0073 P:envMXdIzC
$C0/47AD C2 20       REP #$20                A:AC07 X:0007 Y:0073 P:envMXdIzC
$C0/47AF 29 FE 00    AND #$00FE              A:AC07 X:0007 Y:0073 P:envmXdIzC
$C0/47B2 0A          ASL A                   A:0006 X:0007 Y:0073 P:envmXdIzC
$C0/47B3 0A          ASL A                   A:000C X:0007 Y:0073 P:envmXdIzc
$C0/47B4 0A          ASL A                   A:0018 X:0007 Y:0073 P:envmXdIzc
$C0/47B5 0A          ASL A                   A:0030 X:0007 Y:0073 P:envmXdIzc
$C0/47B6 85 D9       STA $D9    [$00:01D9]   A:0060 X:0007 Y:0073 P:envmXdIzc
$C0/47B8 8A          TXA                     A:0060 X:0007 Y:0073 P:envmXdIzc
$C0/47B9 29 01 00    AND #$0001              A:0007 X:0007 Y:0073 P:envmXdIzc
$C0/47BC 0A          ASL A                   A:0001 X:0007 Y:0073 P:envmXdIzc
$C0/47BD 0A          ASL A                   A:0002 X:0007 Y:0073 P:envmXdIzc
$C0/47BE 0A          ASL A                   A:0004 X:0007 Y:0073 P:envmXdIzc
$C0/47BF 18          CLC                     A:0008 X:0007 Y:0073 P:envmXdIzc
$C0/47C0 65 D9       ADC $D9    [$00:01D9]   A:0008 X:0007 Y:0073 P:envmXdIzc
$C0/47C2 86 D9       STX $D9    [$00:01D9]   A:0068 X:0007 Y:0073 P:envmXdIzc
$C0/47C4 A6 6D       LDX $6D    [$00:016D]   A:0068 X:0007 Y:0073 P:envmXdIzc
$C0/47C6 9D 00 0D    STA $0D00,x[$00:0D10]   A:0068 X:0010 Y:0073 P:envmXdIzc
Edit-I need some time to determine how it places the graphics in different spots because of party members.
Edit 2: It probably doesn't. I got confused because the VRAM addresses weren't the same as the place the graphics appeared.

[Vehek]

Values loaded into 7E0D00,x for PCs.

Code: [Select]

$C0/42C9 A9 08 00    LDA #$0008
$C0/433E A9 20 00    LDA #$0020
$C0/43F1 A9 28 00    LDA #$0028
The game keeps the data it copies into OAM at 7E0700.

Changing these values stored to D00,x hasn't helped so far. A size 1 PC sprite still grabs other PC graphics, even when they're far apart in VRAM.

[FaustWolf]

Vehek, I'm curious to know whether the game even loads all the PC character graphics into VRAM when you've changed that code. Originally, it doesn't -- Slash's feet are missing here with a party of Slash and Marle, for example. What you guys have done so far might still be a step in the right direction.