Anonymous

Changes

From Final Fantasy Inside

FF7/Field

1,157 bytes added, 02:49, 13 July 2019
no edit summary
* The running of the Field Script to display events and to get user input
* The on-demand loading of other modules when needed
 
A list of fields can be found [[FF7/Field/Field_ID|here]].
The Field module loads modular "Field Files". In the PC version, the Field File is a single file with nine sections. In the PSX version, there are three files with the same name but with different extensions that do the same thing. The three files are MIM (Mutiple Image Maps, or the backgrounds), DAT (Field Script Data), and BSX (3D data).
Another last thing to note is in the middle of the bottom texture cache there are a sea of eyes. These blink at random times and reflect the random blinking of the characters in the game.
 
 
== Field Format (PC) ==
=== General PC Field File Format ===
Field files are always found in FLEVEL.LGP. They are always [[FF7/LZS format|LZS]] compressed.
The first two bytes of each (decompressed) field file are blank (zero).
|style="background:rgb(255,255,255)" | 4 bytes
|style="background:rgb(255,255,255)" | Pointer to Section 3
|style="background:rgb(255,255,255)" | [[FF7/Field/Model Loader|Model Loader]]
|-
|style="background:rgb(255,255,255)" | 0x12
|style="background:rgb(255,255,255)" | [[FF7/Field/Walkmesh|Walkmesh]]
|-
|style="background:rgb(255,255,204255)" | 0x1A|style="background:rgb(255,255,204255)" | 4 bytes|style="background:rgb(255,255,204255)" | Pointer to Section 6|style="background:rgb(255,255,204255)" | Unknown[[FF7/Field_Module/DAT/Tile_Map|TileMap]] (Unused)
|-
|style="background:rgb(255,255,255)" | 0x1E
|style="background:rgb(255,255,255)" | 4 bytes
|style="background:rgb(255,255,255)" | Pointer to Section 8
|style="background:rgb(255,255,255)" | 3D & Walkmesh-related[[FF7/Field/Triggers|Triggers]]
|-
|style="background:rgb(255,255,255)" | 0x26
Each section generally starts with a four byte integer indicating the length of the section. You could just work this out by comparing offsets (how much space until the next section/end of file, etc) but FF7 stores the length at the start of the section anyway. After that the actual data follows. So the first bit of data for a section is actually 4 bytes after the point given in the section header (since the first four bytes are actually the length marker).
To examine each section, please navigate using the links in the table above. For sections 3 and 8, there is some information on [http://forums.qhimm.com/index.php?topic=4358.msg58674#msg58674 the forum].
== Field Format (PS1) ==
|style="background:rgb(200,255,200)" | Contains triggers, singles, gateways and so on.
|-
|style="background:rgb(200,255,200)" | [[FF7/Field/EncountersEncounter|EncountersEncounter]]
|style="background:rgb(200,255,200)" | Battle Encounter information for location.
|-
|style="background:rgb(200,255,200)" |  [[FF7/Field/Models|Models]]|style="background:rgb(200,255,200)" |  Some info about field models.
|}
=== PSX MIM Format ===
Part of the PSX background data is contained in the [[FF7/Field/MIMfile|MIM file]], it is compressed with [[FF7/LZS format|LZS compression]]. It consists of palettes (256 color ones) and screen blocks. No data for locating the blocks on the screen is in this file. The MIM file is a truncated TIM file and contains the normal clut location height and width information. This information is directly loaded into the PSX video ram to be decoded by the field module. The structure begins with the  ====MIM Header==== typedef struct { UINT32 Header_Palette; UINT16 PalX, PalY; UINT16 PalWidth; UINT16 PalHeight; } MIMHeader; which is followed by PalHeight number of ====MIM Palette==== typedef struct { UINT16 Palette[256]; } BGRPal256; After the palettes comes the ====MIM Block Header==== typedef struct { UINT32 WordCount; // # words of data in image UINT16 ImageX, ImageY; // location of blocks on 1024x512 display area UINT16 Width, Height; // Width is the # of Word units (UINT16) the blocks are wide } MIMBaseImage; lastly the actual block data for display follows. The palettes are selected from information in the DAT section 3 data.
=== PSX BSX Format ===
The Field models are contained within this in the [[FF7/Field/BSX|BSX file]], it is compressed with [[FF7/LZS format|LZS compression]]. [[FF7/Field/FIELD.TDB|FIELD.TDB ]] contains the textures for these models. The format is similiar to the [[FF7/Playstation_Battle_Model_Format|Playstation Battle Model]].
=== PSX BCX Format ===
The individual characters ' field models are stored in [[FF7/Field/BCX|BCX files, there ]]. Their textures are also in [[FF7/Field/FIELD.TDB|FIELD.TDB, ]]; they are compressed with [[FF7/LZS format|LZS compression]].
== Event Scripting ==
Event scripting is handled via a series of script commands and entities spawned for the event. The exception to this is the battle event scripting. This is actually a little bit different. Please refer to the [[FF7/Field/Script|Field Script]] for more information.
== Script commands ==
== Movies ==
Movies in FF7 are actually triggered from the [[FF7/Field/Script|Field Script]]. The [[FF7/Field/Script/Opcodes/F8 PMVIE|F8 PMVIE]] opcode is first used to set the movie for which the [[FF7/Field/Script/Opcodes/F9 MOVIE|F9 MOVIE]] opcode is used to play. It is important to remember the MOVIE ID may vary in the PS1 versionn depending on what disc you are on.
The PC movies were encoded using the DUCK (goose?) format and are AVI video files.
 
The PS1 movies were encoded using FMV Motion JPEG video files, for the playstation. These files cannot be decode or read directly from the CD disc media because of the Mode 2 format of the files. The files are encoded using ISO Mode 2 which means the sectors are 2302 bytes in length instead of 2048. The video files have interleaved audio (ADPCM format), between video frames and are 320x224 15fps. Video files that have no audio with it actually has empty sectors of space between video frames to prevent the extremely timing sensitive MDEC decoder in the playstation from locking up.
 
[[User:Cyberman|Cyberman]] 14:18, 30 Dec 2006 (CST)
== The 3D Overlay ==
== Data Organization ==
== "A" Field Animation Files for PC by [[User:Mirex|Mirex]] (Edits by [[User:Aali|Aali]]) ==
Each animation file holds one character animation ( run, walk or some other). Some characters have more animation files. Animation is set of frames, in each frame are stored bone rotations.
|-
|style="background:rgb(255,255,255)" | header
|style="background:rgb(255,255,255)" align="center" | 24|-|style="background:rgb(255,255,255)" | unknown|style="background:rgb(255,255,255)" align="center" | 1236
|-
|style="background:rgb(255,255,255)" | frames
|}
-- one frame, size is (bones * 12 + 2412 + 12) -- unknown 24 bytes = 6 floatsrotations bones * 12 bytes = bones * 3 floats
{| border="0" cellspacing="1" cellpadding="3" style="background: rgb(0,0,0)" align="center"
! style="background:rgb(204,204,204)" align="center" | Size
|-
|style="background:rgb(255,255,255)" | unknownroot rotation|style="background:rgb(255,255,255)" align="center" | 24 12 = 6 3 floats|-|style="background:rgb(255,255,255)" | root translation|style="background:rgb(255,255,255)" align="center" | 12 = 3 floats
|-
|style="background:rgb(255,255,255)" | rotations
|}
header structure, 24 36 bytes
struct {
unsigned long x1int32 version; unsigned long int32 frames_count; unsigned long int32 bones_count; unsigned long x2, x3, x4char rotation_order[3]; unsigned char unused; unsigned int32 runtime_data[5];
} anim_head;
I understand only two values from the header, 'frames_count' which is number of animation frames and 'bones_count' which is suprisingly number of animated bones.
 
''version should always be 1 or FF7 will not load the file''
 
''rotation order determines in which order rotations are applied, 0 means alpha rotation, 1 beta rotation and 2 gamma rotation.''
 
''runtime data has no meaning in the animation file and is discarded on load''
If you want to load all possible animations for the model (even animations of different models) then check if animation file has same number of bones as current model.
After header there is 12 bytes of data that are unknown to me. It could be some center of the coordinate system or anything.  Frame starts with 6 floats (unknown)the root rotations and root translations, followed by rotations for each bone. Rotations are stored as 3 floats (float is 4byte floating-point number).