FF8/FileFormat X
By MaKiPL. Thanks for help in research for: shakotay2 (XeNTaX), Halfer, Yagami Light. Complete list of original battle stages by Kaspar01: List of battle stages
Contents
Info
.X file is uncompressed 3D stage model with texture embedeed. The file contains unused info (not used by FF8 engine), camera data, movement, translations and geometry data.
Battle stages DOES NOT contain pointers to next sections. All pointers are HARDCODED in FF8.EXE. Click me for battle stage pointer list
Name | Usually starting with: | Description |
---|---|---|
PlayStation MIPS assembly | E8 FF BD 27 01 00 02 | Used only in PS version; skipped in PC |
Camera data + movement | 02 00 08 00 20 00 | Camera animations, movement (pre-keyed) |
Model section | 06 00 00 00 (See geometry section info) | Divides to object (group) and it's sub-objects + vert/triangle grouping |
Texture | 10 00 00 00 09 (Always) | Contains one .TIM texture, 8 BPP |
How is this file handled by the engine?
FF8 loads specific file and reads it from hardcoded (written in FF8 code) position (or reads MIPS PlayStation assembly that contains battle stage load code). This hardcoded position points to camera data (in PC). Camera data has size uint16, which is calculated and relative jump is made. Just after camera, a typical section based file handling is made.
Offset | Length | Description |
---|---|---|
0 | uint32 | Number of sections |
4 | uint32 | Objects group #1 |
8 | uint32 | Objects group #2 |
12 | uint32 | Objects group #3 |
16 | uint32 | Objects group #4 |
20 | uint32 | Texture [unused in code] |
24 | uint32 | Texture |
28 | uint32 | Relative to EOF |
Objects Group
Offset | Length | Description |
---|---|---|
0 | uint32 | Number of sections |
4 | uint32 | Pointer to Settings #1 |
8 | uint32 | Pointer to ObjectsList |
12 | uint32 | Pointer to Settings #2 |
16 | uint32 | Relative to end_of_group |
Objects List
Offset | Length | Description |
---|---|---|
0 | uint32 | Number of objects |
Num_of_obj*4 | uint32 | Relative pointer to segment (one .obj file) [01 00 01 00] |
Settings 1
Offset | Length | Description |
---|---|---|
0 | uint16 | Unknown, fixed 2? |
2 | sint16 (probably, or uint16) | Scale (01 is the smallest) |
4 | 4 bytes | PADDING |
8 | 4 bytes | Nothing? |
12 | 4 bytes | Nothing? |
16 | 2 bytes | if not FF FF, then model vanishes |
18 | sint16 | X or Z Axis rot origin (Translation) |
20 | 44 bytes | Left null for storing some engine data AFTER loaded in-game |
64 | 2 bytes | if not FF FF or 00 00, then model vanishes |
66 | 2 bytes | Nothing? |
68 | ...up to end | Left null for storing some engine data AFTER loaded in-game |
This might look difficult, but it's like multi-pointer file that starts at different location given by executable. See list at the beginning of this wiki to see which stages camera starts at which position (where FF8.exe really starts to read file as BattleStage) [FF8 stores whole file, even with useless data before camera] If this still makes trouble, see this video: TODO
Camera data
Starts at ~0x5d4 (see How the engine handles this file?). [.text:00509820]
Offset | Length | Description |
---|---|---|
0 | uInt16 | Fixed 02 00 (Unused in code)/ pointers count |
2 | uInt16 | Relative jump to CameraSetting |
4 | uInt16 | Relative jump to CameraAnimationCollection |
6 | uInt16 | Camera data size (starting from 0) [unused in code] |
8 | 24 bytes | Camera Settings |
32 | ?? bytes | Camera Animation Collection |
Camera Setting
Offset | Length | Description |
---|---|---|
0 | char (based on disassembly) | CameraAnimMode? |
1 | byte? | StopEnemyBeforeAnim? |
2 | Bitfield? (1B) | UHM? |
3 | ??? | DefaultEndofCameraPosition_Zoom? |
4 | ??? | ??? |
Camera Animations Collection
Offset | Length | Description |
---|---|---|
0 | uint16 | NumOfSets |
2 *(Set index) | uint16 | Relative pointer to camera Animation Set |
2 *(Set index)+ 2 | uint16 | Camera EOF |
CameraAnimationSetPointer | CameraAnimationSet | CameraAnimationSet |
CameraAnimationSet
Offset | Length | Description |
---|---|---|
0 | ushort | AnimPointer*2 |
AnimPointer | Varies 144-146-148 bytes usually | CameraAnimation |
Camera Animation (WIP)
Offset | Length | Description |
---|---|---|
0 | uint8_t | Animation ID |
1 | uint8_t | Key Frame Count |
2 | uint16_t (bit varies) | Main controller, if 0xFFFF then return |
4 | uint16_t | Starting FOV usually ~280 |
6 | uint16_t | Ending FOV ~006 |
8 | uint16_t | Starting Camera Roll usually 0 |
10 | uint16_t | Starting Time usually 0 |
12 | uint16_t | Current Time // I'm questioning if this is part of the struct. |
14 | array<uint8_t,20> | unknown bytes |
34 | array<uint16_t,32> | Start Frame Offsets |
98 | array<int16_t,32> | Camera World Z |
162 | array<int16_t,32> | Camera World X |
226 | array<int16_t,32> | Camera World Y |
290 | array<uint8_t,32> | Is Frame Durations Shot ~ bool? |
322 | array<int16_t,32> | Camera Look At Z |
386 | array<int16_t,32> | Camera Look At X |
450 | array<int16_t,32> | Camera Look At Y |
514 | array<uint8_t,32> | Is Frame Ending Shots ~ bool? |
546 | array<uint8_t,128> | unknown bytes |
674 | array<uint8_t,128> | unknown bytes |
802 | array<uint8_t,128> | unknown bytes |
930 | array<uint8_t,128> | unknown bytes |
1058 | array<uint8_t,34> | unknown bytes |
Total bytes of struct is 1092. Still much is unknown about this struct. I adjusted things from OpenVIII source code. Though some numbers weren't adding up. I know the total size. So I adjusted one of the unknown bytes arrays to fit in the span.
Time
Time is calculated from number of frames. You basically set starting position World+lookat and ending position, then mark number of frames to interpolate between them. Every frame is one draw call and it costs 16. Starting time needs to be equal or higher for next animation frame to be read; If next frame==0xFFFF then it's all done.
Dependency
CAMERA: -Camera Settings -Camera Animation Collection (even three collections in a0stg006.x and up to 7 in a0stg101.x!) | | -Camera animation Set (Always 8 camera animations, may be empty (0xFFFF); look for example to a0stg127.x collectionId==1; there are 8 animations, but 7 of them are 0xFFFF (pointers increase by 2)) | | - Camera animation
Example
a0stg006.x:
0x5d8 -> 02 00 08 00 20 00
- Get EOF-> *(0x5d8 + 8) -> 32
- Jump to EOF -> 0x5d8 + 32 = 0x5F8 (This is now Camera Animation Collection)
- Get pointer to correct anim collection. In this case we will use AnimCollectionID == 0, so: *(0x5F8 + 0*2 + 2) -> 0x0c
- Jump to Anim collection data: 0x5F8 + 0x0c = 0x604 (This is now Camera Animation Set)
- Jump to Camera animation by cameraAnimSetID, let's take for example cameraAnimSetID == 7, so: *(0x604 + 7*2) -> 0x25E. Now carefully, jump by multiplying it by 2!
- 0x604 + (0x25E * 2) = 0xAC0
Therefore: a0stg006.x Camera animation 7 in camera collection 0 is at 0xAC0
Geometry
Geometry contains groups, that contains Triangles and/or quads poligons. Models always stars at 01 00 01 00, and needs to be after camera data, either it's not model itself, but some other data.
Group
Offset | Length | Description |
---|---|---|
0 | 4 bytes | Always 01 00 01 00 / Header of object |
4 | 2 bytes | Uint16 / number of vertices. |
6 | Number of vertices * 6 | Vertex data, short X; short Y; short Z; |
6 + (Number of vertices *6) | (AbsolutePosition MOD 4) + 4 | Padding |
varies (just after above) | 2 bytes | uint16 / number of triangles |
varies (just after above) | 2 bytes | uint16 / number of quads |
varies (just after above) | 4 bytes | padding |
varies (just after above) | number of triangles * 20 | Triangle data. If NumOfTriangles = 0, then instead of any triangle data, there's quad data. |
varies (just after above) | number of quads * 24 | Triangle data. If NumOfQuads = 0, then instead of any quad data, there's either next header 01 00 01 00, or end of group. |
Triangle
Name | Type | Description |
---|---|---|
F1 (A) | uint16 | A of face indice |
F2 (B) | uint16 | B of face indice |
F3 (C) | uint16 | C of face indice |
U1 | Byte | U of first texture coordinate |
V1 | Byte | V of first texture coordinate |
U2 | Byte | U of second texture coordinate |
V2 | Byte | V of second texture coordinate |
CLUT_ID | UInt16 (BIT operated)* | Index to CLUT_ID operated by BIT (see below) |
U3 | Byte | U of third texture coordinate |
V3 | Byte | V of third texture coordinate |
Special (see below / After QUAD table) | 8 Byte | See below (after QUAD table) |
Hide | Byte/Bool | Bool. Hides or shows texture |
Red | Byte | Texture colourization (Red) |
Green | Byte | Texture colourization (Green) |
Blue | Byte | Texture colourization (Blue) |
PSone GPU related | Byte | PSOne instruction |
Quad
Name | Type | Description |
---|---|---|
F1 (A) | uint16 | A of face indice |
F2 (B) | uint16 | B of face indice |
F3 (C) | uint16 | C of face indice |
F4 (D) | uint16 | D of face indice |
U1 | Byte | U of first texture coordinate |
V1 | Byte | V of first texture coordinate |
CLUT_ID | UInt16 (BIT operated)* | Index to CLUT_ID operated by BIT (see below) |
U2 | Byte | U of second texture coordinate |
V2 | Byte | V of second texture coordinate |
Special (see below) | 8 Byte | See below (after table) |
Hide | Byte/Bool | Bool. Hides or shows texture |
U3 | Byte | U of third texture coordinate |
V3 | Byte | V of third texture coordinate |
U4 | Byte | U of fourth texture coordinate |
V4 | Byte | V of fourth texture coordinate |
Red | Byte | Texture colourization (Red) |
Green | Byte | Texture colourization (Green) |
Blue | Byte | Texture colourization (Blue) |
PSone GPU related | Byte | PSOne instruction |
Special Byte: This byte, needs to be divided to two bytes. So, for example, a 0xE5 needs to be treated like two bytes: 0x0E 0x05
Singular of char | Example | Description |
---|---|---|
First char/ 4 BIT | B2 --> 0B | Unknown |
Second char / 4 BIT | B2 --> 02 | Texture page number |
CLUT ID
The most important bit's are the first two on one byte, and last two on last byte. Example: 00000000 00111100 (00 3C) should be read like this: 00111100 00000000 (3C 00) And the CLUT ID is revealed by watching this four bits: 001111[00 00]000000
Same applies to reading CLUT colors (16bits) where they are: 1b-T, 5b-B, 5b-G, 5b-R (Or RGBT if reordered as shown above)
Complete list (without replacing bit order - as is in HEX editor/memory):
CLUT ID | BIT | HEX |
---|---|---|
#1 | 00000000 00111100 | 00 3C |
#2 | 01000000 00111100 | 40 3C |
#3 | 10000000 00111100 | 80 3C |
#4 | 11000000 00111100 | C0 3C |
#5 | 00000000 00111101 | 00 3D |
#6 | 01000000 00111101 | 40 3D |
#7 | 10000000 00111101 | 80 3D |
#8 | 11000000 00111101 | C0 3D |
#9 | 00000000 00111110 | 00 3E |
#10 | 01000000 00111110 | 40 3E |
#11 | 10000000 00111110 | 80 3E |
#12 | 11000000 00111110 | C0 3E |
#13 | 00000000 00111111 | 00 3F |
#14 | 01000000 00111111 | 40 3F |
#15 | 10000000 00111111 | 80 3F |
#16 | 11000000 00111111 | C0 3F |
Texture
Contains one TIMs with various size 512x256, 673x256, 768x256 (8BPP).
UV calculation algorithm
Float U = (float)U_Byte / (float)(TIM_Texture_Width * 2) + ((float)Texture_Page/(TIM_Texture_Width * 2));
Texture page calculation
Byte TPage = InputBytes[TexturePage_index] & 0F;
Bitwise TPage byte AND 0F, to delete first 4 bits
int TPageINT = TPage * 64;
For 16 bit TIM's, the texture page is 64 pixels wide
Example
For 24-bit TIM:
0xB2 byte is: 2*48 = 96
Unsure about this one. It could be 42.667 instead of 48. It takes 1.5x the space of 16 bit. I haven't seen a file that uses 24-bit yet.
For 16-bit TIM:
0xB2 byte is: 2*64= 128
For 8-bit TIM:
0xB2 byte is: 2*128 = 256
For 4-bit TIM:
0xB2 byte is: 2*256 = 512
Each time you half the number of bits you double the amount of data you can store in the same space. So the calculated Texture Page is different.
Face order / Translation/ triangulation
Quad wing order
ABCD ---> ABDC example: f 1 2 3 4 to: f 1 2 4 3
Quad triangulation face order
ABDC > ABD ACD (same for VT) example: f 1 2 4 3 to: f 1 2 4 f 1 3 4
Triangles VT order
A/T1 > A/T2 B/T2 > B/T3 C/T3 > C/T1
Example
(Also with quad triangulation face order!) f 1/1 2/2 7/4 6/3 to: f 1/1 2/2 7/4 f 1/1 6/3 7/4 where: A=1 B=2 C=6 D=7