Battle Animation Format

  • Thread starter Thread starter L. Spiro
  • Start date Start date
Status
Not open for further replies.
L

L. Spiro

Guest
I decoded it last Sunday but I didn’t say anything for two reasons.
1: I wanted to add it to my own engine to test it on all models.
2: I wanted to present it in a nice clean manner that is easy to understand.


I have already begun on the format description document.
After having used it in my own engine, I have found 100% success with all models.
Everything loads perfectly, and I applied some interpolation to smoothen everything out (with my engine running at such a high frame rate and resolution, it is very easy to see how jerky the animations are).


Shiva 1
Shiva 2

You can clearly see her animation from these shots.
Both shots are fully interpolated, so in fact what you are seeing is a frame between her real frames.

It’s very smooth this way and will make a nice addition to my engine options list.


Anyway, I have been slow about writing out the decoding routine mostly because I am having fun with my own engine now that things are moving.

But I will post code on how to decode them so mirex and the others can make models move for whatever projects they may have in the future.


L. Spiro
 
Congradulations, L. Spiro!

Hey Qhimm, this is a motion to give L. Spiro a special title for what he's done! God knows people have been befuddled over this one for long enough, he deserves some kind of reward.  :D
 
Well for one, it is a major step towards finishing my own project.

For another, it means tools such as BitTurn can now show the models AND animate them.
For another, those same tools can now have the ability to edit the animations.

Fourthly, it adds a major chunk of knowledge to the database that composes this site.
This site, if I am not mistaken, was originally intended to be an in-depth knowledge base for Final Fantasy® VII.
Of course there were other motives, but a large factor is just to discover every deep dark secret the game has, including all file formats.


The battle animation file format has held us up for years, being bit-stream compressed.


As for the document I mentioned, it will be ready tonight.
After my ritualistic Thursday-night Naruto-fest, I will finish the description of the file format.
All that remains is to put into it some code that fully loads each frame.


[EDIT]
I have put up the documents.
DOC format
PDF format

File format exposed, complete with two versions of code that should be enough for anyone to get the files loaded correctly.

Also thanks go to Qhimm for his input, which I included in the files.
[/EDIT]


L. Spiro
 
Ah! I *knew* that the animation must of been delta compressed. Cool work.

(Oh, I'm doing college full time now, That's where I've been)
 
Smooth !!   :love:
I have already anim interpolation in biturn so i only need to add the reading procedure ... I should add it also to Leviathan ... only if I had more free time ... :(
 
New taunt animations for characters.  Now. :P :wink:

But seriously....GOOD JOB, L. SPIRO!!

The animation interpolation gives me an idea, though.  We should see if we can use the interpolation to re-record a "more fluid" animation to replace the original one, so that we see the newer, more fluid one in-game? 8)
 
New taunt animations for characters.  Now. :P :wink:

But seriously....GOOD JOB, L. SPIRO!!

The animation interpolation gives me an idea, though.  We should see if we can use the interpolation to re-record a "more fluid" animation to replace the original one, so that we see the newer, more fluid one in-game? 8)
Click to expand...
I know you don't want to hear this but that won't work. All you will suceed in doing is making a longer animation. Since the game engines frame rate is fixed.   That might be something you could do in a FF7 compatible engine however and it can be done in real time instead (like Quake 2 does with it's animation).  Like cubic spline interpolation would be the best (as it goes through the data points where as most others approximate it).  The performance penalty I suspect would be tiny since today's processors are 1 VERY fast compared to when FF7/8 came out, 2 the memory available is much larger, 3 the graphics systems are MUCH faster.

Let me see. SFFVM Square Final Fantasy Virtual Machine? :)

Cyb
 
Let me see. SFFVM Square Final Fantasy Virtual Machine? :)
Click to expand...

So, maybe it's finally time to stop dreaming and start to create a programmer group then, hm?  8)

BTW: Great work, L. Spiro.

 - Alhexx
 
I know you don't want to hear this but that won't work. All you will suceed in doing is making a longer animation. Since the game engines frame rate is fixed.
Click to expand...

Hadn't thought of it that way.  Well, back to the drawing board with that idea.... -_-

 :P
 
Let me see. SFFVM Square Final Fantasy Virtual Machine? :)
Click to expand...

So, maybe it's finally time to stop dreaming and start to create a programmer group then, hm?  8)

BTW: Great work, L. Spiro.

 - Alhexx
Click to expand...
I suppose one could do that. So the first thing would be to define the goals.  My List of goals would be


  • Run PS1 or PC original content
    Run on PC (first) and other platforms (requires high portability to be a priority)
    Modular design so modules can be improved without having to recompile the entire program and allow for co developement of components
Later Goals for me would be


  • Run FF8 (PC or PS1) content
    Run FF9 content
Perhaps a new thread for such a discussion? :)
Cyb[/list]
[/list]
 
That's cool and all, but we have only 10% of the field opcodes decoded, along with < 1% of the worldmap files...

Heck, the savemap in Gears is borked because the offsets are incorrect somewhere in the middle
 
Yes, but on the other hand, we can talk about how fine it would be to write an  engine and so... but we have to start somewhen when we do not want it to be a dream forever.
BTW: When there is a project, and file formats need to be decoded for that project (as in our old Remake days), then people start working on them... or at least I hope so

 - Alhexx
 
I did this so my own project could proceed, but of course I would share the results.

When you have a project whose end you can actually see, you are more inclined to work hard on hacking and become willing to do whatever it takes to get the task accomplished.

When you sit around and think about what could be done “if only such-and-such was hacked”, that becomes all you do.

It is so eay to dream, dreaming makes you lazy.
Action gets things done and makes dreams come true.


I was pretty sure you had more than that decoded on the world map.
As for the field file BACKGROUNDS, since we can only draw those with errors, I will probably go into that next.
My engine needs that too.


L. Spiro
 
There is an ancient saying 'a little folding of the hands and nodding of the head, and your stomach will be hungry'.  In otherwords you have to work to eat.

Same thing goes with twiddling with FF.

The field format is actually a bit further decoded Spiro Kero has the walk mesh information we have script information. I suppose I ought to actually begin to seriously decode some of it.  I have both PC and PS1 versions of FF so that actually helps.

Part of the anoyance with the field format is it's different between the PC and PS1.  On the PS1 field information is broken between 3 files.  BSX are field models.  DAT contain all the control and structure information for the field file.  MIM contain all the background data, IE animations palettes and such data. The DAT files have to be vivisected but they contain pretty much everything you need to know about the field section including the script program for that field location.

I suppose I need to add some more features to me HEX viewing software (laugh).  IE LSZ decompression over ride on a file.

Cyb
 
Hey mirex, did you ever get the transparent textures/objects done with your Leviathan model viewer?

Thanks,
~Sky
 
Lord_Skylark: no, not at all. I haven't found the transparency information, and I haven't been researching around it much anyhow ... but this info could be somewhere in the 'groups' info of the model ...

When you sit around and think about what could be done “if only such-and-such was hacked”, that becomes all you do.

It is so eay to dream, dreaming makes you lazy.
Action gets things done and makes dreams come true.
Click to expand...
True, true.
 
Lord_Skylark: no, not at all. I haven't found the transparency information, and I haven't been researching around it much anyhow ... but this info could be somewhere in the 'groups' info of the model ...
Click to expand...
Hmmm transparency is handled in textures except in unique cases.  In the PS1 version they set the pallete's bit 15 to 1 for transparancy. It also looks like the use black (which is kind of anoying), is used as well. With some observation I believe black is totally transparent whereas if the transpency bit is set the pixels is partially transparent.

None of the weapons use textures I've noticed, so if a weapon has any transparency, it's likely to be programatically implemented. There appears to be no other information provided with the polygon colors to provide for transparency.
Cyb
 
Black is a special case in that it is transparent by default, unless special transparency is enabled in the GPU (IIRC).
 
Status
Not open for further replies.
Back
Top