Chrono Compendium

Kajar Laboratories - Fan Works and Submissions => Chrono Trigger Modification => Topic started by: FaustWolf on August 22, 2008, 12:25:15 am

Title: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on August 22, 2008, 12:25:15 am

Aaack, I'm now lightyears behind on all the developments that have taken place in this beautiful laboratory. Today I took some time off the campaign trail and managed to work a bit on a spreadsheet detailing where each CT sprite's graphics pack, palette, sprite assembly, and animation data are stored. E.g., let's say we want to change the Lavos Core into Weegee. First we'd need to know where in an unheadered ROM the Lavos Core graphics pack is located so that we may decompress it in Temporal Flux. Then we'd need to know where the sprite assembly data is located so that we can properly manipulate it, etc.

Geiger's NA Offsets Guide already tells us where everything is generally, and Vehek has detailed how sprite assembly and animation work in various threads. All that's needed to put CT sprite insertion capability into the hands of every fan is a step-by-step guide detailing the process. When the attached spreadsheet is finished it will serve as a supplement to such a guide, helping the user target individual sprites for alteration or replacement.

Currently the spreadsheet can be used to find a given sprite's starting offset in an unheadered ROM; sic Temporal Flux's decompression function on address 0x219995, for example, and the graphics pack for a Tyrano should pop out (requiring something like TileMolester to view it, of course). The spreadsheet also details palette locations, though the user will need to unhide columns F ~ M to match sprites to palettes.

I'm in the midst of listing indices for each sprite's assembly and animation pointer -- I'm just literally porting numbers from Chrono Tweaker into the spreadsheet's first worksheet. For example, Chrono Tweaker tells us that Belthasar's sprite gets the 15th Sprite Assembly Pointer and the 17th Animation Pointer. As per Vehek's observation, Chrono Tweaker mislabels the Sprite Assembly and Animation Pointer indices such that the numbers must be switched before they are listed in the spreadsheet. In other words, Chrono Tweaker literally reports that Belthasar gets the 15th Animation Pointer and the 17th Sprite Assembly Pointer, and I've re-interpreted Chrono Tweaker's listing to arrive at the conclusion that Belthasar gets the 15th Assembly Pointer and the 17th Animation Pointer.

So, yeah, that was all just as confusing for me to type as it was for you to read. There is a method to my madness, however, and it will all make sense in the end. I guess at this point I'm looking for help porting index numbers from Chrono Tweaker into this spreadsheet so that I can use the pointer indices to locate the offsets at which each sprite's assembly and animation data begin. This process in-and-of-itself could probably use its own mini-guide, and I'll get to it eventually, but if someone looking to get into the technical side of graphics hacking would like to fire up Chrono Tweaker and dive in, he or she would earn some cred toward an Architect of Kajar label. I think I left off about halfway through the NPC graphics listed in Chrono Tweaker. It should be noted that Chrono Tweaker requires a headered ROM, but that this will not make any difference with regard to the pointer indices. Once we get the indices ported we can use the pointers to find out where each sprite's assembly and animation data are stored. How exciting!

Psst...my heart is set on Hillary, but my money's on Biden. We'll all know Saturday.

[attachment deleted by admin]

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 10, 2008, 08:47:40 pm

Okay, time to get this ball rollin' again. Attached is an updated version of the Chrono Trigger Unheadered Sprite Info Excel spreadsheet. Basically, what you can do with this document is say, "I want to replace the Blue Imp with a Koopa from Super Mario World, where do I start?" and find that a Blue Imp's graphics pack starts at address 0x180000; its palette starts at address 0x240648; its sprite assembly starts at 0x1E5078; and its animation data begin at 0x245A20. Uh, that's it so far. :mrgreen:

One thing I'm quite uncertain about is the size specification I've calculated for each sprite's graphics pack, assembly, animation data, etc. For one thing, according to my calculations the Mammon Machine has a graphics packet that is 0x3D bytes long, yet Crono has a graphics packet that weighs in at 0x7BC0 bytes. Granted, Crono has lots of frames and his graphics packet is uncompressed whereas the Mammon Machine has one frame and its graphics packet is compressed, but given the MM's size, it should have a waaay bigger graphics pack than that. Nevertheless, it's the best I can do given the info provided in Chrono Tweaker.

Also of import is the need to differentiate between enemies that share the same graphics pack. Imps and rollies are stored in the same graphics pack, for example. Consequently, the Imp, the Rolly, and the Rolly Rider are listed on the same line in this spreadsheet but each enemy makes use of separate sprite assembly, palettes, and animation, which muddles things up considerably. That will be addressed in future.

For now I'll forge on with the Sprite Insertion Guide. I've decided on an ambitious goal of replacing Crono with Slash -- though other sprites may need obliterated to make room for the Crono > Slash transition.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on November 10, 2008, 09:14:04 pm

Quote

but given the MM's size, it should have a waaay bigger graphics pack than that.

I haven't checked the sprite, but isn't most of it part of the background?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 10, 2008, 09:15:11 pm

That thought had crossed my mind -- maybe the MM "sprite packet" is just a weird placeholder and the MM itself is defined completely by background tiles.

WAIT

Why is it that I get a correct palette for Crono only when I specify 0x23FFFE as the starting address for the palette in TileMolester?

Blood pressure...rising. Geiger's NA Offsets Guide says that the character sprite palettes should start at address 0x240000, not at 0x23FFFE. Does not compute. Vehek, Geiger, and other hacking gods, any advice on this situation? I'll load a fresh ROM just to make sure I didn't accidently delete two bytes somewhere along the line.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on November 10, 2008, 09:17:05 pm

The "transparent" color isn't part of the palette data in the ROM. So, when you use the proper address, it puts the wrong color in the first, transparent color slot and all the colors get put in the wrong slot. (BTW, if you don't know, each color takes up two bytes.)

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 10, 2008, 09:27:04 pm

Aha! I guess that explains a lot of the problems I've had with palettes thus far. Wild. My cursory investigation suggests that I can view sprites with the "correct" palette by always subtracting 0x2 from the values listed in the spreadsheet, so I guess I'll add another column entitled "correctional factor palette starting address" to account for that. Thanks!

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Geiger on November 11, 2008, 12:31:44 am

Quote from: FaustWolf on November 10, 2008, 09:27:04 pm

My cursory investigation suggests that I can view sprites with the "correct" palette by always subtracting 0x2 from the values listed in the spreadsheet, so I guess I'll add another column entitled "correctional factor palette starting address" to account for that. Thanks!

Well, technically, no you really should not do it that way. The sprite palettes are assembled by the ROM, and that's the way you should do it also. For example, the PC sprite palettes consist of the transparency color, the 12 character colors, and the 3 weapon colors. The character and weapon colors do not reside together. Other palettes are put together in a similar fashion.

(Also, the next release of Flux should make much of the sprite insertion process considerably easier.)

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 11, 2008, 12:58:48 am

I've put in a "correctional factor" column in the "Palettes" tab of the working spreadsheet, but I've kept the true offsets intact for completion's sake. The upshot as I understand it is, one needs to go with the true values as extrapolated from Geiger's offsets guide when editing palettes, but can use the "correctional factor" column for viewing in TileMolester. The point of subtracting two bytes from each palette's true starting offset is to throw some junk bytes into the first slot of the palette, where the phantom transparency would normally go in-game.

I'm slightly bothered by something though -- notice how in Vehek's sprite assembly tutorial example, Crono's sword is a nice bright purple, yet in my sprite sheet capture the sword is white and not quite as apparent? Vehek, did you color the weapon space in to highlight it, or am I still just slightly off with regard to character palettes?

(http://img65.imageshack.us/img65/4410/exampleiw4.th.png) (http://img65.imageshack.us/my.php?image=exampleiw4.png)

Also, a major problem Vehek mentioned sometime ago:

Quote from: Vehek

Change the sprite data of a PC, and when you enter a battle, their sprite data (except for the palette) returns to normal settings.

Has there been any progress on this front?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on November 11, 2008, 02:59:49 am

It's been a while since I made that example, but I probably used a savestate.
The sprite data thing doesn't matter much; I was referring to PC sprite data, which says what # graphics/sprite assembly/etc to load.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 11, 2008, 01:54:29 pm

Okay, that's encouraging if I understand correctly. So let me get this straight -- if I manually replace, say, Crono's graphics pack with Frog's, Crono's sprite assembly data with Frog's, Crono's palette data with Frog's, and Crono's animation data with Frog's, not only will Frog jump out of Crono's bed in the beginning of the game, but Frog will still be Frog in battle and not graphically revert back to Crono?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Ozzie on November 11, 2008, 03:59:34 pm

I think most of that data has pointers that you can simply swap (for testing purposes). Changing the pointers would be a bit easier than manually copying and overwriting all that data, eh? This wouldn't work for custom sprites and animations and all that, but a simple frog swap could mostly be done with pointer swapping I think (Crono's graphics pointer value changed to the same pointer Frog uses, Crono's animation data pointer changed to the same pointer value Frog uses, etc...)

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 11, 2008, 04:10:39 pm

Right on -- what I'm wondering is, is such pointer swapping reverted in-battle somehow, or what exactly was Vehek referring to when he said that "PC sprite data" changes are undone upon battle initialization? I remember running into the difficulty Vehek described (replacing Crono with another character graphically, only to have that character become Crono once again in battle), but my experiments took place such a long time ago I'm not sure which data I was fooling around with.

I'm still extremely paranoid about the in-battle problem. But I should probably do the pointer switches as you suggest Ozzie, just to see what happens. That will resolve the issue of whether or not I should be worrying.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on November 11, 2008, 04:14:35 pm

I was talking about this:
24F000 24F022 DATA N PC sprite data (5 bytes each) 2004.04.01
Same format as NPC sprite data.

I'm not completely sure, but in battle, it basically loads graphics packet x for PC x, sprite assembly x for PC x, etc. (except for palette).

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 11, 2008, 05:53:51 pm

Gotcha, thanks. I wonder if that data beginning at 0x24F022 may be related to the results of my pointer exchange between Magus and Crono? I manually replaced Crono's GFX pack, palette, sprite assembly, and animation pointers with Magus' values, and got this:

http://www.youtube.com/watch?v=qeCGUUHR9ro

The graphics pack and sprite assembly are spot-on, but the palette and animation data are most definitely not. When I first recorded the video I thought Magus' animation data was somehow getting straightened out over time, but turns out certain animations work better or worse depending on the direction he's facing in battle.

Interestingly, it would appear that the game is loading Magus with Crono's palette regardless of the value specified for Crono's palette pointer. I.e., change it to Magus' palette pointer value and you're getting Crono's palette; leave it the same as Crono's palette and you're getting Crono's palette.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on November 11, 2008, 05:57:34 pm

Did you read my animation data notes? The game checks the next animation data pointer to figure out how big the animation data is, and where in the animation data each direction begins.

I don't remember where right now, but in some places, the game uses palette # * 0x18 to get the palette. In some other places (I don't remember where either) it uses the pointer.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 11, 2008, 06:32:52 pm

A-ha, changing the next animation pointer over (Marle's) to the value that would normally follow Magus' animation pointer did the trick for the most part, though Magus' attack animation is still screwed up a bit for some reason.

A simple pointer switch doesn't change the palettes, but changing the palette data byte-by-byte does the trick -- it's as if the palette pointers are there for record-keeping purposes, and this other palette-determination method is the real deal.

As a side note, Magus looks pretty awesome doing Cyclone.

I've made some more corrections and re-attached the Sprite Offsets spreadsheet here and removed it from all other posts so as to minimize the number of versions floating around.

[attachment deleted by admin]

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 11, 2008, 10:38:42 pm

LET US DISCUSS SPRITE ASSEMBLY

I'm up to speed on how the game engine specifies which tile to load I think, and am examining everyone's notes to figure out how the game engine places the loaded tiles on a 2D plane. But in the meantime, here's something I find extremely unsettling, probably due to my inexperience in this area:

(http://img117.imageshack.us/img117/1270/cronohairshiftoddityun3.th.png) (http://img117.imageshack.us/my.php?image=cronohairshiftoddityun3.png)(http://img117.imageshack.us/images/thpix.gif) (http://g.imageshack.us/thpix.php)

Illustrated are the 9 non-blank tiles summoned from Crono's GFX pack to form his first frame, which I will call Frame #1 (Standing-Front). Notice how that damn little hair piece at the very top of his head has to be misaligned for the sprite to be built correctly?

How does sprite assembly data specify such a thing? Is there some function in the last eight bytes of Crono's first frame that allows pixel-by-pixel shifting of a tile?

______________

But I digress -- I should have used this post to describe my understanding of sprite assembly a.) to revive the topic and b.) to ensure that I have a correct understanding of how the game engine decides which tiles from a GFX pack to load. What follows is essentially a regurgitation of what Vehek and justin3009 had posted earlier, just in my own language.

Let's start with the hex code for Crono's first sprite frame, Frame #1 (Standing-Front):

00 00 00 00 02 00 01 00-00 00 00 00 20 00 21 00
00 00 00 00 10 00 11 00-00 00 31 00 30 00 30 40
F8 00 F8 E0 F5 D0 F8 F0

This consists of 16 tiles from Crono's GFX pack, 2 bytes each, plus 8 bytes that I'm still trying to figure out tagging along at the end (third row).

I like to think of the format for the two-byte pairs in rows 1 and 2 as follows:

VH OS
With...
V = Vertical Axis slot
H = Horizontal Axis slot
O = Orientation
S = Section

The Vertical Axis nybble specifies which tile the game engine looks for in the up-down direction.
The Horizontal Axis nybble specifies which tile the game engine looks for in the right-left direction.
The Orientation nybble specifies whether the tile should be mirrored in the built sprite. There may be other ways to orient
the tile, but I am currently unaware of other values besides "4," which is the mirror value.
The Section nybble specifies which 0xF by 0xF grouping in a GFX pack the game engine is supposed to look at when pulling
tiles. Notice that on the vertical axis of the GFX pack pictured below I leave room for two nybbles, or a whole byte --
starting with 0x00 and going through 0x3D at the very bottom. There are four "sections," one from 00 ~ 0F, another from
10 ~ 1F, another from 20 ~ 2F, and another from 30 ~ 3D.

Next, let's get Crono's GFX pack up:
(http://img134.imageshack.us/img134/5543/chronosheetblowuplabeleih1.th.png) (http://img134.imageshack.us/my.php?image=chronosheetblowuplabeleih1.png)

Note that the horizontal axis consists of hexidecimal values from 0x0 through 0xF -- these are H values.
Note that the vertical axis consists of hexidecimal values 0x00 through 0x3D -- these are SV values.

Let's go through the blue-colored bytes in Crono's first frame: 02 00

The game engine reads everything in Little Endian order, so we're looking at [OS VH] being [00 02].

The O value is 0, meaning there's no mirroring of the tile. The S value is 0, meaning we're in the 0V section of the GFX pack. The V value is 0x0, meaning we're in the top row. The H value is 0x2, meaning we're in the third row over. Thus, the tile loaded by this byte pair is the pink-filled tile in the pic below:
(http://img515.imageshack.us/img515/9517/chronosheetblowuplabeleex8.th.png) (http://img515.imageshack.us/my.php?image=chronosheetblowuplabeleex8.png)

In the same vein, the red-colored bytes highlighted in Crono's first frame sprite assembly (30 00) specify the following tile:
(http://img515.imageshack.us/img515/203/chronosheetblowuplabeleuh7.th.png) (http://img515.imageshack.us/my.php?image=chronosheetblowuplabeleuh7.png)

The green-highlighted bytes highighted in Crono's first frame sprite assembly (30 40) give us much better practice. Read 0x4030, the first nybble tells us that the tile is mirrored and the second tells us that the game engine is pulling from the 0x00 ~ 0x0F range on the vertical axis. The tile in question is once again:
(http://img515.imageshack.us/img515/203/chronosheetblowuplabeleuh7.th.png) (http://img515.imageshack.us/my.php?image=chronosheetblowuplabeleuh7.png)

...it's just flipped this time so Crono can have two feet using the same tile.

Sprite Assembly gurus, don't hold back -- let me know if my understanding is correct so far, and please guide me on the meaning of the last eight bytes in Crono's first frame at your convenience.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on November 11, 2008, 10:46:23 pm

As the sprite assembly thread says, the last 8 bytes have to do with x/y. They seem to shift in pixels. For the x-coord part, 00-7F seem to place to the right of where the sprite when x-coord is FF.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: justin3009 on November 11, 2008, 11:51:42 pm

What he said, and by changing a specific byte...forgot which, but it's in the old tutorial posted back, it'll flip the image horizontally so it can be used again.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 12, 2008, 12:44:31 am

Hmmm, I might just be on the verge of understanding the final 8 bytes if I think about them the way you proposed in this post (http://www.chronocompendium.com/Forums/index.php?topic=2872.msg51265#msg51265) Vehek:

00 00 00 00 02 00 01 00 00 00 00 00 20 00 21 00
00 00 00 00 10 00 11 00 00 00 31 00 30 00 30 40
F8 00 F8 E0 F5 D0 F8 F0

So am I correct in positing that what I've been calling "tiles" up to now (8x8 pixel units) are actually subtiles, whereas the game engine actually likes to work with full tiles (16x16 pixel units) at a time? Thus, the following four tiles must compose Crono's first sprite frame?

(http://img232.imageshack.us/img232/2492/firstspritetilebreakdowfl1.png)

And the four byte pairs following those tiles are associated with the tiles in the pictured fashion, determining their coordinates on the x/y 2-dimensional plane? If I'm understanding this right so far, then I must ask a question Vargose posed in that thread: any idea on what the relative point of "origin" is? And where would the "anchor" be on a tile, i.e., the point on each tile whose coordinates are being specified?

EDIT: Ah, well, I can see this much -- the F5 D0 tile is placed above the F8 E0 and F8 F0 tiles, so that they're all stacked one on top of the other, and then the F5 D0 tile is laterally shifted by what appear to be three pixels relative to the lower tiles. Hence the three-unit difference between 0xF5 and 0xF8. That makes sense!

EDIT 2: Reference point of origin and tile anchor are best studied in the following context, I suppose. Here's what happened when I zero'd out the "FE 80" X/Y coordinate bytes:
(http://img60.imageshack.us/img60/223/poojk0.png)

So, question -- is the reference point of origin for the x/y coordinates at the very bottom-right of this pic, with the tile "anchor" being the bottom right-most pixel of the tile, or is the point of origin the bottom-right corner where Crono's foot is, and the tile "anchor" is at the top-left corner of the moved tile? In other words, are the reference point of origin and anchor where the green dot is, or where the red dot is?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 12, 2008, 03:40:42 pm

Okay, I think I understand the location of the sprite frame's origin and where a given tile's "anchor" is. The "anchor" I refer to, in case it wasn't clear, is the point/pixel on a tile to which the X/Y plane coordinates are applied, thus dragging the whole tile with it and snapping it into place.

The origin on the X/Y plane appears to be the red dot below, whereas the green dot is the anchor of Crono's head tile:
(http://img201.imageshack.us/img201/4436/cronohairshiftoddityhb5.png)

The red dot represents the coordinates 0,0.

The green dot represents the coordinates -8,-32.

Let's get the scale that the game engine's working with down-pat before moving any further:

0x00 ~ 0x7F: +0 ~ +127
0x81 ~ 0xFF: -127 ~ -1

WAIT -- if the X coordinate is 0xF8 (-8 dec), it's understandable that the anchor would be eight pixels left of the origin. But if the Y coordinate is -32, shouldn't the tile be below, and not above, the origin? It's mysterious to me, but it seems that the game engine determines the tile anchor's Y coordinate in reverse fashion. That is, if I make the Y coordinate 0x10 (+16 dec), Crono's head tile ends up 16 pixels below his feet.

Someone let me know if my understanding of any of the above is in error.

Moving on -- we have the following format a size 0 sprite frame's assembly:

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

Where...
V = Vertical Axis slot of a subtile in the GFX pack
H = Horizontal Axis slot of a subtile in the GFX pack
O = Orientation of the subtile (0 for normal, 4 for reversed)
S = Section (allows the game engine to search past 0xF on the vertical axis of the GFX pack; it could theoretically search all
the way down to 0xFF thanks to this nybble.

XX = The horizontal displacement of a tile's anchor, in pixels. Interpreted as we would expect, with positive values moving the
anchor right and negative values moving the anchor left.
YY = The vertical displacement of a tile's anchor, in pixels. Interpreted inversely from what we would expect, with positive values
moving the tile anchor down and negative values moving the anchor left.

The VH OS subtiles are grouped into tiles as indicated by color-coding.
Each XX YY coordinate byte pair controls the tile that matches its color.
The scale on which the XX YY byte pair operates is as follows:
0x00 ~ 0x7F: +0 ~ +127
0x81 ~ 0xFF: -127 ~ -1

But enough theory. It's time for the first test of my understanding of sprite assembly...

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 12, 2008, 06:13:17 pm

Sprite assembly pulled off without a hitch, so it would appear that my understanding is correct. In the pics below, note that I couldn't fit all of Slash into a Size 0 sprite assembly -- he'd need a Size 1 sprite assembly I suppose, and I'm not sure how to work with those yet. For now he shall remain footless:
(http://img147.imageshack.us/img147/6397/slashinserttestframe1ab4.th.png) (http://img147.imageshack.us/my.php?image=slashinserttestframe1ab4.png)(http://img147.imageshack.us/img147/7310/slashinserttestgfxub1.th.png) (http://img147.imageshack.us/my.php?image=slashinserttestgfxub1.png)

EDIT: It occurs to me I should have posted my sprite assembly code. Here it is below.

00 00 01 00 00 40 03 00-20 00 21 00 22 00 23 00
10 00 11 00 12 00 13 00-30 00 31 00 32 00 03 00
F0 E0 00 E0 F0 F0 00 F0

What I'm having trouble with right now are palettes. We haaatesss them, precious! Therefore, before moving the subject of sprite sizes, I would like to take a detour...

LET US DISCUSS PALETTES

When you (or at least I) work with sprites in a typical image editing program, I'm working with a palette that invariably looks something like this:

(http://img147.imageshack.us/img147/4594/paletteexamplewc7.png)

That's thirteen colors -- 12 for the actual sprite and one for the background. My question is, when creating a bitmap for import into the ROM, should I ensure that the background color is in the slot labeled "1" or the slot labeled "13"? In other words, I'm trying to manually anticipate what position in a 16-color palette the transparency would occupy. I thought at first that the transparency would occupy the slot labeled "1," so I assigned Slash's colors to slots 2 ~ 13 in the pic above. However, it would appear from my results that the thirteenth palette position is, in fact, where the transparency is being loaded. The solution could be as simple as making sure that the sprite pixels are "pointing" to palette slots 1 ~ 12 when I'm whipping up a bitmap for export, but I wanted to confer with more experienced sprite hackers first.

SUPER EDIT: Palette success! Though I haphazardly re-injected the sprite frame into the ROM, causing some misalignment that's reflected in the one mirrored subtile I used.

(http://img80.imageshack.us/img80/9427/palettesuccessef0.png)

Once again, I had to use the palette correctional factor -- when editing Crono's palette, I had to start with address 0x23FFFE, which is two bytes prior to 0x240000. Therefore, the palette correctional factor in the spreadsheet must be used both for editing and viewing in TileMolester. I'm not sure why this is, because I can't imagine the game engine would be fond of starting a new block of data at 0x23FFFE as opposed to 0x240000, given that the latter is a very well-rounded value.

To answer my question above, one should ensure that all sprite colors fall into slots 1 ~ 12, and the background color falls into slot 13.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 12, 2008, 09:42:30 pm

LET US DISCUSS SPRITE ASSEMBLY SIZE

Earlier Vehek noted that a Size 0 sprite assembly scheme consists of 40 bytes, whereas a Size 1 assembly scheme consists of 80 bytes. Thus, the difference between a Size 0 and a Size 1 assembly is as follows.

Size 0 Assembly
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 -

Size 1 Assembly (Obsolete as per Vehek's observations; see following posts)
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

In other words, bumping up the sprite's size by +1 increases the number of tile groups available by 4. So we have 8 tiles to work with instead of 4 with a Size 1 sprite. Those in the know, is it likely that this "+4 tiles" pattern holds through all sprite sizes? I.e., would we have the following?

Size 0 Sprite: 4 tiles
Size 1 Sprite: 8 tiles
Size 2 Sprite: 12 tiles
Size 3 Sprite: 16 tiles
Size 4 Sprite: 20 tiles

...and so on?

Also, it appears that a Sprite's Size parameter is defined in the "Sprite Data" section as contained in Geiger's NA Offsets Guide:

0x24F000 ~ 24F022: PC sprite data (5 bytes each)
0x24F023 ~ 24F522: NPC sprite data (5 bytes each)
0x24F600 ~ 24FFFF: Enemy sprite data (10 bytes each)

Vehek, Geiger, or justin, after snooping through the data, I suspect that the fifth byte in a player character's sprite data specifies the Assembly Size, is that correct?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on November 12, 2008, 10:07:42 pm

The largest sprite assembly type I know of is 2.
I just checked, and what I said back then still seems to be true: The second row for size 1 assemblies is placed in a different spot. Size 2 assemblies seem to have the 2nd row in the same place though.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: justin3009 on November 12, 2008, 10:19:29 pm

Yea, you're correct Faust. Pretty certain of that.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 12, 2008, 10:31:45 pm

Man, now I'm worried about Size 1 Assemblies after re-reading Vehek's sprite assembly thread. Vehek, could you expound on what you meant here?

Quote from: Vehek

[In a Size 1 Sprite Assembly] There are 8 groups of 4-tile groups. Because there're more groups, the start of the second row of a group is 32 bytes after the start of the first row.

I think you mentioned Gato somewhere as an example of Size 1 Assembly, so I'll look at its sprite assembly and GFX pack as well.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on November 12, 2008, 10:34:53 pm

I was wrong about Gato's sprite assembly size back then. He's size 2.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 12, 2008, 10:38:25 pm

I'll bet Slash is a Size 1, so I'll look at his assembly data. But first, it appears that I really need to pay attention to those sections labeled "Sprite Data" in Geiger's offsets guide, so I'll add those offsets to the developing spreadsheet.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on November 12, 2008, 10:51:32 pm

Yes, Slash uses size 1.

Basically, I think size 1 assembly is more like this (rearrangement of what you had):

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
The x/y coordinates are still in the same place at the end.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 12, 2008, 11:22:33 pm

Many thanks! Ugh, so the subtile groups are sort of spliced together in an unholy way when viewed with 16 bytes per row.

However, if you view with 32 bytes per row, it becomes this:

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

That's way easier for me to look at. Seems the size attribute widens the "window" through which the game engine reads the tiles.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on November 13, 2008, 03:23:51 am

A warning: I've tried to change a PC's sprite assembly size to 1. I don't know if I did it perfectly (I had a program convert the size 0 sprite assembly), but it glitched up when other PCs were in the party.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 13, 2008, 05:24:56 pm

That's a bummer. Hope the game engine isn't hard-coded to read only Size 0 sprites correctly for the playables.

I'll try some Size 1 tests with Slash and see what happens.

_______

Vehek, were your glitches similar to what happens after 2:45 of this video, (http://www.youtube.com/watch?v=9aBoitdZiOY) when Lucca joins? The sprites can apparently coexist, which is encouraging, but I'm pretty freaked out that the second character's sprite gets copied for some weird reason.

This test was a simple port of Slash's various data over Crono's, so it may have turned out better if I had coded the frames and animation by hand.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: justin3009 on November 13, 2008, 06:11:18 pm

It's a wild guess, but since it's extending the reach I guess it is of the sprites, maybe it's changing some areas of the 2nd PC's because it's also reading from the 1st? I'm not sure.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on November 13, 2008, 07:10:35 pm

Quote from: FaustWolf on November 13, 2008, 05:24:56 pm

Vehek, were your glitches similar to what happens after 2:45 of this video, when Lucca joins?

Yes.
Right now, I guess that part of the copied-to-memory graphics overlap with the other PCs' graphics in memory/VRAM.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 13, 2008, 07:15:10 pm

Damn, that's bad. Any way around this theoretically?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: justin3009 on November 13, 2008, 07:40:08 pm

Couldn't you move the graphics and SA of Slash or someone else to empty space? Or would that still kill it.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 13, 2008, 08:15:31 pm

I think it's a memory management issue, but I should try that out anyway. Interestingly, the problem corrects itself in battle. Do we know whether in-battle and out-of-battle memory management differ in any way?

Also, just wanted to report that in-game evidence once again supports our models of Size 1 sprite assembly. The following frame for Slash was hand-coded in a Hex Editor:
(http://img91.imageshack.us/img91/6761/image1bc0.png)

Argh, I'm still not up to snuff on palettes. Looks like my conclusion several posts ago was incorrect; the first palette position is the one that ends up being transparent in-game. But it seems like no matter what I do, I accidently point some pixels on my Slash bitmap to a transparent palette position. There aren't multiple transparencies in a single character's palette, are there?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: justin3009 on November 13, 2008, 10:09:13 pm

No there isn't.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 13, 2008, 11:37:56 pm

justin, I shall have to come straight out and ask -- when you're creating a 12-color bitmap sprite for later insertion, what position in the image's palette (as viewed in your image editor) should you target for the image's background color? Do you need the first color specified in the palette to be the background color?

If there's a program that takes care of this automagically somehow, I'll just kick myself in the head for being such a doofus at palettes.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on November 13, 2008, 11:43:08 pm

What are you doing to import? For me, TileMolester seems to try and match-up the colors in the (png for me) file to the closest colors in the palette.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: justin3009 on November 14, 2008, 12:03:39 am

What Vehek said. Tile Molester makes it a lot easier to work with.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 14, 2008, 12:08:57 am

Hmm, I've been creating bitmaps in an image editor, importing the raw tiles via TileMolester, then using SNESpal to alter Crono's palette (with the whole division by 8 thing) and hoping like hell I'm specifying the colors correctly. :mrgreen: I'll try a .png next time around and see if I have better luck. I'll get it eventually.

If it matters any, I should note that Slash's sprite (when specified to have a Size 1 assembly) "captures" the hand sprite that's on the menu screen. Say you check the party's status in the menu, then close out and go back to the game -- the tiles that make up the hand pointer sprite appear at the origin of Slash's sprite, just like Lucca gets re-copied and appears at the origin of his sprite when she's in the party in that video I posted.

I'm going to use VSNES (http://www.romhacking.net/utils/274/) to peek at the VRAM and see if there's any clues to be found.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 14, 2008, 01:03:42 am

Ah, here's a tasty tidbit, but not sure if it tells us anything important. In the screen below, I thought Lucca's tiles were just overlapping Slash's:
(http://img91.imageshack.us/img91/4919/image1pt4.png)

We can isolate the sprites in VSNES to get a clearer look:
(http://img91.imageshack.us/img91/5610/image2rs2.png)

And VSNES also allows us to toggle individual tiles on and off. When the duplicate Lucca is erased, lo and behold, half of Slash - four tiles to be precise - are missing! They didn't seem to be loaded for some reason:
(http://img91.imageshack.us/img91/7893/image3iv2.png)

It's as if the game engine loaded up Lucca's tiles in place of Slash's tiles. Were the tiles vying for the same space in VRAM? I'm attaching two ZSNES save states, one with Slash by himself, and the second with Slash and Lucca in the party, in case they prove useful to others with more SNES VRAM experience than myself.

[attachment deleted by admin]

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on November 14, 2008, 04:09:41 am

Quote from: FaustWolf on November 14, 2008, 12:08:57 am

I'll try a .png next time around and see if I have better luck. I'll get it eventually.

I don't think it matters what file format you use. If you're going to keep on trying to import with TileMolester, remember this: Load your palette into tilemolester, then import the graphic.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: justin3009 on November 14, 2008, 09:06:16 am

Load up a savestate in Tile Molester that has Slash's palette, add it to bookmarks. Then it's simple and easy to load. When you select it again, it may be wacked out colors, but just scroll through it, it'll have the correct palette.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 14, 2008, 10:45:50 pm

Okay, finally solved my palette dilemma thanks to your guys' help. I was completely unaware all this time that when you insert a graphic via TileMolester, you need to make sure you're viewing the graphic-to-be-inserted with its correct palette even before you do the insertion. Got it now, and it's a user-defined palette to boot, so I didn't have to extract it from a savestate at all:
(http://img408.imageshack.us/img408/2003/image1fg8.png)

So that's over and done with. I'm extremely worried about the memory management issue with the Size 1 sprites though, if only for CE's sake. The only thing I can think of to do is comb this thread (http://www.chronocompendium.com/Forums/index.php?topic=1764.0) for clues, but I don't even know what I'm looking for exactly.

EDIT: For what it's worth, I want to point out that there doesn't seem to be any problem with the third character's sprite, only the second's:
(http://img135.imageshack.us/img135/8750/image2qq9.th.png) (http://img135.imageshack.us/my.php?image=image2qq9.png)

The fact that it's Frog and not Lucca being copied here probably clinches the supposition that it's a memory management issue and not a simple "Slash's data is overriding Lucca's" possibility.

Also, if it's any assistance in the diagnosis --
(http://img135.imageshack.us/img135/3549/image1yx7.th.png) (http://img135.imageshack.us/my.php?image=image1yx7.png)
Sometimes it's Slash's tiles that are copied over Lucca, and Lucca disappears. There seems to be a tradeoff between their tiles being displayed, and the problem seems to lie in the "extra tiles beyond four" that are loaded for Slash. Either all four of Lucca's tiles are displayed and copied, or none of Lucca's tiles appear and all four of Slash's "extra" tiles are displayed and copied.

Once again the problem seems to resolve itself in-battle, but Slash's tile assembly seems to fall to pieces in-battle -- probably due to the possibility that Slash does not have a frame for every frame of animation Crono does (Slash has fewer frames than any of the playables IIRC, though he's closer than any other enemy).

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on November 14, 2008, 10:53:03 pm

The game doesn't read the PCs' PC sprite data in battle, so it doesn't get the sprite assembly size.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 14, 2008, 11:17:19 pm

Whoah, so does sprite assembly size apply only to Field graphics? And by extension, is it even possible for player characters to have Size 1 sprites in battle, or are they "locked" to a total of four tiles (Size 0 assembly) in battle?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on November 14, 2008, 11:23:18 pm

The game seems to load a value from variables starting at 7E967C to determine what sprite assembly size to use in battle. 7E967C seems to represent the sprite assembly size for all three PCs in battle.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 14, 2008, 11:30:19 pm

Aha! That should go in the Memory MAP thread too, or at least I didn't see that address in there when I looked. Anything that could possibly help us in Field (outside of Battle)?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Mauron on November 16, 2008, 11:48:42 am

Quote from: Vehek on November 14, 2008, 11:23:18 pm

7E967C seems to represent the sprite assembly size for all three PCs in battle.

It doesn't. The next two bytes are definitely PCs 2 and 3.

Originally all three bytes were set to 0 along with a larger section with this code:

Code: [Select]

Disassembly:
$CF/FB94	A2 EB 7F	LDX #$7FEB	A:0000	X:0000	Y:0000	D:0000	DB:00	S:01FF	P:EnvmxdIzc	HC:0008	VC:000	00	FL:00
$CF/FB97	9E 00 2D	STZ $2D00,x[$00:2D00]	A:0000	X:0000	Y:0000	D:0000	DB:00	S:01FF	P:EnvmxdIzc	HC:0016	VC:000	00	FL:00
$CF/FB9A	CA 	DEX	A:0000	X:0000	Y:0000	D:0000	DB:00	S:01FF	P:EnvmxdIzc	HC:0024	VC:000	00	FL:00
$CF/FB9B	CA 	DEX	A:0000	X:0000	Y:0000	D:0000	DB:00	S:01FF	P:EnvmxdIzc	HC:0032	VC:000	00	FL:00
$CF/FB9C	10 F9	BPL $F9    [$FB97]	A:0000	X:0000	Y:0000	D:0000	DB:00	S:01FF	P:EnvmxdIzc	HC:0040	VC:000	00	FL:00

I moved that code and replaced it with a simple JSR.

Code: [Select]

Disassembly:
$CF/FB94	20 85 FE	JSR $FE85  [$FD:FE85]	A:0064	X:151C	Y:000E	D:0100	DB:7F	S:06F7	P:envMxdizc	HC:0280	VC:000	00	FL:11
$CF/FB97	80 05	BRA $05    [$FB9E]	A:0000	X:0000	Y:0000	D:0000	DB:00	S:01FF	P:EnvmxdIzc	HC:0016	VC:000	00	FL:00
$CF/FB99	EA 	NOP	A:0064	X:151C	Y:000E	D:0100	DB:7F	S:06F7	P:envMxdizc	HC:0292	VC:000	00	FL:11
$CF/FB9A	EA 	NOP	A:0064	X:151C	Y:000E	D:0100	DB:7F	S:06F7	P:envMxdizc	HC:0298	VC:000	00	FL:11
$CF/FB9B	EA 	NOP	A:0064	X:151C	Y:000E	D:0100	DB:7F	S:06F7	P:envMxdizc	HC:0304	VC:000	00	FL:11
$CF/FB9C	EA 	NOP	A:0064	X:151C	Y:000E	D:0100	DB:7F	S:06F7	P:envMxdizc	HC:0310	VC:000	00	FL:11
$CF/FB9D	EA 	NOP	A:0064	X:151C	Y:000E	D:0100	DB:7F	S:06F7	P:envMxdizc	HC:0316	VC:000	00	FL:11

I then added some new code for loading the sprite assembly size in battle. This is the moved and new code:

Code: [Select]

Disassembly:
$CF/FE85	A2 EB 7F	LDX #$7FEB	A:0000	X:0000	Y:0000	D:0000	DB:00	S:01FF	P:EnvmxdIzc	HC:0504	VC:000	00	FL:00
$CF/FE88	9E 00 2D	STZ $2D00,x[$00:2D00]	A:0000	X:0000	Y:0000	D:0000	DB:00	S:01FF	P:EnvmxdIzc	HC:0512	VC:000	00	FL:00
$CF/FE8B	CA 	DEX	A:0000	X:0000	Y:0000	D:0000	DB:00	S:01FF	P:EnvmxdIzc	HC:0520	VC:000	00	FL:00
$CF/FE8C	CA 	DEX	A:0000	X:0000	Y:0000	D:0000	DB:00	S:01FF	P:EnvmxdIzc	HC:0528	VC:000	00	FL:00
$CF/FE8D	10 F9	BPL $F9    [$FE88]	A:0000	X:0000	Y:0000	D:0000	DB:00	S:01FF	P:EnvmxdIzc	HC:0536	VC:000	00	FL:00
$CF/FE8F	E2 30	SEP #$30	A:0070	X:151C	Y:0066	D:0100	DB:7F	S:06F7	P:envMXdizc	HC:0280	VC:000	00	FL:224
$CF/FE91	A0 02	LDY #$02	A:0070	X:151C	Y:0066	D:0100	DB:7F	S:06F7	P:envMXdizc	HC:0286	VC:000	00	FL:224
$CF/FE93	BE 80 29	LDX $2980,y[$7F:29E6]	A:0070	X:151C	Y:0066	D:0100	DB:7F	S:06F7	P:envMXdizc	HC:0292	VC:000	00	FL:224
$CF/FE96	A9 00	LDA #$00	A:0070	X:151C	Y:0066	D:0100	DB:7F	S:06F7	P:envMXdizc	HC:0298	VC:000	00	FL:224
$CF/FE98	18 	CLC	A:0070	X:151C	Y:0066	D:0100	DB:7F	S:06F7	P:envMXdizc	HC:0304	VC:000	00	FL:224
$CF/FE99	69 05	ADC #$05	A:0070	X:151C	Y:0066	D:0100	DB:7F	S:06F7	P:envMXdizc	HC:0310	VC:000	00	FL:224
$CF/FE9B	CA 	DEX	A:0070	X:151C	Y:0066	D:0100	DB:7F	S:06F7	P:envMXdizc	HC:0316	VC:000	00	FL:224
$CF/FE9C	10 FB	BPL $FB    [$FE99]	A:0070	X:151C	Y:0066	D:0100	DB:7F	S:06F7	P:envMXdizc	HC:0322	VC:000	00	FL:224
$CF/FE9E	3A 	DEC A	A:0070	X:151C	Y:0066	D:0100	DB:7F	S:06F7	P:envMXdizc	HC:0328	VC:000	00	FL:224
$CF/FE9F	AA 	TAX	A:0070	X:151C	Y:0066	D:0100	DB:7F	S:06F7	P:envMXdizc	HC:0334	VC:000	00	FL:224
$CF/FEA0	BF 00 F0 E4	LDA $E4F000,x[$E4:051C]	A:0070	X:151C	Y:0066	D:0100	DB:7F	S:06F7	P:envMXdizc	HC:0340	VC:000	00	FL:224
$CF/FEA4	99 7C 96	STA $967C,y[$7F:96E2]	A:0070	X:151C	Y:0066	D:0100	DB:7F	S:06F7	P:envMXdizc	HC:0346	VC:000	00	FL:224
$CF/FEA7	88 	DEY	A:0070	X:151C	Y:0066	D:0100	DB:7F	S:06F7	P:envMXdizc	HC:0352	VC:000	00	FL:224
$CF/FEA8	10 E9	BPL $E9    [$FE93]	A:0070	X:151C	Y:0066	D:0100	DB:7F	S:06F7	P:envMXdizc	HC:0358	VC:000	00	FL:224
$CF/FEAA	C2 30	REP #$30	A:0070	X:151C	Y:0066	D:0100	DB:7F	S:06F7	P:envMXdizc	HC:0370	VC:000	00	FL:224
$CF/FEAC	60 	RTS	A:0070	X:151C	Y:0066	D:0100	DB:7F	S:06F7	P:envmxdizc	HC:0376	VC:000	00	FL:224

I've attached an IPS patch with the changes.

[attachment deleted by admin]

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on November 16, 2008, 12:46:50 pm

Quote from: Mauron on November 16, 2008, 11:48:42 am

Quote from: Vehek on November 14, 2008, 11:23:18 pm
7E967C seems to represent the sprite assembly size for all three PCs in battle.
It doesn't. The next two bytes are definitely PCs 2 and 3.

Originally all three bytes were set to 0 along with a larger section with this code:

Well, I only did some brief tests and noted that all 3 characters collapsed into junk.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 16, 2008, 01:47:44 pm

Oh damn. Mauron, I assume your code changed the PC character sprites in-battle to Size 1 assembly, and they were locked into Size 0 assembly prior? That's bad. So the game engine may have been forcing Size 0 assembly in-battle all this time? That would explain why Slash's sprite collapsed in-battle but didn't overlap Lucca's.

Looks like what we would need, theoretically, is a way of changing where the game loads player character sprite tiles into VRAM. Not even sure if it's possible though. My guess is we're looking at heavy ASM hacking.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Mauron on November 16, 2008, 05:52:32 pm

Quote from: FaustWolf on November 16, 2008, 01:47:44 pm

Oh damn. Mauron, I assume your code changed the PC character sprites in-battle to Size 1 assembly, and they were locked into Size 0 assembly prior? That's bad. So the game engine may have been forcing Size 0 assembly in-battle all this time? That would explain why Slash's sprite collapsed in-battle but didn't overlap Lucca's.

The new code should be loading the proper size for PC sprites in battle, based on what's stored in the sprite data. It seemed to be working properly in my testing.

Quote from: Vehek on November 16, 2008, 12:46:50 pm

Well, I only did some brief tests and noted that all 3 characters collapsed into junk.

7E967C-7E967E seem to spill over into the next sprite(s) when set to higher values.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on November 21, 2008, 08:12:53 pm

Yeah, the new code seems to have no effect when all player characters are Size 0, so it's working correctly as far as I can tell (just checked on a fresh unheadered ROM).

This is an encouraging development though -- we would essentially have to use Mauron's patch if we ever did solve the Size 1 sprite dilemma, since the game engine normally forces Size 0 in battle from what I understand. Thanks!

EDIT:
Latest version of the sprite offsets list is attached. It's structured much more in line with what Chrono Tweaker had, taking sprite headers into account. With this document complete, I can move on to examine sprite animations. But first, I'm going to see if I can develop the skill necessary to find out how the game loads sprite tiles in VRAM.

[attachment deleted by admin]

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Chrono'99 on December 29, 2008, 08:12:38 am

I noticed that some palette indexes don't seem to be used by any sprite according to this document (Sprite Palette Index 7 for instance). Does this mean they can safely be used as custom palettes for sprite graphic hacking? Or are they used somewhere else in the game, like weapons or battle effects perhaps?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: justin3009 on December 29, 2008, 10:32:55 am

I think the ones that are just one solid color can be used for what you want. I think it was 7 8 9 that was solid gray. I believe if they're something like that, then they're nothing important.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on December 29, 2008, 02:32:59 pm

There are a good 30 palettes referenced by neither NPCs or enemies. Unfortunately, I don't know if their data is used by other things. Is there a good way to check?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on December 29, 2008, 03:24:45 pm

D'oh! I never uploaded the much more readable version of this document. It's attached in the first post now, and I'll get it on the Compendium modification page too, sorry about that.

I've made lists of palettes used for sprites and backgrounds, but haven't for weapons and overworld sprites yet. I guess the overworld backgrounds would need a palette list as well. So I know the following objects have palettes applied to them:

Sprites (done)
Overworld Sprites
Field Backgrounds (done)
Overworld Backgrounds
Weapons
Layer 1 Effects Graphics

Am I missing anything?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: justin3009 on December 29, 2008, 04:51:36 pm

I think that's all of them. I think the next big step we'll have to take is label all animations of characters so we have an easy list to go through. Maybe Geiger can implement the "Scroll Down Animation" when you want to change it if we get them labeled.

On another note, I've been going through some of my Hex notes. Should I go through and put the exact values of where each text thing is? Then post it here for easier organization.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on December 29, 2008, 05:17:21 pm

I guesss we could just make this an "offsets repository" thread.

Anyone know if Layer 3 spell effects have palettes? I didn't see any option for changing it in jsondag's tech editor.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: justin3009 on December 29, 2008, 05:26:18 pm

Window Elements

Quote from: justin3009

3FC457 (D7 C4) - Character Stats On Left
3FC459 (ED C4) - LV**
3FC45B (F4 C4) - TIME 00:00/ ######G
3FC45D (14 CA) - Power, Speed, Evade, Hit, Magic, Magic Defense, Stamina, Experience, Next
3FC45F (35 C5) - Character Name, Level, Power, Speed, Evade etc...#'s
3FC461 (81 C5) - Nothing?
3FC463 (BE C5) - ??? Something to do with character stats
3FC465 (ED C5) - Weapon Text
3FC467 (F4 C5) - ??? Nothing?
3FC469 (FD C5) - ??? Some sort of Stat
3FC46B (5A C6) - "Exchange" Icon/Text
3FC46D (6E C6) - "Who'll you replace?" Text
3FC46F (83 C6) - "Use/Move Organize" Text
3FC471 (98 C6) - Item Icon (In Item Menu)
3FC473 (A2 C6) - All Icons in Settings Menu
3FC475 (5A C7) - 1 2 3 4 5 6 7 8 (Selection)
3FC477 (65 C7) - Confirm Cancel Menu Dash Warp
3FC479 (87 C7) - Erase old Save File? Yes No
3FC47B to 3FC480 (A6 C7) - New Game +
3FC481 (B3 C7) - New Game
3FC483 (BE C7) - Time ######G Save # xxx
3FC485 (DF C7) - Save File Character Stats
3FC487 (E0 C4) - Attack/Defense Data
3FC489 to 3FC48B(02 C8) - Can't do that!
3FC48D to 3FC496 (11 C8) - 1 2 3 (Tech Menu Icon)
3FC497 (2B C8) - Character Stats/MP Used (Tech Menu)
3FC499 (6B C8) - Skill Points Need ###
3FC49B (80 C8) - ???
3FC49D to 3FC49F(C4 C8) - Active Wait
3FC4A1 (12 C9) - Erase old Save? Yes No
3FC4A3 (A6 C7) - New game +
3FC4A5 to 3FC4BE(2D C9) - Equip
3FC4BF (41 C9) - Buy
3FC4C1 (37 C9) - Sell
3FC4C3 (4B C9) - Buy Sell
3FC4C5 (55 C9) - #######G (Shop menu)
3FC4C7 (67 C9) - Blank?
3FC4C9 (71 C9) - AttacK:
3FC4CB (7A C9) - Defense:
3FC4CD (BE C8) - ???
3FC4CF (83 C9) - Buy Sell # Owned
3FC4D1 (A8 C9) - Blank?
3FC4D3 to 3FC4D5(AC C9) - 0-9 A-Z etc..(Name Screen)

Finnish CT VWF

Quote from: justin3009

109c1 - Item VWF List Battle
10B5B - Tech VWF List Battle
025A90 - Repoints the tech learning names to the area you changed it too.
025AD2 - Repoints the monster names to the area you changed it to.
025BA1 - Repoints the item finding to the area you changed it to.
2A57D - Change this so item names don't copy themselves over.
2A5AA - Equip VWF List
2B053 - Items VWF List
2BDB2 - Tech VWF List
CD9FD - Tech Pointer Pointer
0CDA0F - Monster Name Pointer of Pointers - 1EE1ED
0CED13 - Monster Name to load in Battle

Other

Quote from: justin3009

1C25A - Tech Targetting Pointer
025D3F - "You learned {tech}" length.
111AB - Change this and it'll change what direction the hand moves when you press "Down"
111AD - Change this and it'll change what direction the hand moves when you press "Up"
111B6 - Change this and it'll change what direction the hand moves when you press "Down"
111CC - Change this and it'll change what direction the hand moves when you press "Right"
1134D - Change this and it'll change what direction the hand moves in TECH SELECTION IN BATTLE when you press "Right"
10938 to - 10958 - Change to FF's and the menu selection in battle...is weird
10B8C - Edits X Position of Tech names
10BB2 - Change to 50 so it doens't so "hni" when scrolling
10BC3 - X coordinates of "Double technique" and "Triple Tecnique"
0CED20 - Monster Name Routine

Mauron Level Stats

Quote from: Mauron

01F7D2 - Max possible level
01F865 - Same
01F827 - Same
3FCF3A - Lowest level where ** shows up
3FCF33 / 3FCF35-3FCF39 - Max # on stats

Edit: Menu Data

Quote from: justin3009

Japan Name Screen Data
==============================
3FC215 - Japan (Final) Name Holder Width
3FC216 - Japan (Final) Name Holder Height

3FC21A - Japan (Final) Name Box X Coordinate
3FC21B - Japan (Final) Name Box Y Coordinate

3FC222 - Japan (Final) "Enter your name" Height
3FC223 - Japan (Final) "Enter your name" Width

3FC244 - Japan (Final) Letters in Naming Screen X Coordinate

English Name Screen Data
==============================
3FC3CA - Name Holder X Coordinate
3FC3CB - Name Holder Y Coordinate

3FC3CC - Name Holder Width
3FC3CD - Name Holder Height

3FC3D1 - Letter Box X Coordinate
3FC3D2 - Letter Box Y Coordinate

3FC3D3 - Letter Box Width
3FC3D4 - Letter Box Height

3FC3D9 - "Enter your name" Height
3FC3DA - "Enter your name" Width

3FC425 - "Crono" X corrdinate
3FC426 - "Crono" Y corrdinate

02E421 - X coordinate of letters!

3FC3F0 - Y coodrinates of Portrait and Name?
3FC3FB - Letters in Naming Screen Y Coordinate?

02E45C - Portrait X Coordinates (subtract or add 2 bytes)
02E4A4 - Portrait Y Coordinates

3FC3F5 - Possibly something to do with the hand's X coordinates?
3FC410 - Possibly something to do with the hand's X coordinates?

02E2BF - The Y position of the hand after you move it left or right.
02E2EA - The X position of the hand after you move it left or right.

02E458 - Possibly important for 8th character

02E465 - Y Coordinate of Top Pointer
02E471 - Y Coordinate of Bottom Pointer
02E35A - Pointers X Coordinates

02E4EA - X coordinate of "Enter your name then push the" part
02E4FB - X Coordinate of "Start Button" part

02E467 - Naming Screen Pointer Things

7E0F08 - Current Column
7E0F09 - Current Row

English Extending Letter Selection Naming Screen
==============================
02E31A - Change to 0C to allow more letters to be selected from the Right (2 letters more)
02E54F - Change this number for how many letters appear on each row
02E2DB - Change to 0C to select 2 more letters on the Right
02E2D5 - Change to 0A and you can press back or right to go to 12th letter
02E2D3 - Change to 0B and you can select the 12th letter when you press left

02E2AF - Change this and it'll extend how many letters per column
02E2AC - Change this, if you press down, it'll go up to w/e # of letters you set.
02E2A7 - Change this, if you press up, it'll go down to w/e # of letter you set

Japan Extending Letter Selection Naming Screen
===============
029202 - Change to 0C to allow more letters to be selected from the Right (2 letters more)
02E6AC - Change this number for how many letters appear on each row
02E3BF - Change to 0A and you can press back or right to go to 12th letter
02E3BD - Change to 0B and you can select the 12th letter when you press left

02E3b6 - Starting
02E399 - Change this and it'll extend how many letters per column
02E396 - Change this, if you press down, it'll go up to w/e # of letters you set.
02e391 - Change this, if you press up, it'll go down to w/e # of letter you set

02E3A9 - The Y position of the hand after you move it left or right
02E3D4 - The X position of the hand after you move it left or right.

0258BB to 0258DC - Routines load text character, and checks type
0258C4 - How far it reads for substrings

Battle Mode
==============================
3FC42F - Battle Mode X Coordinate
3FC430 - Battle Mode Y Coordinate

3FC438 - Active/Wait Description Box X Coordinate
3FC439 - Active/Wait Description Box Y Coordinate

3FC43A - Active/Wait Description Box Width
3FC43B - Active/Wait Description Box Height

Character Replacement
==============================
3FC457 - Beginning Data?

3FBF0E - Character Replacement Width
3FBF0F - Character Replacement Height
3FBF10-12 - Box design of First Column

3FBF13 - First Column Character X Coordinates
3FBF14 - First Column Height (Maybe Y Coordinate?)
3FBF15 - ???
3FBF16 - Box Height First COlumn?
3FBF17 - ???
3FBF18 - Last 3 Boxes First Column X Coordinate <--
3FBF19 - Last 3 Boxes Background First COlumn Y coordinate
3FBF1A - Last 3 Boxes First Column X Coordinate -->
3FBF1B - First Column Y Coordinate Boxes
3FBF1C - 2 Boxes/First COlumn Width

3FBF1D-1E - ??? Box Underneath "Who'll you replace"

3FBF1F - 2nd Column Box Design
3FBF20 - Same as Above
3FBF21 - 2nd Column X Coordinates
3FBF22 - 2nd Column Height (Maybe Y Coordinate?)
3FBF23 - 2nd Column Background Box Width
3FBF24 - 2nd Column Background Box Height
3FBF25 - ???
3FBF26 - Background Design
3FBF27 - Background Design
3FBF28 - Background Design speed?

Main Menu Editing
==============================
3FB808 - Menu Editing

3fB825 - Character Scrolling Main Menu Editing
3FBBB0 - 3FBC57 - Set all to FF and menu has no shading
3FBD5C-3FBD73 - "I have listed as Coordinates and other data for six main menu icons" (Quoted by: Geiger)
3FBD75 - X coordinates of Power/Evade/etc..
3FBD7D - Gold Text Modifying
3FC4FC - Gold Modifying
3FBD7F-80 - Time X Coordinate

3FBD84 - PWR SPD EVA etc Text Modifying
3fBD85 - PWR SPD EVA etc X Coordinates
3fBD86 - PWR SPD EVA etc Y Coordinates

3fBD89 - Menu X Coordinate (Messes up graphics =/)
3fBD8A - Menu Y Cooridnate (Messes up Graphics =/)

3fBD8E - Character Scrolling Menu X Coordinate (back)
3fBD8F - Character Scrolling Menu Y Coordinate (back)
3fBD90 - Character Scrolling Menu Width
3fBD91 - Character Scrolling Menu Height
3fBD93 - Character Scrolling Menu Bottom 3 Objects Width
3fBD94 - Character Scrolling Menu Bottom 3 Objects Y coordinate
3fBD97 - Character Scrolling Menu Bottom 3 Objects Height
3fBD99 - Character Scrolling Column Menu Height

3fBD9C - Character Status X coordinates
3fBD9D - Character Status Y coordinates
3fBD9E - Character Status Width
3fBD9F - Character Status Height
3fBDA9 - Character Stat Spacing

3fBDB1-2 - Character 2-8 MP Y coordinate

3fBDB5 - Start of Editing Column

3FBE11 - Character Stats X Coordinate Menu
3FBE12 - Character Stats Y Coordinate Menu

3FBE20 - Characters Name/LVl Text Modifying Status

3fC53C-41 - Editing the text "Level **"
3FC38D - Editing "Level **" text (JP FINAL)
3FC542 - Edits the max level symbol 07 = Star * 09 = 00
3FC546 - Pwr Hit Mag ** editing
3FC549 - Edits Max symbol for Power 00 = ** 0a = 99
3FC4D8 - Name Pointer in Menu
3FC4ED - "LV" text modification
3FC557 - SPD EV STAM ** X COORDINATE
3FC55F - SPD Max Symbol Editing
3FC564 - STAM MAX SYMBOL EDITING
3FC56A - M.Def ** X coordinates
3FC56D - M.def Max Symbol editing
3FC5BF - How many letters appear in Menu (Gets rid of 1 ><)
3FCB04 - Prelease (Same as above)
3FC5C3 - Pointer for "LV" Text
3FC5CA - X Coordinate of Health Points
3FC5D5 - Editing / That seperates the HP
3FC5DE-DF - Editing the blank spaces between MP
3FC5E5 - Editing / that seperates MP

3FBE11 - Character Stats X Coordinate Menu \
3FBE12 - Character Stats Y Coordinate Menu / These move the ENTIRE status, including name, attack, defense etc..
3FBE20 - Characters Name/LVl Text Modifying Status?

3FC5BD-3FC5C1 - General Area for Character Name

MP Data
==============================
3FC5E2 - Change to 22 for 3 digit MP. Works Partially.
3FC5E8 - Change to 22 for 3 digit MP. Works Partially.
3FC7FE - Change to 22 for 3 digit MP. Works Partially.

3FC5DB - MP Letter
3FC5C5 - HP Letter

3FC4DB-3FC4E5 - Attack Data (Including Icon)
3FC5CD-3FC5DA - HP Data xxx/xxx
3FC5DE-3FC5EB - MP Data xx/ xx

Character Stats
==============================
3FC4E6 - Defense Symbol/Stat Editing
3FC4DD - Attack symbol/Stat Editing

3FC503 - PWR. text editing
3FC507 - PWR. Stat Editing

Exchange Menu Data
==============================
3FBF51 - Exchange Text Selection
3FBF53/3FBF49 - Exchange X coordinates
3FBF54 - Exchange Y coordinates

Unsure
==============================
02EC45 - Character Portrait Height?
3FBD85 - 0F 12 = Stat X Coordinates

3FC3BC - Naming Screen data
3FC205 to 3FC271 Japanese Naming Screen Data

Other
==============================
0281AC - Hand Icon
029B17 - Edits the surround tiles in menu
029C0A - Positioning of Menu Pointers
0281A4 - Pointer for Selecting Character Coordinates/Graphics
x29EA7 - Main Menu Pointer ??

3FB718 - Editing position of Menu stuff

3FC6A2 - 3FC730? - Menu Settings Editing - Menu Settings Editing
3FC815 - Menu Tech Editing

3FC8F4 - Shop Editing

3FCBB6 - Edits the outline of the text if it's a "NEW" item
3FCBBB - Edits the color of the text if it's a "NEW" item

Battle Menu Editing
==============================
CFADF - Change this and it'll move the X position of where the hand moves when selecting something.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on February 16, 2009, 03:03:38 am

Anyone who's familiar with the animation data format, how do the following data sets differ?

243000 24A5FF ANI N Character animation data 2003.07.07

24A800 24CC5F ANI N Uncomfirmed animation data 2003.07.07

Reviewing notes left earlier, it's my current understanding that the data beginning @ 0x243000 determines which sprite assembly frames are called up for each animation, and the data beginning @ 0x24A800 is what specifies the number of frames that compose each animation.

However, if I do the math with Crono as an example, it turns out that the data at 0x24A800 would give Crono 0x128 (dec 296) animations if each byte in that dataset is a framelength identifier, so I'm puzzled. There shouldn't be any more than 0xFF animations per character as far as I know.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: justin3009 on February 16, 2009, 08:56:05 am

243000 24A5FF ANI N Character animation data 2003.07.07 - This is what frames are used in the animation.
24A800 24CC5F ANI N Uncomfirmed animation data 2003.07.07 - This is the length of each animation and how fast they move. Higher the #, slower they are.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on February 16, 2009, 02:32:14 pm

Ah, okay, so there's something else in the 24A800 data set. Is there one byte that says how long the animation is and one byte that tells how fast for each animation?

So, let's say I want to make a random dude do a three-frame walking animation, and those three walking frames are the first frames in the sprite assembly.

Would I specify the frames 00 01 02 in the 243000 animation data set, and specify 02 as the frame length of the first animation in the 24A800 animation data set? Unless three frames is represented by the byte 0x03.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on February 16, 2009, 02:36:34 pm

There's no byte saying how many frames an animation is.
I've explained how the game finds the start of each animation before: 4 * animation_number + start of animation data for the current direction.
The 24A800 animation data specifies how long each frame of an animation is shown. Each byte there controls one frame. It's applied to all four directions.

I'm not sure, but I think the game keeps on reading animation frames until it hits a 0xFF frame or a 0x00 frame length.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on February 16, 2009, 03:51:44 pm

Okay, by "frame length" I totally misunderstood and thought it meant the number of frames per animation as opposed to display time length.

Let's examine some code. Here's Crono's animation data:


00243000  03 FF 00 00 16 17 18 19 - 1A 1B FF 00 C6 4F C7 4F
00243010  FF 00 00 00 64 FF 00 00 - 20 41 21 22 42 23 FF 00
00243020  45 FF 00 00 6E FF 00 00 - 4F 3A 39 38 6C 6D FF 00
00243030  38 39 3A 4F FF 00 00 00 - 49 8D 8E 49 FF 00 00 00
00243040  71 72 71 72 71 FF 00 00 - 47 48 FF 00 00 FF 00 00
00243050  00 00 00 00 2C 6C FF 00 - 03 93 FF 00 97 03 98 03
00243060  FF 00 00 00 A5 FF 00 00 - CC CD FF 00 68 69 6A 6B
00243070  FF 00 00 00 47 FF 00 00 - 7C FF 00 00 7B FF 00 00
00243080  79 FF 00 00 00 9F A0 FF - AC AD FF 00 87 FF 00 00

Crono's first two animations are highlighted. So, the FF byte is a termination instruction and any 00 bytes that follow serve as buffers to ensure the next animation begins at a multiple of four. Am I correct on that guys?

Given that this is correct, now for another question -- in the above example with Crono, I think the red animation is "standing-front." If so, is the byte 03 telling the game engine to call up the third frame in Crono's sprite assembly? (or would it actually be the fourth frame, with 0x00 representing the first frame?)

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: justin3009 on February 16, 2009, 04:07:19 pm

It'd be the 4th frame if what I'm seeing is correct. Also, yea I believe you're right on that. I haven't done anything with the 00's in front of the actual data, so I think this is a safe guess for right now.

Yes, I think you're correct on that because 00 is him Facing Foward.

Also, another note that is somewhat related is that Size 5 Sprite Assembly for example Lavos is 80 bytes in length.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on February 16, 2009, 04:12:20 pm

I'm confuzzled as to why Crono's first animation reads "03 FF 00 00." The byte 0x03 would seem to call up Crono's fourth frame in sprite assembly, but isn't standing-front Crono's very first frame? Why doesn't it read "00 FF 00 00"?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on February 16, 2009, 04:15:52 pm

Animation data starts with the frames for Facing Up. After that is Facing down, and I don't remember off-hand which order Left and Right go in.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on February 16, 2009, 04:21:58 pm

Oh, okay, sweet. Thanks. It's all clear now.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on February 20, 2009, 02:03:42 am

Is there really a "Size 5 sprite assembly"?
Even though the game may have such large values in its sprite data, that doesn't mean those sizes exist.
At least in the field, the game ANDs the sprite size value with $03.

And 80dec bytes is the size of a size 1 assembly.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on February 20, 2009, 03:37:31 am

I haven't tested it out myself. justin says he's worked with it. If not, might it be possible to make large enemies by putting several Size 1 sprites together? That's basically what happens with Giga Gaea's hands and Queen Zeal, although de-syncing of animation and partial flashing during attacks would be problematic.

I noticed some really wild sprite assembly size numbers were associated with flying enemies (bell birds and so forth) as expressed in Chrono Tweaker. That's going to be interesting.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: justin3009 on February 20, 2009, 08:57:15 am

It might be size 3. I was working with ChronoTweaker and it labeled Lavos as Size 5

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Shee on February 20, 2009, 05:33:09 pm

See, reading something like this makes my head hurt. How in the hell do y'all find this stuff? And even more importantly, how in the hell did y'all find out how to manipulate and use it? Rabble rabble rabble. It's just like...you know....um....I'm behind on the whole damn thing here. Still gettin' the hang of "eventing." And it looks like this stuff ehre could really take it to the next level.

Granted, I have considerably less time these days then when I joined back in December, so the learning curve is a slower process. I don't think I used that last phrase correctly, but it serves it's purpose. Regardless, I have to start putting my brains back into my head...

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on February 20, 2009, 06:16:14 pm

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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Mauron on March 11, 2009, 07:20:00 am

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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on March 11, 2009, 03:29:51 pm

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?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Mauron on March 11, 2009, 03:36:23 pm

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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on March 11, 2009, 04:35:28 pm

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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Mauron on March 11, 2009, 07:54:22 pm

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. >_<

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on March 11, 2009, 08:19:00 pm

There's some docs on SNES DMA (http://www.romhacking.net/?category=&Platform=&game=&author=&perpage=20&page=documents&level=&docsearch=Go&title=DMA&desc=) 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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Mauron on March 11, 2009, 08:36:29 pm

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.

Quote

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.

Quote

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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on March 12, 2009, 03:38:56 am

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

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Mauron on March 12, 2009, 03:52:11 am

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

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on March 12, 2009, 03:55:32 am

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

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on March 12, 2009, 04:23:20 am

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.
(http://img13.imageshack.us/img13/757/image2wtn.png)

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.
(http://img13.imageshack.us/img13/9035/image3oci.png)

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.
(http://img13.imageshack.us/img13/5427/image1qkb.png)

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on March 12, 2009, 03:29:25 pm

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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on March 13, 2009, 03:01:18 pm

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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on March 13, 2009, 04:09:03 pm

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.
(http://img187.imageshack.us/img187/1296/image1czp.png)

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on March 13, 2009, 05:08:51 pm

(http://i239.photobucket.com/albums/ff83/TtravelrKev/Misc CT Stuff/SlashTest.png)
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!
:D :D
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.
(http://i239.photobucket.com/albums/ff83/TtravelrKev/Misc%20CT%20Stuff/SlashSprite1_00000.png)(http://i239.photobucket.com/albums/ff83/TtravelrKev/Misc%20CT%20Stuff/SlashSprite1_00001.png)

Code: [Select]

$C0/42CF A9 00 00    LDA #$0000
$C0/4344 A9 20 00    LDA #$0020
$C0/43F7 A9 40 00    LDA #$0040

A size 1 sprite needs 0x40 bytes of space here to work correctly.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Mauron on March 21, 2009, 02:35:42 pm

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

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: justin3009 on March 21, 2009, 02:39:12 pm

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 :P

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on March 21, 2009, 02:48:02 pm

:lee:

Vehek, have you got a patch for this? Holy shit, holy shit, holllllyyyy shiiiiit!
(http://img23.imageshack.us/img23/4640/awinnerisyou1.gif)

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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Mauron on March 21, 2009, 03:39:05 pm

Quote from: FaustWolf on March 21, 2009, 02:48:02 pm

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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on March 21, 2009, 03:54:28 pm

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:
(http://img18.imageshack.us/img18/3354/image1iuk.png)
(http://img18.imageshack.us/img18/7749/image2xdg.png)

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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Mauron on March 21, 2009, 04:02:16 pm

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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on March 21, 2009, 07:13:06 pm

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          TAY

The 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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on March 21, 2009, 11:08:00 pm

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:
(http://img19.imageshack.us/img19/5555/image2ngn.png)
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?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on March 22, 2009, 03:07:40 am

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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Mauron on March 22, 2009, 06:43:27 am

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

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Chrono'99 on March 22, 2009, 07:40:49 am

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)

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on March 22, 2009, 03:36:17 pm

Quote from: Mauron on March 22, 2009, 06:43:27 am

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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on March 22, 2009, 03:53:33 pm

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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on April 14, 2009, 02:27:59 am

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.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on April 14, 2009, 05:57:01 pm

Huge thanks for updating Vehek.

So the pattern is...

Size 0
Value: 0x00
Normal Hex viewing window (16-byte rows)
4 Tiles

Size 1
Value: 0x01
Double Hex viewing window (32-byte rows)
8 Tiles

Size 2
Value: 0x02
Normal Hex viewing window (16-byte rows)
12 Tiles

Size 3
Value: 0x23
Double Hex viewing window (32-byte rows)
24 Tiles

And Size 3 is the max sprite size? There were some really weird sprite size values for flying enemies (Bellbirds and such) in Chrono Tweaker as I recall, and I'm not sure what was up with that.

EDIT: Observed values added per Chrono '99's observation below. It's possible that only the second nybble of the observed values recorded herein are actually responsible for determining number of tiles, whereas the first nybble may control some other aspect of the sprite.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Chrono'99 on April 14, 2009, 06:54:02 pm

The Lavos Spawn shell is Size 3 but has a value of 23 (in hex) for its sprite size. Maybe the second half-byte is the actual sprite size and the first half-byte is something else?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: FaustWolf on April 15, 2009, 01:49:31 am

That would probably explain why I thought the flying enemy size values were weird. It would be really rad if the first nybble controlled animation (since Size 3 sprites observed so far do not have animations enabled per conversation elsewhere).

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: TheMage on February 21, 2016, 08:18:55 pm

Bumping this to the first page because I keep losing it and desperately need it's help. I'm trying PC insertion. Curse you sprite assembly.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Shishisenkou on March 17, 2016, 02:32:47 pm

It's overall not that bad, though, by raw hex it is a pain. There was a mini editor.. I think Chickenlump did way back, minus that, there IS a Japanese program that was semi-translated. Chrono Chara Viewer I think? Makes it a lot easier to handle sprite assembly though I'm not sure if it's bug free or not.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Vehek on March 18, 2016, 12:22:58 am

She already knew about that program.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: TheMage on March 18, 2016, 07:33:29 am

Thanks! Yeah I have Chrono Charaview and Vehek has been helping me a lot along with other compendiumites I'm just technologically impared. My biggest issue at the moment is the bug. On the 2nd page of chronocharview it doesn't let me click. Vehek, you told me the only way to place those tiles is by editing the data in the "Tile info" box, and I have to know the tile number.

Can you or anyone give me an example of this?

It's not like when I was editing the tilesets and had to use a hex editor to get the packet numbers right? It's something much simpler like the tile number of blank out of blank. (16x16?)

I'm a visual learner so when I read tile number my mind jumps to so many different things. XD

Also does anyone have the one Chickenlump did?

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: justin3009 on March 20, 2016, 10:13:43 am

Chrono Charaview is the better one out of them since you can get an actual 'visual' of what you're seeing. If needed though I can upload Chickenlump's.. or Geiger's. Honestly not sure who did it, I'm pretty sure it was CL.

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: TheMage on March 20, 2016, 05:50:45 pm

Oh! than I best stick with Chronocharview if it's more visual! Turns out I was over thinking it! I think I got it!

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: TheMage on September 26, 2021, 01:39:57 pm

Thread Necromancy because I need this~

Title: Re: Chrono Trigger Sprite Insertion -- Development of a Guide
Post by: Zakyrus on March 02, 2022, 03:12:04 pm

I know I ask this a zillion times, ...how close are we to having this as a Temporal Flux plugin?

Reason I ask is I'm polishing the TUTORIAL VIDEOS, and would like to have as much content as possible...

~Z