Chrono Trigger Sprite Insertion -- Development of a Guide

[Vehek]

It looks like his feet were kept. He's still fused with Marle though and the lower part of his part doesn't show up in the game.

EDIT!
 
Got it to work!
Just after the VRAM address code I posted earlier, it loads values for where to store information that will go into OAM.

Code: [Select]

$C0/42CF A9 00 00    LDA #$0000
$C0/4344 A9 20 00    LDA #$0020
$C0/43F7 A9 40 00    LDA #$0040A size 1 sprite needs 0x40 bytes of space here to work correctly.

[Mauron]

Argh, I cannot seem to find the appropriate code for handling the display in the main menu. >_<

[justin3009]

This is neat.  We essentially needed this if we wanted to put the Prophet into Prophet's Guile, so that could be a little upgrade for that

[FaustWolf]

 

Vehek, have you got a patch for this? Holy shit, holy shit, holllllyyyy shiiiiit!


So Mauron, there's separate code to load the sprites in the field, in battle, and in the menus then? Can whatever Vehek did just be replicated in various situations?

Holy crap, this happened all the way back on March 13. Sorry for missing it till now, this is huge.

[Mauron]

So Mauron, there's separate code to load the sprites in the field, in battle, and in the menus then? Can whatever Vehek did just be replicated in various situations?

From what I've seen, there's separate code for the field and menus. Battle was just ignoring the sprite size data. (My testing showed it as being somewhat garbled still, but that might be leftovers from the partial conversion from Crono to Slash.)

Here's a patch with Vehek's changes and my battle code.

[FaustWolf]

I just did a quick patch of the Slash ROM I whipped up a couple weeks ago and I'm getting a few errors like this, but it might be a result of not patching a fresh ROM or something:



I just wanted to see if you guys were getting these effects too. The first pic may be a result of the menu problem Mauron was talking about.

I do believe I was fairly sloppy in inserting Slash in the ROM we're working with. I'd lost my original and came up with that in a few minutes, and I know that there's frames screwed up in his field animations that weren't when I did the insertion back in November or December. I'll have to take some time out and try to reproduce what I had back in December, to make sure some screwed up frames aren't throwing us off.

[Mauron]

I was getting those too. I figured they were part of the incomplete transition, although looking at the second picture closely, there might be separate data in battle.

The menu problem is visible in the tech menu, and probably the exchange menu - I haven't checked that one.

[Vehek]

This code is used to determine where to write in OAM for menu sprites.

Code: [Select]

$C2/F874 7B          TDC
$C2/F875 4A          LSR A
$C2/F876 4A          LSR A
$C2/F877 E2 30       SEP #$30
$C2/F879 A8          TAYThe value from the TDC is the location of the $40-byte data starting at 7E1800 I was messing with to get the 8th character and Gaspar to show up. (So, $1800, then $1840, and so on, before the LSRs)

Still trying to figure out the graphics data in memory and VRAM.

[FaustWolf]

Turns out that what I thought was a rushed sprite job was actually just me choosing the "wrong" animation data to use. Slash's sprite works much better on the field with the animations for unarmed Slash, and that's what I gave him back in November (in the patch I posted a few pages back, I gave him the armed Slash animations accidently). I've attached an updated patch with the better animation data, so we can have some peace of mind.

That said, I wonder if something changed between the ROM Vehek had on March 13 and the patch Mauron just posted. Vehek posted screens where Marle and Slash are both very clean on field, but I'm getting little visual glitches like this:

Still better than before Mauron's patch certainly, but not quite as good as what was in Vehek's ROM unless he snapped a lucky shot. Anyone know what's up?

[Vehek]

Well, the code I posted on March 13 was the original code in the game (sorry for not making that clear earlier). Mauron doesn't seem to have actually changed it in the patch, which explains the problem.

[Mauron]

I changed it, but must have done so in the wrong way. What are the correct values?

[Chrono'99]

This is kind of unrelated to the current discussion, but I would like to know if Size 0 sprites are restricted to 4 blocks of 16x16 pixels each, or 16 blocks of 8x8 pixels each? Thanks. (just curious)

[Vehek]

I changed it, but must have done so in the wrong way. What are the correct values?

I looked again, and you did change the values for the OAM location. However, you didn't change the VRAM addresses. I'm not sure of the minimum VRAM space for size 1 sprites.

[FaustWolf]

Chrono'99, both descriptions are technically correct, but I think the "more correct" description would be "4 blocks of 16x16 pixels each," because the 8x8 subtiles in each tile absolutely have to be grouped in a square. You can arrange the tile squares into any shape you please, but they have to be contiguous tile squares.

[Vehek]

Size 2 Sprite Assembly (12 16x16 tiles):
VH OS VH OS VH OS VH OS - VH OS VH OS VH OS VH OS
VH OS VH OS VH OS VH OS - VH OS VH OS VH OS VH OS
VH OS VH OS VH OS VH OS - VH OS VH OS VH OS VH OS
VH OS VH OS VH OS VH OS - VH OS VH OS VH OS VH OS
VH OS VH OS VH OS VH OS - VH OS VH OS VH OS VH OS
VH OS VH OS VH OS VH OS - VH OS VH OS VH OS VH OS
XX YY XX YY XX YY XX YY - XX YY XX YY XX YY XX YY
XX YY XX YY XX YY XX YY

Size 2 is arranged the way Faustwolf thought the later sizes would work before he learned how size 1 was really arranged.

Size 3 has 24 16x16 tiles. Like size 2, you have to view with 32 bytes per row to line up the top halves of the tiles with the bottom halves.