CT Foreign Tileset Insertion: Development of a Guide

[FaustWolf]

Perfect, Edward! I'll take a look into Temporal Flux real quick and see which tileset (Guardia Forest or Truce Canyon) would be best to use.

EDIT: I'd recommend going with Truce Canyon. It'll take me awhile to get the resources together to explain why, but basically when you switch on the L1/2 subtile swatches the Truce Canyon set seems more "dense" (less empty space in the subtiles) than the Guardia Forest set. Edward, maybe you can take a look at it and see what you think.

Truce Canyon has a location index in Temporal Flux of 0x070. I believe that will be important for figuring out where its graphics packets are.

[justin3009]

I swear I remember a breakpoint address that someone poinetd to me ages ago...I'll have to dig that up again.

[justin3009]

- .___.''

[FaustWolf]

Ooh! Does that pic show tiles inserted into the Truce Canyon area Justin, i.e., did you find the appropriate address, decompress, insert new graphics, and recompress?

[justin3009]

Yes!

2677f2
2686d4
269341

[FaustWolf]

Awright! Now for the hard part -- can you explain how those graphics packet offsets were extrapolated from the fact that the tile set's index is 0x70? Vehek had told me earlier that he always uses the following info:

0x361C00 ~ 0x361DFF  "Location Tilesets, 8 bytes each, determines which ""packets"" of graphics are used for each location"   

0x362220 ~ 0x3624BF   "Pointers to Location Tiles (224 addresses, first at 0x252000)"   

So the data beginning at 0x36222 points into the data beginning at 0x252000, apparently.

[justin3009]

There's a break point.

USA:

C30569, Execute: When entering a new room, displays address of each compressed packet loaded.
JPN:

C305AA, Execute: When entering a new room, displays address of each compressed packet loaded.
~

[Edward]

We are aiming to fit the new tiles in the original space? That is, not have the new graphics exceed the size of the old packets? If there are 3 packets, we would need to split the new tileset into 3 pieces then, but what would be a good way to do that... count the tiles exactly and divide by 3? Even then we may have to sacrifice a tile or two.

0x362220 ~ 0x3624BF   "Pointers to Location Tiles (224 addresses, first at 0x252000)"   

We would only need to worry about these if our new packets were bigger than the old, and needed slight repointing, I imagine we will try to avoid this if possible for now.

Eventually, we will need to use that breakpoint and make a master list of offsets for every tileset in the game (well, it would make things easier in the long run).

[Vehek]

Each tileset has 8 packets, the last of which is apparently used for tile animation.

[FaustWolf]

Yeah, the goal is to avoid repointing. Each tileset I've looked at so far has an 8-byte "slot", with 6 normal packets, a seventh animation packet, and a filler FF byte IIRC.

Vehek -- once you know the graphics packet indices for a given tileset, how do you find the graphics packet offsets in the range beginning at 0x252000? What I refer to as "graphics packet indices" are the 8-byte slots from 0x361C00 ~ 0x361DFF IIRC.

How does one find breakpoints? Through Geiger's SNES9x debugger? I guess what I was aiming for was to find Truce Canyon's graphics packet pointers in the ROM itself and discover the graphics packets offsets that way (I think that's what Vehek does). If you guys can explain breakpoints in the tutorial, go for it. I'll see if I can do what I originally had in mind, and then we can give readers two methods for finding where the pertinent graphics packets are.

[justin3009]

Yes.  Load up Geiger's SNES9x debugger.

Load your Chrono trigger rom (unheadered)
Click Breakpoints
Type in the value
Click Execute Box
Click Ok
Go to a location in your CT ROM
BAM!  It'll print the value out.

[Vehek]

I use something like location tile packet * 3 + 362220 to get the location of the pointer. Then I convert the 3-byte pointer at that location into an address.

[FaustWolf]

Okay, thanks guys! So the three-byte pointers at 0x362220 ~ 0x3624BF lead to the graphics packets then. Sweet. Now we've got two methods for finding the packets.

EDIT: Vehek, when you get to the tile graphics packet pointers, is there any division or other operation involved in converting those pointers to an address? I assume the pointers need to be interpreted in Little Endian.

[Edward]

I don't think I missed any packets with graphics...

These were decompressed using the addresses from the debugger emulator, and viewed in the graphics viewer.

Tiles in the packet - SNES Address - Tile Address and Range in the ROM

[FaustWolf]

Woohoo! Nice work Edward! I can use those addresses to check my understanding of Vehek's method as well.

Let us know how it goes if you try a swap of the Rabite forest tileset and the Truce Canyon set. Do you happen to have a count on the number of subtiles in the Rabite Forest tileset? Subtiles are 8x8 pixels, whereas tiles are 16x16 pixels I believe. The graphics packets in Chrono Trigger can hold up to 128 subtiles IIRC, but I found the need to keep the last row (sometimes more) blank to save on post-compression space. That was with artwork insertion though; tiles actually meant for game use may naturally be set up in such a way that they compress easier.