The S Files (FF7 PC)

[Borde]

Hello everyone.

I'm currently having a look at the S files stored at magic.lgp. It's obvious by now they define 2D animated sprites used during battles. I'm finding hard to understand how it all works, though. I'm starting this thread to compile the knowledge we currently have about them.

Based on Aali's and NFITC1 job, so far this is what I've got about the format:

Code: [Select]

File header:
   unsigned char FileType
   unsigned char Version
   unsigned short UnknownField_2
   unsigned int NumFrames

Frame header:
   unsigned short UnknownField_0
   unsigned short NumSprites

Sprite definition:
   unsigned int Flags
   signed short XTargetOffset
   signed short YTargetOffset
   short XSource
   short YSource
   unsigned short TexturePageIndex
   short UnknowField_E
   unsigned char SourceWidth
   unsigned char W2
   unsigned char SourceHeight
   unsigned char H2

The contents of the sprite is defined by the rectangle starting at (XSource, YSource) and with dimensions (SourceWidth, SourceHeight). These values aren't in standard texture coordinates, they are in pixels instead.

XTargetOffset and YTargetOffset define position of the first pixel of the image on the target surface (most likely a QUAD), being (0,0) the center of said surface.

Although usually these coordinates point directly to regions in TEX files (some are very easy to identify due to file names), sometimes they don't. My guess is here is what Aali called TexturePage comes into play. I think some of the TEX files are compiled by the engine in a single TexturePage (provably they have fixed dimensions, because they will be needed to generate texture coordinates). I don't know where these pages are defined though.

Attributes W2 and H2 are also pretty puzzling. They are usually equal or very similar to SourceWidth and SourceHeight, but sometimes their value is 0. Maybe their purpose is to stretch the sprites?

I hope someone around here can shed any light about this.

Thanks.

[nfitc1]

I suppose it's reasonable that if there's a "source width/height" we'd have a "target width/height" as well. There's not really a way to know other than to drastically change the values and check a side-by-side comparison of the results.

So the 2D animation is in the s files, huh? Maybe I'll take another crack at slowing the animations now that I know that.

EDIT:
That's why I never found them. The exe references them as .spt files! I've already found the functions that handle the summon effects and that's probably all I need to start on.

[Hellbringer616]

I suppose it's reasonable that if there's a "source width/height" we'd have a "target width/height" as well. There's not really a way to know other than to drastically change the values and check a side-by-side comparison of the results.

So the 2D animation is in the s files, huh? Maybe I'll take another crack at slowing the animations now that I know that.

EDIT:
That's why I never found them. The exe references them as .spt files! I've already found the functions that handle the summon effects and that's probably all I need to start on.

Forgive me cluttering up this thread, But i just wanted to say, NFITC1.. you're a BAMF when it comes to reverse engineering. If you get my 60FPS by my birthday (more or less a year) i'll send you $5

[nfitc1]

...you're a BAMF when it comes to reverse engineering...

Yeah *flexes* I know.


I've been looking at explo_1.s and its associated texture file, wind02.tex (PC). So far, what I've noticed so far is this. X and Y are target coords for a dynamic polygon defined and controlled in the animation (maybe). They're signed with 0,0 being the center of the poly. source X and source Y are the coords in the tex file to draw from. The source width and source height, obviously, tell it what size square to read. These values are not always square. They're either 64 or 32 and sometimes 1 or 2 less than that. All of these Sprite entries makes one frame.

It also looks like the TexturePages have to do with the palettes in the CLUT of each tex file. wind02.tex has 5, but it looks like only the first two are used.
There isn't a clear connection between texture and s file. wind00.tim is associated with both fir_1.spt and fir_2.spt. One file handles the top half of the texture and the other handles the bottom half. Again, I think only the first two palettes are considered here.

The Sprite flags are almost always 100h unless the target width/height doesn't match the source, in which case the flags are 300h.

Still trying to find where these are handled. I found one in memory, but I couldn't find where it was being read. It might be handled in the graphics drivers which I can't get a hook on.

[Borde]

Glad to see you working on this NTFIC. And great job, by the way. Sure you're fast.

So X and Y are actually offsets to center the image at target? Yeah, that sound reasonable.

The way these files work is really odd. The case of fir_1.spt and fir_2.spt seems specially strange. bombo_1 to bomb_16 also seem to use a separate S file for each frame, which pretty much seems to defeat the purpose of having a system that can handle the image sequences. Maybe they ran into memory problems? Could it be that the texture where the images are uploaded too has a very limited size (maybe 256x256) and the only way to use bigger images was to define additional S files?

[nfitc1]

I would imagine it's a way to consolidate images for different effects. Lots of them have 16 images that are then defined by the s files in 32x32 pixel chunks. I'm not sure why it translated into the larger images as well. Probably just because it was just easier to use the existing function than to write a new one. Maybe a throw-back from the limitations of the N64 during early development.

These s files just define the frames, they don't actually display them or have any other information about them. I haven't tried searching in software mode, but I imagine the solution to slowing them down is in the graphics drivers. I found one in memory when I loaded it, but the exe didn't touch it after that.

EDIT:
For version, 10h and 20h are accepted. Not sure what the difference is though.

If you want to check it out yourself, S File loading begins at 0x6A2E56.

A few other functions of interest:
0x4B439D
0x5D1FFB
0x68A195
0x809A48 (this is a memory addr)

I really need the wiki back up. Or at least info on the LGP archive format.

[Borde]

I see. Well, thanks a lot for clarifying everything NFITC1. I guess the actual movement patterns, combinations and textures used must be hardcoded somewhere just like other aspects of the effects.

As for tracing the exe, I've got bad memories from when I tried doing so using SoftIce. Anyway, I'm curious, what tools do you use nowadays?

[nfitc1]

I'd never take anything I say in answers to "why" questions as the gospel truth. Most of those kinds of answers are just speculation.

In any case, I (and probably everyone else that does tracing on this) use IDA/Hex-Rays that I...procured...somewhere.

As far as movement and frame advancement go I don't have the slightest idea yet how that works. There's probably some info somewhere, but Aali's driver hooks a lot of functions that handle those things even after I turn software rendering on.
Just getting FF7 to run windowed (practically required for this to work) is a chore.

[Aali]

SPT to TEX mappings are hardcoded into the .exe, so is the actual usage of the SPT files. That is to say, each effect (all hardcoded) defines exactly how its SPT files are used, thats why there are alot of inconsistencies and also why simply changing the SPT file isn't gonna do anything useful for most effects. As if that wasn't enough, alot of other frame-dependent timing is hardcoded into these effects, nothing short of a rewrite of all effects would really solve that problem. I was playing around with a hack to run the code for these effects once every X frame but it was just not working out and of course that wouldn't really give you 60 FPS effects, it would just keep it in sync with other 60 FPS content.

[Borde]

That's what I feared. It sounds like getting everything to run properly would require an awful lot of work. Thanks for the information Aali.

I can't help but feel this whole STP system comes from some early implementation that became too rigid somewhere during the development and ended up having a marginal purpose.

[nfitc1]

...alot of other frame-dependent timing is hardcoded into these effects, nothing short of a rewrite of all effects would really solve that problem. I was playing around with a hack to run the code for these effects once every X frame but it was just not working out and of course that wouldn't really give you 60 FPS effects, it would just keep it in sync with other 60 FPS content.

This is the same conclusion I was forced to accept after seeing how these effects are handled. I haven't tried to rewrite anything yet just because of the sheer number of effects (nearly 500). I was hoping to trim that down a bit, but I still don't know where the frames are being generated.

However, with the sheer number of blank spaces in the exe it might be possible to write a few helper functions to aid in that process. It would still be virtually 15fps, but the timing of the display would be much simpler than the animation frame count being bumped up and interpolating more images to be used.