Qhimm.com Forums
Miscellaneous Forums => Scripting and Reverse Engineering => Topic started by: Micky on 2004-07-18 12:13:49
-
I had a look a the BCX files, which store the party members on field screens.
The format is similar to the battle models in that it stores the rigidly skinned part separately. But all parts are stored directly after each other, and you have to get the start address from a table at the end of the file.
It has the same problem as the battle models as they are difficult to display without the animation data...
If anyone else wants to have a look: The Caith Sith model is quite good because you can easily identify the vertex colours from vertex, triangle and quad data.
That leaves of course the question where NPC models are stored...
-
I had a look a the BCX files, which store the party members on field screens.
The format is similar to the battle models in that it stores the rigidly skinned part separately. But all parts are stored directly after each other, and you have to get the start address from a table at the end of the file.
It has the same problem as the battle models as they are difficult to display without the animation data...
If anyone else wants to have a look: The Caith Sith model is quite good because you can easily identify the vertex colours from vertex, triangle and quad data.
That leaves of course the question where NPC models are stored...
I believe the NPC's are stored in the BSX files, along with a pile of other stuff the script etc.
Thanks for the information though, I suppose I can setup TV to view those then as well. The animations I suspect are oddly in the BSX file (LOL).
The BSX contain
The script data
Dialog data
likely animations and NPC data.
MIM files contain the actual backgrounds.
Cyb
-
The BSX contain
The script data
Dialog data
likely animations and NPC data.
MIM files contain the actual backgrounds.
That seems to be a mixup, the DAT files contain the script and dialog data.
The MIM files contain the VRAM data, that is 16x16 tiles required to draw the backgrounds and palettes. The data which tiles goes where on screen is part of the DAT file as well, a bit after the dialog data. So far I haven't found a pointer/offset to it so I just found the point manually for a few files.
But your guess sounds good, that the BSX files contain NPCs and animation. But that would be a waste for some frequently used things like the walk animation. And I haven't seen Clouds sword in the BCX file, so it could be part of the field files where you need it.
I'd be interested in knowing where the walkmap is as well.
-
I think we've been trying to find that darned walkmesh for the last four years! I would *REALLY* like for that to be found, along with the camera location, camera range, and floor triggers. That's really the only thing stopping us from having a halfway decent field "player"
It doesn't help that the walkmesh is invisable. To look for the walkmesh data, you should pick apart BLACKBGI as that's a compleatly blank and has a nice square walkmesh. You access BLACKBGI using the debug room. (See Gears on which debug character to talk to in order load it, it's not one you access from the main debug room (STARTMAP)
Compare that data to STARTMAP (The first debug room) as that has the camera angle and rotation set at 0,0,0 and 0,0,0 respectively.
::EDIT::
You know, I just had a thought. In the PC version there are files called "moviecams". Which I bet is a sequence of camera locations that get streamed to the engine. To look for a camera location, look at the field file that has a movie intro, for example the station when you first start the game. The last coords of the cam data and the poisition of the cam set in the field file should be the same.
...Maybe....
-
That seems to be a mixup, the DAT files contain the script and dialog data.
Yes brain hasn't been working too well of late (dies on the spot). :lol:
You know they say the first thing that goes is.. I forget.. hmmm.
BSX files I've looked at a few times I think they contain palettes which likely means they also contain other data. A guess would be they contain multiple models not too much unlike what's in the BCX files.
I think we've been trying to find that darned walkmesh for the last four years! I would *REALLY* like for that to be found, along with the camera location, camera range, and floor triggers. That's really the only thing stopping us from having a halfway decent field "player"
Ummm yes... however one can't suddenly know it all at once. I've got my debugger interface working some, it's not pretty. My first order of debugging believe it or not will be loading the game up and watching that. I would like to find the points of 'entry' into various sections of the game, such as entering a city (what happens), and battles as well. It should be helpful in finding information (grin).
It doesn't help that the walkmesh is invisable. To look for the walkmesh data, you should pick apart BLACKBGI as that's a compleatly blank and has a nice square walkmesh. You access BLACKBGI using the debug room. (See Gears on which debug character to talk to in order load it, it's not one you access from the main debug room (STARTMAP)
Compare that data to STARTMAP (The first debug room) as that has the camera angle and rotation set at 0,0,0 and 0,0,0 respectively.
Hmmm good place to run the debugger in is the debug room now that I think about it! :lol:
I guess I should check both of those rooms have definative walkmesh information etc.
You know, I just had a thought. In the PC version there are files called "moviecams". Which I bet is a sequence of camera locations that get streamed to the engine. To look for a camera location, look at the field file that has a movie intro, for example the station when you first start the game. The last coords of the cam data and the poisition of the cam set in the field file should be the same.
Or how about the gold saucer tram? That's an easier one to use, it's pretty consistant.
Cyb
-
Well, if you want to have camera angle and thigs like that, then it is in section 2 (mostly 36 bytes, sometimes 76bytes). Unfortunately yet I wasnt able to determine what eacha value means, but I am working.
If what you want is walkmesh, your bet is section 5. There it is. For now, I just know, that if I change some values of walkmesh, I can walk to some places I didnt have acces, but as I walk OUT of new defined walkmesh, game crache.
How do I know?
I took hideway2 and hideway3 (btw, these have absolutly same walkmesh)and hideway1 (very, very similar walkmesh). Now change first few values in section 5 from
0x08, 0x00, 0x00, 0x00, 0x37, 0x00, 0x98, 0xFE, 0x00, 0x00, 0x00, 0x00, 0xCA, 0xFF, 0x9A, 0xFE,
to
0x08, 0x00, 0x00, 0x00, 0x50, 0x01, 0x98, 0xFE, 0x00, 0x00, 0x00, 0x00, 0xCA, 0xFF, 0x9A, 0xFE,
and now you can move in hideway2 more to right.
ABout section 2, try to copy section 2 from hideway1 or 3 to hideway2.
Positon of camera as well as walkmesh change. BTW: these files hideway1/2/3 are probably the best chance to figure it out.
-
OK. According to what I have done, section 5 IS walkmesh. It is consisted from U32 (U=unsigned S-signed, after that number of bits) number of tringles(NoT), after that is NoT* definition of position of triangle.
typedef struct {
S16 v1x,
S16 v1y,
S16 unknown1[2],
S16 v2x;
S16 v2y;
S16 unknown2[2],
S16 v2x;
S16 v2y;
S16 unknown3[2];
}
Or something like that . In fact I am working on simple shower of these tringles right now, so I will know wheather I am wrong or right.
After this is NoT *6bytes. Every 6bytes group is probably acces(if 2*byte if 0xFFFF then you probably can cross this line), wheather you can cross line (edge of tringle. I have to wrok on it)
It seems pretty good, or maybe I am just wasting everyones time and this is one big mistake.
Thist should work on simpliest fields
-
I think we've been trying to find that darned walkmesh for the last four years! I would *REALLY* like for that to be found, along with the camera location, camera range, and floor triggers. That's really the only thing stopping us from having a halfway decent field "player"
Be pleased and bow before me, for I am root ^^' , took only one day to figure it out.
Well, here is image of wutai villige(from uutai1 or something like that). I would say that it is correct? I hope so. It was done very dirty, just that you would know that it is working
(http://www.ms.mff.cuni.cz/~havlj3am/wutai.png)
-
I think Halkun will be very pleased with this... :)
-
WOW, I'm pleased as pickles.
I only ask you document this. It doesn't have to be pretty, I can do the text formatting. I would like to put it into Gears when I have the time.
When documenting please remeber to tell what version (PC/PSX) you are getting this from and what steps to take to extract the information. (The data is useless without context)
I've been watching the other threads and the progress on the animation front. Lots is getting tossed back and forth, but I'm getting lost with much of the math. (I'm innumerate)
When discribing formats, either tabulate it (put it in a table) or use a struct example. Gears shows both methods.
I'm going to be super-busy when my current class ends and my next one starts.
-
More correct description of camera can be found in post from 2005-01-30 18:34. Well, there is nothing wrong if you read this post too. There is program at the end.
WOW, I'm pleased as pickles.
I only ask you document this. It doesn't have to be pretty, I can do the text formatting. I would like to put it into Gears when I have the time.
When documenting please remeber to tell what version (PC/PSX) you are getting this from and what steps to take to extract the information. (The data is useless without context)
OK, i will do it. I have only PC version.
I've been watching the other threads and the progress on the animation front. Lots is getting tossed back and forth, but I'm getting lost with much of the math. (I'm innumerate)
Well, I cant spreak wery well, english, so it may be in vaint to write this
Maybe I write this too, in fact it is very simple. It something like you have matrix, matrix consists from 3 vectors and one point. You store matrix in array 4x4. According to math, it is 4D instead of 3D, points in 4d are x,y,z,1 and vectors are x,y,z,0.
Does it work?
Point+vector = point OK
vector+vector=vector OK
point+ point = ?? Rubbish, what ood can it be
Matrix (vectors vx,vy,vz and point p)
vx1 vy1 vz1 px
vx2 vy2 vz2 py
vx3 vy3 vz3 pz
0 0 0 1
Now you have matrix matrix define projection from one space to another space. (by space I mean three vectors and center of space considering another space as unit. Unit space is where vector x is 1,0,0 y 0,1,0 z 0,0,1 and position is 0,0,0). Now you can easily move this space through some universal transformation matrixes. Lets just say, that you want to move space along ITS axis x (in direction of axis x) and you will get another space. How can you translate it? Through matrix multiplication. Well, you can compute matrix you have for translation, but it is (tx means translation in xaxis etc)
| 1 0 0 tx |
| 0 1 0 ty |
| 0 0 1 tz |
| 0 0 0 1 |
+ +
Now multiply matrix_of_space * transmatrix and you have now new space. Rotations are similar. OK What now. In animation you have in each joint parentmatrix = matrix in joint you are connected to. You COPY this matrix as your new matrix, MOVE it for lenght of bone in z-axis and now you are at the end of bone, starting with position of oldspace and ending with your new position of your new matrix. Byt now you have to rotoate it. according to data in animation files. And after that, this became your parentmatrix for another joint, who has parent with right this matrix.
This way, you get position of every joint and because you have position of joint and pointer on its parentmatrix, you got skeleton. After that, you just need to transform polygonmeshes from.pfiles to these spaces. It is very simple:
tx = x*m[0][0] + y*m[1][0] + z*m[2][0] + m[3][0];
ty = x*m[0][1] + y*m[1][1] + z*m[2][1] + m[3][1];
tz = x*m[0][2] + y*m[1][2] + z*m[2][2] + m[3][2];
aka
tx = x*vx1 + y*vy1 + z*vz1 + px;
ty = x*vx2 + y*vy2 + z*vz2 + py;
tz = x*vx3 + y*vy3 + z*vz3 + pz;
This transformation got in time I was learning this 5 days of thinking. Well, good old times and without any knowledge of vector math it was pretty dificult
If you are interested in this stuff, I have uploaded few texts concerning 3dmath and transformation to my webpage.Here (http://www.ms.mff.cuni.cz/~havlj3am/doc/)
Look at 3dmath.txt or in democoder it is very good explained, maybe matrix.pdf. The rest is few texts on texturing, polygon fillig, nowadays this stuff is done by hardware accelerators, but if you want some insane own polytexture effect, you have to do it yourself.
I'm going to be super-busy when my current class ends and my next one starts.
well, I have 3 days to complete my program to school, if I dont, they will kick me out. It is something very similar to walkmesh. You have 1 object from ff7(I have chocobo), with animations and you walk on walkmesh with permission where you can where you dont. If you pick up some crystal, you can get another permission and now you can go to sections where you couldnt before.
Before, you can get a very simple program to show walkmeshes, colored by random colors. You need only section5. Tested on PC version of FF7 Here (http://www.ms.mff.cuni.cz/~havlj3am/walkmesh.zip)[/url][/quote]
-
Description of Section 5 for PC version of FF7
======================================
Every every offset is here relative, 00 is at the start of section 5 (after lenght indicator)
Section 5 of field files is stored walkmesh. Walkmesh is mesh of polygons on which is character moving, it is telling engine for example how height it is and thanks to that PC can for example cross bridge with real feeling that in the middle he is on higher place than on both sides. It has very simple structure. From now on, walkmesh and section 5 data are the same.
Header
---------
Startofs 0x00
Lenght 0x04
Walkmesh doesnt have header, it as only one 4 bytes long unsigned int, called NoS (Number of sectors)
Sector pool
--------------
Startofs 0x04
Lenght NoS*24
typedef struct {
short x,z,y,res; // short is 2 bytes long integer
} vertex_3s; // 3 short
typedef struct {
vertex_3d v[3];
} sect_t;
In sector pool are sectors, in fact just triangles and its position. For each sector you have three vertex_3s. Just store them. It seems that res and z are very often same, but not always.I dont know why. It seems that all polygons are clockwise. I didnt check it, but it is probably in order to know wheather point is in triangle. If you give it in other direction, point will be detected outside if it is inside and vice versa. Nothing difficult
Acces pool
------------
Startofs 0x04 + NoS*24
Lenght NoS*6
typedef {
short acces1,acces2,acces3;
}
In acces pool you have id of poly, you should go into if you cross line.
acces1 is for line from vertex 0 to 1
acces2 is for line from vertex 1 to 2
acces3 is for line from vertex 2 to 0
If acces1/2/3 is FFFF then you are not allowed to cross this line. Acces pool and sector pool are same size (NoT), so you will just use same index for both pools.
If acces dont translate you, it just says, you should be here, if you are not, then there is a problem. If you design polymesh where you cross line and acces tells you that you should be in poly 12, but you are god know where then FF7 stops.
Kero ([email protected])
20040927
-
WOW, I'm pleased as pickles.
I only ask you document this. It doesn't have to be pretty, I can do the text formatting. I would like to put it into Gears when I have the time.
When documenting please remeber to tell what version (PC/PSX) you are getting this from and what steps to take to extract the information. (The data is useless without context)
I've been watching the other threads and the progress on the animation front. Lots is getting tossed back and forth, but I'm getting lost with much of the math. (I'm innumerate)
When discribing formats, either tabulate it (put it in a table) or use a struct example. Gears shows both methods.
I'm going to be super-busy when my current class ends and my next one starts.
You owe Kero a PS1 ;)
hehehe I'm glad someone figured it out, it was going to be after I got the models looking right, ahh well someone beat me too it :)
I wish you well with your school by the way.
Cyb
-
You owe Kero a PS1 ;)
I will pass, I would be more pleased to decode section 2. Cant firure out the correct way to change section into cameramatrix.
Oh, regarding reserved
I wish you well with your school by the way.
Cyb
Thanks, It should be fine. Iam pretty good with programming, although lazy. But its deadline
Sector pool
--------------
typedef struct {
short x,z,y,res; // short is 2 bytes long integer
} vertex_3s; // 3 short
It seems that res and z are very often same, but not always.I dont know why.
When I rendered it with res instead of y (x,z,res instead of x,z,y) then all triangles stayed horizontal. Not too sure what to do with it, but maybe thay wanted to have choice of discrete way instead of continuous. Anyway, if you use x,z,res, all your triangles will be parallel.
Opinion1: you use x,z,y to get actuall height of place you are standing (you have x and z and want y) but you want to have your PC(playing character) to stay stright. If poly is not horizontal, and you would put PC in direction of normal of x,z,y plane, PC would be askew, so you want another normal, poly on same place but with different normal ant it would be x,z,res. I will sometime check it.
-
Sector pool
--------------
typedef struct {
short x,z,y,res; // short is 2 bytes long integer
} vertex_3s; // 3 short
It seems that res and z are very often same, but not always.I dont know why.
When I rendered it with res instead of y (x,z,res instead of x,z,y) then all triangles stayed horizontal. Not too sure what to do with it, but maybe thay wanted to have choice of discrete way instead of continuous. Anyway, if you use x,z,res, all your triangles will be parallel.
Opinion1: you use x,z,y to get actuall height of place you are standing (you have x and z and want y) but you want to have your PC(playing character) to stay stright. If poly is not horizontal, and you would put PC in direction of normal of x,z,y plane, PC would be askew, so you want another normal, poly on same place but with different normal ant it would be x,z,res. I will sometime check it.
Actually, think of these as vertices, in the PS1 version of FF7 it stores vertices the same way. There is no res value. I have a question are you assuming Z is vertical? If so you have the handedness of the values wrong. Z is depth X is left to right and Y is vertical. If not ignore this ;)
Anyhow the PS1 battle models and field models are stored as X, Y, Z, Dummy. The last value is always a constant and is not used. This has to do with memory alignment of the data on the PS1 they align things on long word boundries for speed. So when the data is loaded into memory it's already optimally organized for being accessed.
Removing the vertical information is pointless. You have to look at the scenes in the perspective of what they are drawn as and the camera angle. I bet there are vertical surfaces on things one can climb, if you can find a good one like the Condor village or that area you find out about REDXIII's parents. Check those out and see if I am right. The PC version of the game is SO much easier to hack (Sniff).
Cyb
-
I have decoded section 2 from field files - camera position and orientation. I will soon write some info about it. Of course I can make a mistake and all i decoded is rubbish.
Could some admin or owner of thread change name? FF7 PSX Field Characters really is not what is here, its true that I maybe should create new topc, but doesnt really matter.
Check those out and see if I am right. The PC version of the game is SO much easier to hack (Sniff).
For data extraction and things like that its true, but in psx emulator you can easily see what is stored in memory, anyway, I like PC version better for decoding, since I dont have psx version. But I would like to see quality video from psx version(i heard that psx have way better data for graphic)
-
Subject changed; Complements of me. ^_^
-
In this article, I will assume that you have at least knowledge of matrix.pdf (http://www.ms.mff.cuni.cz/~havlj3am/doc/MATRIX.PDF)
in which are some fundamental facts.
This is yet to be compleatly understand, I am pretty sure that this is not exactly trash, since it is based on at least 300 changes of field files. It was pretty nasty, as you can imagine, first divide sections of field file, load section 2 into hexedit, change byte, save section 2, run .bat file that complete new field file with new section 2 and compress it. After that I always had to use ficedula lgp tools, awfull, I am definitelly going to program commnad line program for this, in gui i had to alway on original field file, click, replace, click instead of just adding line to .bat file. After that run ff7.exe, go to destinated location and observe what happend.
I am working on program to load walkmesh along with cameramatrix. I am pretty sure about vectors, after all, they are all same lenght and they are ortogonal, but i could misinterpret order of them, position of center is little uncertain and resize facotor too. The program shoud help me to figure out these thing.
Description of section 2 (field file) - camera
============================
Goal of this section is to define cameramatrix. In fact it seems pretty simple. For cameramatrix, you need vector for axis x, vector for axis y, vector for axis z and position of camera in worldspace. Vectors for axis x,y,z are defined in worldspace and in cameraspca are normaly united.
Example> you have axis x defined as vector (0.176,-0.512,0.840) but thats in the worldspace, in cameraspace it is just (1,0,0)
* Every every offset is here relative, 00 is at the start of section 2 (after lenght indicator).
* Every pice of code or article about somthing to do with 3d I ever wrote or write was, is and will be in left handed coordinated system= x axis from left to right, y axis from bottom to top, z axis from near to far.
* In here, I am changing signs so these vectors should be correct for file loaded right from section 5-walkmesh. While in walkmesh you dont change any signs, here i am changing them, so they will fit and if you use this article with unchanged values for walkmesh, you should get right image , same as in ff7. (FIXME: not yet true)
How to get vectors for axis:
Vectors are stored right at the beginning of sec2.
typedef struct {
S16 x;
S16 y;
S16 z;
} vector3s;
You will load first vector for axis x (from offset 0 to 5), for axis y(6 to 11) and axis z (12-17). These values are in fixed point with multiply constant 4096. Lenght of vectors x,y and z is always 4096 (more or less see here (http://www.ms.mff.cuni.cz/~havlj3am/sec2camera.txt)(first vecsize is for x, then y and last z)), thats make out multiplication constant. These vectors are also always ortognormal, as you can see in ORTO 1-2 (1=x,2-y,3=z) ORTO U-Vis scalar product of U and V. As you can see, very near zero (first value is without division of multi constant).
Now you have three vectors, but they are not looking in correct direction, you have to change some signs. For each vector change sign of y and z values. Now these vectors should point in correct direction, same as in ff7.
I am now supppose that you have vectors for axises loaded, each component of each vector was divided by 4096 (dont forget to store it in float) and you changed signs for component y and z.
After vectors is one S16 number (from offset 18 to 19), same as z component of vector for z axis.
Now you want to have position of center of cameramatrix. Get three S32 numbers for position of center (x from 20 to 23, y from 24-27 and z from 28-31). These number are not position of center in worldspace, but they are position of center of cameraspce, defined in space, where position of center is in 0,0,0 and axis for vectors are the ones you read, but have opposite signs. If you didnt understood doesnt matter. You get center of cameramatrix like this:
// vx,vy,vz are axis you read, divided, y,z signs changed
// (tx,ty,tz) is position of cameramatrix in worldspace
// ox,oy,oz ire S32 nimbers you read from offset 20 to 31
tx = -(ox*vx.x + oy*vy.x + oz*vz.x);
ty = -(ox*vx.y + oy*vy.y + oz*vz.y);
tz = -(ox*vx.z + oy*vy.z + oz*vz.z);
After this is just blank U32 number, seems always zero and last, but not least resize number (36-37) (dont know wheather Signed or Unsigned). The bigger resize number is, the bigger is the model and walkmesh.
EDIT
I think we've been trying to find that darned walkmesh for the last four years! I would *REALLY* like for that to be found, along with the camera location, camera range, and floor triggers. That's really the only thing stopping us from having a halfway decent field "player"
OK Now I have delivered walkmesh and camera. Well, camera need some more work, but it is more or less 80% complete. Along with research on camera I am doing section 6, there are gateways (little red triangles), places which change location. I already know how to change destination, and few other things. What did you mean by floor triggers?
EDIT2
OK, something is terribly wrong,program is working but axis are not aligned=walkmesh, but I am SURE that thay are axis, so I will try every combination of axis and signes or somethink like that.
(http://www.ms.mff.cuni.cz/~havlj3am/walkmesh.png)
BTW this is slight modifed program I made to university, it has animated chocobo in the middle, own texturizing functions for polygons, mad pipeline, clipping in cameraspace and lots of other features, like permissions, I will be very simple to modify it for walkmesh, since already now it has function that dont allow chocobo to cross sime lines created by polygons I defined.
-
Ok, after few months of nasty eyes problems and busy work I am back.
It seems that no one paid attention to what i wrote here, since it was 95% right (or at least no one said anything). The bad images were fault of my programming and not bad deciphering of file format.
First some images
* condor2.dat
(http://www.ms.mff.cuni.cz/~havlj3am/FF7/condor2cam2bg.png)
* ancnt4.dat
(http://www.ms.mff.cuni.cz/~havlj3am/FF7/ancnt4.PNG)
* blin671b.dat
(http://www.ms.mff.cuni.cz/~havlj3am/FF7/BLIN671B.PNG)
Some program so you can try it for yourself. It is buggy and I am not even sure there is not some file I need to load somewhere on my harddisk, so if it doesnt work, is's my fault. Download field.zip (http://www.ms.mff.cuni.cz/~havlj3am/FF7/field.zip).
And finally some words from me:
As you can see, it doesnt fit completly. Its problem of perspecive correction, I use some (in meaning method and parameters) and i dont know what psx or pc version is using, but it is not really important, it is just slight adjustment (and about 10 hours of boring work - to find out precision parameters).
if you read my previous posts, this is maybe useless for you. I also shortened it.
Description of section 2 (field file) - camera
============================
* Every every offset is here relative, 00 is at the start of section 2 (after lenght indicator).
* Everything is left-handed coordinate system (x to the left, y up, z far).
* size of every camera is either 38 or 76. Every 76 long I have seen were just two same blocks of 38 bytes.
* walkmesh is stored lefthanded
You have to define camera in worldspace ( default cartesian system). To define camera you have to get three vectors for each axis and position of camera.
typedef struct {
S16 x;
S16 z;
S16 y;
} vector3S16;
typedef struct {
vector3S16 vx;
vector3S16 vy;
vector3S16 vz;
S16 repeat;
S16 ox;
S16 oy;
S16 oz;
S32 blank;
S16 size;
} camera
struct camera is structure for camera section. You have vectors for axis x,y,z, but you have to reverse vy (direction is from walkmesh). And oy
vy.x = -vy.x;
vy.y = -vy.y;
vy.z = -vy.z;
oy = -oy;
Also thse vectors are in fixed point, you have to divide every value by 4096.
vx.x /=4096.0; // of course, you have to change it (read values in S16 and vectors have to be floats)
// a littlse since here is vx.x S16 and it has to be float.
......
To get position of camera in worldspace (tx,ty,tz) you use
tx = -(ox*vx.x + oy*vy.x + oz*vz.x);
ty = -(ox*vx.y + oy*vy.y + oz*vz.y);
tz = -(ox*vx.z + oy*vy.z + oz*vz.z);
Now you have axis and position, all done.
It seems that camera is done in way to allow look on complete walkmesh. I dont resize it in any way. I think that area you get to see (like in uutai1 there is complete walkmesh in screen, but you can see only 1/6 in game) is defined through size. I am still not sure.
blank seems to be always 0x0000 and repeat is always same as vz.z. repeat is there probably only to memory alignment.
useless blabing:
1. well, if someone like it i would be happy to hear that.
2. Is here someone who decoded gateways(little red triangles that send you to different location) in section 6? Or anything about section 6.
3. I find little odd to not know if something is already researched or not. For example qhimm pdf for scripts FF7field.pdf, someone (maybe even me) would contribute instruction but no one knows(except author and maybe few others) what has already been done.
4. I would be very pleased if someone (ficedula) modified lgptools so I could on command line exectute lgptools.exe replace 125 ancnt4.dat and this would do the same as run lgptools, open lgp archive. click on file with index 125. click on replace. find file i want to replace it with, ok. I cant find source and writing it from scratch seems compleatly useless if working program is here.
EDIT: my mistake, vectors are in fixed point 4096, I hope that it is correct now.
-
Wow, that's pretty impressive, I barely know anything about decoding file formats so I can't say much else, but I hope halkun and people like that notice your post.
-
I noticed, that's really cool. I don't reconize the bottom location, what odd is there are walkable areas that are outside the normal paths.
Dumb request, but could someone post a picture of costa del sol or some other *really* identifiable area. Just for giggles ^_^
-
I think the bottom location is the floor of the Shinra building where you get thrown into a cell, and wake up to find a trail of blood.
Anyway, this is pretty impressive, yeah.
-
More accurate version of section 3 is in my post from 2005-02-01 10:52 . Well, this post has bad interpretation of lights, but read it too (some ideas ect are here)
First of all, there is nothing like i dont know anything about decoding, I dont know anything about that, its just I programmed few things like that so I have an idea what shoud be there and what not. You have section and change values, put it back to lgp files, run. Observe reults. Again, again, again... forever. Thats all.
second> some parts of text I post here are rather incomplete or there are slight mistakes. Dont let it bother you, just open some filed file, find section and look at what i wrote and follow. For example if there should be x coordinate it probably wont be -25478. Also, my results are based only on few files (2-3) and after I will have time, I will make some checker and run it on all files, so if there will be irregularity, I can find it (like, there is only one file, where camera section is 114 bytesl long, and it arent three same cameras).
Does anyone know anythink about section 6? I think that it is just trash. Pure trash and few checks about if file is really from original field file. Well I looked only on first section
S32 offs1;
S32 offs2;
S32 offs3;
S32 offsEOF; // offset to the end of file
now comes data from section one, it seems like slight fibonachi sequence with few irregularites.
Example what I found in condor1 file
-120 0 20 | -104 20 20 | -88 40 20 | -72 60 20 | -56 80 20| -40 100 20| -24 120 20| -8 140 20 | 8 160 20| 24 180 16| 40 196 13 | 56 209 12| 72 221 12| 88 233 11| 104 244 11| 0xFE7F 0 0| 24 255 4| 40 259 4| 56 263 4| 72 11 4 (*)| 88 271 4 | 104 275 4 |0xFE7F 1 0 | 0xFE7F 24 279 5 40 (**) |284 6 56| 290 6 72| .....blah blah blah. It will end with 3x 0xFE7F.
As you can see It is divided into triplets first number in triplet is always previous first number in triplet + 16, other two numbers in triplet are just some modification of fibonacchi sequence > second number in triplet is addition of second number in previous triplet and third number in previous triplet. Of course, there are some irregularities and I didnt pay attention to rest of parts of section 6 more than few second, but I dont think that there are valueable data. If someone can proof me wrong, I would be glad. I just thing that it is similar with checksum in .p files ( second half of .p files are too some sort of sequence, but I hadnt crack it yet)
Not to valuuable data.
Section 3
well, it is obvious that there are informatuions about objects in scene (indexed, so scripts can easily points on them). It doesnt seem that anyone paid attention to it more, so it decoded it. More or less... more than less.
typedef struct {
S16 blank; // is it always zero?
S16 numchar; // number of characters
S16 offs004;
object charinfo[numchar];
} sec3;
struct sec3 is complete section 3. If you see array like object charinfo[numchar] - it just says that it is arraywith 'numchar' items (it is defined structure). Hope more or less clear. First is blank number = 0x0000, after that is number of objects in this section (i use character, since it is mostly some character, but it can be also crate, savepoint ect). Some unknown number. after this follows numchars objects. objects are defined with following structure.
typedef struct {
S16 charnamelen;
chars charname[charnamelen];
S16 blank; // 0 end of string?
char skeletname[4]; // AAAA
U8 separator1; // 2E
char skelet_suffix[] // "HRC512\0" sometimes "HRC1024\0"
U16 numani; // number of animation or whatever it is. see ani[]
S16 unknown1[6]; // [1] some coeficient for diffusion of light
vector3S16 source; // vector for light position, size is 4096
S16 unknown[6]; // firs few are probably coefficients
// [x] --- unknown[x]
// [0] blue
// [1] ,[2],[3] dont know anything
//
//
// [4] red
// [5] green
animation ani[numani];
} object;
first there is lenght of name for object, after that is charnamelen chars ,without ending \0 , instead of it there is S16 blank number (seems to be always zero). after that is name of skeleton (probably hardcoded to lenght 4), separator of strings (0x2E), after this is string ending with 0 (in C manner) of with unknown meaning to me (why is there sometimes HRC512 and sometimes HRC1024 or maybe even other names). After this is number of animation this object can use in this field file.
Now is here light. Well, I have some idea what is going on there, but details are sill unknown. It seems that there are two parts of light
1] spotlight - it has source
2]ambient light - even if there is not any lightsource, object will still be litted from every side.
properties of spotlight are stored in unknown1 -- shiness, how does intensity of light decrease according to angle (NOT DISTANCE - there is nly vector - direction from where light comes, but is is more silmilar to sun, than to flashlamp). after that is vector where dioes light comes from and properties for ambient light. first is blue, the bigger this is the more blue is ambient light.. after this three S16 with unknown meaning to me (it I changed these, i didnt observe any difference). Then red and green - same properites as blue. blue, red and green are often pretty big 19000 and such.
numAni animation follows.
typedef struct {
S16 lenght; // how long will be anme of next animation
char name[lenght]; // ACFE.aki | ADCC.tor | ????.yos // . == 2E
S16 unknown; // often 0x0001 - maybe end of string?
} animation
A you can see, nothing difficult. first lenght of name of animation file, after this name of animation file (0x2E is separator of name from suffix) without zero at the end, then unknown number , often 1 and it s all.
-
More accurate version of section 8 is in my post from 2005-02-02 00:29 . Well, this is just previous version.
gatways - thats how I call areas on which you step and you are transffered to another location.
typedef struct {
S16 x;
S16 z;
S16 y;
}vector3S16
typedef struct {
S16 left;
S16 bottom; // maybe top, I dont know/care Its nearly always centred
S16 right;
S16 top; // maybe bottom.
} range;
Gateways are stored in section 8 of field files. Section 8 is always 740 bytes long, maximum of gatways for one location is 12. Stucture of section>
* header
* gateways
* unknown part 1
* unknown part 2
* triangles
header
======
typedef {
char name_of-location[8];
U32 movement;
range picture;
U32 blank;
range range1;
U32 blank1[6];
} sec8header`
movement - what direction will character go if you push up, down,left,m right. 128 (0x80) is key-direction (up-up, right-right, down-down, left-left), for 64 (up-right,right-down,down-left,left-up), 32 (up-leftup,right-leftdown,down-rightdown,left-topright)....i dont know how these directions are called.
range picture - you have noticed that your character stays in the center of screen, unless you are near of borders of picture(if you are there, character wont be in the middle, but can move to the very border of image ... well if you define range of picture smaller than is walkmesh, you character can walk out of screen and you wont see it at all). This is what define these borders. Values are in pixels, range if defined from the center of background image (bg image is 300*200 and you define left = - 145, right = 145, top = 98, bottom = -98).
range 1 - well, I dont know if it really is range, just unknown values, probably not, but better than writing four unknown values, every is 1024.
blank,blank1 - seem to be zero, have to run statistical test.
Thats all about header.
gateways
========
gateways starts on offset 0x38 from the start of section.
struct {
vector3S16 corner1;
vector3S16 corner1;
vector3S16 pos; // place where char will apear after transfer.
S16 destindex; // index in maplist
U32 unknownl; // 0x84848484 ot zero ?
}gateways;
corner 1 and corner2 defines two corner of 3D area in which if you go, you will trigger the gateway and will be transferred do destination. pos is position in destination (x,y,z) where you will appear. Just look at walkmesh value and choose some number so you are ON walkmesh and not BELOW. also you have to snad on some polygon of walkmesh (obviously).
destindex is index destination. Every location has its index defined in maplist (or something like that). In maplist are first 64 +-1 destinations on worldmap. If you swap two destinations in maplist, nothing happens, it is probably only for referrence and doesnt actually determine index of location. As every part of sectio 8 gateways have 12 structures gateway. If destination is 7FFF {maximum positive number for S16} then gateway is not active.
unknown part1 & unknown part2
=====================
this is weird, these are just default values. I have to find section 8 where these are not default and all the same.
triangles
=======
this part determines where the red triangles showing where is gateway in the game appear on the screen. I dont know much more then that.
-
4. I would be very pleased if someone (ficedula) modified lgptools so I could on command line exectute lgptools.exe replace 125 ancnt4.dat and this would do the same as run lgptools, open lgp archive. click on file with index 125. click on replace. find file i want to replace it with, ok. I cant find source and writing it from scratch seems compleatly useless if working program is here.
This was already done ... years ago ... except for some reason it's missing off my webpage :/ Must have been lost over the (many) host moves.
http://www.ficedula.co.uk/lgp.exe
...although be warned, I've not even looked at this code in years, so for all I know it might destroy your data and murder your close relatives.
-
Thanks ficedula.
Here comes more accurate decription of section 3
Field file - section 3
======================
This section is about data for showing 3d objects actually to screen, to do that you need some external data and names of files for these data is what is stored here.
Note to position: I am changing sign or something like that so, if you will take x,y,z and change signs according to me, you will get correct position in walkmesh. I just load walkmesh. coordinates [x,y,z] in walkmesh are just x,y,z. No change.
typedef struct {
S16 blank; // always zero
S16 numchar; // number of characters
S16 size; // same as size
object charinfo[numchar];
} sec3;
Lets dig in. Sec3 is structure for complete file.
blank - always zero.
numchar - number of 3dobjects in field. Although it is named char(acters), it can be anything, savepoint, treasure box...
size -- everywhere I lookes was same as size after .HRC (look below for more info), but nothing happend if I changed it(PC version). I thought it is maybe backup if size is not define after HRC then use this. Again wrong. Well, I dont know what it is for, just give it same size as you give after ????.HRC. It doesnt resize walkmesh either. Maybe obsolete from development when they thought it would be nice to have one resize for all and after that they thought it would be nice to let every object have different resize.
typedef struct {
S16 charnamelen;
chars charname[charnamelen];
S16 blank; // 0 end of string?
char skeletname[12]; // AAAA.HRC1024 or AAA.HRC512\0 - just 12 chars, no ending zero
U16 numani; // number of animation or whatever it is. see ani[]
light_s light[3];
U8 ambientred;
U8 ambientgreen;
U8 ambientblue;
animation ani[numani];
} object;
After few necessary information comes numchar * structure object. It has all information for 3dobject - name of skeletonfile, animations and such.
charnamelen - lenght of name for this object. Not really sure, whether there are some rules, but every name I have seen was something like [name_of_location_file][description_of_object_or_its_name][separator, is always 0x2E]char -> eg. condor1main_n_cloud\0x2Echar .charname is string without ending zero, only characters of string.
blank - seems to be always zero
skeletname - every skeleton file for field is 4 chars long (eg. AAER). Then there is separator 0x2E, chars HRC and after this is number of maximum four digits (often 512 or 1024 ). This number define resize value. Every skeleton has some lenght of bones, its .p files have vertexes with some coordinates for x,y,z. These coordinates and lenghts are to be multiplied by this number. TO sum it up, this number define how bigger object will be than is in original files (I hope, I maybe there is some sort of fixed point, but bigger this number is, bigger object on screen). (look ar http://www.ms.mff.cuni.cz/~havlj3am/FF7/condor1_hrc768.png and compare with http://www.ms.mff.cuni.cz/~havlj3am/FF7/condor1_hrc1024.png)
numani - number of animation for this object
typedef struct {
U8 red; // composition of light for spotlight
U8 green;
U8 blue;
vector3S16 pos; // position. I walkmesh [-x,-y,z]
} light_s;
light[3] - every object has three light sources, you can choose its position (distance from [0,0,0]: square often use something around 4103+-5, I have seen 2095... just use imagination) and intensity of each component of light. The bigger is vale for some component the more it will take effect (you can use red for bloodfiled ^__^). Position has to be adjusted.
pos.x = -x;
pos.y = -y;
pos.z = z;
after lights with source, there is ambient light (light that is everywhere, no shading), again, you can define intensity of each component. Picture will show how does ambient light look, so I dont have to explain.
(http://www.ms.mff.cuni.cz/~havlj3am/FF7/condor1_only_ambient.png)
typedef struct {
S16 lenght; // how long will be anme of next animation
char name[lenght]; // ACFE.aki | ADCC.tor | ????.yos // . == 2E
S16 unknown; // often 0x0001 - maybe end of string?
} animation
And last part of are animation. There is numani * structure animation.
lenght - lineght indicator for animation
name - string without zero at the end. [name_of_animation_file][separator 0x2E][aki^yos^anm] like GWIE.anm, HOJD.yos, AAGA.aki ...What is meaning in different suffixes I dont know.
unknown - seems to be always 0x0001
Created by Kero ([email protected])
If you find error, PM me or mail me.
I spent some time researching and writing this (10hrs, light were nasty), so if you find this usefull and write program be so kind let me know.
Thx goes to ficedula, halkun, alhexx..
EDIT:
TODO
sec3.blank - always zero.
sec3.object[].blank - zero or 1. Nothing changed even if I set it to 0x11. Dont know purpose.
sec3.object[].ani[].unknown - various values from 0 to +-200
Link (http://www.ms.mff.cuni.cz/~havlj3am/FF7/ff7_check_sec3.exe) to simple convertor from sec3 to human readable format and it's source (http://www.ms.mff.cuni.cz/~havlj3am/FF7/ff7_check_sec3.cpp)
You may need to use section divider (http://www.ms.mff.cuni.cz/~havlj3am/FF7/ff7div_field_sec.exe) (src (http://www.ms.mff.cuni.cz/~havlj3am/FF7/ff7div_field_sec.cpp)).
-
Field file - section 8
========================
Gatways - thats how I call areas on which you step and you are transffered to another location.
Every every offset is here relative, 00 is at the start of section 8 (after lenght indicator).
Gateways and related data are stored in section 8 of field files. Section 8 is always 740 bytes long, maximum of gatways for one location is 12.
Stucture of section>
* header
* gateways
* triggers
* singles
* triangles
typedef struct {
S16 x;
S16 z;
S16 y;
} vector3S16;
typedef struct {
S16 left;
S16 bottom; // maybe top, I dont know/care Its nearly always centred
S16 right;
S16 top; // maybe bottom.
} range;
header
======
typedef {
char name_of-location[8];
U32 movement;
range picture;
U32 blank;
range range1;
U32 blank1[6];
} sec8header`
movement - what direction will character go if you push up, down,left,m right. 128 (0x80) is key-direction (up-up, right-right, down-down, left-left), for 64 (up-right,right-down,down-left,left-up), 32 (up-leftup,right-leftdown,down-rightdown,left-topright)....i dont know how these directions are called.
range picture - you have noticed that your character stays in the center of screen, unless you are near of borders of picture(if you are there, character wont be in the middle, but can move to the very border of image ... well if you define range of picture smaller than is walkmesh, you character can walk out of screen and you wont see it at all). This is what define these borders. Values are in pixels, range if defined from the center of background image (bg image is 300*200 and you define left = - 145, right = 145, top = 98, bottom = -98).
range 1 - well, I dont know if it really is range, just unknown values, probably not, but better than writing four unknown values, every is 1024.
blank,blank1 - seem to be zero, have to run statistical test.
Thats all about header.
Gateways
========
gateways starts on offset 0x38 from the start of section.
struct {
vector3S16 corner1;
vector3S16 corner1;
vector3S16 pos; // place where char will apear after transfer.
S16 destindex; // index in maplist
U32 unknownl; // 0x84848484 ot zero ?
}gateways;
corner 1 and corner2 defines two corner of 3D area in which if you go, you will trigger the gateway and will be transferred do destination. pos is position in destination (x,y,z) where you will appear. Just look at walkmesh value and choose some number so you are ON walkmesh and not BELOW. also you have to snad on some polygon of walkmesh (obviously).
destindex is index destination. Every location has its index defined in maplist (or something like that). In maplist are first 64 +-1 destinations on worldmap. If you swap two destinations in maplist, nothing happens, it is probably only for referrence and doesnt actually determine index of location. As every part of sectio 8 has 12 structures. If destination is 7FFF {maximum positive number for S16} then gateway is not active.
Triggers
===================
from offset 0x158 till 0x218 - size of 1 item is 16
struct {
vector3S16 corner1 ; // 6
vector3S16 corner2 ; // 6 12
U8 enterstate; // I have more or less faith into defaultstate, but not these two
U8 leavestate; // names are probably wrong
U8 defaultstate; //
U8 sound; // index zvuku, ale v jake databazi?
} triggers
if you step in/out area between corner1 and corner2, you will
* hear sound with id sound (dont know where is table for indexes)
* there will be chage in background (mostly used for opening/closing doors)
enterstate - what sprite show if you enter into area
leavestate - what sprite show if you leave area
defaultstate - what sprite show at the start
These three values are somehow connected to background, at first I thought they define what part of script shoud be called if stepper into/out, but it doesnt seems so (nearly sure, I changed script and changes of background stayed). Still not toos sure about WHAT they are indexing. Have to research section 9 properly.
Singles
======
from offset 0x218 till 0x224
one byte for one item. Dont know what these are for. Values 1 or 0
triangles
==========
from 0x224, lenght of setion 192 -> 16 bytes per item.
This part determines where the red triangles showing where is gateway in the game appear on the screen.
struct {
S32 pos.x;
S32 pos.z;
S32 pos.y;
S32 visible; // is it visible? 01 true 00 false
} triangles;
pos - position in walkmap. No sign changes necessary.
visible - 0 - trinagle is not visible
1 - triangle is red
2 - trinagle is green
>2 - trinagle is red
- I am not really sure if all bytes from U32 are used only for visibility - >run statistical correction
TODO:
triggers[].*state
triangles[].unknown
rest of header
statistical correction for visible
spelling&grammar check
Now we can sum it all.
Field files - we know how sections are defined.
Every section stores specifical data.
section purpose
1 Dialogs and game scripts
2 Camera,its direction and position, FieldOfView
3 Names of files for loading 3d models - meshes, skeletons, animations
4 Palette
5 walkmesh
6 Junk data
7 random enemies
8 Gateways
9 Background images and sprites
Section 1 scripts ect. are not decoded enough, I dont think we can make our own.
Section 2 - meaning of values decoded from 90%, interpretation from 70%. atribut size somehow define viewvolume, unfortuantelly not enough for practical use.
Section 3 - enough for practical use. 95%
Section 4 pallete - compleatly decoded
Section 5 walkmesh - decoded.
Section 6 - trash, just copy from another field file
I checked section 6 and it really is pure trash. More correctly, I replaced 25 000 bytes long section 6 in wutai with 2 500 bytes long from condor1 and hadnt see any difference in behaviour of filed. Maybe I just didnt pay enough attention, but for now, lets call it junk, trash....
Section 7 random enemies - I have seen it decoded somwhere, but dont know where
Section 8 enought for practical use.
Section 9 - havent looked enought into this, but I dont think document ficedula&qhimm wrote is enough (I would like to see sources of 7mimic),
I think I did good job in decoding. But still not enough for good field file editor.
-
Interesting stuff, the fact they used ambient lighting interests me. Perhaps they planed on using this to make the person look like they are in a light or dark place. In other words in shadow or outdoor light, or maybe that was there intention and they never got around to it as well. (Yet another than to add to the engine (Check ambient lighting for ambient lighting affects ;) ).
The walk meshes seem a bit large for just one field location. Are they for a single or multiple field locations? There must be 'gateways' located within the mesh's bounds. What is the purpose of red versus green triangles. I don't recall that in the game.
This is of course for the PC version of the game (section 1 - 9 are different on the PSX). However it is very good you provide this information I can examine the PSX data and compare results :D
I just started ploinking on my viewer and have been improving it's basic functionality bit by bit. I'll post some fun things I have been informed of in another thread (FF8 related).
I suppose my next task is finding the walk mesh in the PSX data. It appears that section 9 is located in the ????????.MIM files and the remaining sections are located in the ????????.DAT files. Do you know where the field models are kept in the game? Maybe section 6 is a redundant copy of the PSX field model information (????????.BSX files)? Just a possibility you might not have considered.
Cyb
-
Interesting stuff, the fact they used ambient lighting interests me. Perhaps they planed on using this to make the person look like they are in a light or dark place. In other words in shadow or outdoor light, or maybe that was there intention and they never got around to it as well. (Yet another than to add to the engine (Check ambient lighting for ambient lighting affects ;) ).
I dont think so, ambient lightning is normally replacement for radiosity, but it takes much less time(and results are of course far from real, but sufficient), and is used (ambient light) in most games I have seen. OpenGl model for light:
Emitted, Ambient, Diffuse, and Specular Light
Emitted light is the simplest - it originates from an object and is unaffected by any light sources.
The ambient component is the light from that source that's been scattered so much by the environment that its direction is impossible to determine - it seems to come from all directions. Backlighting in a room has a large ambient component, since most of the light that reaches your eye has bounced off many surfaces first. A spotlight outdoors has a tiny ambient component; most of the light travels in the same direction, and since you're outdoors, very little of the light reaches your eye after bouncing off other objects. When ambient light strikes a surface, it's scattered equally in all directions.
Diffuse light comes from one direction, so it's brighter if it comes squarely down on a surface than if it barely glances off the surface. Once it hits a surface, however, it's scattered equally in all directions, so it appears equally bright, no matter where the eye is located. Any light coming from a particular position or direction probably has a diffuse component.
Finally, specular light comes from a particular direction, and it tends to bounce off the surface in a preferred direction. A well-collimated laser beam bouncing off a high-quality mirror produces almost 100 percent specular reflection. Shiny metal or plastic has a high specular component, and chalk or carpet has almost none. You can think of specularity as shininess.
Although a light source delivers a single distribution of frequencies, the ambient, diffuse, and specular components might be different. For example, if you have a white light in a room with red walls, the scattered light tends to be red, although the light directly striking objects is white. OpenGL allows you to set the red, green, and blue values for each component of light independently.
The walk meshes seem a bit large for just one field location. Are they for a single or multiple field locations? There must be 'gateways' located within the mesh's bounds. What is the purpose of red versus green triangles. I don't recall that in the game.
I dont recall red x green either, its just color. I dont understand what do you mean by "walk meshes seem a bit large"? One walkmesh is for one field file (although some locations use same walkmesh, but every field file has its own). You just see part of location and move on it. Character stays in the center of screen (excpet : see header of section 8: range picture). Walkmesh is defined through vertexes and triangles. Each gateway is defined through two coreners of block. These corners are defined in walkmesh. If walkmesh is onw triangle (x,y,z, left handed coordinates) [0,0,100],[-100,0,-50],[100,0,50] and you define corner one and two as [-10,0,10]x[10,10,-10] then if you step in the middle of triangle you will be transffered into different location.
I suppose my next task is finding the walk mesh in the PSX data. It appears that section 9 is located in the ????????.MIM files and the remaining sections are located in the ????????.DAT files. Do you know where the field models are kept in the game? Maybe section 6 is a redundant copy of the PSX field model information (????????.BSX files)? Just a possibility you might not have considered.
I have never seen FF7 in PSX version, so I cant help at all.
In PC version field characters are stored in /data/field/char.lgp. You can view them in ilfana.
-
I dont think so, ambient lightning is normally replacement for radiosity, but it takes much less time(and results are of course far from real, but sufficient), and is used (ambient light) in most games I have seen. OpenGl model for light:
Hmmm I'm not sure they used lighting for any of the battle models. I also don't recall if the characters lighting changes at anytime during the game.
Lighting information removed I know quite a bit about lighting types and differences in them etc. Phong (specular diffuse) Tarus Sparrow models (similiar to Phong only closer to reality) etc etc. I did a few papers on it over 15 years ago :D I still even dabble in it but I don't have as much time as I use to. Anyhow what I was really asking is there more than one ambient light definition and if so is it based on the triangles in the walk mesh. I doubt they have any real light sources, though it is possible to do that on the PSX hardware (just slow).
I dont recall red x green either, its just color. I dont understand what do you mean by "walk meshes seem a bit large"? One walkmesh is for one field file (although some locations use same walkmesh, but every field file has its own). You just see part of location and move on it. Character stays in the center of screen (excpet : see header of section 8: range picture). Walkmesh is defined through vertexes and triangles. Each gateway is defined through two coreners of block. These corners are defined in walkmesh. If walkmesh is onw triangle (x,y,z, left handed coordinates) [0,0,100],[-100,0,-50],[100,0,50] and you define corner one and two as [-10,0,10]x[10,10,-10] then if you step in the middle of triangle you will be transffered into different location.
So basically each field file stores the entire walk mesh for the area it's in with new exits and and camera information for each. That makes sense.
I have never seen FF7 in PSX version, so I cant help at all.
In PC version field characters are stored in /data/field/char.lgp. You can view them in ilfana.
Are those just the character models? (They are stored as <NAME>.BCX on the PS1 version.) Do you know if that includes the different field models for each field location? Each fiel d location has a unique set of field models that appear at that location. Such as wutai and midguard. Characters are stored seperately. Combat dialogs such as the ProudClod scene are just that combat models and are not in Field models. It means for example in the Shinra building top floor there are President Shinra Rufus and any other model of a NonPlayer Character stored in it that is at that field location.
I believe Micky posted the information reguarding the field models etc.
In any case it's not a big deal.
Cyb
-
I think I did good job in decoding. But still not enough for good field file editor.
It's not so much an editor that would be cool, but a "player" would be kind of nice. That's where I think efforts should be aimed towards.
-
It is all good and useful as well.
I will need it for my engine, but you go too fast.
I haven’t started programming this into my engine yet, because, to be honest, at times your notes are very confusing.
In the beginning I simply could not follow your notes, but I know that since then you have rewritten things, and if I take the time to read this entire post I can probably put it all together.
Whenever you’re done with this, figure out the battle animation format.
I will look over this all in more detail when I am ready for this addition to my engine, but for now it seems to be nice work that (seemingly) no one else here could do.
L. Spiro
-
It is all good and useful as well.
I will need it for my engine, but you go too fast.
Dont worry, there is nothing wrong with it. I did walkmesh 3 months ago and then was long pause and I did something again.
I haven’t started programming this into my engine yet, because, to be honest, at times your notes are very confusing.
I guess (especially the one from 2004-09-27 13:35 ). Mostly I add a lot of new information and post new reply while old one if still there.
Well, the worst is field scripting, without it this cant do nearly anything. Field scripts are the core, but PSX version is far more suitable for that. Oh well.
Anyhow what I was really asking is there more than one ambient light definition and if so is it based on the triangles in the walk mesh. I doubt they have any real light sources, though it is possible to do that on the PSX hardware (just slow).
Every character is rendered with three spotlights (probably just descover intensity in corners of triangles and then gourard (phong is too difficult for PSX I think)) and ambient light. Every character have definition for these lights, although it is same for character in file I have seen, I can be defined per case. They are not based on triangles (or at least I dont know)
-
I was told by Eidos Support that this is why the company stop support for FF7 six years ago cause they could'nt fix the crash! Did some one else? I have use all the downloads no go! Or can I just skip this!