Qhimm.com Forums
Miscellaneous Forums => Scripting and Reverse Engineering => Topic started by: L. Spiro on 2005-07-06 15:59:01
-
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 (http://www.0kuntz.com/l-spiro/Shiva.jpg)
Shiva 2 (http://www.0kuntz.com/l-spiro/Shiva2.jpg)
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
-
Cool! I can't wait!
-
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
-
I'm sorry, but what does this breakthrough mean, exactly?
-
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 (http://www.memoryhacking.com/Docs/Battle%20Animation%20File%20Format.doc)
PDF format (http://www.memoryhacking.com/Docs/Battle%20Animation%20File%20Format.pdf)
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)
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? :)
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.
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? :)
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 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
[/list:u]Later Goals for me would be
Run FF8 (PC or PS1) content
Run FF9 content
[/list:u]
Perhaps a new thread for such a discussion? :)
Cyb
-
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.
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 ...
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).
-
Thanks Qhimm however after reading some documentation .. these are the "precise" interpretations of the looney things (grin).
The MSB bit set indicates a translucency mix whereas black IS transparent.
I'm not sure what FF7 uses of these ratios for the playstation but
The ratios for translucency are
1/2 background + 1/2 polygon
background + polygon
background - polygon
background + 1/4 polygon
The data on the playstation is not TMD format that is a certainty.
My Guess on the translucency they use is background +polygon. This is because all the lips are dark and the same thing with eyes and eyebrows. I have to yet again correct all my texture generation code. I'm not sure how to perform this particular operation in OGL so I'll have to look into it.
Cyb
-
I got home and was able to read my notes, so if we want the "precise" details on the looney things, this should satisfy everyone. ;)
(the following is 100% confirmed information, with just a small disclaimer if I made some foul typo)
The PSX GPU has support for the per-pixel blending modes that you mention, precisely (except that "background" and "polygon" can be replaced by the more generic "destination pixel" and "source pixel"). When special transparency processing (STP) is enabled in the GPU, any non-black pixel with the MSB set will be blended with the destination pixel according to the currently selected blending mode. Any non-black pixel with the MSB not set will be directly drawn (not blended). The blending mode and/or STP enable can be changed between primitives (lines, polygons, etc), but within any given primitive only one STP/blending mode is in effect. The MSB can however thus be used to mask the blending effect (giving the "illusion" that two different blending modes are at work on the same primitive).
Black pixels work differently in that they are transparent by default (i.e. not drawn) when MSB is not set, regardless of the current blending mode. Setting the MSB bit of these pixels instead forces the GPU to output a black pixel, also regardless of the current blending mode.
As for guessing what blending modes FF7 uses for models and textures, I'd naturally assume that for the facial texture there is no blending (only black-masking), while any weapons that use translucency (Cloud's ultimate weapon?) uses the additive (destination + source) mode, for that glowy effect. I know from experience that Square loves that blending mode of the bunch. ;)
-
I got home and was able to read my notes, so if we want the "precise" details on the looney things, this should satisfy everyone. ;)
(the following is 100% confirmed information, with just a small disclaimer if I made some foul typo)
The PSX GPU has support for the per-pixel blending modes that you mention, precisely (except that "background" and "polygon" can be replaced by the more generic "destination pixel" and "source pixel"). When special transparency processing (STP) is enabled in the GPU, any non-black pixel with the MSB set will be blended with the destination pixel according to the currently selected blending mode. Any non-black pixel with the MSB not set will be directly drawn (not blended). The blending mode and/or STP enable can be changed between primitives (lines, polygons, etc), but within any given primitive only one STP/blending mode is in effect. The MSB can however thus be used to mask the blending effect (giving the "illusion" that two different blending modes are at work on the same primitive).
Black pixels work differently in that they are transparent by default (i.e. not drawn) when MSB is not set, regardless of the current blending mode. Setting the MSB bit of these pixels instead forces the GPU to output a black pixel, also regardless of the current blending mode.
EIIIE that's a suprise. Ok that makes things interesting I'll have to YET again change my texture processing algo (LOL).
As for guessing what blending modes FF7 uses for models and textures, I'd naturally assume that for the facial texture there is no blending (only black-masking), while any weapons that use translucency (Cloud's ultimate weapon?) uses the additive (destination + source) mode, for that glowy effect. I know from experience that Square loves that blending mode of the bunch. ;)
Actually from my processing the eyebrows are blended but not the lips on cloud.
-
*bump*
Well, I got some sort of rendering working, although I made some silly mistakes until I talked to Qhimm ;) Anyway, http://ficedula.uwcs.co.uk/f2k3/programs/ifalna/ifalna140.zip Ifalna 1.4 has basic support for rendering battle models, if you open the battle.lgp archive ... still unstable, but it basically works.
-
So..... cool....
Just something. When i run the program, an error message appears: Invalid Filename. But the program Run. Do you know why?
EDIT: The only thing now is export/import animation.... Great work Ficedula
EDIT 2: Seems some models crash the program. I try to view RYAA. But the program refuse to work. And crash to windows wihout error. Could be my battle.lgp? RTAA seems to show an error message (but that not close the program) : stream read error
-
I know about some of those errors (it can't decode every model), but you should be able to view RTAA fine. That's Cloud's model, and I was using that to test...!
I'll certainly fix some of the problems, though, when I encounter them.
-
maybe because my spanish FF7?
another issue is: When you want to make png's from the model, you should choose what angle. Always use the front.
-
Umm.... Is it just me, or does this viewer swap left and right 'pants' on a lot of models. That is, the length of Sephi's coat, Aeris' dress, Tifa's skirt, it has the left side and the right side swapped. Or at least both sides are rotated 180 degrees. on the y axis....
-
Rendering error? What rendering error? Look! A three headed monkey!
:P
New download in up (same place as before) with that fixed & frame offsets now taken into account.
-
Nice job L. Spiro! 8)
Nice job Fice! 8)
Can't wait to use it when some of the bugs are worked out. :)
:-? My Zack sure does look weird! (result of Reunion's patch for char.lgp) (http://img162.imageshack.us/img162/9210/zackweird3xn.png)