Virtual World R.E. - User contributions [en]

Models

2023-10-07T13:52:28Z

Algoflash: /* Affected files */

[[Gotcha Force | ← Gotcha Force]]

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

== Gotcha Force Models ==

Gotcha Force models work as those from the game Super Smash Bros Melee (SSBM) investigated by its [https://smashboards.com/threads/melee-dat-format.292603/ community].

A model is a file format that organizes objects and resources serialized to be used by the '''H'''al '''S'''ys'''D'''olphin ('''HSD''') library. The HSD library is used in several Capcom games. These are graphic materials structured in a hierarchical way. Some pictures present in the models seem to indicate the use of [https://learn.foundry.com/modo/901/content/help/pages/shading_lighting/shader_items/matcap.html matcap] technic. This library uses Dolphin SDK functions like GX / MTX and so on.

=== Affected files ===
All files in the AFS having '''_mdl''' in their names are models described in this page. We notice also [[ARZ (Gotcha Force)|.arz]] which are compressed models. collision.arc and tdc00.arc to tdc09.arc are also models.

Les fichiers modèles se retrouvent aussi dans les pzz des borgs (plxxxx.pzz) en position 004 à 009.

=== HSDRaw ===
HSDRaw, un éditeur 3D dotnet de ce format est instable sur mon Windows (algoflash). Il est cependant prouvé qu'un edit des _mdl pour commencer à l'offset 0x100 - après le préambule - permet de visualiser le fichier sur HSDRaw et d'avoir le rendu 3D du Borg (click sur le premier dossier JOBJ - puis le JOBJ dedans et double click sur le nœud en violet). Cela devrait aussi permettre d'éditer certaines propriétés ?

== Structure générale ==
Le format des modèles se découpe en plusieurs blocks. Le préambule fait 0x100 octets au tout début du fichier. Il est souvent absent. Toutes les valeurs sont en unsigned big endian, et le pad est en Nulls bytes (\x00). Les offsets trouvés après le début du Data Block (DB) sont relatifs au début du DB. La table de relocs est un tableau d'offsets de 4 octets (relatif au DB) permettant de traduire en adressage absolu les offsets des structures lors du chargement mémoire. La table de reloc permet par exemple de délimiter les structures du fait qu'il est peu probable qu'un offset pointe au milieu d'une structure.

L'ensemble des fichiers répondant à ce format on un seul root_node de type SObj (Scene data).

=== '''Préambule''' : (0x100 octets / 0 octets) ===
* 4 octets - hsd_header_offset=0x100 (toujours)
* 4 octets - bones_flags_table_offset=0x20 (toujours) - offset de la liste des flags des armatures
* 4 octets - bones_table_offset=0xC0 (toujours) - offset de la liste des armatures
* 20 octets - Pad - (toujours)
* 4 octets [32] - Inconnu (flags des armatures ?) 1 octet par flag ?
* 32 octets - Pad - (toujours)
* 32 octets - armatures ?
* 32 octets - Pad - (toujours)
=== '''HSD Header''' - (0x20 octets) ===
* 4 octets - Taille totale du fichier
* 4 octets - Taille du Data block
* 4 octets - Nombre d'entrée dans la Table de relocs
* 4 octets - root0_count
* 4 octets - root1_count
* 12 octets - Pad - (toujours)
=== '''Data block''' : ===
* JOBJ, etc. -> Ces structures sont détaillée plus loin ci-dessous.
=== '''Relocation Table''' : ===
* Tableau d'offsets de 4 octets - Offsets des structures dans le DB.
=== '''Root Nodes (2)''' : ===
* Tableau de taille 8 * root0_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
* Tableau de taille 8 * root1_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
=== '''String Table''' : ===
* Suite de strings terminées par Null au nombre de root0_count + root1_count

== Structures rencontrées dans le DB ==
Note : l'arborescence est cumulative sur les transformations pour les relations parents->enfants

Les Noeuds Racine qui ont pour nom "scene_data" pointent sur un SObj :
=== '''SObj''' : (0x10 octets) ===
* 4 octets - JObjDescs_offsets_list_offset
* 4 octets - Cameras_list_offset
* 4 octets - Lights_list_offset
* 4 octets - Fog

"scene_data" == nom du nœud racine
JObjDescs_offsets_list_offset, cameras.. pointent sur une liste d'offsets terminée par 4 octets à 0x00.
lights_list_offset pointe sur des couples (4 octets - LObj_offset ; 4 octets - light_anim_pointer_offset)

=== '''JObjDesc''' : (0x10 octets) ===
* 4 octets - root_joint_offset - JObj
* 4 octets - joint_animations_offset - ?
* 4 octets - material_animations_offset - ?
* 4 octets - shape_animations_offset - ?

=== '''CObj''' : (0x38 octets) ===
* 4 octets - flags
* 4 octets - projection_type - ProjectionTypeEnum
* 2 octets - viewport_left
* 2 octets - viewport_right
* 2 octets - viewport_top
* 2 octets - viewport_bottom
* 4 octets - proj_width
* 4 octets - proj_height
* 4 octets - eye_offset - WObj
* 4 octets - target_offset - WObj
* 4 octets - roll
* 4 octets - Inconnu
* 4 octets - float - near_clip
* 4 octets - float - far_clip
* 4 octets - float - field_of_view
* 4 octets - float - aspect
Camera object. Note : pour frustrum ou ortho, la structure est différente.

* '''ProjectionTypeEnum''':
** PERSPECTIVE = 1
** FRUSTRUM = 2
** ORTHO = 3

=== '''WObj''': (0x14 octets) ===
* 4 octets - Inconnu
* 4 octets - float - v1
* 4 octets - float - v2
* 4 octets - float - v3
* 4 octets - Inconnu

eye / target

=== '''LObj''' : (0x1c octets) ===
* 4 octets - class_name
* 4 octets - next_offset
* 2 octets - flags - LObjFlagsEnum
* 2 octets - attenuation_flags - LObjAttenuationFlagsEnum
* 1 octet - color_r
* 1 octet - color_g
* 1 octet - color_b
* 1 octet - color_alpha
* 4 octets - lobj_point_offset - position
* 4 octets - infinite_data
* 4 octets - point_spot_data
light

* '''LObjFlagsEnum''' :
** LOBJ_AMBIANT = 00 00
** LOBJ_INFINITE = 00 01
** LOBJ_POINT = 00 02
** LOBJ_SPOT = 00 03
** LOBJ_DIFFUSE = 00 04
** LOBJ_SPECULAR = 00 08
** LOBJ_ALPHA = 00 10
** LOBJ_HIDDEN = 00 20
** LOBJ_RAW_PARAM = 00 40
** LOBJ_DIFF_DIRTY = 00 80
** LOBJ_SPEC_DIRTY = 01 00

* '''LObjAttenuationFlagsEnum''' :
** LOBJ_LIGHT_ATTN_NONE = 00 00
** LOBJ_LIGHT_ATTN = 00 01

=== '''LObjPoint''' : (0x14 octets) ===
* 4 octets - class_name
* 4 octets - float - x
* 4 octets - float - y
* 4 octets - float - z
* 4 octets - Inconnu

=== '''LightAnimPointer''' : (0x10 octets) ===
** 4 octets - next_offset - (LightAnimPointer)
** 4 octets - light_anim - ?
** 4 octets - position_anim - ?
** 4 octets - interst_anim - ?
Bugs dans HSDRaw - à tester

=== '''JObj''' : (0x40 octets) ===
* 4 octets - Inconnu
* 4 octets - flags
* 4 octets - child_offset (JObj)
* 4 octets - next_offset (JObj)
* 4 octets - dobj_offset (DObj)
* 4 octets [3] - float3 - rotation_xyz
* 4 octets [3] - float3 - scale_xyz
* 4 octets [3] - float3 - translation_xyz
* 4 octets - inverse_world_transform_offset (inverse world transform = Matrice de 4x3)
* 4 octets - robj_offset

Pointé par les listes dans Root Node scene_data.

* '''JObjFlagsEnum''' : (peuvent se cumuler)
** NULL = 00 00 00 00
** SKELETON = 00 00 00 01
** SKELETON_ROOT = 00 00 00 02
** ENVELOPE_MODEL = 00 00 00 04
** CLASSICAL_SCALING = 00 00 00 08
** HIDDEN = 00 00 00 10
** PTCL = 00 00 00 20
** MTX_DIRTY = 00 00 00 40
** LIGHTING = 00 00 00 80
** TEXGEN = 00 00 01 00
** BILLBOARD = 00 00 02 00
** VBILLBOARD = 00 00 04 00
** HBILLBOARD = 00 00 06 00
** RBILLBOARD = 00 00 08 00
** INSTANCE = 00 00 10 00
** PBILLBOARD = 00 00 20 00
** SPLINE = 00 00 40 00
** FLIP_IK = 00 00 80 00
** SPECULAR = 00 01 00 00
** USE_QUATERNION = 00 02 00 00
** OPA = 00 04 00 00
** XLU = 00 08 00 00
** TEXEDGE = 00 10 00 00
** JOINT1 = 00 20 00 00
** JOINT2 = 00 40 00 00
** EFFECTOR = 00 60 00 00
** USER_DEFINED_MTX = 00 80 00 00
** MTX_INDEPEND_PARENT = 01 00 00 00
** MTX_INDEPEND_SRT = 02 00 00 00
** MTX_SCALE_COMPENSATE = 04 00 00 00
** ROOT_OPA = 10 00 00 00
** ROOT_XLU = 20 00 00 00
** ROOT_TEXEDGE = 40 00 00 00

=== '''InverseWorldTransform''' : (0x30 octets) ===
* 4 octets - float - M11
* 4 octets - float - M12
* 4 octets - float - M13
* 4 octets - float - M14
* 4 octets - float - M21
* 4 octets - float - M22
* 4 octets - float - M23
* 4 octets - float - M24
* 4 octets - float - M31
* 4 octets - float - M32
* 4 octets - float - M33
* 4 octets - float - M34

=== '''DObj''' : (0x10 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - prochain DOBJ
* 4 octets - mobj_offset - material offset
* 4 octets - pobj_offset - mesh offset
Liste chaînée qui permet de récupérer l'ensemble des materials & mesh pour le JObj auquel il est lié.

=== '''MObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - render_flags - RenderFlagsEnum
* 4 octets - tobj_offset - offset de texture - peut être invalide s'il n'y a pas de texture pour le material
* 4 octets - material_offset - couleurs des materials ?
* 8 octets - PEDesc ?

Contient les textures & informations sur les couleurs des Materials.

* '''RenderFlagsEnum''' : (se cumulent)
** USER = 80 00 00 00
** CONSTANT = 00 00 00 01
** VERTEX = 00 00 00 02
** BOTH = 00 00 00 03
** DIFFUSE = 00 00 00 04
** SPECULAR = 00 00 00 08
** TEX0 = 00 00 00 10
** TEX1 = 00 00 00 20
** TEX2 = 00 00 00 40
** TEX3 = 00 00 00 80
** TEX4 = 00 00 01 00
** TEX5 = 00 00 02 00
** TEX6 = 00 00 04 00
** TEX7 = 00 00 08 00
** TOON = 00 00 10 00
** ALPHA_MAT = 00 00 20 00
** ALPHA_VTX = 00 00 40 00
** ALPHA_BOTH = 00 00 60 00
** ZOFST = 01 00 00 00
** EFFECT = 02 00 00 00
** SHADOW = 04 00 00 00
** ZMODE_ALWAYS = 08 00 00 00
** DF_ALL = 10 00 00 00
** NO_ZUPDATE = 20 00 00 00
** XLU = 40 00 00 00

=== '''TObj''' : (0x5c octets) ===
* 4 octets - ?
* 4 octets - ?
* 4 octets - tex_map_id - TexMapIdEnum
* 4 octets - gx_tex_gen_src - GXTexGenSrcEnum
* 4 octets - float - rx
* 4 octets - float - ry
* 4 octets - float - rz
* 4 octets - float - sx
* 4 octets - float - sy
* 4 octets - float - sz
* 4 octets - float - tx
* 4 octets - float - ty
* 4 octets - float - tz
* 4 octets - wrap_s - WrapEnum
* 4 octets - wrap_t - WrapEnum
* 1 octet - w_scale
* 1 octet - h_scale
* 2 octets - ?
* 1 octets - bump_map - (False = 00 ; True = 01)
* 4 bits - alpha_operation - AlphaOperationEnum
* 4 bits - color_operation - ColorOperationEnum
* 1 octet - shadow_lightmap - (False = 00 ; True = 01) (2 octets avec une Enum lightmap limite)
* 1 bit - ext_lightmap - (False = 0 ; True = 1)
* 1 bit - ambiant_lightmap - (False = 0 ; True = 1)
* 1 bit - specular_lightmap - (False = 0 ; True = 1)
* 1 bit - diffuse_lightmap (False = 0 ; True = 1)
* 4 bits - coord_type - CoordTypeEnum
* 4 octets - float - blending - utilisé quand color_operation ou alpha_operation == BLEND
* 4 octets - mag_filter - MagFilterEnum
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
Informations de Textures. Le TObj contient des informations sur les paramètres d'environnement de textures utilisés pour le rendu graphique ainsi que les offset de l'image et des données de la palette utilisés pour cette texture. Le plus important ici, c'est l'offset d'image et la palette/tlut - si l'image n'est pas indexée (RGBA, CMPR, etc.) alors la structure de description palette/tlut n'est pas utilisée.

* '''TexMapIdEnum''' :
** GX_TEXMAP0 = 00 00 00 00
** GX_TEXMAP1 = 00 00 00 01
** GX_TEXMAP2 = 00 00 00 02
** GX_TEXMAP3 = 00 00 00 03
** GX_TEXMAP4 = 00 00 00 04
** GX_TEXMAP5 = 00 00 00 05
** GX_TEXMAP6 = 00 00 00 06
** GX_TEXMAP7 = 00 00 00 07
** GX_MAX_TEXMAP = 00 00 00 08
** GX_TEXMAP_NULL = 00 00 00 09
** GX_TEXMAP_DISABLE = 00 00 00 0A

* '''GXTexGenSrcEnum''' :
** GX_TG_POS = 00 00 00 00
** GX_TG_NRM = 00 00 00 01
** GX_TG_BINRM = 00 00 00 02
** GX_TG_TANGENT = 00 00 00 03
** GX_TG_TEX0 = 00 00 00 04
** GX_TG_TEX1 = 00 00 00 05
** GX_TG_TEX2 = 00 00 00 06
** GX_TG_TEX3 = 00 00 00 07
** GX_TG_TEX4 = 00 00 00 08
** GX_TG_TEX5 = 00 00 00 09
** GX_TG_TEX6 = 00 00 00 0A
** GX_TG_TEX7 = 00 00 00 0B
** GX_TG_TEXCOORD0 = 00 00 00 0C
** GX_TG_TEXCOORD1 = 00 00 00 0D
** GX_TG_TEXCOORD2 = 00 00 00 0E
** GX_TG_TEXCOORD3 = 00 00 00 0F
** GX_TG_TEXCOORD4 = 00 00 00 10
** GX_TG_TEXCOORD5 = 00 00 00 11
** GX_TG_TEXCOORD6 = 00 00 00 12
** GX_TG_COLOR0 = 00 00 00 13
** GX_TG_COLOR1 = 00 00 00 14

* '''AlphaOperationEnum''':
** NONE = 0X
** ALPHAMASK = 1X
** BLEND = 2X
** MODULATE = 3X
** REPLACE = 4X
** PASS = 5X
** ADD = 6X
** SUB = 7X

* '''ColorOperationEnum''':
** NONE = X0
** ALPHA_MASK = X1
** RGB_MASK = X2
** BLEND = X3
** MODULATE = X4
** REPLACE = X5
** PASS = X6
** ADD = X7
** SUB = X8

* '''CoordTypeEnum''':
** UV = X0
** REFLECTION = X1
** HILIGHT = X2
** SHADOW = X3
** TOON = X4
** GRADATION = X5

* '''MagFilterEnum''':
** GX_NEAR = 00 00 00 00
** GX_LINEAR = 00 00 00 01
** GX_NEAR_MIP_NEAR = 00 00 00 02
** GX_LIN_MIP_NEAR = 00 00 00 03
** GX_NEAR_MIP_LIN = 00 00 00 04
** GX_LIN_MIP_LIN = 00 00 00 05

* '''WrapEnum''':
** CLAMP = 00 00 00 00
** REPEAT = 00 00 00 01
** MIRROR = 00 00 00 02

=== '''Material''' : (0x14 octets) ===
* 1 octets - AMB_R - (ambient)
* 1 octets - AMB_G
* 1 octets - AMB_B
* 1 octets - AMB_A
* 1 octets - DIF_R - (diffuse)
* 1 octets - DIF_G
* 1 octets - DIF_B
* 1 octets - DIF_A
* 1 octets - SPC_R - (specular)
* 1 octets - SPC_G
* 1 octets - SPC_B
* 1 octets - SPC_A
* 4 octets - float - alpha
* 4 octets - float - shininess

=== '''PObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - pobj
* 4 octets - vertex_attr_list_offset
* 2 octets - Flags - PObjFlagsEnum
* 2 octets - display_list_size - number of 0x20 (32) byte blocks occupied by display list data
* 4 octets - display_list_offset
* 4 octets - weight_list_offset - ? verifier qu'on retrouve bien le tableau d'envelope_weights à cet offset

Comme l'indique next_offset, il s'agit d'une liste de meshs à afficher pour un material donné référencé par un dobj. PObj contient les offsets de vertex attributes / display list / joint weight list ce qui suffit et permet d’interpréter et traiter les coordonnées de vertices, normals & textures.

Les attributs vertex sont les plus important - les parametres specifiés contrôlent tout : du format, de la taille des données de chaque vertex, normal et coordonnées de textures et comment ces valeurs sont dimensionnées (scaled) par rapport à la présence et la taille de chaque valeur d'index qui apparaît dans la display list information.

* '''PObjFlagsEnum''' :
** Inconnu0 = 00 01
** Inconnu1 = 00 02
** ANIM = 00 08
** SHAPE_ANIM = 10 00
** ENVELOPE = 20 00
** CULLBACK = 40 00
** CULLFRONT = 80 00

=== EnvelopeWeights : (0x? octets) ===
* 4 octets - envelope_count
* [envelope_count]:
** 4 octets - float - weight
** 4 octets - pad ?
* 4 octets - jobj_list_offset

=== not verified yet ===

* '''IMAGE_HEADER''' :
** 4 octets - image_offset - image data
** 2 octets - width
** 2 octets - height
** 4 octets - image_format

* '''PALETTE_HEADER''' : (0x10)
** 4 octets - palette_offset - palette data
** 4 octets - palette_format
** 4 octets - Inconnu
** 2 octets - color_count
** 2 octets - Inconnu

image_offset et palette_offset sont souvent partagés par plusieurs textures - savoir ça permet de retrouver toutes les informations sur les images des textures (largeur, hauteur, format), ainsi que le format et le nombre de couleurs de la palette/tlut.

Le format d'image ne détermine pas le nombre total de couleurs de la palette qu'elle utilisent. Par exemple, une image indexée sur 8 bits aurait un maximum de 256 couleurs mais seulement 136 ou 221 couleurs sont actuellement utilisées. De la sorte, la palette n'utilisera pas la taille totale qu'elle devrait utiliser.

Les images suivent la structure généralement utilisée par la GameCube :

IMAGE FORMATS :
* case 0: //i4
* case 1: //i8
* case 2: //i4a4
* case 3: //i8a8
* case 4: //r5g6b5
* case 5: //rgb5a3
* case 6: //r8g8b8a8
* case 8: //index4
* case 9: //index8
* case 0xa: //index14x2
* case 0xe: //s3tc1

Les formats indexés utilisent aussi les informations de palettes/tlut et les données peuvent apparaître en plusieurs formats :

PALETTE FORMATS :
* case 0: //ia8
* case 1: //r5g6b5
* case 2: //rgb5a3

---> "Joint Data - Accessing Geometry, Mesh, and Vertex Attributes" https://smashboards.com/threads/melee-dat-format.292603/

trad a revoir à partir de là, il faut investiguer le rendu 3D sur GameCube pour mieux comprendre

// déclaration d'un vertex et attribute information
// attr, type, cnt, data_type, flags?, file_offset
* ATTR_DATA
** 4 octets - GXAttr vtx_attr_offset - attr
** 4 octets - GXAttrType vtx_attr_type - index_type
** 4 octets - GXCompCnt comp_cnt - cnt
** 4 octets - GXCompType comp_type - data_type
** 1 octets - scale
** 1 octets - Inconnu
** 2 octets - vtx_stride
** 2 octets - data_offset

vertex_attr_offset pointe sur une liste d'attributs de vertex. Leur nombre n'est pas donné. Les données dans cette structure suivent les informations et les types conçus par l'architecture GameCube/WII et son API. La liste est terminée par une valeur spécifique de vtx_attr qui signale la fin de cette liste. Avec un accès à la doku SDK, il serait fortement conseillé de lire la section à propos des "vertex attributes and other specifications".

La valeur de vtx_attr determine le type de donnée que cet attribut désigne et peut indiquer un nombre de types natifs utilisés utilisés pour passer les données entre les interfaces logicielles et matérielles.

Les valeures possibles sont les suivantes :
* enum GXAttr (4 octets)
** GX_VA_PNMTXIDX = 0, // position/normal matrix index
** GX_VA_TEX0MTXIDX, // texture 0 matrix index
** GX_VA_TEX1MTXIDX, // texture 1 matrix index
** GX_VA_TEX2MTXIDX, // texture 2 matrix index
** GX_VA_TEX3MTXIDX, // texture 3 matrix index
** GX_VA_TEX4MTXIDX, // texture 4 matrix index
** GX_VA_TEX5MTXIDX, // texture 5 matrix index
** GX_VA_TEX6MTXIDX, // texture 6 matrix index
** GX_VA_TEX7MTXIDX, // texture 7 matrix index
** GX_VA_POS = 9, // position
** GX_VA_NRM, // normal
** GX_VA_CLR0, // color 0
** GX_VA_CLR1, // color 1
** GX_VA_TEX0, // input texture coordinate 0
** GX_VA_TEX1, // input texture coordinate 1
** GX_VA_TEX2, // input texture coordinate 2
** GX_VA_TEX3, // input texture coordinate 3
** GX_VA_TEX4, // input texture coordinate 4
** GX_VA_TEX5, // input texture coordinate 5
** GX_VA_TEX6, // input texture coordinate 6
** GX_VA_TEX7, // input texture coordinate 7

** GX_POS_MTX_ARRAY, // position matrix array pointer
** GX_NRM_MTX_ARRAY, // normal matrix array pointer
** GX_TEX_MTX_ARRAY, // texture matrix array pointer
** GX_LIGHT_ARRAY, // light parameter array pointer
** GX_VA_NBT, // normal, bi-normal, tangent
** GX_VA_MAX_ATTR, // maximum number of vertex attributes

** GX_VA_NULL = 0xff // NULL attribute (to mark end of lists)

Toutes les données nécessaires pour représenter un mesh peuvent être spécifiées et indexées d'une manière ou d'une autre. De même, GX_VA_TEX0MTXIDX, GX_VA_CLR0, et autres sont aussi possibles - les valeurs les plus fréquentes dans les données SSBM sont : GX_VA_PNMTXIDX, GX_VA_POS, GX_VA_NRM, et GX_VA_TEX0. Which is to be expected as joint matrices, vertex positions/normals, and texture coordinates respectively are probably the most basic of elements needed to display a texture mesh, whether static or animated.

When the value of vtx_attr == GX_VA_NULL (0xFF), the end of the vertex attribute array has been reached.

The vtx_attr_type values is actually associated with how the value is indexed, and can thus also determine the size of the index value within the display list data.

* 4 octets - enum GXAttrType
** GX_NONE = 0,
** GX_DIRECT,
** GX_INDEX8,
** GX_INDEX16

* Structures COLL_DATA : (données de collisions)
** 4 octets - vertex_offset (2 float par entrée correspondant à des données 2D probablement)
** 4 octets - vertex_count
** 4 octets - index_offset
** 4 octets - index_count
** 4 octets [5] - tableau inconnu
*** 2 octets - index_start
*** 2 octets - index_count
** 4 octets - Inconnu
** 4 octets - Inconnu

[[Category:Implementations]]
[[Category:Gotcha Force]]

Models

2023-10-07T13:52:07Z

Algoflash: /* Fichiers concernés */

[[Gotcha Force | ← Gotcha Force]]

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

== Gotcha Force Models ==

Gotcha Force models work as those from the game Super Smash Bros Melee (SSBM) investigated by its [https://smashboards.com/threads/melee-dat-format.292603/ community].

A model is a file format that organizes objects and resources serialized to be used by the '''H'''al '''S'''ys'''D'''olphin ('''HSD''') library. The HSD library is used in several Capcom games. These are graphic materials structured in a hierarchical way. Some pictures present in the models seem to indicate the use of [https://learn.foundry.com/modo/901/content/help/pages/shading_lighting/shader_items/matcap.html matcap] technic. This library uses Dolphin SDK functions like GX / MTX and so on.

=== Affected files ===
All files in the AFS having '''_mdl''' in theirs names are models described in this page. We notice also [[ARZ (Gotcha Force)|.arz]] which are compressed models. collision.arc and tdc00.arc to tdc09.arc are also models.

Les fichiers modèles se retrouvent aussi dans les pzz des borgs (plxxxx.pzz) en position 004 à 009.

=== HSDRaw ===
HSDRaw, un éditeur 3D dotnet de ce format est instable sur mon Windows (algoflash). Il est cependant prouvé qu'un edit des _mdl pour commencer à l'offset 0x100 - après le préambule - permet de visualiser le fichier sur HSDRaw et d'avoir le rendu 3D du Borg (click sur le premier dossier JOBJ - puis le JOBJ dedans et double click sur le nœud en violet). Cela devrait aussi permettre d'éditer certaines propriétés ?

== Structure générale ==
Le format des modèles se découpe en plusieurs blocks. Le préambule fait 0x100 octets au tout début du fichier. Il est souvent absent. Toutes les valeurs sont en unsigned big endian, et le pad est en Nulls bytes (\x00). Les offsets trouvés après le début du Data Block (DB) sont relatifs au début du DB. La table de relocs est un tableau d'offsets de 4 octets (relatif au DB) permettant de traduire en adressage absolu les offsets des structures lors du chargement mémoire. La table de reloc permet par exemple de délimiter les structures du fait qu'il est peu probable qu'un offset pointe au milieu d'une structure.

L'ensemble des fichiers répondant à ce format on un seul root_node de type SObj (Scene data).

=== '''Préambule''' : (0x100 octets / 0 octets) ===
* 4 octets - hsd_header_offset=0x100 (toujours)
* 4 octets - bones_flags_table_offset=0x20 (toujours) - offset de la liste des flags des armatures
* 4 octets - bones_table_offset=0xC0 (toujours) - offset de la liste des armatures
* 20 octets - Pad - (toujours)
* 4 octets [32] - Inconnu (flags des armatures ?) 1 octet par flag ?
* 32 octets - Pad - (toujours)
* 32 octets - armatures ?
* 32 octets - Pad - (toujours)
=== '''HSD Header''' - (0x20 octets) ===
* 4 octets - Taille totale du fichier
* 4 octets - Taille du Data block
* 4 octets - Nombre d'entrée dans la Table de relocs
* 4 octets - root0_count
* 4 octets - root1_count
* 12 octets - Pad - (toujours)
=== '''Data block''' : ===
* JOBJ, etc. -> Ces structures sont détaillée plus loin ci-dessous.
=== '''Relocation Table''' : ===
* Tableau d'offsets de 4 octets - Offsets des structures dans le DB.
=== '''Root Nodes (2)''' : ===
* Tableau de taille 8 * root0_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
* Tableau de taille 8 * root1_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
=== '''String Table''' : ===
* Suite de strings terminées par Null au nombre de root0_count + root1_count

== Structures rencontrées dans le DB ==
Note : l'arborescence est cumulative sur les transformations pour les relations parents->enfants

Les Noeuds Racine qui ont pour nom "scene_data" pointent sur un SObj :
=== '''SObj''' : (0x10 octets) ===
* 4 octets - JObjDescs_offsets_list_offset
* 4 octets - Cameras_list_offset
* 4 octets - Lights_list_offset
* 4 octets - Fog

"scene_data" == nom du nœud racine
JObjDescs_offsets_list_offset, cameras.. pointent sur une liste d'offsets terminée par 4 octets à 0x00.
lights_list_offset pointe sur des couples (4 octets - LObj_offset ; 4 octets - light_anim_pointer_offset)

=== '''JObjDesc''' : (0x10 octets) ===
* 4 octets - root_joint_offset - JObj
* 4 octets - joint_animations_offset - ?
* 4 octets - material_animations_offset - ?
* 4 octets - shape_animations_offset - ?

=== '''CObj''' : (0x38 octets) ===
* 4 octets - flags
* 4 octets - projection_type - ProjectionTypeEnum
* 2 octets - viewport_left
* 2 octets - viewport_right
* 2 octets - viewport_top
* 2 octets - viewport_bottom
* 4 octets - proj_width
* 4 octets - proj_height
* 4 octets - eye_offset - WObj
* 4 octets - target_offset - WObj
* 4 octets - roll
* 4 octets - Inconnu
* 4 octets - float - near_clip
* 4 octets - float - far_clip
* 4 octets - float - field_of_view
* 4 octets - float - aspect
Camera object. Note : pour frustrum ou ortho, la structure est différente.

* '''ProjectionTypeEnum''':
** PERSPECTIVE = 1
** FRUSTRUM = 2
** ORTHO = 3

=== '''WObj''': (0x14 octets) ===
* 4 octets - Inconnu
* 4 octets - float - v1
* 4 octets - float - v2
* 4 octets - float - v3
* 4 octets - Inconnu

eye / target

=== '''LObj''' : (0x1c octets) ===
* 4 octets - class_name
* 4 octets - next_offset
* 2 octets - flags - LObjFlagsEnum
* 2 octets - attenuation_flags - LObjAttenuationFlagsEnum
* 1 octet - color_r
* 1 octet - color_g
* 1 octet - color_b
* 1 octet - color_alpha
* 4 octets - lobj_point_offset - position
* 4 octets - infinite_data
* 4 octets - point_spot_data
light

* '''LObjFlagsEnum''' :
** LOBJ_AMBIANT = 00 00
** LOBJ_INFINITE = 00 01
** LOBJ_POINT = 00 02
** LOBJ_SPOT = 00 03
** LOBJ_DIFFUSE = 00 04
** LOBJ_SPECULAR = 00 08
** LOBJ_ALPHA = 00 10
** LOBJ_HIDDEN = 00 20
** LOBJ_RAW_PARAM = 00 40
** LOBJ_DIFF_DIRTY = 00 80
** LOBJ_SPEC_DIRTY = 01 00

* '''LObjAttenuationFlagsEnum''' :
** LOBJ_LIGHT_ATTN_NONE = 00 00
** LOBJ_LIGHT_ATTN = 00 01

=== '''LObjPoint''' : (0x14 octets) ===
* 4 octets - class_name
* 4 octets - float - x
* 4 octets - float - y
* 4 octets - float - z
* 4 octets - Inconnu

=== '''LightAnimPointer''' : (0x10 octets) ===
** 4 octets - next_offset - (LightAnimPointer)
** 4 octets - light_anim - ?
** 4 octets - position_anim - ?
** 4 octets - interst_anim - ?
Bugs dans HSDRaw - à tester

=== '''JObj''' : (0x40 octets) ===
* 4 octets - Inconnu
* 4 octets - flags
* 4 octets - child_offset (JObj)
* 4 octets - next_offset (JObj)
* 4 octets - dobj_offset (DObj)
* 4 octets [3] - float3 - rotation_xyz
* 4 octets [3] - float3 - scale_xyz
* 4 octets [3] - float3 - translation_xyz
* 4 octets - inverse_world_transform_offset (inverse world transform = Matrice de 4x3)
* 4 octets - robj_offset

Pointé par les listes dans Root Node scene_data.

* '''JObjFlagsEnum''' : (peuvent se cumuler)
** NULL = 00 00 00 00
** SKELETON = 00 00 00 01
** SKELETON_ROOT = 00 00 00 02
** ENVELOPE_MODEL = 00 00 00 04
** CLASSICAL_SCALING = 00 00 00 08
** HIDDEN = 00 00 00 10
** PTCL = 00 00 00 20
** MTX_DIRTY = 00 00 00 40
** LIGHTING = 00 00 00 80
** TEXGEN = 00 00 01 00
** BILLBOARD = 00 00 02 00
** VBILLBOARD = 00 00 04 00
** HBILLBOARD = 00 00 06 00
** RBILLBOARD = 00 00 08 00
** INSTANCE = 00 00 10 00
** PBILLBOARD = 00 00 20 00
** SPLINE = 00 00 40 00
** FLIP_IK = 00 00 80 00
** SPECULAR = 00 01 00 00
** USE_QUATERNION = 00 02 00 00
** OPA = 00 04 00 00
** XLU = 00 08 00 00
** TEXEDGE = 00 10 00 00
** JOINT1 = 00 20 00 00
** JOINT2 = 00 40 00 00
** EFFECTOR = 00 60 00 00
** USER_DEFINED_MTX = 00 80 00 00
** MTX_INDEPEND_PARENT = 01 00 00 00
** MTX_INDEPEND_SRT = 02 00 00 00
** MTX_SCALE_COMPENSATE = 04 00 00 00
** ROOT_OPA = 10 00 00 00
** ROOT_XLU = 20 00 00 00
** ROOT_TEXEDGE = 40 00 00 00

=== '''InverseWorldTransform''' : (0x30 octets) ===
* 4 octets - float - M11
* 4 octets - float - M12
* 4 octets - float - M13
* 4 octets - float - M14
* 4 octets - float - M21
* 4 octets - float - M22
* 4 octets - float - M23
* 4 octets - float - M24
* 4 octets - float - M31
* 4 octets - float - M32
* 4 octets - float - M33
* 4 octets - float - M34

=== '''DObj''' : (0x10 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - prochain DOBJ
* 4 octets - mobj_offset - material offset
* 4 octets - pobj_offset - mesh offset
Liste chaînée qui permet de récupérer l'ensemble des materials & mesh pour le JObj auquel il est lié.

=== '''MObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - render_flags - RenderFlagsEnum
* 4 octets - tobj_offset - offset de texture - peut être invalide s'il n'y a pas de texture pour le material
* 4 octets - material_offset - couleurs des materials ?
* 8 octets - PEDesc ?

Contient les textures & informations sur les couleurs des Materials.

* '''RenderFlagsEnum''' : (se cumulent)
** USER = 80 00 00 00
** CONSTANT = 00 00 00 01
** VERTEX = 00 00 00 02
** BOTH = 00 00 00 03
** DIFFUSE = 00 00 00 04
** SPECULAR = 00 00 00 08
** TEX0 = 00 00 00 10
** TEX1 = 00 00 00 20
** TEX2 = 00 00 00 40
** TEX3 = 00 00 00 80
** TEX4 = 00 00 01 00
** TEX5 = 00 00 02 00
** TEX6 = 00 00 04 00
** TEX7 = 00 00 08 00
** TOON = 00 00 10 00
** ALPHA_MAT = 00 00 20 00
** ALPHA_VTX = 00 00 40 00
** ALPHA_BOTH = 00 00 60 00
** ZOFST = 01 00 00 00
** EFFECT = 02 00 00 00
** SHADOW = 04 00 00 00
** ZMODE_ALWAYS = 08 00 00 00
** DF_ALL = 10 00 00 00
** NO_ZUPDATE = 20 00 00 00
** XLU = 40 00 00 00

=== '''TObj''' : (0x5c octets) ===
* 4 octets - ?
* 4 octets - ?
* 4 octets - tex_map_id - TexMapIdEnum
* 4 octets - gx_tex_gen_src - GXTexGenSrcEnum
* 4 octets - float - rx
* 4 octets - float - ry
* 4 octets - float - rz
* 4 octets - float - sx
* 4 octets - float - sy
* 4 octets - float - sz
* 4 octets - float - tx
* 4 octets - float - ty
* 4 octets - float - tz
* 4 octets - wrap_s - WrapEnum
* 4 octets - wrap_t - WrapEnum
* 1 octet - w_scale
* 1 octet - h_scale
* 2 octets - ?
* 1 octets - bump_map - (False = 00 ; True = 01)
* 4 bits - alpha_operation - AlphaOperationEnum
* 4 bits - color_operation - ColorOperationEnum
* 1 octet - shadow_lightmap - (False = 00 ; True = 01) (2 octets avec une Enum lightmap limite)
* 1 bit - ext_lightmap - (False = 0 ; True = 1)
* 1 bit - ambiant_lightmap - (False = 0 ; True = 1)
* 1 bit - specular_lightmap - (False = 0 ; True = 1)
* 1 bit - diffuse_lightmap (False = 0 ; True = 1)
* 4 bits - coord_type - CoordTypeEnum
* 4 octets - float - blending - utilisé quand color_operation ou alpha_operation == BLEND
* 4 octets - mag_filter - MagFilterEnum
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
Informations de Textures. Le TObj contient des informations sur les paramètres d'environnement de textures utilisés pour le rendu graphique ainsi que les offset de l'image et des données de la palette utilisés pour cette texture. Le plus important ici, c'est l'offset d'image et la palette/tlut - si l'image n'est pas indexée (RGBA, CMPR, etc.) alors la structure de description palette/tlut n'est pas utilisée.

* '''TexMapIdEnum''' :
** GX_TEXMAP0 = 00 00 00 00
** GX_TEXMAP1 = 00 00 00 01
** GX_TEXMAP2 = 00 00 00 02
** GX_TEXMAP3 = 00 00 00 03
** GX_TEXMAP4 = 00 00 00 04
** GX_TEXMAP5 = 00 00 00 05
** GX_TEXMAP6 = 00 00 00 06
** GX_TEXMAP7 = 00 00 00 07
** GX_MAX_TEXMAP = 00 00 00 08
** GX_TEXMAP_NULL = 00 00 00 09
** GX_TEXMAP_DISABLE = 00 00 00 0A

* '''GXTexGenSrcEnum''' :
** GX_TG_POS = 00 00 00 00
** GX_TG_NRM = 00 00 00 01
** GX_TG_BINRM = 00 00 00 02
** GX_TG_TANGENT = 00 00 00 03
** GX_TG_TEX0 = 00 00 00 04
** GX_TG_TEX1 = 00 00 00 05
** GX_TG_TEX2 = 00 00 00 06
** GX_TG_TEX3 = 00 00 00 07
** GX_TG_TEX4 = 00 00 00 08
** GX_TG_TEX5 = 00 00 00 09
** GX_TG_TEX6 = 00 00 00 0A
** GX_TG_TEX7 = 00 00 00 0B
** GX_TG_TEXCOORD0 = 00 00 00 0C
** GX_TG_TEXCOORD1 = 00 00 00 0D
** GX_TG_TEXCOORD2 = 00 00 00 0E
** GX_TG_TEXCOORD3 = 00 00 00 0F
** GX_TG_TEXCOORD4 = 00 00 00 10
** GX_TG_TEXCOORD5 = 00 00 00 11
** GX_TG_TEXCOORD6 = 00 00 00 12
** GX_TG_COLOR0 = 00 00 00 13
** GX_TG_COLOR1 = 00 00 00 14

* '''AlphaOperationEnum''':
** NONE = 0X
** ALPHAMASK = 1X
** BLEND = 2X
** MODULATE = 3X
** REPLACE = 4X
** PASS = 5X
** ADD = 6X
** SUB = 7X

* '''ColorOperationEnum''':
** NONE = X0
** ALPHA_MASK = X1
** RGB_MASK = X2
** BLEND = X3
** MODULATE = X4
** REPLACE = X5
** PASS = X6
** ADD = X7
** SUB = X8

* '''CoordTypeEnum''':
** UV = X0
** REFLECTION = X1
** HILIGHT = X2
** SHADOW = X3
** TOON = X4
** GRADATION = X5

* '''MagFilterEnum''':
** GX_NEAR = 00 00 00 00
** GX_LINEAR = 00 00 00 01
** GX_NEAR_MIP_NEAR = 00 00 00 02
** GX_LIN_MIP_NEAR = 00 00 00 03
** GX_NEAR_MIP_LIN = 00 00 00 04
** GX_LIN_MIP_LIN = 00 00 00 05

* '''WrapEnum''':
** CLAMP = 00 00 00 00
** REPEAT = 00 00 00 01
** MIRROR = 00 00 00 02

=== '''Material''' : (0x14 octets) ===
* 1 octets - AMB_R - (ambient)
* 1 octets - AMB_G
* 1 octets - AMB_B
* 1 octets - AMB_A
* 1 octets - DIF_R - (diffuse)
* 1 octets - DIF_G
* 1 octets - DIF_B
* 1 octets - DIF_A
* 1 octets - SPC_R - (specular)
* 1 octets - SPC_G
* 1 octets - SPC_B
* 1 octets - SPC_A
* 4 octets - float - alpha
* 4 octets - float - shininess

=== '''PObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - pobj
* 4 octets - vertex_attr_list_offset
* 2 octets - Flags - PObjFlagsEnum
* 2 octets - display_list_size - number of 0x20 (32) byte blocks occupied by display list data
* 4 octets - display_list_offset
* 4 octets - weight_list_offset - ? verifier qu'on retrouve bien le tableau d'envelope_weights à cet offset

Comme l'indique next_offset, il s'agit d'une liste de meshs à afficher pour un material donné référencé par un dobj. PObj contient les offsets de vertex attributes / display list / joint weight list ce qui suffit et permet d’interpréter et traiter les coordonnées de vertices, normals & textures.

Les attributs vertex sont les plus important - les parametres specifiés contrôlent tout : du format, de la taille des données de chaque vertex, normal et coordonnées de textures et comment ces valeurs sont dimensionnées (scaled) par rapport à la présence et la taille de chaque valeur d'index qui apparaît dans la display list information.

* '''PObjFlagsEnum''' :
** Inconnu0 = 00 01
** Inconnu1 = 00 02
** ANIM = 00 08
** SHAPE_ANIM = 10 00
** ENVELOPE = 20 00
** CULLBACK = 40 00
** CULLFRONT = 80 00

=== EnvelopeWeights : (0x? octets) ===
* 4 octets - envelope_count
* [envelope_count]:
** 4 octets - float - weight
** 4 octets - pad ?
* 4 octets - jobj_list_offset

=== not verified yet ===

* '''IMAGE_HEADER''' :
** 4 octets - image_offset - image data
** 2 octets - width
** 2 octets - height
** 4 octets - image_format

* '''PALETTE_HEADER''' : (0x10)
** 4 octets - palette_offset - palette data
** 4 octets - palette_format
** 4 octets - Inconnu
** 2 octets - color_count
** 2 octets - Inconnu

image_offset et palette_offset sont souvent partagés par plusieurs textures - savoir ça permet de retrouver toutes les informations sur les images des textures (largeur, hauteur, format), ainsi que le format et le nombre de couleurs de la palette/tlut.

Le format d'image ne détermine pas le nombre total de couleurs de la palette qu'elle utilisent. Par exemple, une image indexée sur 8 bits aurait un maximum de 256 couleurs mais seulement 136 ou 221 couleurs sont actuellement utilisées. De la sorte, la palette n'utilisera pas la taille totale qu'elle devrait utiliser.

Les images suivent la structure généralement utilisée par la GameCube :

IMAGE FORMATS :
* case 0: //i4
* case 1: //i8
* case 2: //i4a4
* case 3: //i8a8
* case 4: //r5g6b5
* case 5: //rgb5a3
* case 6: //r8g8b8a8
* case 8: //index4
* case 9: //index8
* case 0xa: //index14x2
* case 0xe: //s3tc1

Les formats indexés utilisent aussi les informations de palettes/tlut et les données peuvent apparaître en plusieurs formats :

PALETTE FORMATS :
* case 0: //ia8
* case 1: //r5g6b5
* case 2: //rgb5a3

---> "Joint Data - Accessing Geometry, Mesh, and Vertex Attributes" https://smashboards.com/threads/melee-dat-format.292603/

trad a revoir à partir de là, il faut investiguer le rendu 3D sur GameCube pour mieux comprendre

// déclaration d'un vertex et attribute information
// attr, type, cnt, data_type, flags?, file_offset
* ATTR_DATA
** 4 octets - GXAttr vtx_attr_offset - attr
** 4 octets - GXAttrType vtx_attr_type - index_type
** 4 octets - GXCompCnt comp_cnt - cnt
** 4 octets - GXCompType comp_type - data_type
** 1 octets - scale
** 1 octets - Inconnu
** 2 octets - vtx_stride
** 2 octets - data_offset

vertex_attr_offset pointe sur une liste d'attributs de vertex. Leur nombre n'est pas donné. Les données dans cette structure suivent les informations et les types conçus par l'architecture GameCube/WII et son API. La liste est terminée par une valeur spécifique de vtx_attr qui signale la fin de cette liste. Avec un accès à la doku SDK, il serait fortement conseillé de lire la section à propos des "vertex attributes and other specifications".

La valeur de vtx_attr determine le type de donnée que cet attribut désigne et peut indiquer un nombre de types natifs utilisés utilisés pour passer les données entre les interfaces logicielles et matérielles.

Les valeures possibles sont les suivantes :
* enum GXAttr (4 octets)
** GX_VA_PNMTXIDX = 0, // position/normal matrix index
** GX_VA_TEX0MTXIDX, // texture 0 matrix index
** GX_VA_TEX1MTXIDX, // texture 1 matrix index
** GX_VA_TEX2MTXIDX, // texture 2 matrix index
** GX_VA_TEX3MTXIDX, // texture 3 matrix index
** GX_VA_TEX4MTXIDX, // texture 4 matrix index
** GX_VA_TEX5MTXIDX, // texture 5 matrix index
** GX_VA_TEX6MTXIDX, // texture 6 matrix index
** GX_VA_TEX7MTXIDX, // texture 7 matrix index
** GX_VA_POS = 9, // position
** GX_VA_NRM, // normal
** GX_VA_CLR0, // color 0
** GX_VA_CLR1, // color 1
** GX_VA_TEX0, // input texture coordinate 0
** GX_VA_TEX1, // input texture coordinate 1
** GX_VA_TEX2, // input texture coordinate 2
** GX_VA_TEX3, // input texture coordinate 3
** GX_VA_TEX4, // input texture coordinate 4
** GX_VA_TEX5, // input texture coordinate 5
** GX_VA_TEX6, // input texture coordinate 6
** GX_VA_TEX7, // input texture coordinate 7

** GX_POS_MTX_ARRAY, // position matrix array pointer
** GX_NRM_MTX_ARRAY, // normal matrix array pointer
** GX_TEX_MTX_ARRAY, // texture matrix array pointer
** GX_LIGHT_ARRAY, // light parameter array pointer
** GX_VA_NBT, // normal, bi-normal, tangent
** GX_VA_MAX_ATTR, // maximum number of vertex attributes

** GX_VA_NULL = 0xff // NULL attribute (to mark end of lists)

Toutes les données nécessaires pour représenter un mesh peuvent être spécifiées et indexées d'une manière ou d'une autre. De même, GX_VA_TEX0MTXIDX, GX_VA_CLR0, et autres sont aussi possibles - les valeurs les plus fréquentes dans les données SSBM sont : GX_VA_PNMTXIDX, GX_VA_POS, GX_VA_NRM, et GX_VA_TEX0. Which is to be expected as joint matrices, vertex positions/normals, and texture coordinates respectively are probably the most basic of elements needed to display a texture mesh, whether static or animated.

When the value of vtx_attr == GX_VA_NULL (0xFF), the end of the vertex attribute array has been reached.

The vtx_attr_type values is actually associated with how the value is indexed, and can thus also determine the size of the index value within the display list data.

* 4 octets - enum GXAttrType
** GX_NONE = 0,
** GX_DIRECT,
** GX_INDEX8,
** GX_INDEX16

* Structures COLL_DATA : (données de collisions)
** 4 octets - vertex_offset (2 float par entrée correspondant à des données 2D probablement)
** 4 octets - vertex_count
** 4 octets - index_offset
** 4 octets - index_count
** 4 octets [5] - tableau inconnu
*** 2 octets - index_start
*** 2 octets - index_count
** 4 octets - Inconnu
** 4 octets - Inconnu

[[Category:Implementations]]
[[Category:Gotcha Force]]

Models

2023-10-07T13:44:51Z

Algoflash: /* Gotcha Force Models */

[[Gotcha Force | ← Gotcha Force]]

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

== Gotcha Force Models ==

Gotcha Force models work as those from the game Super Smash Bros Melee (SSBM) investigated by its [https://smashboards.com/threads/melee-dat-format.292603/ community].

A model is a file format that organizes objects and resources serialized to be used by the '''H'''al '''S'''ys'''D'''olphin ('''HSD''') library. The HSD library is used in several Capcom games. These are graphic materials structured in a hierarchical way. Some pictures present in the models seem to indicate the use of [https://learn.foundry.com/modo/901/content/help/pages/shading_lighting/shader_items/matcap.html matcap] technic. This library uses Dolphin SDK functions like GX / MTX and so on.

=== Fichiers concernés ===
L'ensemble des fichiers ayant dans leur titre '''_mdl''' sont des fichiers modèles correspondant au format décrit dans cette page. On notera les fichiers [[ARZ (Gotcha Force)|.arz]] qui sont des modèles compressés. Le fichier collision.arc et les fichiers tdc00.arc à tdc09.arc sont aussi des modèles.

Les fichiers modèles se retrouvent aussi dans les pzz des borgs (plxxxx.pzz) en position 004 à 009.

=== HSDRaw ===
HSDRaw, un éditeur 3D dotnet de ce format est instable sur mon Windows (algoflash). Il est cependant prouvé qu'un edit des _mdl pour commencer à l'offset 0x100 - après le préambule - permet de visualiser le fichier sur HSDRaw et d'avoir le rendu 3D du Borg (click sur le premier dossier JOBJ - puis le JOBJ dedans et double click sur le nœud en violet). Cela devrait aussi permettre d'éditer certaines propriétés ?

== Structure générale ==
Le format des modèles se découpe en plusieurs blocks. Le préambule fait 0x100 octets au tout début du fichier. Il est souvent absent. Toutes les valeurs sont en unsigned big endian, et le pad est en Nulls bytes (\x00). Les offsets trouvés après le début du Data Block (DB) sont relatifs au début du DB. La table de relocs est un tableau d'offsets de 4 octets (relatif au DB) permettant de traduire en adressage absolu les offsets des structures lors du chargement mémoire. La table de reloc permet par exemple de délimiter les structures du fait qu'il est peu probable qu'un offset pointe au milieu d'une structure.

L'ensemble des fichiers répondant à ce format on un seul root_node de type SObj (Scene data).

=== '''Préambule''' : (0x100 octets / 0 octets) ===
* 4 octets - hsd_header_offset=0x100 (toujours)
* 4 octets - bones_flags_table_offset=0x20 (toujours) - offset de la liste des flags des armatures
* 4 octets - bones_table_offset=0xC0 (toujours) - offset de la liste des armatures
* 20 octets - Pad - (toujours)
* 4 octets [32] - Inconnu (flags des armatures ?) 1 octet par flag ?
* 32 octets - Pad - (toujours)
* 32 octets - armatures ?
* 32 octets - Pad - (toujours)
=== '''HSD Header''' - (0x20 octets) ===
* 4 octets - Taille totale du fichier
* 4 octets - Taille du Data block
* 4 octets - Nombre d'entrée dans la Table de relocs
* 4 octets - root0_count
* 4 octets - root1_count
* 12 octets - Pad - (toujours)
=== '''Data block''' : ===
* JOBJ, etc. -> Ces structures sont détaillée plus loin ci-dessous.
=== '''Relocation Table''' : ===
* Tableau d'offsets de 4 octets - Offsets des structures dans le DB.
=== '''Root Nodes (2)''' : ===
* Tableau de taille 8 * root0_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
* Tableau de taille 8 * root1_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
=== '''String Table''' : ===
* Suite de strings terminées par Null au nombre de root0_count + root1_count

== Structures rencontrées dans le DB ==
Note : l'arborescence est cumulative sur les transformations pour les relations parents->enfants

Les Noeuds Racine qui ont pour nom "scene_data" pointent sur un SObj :
=== '''SObj''' : (0x10 octets) ===
* 4 octets - JObjDescs_offsets_list_offset
* 4 octets - Cameras_list_offset
* 4 octets - Lights_list_offset
* 4 octets - Fog

"scene_data" == nom du nœud racine
JObjDescs_offsets_list_offset, cameras.. pointent sur une liste d'offsets terminée par 4 octets à 0x00.
lights_list_offset pointe sur des couples (4 octets - LObj_offset ; 4 octets - light_anim_pointer_offset)

=== '''JObjDesc''' : (0x10 octets) ===
* 4 octets - root_joint_offset - JObj
* 4 octets - joint_animations_offset - ?
* 4 octets - material_animations_offset - ?
* 4 octets - shape_animations_offset - ?

=== '''CObj''' : (0x38 octets) ===
* 4 octets - flags
* 4 octets - projection_type - ProjectionTypeEnum
* 2 octets - viewport_left
* 2 octets - viewport_right
* 2 octets - viewport_top
* 2 octets - viewport_bottom
* 4 octets - proj_width
* 4 octets - proj_height
* 4 octets - eye_offset - WObj
* 4 octets - target_offset - WObj
* 4 octets - roll
* 4 octets - Inconnu
* 4 octets - float - near_clip
* 4 octets - float - far_clip
* 4 octets - float - field_of_view
* 4 octets - float - aspect
Camera object. Note : pour frustrum ou ortho, la structure est différente.

* '''ProjectionTypeEnum''':
** PERSPECTIVE = 1
** FRUSTRUM = 2
** ORTHO = 3

=== '''WObj''': (0x14 octets) ===
* 4 octets - Inconnu
* 4 octets - float - v1
* 4 octets - float - v2
* 4 octets - float - v3
* 4 octets - Inconnu

eye / target

=== '''LObj''' : (0x1c octets) ===
* 4 octets - class_name
* 4 octets - next_offset
* 2 octets - flags - LObjFlagsEnum
* 2 octets - attenuation_flags - LObjAttenuationFlagsEnum
* 1 octet - color_r
* 1 octet - color_g
* 1 octet - color_b
* 1 octet - color_alpha
* 4 octets - lobj_point_offset - position
* 4 octets - infinite_data
* 4 octets - point_spot_data
light

* '''LObjFlagsEnum''' :
** LOBJ_AMBIANT = 00 00
** LOBJ_INFINITE = 00 01
** LOBJ_POINT = 00 02
** LOBJ_SPOT = 00 03
** LOBJ_DIFFUSE = 00 04
** LOBJ_SPECULAR = 00 08
** LOBJ_ALPHA = 00 10
** LOBJ_HIDDEN = 00 20
** LOBJ_RAW_PARAM = 00 40
** LOBJ_DIFF_DIRTY = 00 80
** LOBJ_SPEC_DIRTY = 01 00

* '''LObjAttenuationFlagsEnum''' :
** LOBJ_LIGHT_ATTN_NONE = 00 00
** LOBJ_LIGHT_ATTN = 00 01

=== '''LObjPoint''' : (0x14 octets) ===
* 4 octets - class_name
* 4 octets - float - x
* 4 octets - float - y
* 4 octets - float - z
* 4 octets - Inconnu

=== '''LightAnimPointer''' : (0x10 octets) ===
** 4 octets - next_offset - (LightAnimPointer)
** 4 octets - light_anim - ?
** 4 octets - position_anim - ?
** 4 octets - interst_anim - ?
Bugs dans HSDRaw - à tester

=== '''JObj''' : (0x40 octets) ===
* 4 octets - Inconnu
* 4 octets - flags
* 4 octets - child_offset (JObj)
* 4 octets - next_offset (JObj)
* 4 octets - dobj_offset (DObj)
* 4 octets [3] - float3 - rotation_xyz
* 4 octets [3] - float3 - scale_xyz
* 4 octets [3] - float3 - translation_xyz
* 4 octets - inverse_world_transform_offset (inverse world transform = Matrice de 4x3)
* 4 octets - robj_offset

Pointé par les listes dans Root Node scene_data.

* '''JObjFlagsEnum''' : (peuvent se cumuler)
** NULL = 00 00 00 00
** SKELETON = 00 00 00 01
** SKELETON_ROOT = 00 00 00 02
** ENVELOPE_MODEL = 00 00 00 04
** CLASSICAL_SCALING = 00 00 00 08
** HIDDEN = 00 00 00 10
** PTCL = 00 00 00 20
** MTX_DIRTY = 00 00 00 40
** LIGHTING = 00 00 00 80
** TEXGEN = 00 00 01 00
** BILLBOARD = 00 00 02 00
** VBILLBOARD = 00 00 04 00
** HBILLBOARD = 00 00 06 00
** RBILLBOARD = 00 00 08 00
** INSTANCE = 00 00 10 00
** PBILLBOARD = 00 00 20 00
** SPLINE = 00 00 40 00
** FLIP_IK = 00 00 80 00
** SPECULAR = 00 01 00 00
** USE_QUATERNION = 00 02 00 00
** OPA = 00 04 00 00
** XLU = 00 08 00 00
** TEXEDGE = 00 10 00 00
** JOINT1 = 00 20 00 00
** JOINT2 = 00 40 00 00
** EFFECTOR = 00 60 00 00
** USER_DEFINED_MTX = 00 80 00 00
** MTX_INDEPEND_PARENT = 01 00 00 00
** MTX_INDEPEND_SRT = 02 00 00 00
** MTX_SCALE_COMPENSATE = 04 00 00 00
** ROOT_OPA = 10 00 00 00
** ROOT_XLU = 20 00 00 00
** ROOT_TEXEDGE = 40 00 00 00

=== '''InverseWorldTransform''' : (0x30 octets) ===
* 4 octets - float - M11
* 4 octets - float - M12
* 4 octets - float - M13
* 4 octets - float - M14
* 4 octets - float - M21
* 4 octets - float - M22
* 4 octets - float - M23
* 4 octets - float - M24
* 4 octets - float - M31
* 4 octets - float - M32
* 4 octets - float - M33
* 4 octets - float - M34

=== '''DObj''' : (0x10 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - prochain DOBJ
* 4 octets - mobj_offset - material offset
* 4 octets - pobj_offset - mesh offset
Liste chaînée qui permet de récupérer l'ensemble des materials & mesh pour le JObj auquel il est lié.

=== '''MObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - render_flags - RenderFlagsEnum
* 4 octets - tobj_offset - offset de texture - peut être invalide s'il n'y a pas de texture pour le material
* 4 octets - material_offset - couleurs des materials ?
* 8 octets - PEDesc ?

Contient les textures & informations sur les couleurs des Materials.

* '''RenderFlagsEnum''' : (se cumulent)
** USER = 80 00 00 00
** CONSTANT = 00 00 00 01
** VERTEX = 00 00 00 02
** BOTH = 00 00 00 03
** DIFFUSE = 00 00 00 04
** SPECULAR = 00 00 00 08
** TEX0 = 00 00 00 10
** TEX1 = 00 00 00 20
** TEX2 = 00 00 00 40
** TEX3 = 00 00 00 80
** TEX4 = 00 00 01 00
** TEX5 = 00 00 02 00
** TEX6 = 00 00 04 00
** TEX7 = 00 00 08 00
** TOON = 00 00 10 00
** ALPHA_MAT = 00 00 20 00
** ALPHA_VTX = 00 00 40 00
** ALPHA_BOTH = 00 00 60 00
** ZOFST = 01 00 00 00
** EFFECT = 02 00 00 00
** SHADOW = 04 00 00 00
** ZMODE_ALWAYS = 08 00 00 00
** DF_ALL = 10 00 00 00
** NO_ZUPDATE = 20 00 00 00
** XLU = 40 00 00 00

=== '''TObj''' : (0x5c octets) ===
* 4 octets - ?
* 4 octets - ?
* 4 octets - tex_map_id - TexMapIdEnum
* 4 octets - gx_tex_gen_src - GXTexGenSrcEnum
* 4 octets - float - rx
* 4 octets - float - ry
* 4 octets - float - rz
* 4 octets - float - sx
* 4 octets - float - sy
* 4 octets - float - sz
* 4 octets - float - tx
* 4 octets - float - ty
* 4 octets - float - tz
* 4 octets - wrap_s - WrapEnum
* 4 octets - wrap_t - WrapEnum
* 1 octet - w_scale
* 1 octet - h_scale
* 2 octets - ?
* 1 octets - bump_map - (False = 00 ; True = 01)
* 4 bits - alpha_operation - AlphaOperationEnum
* 4 bits - color_operation - ColorOperationEnum
* 1 octet - shadow_lightmap - (False = 00 ; True = 01) (2 octets avec une Enum lightmap limite)
* 1 bit - ext_lightmap - (False = 0 ; True = 1)
* 1 bit - ambiant_lightmap - (False = 0 ; True = 1)
* 1 bit - specular_lightmap - (False = 0 ; True = 1)
* 1 bit - diffuse_lightmap (False = 0 ; True = 1)
* 4 bits - coord_type - CoordTypeEnum
* 4 octets - float - blending - utilisé quand color_operation ou alpha_operation == BLEND
* 4 octets - mag_filter - MagFilterEnum
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
Informations de Textures. Le TObj contient des informations sur les paramètres d'environnement de textures utilisés pour le rendu graphique ainsi que les offset de l'image et des données de la palette utilisés pour cette texture. Le plus important ici, c'est l'offset d'image et la palette/tlut - si l'image n'est pas indexée (RGBA, CMPR, etc.) alors la structure de description palette/tlut n'est pas utilisée.

* '''TexMapIdEnum''' :
** GX_TEXMAP0 = 00 00 00 00
** GX_TEXMAP1 = 00 00 00 01
** GX_TEXMAP2 = 00 00 00 02
** GX_TEXMAP3 = 00 00 00 03
** GX_TEXMAP4 = 00 00 00 04
** GX_TEXMAP5 = 00 00 00 05
** GX_TEXMAP6 = 00 00 00 06
** GX_TEXMAP7 = 00 00 00 07
** GX_MAX_TEXMAP = 00 00 00 08
** GX_TEXMAP_NULL = 00 00 00 09
** GX_TEXMAP_DISABLE = 00 00 00 0A

* '''GXTexGenSrcEnum''' :
** GX_TG_POS = 00 00 00 00
** GX_TG_NRM = 00 00 00 01
** GX_TG_BINRM = 00 00 00 02
** GX_TG_TANGENT = 00 00 00 03
** GX_TG_TEX0 = 00 00 00 04
** GX_TG_TEX1 = 00 00 00 05
** GX_TG_TEX2 = 00 00 00 06
** GX_TG_TEX3 = 00 00 00 07
** GX_TG_TEX4 = 00 00 00 08
** GX_TG_TEX5 = 00 00 00 09
** GX_TG_TEX6 = 00 00 00 0A
** GX_TG_TEX7 = 00 00 00 0B
** GX_TG_TEXCOORD0 = 00 00 00 0C
** GX_TG_TEXCOORD1 = 00 00 00 0D
** GX_TG_TEXCOORD2 = 00 00 00 0E
** GX_TG_TEXCOORD3 = 00 00 00 0F
** GX_TG_TEXCOORD4 = 00 00 00 10
** GX_TG_TEXCOORD5 = 00 00 00 11
** GX_TG_TEXCOORD6 = 00 00 00 12
** GX_TG_COLOR0 = 00 00 00 13
** GX_TG_COLOR1 = 00 00 00 14

* '''AlphaOperationEnum''':
** NONE = 0X
** ALPHAMASK = 1X
** BLEND = 2X
** MODULATE = 3X
** REPLACE = 4X
** PASS = 5X
** ADD = 6X
** SUB = 7X

* '''ColorOperationEnum''':
** NONE = X0
** ALPHA_MASK = X1
** RGB_MASK = X2
** BLEND = X3
** MODULATE = X4
** REPLACE = X5
** PASS = X6
** ADD = X7
** SUB = X8

* '''CoordTypeEnum''':
** UV = X0
** REFLECTION = X1
** HILIGHT = X2
** SHADOW = X3
** TOON = X4
** GRADATION = X5

* '''MagFilterEnum''':
** GX_NEAR = 00 00 00 00
** GX_LINEAR = 00 00 00 01
** GX_NEAR_MIP_NEAR = 00 00 00 02
** GX_LIN_MIP_NEAR = 00 00 00 03
** GX_NEAR_MIP_LIN = 00 00 00 04
** GX_LIN_MIP_LIN = 00 00 00 05

* '''WrapEnum''':
** CLAMP = 00 00 00 00
** REPEAT = 00 00 00 01
** MIRROR = 00 00 00 02

=== '''Material''' : (0x14 octets) ===
* 1 octets - AMB_R - (ambient)
* 1 octets - AMB_G
* 1 octets - AMB_B
* 1 octets - AMB_A
* 1 octets - DIF_R - (diffuse)
* 1 octets - DIF_G
* 1 octets - DIF_B
* 1 octets - DIF_A
* 1 octets - SPC_R - (specular)
* 1 octets - SPC_G
* 1 octets - SPC_B
* 1 octets - SPC_A
* 4 octets - float - alpha
* 4 octets - float - shininess

=== '''PObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - pobj
* 4 octets - vertex_attr_list_offset
* 2 octets - Flags - PObjFlagsEnum
* 2 octets - display_list_size - number of 0x20 (32) byte blocks occupied by display list data
* 4 octets - display_list_offset
* 4 octets - weight_list_offset - ? verifier qu'on retrouve bien le tableau d'envelope_weights à cet offset

Comme l'indique next_offset, il s'agit d'une liste de meshs à afficher pour un material donné référencé par un dobj. PObj contient les offsets de vertex attributes / display list / joint weight list ce qui suffit et permet d’interpréter et traiter les coordonnées de vertices, normals & textures.

Les attributs vertex sont les plus important - les parametres specifiés contrôlent tout : du format, de la taille des données de chaque vertex, normal et coordonnées de textures et comment ces valeurs sont dimensionnées (scaled) par rapport à la présence et la taille de chaque valeur d'index qui apparaît dans la display list information.

* '''PObjFlagsEnum''' :
** Inconnu0 = 00 01
** Inconnu1 = 00 02
** ANIM = 00 08
** SHAPE_ANIM = 10 00
** ENVELOPE = 20 00
** CULLBACK = 40 00
** CULLFRONT = 80 00

=== EnvelopeWeights : (0x? octets) ===
* 4 octets - envelope_count
* [envelope_count]:
** 4 octets - float - weight
** 4 octets - pad ?
* 4 octets - jobj_list_offset

=== not verified yet ===

* '''IMAGE_HEADER''' :
** 4 octets - image_offset - image data
** 2 octets - width
** 2 octets - height
** 4 octets - image_format

* '''PALETTE_HEADER''' : (0x10)
** 4 octets - palette_offset - palette data
** 4 octets - palette_format
** 4 octets - Inconnu
** 2 octets - color_count
** 2 octets - Inconnu

image_offset et palette_offset sont souvent partagés par plusieurs textures - savoir ça permet de retrouver toutes les informations sur les images des textures (largeur, hauteur, format), ainsi que le format et le nombre de couleurs de la palette/tlut.

Le format d'image ne détermine pas le nombre total de couleurs de la palette qu'elle utilisent. Par exemple, une image indexée sur 8 bits aurait un maximum de 256 couleurs mais seulement 136 ou 221 couleurs sont actuellement utilisées. De la sorte, la palette n'utilisera pas la taille totale qu'elle devrait utiliser.

Les images suivent la structure généralement utilisée par la GameCube :

IMAGE FORMATS :
* case 0: //i4
* case 1: //i8
* case 2: //i4a4
* case 3: //i8a8
* case 4: //r5g6b5
* case 5: //rgb5a3
* case 6: //r8g8b8a8
* case 8: //index4
* case 9: //index8
* case 0xa: //index14x2
* case 0xe: //s3tc1

Les formats indexés utilisent aussi les informations de palettes/tlut et les données peuvent apparaître en plusieurs formats :

PALETTE FORMATS :
* case 0: //ia8
* case 1: //r5g6b5
* case 2: //rgb5a3

---> "Joint Data - Accessing Geometry, Mesh, and Vertex Attributes" https://smashboards.com/threads/melee-dat-format.292603/

trad a revoir à partir de là, il faut investiguer le rendu 3D sur GameCube pour mieux comprendre

// déclaration d'un vertex et attribute information
// attr, type, cnt, data_type, flags?, file_offset
* ATTR_DATA
** 4 octets - GXAttr vtx_attr_offset - attr
** 4 octets - GXAttrType vtx_attr_type - index_type
** 4 octets - GXCompCnt comp_cnt - cnt
** 4 octets - GXCompType comp_type - data_type
** 1 octets - scale
** 1 octets - Inconnu
** 2 octets - vtx_stride
** 2 octets - data_offset

vertex_attr_offset pointe sur une liste d'attributs de vertex. Leur nombre n'est pas donné. Les données dans cette structure suivent les informations et les types conçus par l'architecture GameCube/WII et son API. La liste est terminée par une valeur spécifique de vtx_attr qui signale la fin de cette liste. Avec un accès à la doku SDK, il serait fortement conseillé de lire la section à propos des "vertex attributes and other specifications".

La valeur de vtx_attr determine le type de donnée que cet attribut désigne et peut indiquer un nombre de types natifs utilisés utilisés pour passer les données entre les interfaces logicielles et matérielles.

Les valeures possibles sont les suivantes :
* enum GXAttr (4 octets)
** GX_VA_PNMTXIDX = 0, // position/normal matrix index
** GX_VA_TEX0MTXIDX, // texture 0 matrix index
** GX_VA_TEX1MTXIDX, // texture 1 matrix index
** GX_VA_TEX2MTXIDX, // texture 2 matrix index
** GX_VA_TEX3MTXIDX, // texture 3 matrix index
** GX_VA_TEX4MTXIDX, // texture 4 matrix index
** GX_VA_TEX5MTXIDX, // texture 5 matrix index
** GX_VA_TEX6MTXIDX, // texture 6 matrix index
** GX_VA_TEX7MTXIDX, // texture 7 matrix index
** GX_VA_POS = 9, // position
** GX_VA_NRM, // normal
** GX_VA_CLR0, // color 0
** GX_VA_CLR1, // color 1
** GX_VA_TEX0, // input texture coordinate 0
** GX_VA_TEX1, // input texture coordinate 1
** GX_VA_TEX2, // input texture coordinate 2
** GX_VA_TEX3, // input texture coordinate 3
** GX_VA_TEX4, // input texture coordinate 4
** GX_VA_TEX5, // input texture coordinate 5
** GX_VA_TEX6, // input texture coordinate 6
** GX_VA_TEX7, // input texture coordinate 7

** GX_POS_MTX_ARRAY, // position matrix array pointer
** GX_NRM_MTX_ARRAY, // normal matrix array pointer
** GX_TEX_MTX_ARRAY, // texture matrix array pointer
** GX_LIGHT_ARRAY, // light parameter array pointer
** GX_VA_NBT, // normal, bi-normal, tangent
** GX_VA_MAX_ATTR, // maximum number of vertex attributes

** GX_VA_NULL = 0xff // NULL attribute (to mark end of lists)

Toutes les données nécessaires pour représenter un mesh peuvent être spécifiées et indexées d'une manière ou d'une autre. De même, GX_VA_TEX0MTXIDX, GX_VA_CLR0, et autres sont aussi possibles - les valeurs les plus fréquentes dans les données SSBM sont : GX_VA_PNMTXIDX, GX_VA_POS, GX_VA_NRM, et GX_VA_TEX0. Which is to be expected as joint matrices, vertex positions/normals, and texture coordinates respectively are probably the most basic of elements needed to display a texture mesh, whether static or animated.

When the value of vtx_attr == GX_VA_NULL (0xFF), the end of the vertex attribute array has been reached.

The vtx_attr_type values is actually associated with how the value is indexed, and can thus also determine the size of the index value within the display list data.

* 4 octets - enum GXAttrType
** GX_NONE = 0,
** GX_DIRECT,
** GX_INDEX8,
** GX_INDEX16

* Structures COLL_DATA : (données de collisions)
** 4 octets - vertex_offset (2 float par entrée correspondant à des données 2D probablement)
** 4 octets - vertex_count
** 4 octets - index_offset
** 4 octets - index_count
** 4 octets [5] - tableau inconnu
*** 2 octets - index_start
*** 2 octets - index_count
** 4 octets - Inconnu
** 4 octets - Inconnu

[[Category:Implementations]]
[[Category:Gotcha Force]]

Models

2023-10-07T13:44:29Z

Algoflash: /* Gotcha Force Models */

[[Gotcha Force | ← Gotcha Force]]

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

== Gotcha Force Models ==

Gotcha Force models work as those from the game Super Smash Bros Melee (SSBM) investigated by its [https://smashboards.com/threads/melee-dat-format.292603/ community].

A model is a file format that organizes objects and resources serialized to be used by the '''H'''al '''S'''ys'''D'''olphin ('''HSD''') library. The HSD library is used in several Capcom games. These are graphic materials structured in a hierarchical way. Some pictures present in the models seem to indicate the use of [https://learn.foundry.com/modo/901/content/help/pages/shading_lighting/shader_items/matcap.html matcap] technic. This library use Dolphin SDK functions like GX / MTX and so on.

=== Fichiers concernés ===
L'ensemble des fichiers ayant dans leur titre '''_mdl''' sont des fichiers modèles correspondant au format décrit dans cette page. On notera les fichiers [[ARZ (Gotcha Force)|.arz]] qui sont des modèles compressés. Le fichier collision.arc et les fichiers tdc00.arc à tdc09.arc sont aussi des modèles.

Les fichiers modèles se retrouvent aussi dans les pzz des borgs (plxxxx.pzz) en position 004 à 009.

=== HSDRaw ===
HSDRaw, un éditeur 3D dotnet de ce format est instable sur mon Windows (algoflash). Il est cependant prouvé qu'un edit des _mdl pour commencer à l'offset 0x100 - après le préambule - permet de visualiser le fichier sur HSDRaw et d'avoir le rendu 3D du Borg (click sur le premier dossier JOBJ - puis le JOBJ dedans et double click sur le nœud en violet). Cela devrait aussi permettre d'éditer certaines propriétés ?

== Structure générale ==
Le format des modèles se découpe en plusieurs blocks. Le préambule fait 0x100 octets au tout début du fichier. Il est souvent absent. Toutes les valeurs sont en unsigned big endian, et le pad est en Nulls bytes (\x00). Les offsets trouvés après le début du Data Block (DB) sont relatifs au début du DB. La table de relocs est un tableau d'offsets de 4 octets (relatif au DB) permettant de traduire en adressage absolu les offsets des structures lors du chargement mémoire. La table de reloc permet par exemple de délimiter les structures du fait qu'il est peu probable qu'un offset pointe au milieu d'une structure.

L'ensemble des fichiers répondant à ce format on un seul root_node de type SObj (Scene data).

=== '''Préambule''' : (0x100 octets / 0 octets) ===
* 4 octets - hsd_header_offset=0x100 (toujours)
* 4 octets - bones_flags_table_offset=0x20 (toujours) - offset de la liste des flags des armatures
* 4 octets - bones_table_offset=0xC0 (toujours) - offset de la liste des armatures
* 20 octets - Pad - (toujours)
* 4 octets [32] - Inconnu (flags des armatures ?) 1 octet par flag ?
* 32 octets - Pad - (toujours)
* 32 octets - armatures ?
* 32 octets - Pad - (toujours)
=== '''HSD Header''' - (0x20 octets) ===
* 4 octets - Taille totale du fichier
* 4 octets - Taille du Data block
* 4 octets - Nombre d'entrée dans la Table de relocs
* 4 octets - root0_count
* 4 octets - root1_count
* 12 octets - Pad - (toujours)
=== '''Data block''' : ===
* JOBJ, etc. -> Ces structures sont détaillée plus loin ci-dessous.
=== '''Relocation Table''' : ===
* Tableau d'offsets de 4 octets - Offsets des structures dans le DB.
=== '''Root Nodes (2)''' : ===
* Tableau de taille 8 * root0_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
* Tableau de taille 8 * root1_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
=== '''String Table''' : ===
* Suite de strings terminées par Null au nombre de root0_count + root1_count

== Structures rencontrées dans le DB ==
Note : l'arborescence est cumulative sur les transformations pour les relations parents->enfants

Les Noeuds Racine qui ont pour nom "scene_data" pointent sur un SObj :
=== '''SObj''' : (0x10 octets) ===
* 4 octets - JObjDescs_offsets_list_offset
* 4 octets - Cameras_list_offset
* 4 octets - Lights_list_offset
* 4 octets - Fog

"scene_data" == nom du nœud racine
JObjDescs_offsets_list_offset, cameras.. pointent sur une liste d'offsets terminée par 4 octets à 0x00.
lights_list_offset pointe sur des couples (4 octets - LObj_offset ; 4 octets - light_anim_pointer_offset)

=== '''JObjDesc''' : (0x10 octets) ===
* 4 octets - root_joint_offset - JObj
* 4 octets - joint_animations_offset - ?
* 4 octets - material_animations_offset - ?
* 4 octets - shape_animations_offset - ?

=== '''CObj''' : (0x38 octets) ===
* 4 octets - flags
* 4 octets - projection_type - ProjectionTypeEnum
* 2 octets - viewport_left
* 2 octets - viewport_right
* 2 octets - viewport_top
* 2 octets - viewport_bottom
* 4 octets - proj_width
* 4 octets - proj_height
* 4 octets - eye_offset - WObj
* 4 octets - target_offset - WObj
* 4 octets - roll
* 4 octets - Inconnu
* 4 octets - float - near_clip
* 4 octets - float - far_clip
* 4 octets - float - field_of_view
* 4 octets - float - aspect
Camera object. Note : pour frustrum ou ortho, la structure est différente.

* '''ProjectionTypeEnum''':
** PERSPECTIVE = 1
** FRUSTRUM = 2
** ORTHO = 3

=== '''WObj''': (0x14 octets) ===
* 4 octets - Inconnu
* 4 octets - float - v1
* 4 octets - float - v2
* 4 octets - float - v3
* 4 octets - Inconnu

eye / target

=== '''LObj''' : (0x1c octets) ===
* 4 octets - class_name
* 4 octets - next_offset
* 2 octets - flags - LObjFlagsEnum
* 2 octets - attenuation_flags - LObjAttenuationFlagsEnum
* 1 octet - color_r
* 1 octet - color_g
* 1 octet - color_b
* 1 octet - color_alpha
* 4 octets - lobj_point_offset - position
* 4 octets - infinite_data
* 4 octets - point_spot_data
light

* '''LObjFlagsEnum''' :
** LOBJ_AMBIANT = 00 00
** LOBJ_INFINITE = 00 01
** LOBJ_POINT = 00 02
** LOBJ_SPOT = 00 03
** LOBJ_DIFFUSE = 00 04
** LOBJ_SPECULAR = 00 08
** LOBJ_ALPHA = 00 10
** LOBJ_HIDDEN = 00 20
** LOBJ_RAW_PARAM = 00 40
** LOBJ_DIFF_DIRTY = 00 80
** LOBJ_SPEC_DIRTY = 01 00

* '''LObjAttenuationFlagsEnum''' :
** LOBJ_LIGHT_ATTN_NONE = 00 00
** LOBJ_LIGHT_ATTN = 00 01

=== '''LObjPoint''' : (0x14 octets) ===
* 4 octets - class_name
* 4 octets - float - x
* 4 octets - float - y
* 4 octets - float - z
* 4 octets - Inconnu

=== '''LightAnimPointer''' : (0x10 octets) ===
** 4 octets - next_offset - (LightAnimPointer)
** 4 octets - light_anim - ?
** 4 octets - position_anim - ?
** 4 octets - interst_anim - ?
Bugs dans HSDRaw - à tester

=== '''JObj''' : (0x40 octets) ===
* 4 octets - Inconnu
* 4 octets - flags
* 4 octets - child_offset (JObj)
* 4 octets - next_offset (JObj)
* 4 octets - dobj_offset (DObj)
* 4 octets [3] - float3 - rotation_xyz
* 4 octets [3] - float3 - scale_xyz
* 4 octets [3] - float3 - translation_xyz
* 4 octets - inverse_world_transform_offset (inverse world transform = Matrice de 4x3)
* 4 octets - robj_offset

Pointé par les listes dans Root Node scene_data.

* '''JObjFlagsEnum''' : (peuvent se cumuler)
** NULL = 00 00 00 00
** SKELETON = 00 00 00 01
** SKELETON_ROOT = 00 00 00 02
** ENVELOPE_MODEL = 00 00 00 04
** CLASSICAL_SCALING = 00 00 00 08
** HIDDEN = 00 00 00 10
** PTCL = 00 00 00 20
** MTX_DIRTY = 00 00 00 40
** LIGHTING = 00 00 00 80
** TEXGEN = 00 00 01 00
** BILLBOARD = 00 00 02 00
** VBILLBOARD = 00 00 04 00
** HBILLBOARD = 00 00 06 00
** RBILLBOARD = 00 00 08 00
** INSTANCE = 00 00 10 00
** PBILLBOARD = 00 00 20 00
** SPLINE = 00 00 40 00
** FLIP_IK = 00 00 80 00
** SPECULAR = 00 01 00 00
** USE_QUATERNION = 00 02 00 00
** OPA = 00 04 00 00
** XLU = 00 08 00 00
** TEXEDGE = 00 10 00 00
** JOINT1 = 00 20 00 00
** JOINT2 = 00 40 00 00
** EFFECTOR = 00 60 00 00
** USER_DEFINED_MTX = 00 80 00 00
** MTX_INDEPEND_PARENT = 01 00 00 00
** MTX_INDEPEND_SRT = 02 00 00 00
** MTX_SCALE_COMPENSATE = 04 00 00 00
** ROOT_OPA = 10 00 00 00
** ROOT_XLU = 20 00 00 00
** ROOT_TEXEDGE = 40 00 00 00

=== '''InverseWorldTransform''' : (0x30 octets) ===
* 4 octets - float - M11
* 4 octets - float - M12
* 4 octets - float - M13
* 4 octets - float - M14
* 4 octets - float - M21
* 4 octets - float - M22
* 4 octets - float - M23
* 4 octets - float - M24
* 4 octets - float - M31
* 4 octets - float - M32
* 4 octets - float - M33
* 4 octets - float - M34

=== '''DObj''' : (0x10 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - prochain DOBJ
* 4 octets - mobj_offset - material offset
* 4 octets - pobj_offset - mesh offset
Liste chaînée qui permet de récupérer l'ensemble des materials & mesh pour le JObj auquel il est lié.

=== '''MObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - render_flags - RenderFlagsEnum
* 4 octets - tobj_offset - offset de texture - peut être invalide s'il n'y a pas de texture pour le material
* 4 octets - material_offset - couleurs des materials ?
* 8 octets - PEDesc ?

Contient les textures & informations sur les couleurs des Materials.

* '''RenderFlagsEnum''' : (se cumulent)
** USER = 80 00 00 00
** CONSTANT = 00 00 00 01
** VERTEX = 00 00 00 02
** BOTH = 00 00 00 03
** DIFFUSE = 00 00 00 04
** SPECULAR = 00 00 00 08
** TEX0 = 00 00 00 10
** TEX1 = 00 00 00 20
** TEX2 = 00 00 00 40
** TEX3 = 00 00 00 80
** TEX4 = 00 00 01 00
** TEX5 = 00 00 02 00
** TEX6 = 00 00 04 00
** TEX7 = 00 00 08 00
** TOON = 00 00 10 00
** ALPHA_MAT = 00 00 20 00
** ALPHA_VTX = 00 00 40 00
** ALPHA_BOTH = 00 00 60 00
** ZOFST = 01 00 00 00
** EFFECT = 02 00 00 00
** SHADOW = 04 00 00 00
** ZMODE_ALWAYS = 08 00 00 00
** DF_ALL = 10 00 00 00
** NO_ZUPDATE = 20 00 00 00
** XLU = 40 00 00 00

=== '''TObj''' : (0x5c octets) ===
* 4 octets - ?
* 4 octets - ?
* 4 octets - tex_map_id - TexMapIdEnum
* 4 octets - gx_tex_gen_src - GXTexGenSrcEnum
* 4 octets - float - rx
* 4 octets - float - ry
* 4 octets - float - rz
* 4 octets - float - sx
* 4 octets - float - sy
* 4 octets - float - sz
* 4 octets - float - tx
* 4 octets - float - ty
* 4 octets - float - tz
* 4 octets - wrap_s - WrapEnum
* 4 octets - wrap_t - WrapEnum
* 1 octet - w_scale
* 1 octet - h_scale
* 2 octets - ?
* 1 octets - bump_map - (False = 00 ; True = 01)
* 4 bits - alpha_operation - AlphaOperationEnum
* 4 bits - color_operation - ColorOperationEnum
* 1 octet - shadow_lightmap - (False = 00 ; True = 01) (2 octets avec une Enum lightmap limite)
* 1 bit - ext_lightmap - (False = 0 ; True = 1)
* 1 bit - ambiant_lightmap - (False = 0 ; True = 1)
* 1 bit - specular_lightmap - (False = 0 ; True = 1)
* 1 bit - diffuse_lightmap (False = 0 ; True = 1)
* 4 bits - coord_type - CoordTypeEnum
* 4 octets - float - blending - utilisé quand color_operation ou alpha_operation == BLEND
* 4 octets - mag_filter - MagFilterEnum
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
Informations de Textures. Le TObj contient des informations sur les paramètres d'environnement de textures utilisés pour le rendu graphique ainsi que les offset de l'image et des données de la palette utilisés pour cette texture. Le plus important ici, c'est l'offset d'image et la palette/tlut - si l'image n'est pas indexée (RGBA, CMPR, etc.) alors la structure de description palette/tlut n'est pas utilisée.

* '''TexMapIdEnum''' :
** GX_TEXMAP0 = 00 00 00 00
** GX_TEXMAP1 = 00 00 00 01
** GX_TEXMAP2 = 00 00 00 02
** GX_TEXMAP3 = 00 00 00 03
** GX_TEXMAP4 = 00 00 00 04
** GX_TEXMAP5 = 00 00 00 05
** GX_TEXMAP6 = 00 00 00 06
** GX_TEXMAP7 = 00 00 00 07
** GX_MAX_TEXMAP = 00 00 00 08
** GX_TEXMAP_NULL = 00 00 00 09
** GX_TEXMAP_DISABLE = 00 00 00 0A

* '''GXTexGenSrcEnum''' :
** GX_TG_POS = 00 00 00 00
** GX_TG_NRM = 00 00 00 01
** GX_TG_BINRM = 00 00 00 02
** GX_TG_TANGENT = 00 00 00 03
** GX_TG_TEX0 = 00 00 00 04
** GX_TG_TEX1 = 00 00 00 05
** GX_TG_TEX2 = 00 00 00 06
** GX_TG_TEX3 = 00 00 00 07
** GX_TG_TEX4 = 00 00 00 08
** GX_TG_TEX5 = 00 00 00 09
** GX_TG_TEX6 = 00 00 00 0A
** GX_TG_TEX7 = 00 00 00 0B
** GX_TG_TEXCOORD0 = 00 00 00 0C
** GX_TG_TEXCOORD1 = 00 00 00 0D
** GX_TG_TEXCOORD2 = 00 00 00 0E
** GX_TG_TEXCOORD3 = 00 00 00 0F
** GX_TG_TEXCOORD4 = 00 00 00 10
** GX_TG_TEXCOORD5 = 00 00 00 11
** GX_TG_TEXCOORD6 = 00 00 00 12
** GX_TG_COLOR0 = 00 00 00 13
** GX_TG_COLOR1 = 00 00 00 14

* '''AlphaOperationEnum''':
** NONE = 0X
** ALPHAMASK = 1X
** BLEND = 2X
** MODULATE = 3X
** REPLACE = 4X
** PASS = 5X
** ADD = 6X
** SUB = 7X

* '''ColorOperationEnum''':
** NONE = X0
** ALPHA_MASK = X1
** RGB_MASK = X2
** BLEND = X3
** MODULATE = X4
** REPLACE = X5
** PASS = X6
** ADD = X7
** SUB = X8

* '''CoordTypeEnum''':
** UV = X0
** REFLECTION = X1
** HILIGHT = X2
** SHADOW = X3
** TOON = X4
** GRADATION = X5

* '''MagFilterEnum''':
** GX_NEAR = 00 00 00 00
** GX_LINEAR = 00 00 00 01
** GX_NEAR_MIP_NEAR = 00 00 00 02
** GX_LIN_MIP_NEAR = 00 00 00 03
** GX_NEAR_MIP_LIN = 00 00 00 04
** GX_LIN_MIP_LIN = 00 00 00 05

* '''WrapEnum''':
** CLAMP = 00 00 00 00
** REPEAT = 00 00 00 01
** MIRROR = 00 00 00 02

=== '''Material''' : (0x14 octets) ===
* 1 octets - AMB_R - (ambient)
* 1 octets - AMB_G
* 1 octets - AMB_B
* 1 octets - AMB_A
* 1 octets - DIF_R - (diffuse)
* 1 octets - DIF_G
* 1 octets - DIF_B
* 1 octets - DIF_A
* 1 octets - SPC_R - (specular)
* 1 octets - SPC_G
* 1 octets - SPC_B
* 1 octets - SPC_A
* 4 octets - float - alpha
* 4 octets - float - shininess

=== '''PObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - pobj
* 4 octets - vertex_attr_list_offset
* 2 octets - Flags - PObjFlagsEnum
* 2 octets - display_list_size - number of 0x20 (32) byte blocks occupied by display list data
* 4 octets - display_list_offset
* 4 octets - weight_list_offset - ? verifier qu'on retrouve bien le tableau d'envelope_weights à cet offset

Comme l'indique next_offset, il s'agit d'une liste de meshs à afficher pour un material donné référencé par un dobj. PObj contient les offsets de vertex attributes / display list / joint weight list ce qui suffit et permet d’interpréter et traiter les coordonnées de vertices, normals & textures.

Les attributs vertex sont les plus important - les parametres specifiés contrôlent tout : du format, de la taille des données de chaque vertex, normal et coordonnées de textures et comment ces valeurs sont dimensionnées (scaled) par rapport à la présence et la taille de chaque valeur d'index qui apparaît dans la display list information.

* '''PObjFlagsEnum''' :
** Inconnu0 = 00 01
** Inconnu1 = 00 02
** ANIM = 00 08
** SHAPE_ANIM = 10 00
** ENVELOPE = 20 00
** CULLBACK = 40 00
** CULLFRONT = 80 00

=== EnvelopeWeights : (0x? octets) ===
* 4 octets - envelope_count
* [envelope_count]:
** 4 octets - float - weight
** 4 octets - pad ?
* 4 octets - jobj_list_offset

=== not verified yet ===

* '''IMAGE_HEADER''' :
** 4 octets - image_offset - image data
** 2 octets - width
** 2 octets - height
** 4 octets - image_format

* '''PALETTE_HEADER''' : (0x10)
** 4 octets - palette_offset - palette data
** 4 octets - palette_format
** 4 octets - Inconnu
** 2 octets - color_count
** 2 octets - Inconnu

image_offset et palette_offset sont souvent partagés par plusieurs textures - savoir ça permet de retrouver toutes les informations sur les images des textures (largeur, hauteur, format), ainsi que le format et le nombre de couleurs de la palette/tlut.

Le format d'image ne détermine pas le nombre total de couleurs de la palette qu'elle utilisent. Par exemple, une image indexée sur 8 bits aurait un maximum de 256 couleurs mais seulement 136 ou 221 couleurs sont actuellement utilisées. De la sorte, la palette n'utilisera pas la taille totale qu'elle devrait utiliser.

Les images suivent la structure généralement utilisée par la GameCube :

IMAGE FORMATS :
* case 0: //i4
* case 1: //i8
* case 2: //i4a4
* case 3: //i8a8
* case 4: //r5g6b5
* case 5: //rgb5a3
* case 6: //r8g8b8a8
* case 8: //index4
* case 9: //index8
* case 0xa: //index14x2
* case 0xe: //s3tc1

Les formats indexés utilisent aussi les informations de palettes/tlut et les données peuvent apparaître en plusieurs formats :

PALETTE FORMATS :
* case 0: //ia8
* case 1: //r5g6b5
* case 2: //rgb5a3

---> "Joint Data - Accessing Geometry, Mesh, and Vertex Attributes" https://smashboards.com/threads/melee-dat-format.292603/

trad a revoir à partir de là, il faut investiguer le rendu 3D sur GameCube pour mieux comprendre

// déclaration d'un vertex et attribute information
// attr, type, cnt, data_type, flags?, file_offset
* ATTR_DATA
** 4 octets - GXAttr vtx_attr_offset - attr
** 4 octets - GXAttrType vtx_attr_type - index_type
** 4 octets - GXCompCnt comp_cnt - cnt
** 4 octets - GXCompType comp_type - data_type
** 1 octets - scale
** 1 octets - Inconnu
** 2 octets - vtx_stride
** 2 octets - data_offset

vertex_attr_offset pointe sur une liste d'attributs de vertex. Leur nombre n'est pas donné. Les données dans cette structure suivent les informations et les types conçus par l'architecture GameCube/WII et son API. La liste est terminée par une valeur spécifique de vtx_attr qui signale la fin de cette liste. Avec un accès à la doku SDK, il serait fortement conseillé de lire la section à propos des "vertex attributes and other specifications".

La valeur de vtx_attr determine le type de donnée que cet attribut désigne et peut indiquer un nombre de types natifs utilisés utilisés pour passer les données entre les interfaces logicielles et matérielles.

Les valeures possibles sont les suivantes :
* enum GXAttr (4 octets)
** GX_VA_PNMTXIDX = 0, // position/normal matrix index
** GX_VA_TEX0MTXIDX, // texture 0 matrix index
** GX_VA_TEX1MTXIDX, // texture 1 matrix index
** GX_VA_TEX2MTXIDX, // texture 2 matrix index
** GX_VA_TEX3MTXIDX, // texture 3 matrix index
** GX_VA_TEX4MTXIDX, // texture 4 matrix index
** GX_VA_TEX5MTXIDX, // texture 5 matrix index
** GX_VA_TEX6MTXIDX, // texture 6 matrix index
** GX_VA_TEX7MTXIDX, // texture 7 matrix index
** GX_VA_POS = 9, // position
** GX_VA_NRM, // normal
** GX_VA_CLR0, // color 0
** GX_VA_CLR1, // color 1
** GX_VA_TEX0, // input texture coordinate 0
** GX_VA_TEX1, // input texture coordinate 1
** GX_VA_TEX2, // input texture coordinate 2
** GX_VA_TEX3, // input texture coordinate 3
** GX_VA_TEX4, // input texture coordinate 4
** GX_VA_TEX5, // input texture coordinate 5
** GX_VA_TEX6, // input texture coordinate 6
** GX_VA_TEX7, // input texture coordinate 7

** GX_POS_MTX_ARRAY, // position matrix array pointer
** GX_NRM_MTX_ARRAY, // normal matrix array pointer
** GX_TEX_MTX_ARRAY, // texture matrix array pointer
** GX_LIGHT_ARRAY, // light parameter array pointer
** GX_VA_NBT, // normal, bi-normal, tangent
** GX_VA_MAX_ATTR, // maximum number of vertex attributes

** GX_VA_NULL = 0xff // NULL attribute (to mark end of lists)

Toutes les données nécessaires pour représenter un mesh peuvent être spécifiées et indexées d'une manière ou d'une autre. De même, GX_VA_TEX0MTXIDX, GX_VA_CLR0, et autres sont aussi possibles - les valeurs les plus fréquentes dans les données SSBM sont : GX_VA_PNMTXIDX, GX_VA_POS, GX_VA_NRM, et GX_VA_TEX0. Which is to be expected as joint matrices, vertex positions/normals, and texture coordinates respectively are probably the most basic of elements needed to display a texture mesh, whether static or animated.

When the value of vtx_attr == GX_VA_NULL (0xFF), the end of the vertex attribute array has been reached.

The vtx_attr_type values is actually associated with how the value is indexed, and can thus also determine the size of the index value within the display list data.

* 4 octets - enum GXAttrType
** GX_NONE = 0,
** GX_DIRECT,
** GX_INDEX8,
** GX_INDEX16

* Structures COLL_DATA : (données de collisions)
** 4 octets - vertex_offset (2 float par entrée correspondant à des données 2D probablement)
** 4 octets - vertex_count
** 4 octets - index_offset
** 4 octets - index_count
** 4 octets [5] - tableau inconnu
*** 2 octets - index_start
*** 2 octets - index_count
** 4 octets - Inconnu
** 4 octets - Inconnu

[[Category:Implementations]]
[[Category:Gotcha Force]]

Models

2023-10-07T13:39:17Z

Algoflash: /* Gotcha Force Models */

[[Gotcha Force | ← Gotcha Force]]

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

== Gotcha Force Models ==

Gotcha Force models work as those from the game Super Smash Bros Melee (SSBM) investigated by its [https://smashboards.com/threads/melee-dat-format.292603/ community].

A model is a file format that organizes objects and resources serialized to be used by the '''H'''al '''S'''ys'''D'''olphin ('''HSD''') library. The HSD library is used in several Capcom games. These are graphic materials structured in a hierarchical way. Some pictures present in the models seems to indicate the use of [https://learn.foundry.com/modo/901/content/help/pages/shading_lighting/shader_items/matcap.html matcap] technic.
Par ailleurs, la librairie prendrait ses sources sur le SDK Dolphin, tel que GX ou encore MTX.

=== Fichiers concernés ===
L'ensemble des fichiers ayant dans leur titre '''_mdl''' sont des fichiers modèles correspondant au format décrit dans cette page. On notera les fichiers [[ARZ (Gotcha Force)|.arz]] qui sont des modèles compressés. Le fichier collision.arc et les fichiers tdc00.arc à tdc09.arc sont aussi des modèles.

Les fichiers modèles se retrouvent aussi dans les pzz des borgs (plxxxx.pzz) en position 004 à 009.

=== HSDRaw ===
HSDRaw, un éditeur 3D dotnet de ce format est instable sur mon Windows (algoflash). Il est cependant prouvé qu'un edit des _mdl pour commencer à l'offset 0x100 - après le préambule - permet de visualiser le fichier sur HSDRaw et d'avoir le rendu 3D du Borg (click sur le premier dossier JOBJ - puis le JOBJ dedans et double click sur le nœud en violet). Cela devrait aussi permettre d'éditer certaines propriétés ?

== Structure générale ==
Le format des modèles se découpe en plusieurs blocks. Le préambule fait 0x100 octets au tout début du fichier. Il est souvent absent. Toutes les valeurs sont en unsigned big endian, et le pad est en Nulls bytes (\x00). Les offsets trouvés après le début du Data Block (DB) sont relatifs au début du DB. La table de relocs est un tableau d'offsets de 4 octets (relatif au DB) permettant de traduire en adressage absolu les offsets des structures lors du chargement mémoire. La table de reloc permet par exemple de délimiter les structures du fait qu'il est peu probable qu'un offset pointe au milieu d'une structure.

L'ensemble des fichiers répondant à ce format on un seul root_node de type SObj (Scene data).

=== '''Préambule''' : (0x100 octets / 0 octets) ===
* 4 octets - hsd_header_offset=0x100 (toujours)
* 4 octets - bones_flags_table_offset=0x20 (toujours) - offset de la liste des flags des armatures
* 4 octets - bones_table_offset=0xC0 (toujours) - offset de la liste des armatures
* 20 octets - Pad - (toujours)
* 4 octets [32] - Inconnu (flags des armatures ?) 1 octet par flag ?
* 32 octets - Pad - (toujours)
* 32 octets - armatures ?
* 32 octets - Pad - (toujours)
=== '''HSD Header''' - (0x20 octets) ===
* 4 octets - Taille totale du fichier
* 4 octets - Taille du Data block
* 4 octets - Nombre d'entrée dans la Table de relocs
* 4 octets - root0_count
* 4 octets - root1_count
* 12 octets - Pad - (toujours)
=== '''Data block''' : ===
* JOBJ, etc. -> Ces structures sont détaillée plus loin ci-dessous.
=== '''Relocation Table''' : ===
* Tableau d'offsets de 4 octets - Offsets des structures dans le DB.
=== '''Root Nodes (2)''' : ===
* Tableau de taille 8 * root0_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
* Tableau de taille 8 * root1_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
=== '''String Table''' : ===
* Suite de strings terminées par Null au nombre de root0_count + root1_count

== Structures rencontrées dans le DB ==
Note : l'arborescence est cumulative sur les transformations pour les relations parents->enfants

Les Noeuds Racine qui ont pour nom "scene_data" pointent sur un SObj :
=== '''SObj''' : (0x10 octets) ===
* 4 octets - JObjDescs_offsets_list_offset
* 4 octets - Cameras_list_offset
* 4 octets - Lights_list_offset
* 4 octets - Fog

"scene_data" == nom du nœud racine
JObjDescs_offsets_list_offset, cameras.. pointent sur une liste d'offsets terminée par 4 octets à 0x00.
lights_list_offset pointe sur des couples (4 octets - LObj_offset ; 4 octets - light_anim_pointer_offset)

=== '''JObjDesc''' : (0x10 octets) ===
* 4 octets - root_joint_offset - JObj
* 4 octets - joint_animations_offset - ?
* 4 octets - material_animations_offset - ?
* 4 octets - shape_animations_offset - ?

=== '''CObj''' : (0x38 octets) ===
* 4 octets - flags
* 4 octets - projection_type - ProjectionTypeEnum
* 2 octets - viewport_left
* 2 octets - viewport_right
* 2 octets - viewport_top
* 2 octets - viewport_bottom
* 4 octets - proj_width
* 4 octets - proj_height
* 4 octets - eye_offset - WObj
* 4 octets - target_offset - WObj
* 4 octets - roll
* 4 octets - Inconnu
* 4 octets - float - near_clip
* 4 octets - float - far_clip
* 4 octets - float - field_of_view
* 4 octets - float - aspect
Camera object. Note : pour frustrum ou ortho, la structure est différente.

* '''ProjectionTypeEnum''':
** PERSPECTIVE = 1
** FRUSTRUM = 2
** ORTHO = 3

=== '''WObj''': (0x14 octets) ===
* 4 octets - Inconnu
* 4 octets - float - v1
* 4 octets - float - v2
* 4 octets - float - v3
* 4 octets - Inconnu

eye / target

=== '''LObj''' : (0x1c octets) ===
* 4 octets - class_name
* 4 octets - next_offset
* 2 octets - flags - LObjFlagsEnum
* 2 octets - attenuation_flags - LObjAttenuationFlagsEnum
* 1 octet - color_r
* 1 octet - color_g
* 1 octet - color_b
* 1 octet - color_alpha
* 4 octets - lobj_point_offset - position
* 4 octets - infinite_data
* 4 octets - point_spot_data
light

* '''LObjFlagsEnum''' :
** LOBJ_AMBIANT = 00 00
** LOBJ_INFINITE = 00 01
** LOBJ_POINT = 00 02
** LOBJ_SPOT = 00 03
** LOBJ_DIFFUSE = 00 04
** LOBJ_SPECULAR = 00 08
** LOBJ_ALPHA = 00 10
** LOBJ_HIDDEN = 00 20
** LOBJ_RAW_PARAM = 00 40
** LOBJ_DIFF_DIRTY = 00 80
** LOBJ_SPEC_DIRTY = 01 00

* '''LObjAttenuationFlagsEnum''' :
** LOBJ_LIGHT_ATTN_NONE = 00 00
** LOBJ_LIGHT_ATTN = 00 01

=== '''LObjPoint''' : (0x14 octets) ===
* 4 octets - class_name
* 4 octets - float - x
* 4 octets - float - y
* 4 octets - float - z
* 4 octets - Inconnu

=== '''LightAnimPointer''' : (0x10 octets) ===
** 4 octets - next_offset - (LightAnimPointer)
** 4 octets - light_anim - ?
** 4 octets - position_anim - ?
** 4 octets - interst_anim - ?
Bugs dans HSDRaw - à tester

=== '''JObj''' : (0x40 octets) ===
* 4 octets - Inconnu
* 4 octets - flags
* 4 octets - child_offset (JObj)
* 4 octets - next_offset (JObj)
* 4 octets - dobj_offset (DObj)
* 4 octets [3] - float3 - rotation_xyz
* 4 octets [3] - float3 - scale_xyz
* 4 octets [3] - float3 - translation_xyz
* 4 octets - inverse_world_transform_offset (inverse world transform = Matrice de 4x3)
* 4 octets - robj_offset

Pointé par les listes dans Root Node scene_data.

* '''JObjFlagsEnum''' : (peuvent se cumuler)
** NULL = 00 00 00 00
** SKELETON = 00 00 00 01
** SKELETON_ROOT = 00 00 00 02
** ENVELOPE_MODEL = 00 00 00 04
** CLASSICAL_SCALING = 00 00 00 08
** HIDDEN = 00 00 00 10
** PTCL = 00 00 00 20
** MTX_DIRTY = 00 00 00 40
** LIGHTING = 00 00 00 80
** TEXGEN = 00 00 01 00
** BILLBOARD = 00 00 02 00
** VBILLBOARD = 00 00 04 00
** HBILLBOARD = 00 00 06 00
** RBILLBOARD = 00 00 08 00
** INSTANCE = 00 00 10 00
** PBILLBOARD = 00 00 20 00
** SPLINE = 00 00 40 00
** FLIP_IK = 00 00 80 00
** SPECULAR = 00 01 00 00
** USE_QUATERNION = 00 02 00 00
** OPA = 00 04 00 00
** XLU = 00 08 00 00
** TEXEDGE = 00 10 00 00
** JOINT1 = 00 20 00 00
** JOINT2 = 00 40 00 00
** EFFECTOR = 00 60 00 00
** USER_DEFINED_MTX = 00 80 00 00
** MTX_INDEPEND_PARENT = 01 00 00 00
** MTX_INDEPEND_SRT = 02 00 00 00
** MTX_SCALE_COMPENSATE = 04 00 00 00
** ROOT_OPA = 10 00 00 00
** ROOT_XLU = 20 00 00 00
** ROOT_TEXEDGE = 40 00 00 00

=== '''InverseWorldTransform''' : (0x30 octets) ===
* 4 octets - float - M11
* 4 octets - float - M12
* 4 octets - float - M13
* 4 octets - float - M14
* 4 octets - float - M21
* 4 octets - float - M22
* 4 octets - float - M23
* 4 octets - float - M24
* 4 octets - float - M31
* 4 octets - float - M32
* 4 octets - float - M33
* 4 octets - float - M34

=== '''DObj''' : (0x10 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - prochain DOBJ
* 4 octets - mobj_offset - material offset
* 4 octets - pobj_offset - mesh offset
Liste chaînée qui permet de récupérer l'ensemble des materials & mesh pour le JObj auquel il est lié.

=== '''MObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - render_flags - RenderFlagsEnum
* 4 octets - tobj_offset - offset de texture - peut être invalide s'il n'y a pas de texture pour le material
* 4 octets - material_offset - couleurs des materials ?
* 8 octets - PEDesc ?

Contient les textures & informations sur les couleurs des Materials.

* '''RenderFlagsEnum''' : (se cumulent)
** USER = 80 00 00 00
** CONSTANT = 00 00 00 01
** VERTEX = 00 00 00 02
** BOTH = 00 00 00 03
** DIFFUSE = 00 00 00 04
** SPECULAR = 00 00 00 08
** TEX0 = 00 00 00 10
** TEX1 = 00 00 00 20
** TEX2 = 00 00 00 40
** TEX3 = 00 00 00 80
** TEX4 = 00 00 01 00
** TEX5 = 00 00 02 00
** TEX6 = 00 00 04 00
** TEX7 = 00 00 08 00
** TOON = 00 00 10 00
** ALPHA_MAT = 00 00 20 00
** ALPHA_VTX = 00 00 40 00
** ALPHA_BOTH = 00 00 60 00
** ZOFST = 01 00 00 00
** EFFECT = 02 00 00 00
** SHADOW = 04 00 00 00
** ZMODE_ALWAYS = 08 00 00 00
** DF_ALL = 10 00 00 00
** NO_ZUPDATE = 20 00 00 00
** XLU = 40 00 00 00

=== '''TObj''' : (0x5c octets) ===
* 4 octets - ?
* 4 octets - ?
* 4 octets - tex_map_id - TexMapIdEnum
* 4 octets - gx_tex_gen_src - GXTexGenSrcEnum
* 4 octets - float - rx
* 4 octets - float - ry
* 4 octets - float - rz
* 4 octets - float - sx
* 4 octets - float - sy
* 4 octets - float - sz
* 4 octets - float - tx
* 4 octets - float - ty
* 4 octets - float - tz
* 4 octets - wrap_s - WrapEnum
* 4 octets - wrap_t - WrapEnum
* 1 octet - w_scale
* 1 octet - h_scale
* 2 octets - ?
* 1 octets - bump_map - (False = 00 ; True = 01)
* 4 bits - alpha_operation - AlphaOperationEnum
* 4 bits - color_operation - ColorOperationEnum
* 1 octet - shadow_lightmap - (False = 00 ; True = 01) (2 octets avec une Enum lightmap limite)
* 1 bit - ext_lightmap - (False = 0 ; True = 1)
* 1 bit - ambiant_lightmap - (False = 0 ; True = 1)
* 1 bit - specular_lightmap - (False = 0 ; True = 1)
* 1 bit - diffuse_lightmap (False = 0 ; True = 1)
* 4 bits - coord_type - CoordTypeEnum
* 4 octets - float - blending - utilisé quand color_operation ou alpha_operation == BLEND
* 4 octets - mag_filter - MagFilterEnum
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
Informations de Textures. Le TObj contient des informations sur les paramètres d'environnement de textures utilisés pour le rendu graphique ainsi que les offset de l'image et des données de la palette utilisés pour cette texture. Le plus important ici, c'est l'offset d'image et la palette/tlut - si l'image n'est pas indexée (RGBA, CMPR, etc.) alors la structure de description palette/tlut n'est pas utilisée.

* '''TexMapIdEnum''' :
** GX_TEXMAP0 = 00 00 00 00
** GX_TEXMAP1 = 00 00 00 01
** GX_TEXMAP2 = 00 00 00 02
** GX_TEXMAP3 = 00 00 00 03
** GX_TEXMAP4 = 00 00 00 04
** GX_TEXMAP5 = 00 00 00 05
** GX_TEXMAP6 = 00 00 00 06
** GX_TEXMAP7 = 00 00 00 07
** GX_MAX_TEXMAP = 00 00 00 08
** GX_TEXMAP_NULL = 00 00 00 09
** GX_TEXMAP_DISABLE = 00 00 00 0A

* '''GXTexGenSrcEnum''' :
** GX_TG_POS = 00 00 00 00
** GX_TG_NRM = 00 00 00 01
** GX_TG_BINRM = 00 00 00 02
** GX_TG_TANGENT = 00 00 00 03
** GX_TG_TEX0 = 00 00 00 04
** GX_TG_TEX1 = 00 00 00 05
** GX_TG_TEX2 = 00 00 00 06
** GX_TG_TEX3 = 00 00 00 07
** GX_TG_TEX4 = 00 00 00 08
** GX_TG_TEX5 = 00 00 00 09
** GX_TG_TEX6 = 00 00 00 0A
** GX_TG_TEX7 = 00 00 00 0B
** GX_TG_TEXCOORD0 = 00 00 00 0C
** GX_TG_TEXCOORD1 = 00 00 00 0D
** GX_TG_TEXCOORD2 = 00 00 00 0E
** GX_TG_TEXCOORD3 = 00 00 00 0F
** GX_TG_TEXCOORD4 = 00 00 00 10
** GX_TG_TEXCOORD5 = 00 00 00 11
** GX_TG_TEXCOORD6 = 00 00 00 12
** GX_TG_COLOR0 = 00 00 00 13
** GX_TG_COLOR1 = 00 00 00 14

* '''AlphaOperationEnum''':
** NONE = 0X
** ALPHAMASK = 1X
** BLEND = 2X
** MODULATE = 3X
** REPLACE = 4X
** PASS = 5X
** ADD = 6X
** SUB = 7X

* '''ColorOperationEnum''':
** NONE = X0
** ALPHA_MASK = X1
** RGB_MASK = X2
** BLEND = X3
** MODULATE = X4
** REPLACE = X5
** PASS = X6
** ADD = X7
** SUB = X8

* '''CoordTypeEnum''':
** UV = X0
** REFLECTION = X1
** HILIGHT = X2
** SHADOW = X3
** TOON = X4
** GRADATION = X5

* '''MagFilterEnum''':
** GX_NEAR = 00 00 00 00
** GX_LINEAR = 00 00 00 01
** GX_NEAR_MIP_NEAR = 00 00 00 02
** GX_LIN_MIP_NEAR = 00 00 00 03
** GX_NEAR_MIP_LIN = 00 00 00 04
** GX_LIN_MIP_LIN = 00 00 00 05

* '''WrapEnum''':
** CLAMP = 00 00 00 00
** REPEAT = 00 00 00 01
** MIRROR = 00 00 00 02

=== '''Material''' : (0x14 octets) ===
* 1 octets - AMB_R - (ambient)
* 1 octets - AMB_G
* 1 octets - AMB_B
* 1 octets - AMB_A
* 1 octets - DIF_R - (diffuse)
* 1 octets - DIF_G
* 1 octets - DIF_B
* 1 octets - DIF_A
* 1 octets - SPC_R - (specular)
* 1 octets - SPC_G
* 1 octets - SPC_B
* 1 octets - SPC_A
* 4 octets - float - alpha
* 4 octets - float - shininess

=== '''PObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - pobj
* 4 octets - vertex_attr_list_offset
* 2 octets - Flags - PObjFlagsEnum
* 2 octets - display_list_size - number of 0x20 (32) byte blocks occupied by display list data
* 4 octets - display_list_offset
* 4 octets - weight_list_offset - ? verifier qu'on retrouve bien le tableau d'envelope_weights à cet offset

Comme l'indique next_offset, il s'agit d'une liste de meshs à afficher pour un material donné référencé par un dobj. PObj contient les offsets de vertex attributes / display list / joint weight list ce qui suffit et permet d’interpréter et traiter les coordonnées de vertices, normals & textures.

Les attributs vertex sont les plus important - les parametres specifiés contrôlent tout : du format, de la taille des données de chaque vertex, normal et coordonnées de textures et comment ces valeurs sont dimensionnées (scaled) par rapport à la présence et la taille de chaque valeur d'index qui apparaît dans la display list information.

* '''PObjFlagsEnum''' :
** Inconnu0 = 00 01
** Inconnu1 = 00 02
** ANIM = 00 08
** SHAPE_ANIM = 10 00
** ENVELOPE = 20 00
** CULLBACK = 40 00
** CULLFRONT = 80 00

=== EnvelopeWeights : (0x? octets) ===
* 4 octets - envelope_count
* [envelope_count]:
** 4 octets - float - weight
** 4 octets - pad ?
* 4 octets - jobj_list_offset

=== not verified yet ===

* '''IMAGE_HEADER''' :
** 4 octets - image_offset - image data
** 2 octets - width
** 2 octets - height
** 4 octets - image_format

* '''PALETTE_HEADER''' : (0x10)
** 4 octets - palette_offset - palette data
** 4 octets - palette_format
** 4 octets - Inconnu
** 2 octets - color_count
** 2 octets - Inconnu

image_offset et palette_offset sont souvent partagés par plusieurs textures - savoir ça permet de retrouver toutes les informations sur les images des textures (largeur, hauteur, format), ainsi que le format et le nombre de couleurs de la palette/tlut.

Le format d'image ne détermine pas le nombre total de couleurs de la palette qu'elle utilisent. Par exemple, une image indexée sur 8 bits aurait un maximum de 256 couleurs mais seulement 136 ou 221 couleurs sont actuellement utilisées. De la sorte, la palette n'utilisera pas la taille totale qu'elle devrait utiliser.

Les images suivent la structure généralement utilisée par la GameCube :

IMAGE FORMATS :
* case 0: //i4
* case 1: //i8
* case 2: //i4a4
* case 3: //i8a8
* case 4: //r5g6b5
* case 5: //rgb5a3
* case 6: //r8g8b8a8
* case 8: //index4
* case 9: //index8
* case 0xa: //index14x2
* case 0xe: //s3tc1

Les formats indexés utilisent aussi les informations de palettes/tlut et les données peuvent apparaître en plusieurs formats :

PALETTE FORMATS :
* case 0: //ia8
* case 1: //r5g6b5
* case 2: //rgb5a3

---> "Joint Data - Accessing Geometry, Mesh, and Vertex Attributes" https://smashboards.com/threads/melee-dat-format.292603/

trad a revoir à partir de là, il faut investiguer le rendu 3D sur GameCube pour mieux comprendre

// déclaration d'un vertex et attribute information
// attr, type, cnt, data_type, flags?, file_offset
* ATTR_DATA
** 4 octets - GXAttr vtx_attr_offset - attr
** 4 octets - GXAttrType vtx_attr_type - index_type
** 4 octets - GXCompCnt comp_cnt - cnt
** 4 octets - GXCompType comp_type - data_type
** 1 octets - scale
** 1 octets - Inconnu
** 2 octets - vtx_stride
** 2 octets - data_offset

vertex_attr_offset pointe sur une liste d'attributs de vertex. Leur nombre n'est pas donné. Les données dans cette structure suivent les informations et les types conçus par l'architecture GameCube/WII et son API. La liste est terminée par une valeur spécifique de vtx_attr qui signale la fin de cette liste. Avec un accès à la doku SDK, il serait fortement conseillé de lire la section à propos des "vertex attributes and other specifications".

La valeur de vtx_attr determine le type de donnée que cet attribut désigne et peut indiquer un nombre de types natifs utilisés utilisés pour passer les données entre les interfaces logicielles et matérielles.

Les valeures possibles sont les suivantes :
* enum GXAttr (4 octets)
** GX_VA_PNMTXIDX = 0, // position/normal matrix index
** GX_VA_TEX0MTXIDX, // texture 0 matrix index
** GX_VA_TEX1MTXIDX, // texture 1 matrix index
** GX_VA_TEX2MTXIDX, // texture 2 matrix index
** GX_VA_TEX3MTXIDX, // texture 3 matrix index
** GX_VA_TEX4MTXIDX, // texture 4 matrix index
** GX_VA_TEX5MTXIDX, // texture 5 matrix index
** GX_VA_TEX6MTXIDX, // texture 6 matrix index
** GX_VA_TEX7MTXIDX, // texture 7 matrix index
** GX_VA_POS = 9, // position
** GX_VA_NRM, // normal
** GX_VA_CLR0, // color 0
** GX_VA_CLR1, // color 1
** GX_VA_TEX0, // input texture coordinate 0
** GX_VA_TEX1, // input texture coordinate 1
** GX_VA_TEX2, // input texture coordinate 2
** GX_VA_TEX3, // input texture coordinate 3
** GX_VA_TEX4, // input texture coordinate 4
** GX_VA_TEX5, // input texture coordinate 5
** GX_VA_TEX6, // input texture coordinate 6
** GX_VA_TEX7, // input texture coordinate 7

** GX_POS_MTX_ARRAY, // position matrix array pointer
** GX_NRM_MTX_ARRAY, // normal matrix array pointer
** GX_TEX_MTX_ARRAY, // texture matrix array pointer
** GX_LIGHT_ARRAY, // light parameter array pointer
** GX_VA_NBT, // normal, bi-normal, tangent
** GX_VA_MAX_ATTR, // maximum number of vertex attributes

** GX_VA_NULL = 0xff // NULL attribute (to mark end of lists)

Toutes les données nécessaires pour représenter un mesh peuvent être spécifiées et indexées d'une manière ou d'une autre. De même, GX_VA_TEX0MTXIDX, GX_VA_CLR0, et autres sont aussi possibles - les valeurs les plus fréquentes dans les données SSBM sont : GX_VA_PNMTXIDX, GX_VA_POS, GX_VA_NRM, et GX_VA_TEX0. Which is to be expected as joint matrices, vertex positions/normals, and texture coordinates respectively are probably the most basic of elements needed to display a texture mesh, whether static or animated.

When the value of vtx_attr == GX_VA_NULL (0xFF), the end of the vertex attribute array has been reached.

The vtx_attr_type values is actually associated with how the value is indexed, and can thus also determine the size of the index value within the display list data.

* 4 octets - enum GXAttrType
** GX_NONE = 0,
** GX_DIRECT,
** GX_INDEX8,
** GX_INDEX16

* Structures COLL_DATA : (données de collisions)
** 4 octets - vertex_offset (2 float par entrée correspondant à des données 2D probablement)
** 4 octets - vertex_count
** 4 octets - index_offset
** 4 octets - index_count
** 4 octets [5] - tableau inconnu
*** 2 octets - index_start
*** 2 octets - index_count
** 4 octets - Inconnu
** 4 octets - Inconnu

[[Category:Implementations]]
[[Category:Gotcha Force]]

Models

2023-10-07T13:36:26Z

Algoflash: /* Gotcha Force Models */

[[Gotcha Force | ← Gotcha Force]]

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

== Gotcha Force Models ==

Gotcha Force models work as those from the game Super Smash Bros Melee (SSBM) investigated by its [https://smashboards.com/threads/melee-dat-format.292603/ community].

A model is a file format that organizes objects and resources serialized to be used by the '''H'''al '''S'''ys'''D'''olphin ('''HSD''') library. The HSD library is used in several Capcom games. These are graphic materials structured in a hierarchical way.

Ce sont des ressources graphiques structurées de manière hiérarchique. La présence de certaines images dans les modèles montrent à priori l'utilisation de la technique [https://learn.foundry.com/modo/901/content/help/pages/shading_lighting/shader_items/matcap.html matcap].
Par ailleurs, la librairie prendrait ses sources sur le SDK Dolphin, tel que GX ou encore MTX.

=== Fichiers concernés ===
L'ensemble des fichiers ayant dans leur titre '''_mdl''' sont des fichiers modèles correspondant au format décrit dans cette page. On notera les fichiers [[ARZ (Gotcha Force)|.arz]] qui sont des modèles compressés. Le fichier collision.arc et les fichiers tdc00.arc à tdc09.arc sont aussi des modèles.

Les fichiers modèles se retrouvent aussi dans les pzz des borgs (plxxxx.pzz) en position 004 à 009.

=== HSDRaw ===
HSDRaw, un éditeur 3D dotnet de ce format est instable sur mon Windows (algoflash). Il est cependant prouvé qu'un edit des _mdl pour commencer à l'offset 0x100 - après le préambule - permet de visualiser le fichier sur HSDRaw et d'avoir le rendu 3D du Borg (click sur le premier dossier JOBJ - puis le JOBJ dedans et double click sur le nœud en violet). Cela devrait aussi permettre d'éditer certaines propriétés ?

== Structure générale ==
Le format des modèles se découpe en plusieurs blocks. Le préambule fait 0x100 octets au tout début du fichier. Il est souvent absent. Toutes les valeurs sont en unsigned big endian, et le pad est en Nulls bytes (\x00). Les offsets trouvés après le début du Data Block (DB) sont relatifs au début du DB. La table de relocs est un tableau d'offsets de 4 octets (relatif au DB) permettant de traduire en adressage absolu les offsets des structures lors du chargement mémoire. La table de reloc permet par exemple de délimiter les structures du fait qu'il est peu probable qu'un offset pointe au milieu d'une structure.

L'ensemble des fichiers répondant à ce format on un seul root_node de type SObj (Scene data).

=== '''Préambule''' : (0x100 octets / 0 octets) ===
* 4 octets - hsd_header_offset=0x100 (toujours)
* 4 octets - bones_flags_table_offset=0x20 (toujours) - offset de la liste des flags des armatures
* 4 octets - bones_table_offset=0xC0 (toujours) - offset de la liste des armatures
* 20 octets - Pad - (toujours)
* 4 octets [32] - Inconnu (flags des armatures ?) 1 octet par flag ?
* 32 octets - Pad - (toujours)
* 32 octets - armatures ?
* 32 octets - Pad - (toujours)
=== '''HSD Header''' - (0x20 octets) ===
* 4 octets - Taille totale du fichier
* 4 octets - Taille du Data block
* 4 octets - Nombre d'entrée dans la Table de relocs
* 4 octets - root0_count
* 4 octets - root1_count
* 12 octets - Pad - (toujours)
=== '''Data block''' : ===
* JOBJ, etc. -> Ces structures sont détaillée plus loin ci-dessous.
=== '''Relocation Table''' : ===
* Tableau d'offsets de 4 octets - Offsets des structures dans le DB.
=== '''Root Nodes (2)''' : ===
* Tableau de taille 8 * root0_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
* Tableau de taille 8 * root1_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
=== '''String Table''' : ===
* Suite de strings terminées par Null au nombre de root0_count + root1_count

== Structures rencontrées dans le DB ==
Note : l'arborescence est cumulative sur les transformations pour les relations parents->enfants

Les Noeuds Racine qui ont pour nom "scene_data" pointent sur un SObj :
=== '''SObj''' : (0x10 octets) ===
* 4 octets - JObjDescs_offsets_list_offset
* 4 octets - Cameras_list_offset
* 4 octets - Lights_list_offset
* 4 octets - Fog

"scene_data" == nom du nœud racine
JObjDescs_offsets_list_offset, cameras.. pointent sur une liste d'offsets terminée par 4 octets à 0x00.
lights_list_offset pointe sur des couples (4 octets - LObj_offset ; 4 octets - light_anim_pointer_offset)

=== '''JObjDesc''' : (0x10 octets) ===
* 4 octets - root_joint_offset - JObj
* 4 octets - joint_animations_offset - ?
* 4 octets - material_animations_offset - ?
* 4 octets - shape_animations_offset - ?

=== '''CObj''' : (0x38 octets) ===
* 4 octets - flags
* 4 octets - projection_type - ProjectionTypeEnum
* 2 octets - viewport_left
* 2 octets - viewport_right
* 2 octets - viewport_top
* 2 octets - viewport_bottom
* 4 octets - proj_width
* 4 octets - proj_height
* 4 octets - eye_offset - WObj
* 4 octets - target_offset - WObj
* 4 octets - roll
* 4 octets - Inconnu
* 4 octets - float - near_clip
* 4 octets - float - far_clip
* 4 octets - float - field_of_view
* 4 octets - float - aspect
Camera object. Note : pour frustrum ou ortho, la structure est différente.

* '''ProjectionTypeEnum''':
** PERSPECTIVE = 1
** FRUSTRUM = 2
** ORTHO = 3

=== '''WObj''': (0x14 octets) ===
* 4 octets - Inconnu
* 4 octets - float - v1
* 4 octets - float - v2
* 4 octets - float - v3
* 4 octets - Inconnu

eye / target

=== '''LObj''' : (0x1c octets) ===
* 4 octets - class_name
* 4 octets - next_offset
* 2 octets - flags - LObjFlagsEnum
* 2 octets - attenuation_flags - LObjAttenuationFlagsEnum
* 1 octet - color_r
* 1 octet - color_g
* 1 octet - color_b
* 1 octet - color_alpha
* 4 octets - lobj_point_offset - position
* 4 octets - infinite_data
* 4 octets - point_spot_data
light

* '''LObjFlagsEnum''' :
** LOBJ_AMBIANT = 00 00
** LOBJ_INFINITE = 00 01
** LOBJ_POINT = 00 02
** LOBJ_SPOT = 00 03
** LOBJ_DIFFUSE = 00 04
** LOBJ_SPECULAR = 00 08
** LOBJ_ALPHA = 00 10
** LOBJ_HIDDEN = 00 20
** LOBJ_RAW_PARAM = 00 40
** LOBJ_DIFF_DIRTY = 00 80
** LOBJ_SPEC_DIRTY = 01 00

* '''LObjAttenuationFlagsEnum''' :
** LOBJ_LIGHT_ATTN_NONE = 00 00
** LOBJ_LIGHT_ATTN = 00 01

=== '''LObjPoint''' : (0x14 octets) ===
* 4 octets - class_name
* 4 octets - float - x
* 4 octets - float - y
* 4 octets - float - z
* 4 octets - Inconnu

=== '''LightAnimPointer''' : (0x10 octets) ===
** 4 octets - next_offset - (LightAnimPointer)
** 4 octets - light_anim - ?
** 4 octets - position_anim - ?
** 4 octets - interst_anim - ?
Bugs dans HSDRaw - à tester

=== '''JObj''' : (0x40 octets) ===
* 4 octets - Inconnu
* 4 octets - flags
* 4 octets - child_offset (JObj)
* 4 octets - next_offset (JObj)
* 4 octets - dobj_offset (DObj)
* 4 octets [3] - float3 - rotation_xyz
* 4 octets [3] - float3 - scale_xyz
* 4 octets [3] - float3 - translation_xyz
* 4 octets - inverse_world_transform_offset (inverse world transform = Matrice de 4x3)
* 4 octets - robj_offset

Pointé par les listes dans Root Node scene_data.

* '''JObjFlagsEnum''' : (peuvent se cumuler)
** NULL = 00 00 00 00
** SKELETON = 00 00 00 01
** SKELETON_ROOT = 00 00 00 02
** ENVELOPE_MODEL = 00 00 00 04
** CLASSICAL_SCALING = 00 00 00 08
** HIDDEN = 00 00 00 10
** PTCL = 00 00 00 20
** MTX_DIRTY = 00 00 00 40
** LIGHTING = 00 00 00 80
** TEXGEN = 00 00 01 00
** BILLBOARD = 00 00 02 00
** VBILLBOARD = 00 00 04 00
** HBILLBOARD = 00 00 06 00
** RBILLBOARD = 00 00 08 00
** INSTANCE = 00 00 10 00
** PBILLBOARD = 00 00 20 00
** SPLINE = 00 00 40 00
** FLIP_IK = 00 00 80 00
** SPECULAR = 00 01 00 00
** USE_QUATERNION = 00 02 00 00
** OPA = 00 04 00 00
** XLU = 00 08 00 00
** TEXEDGE = 00 10 00 00
** JOINT1 = 00 20 00 00
** JOINT2 = 00 40 00 00
** EFFECTOR = 00 60 00 00
** USER_DEFINED_MTX = 00 80 00 00
** MTX_INDEPEND_PARENT = 01 00 00 00
** MTX_INDEPEND_SRT = 02 00 00 00
** MTX_SCALE_COMPENSATE = 04 00 00 00
** ROOT_OPA = 10 00 00 00
** ROOT_XLU = 20 00 00 00
** ROOT_TEXEDGE = 40 00 00 00

=== '''InverseWorldTransform''' : (0x30 octets) ===
* 4 octets - float - M11
* 4 octets - float - M12
* 4 octets - float - M13
* 4 octets - float - M14
* 4 octets - float - M21
* 4 octets - float - M22
* 4 octets - float - M23
* 4 octets - float - M24
* 4 octets - float - M31
* 4 octets - float - M32
* 4 octets - float - M33
* 4 octets - float - M34

=== '''DObj''' : (0x10 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - prochain DOBJ
* 4 octets - mobj_offset - material offset
* 4 octets - pobj_offset - mesh offset
Liste chaînée qui permet de récupérer l'ensemble des materials & mesh pour le JObj auquel il est lié.

=== '''MObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - render_flags - RenderFlagsEnum
* 4 octets - tobj_offset - offset de texture - peut être invalide s'il n'y a pas de texture pour le material
* 4 octets - material_offset - couleurs des materials ?
* 8 octets - PEDesc ?

Contient les textures & informations sur les couleurs des Materials.

* '''RenderFlagsEnum''' : (se cumulent)
** USER = 80 00 00 00
** CONSTANT = 00 00 00 01
** VERTEX = 00 00 00 02
** BOTH = 00 00 00 03
** DIFFUSE = 00 00 00 04
** SPECULAR = 00 00 00 08
** TEX0 = 00 00 00 10
** TEX1 = 00 00 00 20
** TEX2 = 00 00 00 40
** TEX3 = 00 00 00 80
** TEX4 = 00 00 01 00
** TEX5 = 00 00 02 00
** TEX6 = 00 00 04 00
** TEX7 = 00 00 08 00
** TOON = 00 00 10 00
** ALPHA_MAT = 00 00 20 00
** ALPHA_VTX = 00 00 40 00
** ALPHA_BOTH = 00 00 60 00
** ZOFST = 01 00 00 00
** EFFECT = 02 00 00 00
** SHADOW = 04 00 00 00
** ZMODE_ALWAYS = 08 00 00 00
** DF_ALL = 10 00 00 00
** NO_ZUPDATE = 20 00 00 00
** XLU = 40 00 00 00

=== '''TObj''' : (0x5c octets) ===
* 4 octets - ?
* 4 octets - ?
* 4 octets - tex_map_id - TexMapIdEnum
* 4 octets - gx_tex_gen_src - GXTexGenSrcEnum
* 4 octets - float - rx
* 4 octets - float - ry
* 4 octets - float - rz
* 4 octets - float - sx
* 4 octets - float - sy
* 4 octets - float - sz
* 4 octets - float - tx
* 4 octets - float - ty
* 4 octets - float - tz
* 4 octets - wrap_s - WrapEnum
* 4 octets - wrap_t - WrapEnum
* 1 octet - w_scale
* 1 octet - h_scale
* 2 octets - ?
* 1 octets - bump_map - (False = 00 ; True = 01)
* 4 bits - alpha_operation - AlphaOperationEnum
* 4 bits - color_operation - ColorOperationEnum
* 1 octet - shadow_lightmap - (False = 00 ; True = 01) (2 octets avec une Enum lightmap limite)
* 1 bit - ext_lightmap - (False = 0 ; True = 1)
* 1 bit - ambiant_lightmap - (False = 0 ; True = 1)
* 1 bit - specular_lightmap - (False = 0 ; True = 1)
* 1 bit - diffuse_lightmap (False = 0 ; True = 1)
* 4 bits - coord_type - CoordTypeEnum
* 4 octets - float - blending - utilisé quand color_operation ou alpha_operation == BLEND
* 4 octets - mag_filter - MagFilterEnum
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
Informations de Textures. Le TObj contient des informations sur les paramètres d'environnement de textures utilisés pour le rendu graphique ainsi que les offset de l'image et des données de la palette utilisés pour cette texture. Le plus important ici, c'est l'offset d'image et la palette/tlut - si l'image n'est pas indexée (RGBA, CMPR, etc.) alors la structure de description palette/tlut n'est pas utilisée.

* '''TexMapIdEnum''' :
** GX_TEXMAP0 = 00 00 00 00
** GX_TEXMAP1 = 00 00 00 01
** GX_TEXMAP2 = 00 00 00 02
** GX_TEXMAP3 = 00 00 00 03
** GX_TEXMAP4 = 00 00 00 04
** GX_TEXMAP5 = 00 00 00 05
** GX_TEXMAP6 = 00 00 00 06
** GX_TEXMAP7 = 00 00 00 07
** GX_MAX_TEXMAP = 00 00 00 08
** GX_TEXMAP_NULL = 00 00 00 09
** GX_TEXMAP_DISABLE = 00 00 00 0A

* '''GXTexGenSrcEnum''' :
** GX_TG_POS = 00 00 00 00
** GX_TG_NRM = 00 00 00 01
** GX_TG_BINRM = 00 00 00 02
** GX_TG_TANGENT = 00 00 00 03
** GX_TG_TEX0 = 00 00 00 04
** GX_TG_TEX1 = 00 00 00 05
** GX_TG_TEX2 = 00 00 00 06
** GX_TG_TEX3 = 00 00 00 07
** GX_TG_TEX4 = 00 00 00 08
** GX_TG_TEX5 = 00 00 00 09
** GX_TG_TEX6 = 00 00 00 0A
** GX_TG_TEX7 = 00 00 00 0B
** GX_TG_TEXCOORD0 = 00 00 00 0C
** GX_TG_TEXCOORD1 = 00 00 00 0D
** GX_TG_TEXCOORD2 = 00 00 00 0E
** GX_TG_TEXCOORD3 = 00 00 00 0F
** GX_TG_TEXCOORD4 = 00 00 00 10
** GX_TG_TEXCOORD5 = 00 00 00 11
** GX_TG_TEXCOORD6 = 00 00 00 12
** GX_TG_COLOR0 = 00 00 00 13
** GX_TG_COLOR1 = 00 00 00 14

* '''AlphaOperationEnum''':
** NONE = 0X
** ALPHAMASK = 1X
** BLEND = 2X
** MODULATE = 3X
** REPLACE = 4X
** PASS = 5X
** ADD = 6X
** SUB = 7X

* '''ColorOperationEnum''':
** NONE = X0
** ALPHA_MASK = X1
** RGB_MASK = X2
** BLEND = X3
** MODULATE = X4
** REPLACE = X5
** PASS = X6
** ADD = X7
** SUB = X8

* '''CoordTypeEnum''':
** UV = X0
** REFLECTION = X1
** HILIGHT = X2
** SHADOW = X3
** TOON = X4
** GRADATION = X5

* '''MagFilterEnum''':
** GX_NEAR = 00 00 00 00
** GX_LINEAR = 00 00 00 01
** GX_NEAR_MIP_NEAR = 00 00 00 02
** GX_LIN_MIP_NEAR = 00 00 00 03
** GX_NEAR_MIP_LIN = 00 00 00 04
** GX_LIN_MIP_LIN = 00 00 00 05

* '''WrapEnum''':
** CLAMP = 00 00 00 00
** REPEAT = 00 00 00 01
** MIRROR = 00 00 00 02

=== '''Material''' : (0x14 octets) ===
* 1 octets - AMB_R - (ambient)
* 1 octets - AMB_G
* 1 octets - AMB_B
* 1 octets - AMB_A
* 1 octets - DIF_R - (diffuse)
* 1 octets - DIF_G
* 1 octets - DIF_B
* 1 octets - DIF_A
* 1 octets - SPC_R - (specular)
* 1 octets - SPC_G
* 1 octets - SPC_B
* 1 octets - SPC_A
* 4 octets - float - alpha
* 4 octets - float - shininess

=== '''PObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - pobj
* 4 octets - vertex_attr_list_offset
* 2 octets - Flags - PObjFlagsEnum
* 2 octets - display_list_size - number of 0x20 (32) byte blocks occupied by display list data
* 4 octets - display_list_offset
* 4 octets - weight_list_offset - ? verifier qu'on retrouve bien le tableau d'envelope_weights à cet offset

Comme l'indique next_offset, il s'agit d'une liste de meshs à afficher pour un material donné référencé par un dobj. PObj contient les offsets de vertex attributes / display list / joint weight list ce qui suffit et permet d’interpréter et traiter les coordonnées de vertices, normals & textures.

Les attributs vertex sont les plus important - les parametres specifiés contrôlent tout : du format, de la taille des données de chaque vertex, normal et coordonnées de textures et comment ces valeurs sont dimensionnées (scaled) par rapport à la présence et la taille de chaque valeur d'index qui apparaît dans la display list information.

* '''PObjFlagsEnum''' :
** Inconnu0 = 00 01
** Inconnu1 = 00 02
** ANIM = 00 08
** SHAPE_ANIM = 10 00
** ENVELOPE = 20 00
** CULLBACK = 40 00
** CULLFRONT = 80 00

=== EnvelopeWeights : (0x? octets) ===
* 4 octets - envelope_count
* [envelope_count]:
** 4 octets - float - weight
** 4 octets - pad ?
* 4 octets - jobj_list_offset

=== not verified yet ===

* '''IMAGE_HEADER''' :
** 4 octets - image_offset - image data
** 2 octets - width
** 2 octets - height
** 4 octets - image_format

* '''PALETTE_HEADER''' : (0x10)
** 4 octets - palette_offset - palette data
** 4 octets - palette_format
** 4 octets - Inconnu
** 2 octets - color_count
** 2 octets - Inconnu

image_offset et palette_offset sont souvent partagés par plusieurs textures - savoir ça permet de retrouver toutes les informations sur les images des textures (largeur, hauteur, format), ainsi que le format et le nombre de couleurs de la palette/tlut.

Le format d'image ne détermine pas le nombre total de couleurs de la palette qu'elle utilisent. Par exemple, une image indexée sur 8 bits aurait un maximum de 256 couleurs mais seulement 136 ou 221 couleurs sont actuellement utilisées. De la sorte, la palette n'utilisera pas la taille totale qu'elle devrait utiliser.

Les images suivent la structure généralement utilisée par la GameCube :

IMAGE FORMATS :
* case 0: //i4
* case 1: //i8
* case 2: //i4a4
* case 3: //i8a8
* case 4: //r5g6b5
* case 5: //rgb5a3
* case 6: //r8g8b8a8
* case 8: //index4
* case 9: //index8
* case 0xa: //index14x2
* case 0xe: //s3tc1

Les formats indexés utilisent aussi les informations de palettes/tlut et les données peuvent apparaître en plusieurs formats :

PALETTE FORMATS :
* case 0: //ia8
* case 1: //r5g6b5
* case 2: //rgb5a3

---> "Joint Data - Accessing Geometry, Mesh, and Vertex Attributes" https://smashboards.com/threads/melee-dat-format.292603/

trad a revoir à partir de là, il faut investiguer le rendu 3D sur GameCube pour mieux comprendre

// déclaration d'un vertex et attribute information
// attr, type, cnt, data_type, flags?, file_offset
* ATTR_DATA
** 4 octets - GXAttr vtx_attr_offset - attr
** 4 octets - GXAttrType vtx_attr_type - index_type
** 4 octets - GXCompCnt comp_cnt - cnt
** 4 octets - GXCompType comp_type - data_type
** 1 octets - scale
** 1 octets - Inconnu
** 2 octets - vtx_stride
** 2 octets - data_offset

vertex_attr_offset pointe sur une liste d'attributs de vertex. Leur nombre n'est pas donné. Les données dans cette structure suivent les informations et les types conçus par l'architecture GameCube/WII et son API. La liste est terminée par une valeur spécifique de vtx_attr qui signale la fin de cette liste. Avec un accès à la doku SDK, il serait fortement conseillé de lire la section à propos des "vertex attributes and other specifications".

La valeur de vtx_attr determine le type de donnée que cet attribut désigne et peut indiquer un nombre de types natifs utilisés utilisés pour passer les données entre les interfaces logicielles et matérielles.

Les valeures possibles sont les suivantes :
* enum GXAttr (4 octets)
** GX_VA_PNMTXIDX = 0, // position/normal matrix index
** GX_VA_TEX0MTXIDX, // texture 0 matrix index
** GX_VA_TEX1MTXIDX, // texture 1 matrix index
** GX_VA_TEX2MTXIDX, // texture 2 matrix index
** GX_VA_TEX3MTXIDX, // texture 3 matrix index
** GX_VA_TEX4MTXIDX, // texture 4 matrix index
** GX_VA_TEX5MTXIDX, // texture 5 matrix index
** GX_VA_TEX6MTXIDX, // texture 6 matrix index
** GX_VA_TEX7MTXIDX, // texture 7 matrix index
** GX_VA_POS = 9, // position
** GX_VA_NRM, // normal
** GX_VA_CLR0, // color 0
** GX_VA_CLR1, // color 1
** GX_VA_TEX0, // input texture coordinate 0
** GX_VA_TEX1, // input texture coordinate 1
** GX_VA_TEX2, // input texture coordinate 2
** GX_VA_TEX3, // input texture coordinate 3
** GX_VA_TEX4, // input texture coordinate 4
** GX_VA_TEX5, // input texture coordinate 5
** GX_VA_TEX6, // input texture coordinate 6
** GX_VA_TEX7, // input texture coordinate 7

** GX_POS_MTX_ARRAY, // position matrix array pointer
** GX_NRM_MTX_ARRAY, // normal matrix array pointer
** GX_TEX_MTX_ARRAY, // texture matrix array pointer
** GX_LIGHT_ARRAY, // light parameter array pointer
** GX_VA_NBT, // normal, bi-normal, tangent
** GX_VA_MAX_ATTR, // maximum number of vertex attributes

** GX_VA_NULL = 0xff // NULL attribute (to mark end of lists)

Toutes les données nécessaires pour représenter un mesh peuvent être spécifiées et indexées d'une manière ou d'une autre. De même, GX_VA_TEX0MTXIDX, GX_VA_CLR0, et autres sont aussi possibles - les valeurs les plus fréquentes dans les données SSBM sont : GX_VA_PNMTXIDX, GX_VA_POS, GX_VA_NRM, et GX_VA_TEX0. Which is to be expected as joint matrices, vertex positions/normals, and texture coordinates respectively are probably the most basic of elements needed to display a texture mesh, whether static or animated.

When the value of vtx_attr == GX_VA_NULL (0xFF), the end of the vertex attribute array has been reached.

The vtx_attr_type values is actually associated with how the value is indexed, and can thus also determine the size of the index value within the display list data.

* 4 octets - enum GXAttrType
** GX_NONE = 0,
** GX_DIRECT,
** GX_INDEX8,
** GX_INDEX16

* Structures COLL_DATA : (données de collisions)
** 4 octets - vertex_offset (2 float par entrée correspondant à des données 2D probablement)
** 4 octets - vertex_count
** 4 octets - index_offset
** 4 octets - index_count
** 4 octets [5] - tableau inconnu
*** 2 octets - index_start
*** 2 octets - index_count
** 4 octets - Inconnu
** 4 octets - Inconnu

[[Category:Implementations]]
[[Category:Gotcha Force]]

Models

2023-10-07T13:36:09Z

Algoflash: /* Gotcha Force Models */

[[Gotcha Force | ← Gotcha Force]]

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

== Gotcha Force Models ==

Gotcha Force models work as those from the game Super Smash Bros Melee (SSBM) investigated by its [https://smashboards.com/threads/melee-dat-format.292603/ community].

A model is a file format that organizes objects and resources serialized to be used by the '''H'''al '''S'''ys'''D'''olphin ('''HSD''') library. The HSD library is used in several Capcom games. These are graphics materials structured in an hierarchical way.

Ce sont des ressources graphiques structurées de manière hiérarchique. La présence de certaines images dans les modèles montrent à priori l'utilisation de la technique [https://learn.foundry.com/modo/901/content/help/pages/shading_lighting/shader_items/matcap.html matcap].
Par ailleurs, la librairie prendrait ses sources sur le SDK Dolphin, tel que GX ou encore MTX.

=== Fichiers concernés ===
L'ensemble des fichiers ayant dans leur titre '''_mdl''' sont des fichiers modèles correspondant au format décrit dans cette page. On notera les fichiers [[ARZ (Gotcha Force)|.arz]] qui sont des modèles compressés. Le fichier collision.arc et les fichiers tdc00.arc à tdc09.arc sont aussi des modèles.

Les fichiers modèles se retrouvent aussi dans les pzz des borgs (plxxxx.pzz) en position 004 à 009.

=== HSDRaw ===
HSDRaw, un éditeur 3D dotnet de ce format est instable sur mon Windows (algoflash). Il est cependant prouvé qu'un edit des _mdl pour commencer à l'offset 0x100 - après le préambule - permet de visualiser le fichier sur HSDRaw et d'avoir le rendu 3D du Borg (click sur le premier dossier JOBJ - puis le JOBJ dedans et double click sur le nœud en violet). Cela devrait aussi permettre d'éditer certaines propriétés ?

== Structure générale ==
Le format des modèles se découpe en plusieurs blocks. Le préambule fait 0x100 octets au tout début du fichier. Il est souvent absent. Toutes les valeurs sont en unsigned big endian, et le pad est en Nulls bytes (\x00). Les offsets trouvés après le début du Data Block (DB) sont relatifs au début du DB. La table de relocs est un tableau d'offsets de 4 octets (relatif au DB) permettant de traduire en adressage absolu les offsets des structures lors du chargement mémoire. La table de reloc permet par exemple de délimiter les structures du fait qu'il est peu probable qu'un offset pointe au milieu d'une structure.

L'ensemble des fichiers répondant à ce format on un seul root_node de type SObj (Scene data).

=== '''Préambule''' : (0x100 octets / 0 octets) ===
* 4 octets - hsd_header_offset=0x100 (toujours)
* 4 octets - bones_flags_table_offset=0x20 (toujours) - offset de la liste des flags des armatures
* 4 octets - bones_table_offset=0xC0 (toujours) - offset de la liste des armatures
* 20 octets - Pad - (toujours)
* 4 octets [32] - Inconnu (flags des armatures ?) 1 octet par flag ?
* 32 octets - Pad - (toujours)
* 32 octets - armatures ?
* 32 octets - Pad - (toujours)
=== '''HSD Header''' - (0x20 octets) ===
* 4 octets - Taille totale du fichier
* 4 octets - Taille du Data block
* 4 octets - Nombre d'entrée dans la Table de relocs
* 4 octets - root0_count
* 4 octets - root1_count
* 12 octets - Pad - (toujours)
=== '''Data block''' : ===
* JOBJ, etc. -> Ces structures sont détaillée plus loin ci-dessous.
=== '''Relocation Table''' : ===
* Tableau d'offsets de 4 octets - Offsets des structures dans le DB.
=== '''Root Nodes (2)''' : ===
* Tableau de taille 8 * root0_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
* Tableau de taille 8 * root1_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
=== '''String Table''' : ===
* Suite de strings terminées par Null au nombre de root0_count + root1_count

== Structures rencontrées dans le DB ==
Note : l'arborescence est cumulative sur les transformations pour les relations parents->enfants

Les Noeuds Racine qui ont pour nom "scene_data" pointent sur un SObj :
=== '''SObj''' : (0x10 octets) ===
* 4 octets - JObjDescs_offsets_list_offset
* 4 octets - Cameras_list_offset
* 4 octets - Lights_list_offset
* 4 octets - Fog

"scene_data" == nom du nœud racine
JObjDescs_offsets_list_offset, cameras.. pointent sur une liste d'offsets terminée par 4 octets à 0x00.
lights_list_offset pointe sur des couples (4 octets - LObj_offset ; 4 octets - light_anim_pointer_offset)

=== '''JObjDesc''' : (0x10 octets) ===
* 4 octets - root_joint_offset - JObj
* 4 octets - joint_animations_offset - ?
* 4 octets - material_animations_offset - ?
* 4 octets - shape_animations_offset - ?

=== '''CObj''' : (0x38 octets) ===
* 4 octets - flags
* 4 octets - projection_type - ProjectionTypeEnum
* 2 octets - viewport_left
* 2 octets - viewport_right
* 2 octets - viewport_top
* 2 octets - viewport_bottom
* 4 octets - proj_width
* 4 octets - proj_height
* 4 octets - eye_offset - WObj
* 4 octets - target_offset - WObj
* 4 octets - roll
* 4 octets - Inconnu
* 4 octets - float - near_clip
* 4 octets - float - far_clip
* 4 octets - float - field_of_view
* 4 octets - float - aspect
Camera object. Note : pour frustrum ou ortho, la structure est différente.

* '''ProjectionTypeEnum''':
** PERSPECTIVE = 1
** FRUSTRUM = 2
** ORTHO = 3

=== '''WObj''': (0x14 octets) ===
* 4 octets - Inconnu
* 4 octets - float - v1
* 4 octets - float - v2
* 4 octets - float - v3
* 4 octets - Inconnu

eye / target

=== '''LObj''' : (0x1c octets) ===
* 4 octets - class_name
* 4 octets - next_offset
* 2 octets - flags - LObjFlagsEnum
* 2 octets - attenuation_flags - LObjAttenuationFlagsEnum
* 1 octet - color_r
* 1 octet - color_g
* 1 octet - color_b
* 1 octet - color_alpha
* 4 octets - lobj_point_offset - position
* 4 octets - infinite_data
* 4 octets - point_spot_data
light

* '''LObjFlagsEnum''' :
** LOBJ_AMBIANT = 00 00
** LOBJ_INFINITE = 00 01
** LOBJ_POINT = 00 02
** LOBJ_SPOT = 00 03
** LOBJ_DIFFUSE = 00 04
** LOBJ_SPECULAR = 00 08
** LOBJ_ALPHA = 00 10
** LOBJ_HIDDEN = 00 20
** LOBJ_RAW_PARAM = 00 40
** LOBJ_DIFF_DIRTY = 00 80
** LOBJ_SPEC_DIRTY = 01 00

* '''LObjAttenuationFlagsEnum''' :
** LOBJ_LIGHT_ATTN_NONE = 00 00
** LOBJ_LIGHT_ATTN = 00 01

=== '''LObjPoint''' : (0x14 octets) ===
* 4 octets - class_name
* 4 octets - float - x
* 4 octets - float - y
* 4 octets - float - z
* 4 octets - Inconnu

=== '''LightAnimPointer''' : (0x10 octets) ===
** 4 octets - next_offset - (LightAnimPointer)
** 4 octets - light_anim - ?
** 4 octets - position_anim - ?
** 4 octets - interst_anim - ?
Bugs dans HSDRaw - à tester

=== '''JObj''' : (0x40 octets) ===
* 4 octets - Inconnu
* 4 octets - flags
* 4 octets - child_offset (JObj)
* 4 octets - next_offset (JObj)
* 4 octets - dobj_offset (DObj)
* 4 octets [3] - float3 - rotation_xyz
* 4 octets [3] - float3 - scale_xyz
* 4 octets [3] - float3 - translation_xyz
* 4 octets - inverse_world_transform_offset (inverse world transform = Matrice de 4x3)
* 4 octets - robj_offset

Pointé par les listes dans Root Node scene_data.

* '''JObjFlagsEnum''' : (peuvent se cumuler)
** NULL = 00 00 00 00
** SKELETON = 00 00 00 01
** SKELETON_ROOT = 00 00 00 02
** ENVELOPE_MODEL = 00 00 00 04
** CLASSICAL_SCALING = 00 00 00 08
** HIDDEN = 00 00 00 10
** PTCL = 00 00 00 20
** MTX_DIRTY = 00 00 00 40
** LIGHTING = 00 00 00 80
** TEXGEN = 00 00 01 00
** BILLBOARD = 00 00 02 00
** VBILLBOARD = 00 00 04 00
** HBILLBOARD = 00 00 06 00
** RBILLBOARD = 00 00 08 00
** INSTANCE = 00 00 10 00
** PBILLBOARD = 00 00 20 00
** SPLINE = 00 00 40 00
** FLIP_IK = 00 00 80 00
** SPECULAR = 00 01 00 00
** USE_QUATERNION = 00 02 00 00
** OPA = 00 04 00 00
** XLU = 00 08 00 00
** TEXEDGE = 00 10 00 00
** JOINT1 = 00 20 00 00
** JOINT2 = 00 40 00 00
** EFFECTOR = 00 60 00 00
** USER_DEFINED_MTX = 00 80 00 00
** MTX_INDEPEND_PARENT = 01 00 00 00
** MTX_INDEPEND_SRT = 02 00 00 00
** MTX_SCALE_COMPENSATE = 04 00 00 00
** ROOT_OPA = 10 00 00 00
** ROOT_XLU = 20 00 00 00
** ROOT_TEXEDGE = 40 00 00 00

=== '''InverseWorldTransform''' : (0x30 octets) ===
* 4 octets - float - M11
* 4 octets - float - M12
* 4 octets - float - M13
* 4 octets - float - M14
* 4 octets - float - M21
* 4 octets - float - M22
* 4 octets - float - M23
* 4 octets - float - M24
* 4 octets - float - M31
* 4 octets - float - M32
* 4 octets - float - M33
* 4 octets - float - M34

=== '''DObj''' : (0x10 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - prochain DOBJ
* 4 octets - mobj_offset - material offset
* 4 octets - pobj_offset - mesh offset
Liste chaînée qui permet de récupérer l'ensemble des materials & mesh pour le JObj auquel il est lié.

=== '''MObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - render_flags - RenderFlagsEnum
* 4 octets - tobj_offset - offset de texture - peut être invalide s'il n'y a pas de texture pour le material
* 4 octets - material_offset - couleurs des materials ?
* 8 octets - PEDesc ?

Contient les textures & informations sur les couleurs des Materials.

* '''RenderFlagsEnum''' : (se cumulent)
** USER = 80 00 00 00
** CONSTANT = 00 00 00 01
** VERTEX = 00 00 00 02
** BOTH = 00 00 00 03
** DIFFUSE = 00 00 00 04
** SPECULAR = 00 00 00 08
** TEX0 = 00 00 00 10
** TEX1 = 00 00 00 20
** TEX2 = 00 00 00 40
** TEX3 = 00 00 00 80
** TEX4 = 00 00 01 00
** TEX5 = 00 00 02 00
** TEX6 = 00 00 04 00
** TEX7 = 00 00 08 00
** TOON = 00 00 10 00
** ALPHA_MAT = 00 00 20 00
** ALPHA_VTX = 00 00 40 00
** ALPHA_BOTH = 00 00 60 00
** ZOFST = 01 00 00 00
** EFFECT = 02 00 00 00
** SHADOW = 04 00 00 00
** ZMODE_ALWAYS = 08 00 00 00
** DF_ALL = 10 00 00 00
** NO_ZUPDATE = 20 00 00 00
** XLU = 40 00 00 00

=== '''TObj''' : (0x5c octets) ===
* 4 octets - ?
* 4 octets - ?
* 4 octets - tex_map_id - TexMapIdEnum
* 4 octets - gx_tex_gen_src - GXTexGenSrcEnum
* 4 octets - float - rx
* 4 octets - float - ry
* 4 octets - float - rz
* 4 octets - float - sx
* 4 octets - float - sy
* 4 octets - float - sz
* 4 octets - float - tx
* 4 octets - float - ty
* 4 octets - float - tz
* 4 octets - wrap_s - WrapEnum
* 4 octets - wrap_t - WrapEnum
* 1 octet - w_scale
* 1 octet - h_scale
* 2 octets - ?
* 1 octets - bump_map - (False = 00 ; True = 01)
* 4 bits - alpha_operation - AlphaOperationEnum
* 4 bits - color_operation - ColorOperationEnum
* 1 octet - shadow_lightmap - (False = 00 ; True = 01) (2 octets avec une Enum lightmap limite)
* 1 bit - ext_lightmap - (False = 0 ; True = 1)
* 1 bit - ambiant_lightmap - (False = 0 ; True = 1)
* 1 bit - specular_lightmap - (False = 0 ; True = 1)
* 1 bit - diffuse_lightmap (False = 0 ; True = 1)
* 4 bits - coord_type - CoordTypeEnum
* 4 octets - float - blending - utilisé quand color_operation ou alpha_operation == BLEND
* 4 octets - mag_filter - MagFilterEnum
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
Informations de Textures. Le TObj contient des informations sur les paramètres d'environnement de textures utilisés pour le rendu graphique ainsi que les offset de l'image et des données de la palette utilisés pour cette texture. Le plus important ici, c'est l'offset d'image et la palette/tlut - si l'image n'est pas indexée (RGBA, CMPR, etc.) alors la structure de description palette/tlut n'est pas utilisée.

* '''TexMapIdEnum''' :
** GX_TEXMAP0 = 00 00 00 00
** GX_TEXMAP1 = 00 00 00 01
** GX_TEXMAP2 = 00 00 00 02
** GX_TEXMAP3 = 00 00 00 03
** GX_TEXMAP4 = 00 00 00 04
** GX_TEXMAP5 = 00 00 00 05
** GX_TEXMAP6 = 00 00 00 06
** GX_TEXMAP7 = 00 00 00 07
** GX_MAX_TEXMAP = 00 00 00 08
** GX_TEXMAP_NULL = 00 00 00 09
** GX_TEXMAP_DISABLE = 00 00 00 0A

* '''GXTexGenSrcEnum''' :
** GX_TG_POS = 00 00 00 00
** GX_TG_NRM = 00 00 00 01
** GX_TG_BINRM = 00 00 00 02
** GX_TG_TANGENT = 00 00 00 03
** GX_TG_TEX0 = 00 00 00 04
** GX_TG_TEX1 = 00 00 00 05
** GX_TG_TEX2 = 00 00 00 06
** GX_TG_TEX3 = 00 00 00 07
** GX_TG_TEX4 = 00 00 00 08
** GX_TG_TEX5 = 00 00 00 09
** GX_TG_TEX6 = 00 00 00 0A
** GX_TG_TEX7 = 00 00 00 0B
** GX_TG_TEXCOORD0 = 00 00 00 0C
** GX_TG_TEXCOORD1 = 00 00 00 0D
** GX_TG_TEXCOORD2 = 00 00 00 0E
** GX_TG_TEXCOORD3 = 00 00 00 0F
** GX_TG_TEXCOORD4 = 00 00 00 10
** GX_TG_TEXCOORD5 = 00 00 00 11
** GX_TG_TEXCOORD6 = 00 00 00 12
** GX_TG_COLOR0 = 00 00 00 13
** GX_TG_COLOR1 = 00 00 00 14

* '''AlphaOperationEnum''':
** NONE = 0X
** ALPHAMASK = 1X
** BLEND = 2X
** MODULATE = 3X
** REPLACE = 4X
** PASS = 5X
** ADD = 6X
** SUB = 7X

* '''ColorOperationEnum''':
** NONE = X0
** ALPHA_MASK = X1
** RGB_MASK = X2
** BLEND = X3
** MODULATE = X4
** REPLACE = X5
** PASS = X6
** ADD = X7
** SUB = X8

* '''CoordTypeEnum''':
** UV = X0
** REFLECTION = X1
** HILIGHT = X2
** SHADOW = X3
** TOON = X4
** GRADATION = X5

* '''MagFilterEnum''':
** GX_NEAR = 00 00 00 00
** GX_LINEAR = 00 00 00 01
** GX_NEAR_MIP_NEAR = 00 00 00 02
** GX_LIN_MIP_NEAR = 00 00 00 03
** GX_NEAR_MIP_LIN = 00 00 00 04
** GX_LIN_MIP_LIN = 00 00 00 05

* '''WrapEnum''':
** CLAMP = 00 00 00 00
** REPEAT = 00 00 00 01
** MIRROR = 00 00 00 02

=== '''Material''' : (0x14 octets) ===
* 1 octets - AMB_R - (ambient)
* 1 octets - AMB_G
* 1 octets - AMB_B
* 1 octets - AMB_A
* 1 octets - DIF_R - (diffuse)
* 1 octets - DIF_G
* 1 octets - DIF_B
* 1 octets - DIF_A
* 1 octets - SPC_R - (specular)
* 1 octets - SPC_G
* 1 octets - SPC_B
* 1 octets - SPC_A
* 4 octets - float - alpha
* 4 octets - float - shininess

=== '''PObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - pobj
* 4 octets - vertex_attr_list_offset
* 2 octets - Flags - PObjFlagsEnum
* 2 octets - display_list_size - number of 0x20 (32) byte blocks occupied by display list data
* 4 octets - display_list_offset
* 4 octets - weight_list_offset - ? verifier qu'on retrouve bien le tableau d'envelope_weights à cet offset

Comme l'indique next_offset, il s'agit d'une liste de meshs à afficher pour un material donné référencé par un dobj. PObj contient les offsets de vertex attributes / display list / joint weight list ce qui suffit et permet d’interpréter et traiter les coordonnées de vertices, normals & textures.

Les attributs vertex sont les plus important - les parametres specifiés contrôlent tout : du format, de la taille des données de chaque vertex, normal et coordonnées de textures et comment ces valeurs sont dimensionnées (scaled) par rapport à la présence et la taille de chaque valeur d'index qui apparaît dans la display list information.

* '''PObjFlagsEnum''' :
** Inconnu0 = 00 01
** Inconnu1 = 00 02
** ANIM = 00 08
** SHAPE_ANIM = 10 00
** ENVELOPE = 20 00
** CULLBACK = 40 00
** CULLFRONT = 80 00

=== EnvelopeWeights : (0x? octets) ===
* 4 octets - envelope_count
* [envelope_count]:
** 4 octets - float - weight
** 4 octets - pad ?
* 4 octets - jobj_list_offset

=== not verified yet ===

* '''IMAGE_HEADER''' :
** 4 octets - image_offset - image data
** 2 octets - width
** 2 octets - height
** 4 octets - image_format

* '''PALETTE_HEADER''' : (0x10)
** 4 octets - palette_offset - palette data
** 4 octets - palette_format
** 4 octets - Inconnu
** 2 octets - color_count
** 2 octets - Inconnu

image_offset et palette_offset sont souvent partagés par plusieurs textures - savoir ça permet de retrouver toutes les informations sur les images des textures (largeur, hauteur, format), ainsi que le format et le nombre de couleurs de la palette/tlut.

Le format d'image ne détermine pas le nombre total de couleurs de la palette qu'elle utilisent. Par exemple, une image indexée sur 8 bits aurait un maximum de 256 couleurs mais seulement 136 ou 221 couleurs sont actuellement utilisées. De la sorte, la palette n'utilisera pas la taille totale qu'elle devrait utiliser.

Les images suivent la structure généralement utilisée par la GameCube :

IMAGE FORMATS :
* case 0: //i4
* case 1: //i8
* case 2: //i4a4
* case 3: //i8a8
* case 4: //r5g6b5
* case 5: //rgb5a3
* case 6: //r8g8b8a8
* case 8: //index4
* case 9: //index8
* case 0xa: //index14x2
* case 0xe: //s3tc1

Les formats indexés utilisent aussi les informations de palettes/tlut et les données peuvent apparaître en plusieurs formats :

PALETTE FORMATS :
* case 0: //ia8
* case 1: //r5g6b5
* case 2: //rgb5a3

---> "Joint Data - Accessing Geometry, Mesh, and Vertex Attributes" https://smashboards.com/threads/melee-dat-format.292603/

trad a revoir à partir de là, il faut investiguer le rendu 3D sur GameCube pour mieux comprendre

// déclaration d'un vertex et attribute information
// attr, type, cnt, data_type, flags?, file_offset
* ATTR_DATA
** 4 octets - GXAttr vtx_attr_offset - attr
** 4 octets - GXAttrType vtx_attr_type - index_type
** 4 octets - GXCompCnt comp_cnt - cnt
** 4 octets - GXCompType comp_type - data_type
** 1 octets - scale
** 1 octets - Inconnu
** 2 octets - vtx_stride
** 2 octets - data_offset

vertex_attr_offset pointe sur une liste d'attributs de vertex. Leur nombre n'est pas donné. Les données dans cette structure suivent les informations et les types conçus par l'architecture GameCube/WII et son API. La liste est terminée par une valeur spécifique de vtx_attr qui signale la fin de cette liste. Avec un accès à la doku SDK, il serait fortement conseillé de lire la section à propos des "vertex attributes and other specifications".

La valeur de vtx_attr determine le type de donnée que cet attribut désigne et peut indiquer un nombre de types natifs utilisés utilisés pour passer les données entre les interfaces logicielles et matérielles.

Les valeures possibles sont les suivantes :
* enum GXAttr (4 octets)
** GX_VA_PNMTXIDX = 0, // position/normal matrix index
** GX_VA_TEX0MTXIDX, // texture 0 matrix index
** GX_VA_TEX1MTXIDX, // texture 1 matrix index
** GX_VA_TEX2MTXIDX, // texture 2 matrix index
** GX_VA_TEX3MTXIDX, // texture 3 matrix index
** GX_VA_TEX4MTXIDX, // texture 4 matrix index
** GX_VA_TEX5MTXIDX, // texture 5 matrix index
** GX_VA_TEX6MTXIDX, // texture 6 matrix index
** GX_VA_TEX7MTXIDX, // texture 7 matrix index
** GX_VA_POS = 9, // position
** GX_VA_NRM, // normal
** GX_VA_CLR0, // color 0
** GX_VA_CLR1, // color 1
** GX_VA_TEX0, // input texture coordinate 0
** GX_VA_TEX1, // input texture coordinate 1
** GX_VA_TEX2, // input texture coordinate 2
** GX_VA_TEX3, // input texture coordinate 3
** GX_VA_TEX4, // input texture coordinate 4
** GX_VA_TEX5, // input texture coordinate 5
** GX_VA_TEX6, // input texture coordinate 6
** GX_VA_TEX7, // input texture coordinate 7

** GX_POS_MTX_ARRAY, // position matrix array pointer
** GX_NRM_MTX_ARRAY, // normal matrix array pointer
** GX_TEX_MTX_ARRAY, // texture matrix array pointer
** GX_LIGHT_ARRAY, // light parameter array pointer
** GX_VA_NBT, // normal, bi-normal, tangent
** GX_VA_MAX_ATTR, // maximum number of vertex attributes

** GX_VA_NULL = 0xff // NULL attribute (to mark end of lists)

Toutes les données nécessaires pour représenter un mesh peuvent être spécifiées et indexées d'une manière ou d'une autre. De même, GX_VA_TEX0MTXIDX, GX_VA_CLR0, et autres sont aussi possibles - les valeurs les plus fréquentes dans les données SSBM sont : GX_VA_PNMTXIDX, GX_VA_POS, GX_VA_NRM, et GX_VA_TEX0. Which is to be expected as joint matrices, vertex positions/normals, and texture coordinates respectively are probably the most basic of elements needed to display a texture mesh, whether static or animated.

When the value of vtx_attr == GX_VA_NULL (0xFF), the end of the vertex attribute array has been reached.

The vtx_attr_type values is actually associated with how the value is indexed, and can thus also determine the size of the index value within the display list data.

* 4 octets - enum GXAttrType
** GX_NONE = 0,
** GX_DIRECT,
** GX_INDEX8,
** GX_INDEX16

* Structures COLL_DATA : (données de collisions)
** 4 octets - vertex_offset (2 float par entrée correspondant à des données 2D probablement)
** 4 octets - vertex_count
** 4 octets - index_offset
** 4 octets - index_count
** 4 octets [5] - tableau inconnu
*** 2 octets - index_start
*** 2 octets - index_count
** 4 octets - Inconnu
** 4 octets - Inconnu

[[Category:Implementations]]
[[Category:Gotcha Force]]

Models

2023-10-07T13:35:50Z

Algoflash: /* Gotcha Force Models */

[[Gotcha Force | ← Gotcha Force]]

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

== Gotcha Force Models ==

Gotcha Force models work as those from the game Super Smash Bros Melee (SSBM) investigated by its [https://smashboards.com/threads/melee-dat-format.292603/ community].

A model is a file format that organizes objects and resources serialized to be used by the '''H'''al '''S'''ys'''D'''olphin ('''HSD''') library. The HSD library is used in several Capcom games. These are graphic materials structured in a hierarchical way.

Ce sont des ressources graphiques structurées de manière hiérarchique. La présence de certaines images dans les modèles montrent à priori l'utilisation de la technique [https://learn.foundry.com/modo/901/content/help/pages/shading_lighting/shader_items/matcap.html matcap].
Par ailleurs, la librairie prendrait ses sources sur le SDK Dolphin, tel que GX ou encore MTX.

=== Fichiers concernés ===
L'ensemble des fichiers ayant dans leur titre '''_mdl''' sont des fichiers modèles correspondant au format décrit dans cette page. On notera les fichiers [[ARZ (Gotcha Force)|.arz]] qui sont des modèles compressés. Le fichier collision.arc et les fichiers tdc00.arc à tdc09.arc sont aussi des modèles.

Les fichiers modèles se retrouvent aussi dans les pzz des borgs (plxxxx.pzz) en position 004 à 009.

=== HSDRaw ===
HSDRaw, un éditeur 3D dotnet de ce format est instable sur mon Windows (algoflash). Il est cependant prouvé qu'un edit des _mdl pour commencer à l'offset 0x100 - après le préambule - permet de visualiser le fichier sur HSDRaw et d'avoir le rendu 3D du Borg (click sur le premier dossier JOBJ - puis le JOBJ dedans et double click sur le nœud en violet). Cela devrait aussi permettre d'éditer certaines propriétés ?

== Structure générale ==
Le format des modèles se découpe en plusieurs blocks. Le préambule fait 0x100 octets au tout début du fichier. Il est souvent absent. Toutes les valeurs sont en unsigned big endian, et le pad est en Nulls bytes (\x00). Les offsets trouvés après le début du Data Block (DB) sont relatifs au début du DB. La table de relocs est un tableau d'offsets de 4 octets (relatif au DB) permettant de traduire en adressage absolu les offsets des structures lors du chargement mémoire. La table de reloc permet par exemple de délimiter les structures du fait qu'il est peu probable qu'un offset pointe au milieu d'une structure.

L'ensemble des fichiers répondant à ce format on un seul root_node de type SObj (Scene data).

=== '''Préambule''' : (0x100 octets / 0 octets) ===
* 4 octets - hsd_header_offset=0x100 (toujours)
* 4 octets - bones_flags_table_offset=0x20 (toujours) - offset de la liste des flags des armatures
* 4 octets - bones_table_offset=0xC0 (toujours) - offset de la liste des armatures
* 20 octets - Pad - (toujours)
* 4 octets [32] - Inconnu (flags des armatures ?) 1 octet par flag ?
* 32 octets - Pad - (toujours)
* 32 octets - armatures ?
* 32 octets - Pad - (toujours)
=== '''HSD Header''' - (0x20 octets) ===
* 4 octets - Taille totale du fichier
* 4 octets - Taille du Data block
* 4 octets - Nombre d'entrée dans la Table de relocs
* 4 octets - root0_count
* 4 octets - root1_count
* 12 octets - Pad - (toujours)
=== '''Data block''' : ===
* JOBJ, etc. -> Ces structures sont détaillée plus loin ci-dessous.
=== '''Relocation Table''' : ===
* Tableau d'offsets de 4 octets - Offsets des structures dans le DB.
=== '''Root Nodes (2)''' : ===
* Tableau de taille 8 * root0_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
* Tableau de taille 8 * root1_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
=== '''String Table''' : ===
* Suite de strings terminées par Null au nombre de root0_count + root1_count

== Structures rencontrées dans le DB ==
Note : l'arborescence est cumulative sur les transformations pour les relations parents->enfants

Les Noeuds Racine qui ont pour nom "scene_data" pointent sur un SObj :
=== '''SObj''' : (0x10 octets) ===
* 4 octets - JObjDescs_offsets_list_offset
* 4 octets - Cameras_list_offset
* 4 octets - Lights_list_offset
* 4 octets - Fog

"scene_data" == nom du nœud racine
JObjDescs_offsets_list_offset, cameras.. pointent sur une liste d'offsets terminée par 4 octets à 0x00.
lights_list_offset pointe sur des couples (4 octets - LObj_offset ; 4 octets - light_anim_pointer_offset)

=== '''JObjDesc''' : (0x10 octets) ===
* 4 octets - root_joint_offset - JObj
* 4 octets - joint_animations_offset - ?
* 4 octets - material_animations_offset - ?
* 4 octets - shape_animations_offset - ?

=== '''CObj''' : (0x38 octets) ===
* 4 octets - flags
* 4 octets - projection_type - ProjectionTypeEnum
* 2 octets - viewport_left
* 2 octets - viewport_right
* 2 octets - viewport_top
* 2 octets - viewport_bottom
* 4 octets - proj_width
* 4 octets - proj_height
* 4 octets - eye_offset - WObj
* 4 octets - target_offset - WObj
* 4 octets - roll
* 4 octets - Inconnu
* 4 octets - float - near_clip
* 4 octets - float - far_clip
* 4 octets - float - field_of_view
* 4 octets - float - aspect
Camera object. Note : pour frustrum ou ortho, la structure est différente.

* '''ProjectionTypeEnum''':
** PERSPECTIVE = 1
** FRUSTRUM = 2
** ORTHO = 3

=== '''WObj''': (0x14 octets) ===
* 4 octets - Inconnu
* 4 octets - float - v1
* 4 octets - float - v2
* 4 octets - float - v3
* 4 octets - Inconnu

eye / target

=== '''LObj''' : (0x1c octets) ===
* 4 octets - class_name
* 4 octets - next_offset
* 2 octets - flags - LObjFlagsEnum
* 2 octets - attenuation_flags - LObjAttenuationFlagsEnum
* 1 octet - color_r
* 1 octet - color_g
* 1 octet - color_b
* 1 octet - color_alpha
* 4 octets - lobj_point_offset - position
* 4 octets - infinite_data
* 4 octets - point_spot_data
light

* '''LObjFlagsEnum''' :
** LOBJ_AMBIANT = 00 00
** LOBJ_INFINITE = 00 01
** LOBJ_POINT = 00 02
** LOBJ_SPOT = 00 03
** LOBJ_DIFFUSE = 00 04
** LOBJ_SPECULAR = 00 08
** LOBJ_ALPHA = 00 10
** LOBJ_HIDDEN = 00 20
** LOBJ_RAW_PARAM = 00 40
** LOBJ_DIFF_DIRTY = 00 80
** LOBJ_SPEC_DIRTY = 01 00

* '''LObjAttenuationFlagsEnum''' :
** LOBJ_LIGHT_ATTN_NONE = 00 00
** LOBJ_LIGHT_ATTN = 00 01

=== '''LObjPoint''' : (0x14 octets) ===
* 4 octets - class_name
* 4 octets - float - x
* 4 octets - float - y
* 4 octets - float - z
* 4 octets - Inconnu

=== '''LightAnimPointer''' : (0x10 octets) ===
** 4 octets - next_offset - (LightAnimPointer)
** 4 octets - light_anim - ?
** 4 octets - position_anim - ?
** 4 octets - interst_anim - ?
Bugs dans HSDRaw - à tester

=== '''JObj''' : (0x40 octets) ===
* 4 octets - Inconnu
* 4 octets - flags
* 4 octets - child_offset (JObj)
* 4 octets - next_offset (JObj)
* 4 octets - dobj_offset (DObj)
* 4 octets [3] - float3 - rotation_xyz
* 4 octets [3] - float3 - scale_xyz
* 4 octets [3] - float3 - translation_xyz
* 4 octets - inverse_world_transform_offset (inverse world transform = Matrice de 4x3)
* 4 octets - robj_offset

Pointé par les listes dans Root Node scene_data.

* '''JObjFlagsEnum''' : (peuvent se cumuler)
** NULL = 00 00 00 00
** SKELETON = 00 00 00 01
** SKELETON_ROOT = 00 00 00 02
** ENVELOPE_MODEL = 00 00 00 04
** CLASSICAL_SCALING = 00 00 00 08
** HIDDEN = 00 00 00 10
** PTCL = 00 00 00 20
** MTX_DIRTY = 00 00 00 40
** LIGHTING = 00 00 00 80
** TEXGEN = 00 00 01 00
** BILLBOARD = 00 00 02 00
** VBILLBOARD = 00 00 04 00
** HBILLBOARD = 00 00 06 00
** RBILLBOARD = 00 00 08 00
** INSTANCE = 00 00 10 00
** PBILLBOARD = 00 00 20 00
** SPLINE = 00 00 40 00
** FLIP_IK = 00 00 80 00
** SPECULAR = 00 01 00 00
** USE_QUATERNION = 00 02 00 00
** OPA = 00 04 00 00
** XLU = 00 08 00 00
** TEXEDGE = 00 10 00 00
** JOINT1 = 00 20 00 00
** JOINT2 = 00 40 00 00
** EFFECTOR = 00 60 00 00
** USER_DEFINED_MTX = 00 80 00 00
** MTX_INDEPEND_PARENT = 01 00 00 00
** MTX_INDEPEND_SRT = 02 00 00 00
** MTX_SCALE_COMPENSATE = 04 00 00 00
** ROOT_OPA = 10 00 00 00
** ROOT_XLU = 20 00 00 00
** ROOT_TEXEDGE = 40 00 00 00

=== '''InverseWorldTransform''' : (0x30 octets) ===
* 4 octets - float - M11
* 4 octets - float - M12
* 4 octets - float - M13
* 4 octets - float - M14
* 4 octets - float - M21
* 4 octets - float - M22
* 4 octets - float - M23
* 4 octets - float - M24
* 4 octets - float - M31
* 4 octets - float - M32
* 4 octets - float - M33
* 4 octets - float - M34

=== '''DObj''' : (0x10 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - prochain DOBJ
* 4 octets - mobj_offset - material offset
* 4 octets - pobj_offset - mesh offset
Liste chaînée qui permet de récupérer l'ensemble des materials & mesh pour le JObj auquel il est lié.

=== '''MObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - render_flags - RenderFlagsEnum
* 4 octets - tobj_offset - offset de texture - peut être invalide s'il n'y a pas de texture pour le material
* 4 octets - material_offset - couleurs des materials ?
* 8 octets - PEDesc ?

Contient les textures & informations sur les couleurs des Materials.

* '''RenderFlagsEnum''' : (se cumulent)
** USER = 80 00 00 00
** CONSTANT = 00 00 00 01
** VERTEX = 00 00 00 02
** BOTH = 00 00 00 03
** DIFFUSE = 00 00 00 04
** SPECULAR = 00 00 00 08
** TEX0 = 00 00 00 10
** TEX1 = 00 00 00 20
** TEX2 = 00 00 00 40
** TEX3 = 00 00 00 80
** TEX4 = 00 00 01 00
** TEX5 = 00 00 02 00
** TEX6 = 00 00 04 00
** TEX7 = 00 00 08 00
** TOON = 00 00 10 00
** ALPHA_MAT = 00 00 20 00
** ALPHA_VTX = 00 00 40 00
** ALPHA_BOTH = 00 00 60 00
** ZOFST = 01 00 00 00
** EFFECT = 02 00 00 00
** SHADOW = 04 00 00 00
** ZMODE_ALWAYS = 08 00 00 00
** DF_ALL = 10 00 00 00
** NO_ZUPDATE = 20 00 00 00
** XLU = 40 00 00 00

=== '''TObj''' : (0x5c octets) ===
* 4 octets - ?
* 4 octets - ?
* 4 octets - tex_map_id - TexMapIdEnum
* 4 octets - gx_tex_gen_src - GXTexGenSrcEnum
* 4 octets - float - rx
* 4 octets - float - ry
* 4 octets - float - rz
* 4 octets - float - sx
* 4 octets - float - sy
* 4 octets - float - sz
* 4 octets - float - tx
* 4 octets - float - ty
* 4 octets - float - tz
* 4 octets - wrap_s - WrapEnum
* 4 octets - wrap_t - WrapEnum
* 1 octet - w_scale
* 1 octet - h_scale
* 2 octets - ?
* 1 octets - bump_map - (False = 00 ; True = 01)
* 4 bits - alpha_operation - AlphaOperationEnum
* 4 bits - color_operation - ColorOperationEnum
* 1 octet - shadow_lightmap - (False = 00 ; True = 01) (2 octets avec une Enum lightmap limite)
* 1 bit - ext_lightmap - (False = 0 ; True = 1)
* 1 bit - ambiant_lightmap - (False = 0 ; True = 1)
* 1 bit - specular_lightmap - (False = 0 ; True = 1)
* 1 bit - diffuse_lightmap (False = 0 ; True = 1)
* 4 bits - coord_type - CoordTypeEnum
* 4 octets - float - blending - utilisé quand color_operation ou alpha_operation == BLEND
* 4 octets - mag_filter - MagFilterEnum
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
Informations de Textures. Le TObj contient des informations sur les paramètres d'environnement de textures utilisés pour le rendu graphique ainsi que les offset de l'image et des données de la palette utilisés pour cette texture. Le plus important ici, c'est l'offset d'image et la palette/tlut - si l'image n'est pas indexée (RGBA, CMPR, etc.) alors la structure de description palette/tlut n'est pas utilisée.

* '''TexMapIdEnum''' :
** GX_TEXMAP0 = 00 00 00 00
** GX_TEXMAP1 = 00 00 00 01
** GX_TEXMAP2 = 00 00 00 02
** GX_TEXMAP3 = 00 00 00 03
** GX_TEXMAP4 = 00 00 00 04
** GX_TEXMAP5 = 00 00 00 05
** GX_TEXMAP6 = 00 00 00 06
** GX_TEXMAP7 = 00 00 00 07
** GX_MAX_TEXMAP = 00 00 00 08
** GX_TEXMAP_NULL = 00 00 00 09
** GX_TEXMAP_DISABLE = 00 00 00 0A

* '''GXTexGenSrcEnum''' :
** GX_TG_POS = 00 00 00 00
** GX_TG_NRM = 00 00 00 01
** GX_TG_BINRM = 00 00 00 02
** GX_TG_TANGENT = 00 00 00 03
** GX_TG_TEX0 = 00 00 00 04
** GX_TG_TEX1 = 00 00 00 05
** GX_TG_TEX2 = 00 00 00 06
** GX_TG_TEX3 = 00 00 00 07
** GX_TG_TEX4 = 00 00 00 08
** GX_TG_TEX5 = 00 00 00 09
** GX_TG_TEX6 = 00 00 00 0A
** GX_TG_TEX7 = 00 00 00 0B
** GX_TG_TEXCOORD0 = 00 00 00 0C
** GX_TG_TEXCOORD1 = 00 00 00 0D
** GX_TG_TEXCOORD2 = 00 00 00 0E
** GX_TG_TEXCOORD3 = 00 00 00 0F
** GX_TG_TEXCOORD4 = 00 00 00 10
** GX_TG_TEXCOORD5 = 00 00 00 11
** GX_TG_TEXCOORD6 = 00 00 00 12
** GX_TG_COLOR0 = 00 00 00 13
** GX_TG_COLOR1 = 00 00 00 14

* '''AlphaOperationEnum''':
** NONE = 0X
** ALPHAMASK = 1X
** BLEND = 2X
** MODULATE = 3X
** REPLACE = 4X
** PASS = 5X
** ADD = 6X
** SUB = 7X

* '''ColorOperationEnum''':
** NONE = X0
** ALPHA_MASK = X1
** RGB_MASK = X2
** BLEND = X3
** MODULATE = X4
** REPLACE = X5
** PASS = X6
** ADD = X7
** SUB = X8

* '''CoordTypeEnum''':
** UV = X0
** REFLECTION = X1
** HILIGHT = X2
** SHADOW = X3
** TOON = X4
** GRADATION = X5

* '''MagFilterEnum''':
** GX_NEAR = 00 00 00 00
** GX_LINEAR = 00 00 00 01
** GX_NEAR_MIP_NEAR = 00 00 00 02
** GX_LIN_MIP_NEAR = 00 00 00 03
** GX_NEAR_MIP_LIN = 00 00 00 04
** GX_LIN_MIP_LIN = 00 00 00 05

* '''WrapEnum''':
** CLAMP = 00 00 00 00
** REPEAT = 00 00 00 01
** MIRROR = 00 00 00 02

=== '''Material''' : (0x14 octets) ===
* 1 octets - AMB_R - (ambient)
* 1 octets - AMB_G
* 1 octets - AMB_B
* 1 octets - AMB_A
* 1 octets - DIF_R - (diffuse)
* 1 octets - DIF_G
* 1 octets - DIF_B
* 1 octets - DIF_A
* 1 octets - SPC_R - (specular)
* 1 octets - SPC_G
* 1 octets - SPC_B
* 1 octets - SPC_A
* 4 octets - float - alpha
* 4 octets - float - shininess

=== '''PObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - pobj
* 4 octets - vertex_attr_list_offset
* 2 octets - Flags - PObjFlagsEnum
* 2 octets - display_list_size - number of 0x20 (32) byte blocks occupied by display list data
* 4 octets - display_list_offset
* 4 octets - weight_list_offset - ? verifier qu'on retrouve bien le tableau d'envelope_weights à cet offset

Comme l'indique next_offset, il s'agit d'une liste de meshs à afficher pour un material donné référencé par un dobj. PObj contient les offsets de vertex attributes / display list / joint weight list ce qui suffit et permet d’interpréter et traiter les coordonnées de vertices, normals & textures.

Les attributs vertex sont les plus important - les parametres specifiés contrôlent tout : du format, de la taille des données de chaque vertex, normal et coordonnées de textures et comment ces valeurs sont dimensionnées (scaled) par rapport à la présence et la taille de chaque valeur d'index qui apparaît dans la display list information.

* '''PObjFlagsEnum''' :
** Inconnu0 = 00 01
** Inconnu1 = 00 02
** ANIM = 00 08
** SHAPE_ANIM = 10 00
** ENVELOPE = 20 00
** CULLBACK = 40 00
** CULLFRONT = 80 00

=== EnvelopeWeights : (0x? octets) ===
* 4 octets - envelope_count
* [envelope_count]:
** 4 octets - float - weight
** 4 octets - pad ?
* 4 octets - jobj_list_offset

=== not verified yet ===

* '''IMAGE_HEADER''' :
** 4 octets - image_offset - image data
** 2 octets - width
** 2 octets - height
** 4 octets - image_format

* '''PALETTE_HEADER''' : (0x10)
** 4 octets - palette_offset - palette data
** 4 octets - palette_format
** 4 octets - Inconnu
** 2 octets - color_count
** 2 octets - Inconnu

image_offset et palette_offset sont souvent partagés par plusieurs textures - savoir ça permet de retrouver toutes les informations sur les images des textures (largeur, hauteur, format), ainsi que le format et le nombre de couleurs de la palette/tlut.

Le format d'image ne détermine pas le nombre total de couleurs de la palette qu'elle utilisent. Par exemple, une image indexée sur 8 bits aurait un maximum de 256 couleurs mais seulement 136 ou 221 couleurs sont actuellement utilisées. De la sorte, la palette n'utilisera pas la taille totale qu'elle devrait utiliser.

Les images suivent la structure généralement utilisée par la GameCube :

IMAGE FORMATS :
* case 0: //i4
* case 1: //i8
* case 2: //i4a4
* case 3: //i8a8
* case 4: //r5g6b5
* case 5: //rgb5a3
* case 6: //r8g8b8a8
* case 8: //index4
* case 9: //index8
* case 0xa: //index14x2
* case 0xe: //s3tc1

Les formats indexés utilisent aussi les informations de palettes/tlut et les données peuvent apparaître en plusieurs formats :

PALETTE FORMATS :
* case 0: //ia8
* case 1: //r5g6b5
* case 2: //rgb5a3

---> "Joint Data - Accessing Geometry, Mesh, and Vertex Attributes" https://smashboards.com/threads/melee-dat-format.292603/

trad a revoir à partir de là, il faut investiguer le rendu 3D sur GameCube pour mieux comprendre

// déclaration d'un vertex et attribute information
// attr, type, cnt, data_type, flags?, file_offset
* ATTR_DATA
** 4 octets - GXAttr vtx_attr_offset - attr
** 4 octets - GXAttrType vtx_attr_type - index_type
** 4 octets - GXCompCnt comp_cnt - cnt
** 4 octets - GXCompType comp_type - data_type
** 1 octets - scale
** 1 octets - Inconnu
** 2 octets - vtx_stride
** 2 octets - data_offset

vertex_attr_offset pointe sur une liste d'attributs de vertex. Leur nombre n'est pas donné. Les données dans cette structure suivent les informations et les types conçus par l'architecture GameCube/WII et son API. La liste est terminée par une valeur spécifique de vtx_attr qui signale la fin de cette liste. Avec un accès à la doku SDK, il serait fortement conseillé de lire la section à propos des "vertex attributes and other specifications".

La valeur de vtx_attr determine le type de donnée que cet attribut désigne et peut indiquer un nombre de types natifs utilisés utilisés pour passer les données entre les interfaces logicielles et matérielles.

Les valeures possibles sont les suivantes :
* enum GXAttr (4 octets)
** GX_VA_PNMTXIDX = 0, // position/normal matrix index
** GX_VA_TEX0MTXIDX, // texture 0 matrix index
** GX_VA_TEX1MTXIDX, // texture 1 matrix index
** GX_VA_TEX2MTXIDX, // texture 2 matrix index
** GX_VA_TEX3MTXIDX, // texture 3 matrix index
** GX_VA_TEX4MTXIDX, // texture 4 matrix index
** GX_VA_TEX5MTXIDX, // texture 5 matrix index
** GX_VA_TEX6MTXIDX, // texture 6 matrix index
** GX_VA_TEX7MTXIDX, // texture 7 matrix index
** GX_VA_POS = 9, // position
** GX_VA_NRM, // normal
** GX_VA_CLR0, // color 0
** GX_VA_CLR1, // color 1
** GX_VA_TEX0, // input texture coordinate 0
** GX_VA_TEX1, // input texture coordinate 1
** GX_VA_TEX2, // input texture coordinate 2
** GX_VA_TEX3, // input texture coordinate 3
** GX_VA_TEX4, // input texture coordinate 4
** GX_VA_TEX5, // input texture coordinate 5
** GX_VA_TEX6, // input texture coordinate 6
** GX_VA_TEX7, // input texture coordinate 7

** GX_POS_MTX_ARRAY, // position matrix array pointer
** GX_NRM_MTX_ARRAY, // normal matrix array pointer
** GX_TEX_MTX_ARRAY, // texture matrix array pointer
** GX_LIGHT_ARRAY, // light parameter array pointer
** GX_VA_NBT, // normal, bi-normal, tangent
** GX_VA_MAX_ATTR, // maximum number of vertex attributes

** GX_VA_NULL = 0xff // NULL attribute (to mark end of lists)

Toutes les données nécessaires pour représenter un mesh peuvent être spécifiées et indexées d'une manière ou d'une autre. De même, GX_VA_TEX0MTXIDX, GX_VA_CLR0, et autres sont aussi possibles - les valeurs les plus fréquentes dans les données SSBM sont : GX_VA_PNMTXIDX, GX_VA_POS, GX_VA_NRM, et GX_VA_TEX0. Which is to be expected as joint matrices, vertex positions/normals, and texture coordinates respectively are probably the most basic of elements needed to display a texture mesh, whether static or animated.

When the value of vtx_attr == GX_VA_NULL (0xFF), the end of the vertex attribute array has been reached.

The vtx_attr_type values is actually associated with how the value is indexed, and can thus also determine the size of the index value within the display list data.

* 4 octets - enum GXAttrType
** GX_NONE = 0,
** GX_DIRECT,
** GX_INDEX8,
** GX_INDEX16

* Structures COLL_DATA : (données de collisions)
** 4 octets - vertex_offset (2 float par entrée correspondant à des données 2D probablement)
** 4 octets - vertex_count
** 4 octets - index_offset
** 4 octets - index_count
** 4 octets [5] - tableau inconnu
*** 2 octets - index_start
*** 2 octets - index_count
** 4 octets - Inconnu
** 4 octets - Inconnu

[[Category:Implementations]]
[[Category:Gotcha Force]]

Models

2023-10-07T13:34:45Z

Algoflash: /* Gotcha Force Models */

[[Gotcha Force | ← Gotcha Force]]

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

== Gotcha Force Models ==

Gotcha Force models work as those from the game Super Smash Bros Melee (SSBM) investigated by its [https://smashboards.com/threads/melee-dat-format.292603/ community].

A model is a file format that organizes objects and resources serialized to be used by the '''H'''al '''S'''ys'''D'''olphin ('''HSD''') library. The HSD library is used in several Capcom games.

Ce sont des ressources graphiques structurées de manière hiérarchique. La présence de certaines images dans les modèles montrent à priori l'utilisation de la technique [https://learn.foundry.com/modo/901/content/help/pages/shading_lighting/shader_items/matcap.html matcap].
Par ailleurs, la librairie prendrait ses sources sur le SDK Dolphin, tel que GX ou encore MTX.

=== Fichiers concernés ===
L'ensemble des fichiers ayant dans leur titre '''_mdl''' sont des fichiers modèles correspondant au format décrit dans cette page. On notera les fichiers [[ARZ (Gotcha Force)|.arz]] qui sont des modèles compressés. Le fichier collision.arc et les fichiers tdc00.arc à tdc09.arc sont aussi des modèles.

Les fichiers modèles se retrouvent aussi dans les pzz des borgs (plxxxx.pzz) en position 004 à 009.

=== HSDRaw ===
HSDRaw, un éditeur 3D dotnet de ce format est instable sur mon Windows (algoflash). Il est cependant prouvé qu'un edit des _mdl pour commencer à l'offset 0x100 - après le préambule - permet de visualiser le fichier sur HSDRaw et d'avoir le rendu 3D du Borg (click sur le premier dossier JOBJ - puis le JOBJ dedans et double click sur le nœud en violet). Cela devrait aussi permettre d'éditer certaines propriétés ?

== Structure générale ==
Le format des modèles se découpe en plusieurs blocks. Le préambule fait 0x100 octets au tout début du fichier. Il est souvent absent. Toutes les valeurs sont en unsigned big endian, et le pad est en Nulls bytes (\x00). Les offsets trouvés après le début du Data Block (DB) sont relatifs au début du DB. La table de relocs est un tableau d'offsets de 4 octets (relatif au DB) permettant de traduire en adressage absolu les offsets des structures lors du chargement mémoire. La table de reloc permet par exemple de délimiter les structures du fait qu'il est peu probable qu'un offset pointe au milieu d'une structure.

L'ensemble des fichiers répondant à ce format on un seul root_node de type SObj (Scene data).

=== '''Préambule''' : (0x100 octets / 0 octets) ===
* 4 octets - hsd_header_offset=0x100 (toujours)
* 4 octets - bones_flags_table_offset=0x20 (toujours) - offset de la liste des flags des armatures
* 4 octets - bones_table_offset=0xC0 (toujours) - offset de la liste des armatures
* 20 octets - Pad - (toujours)
* 4 octets [32] - Inconnu (flags des armatures ?) 1 octet par flag ?
* 32 octets - Pad - (toujours)
* 32 octets - armatures ?
* 32 octets - Pad - (toujours)
=== '''HSD Header''' - (0x20 octets) ===
* 4 octets - Taille totale du fichier
* 4 octets - Taille du Data block
* 4 octets - Nombre d'entrée dans la Table de relocs
* 4 octets - root0_count
* 4 octets - root1_count
* 12 octets - Pad - (toujours)
=== '''Data block''' : ===
* JOBJ, etc. -> Ces structures sont détaillée plus loin ci-dessous.
=== '''Relocation Table''' : ===
* Tableau d'offsets de 4 octets - Offsets des structures dans le DB.
=== '''Root Nodes (2)''' : ===
* Tableau de taille 8 * root0_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
* Tableau de taille 8 * root1_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
=== '''String Table''' : ===
* Suite de strings terminées par Null au nombre de root0_count + root1_count

== Structures rencontrées dans le DB ==
Note : l'arborescence est cumulative sur les transformations pour les relations parents->enfants

Les Noeuds Racine qui ont pour nom "scene_data" pointent sur un SObj :
=== '''SObj''' : (0x10 octets) ===
* 4 octets - JObjDescs_offsets_list_offset
* 4 octets - Cameras_list_offset
* 4 octets - Lights_list_offset
* 4 octets - Fog

"scene_data" == nom du nœud racine
JObjDescs_offsets_list_offset, cameras.. pointent sur une liste d'offsets terminée par 4 octets à 0x00.
lights_list_offset pointe sur des couples (4 octets - LObj_offset ; 4 octets - light_anim_pointer_offset)

=== '''JObjDesc''' : (0x10 octets) ===
* 4 octets - root_joint_offset - JObj
* 4 octets - joint_animations_offset - ?
* 4 octets - material_animations_offset - ?
* 4 octets - shape_animations_offset - ?

=== '''CObj''' : (0x38 octets) ===
* 4 octets - flags
* 4 octets - projection_type - ProjectionTypeEnum
* 2 octets - viewport_left
* 2 octets - viewport_right
* 2 octets - viewport_top
* 2 octets - viewport_bottom
* 4 octets - proj_width
* 4 octets - proj_height
* 4 octets - eye_offset - WObj
* 4 octets - target_offset - WObj
* 4 octets - roll
* 4 octets - Inconnu
* 4 octets - float - near_clip
* 4 octets - float - far_clip
* 4 octets - float - field_of_view
* 4 octets - float - aspect
Camera object. Note : pour frustrum ou ortho, la structure est différente.

* '''ProjectionTypeEnum''':
** PERSPECTIVE = 1
** FRUSTRUM = 2
** ORTHO = 3

=== '''WObj''': (0x14 octets) ===
* 4 octets - Inconnu
* 4 octets - float - v1
* 4 octets - float - v2
* 4 octets - float - v3
* 4 octets - Inconnu

eye / target

=== '''LObj''' : (0x1c octets) ===
* 4 octets - class_name
* 4 octets - next_offset
* 2 octets - flags - LObjFlagsEnum
* 2 octets - attenuation_flags - LObjAttenuationFlagsEnum
* 1 octet - color_r
* 1 octet - color_g
* 1 octet - color_b
* 1 octet - color_alpha
* 4 octets - lobj_point_offset - position
* 4 octets - infinite_data
* 4 octets - point_spot_data
light

* '''LObjFlagsEnum''' :
** LOBJ_AMBIANT = 00 00
** LOBJ_INFINITE = 00 01
** LOBJ_POINT = 00 02
** LOBJ_SPOT = 00 03
** LOBJ_DIFFUSE = 00 04
** LOBJ_SPECULAR = 00 08
** LOBJ_ALPHA = 00 10
** LOBJ_HIDDEN = 00 20
** LOBJ_RAW_PARAM = 00 40
** LOBJ_DIFF_DIRTY = 00 80
** LOBJ_SPEC_DIRTY = 01 00

* '''LObjAttenuationFlagsEnum''' :
** LOBJ_LIGHT_ATTN_NONE = 00 00
** LOBJ_LIGHT_ATTN = 00 01

=== '''LObjPoint''' : (0x14 octets) ===
* 4 octets - class_name
* 4 octets - float - x
* 4 octets - float - y
* 4 octets - float - z
* 4 octets - Inconnu

=== '''LightAnimPointer''' : (0x10 octets) ===
** 4 octets - next_offset - (LightAnimPointer)
** 4 octets - light_anim - ?
** 4 octets - position_anim - ?
** 4 octets - interst_anim - ?
Bugs dans HSDRaw - à tester

=== '''JObj''' : (0x40 octets) ===
* 4 octets - Inconnu
* 4 octets - flags
* 4 octets - child_offset (JObj)
* 4 octets - next_offset (JObj)
* 4 octets - dobj_offset (DObj)
* 4 octets [3] - float3 - rotation_xyz
* 4 octets [3] - float3 - scale_xyz
* 4 octets [3] - float3 - translation_xyz
* 4 octets - inverse_world_transform_offset (inverse world transform = Matrice de 4x3)
* 4 octets - robj_offset

Pointé par les listes dans Root Node scene_data.

* '''JObjFlagsEnum''' : (peuvent se cumuler)
** NULL = 00 00 00 00
** SKELETON = 00 00 00 01
** SKELETON_ROOT = 00 00 00 02
** ENVELOPE_MODEL = 00 00 00 04
** CLASSICAL_SCALING = 00 00 00 08
** HIDDEN = 00 00 00 10
** PTCL = 00 00 00 20
** MTX_DIRTY = 00 00 00 40
** LIGHTING = 00 00 00 80
** TEXGEN = 00 00 01 00
** BILLBOARD = 00 00 02 00
** VBILLBOARD = 00 00 04 00
** HBILLBOARD = 00 00 06 00
** RBILLBOARD = 00 00 08 00
** INSTANCE = 00 00 10 00
** PBILLBOARD = 00 00 20 00
** SPLINE = 00 00 40 00
** FLIP_IK = 00 00 80 00
** SPECULAR = 00 01 00 00
** USE_QUATERNION = 00 02 00 00
** OPA = 00 04 00 00
** XLU = 00 08 00 00
** TEXEDGE = 00 10 00 00
** JOINT1 = 00 20 00 00
** JOINT2 = 00 40 00 00
** EFFECTOR = 00 60 00 00
** USER_DEFINED_MTX = 00 80 00 00
** MTX_INDEPEND_PARENT = 01 00 00 00
** MTX_INDEPEND_SRT = 02 00 00 00
** MTX_SCALE_COMPENSATE = 04 00 00 00
** ROOT_OPA = 10 00 00 00
** ROOT_XLU = 20 00 00 00
** ROOT_TEXEDGE = 40 00 00 00

=== '''InverseWorldTransform''' : (0x30 octets) ===
* 4 octets - float - M11
* 4 octets - float - M12
* 4 octets - float - M13
* 4 octets - float - M14
* 4 octets - float - M21
* 4 octets - float - M22
* 4 octets - float - M23
* 4 octets - float - M24
* 4 octets - float - M31
* 4 octets - float - M32
* 4 octets - float - M33
* 4 octets - float - M34

=== '''DObj''' : (0x10 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - prochain DOBJ
* 4 octets - mobj_offset - material offset
* 4 octets - pobj_offset - mesh offset
Liste chaînée qui permet de récupérer l'ensemble des materials & mesh pour le JObj auquel il est lié.

=== '''MObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - render_flags - RenderFlagsEnum
* 4 octets - tobj_offset - offset de texture - peut être invalide s'il n'y a pas de texture pour le material
* 4 octets - material_offset - couleurs des materials ?
* 8 octets - PEDesc ?

Contient les textures & informations sur les couleurs des Materials.

* '''RenderFlagsEnum''' : (se cumulent)
** USER = 80 00 00 00
** CONSTANT = 00 00 00 01
** VERTEX = 00 00 00 02
** BOTH = 00 00 00 03
** DIFFUSE = 00 00 00 04
** SPECULAR = 00 00 00 08
** TEX0 = 00 00 00 10
** TEX1 = 00 00 00 20
** TEX2 = 00 00 00 40
** TEX3 = 00 00 00 80
** TEX4 = 00 00 01 00
** TEX5 = 00 00 02 00
** TEX6 = 00 00 04 00
** TEX7 = 00 00 08 00
** TOON = 00 00 10 00
** ALPHA_MAT = 00 00 20 00
** ALPHA_VTX = 00 00 40 00
** ALPHA_BOTH = 00 00 60 00
** ZOFST = 01 00 00 00
** EFFECT = 02 00 00 00
** SHADOW = 04 00 00 00
** ZMODE_ALWAYS = 08 00 00 00
** DF_ALL = 10 00 00 00
** NO_ZUPDATE = 20 00 00 00
** XLU = 40 00 00 00

=== '''TObj''' : (0x5c octets) ===
* 4 octets - ?
* 4 octets - ?
* 4 octets - tex_map_id - TexMapIdEnum
* 4 octets - gx_tex_gen_src - GXTexGenSrcEnum
* 4 octets - float - rx
* 4 octets - float - ry
* 4 octets - float - rz
* 4 octets - float - sx
* 4 octets - float - sy
* 4 octets - float - sz
* 4 octets - float - tx
* 4 octets - float - ty
* 4 octets - float - tz
* 4 octets - wrap_s - WrapEnum
* 4 octets - wrap_t - WrapEnum
* 1 octet - w_scale
* 1 octet - h_scale
* 2 octets - ?
* 1 octets - bump_map - (False = 00 ; True = 01)
* 4 bits - alpha_operation - AlphaOperationEnum
* 4 bits - color_operation - ColorOperationEnum
* 1 octet - shadow_lightmap - (False = 00 ; True = 01) (2 octets avec une Enum lightmap limite)
* 1 bit - ext_lightmap - (False = 0 ; True = 1)
* 1 bit - ambiant_lightmap - (False = 0 ; True = 1)
* 1 bit - specular_lightmap - (False = 0 ; True = 1)
* 1 bit - diffuse_lightmap (False = 0 ; True = 1)
* 4 bits - coord_type - CoordTypeEnum
* 4 octets - float - blending - utilisé quand color_operation ou alpha_operation == BLEND
* 4 octets - mag_filter - MagFilterEnum
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
Informations de Textures. Le TObj contient des informations sur les paramètres d'environnement de textures utilisés pour le rendu graphique ainsi que les offset de l'image et des données de la palette utilisés pour cette texture. Le plus important ici, c'est l'offset d'image et la palette/tlut - si l'image n'est pas indexée (RGBA, CMPR, etc.) alors la structure de description palette/tlut n'est pas utilisée.

* '''TexMapIdEnum''' :
** GX_TEXMAP0 = 00 00 00 00
** GX_TEXMAP1 = 00 00 00 01
** GX_TEXMAP2 = 00 00 00 02
** GX_TEXMAP3 = 00 00 00 03
** GX_TEXMAP4 = 00 00 00 04
** GX_TEXMAP5 = 00 00 00 05
** GX_TEXMAP6 = 00 00 00 06
** GX_TEXMAP7 = 00 00 00 07
** GX_MAX_TEXMAP = 00 00 00 08
** GX_TEXMAP_NULL = 00 00 00 09
** GX_TEXMAP_DISABLE = 00 00 00 0A

* '''GXTexGenSrcEnum''' :
** GX_TG_POS = 00 00 00 00
** GX_TG_NRM = 00 00 00 01
** GX_TG_BINRM = 00 00 00 02
** GX_TG_TANGENT = 00 00 00 03
** GX_TG_TEX0 = 00 00 00 04
** GX_TG_TEX1 = 00 00 00 05
** GX_TG_TEX2 = 00 00 00 06
** GX_TG_TEX3 = 00 00 00 07
** GX_TG_TEX4 = 00 00 00 08
** GX_TG_TEX5 = 00 00 00 09
** GX_TG_TEX6 = 00 00 00 0A
** GX_TG_TEX7 = 00 00 00 0B
** GX_TG_TEXCOORD0 = 00 00 00 0C
** GX_TG_TEXCOORD1 = 00 00 00 0D
** GX_TG_TEXCOORD2 = 00 00 00 0E
** GX_TG_TEXCOORD3 = 00 00 00 0F
** GX_TG_TEXCOORD4 = 00 00 00 10
** GX_TG_TEXCOORD5 = 00 00 00 11
** GX_TG_TEXCOORD6 = 00 00 00 12
** GX_TG_COLOR0 = 00 00 00 13
** GX_TG_COLOR1 = 00 00 00 14

* '''AlphaOperationEnum''':
** NONE = 0X
** ALPHAMASK = 1X
** BLEND = 2X
** MODULATE = 3X
** REPLACE = 4X
** PASS = 5X
** ADD = 6X
** SUB = 7X

* '''ColorOperationEnum''':
** NONE = X0
** ALPHA_MASK = X1
** RGB_MASK = X2
** BLEND = X3
** MODULATE = X4
** REPLACE = X5
** PASS = X6
** ADD = X7
** SUB = X8

* '''CoordTypeEnum''':
** UV = X0
** REFLECTION = X1
** HILIGHT = X2
** SHADOW = X3
** TOON = X4
** GRADATION = X5

* '''MagFilterEnum''':
** GX_NEAR = 00 00 00 00
** GX_LINEAR = 00 00 00 01
** GX_NEAR_MIP_NEAR = 00 00 00 02
** GX_LIN_MIP_NEAR = 00 00 00 03
** GX_NEAR_MIP_LIN = 00 00 00 04
** GX_LIN_MIP_LIN = 00 00 00 05

* '''WrapEnum''':
** CLAMP = 00 00 00 00
** REPEAT = 00 00 00 01
** MIRROR = 00 00 00 02

=== '''Material''' : (0x14 octets) ===
* 1 octets - AMB_R - (ambient)
* 1 octets - AMB_G
* 1 octets - AMB_B
* 1 octets - AMB_A
* 1 octets - DIF_R - (diffuse)
* 1 octets - DIF_G
* 1 octets - DIF_B
* 1 octets - DIF_A
* 1 octets - SPC_R - (specular)
* 1 octets - SPC_G
* 1 octets - SPC_B
* 1 octets - SPC_A
* 4 octets - float - alpha
* 4 octets - float - shininess

=== '''PObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - pobj
* 4 octets - vertex_attr_list_offset
* 2 octets - Flags - PObjFlagsEnum
* 2 octets - display_list_size - number of 0x20 (32) byte blocks occupied by display list data
* 4 octets - display_list_offset
* 4 octets - weight_list_offset - ? verifier qu'on retrouve bien le tableau d'envelope_weights à cet offset

Comme l'indique next_offset, il s'agit d'une liste de meshs à afficher pour un material donné référencé par un dobj. PObj contient les offsets de vertex attributes / display list / joint weight list ce qui suffit et permet d’interpréter et traiter les coordonnées de vertices, normals & textures.

Les attributs vertex sont les plus important - les parametres specifiés contrôlent tout : du format, de la taille des données de chaque vertex, normal et coordonnées de textures et comment ces valeurs sont dimensionnées (scaled) par rapport à la présence et la taille de chaque valeur d'index qui apparaît dans la display list information.

* '''PObjFlagsEnum''' :
** Inconnu0 = 00 01
** Inconnu1 = 00 02
** ANIM = 00 08
** SHAPE_ANIM = 10 00
** ENVELOPE = 20 00
** CULLBACK = 40 00
** CULLFRONT = 80 00

=== EnvelopeWeights : (0x? octets) ===
* 4 octets - envelope_count
* [envelope_count]:
** 4 octets - float - weight
** 4 octets - pad ?
* 4 octets - jobj_list_offset

=== not verified yet ===

* '''IMAGE_HEADER''' :
** 4 octets - image_offset - image data
** 2 octets - width
** 2 octets - height
** 4 octets - image_format

* '''PALETTE_HEADER''' : (0x10)
** 4 octets - palette_offset - palette data
** 4 octets - palette_format
** 4 octets - Inconnu
** 2 octets - color_count
** 2 octets - Inconnu

image_offset et palette_offset sont souvent partagés par plusieurs textures - savoir ça permet de retrouver toutes les informations sur les images des textures (largeur, hauteur, format), ainsi que le format et le nombre de couleurs de la palette/tlut.

Le format d'image ne détermine pas le nombre total de couleurs de la palette qu'elle utilisent. Par exemple, une image indexée sur 8 bits aurait un maximum de 256 couleurs mais seulement 136 ou 221 couleurs sont actuellement utilisées. De la sorte, la palette n'utilisera pas la taille totale qu'elle devrait utiliser.

Les images suivent la structure généralement utilisée par la GameCube :

IMAGE FORMATS :
* case 0: //i4
* case 1: //i8
* case 2: //i4a4
* case 3: //i8a8
* case 4: //r5g6b5
* case 5: //rgb5a3
* case 6: //r8g8b8a8
* case 8: //index4
* case 9: //index8
* case 0xa: //index14x2
* case 0xe: //s3tc1

Les formats indexés utilisent aussi les informations de palettes/tlut et les données peuvent apparaître en plusieurs formats :

PALETTE FORMATS :
* case 0: //ia8
* case 1: //r5g6b5
* case 2: //rgb5a3

---> "Joint Data - Accessing Geometry, Mesh, and Vertex Attributes" https://smashboards.com/threads/melee-dat-format.292603/

trad a revoir à partir de là, il faut investiguer le rendu 3D sur GameCube pour mieux comprendre

// déclaration d'un vertex et attribute information
// attr, type, cnt, data_type, flags?, file_offset
* ATTR_DATA
** 4 octets - GXAttr vtx_attr_offset - attr
** 4 octets - GXAttrType vtx_attr_type - index_type
** 4 octets - GXCompCnt comp_cnt - cnt
** 4 octets - GXCompType comp_type - data_type
** 1 octets - scale
** 1 octets - Inconnu
** 2 octets - vtx_stride
** 2 octets - data_offset

vertex_attr_offset pointe sur une liste d'attributs de vertex. Leur nombre n'est pas donné. Les données dans cette structure suivent les informations et les types conçus par l'architecture GameCube/WII et son API. La liste est terminée par une valeur spécifique de vtx_attr qui signale la fin de cette liste. Avec un accès à la doku SDK, il serait fortement conseillé de lire la section à propos des "vertex attributes and other specifications".

La valeur de vtx_attr determine le type de donnée que cet attribut désigne et peut indiquer un nombre de types natifs utilisés utilisés pour passer les données entre les interfaces logicielles et matérielles.

Les valeures possibles sont les suivantes :
* enum GXAttr (4 octets)
** GX_VA_PNMTXIDX = 0, // position/normal matrix index
** GX_VA_TEX0MTXIDX, // texture 0 matrix index
** GX_VA_TEX1MTXIDX, // texture 1 matrix index
** GX_VA_TEX2MTXIDX, // texture 2 matrix index
** GX_VA_TEX3MTXIDX, // texture 3 matrix index
** GX_VA_TEX4MTXIDX, // texture 4 matrix index
** GX_VA_TEX5MTXIDX, // texture 5 matrix index
** GX_VA_TEX6MTXIDX, // texture 6 matrix index
** GX_VA_TEX7MTXIDX, // texture 7 matrix index
** GX_VA_POS = 9, // position
** GX_VA_NRM, // normal
** GX_VA_CLR0, // color 0
** GX_VA_CLR1, // color 1
** GX_VA_TEX0, // input texture coordinate 0
** GX_VA_TEX1, // input texture coordinate 1
** GX_VA_TEX2, // input texture coordinate 2
** GX_VA_TEX3, // input texture coordinate 3
** GX_VA_TEX4, // input texture coordinate 4
** GX_VA_TEX5, // input texture coordinate 5
** GX_VA_TEX6, // input texture coordinate 6
** GX_VA_TEX7, // input texture coordinate 7

** GX_POS_MTX_ARRAY, // position matrix array pointer
** GX_NRM_MTX_ARRAY, // normal matrix array pointer
** GX_TEX_MTX_ARRAY, // texture matrix array pointer
** GX_LIGHT_ARRAY, // light parameter array pointer
** GX_VA_NBT, // normal, bi-normal, tangent
** GX_VA_MAX_ATTR, // maximum number of vertex attributes

** GX_VA_NULL = 0xff // NULL attribute (to mark end of lists)

Toutes les données nécessaires pour représenter un mesh peuvent être spécifiées et indexées d'une manière ou d'une autre. De même, GX_VA_TEX0MTXIDX, GX_VA_CLR0, et autres sont aussi possibles - les valeurs les plus fréquentes dans les données SSBM sont : GX_VA_PNMTXIDX, GX_VA_POS, GX_VA_NRM, et GX_VA_TEX0. Which is to be expected as joint matrices, vertex positions/normals, and texture coordinates respectively are probably the most basic of elements needed to display a texture mesh, whether static or animated.

When the value of vtx_attr == GX_VA_NULL (0xFF), the end of the vertex attribute array has been reached.

The vtx_attr_type values is actually associated with how the value is indexed, and can thus also determine the size of the index value within the display list data.

* 4 octets - enum GXAttrType
** GX_NONE = 0,
** GX_DIRECT,
** GX_INDEX8,
** GX_INDEX16

* Structures COLL_DATA : (données de collisions)
** 4 octets - vertex_offset (2 float par entrée correspondant à des données 2D probablement)
** 4 octets - vertex_count
** 4 octets - index_offset
** 4 octets - index_count
** 4 octets [5] - tableau inconnu
*** 2 octets - index_start
*** 2 octets - index_count
** 4 octets - Inconnu
** 4 octets - Inconnu

[[Category:Implementations]]
[[Category:Gotcha Force]]

Models

2023-10-07T13:34:28Z

Algoflash: /* Gotcha Force Models */

[[Gotcha Force | ← Gotcha Force]]

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

== Gotcha Force Models ==

Gotcha Force models work as those from the game Super Smash Bros Melee (SSBM) investigated by its [https://smashboards.com/threads/melee-dat-format.292603/ community].

A model is a file format that organizes objects and ressources serialized to be used by the '''H'''al '''S'''ys'''D'''olphin ('''HSD''') library. The HSD library is used in several Capcom games.

Ce sont des ressources graphiques structurées de manière hiérarchique. La présence de certaines images dans les modèles montrent à priori l'utilisation de la technique [https://learn.foundry.com/modo/901/content/help/pages/shading_lighting/shader_items/matcap.html matcap].
Par ailleurs, la librairie prendrait ses sources sur le SDK Dolphin, tel que GX ou encore MTX.

=== Fichiers concernés ===
L'ensemble des fichiers ayant dans leur titre '''_mdl''' sont des fichiers modèles correspondant au format décrit dans cette page. On notera les fichiers [[ARZ (Gotcha Force)|.arz]] qui sont des modèles compressés. Le fichier collision.arc et les fichiers tdc00.arc à tdc09.arc sont aussi des modèles.

Les fichiers modèles se retrouvent aussi dans les pzz des borgs (plxxxx.pzz) en position 004 à 009.

=== HSDRaw ===
HSDRaw, un éditeur 3D dotnet de ce format est instable sur mon Windows (algoflash). Il est cependant prouvé qu'un edit des _mdl pour commencer à l'offset 0x100 - après le préambule - permet de visualiser le fichier sur HSDRaw et d'avoir le rendu 3D du Borg (click sur le premier dossier JOBJ - puis le JOBJ dedans et double click sur le nœud en violet). Cela devrait aussi permettre d'éditer certaines propriétés ?

== Structure générale ==
Le format des modèles se découpe en plusieurs blocks. Le préambule fait 0x100 octets au tout début du fichier. Il est souvent absent. Toutes les valeurs sont en unsigned big endian, et le pad est en Nulls bytes (\x00). Les offsets trouvés après le début du Data Block (DB) sont relatifs au début du DB. La table de relocs est un tableau d'offsets de 4 octets (relatif au DB) permettant de traduire en adressage absolu les offsets des structures lors du chargement mémoire. La table de reloc permet par exemple de délimiter les structures du fait qu'il est peu probable qu'un offset pointe au milieu d'une structure.

L'ensemble des fichiers répondant à ce format on un seul root_node de type SObj (Scene data).

=== '''Préambule''' : (0x100 octets / 0 octets) ===
* 4 octets - hsd_header_offset=0x100 (toujours)
* 4 octets - bones_flags_table_offset=0x20 (toujours) - offset de la liste des flags des armatures
* 4 octets - bones_table_offset=0xC0 (toujours) - offset de la liste des armatures
* 20 octets - Pad - (toujours)
* 4 octets [32] - Inconnu (flags des armatures ?) 1 octet par flag ?
* 32 octets - Pad - (toujours)
* 32 octets - armatures ?
* 32 octets - Pad - (toujours)
=== '''HSD Header''' - (0x20 octets) ===
* 4 octets - Taille totale du fichier
* 4 octets - Taille du Data block
* 4 octets - Nombre d'entrée dans la Table de relocs
* 4 octets - root0_count
* 4 octets - root1_count
* 12 octets - Pad - (toujours)
=== '''Data block''' : ===
* JOBJ, etc. -> Ces structures sont détaillée plus loin ci-dessous.
=== '''Relocation Table''' : ===
* Tableau d'offsets de 4 octets - Offsets des structures dans le DB.
=== '''Root Nodes (2)''' : ===
* Tableau de taille 8 * root0_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
* Tableau de taille 8 * root1_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
=== '''String Table''' : ===
* Suite de strings terminées par Null au nombre de root0_count + root1_count

== Structures rencontrées dans le DB ==
Note : l'arborescence est cumulative sur les transformations pour les relations parents->enfants

Les Noeuds Racine qui ont pour nom "scene_data" pointent sur un SObj :
=== '''SObj''' : (0x10 octets) ===
* 4 octets - JObjDescs_offsets_list_offset
* 4 octets - Cameras_list_offset
* 4 octets - Lights_list_offset
* 4 octets - Fog

"scene_data" == nom du nœud racine
JObjDescs_offsets_list_offset, cameras.. pointent sur une liste d'offsets terminée par 4 octets à 0x00.
lights_list_offset pointe sur des couples (4 octets - LObj_offset ; 4 octets - light_anim_pointer_offset)

=== '''JObjDesc''' : (0x10 octets) ===
* 4 octets - root_joint_offset - JObj
* 4 octets - joint_animations_offset - ?
* 4 octets - material_animations_offset - ?
* 4 octets - shape_animations_offset - ?

=== '''CObj''' : (0x38 octets) ===
* 4 octets - flags
* 4 octets - projection_type - ProjectionTypeEnum
* 2 octets - viewport_left
* 2 octets - viewport_right
* 2 octets - viewport_top
* 2 octets - viewport_bottom
* 4 octets - proj_width
* 4 octets - proj_height
* 4 octets - eye_offset - WObj
* 4 octets - target_offset - WObj
* 4 octets - roll
* 4 octets - Inconnu
* 4 octets - float - near_clip
* 4 octets - float - far_clip
* 4 octets - float - field_of_view
* 4 octets - float - aspect
Camera object. Note : pour frustrum ou ortho, la structure est différente.

* '''ProjectionTypeEnum''':
** PERSPECTIVE = 1
** FRUSTRUM = 2
** ORTHO = 3

=== '''WObj''': (0x14 octets) ===
* 4 octets - Inconnu
* 4 octets - float - v1
* 4 octets - float - v2
* 4 octets - float - v3
* 4 octets - Inconnu

eye / target

=== '''LObj''' : (0x1c octets) ===
* 4 octets - class_name
* 4 octets - next_offset
* 2 octets - flags - LObjFlagsEnum
* 2 octets - attenuation_flags - LObjAttenuationFlagsEnum
* 1 octet - color_r
* 1 octet - color_g
* 1 octet - color_b
* 1 octet - color_alpha
* 4 octets - lobj_point_offset - position
* 4 octets - infinite_data
* 4 octets - point_spot_data
light

* '''LObjFlagsEnum''' :
** LOBJ_AMBIANT = 00 00
** LOBJ_INFINITE = 00 01
** LOBJ_POINT = 00 02
** LOBJ_SPOT = 00 03
** LOBJ_DIFFUSE = 00 04
** LOBJ_SPECULAR = 00 08
** LOBJ_ALPHA = 00 10
** LOBJ_HIDDEN = 00 20
** LOBJ_RAW_PARAM = 00 40
** LOBJ_DIFF_DIRTY = 00 80
** LOBJ_SPEC_DIRTY = 01 00

* '''LObjAttenuationFlagsEnum''' :
** LOBJ_LIGHT_ATTN_NONE = 00 00
** LOBJ_LIGHT_ATTN = 00 01

=== '''LObjPoint''' : (0x14 octets) ===
* 4 octets - class_name
* 4 octets - float - x
* 4 octets - float - y
* 4 octets - float - z
* 4 octets - Inconnu

=== '''LightAnimPointer''' : (0x10 octets) ===
** 4 octets - next_offset - (LightAnimPointer)
** 4 octets - light_anim - ?
** 4 octets - position_anim - ?
** 4 octets - interst_anim - ?
Bugs dans HSDRaw - à tester

=== '''JObj''' : (0x40 octets) ===
* 4 octets - Inconnu
* 4 octets - flags
* 4 octets - child_offset (JObj)
* 4 octets - next_offset (JObj)
* 4 octets - dobj_offset (DObj)
* 4 octets [3] - float3 - rotation_xyz
* 4 octets [3] - float3 - scale_xyz
* 4 octets [3] - float3 - translation_xyz
* 4 octets - inverse_world_transform_offset (inverse world transform = Matrice de 4x3)
* 4 octets - robj_offset

Pointé par les listes dans Root Node scene_data.

* '''JObjFlagsEnum''' : (peuvent se cumuler)
** NULL = 00 00 00 00
** SKELETON = 00 00 00 01
** SKELETON_ROOT = 00 00 00 02
** ENVELOPE_MODEL = 00 00 00 04
** CLASSICAL_SCALING = 00 00 00 08
** HIDDEN = 00 00 00 10
** PTCL = 00 00 00 20
** MTX_DIRTY = 00 00 00 40
** LIGHTING = 00 00 00 80
** TEXGEN = 00 00 01 00
** BILLBOARD = 00 00 02 00
** VBILLBOARD = 00 00 04 00
** HBILLBOARD = 00 00 06 00
** RBILLBOARD = 00 00 08 00
** INSTANCE = 00 00 10 00
** PBILLBOARD = 00 00 20 00
** SPLINE = 00 00 40 00
** FLIP_IK = 00 00 80 00
** SPECULAR = 00 01 00 00
** USE_QUATERNION = 00 02 00 00
** OPA = 00 04 00 00
** XLU = 00 08 00 00
** TEXEDGE = 00 10 00 00
** JOINT1 = 00 20 00 00
** JOINT2 = 00 40 00 00
** EFFECTOR = 00 60 00 00
** USER_DEFINED_MTX = 00 80 00 00
** MTX_INDEPEND_PARENT = 01 00 00 00
** MTX_INDEPEND_SRT = 02 00 00 00
** MTX_SCALE_COMPENSATE = 04 00 00 00
** ROOT_OPA = 10 00 00 00
** ROOT_XLU = 20 00 00 00
** ROOT_TEXEDGE = 40 00 00 00

=== '''InverseWorldTransform''' : (0x30 octets) ===
* 4 octets - float - M11
* 4 octets - float - M12
* 4 octets - float - M13
* 4 octets - float - M14
* 4 octets - float - M21
* 4 octets - float - M22
* 4 octets - float - M23
* 4 octets - float - M24
* 4 octets - float - M31
* 4 octets - float - M32
* 4 octets - float - M33
* 4 octets - float - M34

=== '''DObj''' : (0x10 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - prochain DOBJ
* 4 octets - mobj_offset - material offset
* 4 octets - pobj_offset - mesh offset
Liste chaînée qui permet de récupérer l'ensemble des materials & mesh pour le JObj auquel il est lié.

=== '''MObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - render_flags - RenderFlagsEnum
* 4 octets - tobj_offset - offset de texture - peut être invalide s'il n'y a pas de texture pour le material
* 4 octets - material_offset - couleurs des materials ?
* 8 octets - PEDesc ?

Contient les textures & informations sur les couleurs des Materials.

* '''RenderFlagsEnum''' : (se cumulent)
** USER = 80 00 00 00
** CONSTANT = 00 00 00 01
** VERTEX = 00 00 00 02
** BOTH = 00 00 00 03
** DIFFUSE = 00 00 00 04
** SPECULAR = 00 00 00 08
** TEX0 = 00 00 00 10
** TEX1 = 00 00 00 20
** TEX2 = 00 00 00 40
** TEX3 = 00 00 00 80
** TEX4 = 00 00 01 00
** TEX5 = 00 00 02 00
** TEX6 = 00 00 04 00
** TEX7 = 00 00 08 00
** TOON = 00 00 10 00
** ALPHA_MAT = 00 00 20 00
** ALPHA_VTX = 00 00 40 00
** ALPHA_BOTH = 00 00 60 00
** ZOFST = 01 00 00 00
** EFFECT = 02 00 00 00
** SHADOW = 04 00 00 00
** ZMODE_ALWAYS = 08 00 00 00
** DF_ALL = 10 00 00 00
** NO_ZUPDATE = 20 00 00 00
** XLU = 40 00 00 00

=== '''TObj''' : (0x5c octets) ===
* 4 octets - ?
* 4 octets - ?
* 4 octets - tex_map_id - TexMapIdEnum
* 4 octets - gx_tex_gen_src - GXTexGenSrcEnum
* 4 octets - float - rx
* 4 octets - float - ry
* 4 octets - float - rz
* 4 octets - float - sx
* 4 octets - float - sy
* 4 octets - float - sz
* 4 octets - float - tx
* 4 octets - float - ty
* 4 octets - float - tz
* 4 octets - wrap_s - WrapEnum
* 4 octets - wrap_t - WrapEnum
* 1 octet - w_scale
* 1 octet - h_scale
* 2 octets - ?
* 1 octets - bump_map - (False = 00 ; True = 01)
* 4 bits - alpha_operation - AlphaOperationEnum
* 4 bits - color_operation - ColorOperationEnum
* 1 octet - shadow_lightmap - (False = 00 ; True = 01) (2 octets avec une Enum lightmap limite)
* 1 bit - ext_lightmap - (False = 0 ; True = 1)
* 1 bit - ambiant_lightmap - (False = 0 ; True = 1)
* 1 bit - specular_lightmap - (False = 0 ; True = 1)
* 1 bit - diffuse_lightmap (False = 0 ; True = 1)
* 4 bits - coord_type - CoordTypeEnum
* 4 octets - float - blending - utilisé quand color_operation ou alpha_operation == BLEND
* 4 octets - mag_filter - MagFilterEnum
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
Informations de Textures. Le TObj contient des informations sur les paramètres d'environnement de textures utilisés pour le rendu graphique ainsi que les offset de l'image et des données de la palette utilisés pour cette texture. Le plus important ici, c'est l'offset d'image et la palette/tlut - si l'image n'est pas indexée (RGBA, CMPR, etc.) alors la structure de description palette/tlut n'est pas utilisée.

* '''TexMapIdEnum''' :
** GX_TEXMAP0 = 00 00 00 00
** GX_TEXMAP1 = 00 00 00 01
** GX_TEXMAP2 = 00 00 00 02
** GX_TEXMAP3 = 00 00 00 03
** GX_TEXMAP4 = 00 00 00 04
** GX_TEXMAP5 = 00 00 00 05
** GX_TEXMAP6 = 00 00 00 06
** GX_TEXMAP7 = 00 00 00 07
** GX_MAX_TEXMAP = 00 00 00 08
** GX_TEXMAP_NULL = 00 00 00 09
** GX_TEXMAP_DISABLE = 00 00 00 0A

* '''GXTexGenSrcEnum''' :
** GX_TG_POS = 00 00 00 00
** GX_TG_NRM = 00 00 00 01
** GX_TG_BINRM = 00 00 00 02
** GX_TG_TANGENT = 00 00 00 03
** GX_TG_TEX0 = 00 00 00 04
** GX_TG_TEX1 = 00 00 00 05
** GX_TG_TEX2 = 00 00 00 06
** GX_TG_TEX3 = 00 00 00 07
** GX_TG_TEX4 = 00 00 00 08
** GX_TG_TEX5 = 00 00 00 09
** GX_TG_TEX6 = 00 00 00 0A
** GX_TG_TEX7 = 00 00 00 0B
** GX_TG_TEXCOORD0 = 00 00 00 0C
** GX_TG_TEXCOORD1 = 00 00 00 0D
** GX_TG_TEXCOORD2 = 00 00 00 0E
** GX_TG_TEXCOORD3 = 00 00 00 0F
** GX_TG_TEXCOORD4 = 00 00 00 10
** GX_TG_TEXCOORD5 = 00 00 00 11
** GX_TG_TEXCOORD6 = 00 00 00 12
** GX_TG_COLOR0 = 00 00 00 13
** GX_TG_COLOR1 = 00 00 00 14

* '''AlphaOperationEnum''':
** NONE = 0X
** ALPHAMASK = 1X
** BLEND = 2X
** MODULATE = 3X
** REPLACE = 4X
** PASS = 5X
** ADD = 6X
** SUB = 7X

* '''ColorOperationEnum''':
** NONE = X0
** ALPHA_MASK = X1
** RGB_MASK = X2
** BLEND = X3
** MODULATE = X4
** REPLACE = X5
** PASS = X6
** ADD = X7
** SUB = X8

* '''CoordTypeEnum''':
** UV = X0
** REFLECTION = X1
** HILIGHT = X2
** SHADOW = X3
** TOON = X4
** GRADATION = X5

* '''MagFilterEnum''':
** GX_NEAR = 00 00 00 00
** GX_LINEAR = 00 00 00 01
** GX_NEAR_MIP_NEAR = 00 00 00 02
** GX_LIN_MIP_NEAR = 00 00 00 03
** GX_NEAR_MIP_LIN = 00 00 00 04
** GX_LIN_MIP_LIN = 00 00 00 05

* '''WrapEnum''':
** CLAMP = 00 00 00 00
** REPEAT = 00 00 00 01
** MIRROR = 00 00 00 02

=== '''Material''' : (0x14 octets) ===
* 1 octets - AMB_R - (ambient)
* 1 octets - AMB_G
* 1 octets - AMB_B
* 1 octets - AMB_A
* 1 octets - DIF_R - (diffuse)
* 1 octets - DIF_G
* 1 octets - DIF_B
* 1 octets - DIF_A
* 1 octets - SPC_R - (specular)
* 1 octets - SPC_G
* 1 octets - SPC_B
* 1 octets - SPC_A
* 4 octets - float - alpha
* 4 octets - float - shininess

=== '''PObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - pobj
* 4 octets - vertex_attr_list_offset
* 2 octets - Flags - PObjFlagsEnum
* 2 octets - display_list_size - number of 0x20 (32) byte blocks occupied by display list data
* 4 octets - display_list_offset
* 4 octets - weight_list_offset - ? verifier qu'on retrouve bien le tableau d'envelope_weights à cet offset

Comme l'indique next_offset, il s'agit d'une liste de meshs à afficher pour un material donné référencé par un dobj. PObj contient les offsets de vertex attributes / display list / joint weight list ce qui suffit et permet d’interpréter et traiter les coordonnées de vertices, normals & textures.

Les attributs vertex sont les plus important - les parametres specifiés contrôlent tout : du format, de la taille des données de chaque vertex, normal et coordonnées de textures et comment ces valeurs sont dimensionnées (scaled) par rapport à la présence et la taille de chaque valeur d'index qui apparaît dans la display list information.

* '''PObjFlagsEnum''' :
** Inconnu0 = 00 01
** Inconnu1 = 00 02
** ANIM = 00 08
** SHAPE_ANIM = 10 00
** ENVELOPE = 20 00
** CULLBACK = 40 00
** CULLFRONT = 80 00

=== EnvelopeWeights : (0x? octets) ===
* 4 octets - envelope_count
* [envelope_count]:
** 4 octets - float - weight
** 4 octets - pad ?
* 4 octets - jobj_list_offset

=== not verified yet ===

* '''IMAGE_HEADER''' :
** 4 octets - image_offset - image data
** 2 octets - width
** 2 octets - height
** 4 octets - image_format

* '''PALETTE_HEADER''' : (0x10)
** 4 octets - palette_offset - palette data
** 4 octets - palette_format
** 4 octets - Inconnu
** 2 octets - color_count
** 2 octets - Inconnu

image_offset et palette_offset sont souvent partagés par plusieurs textures - savoir ça permet de retrouver toutes les informations sur les images des textures (largeur, hauteur, format), ainsi que le format et le nombre de couleurs de la palette/tlut.

Le format d'image ne détermine pas le nombre total de couleurs de la palette qu'elle utilisent. Par exemple, une image indexée sur 8 bits aurait un maximum de 256 couleurs mais seulement 136 ou 221 couleurs sont actuellement utilisées. De la sorte, la palette n'utilisera pas la taille totale qu'elle devrait utiliser.

Les images suivent la structure généralement utilisée par la GameCube :

IMAGE FORMATS :
* case 0: //i4
* case 1: //i8
* case 2: //i4a4
* case 3: //i8a8
* case 4: //r5g6b5
* case 5: //rgb5a3
* case 6: //r8g8b8a8
* case 8: //index4
* case 9: //index8
* case 0xa: //index14x2
* case 0xe: //s3tc1

Les formats indexés utilisent aussi les informations de palettes/tlut et les données peuvent apparaître en plusieurs formats :

PALETTE FORMATS :
* case 0: //ia8
* case 1: //r5g6b5
* case 2: //rgb5a3

---> "Joint Data - Accessing Geometry, Mesh, and Vertex Attributes" https://smashboards.com/threads/melee-dat-format.292603/

trad a revoir à partir de là, il faut investiguer le rendu 3D sur GameCube pour mieux comprendre

// déclaration d'un vertex et attribute information
// attr, type, cnt, data_type, flags?, file_offset
* ATTR_DATA
** 4 octets - GXAttr vtx_attr_offset - attr
** 4 octets - GXAttrType vtx_attr_type - index_type
** 4 octets - GXCompCnt comp_cnt - cnt
** 4 octets - GXCompType comp_type - data_type
** 1 octets - scale
** 1 octets - Inconnu
** 2 octets - vtx_stride
** 2 octets - data_offset

vertex_attr_offset pointe sur une liste d'attributs de vertex. Leur nombre n'est pas donné. Les données dans cette structure suivent les informations et les types conçus par l'architecture GameCube/WII et son API. La liste est terminée par une valeur spécifique de vtx_attr qui signale la fin de cette liste. Avec un accès à la doku SDK, il serait fortement conseillé de lire la section à propos des "vertex attributes and other specifications".

La valeur de vtx_attr determine le type de donnée que cet attribut désigne et peut indiquer un nombre de types natifs utilisés utilisés pour passer les données entre les interfaces logicielles et matérielles.

Les valeures possibles sont les suivantes :
* enum GXAttr (4 octets)
** GX_VA_PNMTXIDX = 0, // position/normal matrix index
** GX_VA_TEX0MTXIDX, // texture 0 matrix index
** GX_VA_TEX1MTXIDX, // texture 1 matrix index
** GX_VA_TEX2MTXIDX, // texture 2 matrix index
** GX_VA_TEX3MTXIDX, // texture 3 matrix index
** GX_VA_TEX4MTXIDX, // texture 4 matrix index
** GX_VA_TEX5MTXIDX, // texture 5 matrix index
** GX_VA_TEX6MTXIDX, // texture 6 matrix index
** GX_VA_TEX7MTXIDX, // texture 7 matrix index
** GX_VA_POS = 9, // position
** GX_VA_NRM, // normal
** GX_VA_CLR0, // color 0
** GX_VA_CLR1, // color 1
** GX_VA_TEX0, // input texture coordinate 0
** GX_VA_TEX1, // input texture coordinate 1
** GX_VA_TEX2, // input texture coordinate 2
** GX_VA_TEX3, // input texture coordinate 3
** GX_VA_TEX4, // input texture coordinate 4
** GX_VA_TEX5, // input texture coordinate 5
** GX_VA_TEX6, // input texture coordinate 6
** GX_VA_TEX7, // input texture coordinate 7

** GX_POS_MTX_ARRAY, // position matrix array pointer
** GX_NRM_MTX_ARRAY, // normal matrix array pointer
** GX_TEX_MTX_ARRAY, // texture matrix array pointer
** GX_LIGHT_ARRAY, // light parameter array pointer
** GX_VA_NBT, // normal, bi-normal, tangent
** GX_VA_MAX_ATTR, // maximum number of vertex attributes

** GX_VA_NULL = 0xff // NULL attribute (to mark end of lists)

Toutes les données nécessaires pour représenter un mesh peuvent être spécifiées et indexées d'une manière ou d'une autre. De même, GX_VA_TEX0MTXIDX, GX_VA_CLR0, et autres sont aussi possibles - les valeurs les plus fréquentes dans les données SSBM sont : GX_VA_PNMTXIDX, GX_VA_POS, GX_VA_NRM, et GX_VA_TEX0. Which is to be expected as joint matrices, vertex positions/normals, and texture coordinates respectively are probably the most basic of elements needed to display a texture mesh, whether static or animated.

When the value of vtx_attr == GX_VA_NULL (0xFF), the end of the vertex attribute array has been reached.

The vtx_attr_type values is actually associated with how the value is indexed, and can thus also determine the size of the index value within the display list data.

* 4 octets - enum GXAttrType
** GX_NONE = 0,
** GX_DIRECT,
** GX_INDEX8,
** GX_INDEX16

* Structures COLL_DATA : (données de collisions)
** 4 octets - vertex_offset (2 float par entrée correspondant à des données 2D probablement)
** 4 octets - vertex_count
** 4 octets - index_offset
** 4 octets - index_count
** 4 octets [5] - tableau inconnu
*** 2 octets - index_start
*** 2 octets - index_count
** 4 octets - Inconnu
** 4 octets - Inconnu

[[Category:Implementations]]
[[Category:Gotcha Force]]

Models

2023-10-07T13:33:56Z

Algoflash: /* Gotcha Force Models */

[[Gotcha Force | ← Gotcha Force]]

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

== Gotcha Force Models ==

Gotcha Force models work as those from the game Super Smash Bros Melee (SSBM) investigated by its [https://smashboards.com/threads/melee-dat-format.292603/ community].

A model is a file format organizating objects and ressources serialized to be used by the '''H'''al '''S'''ys'''D'''olphin ('''HSD''') library. The HSD library is used in several Capcom games.

Ce sont des ressources graphiques structurées de manière hiérarchique. La présence de certaines images dans les modèles montrent à priori l'utilisation de la technique [https://learn.foundry.com/modo/901/content/help/pages/shading_lighting/shader_items/matcap.html matcap].
Par ailleurs, la librairie prendrait ses sources sur le SDK Dolphin, tel que GX ou encore MTX.

=== Fichiers concernés ===
L'ensemble des fichiers ayant dans leur titre '''_mdl''' sont des fichiers modèles correspondant au format décrit dans cette page. On notera les fichiers [[ARZ (Gotcha Force)|.arz]] qui sont des modèles compressés. Le fichier collision.arc et les fichiers tdc00.arc à tdc09.arc sont aussi des modèles.

Les fichiers modèles se retrouvent aussi dans les pzz des borgs (plxxxx.pzz) en position 004 à 009.

=== HSDRaw ===
HSDRaw, un éditeur 3D dotnet de ce format est instable sur mon Windows (algoflash). Il est cependant prouvé qu'un edit des _mdl pour commencer à l'offset 0x100 - après le préambule - permet de visualiser le fichier sur HSDRaw et d'avoir le rendu 3D du Borg (click sur le premier dossier JOBJ - puis le JOBJ dedans et double click sur le nœud en violet). Cela devrait aussi permettre d'éditer certaines propriétés ?

== Structure générale ==
Le format des modèles se découpe en plusieurs blocks. Le préambule fait 0x100 octets au tout début du fichier. Il est souvent absent. Toutes les valeurs sont en unsigned big endian, et le pad est en Nulls bytes (\x00). Les offsets trouvés après le début du Data Block (DB) sont relatifs au début du DB. La table de relocs est un tableau d'offsets de 4 octets (relatif au DB) permettant de traduire en adressage absolu les offsets des structures lors du chargement mémoire. La table de reloc permet par exemple de délimiter les structures du fait qu'il est peu probable qu'un offset pointe au milieu d'une structure.

L'ensemble des fichiers répondant à ce format on un seul root_node de type SObj (Scene data).

=== '''Préambule''' : (0x100 octets / 0 octets) ===
* 4 octets - hsd_header_offset=0x100 (toujours)
* 4 octets - bones_flags_table_offset=0x20 (toujours) - offset de la liste des flags des armatures
* 4 octets - bones_table_offset=0xC0 (toujours) - offset de la liste des armatures
* 20 octets - Pad - (toujours)
* 4 octets [32] - Inconnu (flags des armatures ?) 1 octet par flag ?
* 32 octets - Pad - (toujours)
* 32 octets - armatures ?
* 32 octets - Pad - (toujours)
=== '''HSD Header''' - (0x20 octets) ===
* 4 octets - Taille totale du fichier
* 4 octets - Taille du Data block
* 4 octets - Nombre d'entrée dans la Table de relocs
* 4 octets - root0_count
* 4 octets - root1_count
* 12 octets - Pad - (toujours)
=== '''Data block''' : ===
* JOBJ, etc. -> Ces structures sont détaillée plus loin ci-dessous.
=== '''Relocation Table''' : ===
* Tableau d'offsets de 4 octets - Offsets des structures dans le DB.
=== '''Root Nodes (2)''' : ===
* Tableau de taille 8 * root0_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
* Tableau de taille 8 * root1_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
=== '''String Table''' : ===
* Suite de strings terminées par Null au nombre de root0_count + root1_count

== Structures rencontrées dans le DB ==
Note : l'arborescence est cumulative sur les transformations pour les relations parents->enfants

Les Noeuds Racine qui ont pour nom "scene_data" pointent sur un SObj :
=== '''SObj''' : (0x10 octets) ===
* 4 octets - JObjDescs_offsets_list_offset
* 4 octets - Cameras_list_offset
* 4 octets - Lights_list_offset
* 4 octets - Fog

"scene_data" == nom du nœud racine
JObjDescs_offsets_list_offset, cameras.. pointent sur une liste d'offsets terminée par 4 octets à 0x00.
lights_list_offset pointe sur des couples (4 octets - LObj_offset ; 4 octets - light_anim_pointer_offset)

=== '''JObjDesc''' : (0x10 octets) ===
* 4 octets - root_joint_offset - JObj
* 4 octets - joint_animations_offset - ?
* 4 octets - material_animations_offset - ?
* 4 octets - shape_animations_offset - ?

=== '''CObj''' : (0x38 octets) ===
* 4 octets - flags
* 4 octets - projection_type - ProjectionTypeEnum
* 2 octets - viewport_left
* 2 octets - viewport_right
* 2 octets - viewport_top
* 2 octets - viewport_bottom
* 4 octets - proj_width
* 4 octets - proj_height
* 4 octets - eye_offset - WObj
* 4 octets - target_offset - WObj
* 4 octets - roll
* 4 octets - Inconnu
* 4 octets - float - near_clip
* 4 octets - float - far_clip
* 4 octets - float - field_of_view
* 4 octets - float - aspect
Camera object. Note : pour frustrum ou ortho, la structure est différente.

* '''ProjectionTypeEnum''':
** PERSPECTIVE = 1
** FRUSTRUM = 2
** ORTHO = 3

=== '''WObj''': (0x14 octets) ===
* 4 octets - Inconnu
* 4 octets - float - v1
* 4 octets - float - v2
* 4 octets - float - v3
* 4 octets - Inconnu

eye / target

=== '''LObj''' : (0x1c octets) ===
* 4 octets - class_name
* 4 octets - next_offset
* 2 octets - flags - LObjFlagsEnum
* 2 octets - attenuation_flags - LObjAttenuationFlagsEnum
* 1 octet - color_r
* 1 octet - color_g
* 1 octet - color_b
* 1 octet - color_alpha
* 4 octets - lobj_point_offset - position
* 4 octets - infinite_data
* 4 octets - point_spot_data
light

* '''LObjFlagsEnum''' :
** LOBJ_AMBIANT = 00 00
** LOBJ_INFINITE = 00 01
** LOBJ_POINT = 00 02
** LOBJ_SPOT = 00 03
** LOBJ_DIFFUSE = 00 04
** LOBJ_SPECULAR = 00 08
** LOBJ_ALPHA = 00 10
** LOBJ_HIDDEN = 00 20
** LOBJ_RAW_PARAM = 00 40
** LOBJ_DIFF_DIRTY = 00 80
** LOBJ_SPEC_DIRTY = 01 00

* '''LObjAttenuationFlagsEnum''' :
** LOBJ_LIGHT_ATTN_NONE = 00 00
** LOBJ_LIGHT_ATTN = 00 01

=== '''LObjPoint''' : (0x14 octets) ===
* 4 octets - class_name
* 4 octets - float - x
* 4 octets - float - y
* 4 octets - float - z
* 4 octets - Inconnu

=== '''LightAnimPointer''' : (0x10 octets) ===
** 4 octets - next_offset - (LightAnimPointer)
** 4 octets - light_anim - ?
** 4 octets - position_anim - ?
** 4 octets - interst_anim - ?
Bugs dans HSDRaw - à tester

=== '''JObj''' : (0x40 octets) ===
* 4 octets - Inconnu
* 4 octets - flags
* 4 octets - child_offset (JObj)
* 4 octets - next_offset (JObj)
* 4 octets - dobj_offset (DObj)
* 4 octets [3] - float3 - rotation_xyz
* 4 octets [3] - float3 - scale_xyz
* 4 octets [3] - float3 - translation_xyz
* 4 octets - inverse_world_transform_offset (inverse world transform = Matrice de 4x3)
* 4 octets - robj_offset

Pointé par les listes dans Root Node scene_data.

* '''JObjFlagsEnum''' : (peuvent se cumuler)
** NULL = 00 00 00 00
** SKELETON = 00 00 00 01
** SKELETON_ROOT = 00 00 00 02
** ENVELOPE_MODEL = 00 00 00 04
** CLASSICAL_SCALING = 00 00 00 08
** HIDDEN = 00 00 00 10
** PTCL = 00 00 00 20
** MTX_DIRTY = 00 00 00 40
** LIGHTING = 00 00 00 80
** TEXGEN = 00 00 01 00
** BILLBOARD = 00 00 02 00
** VBILLBOARD = 00 00 04 00
** HBILLBOARD = 00 00 06 00
** RBILLBOARD = 00 00 08 00
** INSTANCE = 00 00 10 00
** PBILLBOARD = 00 00 20 00
** SPLINE = 00 00 40 00
** FLIP_IK = 00 00 80 00
** SPECULAR = 00 01 00 00
** USE_QUATERNION = 00 02 00 00
** OPA = 00 04 00 00
** XLU = 00 08 00 00
** TEXEDGE = 00 10 00 00
** JOINT1 = 00 20 00 00
** JOINT2 = 00 40 00 00
** EFFECTOR = 00 60 00 00
** USER_DEFINED_MTX = 00 80 00 00
** MTX_INDEPEND_PARENT = 01 00 00 00
** MTX_INDEPEND_SRT = 02 00 00 00
** MTX_SCALE_COMPENSATE = 04 00 00 00
** ROOT_OPA = 10 00 00 00
** ROOT_XLU = 20 00 00 00
** ROOT_TEXEDGE = 40 00 00 00

=== '''InverseWorldTransform''' : (0x30 octets) ===
* 4 octets - float - M11
* 4 octets - float - M12
* 4 octets - float - M13
* 4 octets - float - M14
* 4 octets - float - M21
* 4 octets - float - M22
* 4 octets - float - M23
* 4 octets - float - M24
* 4 octets - float - M31
* 4 octets - float - M32
* 4 octets - float - M33
* 4 octets - float - M34

=== '''DObj''' : (0x10 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - prochain DOBJ
* 4 octets - mobj_offset - material offset
* 4 octets - pobj_offset - mesh offset
Liste chaînée qui permet de récupérer l'ensemble des materials & mesh pour le JObj auquel il est lié.

=== '''MObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - render_flags - RenderFlagsEnum
* 4 octets - tobj_offset - offset de texture - peut être invalide s'il n'y a pas de texture pour le material
* 4 octets - material_offset - couleurs des materials ?
* 8 octets - PEDesc ?

Contient les textures & informations sur les couleurs des Materials.

* '''RenderFlagsEnum''' : (se cumulent)
** USER = 80 00 00 00
** CONSTANT = 00 00 00 01
** VERTEX = 00 00 00 02
** BOTH = 00 00 00 03
** DIFFUSE = 00 00 00 04
** SPECULAR = 00 00 00 08
** TEX0 = 00 00 00 10
** TEX1 = 00 00 00 20
** TEX2 = 00 00 00 40
** TEX3 = 00 00 00 80
** TEX4 = 00 00 01 00
** TEX5 = 00 00 02 00
** TEX6 = 00 00 04 00
** TEX7 = 00 00 08 00
** TOON = 00 00 10 00
** ALPHA_MAT = 00 00 20 00
** ALPHA_VTX = 00 00 40 00
** ALPHA_BOTH = 00 00 60 00
** ZOFST = 01 00 00 00
** EFFECT = 02 00 00 00
** SHADOW = 04 00 00 00
** ZMODE_ALWAYS = 08 00 00 00
** DF_ALL = 10 00 00 00
** NO_ZUPDATE = 20 00 00 00
** XLU = 40 00 00 00

=== '''TObj''' : (0x5c octets) ===
* 4 octets - ?
* 4 octets - ?
* 4 octets - tex_map_id - TexMapIdEnum
* 4 octets - gx_tex_gen_src - GXTexGenSrcEnum
* 4 octets - float - rx
* 4 octets - float - ry
* 4 octets - float - rz
* 4 octets - float - sx
* 4 octets - float - sy
* 4 octets - float - sz
* 4 octets - float - tx
* 4 octets - float - ty
* 4 octets - float - tz
* 4 octets - wrap_s - WrapEnum
* 4 octets - wrap_t - WrapEnum
* 1 octet - w_scale
* 1 octet - h_scale
* 2 octets - ?
* 1 octets - bump_map - (False = 00 ; True = 01)
* 4 bits - alpha_operation - AlphaOperationEnum
* 4 bits - color_operation - ColorOperationEnum
* 1 octet - shadow_lightmap - (False = 00 ; True = 01) (2 octets avec une Enum lightmap limite)
* 1 bit - ext_lightmap - (False = 0 ; True = 1)
* 1 bit - ambiant_lightmap - (False = 0 ; True = 1)
* 1 bit - specular_lightmap - (False = 0 ; True = 1)
* 1 bit - diffuse_lightmap (False = 0 ; True = 1)
* 4 bits - coord_type - CoordTypeEnum
* 4 octets - float - blending - utilisé quand color_operation ou alpha_operation == BLEND
* 4 octets - mag_filter - MagFilterEnum
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
Informations de Textures. Le TObj contient des informations sur les paramètres d'environnement de textures utilisés pour le rendu graphique ainsi que les offset de l'image et des données de la palette utilisés pour cette texture. Le plus important ici, c'est l'offset d'image et la palette/tlut - si l'image n'est pas indexée (RGBA, CMPR, etc.) alors la structure de description palette/tlut n'est pas utilisée.

* '''TexMapIdEnum''' :
** GX_TEXMAP0 = 00 00 00 00
** GX_TEXMAP1 = 00 00 00 01
** GX_TEXMAP2 = 00 00 00 02
** GX_TEXMAP3 = 00 00 00 03
** GX_TEXMAP4 = 00 00 00 04
** GX_TEXMAP5 = 00 00 00 05
** GX_TEXMAP6 = 00 00 00 06
** GX_TEXMAP7 = 00 00 00 07
** GX_MAX_TEXMAP = 00 00 00 08
** GX_TEXMAP_NULL = 00 00 00 09
** GX_TEXMAP_DISABLE = 00 00 00 0A

* '''GXTexGenSrcEnum''' :
** GX_TG_POS = 00 00 00 00
** GX_TG_NRM = 00 00 00 01
** GX_TG_BINRM = 00 00 00 02
** GX_TG_TANGENT = 00 00 00 03
** GX_TG_TEX0 = 00 00 00 04
** GX_TG_TEX1 = 00 00 00 05
** GX_TG_TEX2 = 00 00 00 06
** GX_TG_TEX3 = 00 00 00 07
** GX_TG_TEX4 = 00 00 00 08
** GX_TG_TEX5 = 00 00 00 09
** GX_TG_TEX6 = 00 00 00 0A
** GX_TG_TEX7 = 00 00 00 0B
** GX_TG_TEXCOORD0 = 00 00 00 0C
** GX_TG_TEXCOORD1 = 00 00 00 0D
** GX_TG_TEXCOORD2 = 00 00 00 0E
** GX_TG_TEXCOORD3 = 00 00 00 0F
** GX_TG_TEXCOORD4 = 00 00 00 10
** GX_TG_TEXCOORD5 = 00 00 00 11
** GX_TG_TEXCOORD6 = 00 00 00 12
** GX_TG_COLOR0 = 00 00 00 13
** GX_TG_COLOR1 = 00 00 00 14

* '''AlphaOperationEnum''':
** NONE = 0X
** ALPHAMASK = 1X
** BLEND = 2X
** MODULATE = 3X
** REPLACE = 4X
** PASS = 5X
** ADD = 6X
** SUB = 7X

* '''ColorOperationEnum''':
** NONE = X0
** ALPHA_MASK = X1
** RGB_MASK = X2
** BLEND = X3
** MODULATE = X4
** REPLACE = X5
** PASS = X6
** ADD = X7
** SUB = X8

* '''CoordTypeEnum''':
** UV = X0
** REFLECTION = X1
** HILIGHT = X2
** SHADOW = X3
** TOON = X4
** GRADATION = X5

* '''MagFilterEnum''':
** GX_NEAR = 00 00 00 00
** GX_LINEAR = 00 00 00 01
** GX_NEAR_MIP_NEAR = 00 00 00 02
** GX_LIN_MIP_NEAR = 00 00 00 03
** GX_NEAR_MIP_LIN = 00 00 00 04
** GX_LIN_MIP_LIN = 00 00 00 05

* '''WrapEnum''':
** CLAMP = 00 00 00 00
** REPEAT = 00 00 00 01
** MIRROR = 00 00 00 02

=== '''Material''' : (0x14 octets) ===
* 1 octets - AMB_R - (ambient)
* 1 octets - AMB_G
* 1 octets - AMB_B
* 1 octets - AMB_A
* 1 octets - DIF_R - (diffuse)
* 1 octets - DIF_G
* 1 octets - DIF_B
* 1 octets - DIF_A
* 1 octets - SPC_R - (specular)
* 1 octets - SPC_G
* 1 octets - SPC_B
* 1 octets - SPC_A
* 4 octets - float - alpha
* 4 octets - float - shininess

=== '''PObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - pobj
* 4 octets - vertex_attr_list_offset
* 2 octets - Flags - PObjFlagsEnum
* 2 octets - display_list_size - number of 0x20 (32) byte blocks occupied by display list data
* 4 octets - display_list_offset
* 4 octets - weight_list_offset - ? verifier qu'on retrouve bien le tableau d'envelope_weights à cet offset

Comme l'indique next_offset, il s'agit d'une liste de meshs à afficher pour un material donné référencé par un dobj. PObj contient les offsets de vertex attributes / display list / joint weight list ce qui suffit et permet d’interpréter et traiter les coordonnées de vertices, normals & textures.

Les attributs vertex sont les plus important - les parametres specifiés contrôlent tout : du format, de la taille des données de chaque vertex, normal et coordonnées de textures et comment ces valeurs sont dimensionnées (scaled) par rapport à la présence et la taille de chaque valeur d'index qui apparaît dans la display list information.

* '''PObjFlagsEnum''' :
** Inconnu0 = 00 01
** Inconnu1 = 00 02
** ANIM = 00 08
** SHAPE_ANIM = 10 00
** ENVELOPE = 20 00
** CULLBACK = 40 00
** CULLFRONT = 80 00

=== EnvelopeWeights : (0x? octets) ===
* 4 octets - envelope_count
* [envelope_count]:
** 4 octets - float - weight
** 4 octets - pad ?
* 4 octets - jobj_list_offset

=== not verified yet ===

* '''IMAGE_HEADER''' :
** 4 octets - image_offset - image data
** 2 octets - width
** 2 octets - height
** 4 octets - image_format

* '''PALETTE_HEADER''' : (0x10)
** 4 octets - palette_offset - palette data
** 4 octets - palette_format
** 4 octets - Inconnu
** 2 octets - color_count
** 2 octets - Inconnu

image_offset et palette_offset sont souvent partagés par plusieurs textures - savoir ça permet de retrouver toutes les informations sur les images des textures (largeur, hauteur, format), ainsi que le format et le nombre de couleurs de la palette/tlut.

Le format d'image ne détermine pas le nombre total de couleurs de la palette qu'elle utilisent. Par exemple, une image indexée sur 8 bits aurait un maximum de 256 couleurs mais seulement 136 ou 221 couleurs sont actuellement utilisées. De la sorte, la palette n'utilisera pas la taille totale qu'elle devrait utiliser.

Les images suivent la structure généralement utilisée par la GameCube :

IMAGE FORMATS :
* case 0: //i4
* case 1: //i8
* case 2: //i4a4
* case 3: //i8a8
* case 4: //r5g6b5
* case 5: //rgb5a3
* case 6: //r8g8b8a8
* case 8: //index4
* case 9: //index8
* case 0xa: //index14x2
* case 0xe: //s3tc1

Les formats indexés utilisent aussi les informations de palettes/tlut et les données peuvent apparaître en plusieurs formats :

PALETTE FORMATS :
* case 0: //ia8
* case 1: //r5g6b5
* case 2: //rgb5a3

---> "Joint Data - Accessing Geometry, Mesh, and Vertex Attributes" https://smashboards.com/threads/melee-dat-format.292603/

trad a revoir à partir de là, il faut investiguer le rendu 3D sur GameCube pour mieux comprendre

// déclaration d'un vertex et attribute information
// attr, type, cnt, data_type, flags?, file_offset
* ATTR_DATA
** 4 octets - GXAttr vtx_attr_offset - attr
** 4 octets - GXAttrType vtx_attr_type - index_type
** 4 octets - GXCompCnt comp_cnt - cnt
** 4 octets - GXCompType comp_type - data_type
** 1 octets - scale
** 1 octets - Inconnu
** 2 octets - vtx_stride
** 2 octets - data_offset

vertex_attr_offset pointe sur une liste d'attributs de vertex. Leur nombre n'est pas donné. Les données dans cette structure suivent les informations et les types conçus par l'architecture GameCube/WII et son API. La liste est terminée par une valeur spécifique de vtx_attr qui signale la fin de cette liste. Avec un accès à la doku SDK, il serait fortement conseillé de lire la section à propos des "vertex attributes and other specifications".

La valeur de vtx_attr determine le type de donnée que cet attribut désigne et peut indiquer un nombre de types natifs utilisés utilisés pour passer les données entre les interfaces logicielles et matérielles.

Les valeures possibles sont les suivantes :
* enum GXAttr (4 octets)
** GX_VA_PNMTXIDX = 0, // position/normal matrix index
** GX_VA_TEX0MTXIDX, // texture 0 matrix index
** GX_VA_TEX1MTXIDX, // texture 1 matrix index
** GX_VA_TEX2MTXIDX, // texture 2 matrix index
** GX_VA_TEX3MTXIDX, // texture 3 matrix index
** GX_VA_TEX4MTXIDX, // texture 4 matrix index
** GX_VA_TEX5MTXIDX, // texture 5 matrix index
** GX_VA_TEX6MTXIDX, // texture 6 matrix index
** GX_VA_TEX7MTXIDX, // texture 7 matrix index
** GX_VA_POS = 9, // position
** GX_VA_NRM, // normal
** GX_VA_CLR0, // color 0
** GX_VA_CLR1, // color 1
** GX_VA_TEX0, // input texture coordinate 0
** GX_VA_TEX1, // input texture coordinate 1
** GX_VA_TEX2, // input texture coordinate 2
** GX_VA_TEX3, // input texture coordinate 3
** GX_VA_TEX4, // input texture coordinate 4
** GX_VA_TEX5, // input texture coordinate 5
** GX_VA_TEX6, // input texture coordinate 6
** GX_VA_TEX7, // input texture coordinate 7

** GX_POS_MTX_ARRAY, // position matrix array pointer
** GX_NRM_MTX_ARRAY, // normal matrix array pointer
** GX_TEX_MTX_ARRAY, // texture matrix array pointer
** GX_LIGHT_ARRAY, // light parameter array pointer
** GX_VA_NBT, // normal, bi-normal, tangent
** GX_VA_MAX_ATTR, // maximum number of vertex attributes

** GX_VA_NULL = 0xff // NULL attribute (to mark end of lists)

Toutes les données nécessaires pour représenter un mesh peuvent être spécifiées et indexées d'une manière ou d'une autre. De même, GX_VA_TEX0MTXIDX, GX_VA_CLR0, et autres sont aussi possibles - les valeurs les plus fréquentes dans les données SSBM sont : GX_VA_PNMTXIDX, GX_VA_POS, GX_VA_NRM, et GX_VA_TEX0. Which is to be expected as joint matrices, vertex positions/normals, and texture coordinates respectively are probably the most basic of elements needed to display a texture mesh, whether static or animated.

When the value of vtx_attr == GX_VA_NULL (0xFF), the end of the vertex attribute array has been reached.

The vtx_attr_type values is actually associated with how the value is indexed, and can thus also determine the size of the index value within the display list data.

* 4 octets - enum GXAttrType
** GX_NONE = 0,
** GX_DIRECT,
** GX_INDEX8,
** GX_INDEX16

* Structures COLL_DATA : (données de collisions)
** 4 octets - vertex_offset (2 float par entrée correspondant à des données 2D probablement)
** 4 octets - vertex_count
** 4 octets - index_offset
** 4 octets - index_count
** 4 octets [5] - tableau inconnu
*** 2 octets - index_start
*** 2 octets - index_count
** 4 octets - Inconnu
** 4 octets - Inconnu

[[Category:Implementations]]
[[Category:Gotcha Force]]

Models

2023-10-07T13:29:46Z

Algoflash: /* Gotcha Force Models */

[[Gotcha Force | ← Gotcha Force]]

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

== Gotcha Force Models ==

Gotcha Force models work as those from the game Super Smash Bros Melee (SSBM) investigated by its [https://smashboards.com/threads/melee-dat-format.292603/ community].

Un modèle est un format de fichier organisant des objets et des ressources sérialisés pour être utilisés par la librairie '''H'''al '''S'''ys'''D'''olphin ('''HSD'''), une librairie utilisée dans plusieurs jeux par Capcom. Ce sont des ressources graphiques structurées de manière hiérarchique. La présence de certaines images dans les modèles montrent à priori l'utilisation de la technique [https://learn.foundry.com/modo/901/content/help/pages/shading_lighting/shader_items/matcap.html matcap].
Par ailleurs, la librairie prendrait ses sources sur le SDK Dolphin, tel que GX ou encore MTX.

=== Fichiers concernés ===
L'ensemble des fichiers ayant dans leur titre '''_mdl''' sont des fichiers modèles correspondant au format décrit dans cette page. On notera les fichiers [[ARZ (Gotcha Force)|.arz]] qui sont des modèles compressés. Le fichier collision.arc et les fichiers tdc00.arc à tdc09.arc sont aussi des modèles.

Les fichiers modèles se retrouvent aussi dans les pzz des borgs (plxxxx.pzz) en position 004 à 009.

=== HSDRaw ===
HSDRaw, un éditeur 3D dotnet de ce format est instable sur mon Windows (algoflash). Il est cependant prouvé qu'un edit des _mdl pour commencer à l'offset 0x100 - après le préambule - permet de visualiser le fichier sur HSDRaw et d'avoir le rendu 3D du Borg (click sur le premier dossier JOBJ - puis le JOBJ dedans et double click sur le nœud en violet). Cela devrait aussi permettre d'éditer certaines propriétés ?

== Structure générale ==
Le format des modèles se découpe en plusieurs blocks. Le préambule fait 0x100 octets au tout début du fichier. Il est souvent absent. Toutes les valeurs sont en unsigned big endian, et le pad est en Nulls bytes (\x00). Les offsets trouvés après le début du Data Block (DB) sont relatifs au début du DB. La table de relocs est un tableau d'offsets de 4 octets (relatif au DB) permettant de traduire en adressage absolu les offsets des structures lors du chargement mémoire. La table de reloc permet par exemple de délimiter les structures du fait qu'il est peu probable qu'un offset pointe au milieu d'une structure.

L'ensemble des fichiers répondant à ce format on un seul root_node de type SObj (Scene data).

=== '''Préambule''' : (0x100 octets / 0 octets) ===
* 4 octets - hsd_header_offset=0x100 (toujours)
* 4 octets - bones_flags_table_offset=0x20 (toujours) - offset de la liste des flags des armatures
* 4 octets - bones_table_offset=0xC0 (toujours) - offset de la liste des armatures
* 20 octets - Pad - (toujours)
* 4 octets [32] - Inconnu (flags des armatures ?) 1 octet par flag ?
* 32 octets - Pad - (toujours)
* 32 octets - armatures ?
* 32 octets - Pad - (toujours)
=== '''HSD Header''' - (0x20 octets) ===
* 4 octets - Taille totale du fichier
* 4 octets - Taille du Data block
* 4 octets - Nombre d'entrée dans la Table de relocs
* 4 octets - root0_count
* 4 octets - root1_count
* 12 octets - Pad - (toujours)
=== '''Data block''' : ===
* JOBJ, etc. -> Ces structures sont détaillée plus loin ci-dessous.
=== '''Relocation Table''' : ===
* Tableau d'offsets de 4 octets - Offsets des structures dans le DB.
=== '''Root Nodes (2)''' : ===
* Tableau de taille 8 * root0_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
* Tableau de taille 8 * root1_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
=== '''String Table''' : ===
* Suite de strings terminées par Null au nombre de root0_count + root1_count

== Structures rencontrées dans le DB ==
Note : l'arborescence est cumulative sur les transformations pour les relations parents->enfants

Les Noeuds Racine qui ont pour nom "scene_data" pointent sur un SObj :
=== '''SObj''' : (0x10 octets) ===
* 4 octets - JObjDescs_offsets_list_offset
* 4 octets - Cameras_list_offset
* 4 octets - Lights_list_offset
* 4 octets - Fog

"scene_data" == nom du nœud racine
JObjDescs_offsets_list_offset, cameras.. pointent sur une liste d'offsets terminée par 4 octets à 0x00.
lights_list_offset pointe sur des couples (4 octets - LObj_offset ; 4 octets - light_anim_pointer_offset)

=== '''JObjDesc''' : (0x10 octets) ===
* 4 octets - root_joint_offset - JObj
* 4 octets - joint_animations_offset - ?
* 4 octets - material_animations_offset - ?
* 4 octets - shape_animations_offset - ?

=== '''CObj''' : (0x38 octets) ===
* 4 octets - flags
* 4 octets - projection_type - ProjectionTypeEnum
* 2 octets - viewport_left
* 2 octets - viewport_right
* 2 octets - viewport_top
* 2 octets - viewport_bottom
* 4 octets - proj_width
* 4 octets - proj_height
* 4 octets - eye_offset - WObj
* 4 octets - target_offset - WObj
* 4 octets - roll
* 4 octets - Inconnu
* 4 octets - float - near_clip
* 4 octets - float - far_clip
* 4 octets - float - field_of_view
* 4 octets - float - aspect
Camera object. Note : pour frustrum ou ortho, la structure est différente.

* '''ProjectionTypeEnum''':
** PERSPECTIVE = 1
** FRUSTRUM = 2
** ORTHO = 3

=== '''WObj''': (0x14 octets) ===
* 4 octets - Inconnu
* 4 octets - float - v1
* 4 octets - float - v2
* 4 octets - float - v3
* 4 octets - Inconnu

eye / target

=== '''LObj''' : (0x1c octets) ===
* 4 octets - class_name
* 4 octets - next_offset
* 2 octets - flags - LObjFlagsEnum
* 2 octets - attenuation_flags - LObjAttenuationFlagsEnum
* 1 octet - color_r
* 1 octet - color_g
* 1 octet - color_b
* 1 octet - color_alpha
* 4 octets - lobj_point_offset - position
* 4 octets - infinite_data
* 4 octets - point_spot_data
light

* '''LObjFlagsEnum''' :
** LOBJ_AMBIANT = 00 00
** LOBJ_INFINITE = 00 01
** LOBJ_POINT = 00 02
** LOBJ_SPOT = 00 03
** LOBJ_DIFFUSE = 00 04
** LOBJ_SPECULAR = 00 08
** LOBJ_ALPHA = 00 10
** LOBJ_HIDDEN = 00 20
** LOBJ_RAW_PARAM = 00 40
** LOBJ_DIFF_DIRTY = 00 80
** LOBJ_SPEC_DIRTY = 01 00

* '''LObjAttenuationFlagsEnum''' :
** LOBJ_LIGHT_ATTN_NONE = 00 00
** LOBJ_LIGHT_ATTN = 00 01

=== '''LObjPoint''' : (0x14 octets) ===
* 4 octets - class_name
* 4 octets - float - x
* 4 octets - float - y
* 4 octets - float - z
* 4 octets - Inconnu

=== '''LightAnimPointer''' : (0x10 octets) ===
** 4 octets - next_offset - (LightAnimPointer)
** 4 octets - light_anim - ?
** 4 octets - position_anim - ?
** 4 octets - interst_anim - ?
Bugs dans HSDRaw - à tester

=== '''JObj''' : (0x40 octets) ===
* 4 octets - Inconnu
* 4 octets - flags
* 4 octets - child_offset (JObj)
* 4 octets - next_offset (JObj)
* 4 octets - dobj_offset (DObj)
* 4 octets [3] - float3 - rotation_xyz
* 4 octets [3] - float3 - scale_xyz
* 4 octets [3] - float3 - translation_xyz
* 4 octets - inverse_world_transform_offset (inverse world transform = Matrice de 4x3)
* 4 octets - robj_offset

Pointé par les listes dans Root Node scene_data.

* '''JObjFlagsEnum''' : (peuvent se cumuler)
** NULL = 00 00 00 00
** SKELETON = 00 00 00 01
** SKELETON_ROOT = 00 00 00 02
** ENVELOPE_MODEL = 00 00 00 04
** CLASSICAL_SCALING = 00 00 00 08
** HIDDEN = 00 00 00 10
** PTCL = 00 00 00 20
** MTX_DIRTY = 00 00 00 40
** LIGHTING = 00 00 00 80
** TEXGEN = 00 00 01 00
** BILLBOARD = 00 00 02 00
** VBILLBOARD = 00 00 04 00
** HBILLBOARD = 00 00 06 00
** RBILLBOARD = 00 00 08 00
** INSTANCE = 00 00 10 00
** PBILLBOARD = 00 00 20 00
** SPLINE = 00 00 40 00
** FLIP_IK = 00 00 80 00
** SPECULAR = 00 01 00 00
** USE_QUATERNION = 00 02 00 00
** OPA = 00 04 00 00
** XLU = 00 08 00 00
** TEXEDGE = 00 10 00 00
** JOINT1 = 00 20 00 00
** JOINT2 = 00 40 00 00
** EFFECTOR = 00 60 00 00
** USER_DEFINED_MTX = 00 80 00 00
** MTX_INDEPEND_PARENT = 01 00 00 00
** MTX_INDEPEND_SRT = 02 00 00 00
** MTX_SCALE_COMPENSATE = 04 00 00 00
** ROOT_OPA = 10 00 00 00
** ROOT_XLU = 20 00 00 00
** ROOT_TEXEDGE = 40 00 00 00

=== '''InverseWorldTransform''' : (0x30 octets) ===
* 4 octets - float - M11
* 4 octets - float - M12
* 4 octets - float - M13
* 4 octets - float - M14
* 4 octets - float - M21
* 4 octets - float - M22
* 4 octets - float - M23
* 4 octets - float - M24
* 4 octets - float - M31
* 4 octets - float - M32
* 4 octets - float - M33
* 4 octets - float - M34

=== '''DObj''' : (0x10 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - prochain DOBJ
* 4 octets - mobj_offset - material offset
* 4 octets - pobj_offset - mesh offset
Liste chaînée qui permet de récupérer l'ensemble des materials & mesh pour le JObj auquel il est lié.

=== '''MObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - render_flags - RenderFlagsEnum
* 4 octets - tobj_offset - offset de texture - peut être invalide s'il n'y a pas de texture pour le material
* 4 octets - material_offset - couleurs des materials ?
* 8 octets - PEDesc ?

Contient les textures & informations sur les couleurs des Materials.

* '''RenderFlagsEnum''' : (se cumulent)
** USER = 80 00 00 00
** CONSTANT = 00 00 00 01
** VERTEX = 00 00 00 02
** BOTH = 00 00 00 03
** DIFFUSE = 00 00 00 04
** SPECULAR = 00 00 00 08
** TEX0 = 00 00 00 10
** TEX1 = 00 00 00 20
** TEX2 = 00 00 00 40
** TEX3 = 00 00 00 80
** TEX4 = 00 00 01 00
** TEX5 = 00 00 02 00
** TEX6 = 00 00 04 00
** TEX7 = 00 00 08 00
** TOON = 00 00 10 00
** ALPHA_MAT = 00 00 20 00
** ALPHA_VTX = 00 00 40 00
** ALPHA_BOTH = 00 00 60 00
** ZOFST = 01 00 00 00
** EFFECT = 02 00 00 00
** SHADOW = 04 00 00 00
** ZMODE_ALWAYS = 08 00 00 00
** DF_ALL = 10 00 00 00
** NO_ZUPDATE = 20 00 00 00
** XLU = 40 00 00 00

=== '''TObj''' : (0x5c octets) ===
* 4 octets - ?
* 4 octets - ?
* 4 octets - tex_map_id - TexMapIdEnum
* 4 octets - gx_tex_gen_src - GXTexGenSrcEnum
* 4 octets - float - rx
* 4 octets - float - ry
* 4 octets - float - rz
* 4 octets - float - sx
* 4 octets - float - sy
* 4 octets - float - sz
* 4 octets - float - tx
* 4 octets - float - ty
* 4 octets - float - tz
* 4 octets - wrap_s - WrapEnum
* 4 octets - wrap_t - WrapEnum
* 1 octet - w_scale
* 1 octet - h_scale
* 2 octets - ?
* 1 octets - bump_map - (False = 00 ; True = 01)
* 4 bits - alpha_operation - AlphaOperationEnum
* 4 bits - color_operation - ColorOperationEnum
* 1 octet - shadow_lightmap - (False = 00 ; True = 01) (2 octets avec une Enum lightmap limite)
* 1 bit - ext_lightmap - (False = 0 ; True = 1)
* 1 bit - ambiant_lightmap - (False = 0 ; True = 1)
* 1 bit - specular_lightmap - (False = 0 ; True = 1)
* 1 bit - diffuse_lightmap (False = 0 ; True = 1)
* 4 bits - coord_type - CoordTypeEnum
* 4 octets - float - blending - utilisé quand color_operation ou alpha_operation == BLEND
* 4 octets - mag_filter - MagFilterEnum
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
Informations de Textures. Le TObj contient des informations sur les paramètres d'environnement de textures utilisés pour le rendu graphique ainsi que les offset de l'image et des données de la palette utilisés pour cette texture. Le plus important ici, c'est l'offset d'image et la palette/tlut - si l'image n'est pas indexée (RGBA, CMPR, etc.) alors la structure de description palette/tlut n'est pas utilisée.

* '''TexMapIdEnum''' :
** GX_TEXMAP0 = 00 00 00 00
** GX_TEXMAP1 = 00 00 00 01
** GX_TEXMAP2 = 00 00 00 02
** GX_TEXMAP3 = 00 00 00 03
** GX_TEXMAP4 = 00 00 00 04
** GX_TEXMAP5 = 00 00 00 05
** GX_TEXMAP6 = 00 00 00 06
** GX_TEXMAP7 = 00 00 00 07
** GX_MAX_TEXMAP = 00 00 00 08
** GX_TEXMAP_NULL = 00 00 00 09
** GX_TEXMAP_DISABLE = 00 00 00 0A

* '''GXTexGenSrcEnum''' :
** GX_TG_POS = 00 00 00 00
** GX_TG_NRM = 00 00 00 01
** GX_TG_BINRM = 00 00 00 02
** GX_TG_TANGENT = 00 00 00 03
** GX_TG_TEX0 = 00 00 00 04
** GX_TG_TEX1 = 00 00 00 05
** GX_TG_TEX2 = 00 00 00 06
** GX_TG_TEX3 = 00 00 00 07
** GX_TG_TEX4 = 00 00 00 08
** GX_TG_TEX5 = 00 00 00 09
** GX_TG_TEX6 = 00 00 00 0A
** GX_TG_TEX7 = 00 00 00 0B
** GX_TG_TEXCOORD0 = 00 00 00 0C
** GX_TG_TEXCOORD1 = 00 00 00 0D
** GX_TG_TEXCOORD2 = 00 00 00 0E
** GX_TG_TEXCOORD3 = 00 00 00 0F
** GX_TG_TEXCOORD4 = 00 00 00 10
** GX_TG_TEXCOORD5 = 00 00 00 11
** GX_TG_TEXCOORD6 = 00 00 00 12
** GX_TG_COLOR0 = 00 00 00 13
** GX_TG_COLOR1 = 00 00 00 14

* '''AlphaOperationEnum''':
** NONE = 0X
** ALPHAMASK = 1X
** BLEND = 2X
** MODULATE = 3X
** REPLACE = 4X
** PASS = 5X
** ADD = 6X
** SUB = 7X

* '''ColorOperationEnum''':
** NONE = X0
** ALPHA_MASK = X1
** RGB_MASK = X2
** BLEND = X3
** MODULATE = X4
** REPLACE = X5
** PASS = X6
** ADD = X7
** SUB = X8

* '''CoordTypeEnum''':
** UV = X0
** REFLECTION = X1
** HILIGHT = X2
** SHADOW = X3
** TOON = X4
** GRADATION = X5

* '''MagFilterEnum''':
** GX_NEAR = 00 00 00 00
** GX_LINEAR = 00 00 00 01
** GX_NEAR_MIP_NEAR = 00 00 00 02
** GX_LIN_MIP_NEAR = 00 00 00 03
** GX_NEAR_MIP_LIN = 00 00 00 04
** GX_LIN_MIP_LIN = 00 00 00 05

* '''WrapEnum''':
** CLAMP = 00 00 00 00
** REPEAT = 00 00 00 01
** MIRROR = 00 00 00 02

=== '''Material''' : (0x14 octets) ===
* 1 octets - AMB_R - (ambient)
* 1 octets - AMB_G
* 1 octets - AMB_B
* 1 octets - AMB_A
* 1 octets - DIF_R - (diffuse)
* 1 octets - DIF_G
* 1 octets - DIF_B
* 1 octets - DIF_A
* 1 octets - SPC_R - (specular)
* 1 octets - SPC_G
* 1 octets - SPC_B
* 1 octets - SPC_A
* 4 octets - float - alpha
* 4 octets - float - shininess

=== '''PObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - pobj
* 4 octets - vertex_attr_list_offset
* 2 octets - Flags - PObjFlagsEnum
* 2 octets - display_list_size - number of 0x20 (32) byte blocks occupied by display list data
* 4 octets - display_list_offset
* 4 octets - weight_list_offset - ? verifier qu'on retrouve bien le tableau d'envelope_weights à cet offset

Comme l'indique next_offset, il s'agit d'une liste de meshs à afficher pour un material donné référencé par un dobj. PObj contient les offsets de vertex attributes / display list / joint weight list ce qui suffit et permet d’interpréter et traiter les coordonnées de vertices, normals & textures.

Les attributs vertex sont les plus important - les parametres specifiés contrôlent tout : du format, de la taille des données de chaque vertex, normal et coordonnées de textures et comment ces valeurs sont dimensionnées (scaled) par rapport à la présence et la taille de chaque valeur d'index qui apparaît dans la display list information.

* '''PObjFlagsEnum''' :
** Inconnu0 = 00 01
** Inconnu1 = 00 02
** ANIM = 00 08
** SHAPE_ANIM = 10 00
** ENVELOPE = 20 00
** CULLBACK = 40 00
** CULLFRONT = 80 00

=== EnvelopeWeights : (0x? octets) ===
* 4 octets - envelope_count
* [envelope_count]:
** 4 octets - float - weight
** 4 octets - pad ?
* 4 octets - jobj_list_offset

=== not verified yet ===

* '''IMAGE_HEADER''' :
** 4 octets - image_offset - image data
** 2 octets - width
** 2 octets - height
** 4 octets - image_format

* '''PALETTE_HEADER''' : (0x10)
** 4 octets - palette_offset - palette data
** 4 octets - palette_format
** 4 octets - Inconnu
** 2 octets - color_count
** 2 octets - Inconnu

image_offset et palette_offset sont souvent partagés par plusieurs textures - savoir ça permet de retrouver toutes les informations sur les images des textures (largeur, hauteur, format), ainsi que le format et le nombre de couleurs de la palette/tlut.

Le format d'image ne détermine pas le nombre total de couleurs de la palette qu'elle utilisent. Par exemple, une image indexée sur 8 bits aurait un maximum de 256 couleurs mais seulement 136 ou 221 couleurs sont actuellement utilisées. De la sorte, la palette n'utilisera pas la taille totale qu'elle devrait utiliser.

Les images suivent la structure généralement utilisée par la GameCube :

IMAGE FORMATS :
* case 0: //i4
* case 1: //i8
* case 2: //i4a4
* case 3: //i8a8
* case 4: //r5g6b5
* case 5: //rgb5a3
* case 6: //r8g8b8a8
* case 8: //index4
* case 9: //index8
* case 0xa: //index14x2
* case 0xe: //s3tc1

Les formats indexés utilisent aussi les informations de palettes/tlut et les données peuvent apparaître en plusieurs formats :

PALETTE FORMATS :
* case 0: //ia8
* case 1: //r5g6b5
* case 2: //rgb5a3

---> "Joint Data - Accessing Geometry, Mesh, and Vertex Attributes" https://smashboards.com/threads/melee-dat-format.292603/

trad a revoir à partir de là, il faut investiguer le rendu 3D sur GameCube pour mieux comprendre

// déclaration d'un vertex et attribute information
// attr, type, cnt, data_type, flags?, file_offset
* ATTR_DATA
** 4 octets - GXAttr vtx_attr_offset - attr
** 4 octets - GXAttrType vtx_attr_type - index_type
** 4 octets - GXCompCnt comp_cnt - cnt
** 4 octets - GXCompType comp_type - data_type
** 1 octets - scale
** 1 octets - Inconnu
** 2 octets - vtx_stride
** 2 octets - data_offset

vertex_attr_offset pointe sur une liste d'attributs de vertex. Leur nombre n'est pas donné. Les données dans cette structure suivent les informations et les types conçus par l'architecture GameCube/WII et son API. La liste est terminée par une valeur spécifique de vtx_attr qui signale la fin de cette liste. Avec un accès à la doku SDK, il serait fortement conseillé de lire la section à propos des "vertex attributes and other specifications".

La valeur de vtx_attr determine le type de donnée que cet attribut désigne et peut indiquer un nombre de types natifs utilisés utilisés pour passer les données entre les interfaces logicielles et matérielles.

Les valeures possibles sont les suivantes :
* enum GXAttr (4 octets)
** GX_VA_PNMTXIDX = 0, // position/normal matrix index
** GX_VA_TEX0MTXIDX, // texture 0 matrix index
** GX_VA_TEX1MTXIDX, // texture 1 matrix index
** GX_VA_TEX2MTXIDX, // texture 2 matrix index
** GX_VA_TEX3MTXIDX, // texture 3 matrix index
** GX_VA_TEX4MTXIDX, // texture 4 matrix index
** GX_VA_TEX5MTXIDX, // texture 5 matrix index
** GX_VA_TEX6MTXIDX, // texture 6 matrix index
** GX_VA_TEX7MTXIDX, // texture 7 matrix index
** GX_VA_POS = 9, // position
** GX_VA_NRM, // normal
** GX_VA_CLR0, // color 0
** GX_VA_CLR1, // color 1
** GX_VA_TEX0, // input texture coordinate 0
** GX_VA_TEX1, // input texture coordinate 1
** GX_VA_TEX2, // input texture coordinate 2
** GX_VA_TEX3, // input texture coordinate 3
** GX_VA_TEX4, // input texture coordinate 4
** GX_VA_TEX5, // input texture coordinate 5
** GX_VA_TEX6, // input texture coordinate 6
** GX_VA_TEX7, // input texture coordinate 7

** GX_POS_MTX_ARRAY, // position matrix array pointer
** GX_NRM_MTX_ARRAY, // normal matrix array pointer
** GX_TEX_MTX_ARRAY, // texture matrix array pointer
** GX_LIGHT_ARRAY, // light parameter array pointer
** GX_VA_NBT, // normal, bi-normal, tangent
** GX_VA_MAX_ATTR, // maximum number of vertex attributes

** GX_VA_NULL = 0xff // NULL attribute (to mark end of lists)

Toutes les données nécessaires pour représenter un mesh peuvent être spécifiées et indexées d'une manière ou d'une autre. De même, GX_VA_TEX0MTXIDX, GX_VA_CLR0, et autres sont aussi possibles - les valeurs les plus fréquentes dans les données SSBM sont : GX_VA_PNMTXIDX, GX_VA_POS, GX_VA_NRM, et GX_VA_TEX0. Which is to be expected as joint matrices, vertex positions/normals, and texture coordinates respectively are probably the most basic of elements needed to display a texture mesh, whether static or animated.

When the value of vtx_attr == GX_VA_NULL (0xFF), the end of the vertex attribute array has been reached.

The vtx_attr_type values is actually associated with how the value is indexed, and can thus also determine the size of the index value within the display list data.

* 4 octets - enum GXAttrType
** GX_NONE = 0,
** GX_DIRECT,
** GX_INDEX8,
** GX_INDEX16

* Structures COLL_DATA : (données de collisions)
** 4 octets - vertex_offset (2 float par entrée correspondant à des données 2D probablement)
** 4 octets - vertex_count
** 4 octets - index_offset
** 4 octets - index_count
** 4 octets [5] - tableau inconnu
*** 2 octets - index_start
*** 2 octets - index_count
** 4 octets - Inconnu
** 4 octets - Inconnu

[[Category:Implementations]]
[[Category:Gotcha Force]]

Models

2023-10-07T13:28:52Z

Algoflash:

[[Gotcha Force | ← Gotcha Force]]

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

== Gotcha Force Models ==

Gotcha Force models work as in the game Super Smash Bros Melee (SSBM) investigated by its [https://smashboards.com/threads/melee-dat-format.292603/ community].

Un modèle est un format de fichier organisant des objets et des ressources sérialisés pour être utilisés par la librairie '''H'''al '''S'''ys'''D'''olphin ('''HSD'''), une librairie utilisée dans plusieurs jeux par Capcom. Ce sont des ressources graphiques structurées de manière hiérarchique. La présence de certaines images dans les modèles montrent à priori l'utilisation de la technique [https://learn.foundry.com/modo/901/content/help/pages/shading_lighting/shader_items/matcap.html matcap].
Par ailleurs, la librairie prendrait ses sources sur le SDK Dolphin, tel que GX ou encore MTX.

=== Fichiers concernés ===
L'ensemble des fichiers ayant dans leur titre '''_mdl''' sont des fichiers modèles correspondant au format décrit dans cette page. On notera les fichiers [[ARZ (Gotcha Force)|.arz]] qui sont des modèles compressés. Le fichier collision.arc et les fichiers tdc00.arc à tdc09.arc sont aussi des modèles.

Les fichiers modèles se retrouvent aussi dans les pzz des borgs (plxxxx.pzz) en position 004 à 009.

=== HSDRaw ===
HSDRaw, un éditeur 3D dotnet de ce format est instable sur mon Windows (algoflash). Il est cependant prouvé qu'un edit des _mdl pour commencer à l'offset 0x100 - après le préambule - permet de visualiser le fichier sur HSDRaw et d'avoir le rendu 3D du Borg (click sur le premier dossier JOBJ - puis le JOBJ dedans et double click sur le nœud en violet). Cela devrait aussi permettre d'éditer certaines propriétés ?

== Structure générale ==
Le format des modèles se découpe en plusieurs blocks. Le préambule fait 0x100 octets au tout début du fichier. Il est souvent absent. Toutes les valeurs sont en unsigned big endian, et le pad est en Nulls bytes (\x00). Les offsets trouvés après le début du Data Block (DB) sont relatifs au début du DB. La table de relocs est un tableau d'offsets de 4 octets (relatif au DB) permettant de traduire en adressage absolu les offsets des structures lors du chargement mémoire. La table de reloc permet par exemple de délimiter les structures du fait qu'il est peu probable qu'un offset pointe au milieu d'une structure.

L'ensemble des fichiers répondant à ce format on un seul root_node de type SObj (Scene data).

=== '''Préambule''' : (0x100 octets / 0 octets) ===
* 4 octets - hsd_header_offset=0x100 (toujours)
* 4 octets - bones_flags_table_offset=0x20 (toujours) - offset de la liste des flags des armatures
* 4 octets - bones_table_offset=0xC0 (toujours) - offset de la liste des armatures
* 20 octets - Pad - (toujours)
* 4 octets [32] - Inconnu (flags des armatures ?) 1 octet par flag ?
* 32 octets - Pad - (toujours)
* 32 octets - armatures ?
* 32 octets - Pad - (toujours)
=== '''HSD Header''' - (0x20 octets) ===
* 4 octets - Taille totale du fichier
* 4 octets - Taille du Data block
* 4 octets - Nombre d'entrée dans la Table de relocs
* 4 octets - root0_count
* 4 octets - root1_count
* 12 octets - Pad - (toujours)
=== '''Data block''' : ===
* JOBJ, etc. -> Ces structures sont détaillée plus loin ci-dessous.
=== '''Relocation Table''' : ===
* Tableau d'offsets de 4 octets - Offsets des structures dans le DB.
=== '''Root Nodes (2)''' : ===
* Tableau de taille 8 * root0_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
* Tableau de taille 8 * root1_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
=== '''String Table''' : ===
* Suite de strings terminées par Null au nombre de root0_count + root1_count

== Structures rencontrées dans le DB ==
Note : l'arborescence est cumulative sur les transformations pour les relations parents->enfants

Les Noeuds Racine qui ont pour nom "scene_data" pointent sur un SObj :
=== '''SObj''' : (0x10 octets) ===
* 4 octets - JObjDescs_offsets_list_offset
* 4 octets - Cameras_list_offset
* 4 octets - Lights_list_offset
* 4 octets - Fog

"scene_data" == nom du nœud racine
JObjDescs_offsets_list_offset, cameras.. pointent sur une liste d'offsets terminée par 4 octets à 0x00.
lights_list_offset pointe sur des couples (4 octets - LObj_offset ; 4 octets - light_anim_pointer_offset)

=== '''JObjDesc''' : (0x10 octets) ===
* 4 octets - root_joint_offset - JObj
* 4 octets - joint_animations_offset - ?
* 4 octets - material_animations_offset - ?
* 4 octets - shape_animations_offset - ?

=== '''CObj''' : (0x38 octets) ===
* 4 octets - flags
* 4 octets - projection_type - ProjectionTypeEnum
* 2 octets - viewport_left
* 2 octets - viewport_right
* 2 octets - viewport_top
* 2 octets - viewport_bottom
* 4 octets - proj_width
* 4 octets - proj_height
* 4 octets - eye_offset - WObj
* 4 octets - target_offset - WObj
* 4 octets - roll
* 4 octets - Inconnu
* 4 octets - float - near_clip
* 4 octets - float - far_clip
* 4 octets - float - field_of_view
* 4 octets - float - aspect
Camera object. Note : pour frustrum ou ortho, la structure est différente.

* '''ProjectionTypeEnum''':
** PERSPECTIVE = 1
** FRUSTRUM = 2
** ORTHO = 3

=== '''WObj''': (0x14 octets) ===
* 4 octets - Inconnu
* 4 octets - float - v1
* 4 octets - float - v2
* 4 octets - float - v3
* 4 octets - Inconnu

eye / target

=== '''LObj''' : (0x1c octets) ===
* 4 octets - class_name
* 4 octets - next_offset
* 2 octets - flags - LObjFlagsEnum
* 2 octets - attenuation_flags - LObjAttenuationFlagsEnum
* 1 octet - color_r
* 1 octet - color_g
* 1 octet - color_b
* 1 octet - color_alpha
* 4 octets - lobj_point_offset - position
* 4 octets - infinite_data
* 4 octets - point_spot_data
light

* '''LObjFlagsEnum''' :
** LOBJ_AMBIANT = 00 00
** LOBJ_INFINITE = 00 01
** LOBJ_POINT = 00 02
** LOBJ_SPOT = 00 03
** LOBJ_DIFFUSE = 00 04
** LOBJ_SPECULAR = 00 08
** LOBJ_ALPHA = 00 10
** LOBJ_HIDDEN = 00 20
** LOBJ_RAW_PARAM = 00 40
** LOBJ_DIFF_DIRTY = 00 80
** LOBJ_SPEC_DIRTY = 01 00

* '''LObjAttenuationFlagsEnum''' :
** LOBJ_LIGHT_ATTN_NONE = 00 00
** LOBJ_LIGHT_ATTN = 00 01

=== '''LObjPoint''' : (0x14 octets) ===
* 4 octets - class_name
* 4 octets - float - x
* 4 octets - float - y
* 4 octets - float - z
* 4 octets - Inconnu

=== '''LightAnimPointer''' : (0x10 octets) ===
** 4 octets - next_offset - (LightAnimPointer)
** 4 octets - light_anim - ?
** 4 octets - position_anim - ?
** 4 octets - interst_anim - ?
Bugs dans HSDRaw - à tester

=== '''JObj''' : (0x40 octets) ===
* 4 octets - Inconnu
* 4 octets - flags
* 4 octets - child_offset (JObj)
* 4 octets - next_offset (JObj)
* 4 octets - dobj_offset (DObj)
* 4 octets [3] - float3 - rotation_xyz
* 4 octets [3] - float3 - scale_xyz
* 4 octets [3] - float3 - translation_xyz
* 4 octets - inverse_world_transform_offset (inverse world transform = Matrice de 4x3)
* 4 octets - robj_offset

Pointé par les listes dans Root Node scene_data.

* '''JObjFlagsEnum''' : (peuvent se cumuler)
** NULL = 00 00 00 00
** SKELETON = 00 00 00 01
** SKELETON_ROOT = 00 00 00 02
** ENVELOPE_MODEL = 00 00 00 04
** CLASSICAL_SCALING = 00 00 00 08
** HIDDEN = 00 00 00 10
** PTCL = 00 00 00 20
** MTX_DIRTY = 00 00 00 40
** LIGHTING = 00 00 00 80
** TEXGEN = 00 00 01 00
** BILLBOARD = 00 00 02 00
** VBILLBOARD = 00 00 04 00
** HBILLBOARD = 00 00 06 00
** RBILLBOARD = 00 00 08 00
** INSTANCE = 00 00 10 00
** PBILLBOARD = 00 00 20 00
** SPLINE = 00 00 40 00
** FLIP_IK = 00 00 80 00
** SPECULAR = 00 01 00 00
** USE_QUATERNION = 00 02 00 00
** OPA = 00 04 00 00
** XLU = 00 08 00 00
** TEXEDGE = 00 10 00 00
** JOINT1 = 00 20 00 00
** JOINT2 = 00 40 00 00
** EFFECTOR = 00 60 00 00
** USER_DEFINED_MTX = 00 80 00 00
** MTX_INDEPEND_PARENT = 01 00 00 00
** MTX_INDEPEND_SRT = 02 00 00 00
** MTX_SCALE_COMPENSATE = 04 00 00 00
** ROOT_OPA = 10 00 00 00
** ROOT_XLU = 20 00 00 00
** ROOT_TEXEDGE = 40 00 00 00

=== '''InverseWorldTransform''' : (0x30 octets) ===
* 4 octets - float - M11
* 4 octets - float - M12
* 4 octets - float - M13
* 4 octets - float - M14
* 4 octets - float - M21
* 4 octets - float - M22
* 4 octets - float - M23
* 4 octets - float - M24
* 4 octets - float - M31
* 4 octets - float - M32
* 4 octets - float - M33
* 4 octets - float - M34

=== '''DObj''' : (0x10 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - prochain DOBJ
* 4 octets - mobj_offset - material offset
* 4 octets - pobj_offset - mesh offset
Liste chaînée qui permet de récupérer l'ensemble des materials & mesh pour le JObj auquel il est lié.

=== '''MObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - render_flags - RenderFlagsEnum
* 4 octets - tobj_offset - offset de texture - peut être invalide s'il n'y a pas de texture pour le material
* 4 octets - material_offset - couleurs des materials ?
* 8 octets - PEDesc ?

Contient les textures & informations sur les couleurs des Materials.

* '''RenderFlagsEnum''' : (se cumulent)
** USER = 80 00 00 00
** CONSTANT = 00 00 00 01
** VERTEX = 00 00 00 02
** BOTH = 00 00 00 03
** DIFFUSE = 00 00 00 04
** SPECULAR = 00 00 00 08
** TEX0 = 00 00 00 10
** TEX1 = 00 00 00 20
** TEX2 = 00 00 00 40
** TEX3 = 00 00 00 80
** TEX4 = 00 00 01 00
** TEX5 = 00 00 02 00
** TEX6 = 00 00 04 00
** TEX7 = 00 00 08 00
** TOON = 00 00 10 00
** ALPHA_MAT = 00 00 20 00
** ALPHA_VTX = 00 00 40 00
** ALPHA_BOTH = 00 00 60 00
** ZOFST = 01 00 00 00
** EFFECT = 02 00 00 00
** SHADOW = 04 00 00 00
** ZMODE_ALWAYS = 08 00 00 00
** DF_ALL = 10 00 00 00
** NO_ZUPDATE = 20 00 00 00
** XLU = 40 00 00 00

=== '''TObj''' : (0x5c octets) ===
* 4 octets - ?
* 4 octets - ?
* 4 octets - tex_map_id - TexMapIdEnum
* 4 octets - gx_tex_gen_src - GXTexGenSrcEnum
* 4 octets - float - rx
* 4 octets - float - ry
* 4 octets - float - rz
* 4 octets - float - sx
* 4 octets - float - sy
* 4 octets - float - sz
* 4 octets - float - tx
* 4 octets - float - ty
* 4 octets - float - tz
* 4 octets - wrap_s - WrapEnum
* 4 octets - wrap_t - WrapEnum
* 1 octet - w_scale
* 1 octet - h_scale
* 2 octets - ?
* 1 octets - bump_map - (False = 00 ; True = 01)
* 4 bits - alpha_operation - AlphaOperationEnum
* 4 bits - color_operation - ColorOperationEnum
* 1 octet - shadow_lightmap - (False = 00 ; True = 01) (2 octets avec une Enum lightmap limite)
* 1 bit - ext_lightmap - (False = 0 ; True = 1)
* 1 bit - ambiant_lightmap - (False = 0 ; True = 1)
* 1 bit - specular_lightmap - (False = 0 ; True = 1)
* 1 bit - diffuse_lightmap (False = 0 ; True = 1)
* 4 bits - coord_type - CoordTypeEnum
* 4 octets - float - blending - utilisé quand color_operation ou alpha_operation == BLEND
* 4 octets - mag_filter - MagFilterEnum
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
Informations de Textures. Le TObj contient des informations sur les paramètres d'environnement de textures utilisés pour le rendu graphique ainsi que les offset de l'image et des données de la palette utilisés pour cette texture. Le plus important ici, c'est l'offset d'image et la palette/tlut - si l'image n'est pas indexée (RGBA, CMPR, etc.) alors la structure de description palette/tlut n'est pas utilisée.

* '''TexMapIdEnum''' :
** GX_TEXMAP0 = 00 00 00 00
** GX_TEXMAP1 = 00 00 00 01
** GX_TEXMAP2 = 00 00 00 02
** GX_TEXMAP3 = 00 00 00 03
** GX_TEXMAP4 = 00 00 00 04
** GX_TEXMAP5 = 00 00 00 05
** GX_TEXMAP6 = 00 00 00 06
** GX_TEXMAP7 = 00 00 00 07
** GX_MAX_TEXMAP = 00 00 00 08
** GX_TEXMAP_NULL = 00 00 00 09
** GX_TEXMAP_DISABLE = 00 00 00 0A

* '''GXTexGenSrcEnum''' :
** GX_TG_POS = 00 00 00 00
** GX_TG_NRM = 00 00 00 01
** GX_TG_BINRM = 00 00 00 02
** GX_TG_TANGENT = 00 00 00 03
** GX_TG_TEX0 = 00 00 00 04
** GX_TG_TEX1 = 00 00 00 05
** GX_TG_TEX2 = 00 00 00 06
** GX_TG_TEX3 = 00 00 00 07
** GX_TG_TEX4 = 00 00 00 08
** GX_TG_TEX5 = 00 00 00 09
** GX_TG_TEX6 = 00 00 00 0A
** GX_TG_TEX7 = 00 00 00 0B
** GX_TG_TEXCOORD0 = 00 00 00 0C
** GX_TG_TEXCOORD1 = 00 00 00 0D
** GX_TG_TEXCOORD2 = 00 00 00 0E
** GX_TG_TEXCOORD3 = 00 00 00 0F
** GX_TG_TEXCOORD4 = 00 00 00 10
** GX_TG_TEXCOORD5 = 00 00 00 11
** GX_TG_TEXCOORD6 = 00 00 00 12
** GX_TG_COLOR0 = 00 00 00 13
** GX_TG_COLOR1 = 00 00 00 14

* '''AlphaOperationEnum''':
** NONE = 0X
** ALPHAMASK = 1X
** BLEND = 2X
** MODULATE = 3X
** REPLACE = 4X
** PASS = 5X
** ADD = 6X
** SUB = 7X

* '''ColorOperationEnum''':
** NONE = X0
** ALPHA_MASK = X1
** RGB_MASK = X2
** BLEND = X3
** MODULATE = X4
** REPLACE = X5
** PASS = X6
** ADD = X7
** SUB = X8

* '''CoordTypeEnum''':
** UV = X0
** REFLECTION = X1
** HILIGHT = X2
** SHADOW = X3
** TOON = X4
** GRADATION = X5

* '''MagFilterEnum''':
** GX_NEAR = 00 00 00 00
** GX_LINEAR = 00 00 00 01
** GX_NEAR_MIP_NEAR = 00 00 00 02
** GX_LIN_MIP_NEAR = 00 00 00 03
** GX_NEAR_MIP_LIN = 00 00 00 04
** GX_LIN_MIP_LIN = 00 00 00 05

* '''WrapEnum''':
** CLAMP = 00 00 00 00
** REPEAT = 00 00 00 01
** MIRROR = 00 00 00 02

=== '''Material''' : (0x14 octets) ===
* 1 octets - AMB_R - (ambient)
* 1 octets - AMB_G
* 1 octets - AMB_B
* 1 octets - AMB_A
* 1 octets - DIF_R - (diffuse)
* 1 octets - DIF_G
* 1 octets - DIF_B
* 1 octets - DIF_A
* 1 octets - SPC_R - (specular)
* 1 octets - SPC_G
* 1 octets - SPC_B
* 1 octets - SPC_A
* 4 octets - float - alpha
* 4 octets - float - shininess

=== '''PObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - pobj
* 4 octets - vertex_attr_list_offset
* 2 octets - Flags - PObjFlagsEnum
* 2 octets - display_list_size - number of 0x20 (32) byte blocks occupied by display list data
* 4 octets - display_list_offset
* 4 octets - weight_list_offset - ? verifier qu'on retrouve bien le tableau d'envelope_weights à cet offset

Comme l'indique next_offset, il s'agit d'une liste de meshs à afficher pour un material donné référencé par un dobj. PObj contient les offsets de vertex attributes / display list / joint weight list ce qui suffit et permet d’interpréter et traiter les coordonnées de vertices, normals & textures.

Les attributs vertex sont les plus important - les parametres specifiés contrôlent tout : du format, de la taille des données de chaque vertex, normal et coordonnées de textures et comment ces valeurs sont dimensionnées (scaled) par rapport à la présence et la taille de chaque valeur d'index qui apparaît dans la display list information.

* '''PObjFlagsEnum''' :
** Inconnu0 = 00 01
** Inconnu1 = 00 02
** ANIM = 00 08
** SHAPE_ANIM = 10 00
** ENVELOPE = 20 00
** CULLBACK = 40 00
** CULLFRONT = 80 00

=== EnvelopeWeights : (0x? octets) ===
* 4 octets - envelope_count
* [envelope_count]:
** 4 octets - float - weight
** 4 octets - pad ?
* 4 octets - jobj_list_offset

=== not verified yet ===

* '''IMAGE_HEADER''' :
** 4 octets - image_offset - image data
** 2 octets - width
** 2 octets - height
** 4 octets - image_format

* '''PALETTE_HEADER''' : (0x10)
** 4 octets - palette_offset - palette data
** 4 octets - palette_format
** 4 octets - Inconnu
** 2 octets - color_count
** 2 octets - Inconnu

image_offset et palette_offset sont souvent partagés par plusieurs textures - savoir ça permet de retrouver toutes les informations sur les images des textures (largeur, hauteur, format), ainsi que le format et le nombre de couleurs de la palette/tlut.

Le format d'image ne détermine pas le nombre total de couleurs de la palette qu'elle utilisent. Par exemple, une image indexée sur 8 bits aurait un maximum de 256 couleurs mais seulement 136 ou 221 couleurs sont actuellement utilisées. De la sorte, la palette n'utilisera pas la taille totale qu'elle devrait utiliser.

Les images suivent la structure généralement utilisée par la GameCube :

IMAGE FORMATS :
* case 0: //i4
* case 1: //i8
* case 2: //i4a4
* case 3: //i8a8
* case 4: //r5g6b5
* case 5: //rgb5a3
* case 6: //r8g8b8a8
* case 8: //index4
* case 9: //index8
* case 0xa: //index14x2
* case 0xe: //s3tc1

Les formats indexés utilisent aussi les informations de palettes/tlut et les données peuvent apparaître en plusieurs formats :

PALETTE FORMATS :
* case 0: //ia8
* case 1: //r5g6b5
* case 2: //rgb5a3

---> "Joint Data - Accessing Geometry, Mesh, and Vertex Attributes" https://smashboards.com/threads/melee-dat-format.292603/

trad a revoir à partir de là, il faut investiguer le rendu 3D sur GameCube pour mieux comprendre

// déclaration d'un vertex et attribute information
// attr, type, cnt, data_type, flags?, file_offset
* ATTR_DATA
** 4 octets - GXAttr vtx_attr_offset - attr
** 4 octets - GXAttrType vtx_attr_type - index_type
** 4 octets - GXCompCnt comp_cnt - cnt
** 4 octets - GXCompType comp_type - data_type
** 1 octets - scale
** 1 octets - Inconnu
** 2 octets - vtx_stride
** 2 octets - data_offset

vertex_attr_offset pointe sur une liste d'attributs de vertex. Leur nombre n'est pas donné. Les données dans cette structure suivent les informations et les types conçus par l'architecture GameCube/WII et son API. La liste est terminée par une valeur spécifique de vtx_attr qui signale la fin de cette liste. Avec un accès à la doku SDK, il serait fortement conseillé de lire la section à propos des "vertex attributes and other specifications".

La valeur de vtx_attr determine le type de donnée que cet attribut désigne et peut indiquer un nombre de types natifs utilisés utilisés pour passer les données entre les interfaces logicielles et matérielles.

Les valeures possibles sont les suivantes :
* enum GXAttr (4 octets)
** GX_VA_PNMTXIDX = 0, // position/normal matrix index
** GX_VA_TEX0MTXIDX, // texture 0 matrix index
** GX_VA_TEX1MTXIDX, // texture 1 matrix index
** GX_VA_TEX2MTXIDX, // texture 2 matrix index
** GX_VA_TEX3MTXIDX, // texture 3 matrix index
** GX_VA_TEX4MTXIDX, // texture 4 matrix index
** GX_VA_TEX5MTXIDX, // texture 5 matrix index
** GX_VA_TEX6MTXIDX, // texture 6 matrix index
** GX_VA_TEX7MTXIDX, // texture 7 matrix index
** GX_VA_POS = 9, // position
** GX_VA_NRM, // normal
** GX_VA_CLR0, // color 0
** GX_VA_CLR1, // color 1
** GX_VA_TEX0, // input texture coordinate 0
** GX_VA_TEX1, // input texture coordinate 1
** GX_VA_TEX2, // input texture coordinate 2
** GX_VA_TEX3, // input texture coordinate 3
** GX_VA_TEX4, // input texture coordinate 4
** GX_VA_TEX5, // input texture coordinate 5
** GX_VA_TEX6, // input texture coordinate 6
** GX_VA_TEX7, // input texture coordinate 7

** GX_POS_MTX_ARRAY, // position matrix array pointer
** GX_NRM_MTX_ARRAY, // normal matrix array pointer
** GX_TEX_MTX_ARRAY, // texture matrix array pointer
** GX_LIGHT_ARRAY, // light parameter array pointer
** GX_VA_NBT, // normal, bi-normal, tangent
** GX_VA_MAX_ATTR, // maximum number of vertex attributes

** GX_VA_NULL = 0xff // NULL attribute (to mark end of lists)

Toutes les données nécessaires pour représenter un mesh peuvent être spécifiées et indexées d'une manière ou d'une autre. De même, GX_VA_TEX0MTXIDX, GX_VA_CLR0, et autres sont aussi possibles - les valeurs les plus fréquentes dans les données SSBM sont : GX_VA_PNMTXIDX, GX_VA_POS, GX_VA_NRM, et GX_VA_TEX0. Which is to be expected as joint matrices, vertex positions/normals, and texture coordinates respectively are probably the most basic of elements needed to display a texture mesh, whether static or animated.

When the value of vtx_attr == GX_VA_NULL (0xFF), the end of the vertex attribute array has been reached.

The vtx_attr_type values is actually associated with how the value is indexed, and can thus also determine the size of the index value within the display list data.

* 4 octets - enum GXAttrType
** GX_NONE = 0,
** GX_DIRECT,
** GX_INDEX8,
** GX_INDEX16

* Structures COLL_DATA : (données de collisions)
** 4 octets - vertex_offset (2 float par entrée correspondant à des données 2D probablement)
** 4 octets - vertex_count
** 4 octets - index_offset
** 4 octets - index_count
** 4 octets [5] - tableau inconnu
*** 2 octets - index_start
*** 2 octets - index_count
** 4 octets - Inconnu
** 4 octets - Inconnu

[[Category:Implementations]]
[[Category:Gotcha Force]]

Models

2023-10-07T13:17:38Z

Algoflash:

[[Gotcha Force | ← Gotcha Force]]

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

== Modèles Gotcha Force ==

Les modèles Gotcha Force fonctionnent comme ceux du jeu Super Smash Bros Melee (SSBM) investigué par sa [https://smashboards.com/threads/melee-dat-format.292603/ communauté].

Un modèle est un format de fichier organisant des objets et des ressources sérialisés pour être utilisés par la librairie '''H'''al '''S'''ys'''D'''olphin ('''HSD'''), une librairie utilisée dans plusieurs jeux par Capcom. Ce sont des ressources graphiques structurées de manière hiérarchique. La présence de certaines images dans les modèles montrent à priori l'utilisation de la technique [https://learn.foundry.com/modo/901/content/help/pages/shading_lighting/shader_items/matcap.html matcap].
Par ailleurs, la librairie prendrait ses sources sur le SDK Dolphin, tel que GX ou encore MTX.

=== Fichiers concernés ===
L'ensemble des fichiers ayant dans leur titre '''_mdl''' sont des fichiers modèles correspondant au format décrit dans cette page. On notera les fichiers [[ARZ (Gotcha Force)|.arz]] qui sont des modèles compressés. Le fichier collision.arc et les fichiers tdc00.arc à tdc09.arc sont aussi des modèles.

Les fichiers modèles se retrouvent aussi dans les pzz des borgs (plxxxx.pzz) en position 004 à 009.

=== HSDRaw ===
HSDRaw, un éditeur 3D dotnet de ce format est instable sur mon Windows (algoflash). Il est cependant prouvé qu'un edit des _mdl pour commencer à l'offset 0x100 - après le préambule - permet de visualiser le fichier sur HSDRaw et d'avoir le rendu 3D du Borg (click sur le premier dossier JOBJ - puis le JOBJ dedans et double click sur le nœud en violet). Cela devrait aussi permettre d'éditer certaines propriétés ?

== Structure générale ==
Le format des modèles se découpe en plusieurs blocks. Le préambule fait 0x100 octets au tout début du fichier. Il est souvent absent. Toutes les valeurs sont en unsigned big endian, et le pad est en Nulls bytes (\x00). Les offsets trouvés après le début du Data Block (DB) sont relatifs au début du DB. La table de relocs est un tableau d'offsets de 4 octets (relatif au DB) permettant de traduire en adressage absolu les offsets des structures lors du chargement mémoire. La table de reloc permet par exemple de délimiter les structures du fait qu'il est peu probable qu'un offset pointe au milieu d'une structure.

L'ensemble des fichiers répondant à ce format on un seul root_node de type SObj (Scene data).

=== '''Préambule''' : (0x100 octets / 0 octets) ===
* 4 octets - hsd_header_offset=0x100 (toujours)
* 4 octets - bones_flags_table_offset=0x20 (toujours) - offset de la liste des flags des armatures
* 4 octets - bones_table_offset=0xC0 (toujours) - offset de la liste des armatures
* 20 octets - Pad - (toujours)
* 4 octets [32] - Inconnu (flags des armatures ?) 1 octet par flag ?
* 32 octets - Pad - (toujours)
* 32 octets - armatures ?
* 32 octets - Pad - (toujours)
=== '''HSD Header''' - (0x20 octets) ===
* 4 octets - Taille totale du fichier
* 4 octets - Taille du Data block
* 4 octets - Nombre d'entrée dans la Table de relocs
* 4 octets - root0_count
* 4 octets - root1_count
* 12 octets - Pad - (toujours)
=== '''Data block''' : ===
* JOBJ, etc. -> Ces structures sont détaillée plus loin ci-dessous.
=== '''Relocation Table''' : ===
* Tableau d'offsets de 4 octets - Offsets des structures dans le DB.
=== '''Root Nodes (2)''' : ===
* Tableau de taille 8 * root0_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
* Tableau de taille 8 * root1_count
** 4 octets - root_offset - relatif au DB
** 4 octets - string_table_offset - relatif à la StringTable
=== '''String Table''' : ===
* Suite de strings terminées par Null au nombre de root0_count + root1_count

== Structures rencontrées dans le DB ==
Note : l'arborescence est cumulative sur les transformations pour les relations parents->enfants

Les Noeuds Racine qui ont pour nom "scene_data" pointent sur un SObj :
=== '''SObj''' : (0x10 octets) ===
* 4 octets - JObjDescs_offsets_list_offset
* 4 octets - Cameras_list_offset
* 4 octets - Lights_list_offset
* 4 octets - Fog

"scene_data" == nom du nœud racine
JObjDescs_offsets_list_offset, cameras.. pointent sur une liste d'offsets terminée par 4 octets à 0x00.
lights_list_offset pointe sur des couples (4 octets - LObj_offset ; 4 octets - light_anim_pointer_offset)

=== '''JObjDesc''' : (0x10 octets) ===
* 4 octets - root_joint_offset - JObj
* 4 octets - joint_animations_offset - ?
* 4 octets - material_animations_offset - ?
* 4 octets - shape_animations_offset - ?

=== '''CObj''' : (0x38 octets) ===
* 4 octets - flags
* 4 octets - projection_type - ProjectionTypeEnum
* 2 octets - viewport_left
* 2 octets - viewport_right
* 2 octets - viewport_top
* 2 octets - viewport_bottom
* 4 octets - proj_width
* 4 octets - proj_height
* 4 octets - eye_offset - WObj
* 4 octets - target_offset - WObj
* 4 octets - roll
* 4 octets - Inconnu
* 4 octets - float - near_clip
* 4 octets - float - far_clip
* 4 octets - float - field_of_view
* 4 octets - float - aspect
Camera object. Note : pour frustrum ou ortho, la structure est différente.

* '''ProjectionTypeEnum''':
** PERSPECTIVE = 1
** FRUSTRUM = 2
** ORTHO = 3

=== '''WObj''': (0x14 octets) ===
* 4 octets - Inconnu
* 4 octets - float - v1
* 4 octets - float - v2
* 4 octets - float - v3
* 4 octets - Inconnu

eye / target

=== '''LObj''' : (0x1c octets) ===
* 4 octets - class_name
* 4 octets - next_offset
* 2 octets - flags - LObjFlagsEnum
* 2 octets - attenuation_flags - LObjAttenuationFlagsEnum
* 1 octet - color_r
* 1 octet - color_g
* 1 octet - color_b
* 1 octet - color_alpha
* 4 octets - lobj_point_offset - position
* 4 octets - infinite_data
* 4 octets - point_spot_data
light

* '''LObjFlagsEnum''' :
** LOBJ_AMBIANT = 00 00
** LOBJ_INFINITE = 00 01
** LOBJ_POINT = 00 02
** LOBJ_SPOT = 00 03
** LOBJ_DIFFUSE = 00 04
** LOBJ_SPECULAR = 00 08
** LOBJ_ALPHA = 00 10
** LOBJ_HIDDEN = 00 20
** LOBJ_RAW_PARAM = 00 40
** LOBJ_DIFF_DIRTY = 00 80
** LOBJ_SPEC_DIRTY = 01 00

* '''LObjAttenuationFlagsEnum''' :
** LOBJ_LIGHT_ATTN_NONE = 00 00
** LOBJ_LIGHT_ATTN = 00 01

=== '''LObjPoint''' : (0x14 octets) ===
* 4 octets - class_name
* 4 octets - float - x
* 4 octets - float - y
* 4 octets - float - z
* 4 octets - Inconnu

=== '''LightAnimPointer''' : (0x10 octets) ===
** 4 octets - next_offset - (LightAnimPointer)
** 4 octets - light_anim - ?
** 4 octets - position_anim - ?
** 4 octets - interst_anim - ?
Bugs dans HSDRaw - à tester

=== '''JObj''' : (0x40 octets) ===
* 4 octets - Inconnu
* 4 octets - flags
* 4 octets - child_offset (JObj)
* 4 octets - next_offset (JObj)
* 4 octets - dobj_offset (DObj)
* 4 octets [3] - float3 - rotation_xyz
* 4 octets [3] - float3 - scale_xyz
* 4 octets [3] - float3 - translation_xyz
* 4 octets - inverse_world_transform_offset (inverse world transform = Matrice de 4x3)
* 4 octets - robj_offset

Pointé par les listes dans Root Node scene_data.

* '''JObjFlagsEnum''' : (peuvent se cumuler)
** NULL = 00 00 00 00
** SKELETON = 00 00 00 01
** SKELETON_ROOT = 00 00 00 02
** ENVELOPE_MODEL = 00 00 00 04
** CLASSICAL_SCALING = 00 00 00 08
** HIDDEN = 00 00 00 10
** PTCL = 00 00 00 20
** MTX_DIRTY = 00 00 00 40
** LIGHTING = 00 00 00 80
** TEXGEN = 00 00 01 00
** BILLBOARD = 00 00 02 00
** VBILLBOARD = 00 00 04 00
** HBILLBOARD = 00 00 06 00
** RBILLBOARD = 00 00 08 00
** INSTANCE = 00 00 10 00
** PBILLBOARD = 00 00 20 00
** SPLINE = 00 00 40 00
** FLIP_IK = 00 00 80 00
** SPECULAR = 00 01 00 00
** USE_QUATERNION = 00 02 00 00
** OPA = 00 04 00 00
** XLU = 00 08 00 00
** TEXEDGE = 00 10 00 00
** JOINT1 = 00 20 00 00
** JOINT2 = 00 40 00 00
** EFFECTOR = 00 60 00 00
** USER_DEFINED_MTX = 00 80 00 00
** MTX_INDEPEND_PARENT = 01 00 00 00
** MTX_INDEPEND_SRT = 02 00 00 00
** MTX_SCALE_COMPENSATE = 04 00 00 00
** ROOT_OPA = 10 00 00 00
** ROOT_XLU = 20 00 00 00
** ROOT_TEXEDGE = 40 00 00 00

=== '''InverseWorldTransform''' : (0x30 octets) ===
* 4 octets - float - M11
* 4 octets - float - M12
* 4 octets - float - M13
* 4 octets - float - M14
* 4 octets - float - M21
* 4 octets - float - M22
* 4 octets - float - M23
* 4 octets - float - M24
* 4 octets - float - M31
* 4 octets - float - M32
* 4 octets - float - M33
* 4 octets - float - M34

=== '''DObj''' : (0x10 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - prochain DOBJ
* 4 octets - mobj_offset - material offset
* 4 octets - pobj_offset - mesh offset
Liste chaînée qui permet de récupérer l'ensemble des materials & mesh pour le JObj auquel il est lié.

=== '''MObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - render_flags - RenderFlagsEnum
* 4 octets - tobj_offset - offset de texture - peut être invalide s'il n'y a pas de texture pour le material
* 4 octets - material_offset - couleurs des materials ?
* 8 octets - PEDesc ?

Contient les textures & informations sur les couleurs des Materials.

* '''RenderFlagsEnum''' : (se cumulent)
** USER = 80 00 00 00
** CONSTANT = 00 00 00 01
** VERTEX = 00 00 00 02
** BOTH = 00 00 00 03
** DIFFUSE = 00 00 00 04
** SPECULAR = 00 00 00 08
** TEX0 = 00 00 00 10
** TEX1 = 00 00 00 20
** TEX2 = 00 00 00 40
** TEX3 = 00 00 00 80
** TEX4 = 00 00 01 00
** TEX5 = 00 00 02 00
** TEX6 = 00 00 04 00
** TEX7 = 00 00 08 00
** TOON = 00 00 10 00
** ALPHA_MAT = 00 00 20 00
** ALPHA_VTX = 00 00 40 00
** ALPHA_BOTH = 00 00 60 00
** ZOFST = 01 00 00 00
** EFFECT = 02 00 00 00
** SHADOW = 04 00 00 00
** ZMODE_ALWAYS = 08 00 00 00
** DF_ALL = 10 00 00 00
** NO_ZUPDATE = 20 00 00 00
** XLU = 40 00 00 00

=== '''TObj''' : (0x5c octets) ===
* 4 octets - ?
* 4 octets - ?
* 4 octets - tex_map_id - TexMapIdEnum
* 4 octets - gx_tex_gen_src - GXTexGenSrcEnum
* 4 octets - float - rx
* 4 octets - float - ry
* 4 octets - float - rz
* 4 octets - float - sx
* 4 octets - float - sy
* 4 octets - float - sz
* 4 octets - float - tx
* 4 octets - float - ty
* 4 octets - float - tz
* 4 octets - wrap_s - WrapEnum
* 4 octets - wrap_t - WrapEnum
* 1 octet - w_scale
* 1 octet - h_scale
* 2 octets - ?
* 1 octets - bump_map - (False = 00 ; True = 01)
* 4 bits - alpha_operation - AlphaOperationEnum
* 4 bits - color_operation - ColorOperationEnum
* 1 octet - shadow_lightmap - (False = 00 ; True = 01) (2 octets avec une Enum lightmap limite)
* 1 bit - ext_lightmap - (False = 0 ; True = 1)
* 1 bit - ambiant_lightmap - (False = 0 ; True = 1)
* 1 bit - specular_lightmap - (False = 0 ; True = 1)
* 1 bit - diffuse_lightmap (False = 0 ; True = 1)
* 4 bits - coord_type - CoordTypeEnum
* 4 octets - float - blending - utilisé quand color_operation ou alpha_operation == BLEND
* 4 octets - mag_filter - MagFilterEnum
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
* 4 octets - ?
Informations de Textures. Le TObj contient des informations sur les paramètres d'environnement de textures utilisés pour le rendu graphique ainsi que les offset de l'image et des données de la palette utilisés pour cette texture. Le plus important ici, c'est l'offset d'image et la palette/tlut - si l'image n'est pas indexée (RGBA, CMPR, etc.) alors la structure de description palette/tlut n'est pas utilisée.

* '''TexMapIdEnum''' :
** GX_TEXMAP0 = 00 00 00 00
** GX_TEXMAP1 = 00 00 00 01
** GX_TEXMAP2 = 00 00 00 02
** GX_TEXMAP3 = 00 00 00 03
** GX_TEXMAP4 = 00 00 00 04
** GX_TEXMAP5 = 00 00 00 05
** GX_TEXMAP6 = 00 00 00 06
** GX_TEXMAP7 = 00 00 00 07
** GX_MAX_TEXMAP = 00 00 00 08
** GX_TEXMAP_NULL = 00 00 00 09
** GX_TEXMAP_DISABLE = 00 00 00 0A

* '''GXTexGenSrcEnum''' :
** GX_TG_POS = 00 00 00 00
** GX_TG_NRM = 00 00 00 01
** GX_TG_BINRM = 00 00 00 02
** GX_TG_TANGENT = 00 00 00 03
** GX_TG_TEX0 = 00 00 00 04
** GX_TG_TEX1 = 00 00 00 05
** GX_TG_TEX2 = 00 00 00 06
** GX_TG_TEX3 = 00 00 00 07
** GX_TG_TEX4 = 00 00 00 08
** GX_TG_TEX5 = 00 00 00 09
** GX_TG_TEX6 = 00 00 00 0A
** GX_TG_TEX7 = 00 00 00 0B
** GX_TG_TEXCOORD0 = 00 00 00 0C
** GX_TG_TEXCOORD1 = 00 00 00 0D
** GX_TG_TEXCOORD2 = 00 00 00 0E
** GX_TG_TEXCOORD3 = 00 00 00 0F
** GX_TG_TEXCOORD4 = 00 00 00 10
** GX_TG_TEXCOORD5 = 00 00 00 11
** GX_TG_TEXCOORD6 = 00 00 00 12
** GX_TG_COLOR0 = 00 00 00 13
** GX_TG_COLOR1 = 00 00 00 14

* '''AlphaOperationEnum''':
** NONE = 0X
** ALPHAMASK = 1X
** BLEND = 2X
** MODULATE = 3X
** REPLACE = 4X
** PASS = 5X
** ADD = 6X
** SUB = 7X

* '''ColorOperationEnum''':
** NONE = X0
** ALPHA_MASK = X1
** RGB_MASK = X2
** BLEND = X3
** MODULATE = X4
** REPLACE = X5
** PASS = X6
** ADD = X7
** SUB = X8

* '''CoordTypeEnum''':
** UV = X0
** REFLECTION = X1
** HILIGHT = X2
** SHADOW = X3
** TOON = X4
** GRADATION = X5

* '''MagFilterEnum''':
** GX_NEAR = 00 00 00 00
** GX_LINEAR = 00 00 00 01
** GX_NEAR_MIP_NEAR = 00 00 00 02
** GX_LIN_MIP_NEAR = 00 00 00 03
** GX_NEAR_MIP_LIN = 00 00 00 04
** GX_LIN_MIP_LIN = 00 00 00 05

* '''WrapEnum''':
** CLAMP = 00 00 00 00
** REPEAT = 00 00 00 01
** MIRROR = 00 00 00 02

=== '''Material''' : (0x14 octets) ===
* 1 octets - AMB_R - (ambient)
* 1 octets - AMB_G
* 1 octets - AMB_B
* 1 octets - AMB_A
* 1 octets - DIF_R - (diffuse)
* 1 octets - DIF_G
* 1 octets - DIF_B
* 1 octets - DIF_A
* 1 octets - SPC_R - (specular)
* 1 octets - SPC_G
* 1 octets - SPC_B
* 1 octets - SPC_A
* 4 octets - float - alpha
* 4 octets - float - shininess

=== '''PObj''' : (0x18 octets) ===
* 4 octets - Inconnu
* 4 octets - next_offset - pobj
* 4 octets - vertex_attr_list_offset
* 2 octets - Flags - PObjFlagsEnum
* 2 octets - display_list_size - number of 0x20 (32) byte blocks occupied by display list data
* 4 octets - display_list_offset
* 4 octets - weight_list_offset - ? verifier qu'on retrouve bien le tableau d'envelope_weights à cet offset

Comme l'indique next_offset, il s'agit d'une liste de meshs à afficher pour un material donné référencé par un dobj. PObj contient les offsets de vertex attributes / display list / joint weight list ce qui suffit et permet d’interpréter et traiter les coordonnées de vertices, normals & textures.

Les attributs vertex sont les plus important - les parametres specifiés contrôlent tout : du format, de la taille des données de chaque vertex, normal et coordonnées de textures et comment ces valeurs sont dimensionnées (scaled) par rapport à la présence et la taille de chaque valeur d'index qui apparaît dans la display list information.

* '''PObjFlagsEnum''' :
** Inconnu0 = 00 01
** Inconnu1 = 00 02
** ANIM = 00 08
** SHAPE_ANIM = 10 00
** ENVELOPE = 20 00
** CULLBACK = 40 00
** CULLFRONT = 80 00

=== EnvelopeWeights : (0x? octets) ===
* 4 octets - envelope_count
* [envelope_count]:
** 4 octets - float - weight
** 4 octets - pad ?
* 4 octets - jobj_list_offset

=== not verified yet ===

* '''IMAGE_HEADER''' :
** 4 octets - image_offset - image data
** 2 octets - width
** 2 octets - height
** 4 octets - image_format

* '''PALETTE_HEADER''' : (0x10)
** 4 octets - palette_offset - palette data
** 4 octets - palette_format
** 4 octets - Inconnu
** 2 octets - color_count
** 2 octets - Inconnu

image_offset et palette_offset sont souvent partagés par plusieurs textures - savoir ça permet de retrouver toutes les informations sur les images des textures (largeur, hauteur, format), ainsi que le format et le nombre de couleurs de la palette/tlut.

Le format d'image ne détermine pas le nombre total de couleurs de la palette qu'elle utilisent. Par exemple, une image indexée sur 8 bits aurait un maximum de 256 couleurs mais seulement 136 ou 221 couleurs sont actuellement utilisées. De la sorte, la palette n'utilisera pas la taille totale qu'elle devrait utiliser.

Les images suivent la structure généralement utilisée par la GameCube :

IMAGE FORMATS :
* case 0: //i4
* case 1: //i8
* case 2: //i4a4
* case 3: //i8a8
* case 4: //r5g6b5
* case 5: //rgb5a3
* case 6: //r8g8b8a8
* case 8: //index4
* case 9: //index8
* case 0xa: //index14x2
* case 0xe: //s3tc1

Les formats indexés utilisent aussi les informations de palettes/tlut et les données peuvent apparaître en plusieurs formats :

PALETTE FORMATS :
* case 0: //ia8
* case 1: //r5g6b5
* case 2: //rgb5a3

---> "Joint Data - Accessing Geometry, Mesh, and Vertex Attributes" https://smashboards.com/threads/melee-dat-format.292603/

trad a revoir à partir de là, il faut investiguer le rendu 3D sur GameCube pour mieux comprendre

// déclaration d'un vertex et attribute information
// attr, type, cnt, data_type, flags?, file_offset
* ATTR_DATA
** 4 octets - GXAttr vtx_attr_offset - attr
** 4 octets - GXAttrType vtx_attr_type - index_type
** 4 octets - GXCompCnt comp_cnt - cnt
** 4 octets - GXCompType comp_type - data_type
** 1 octets - scale
** 1 octets - Inconnu
** 2 octets - vtx_stride
** 2 octets - data_offset

vertex_attr_offset pointe sur une liste d'attributs de vertex. Leur nombre n'est pas donné. Les données dans cette structure suivent les informations et les types conçus par l'architecture GameCube/WII et son API. La liste est terminée par une valeur spécifique de vtx_attr qui signale la fin de cette liste. Avec un accès à la doku SDK, il serait fortement conseillé de lire la section à propos des "vertex attributes and other specifications".

La valeur de vtx_attr determine le type de donnée que cet attribut désigne et peut indiquer un nombre de types natifs utilisés utilisés pour passer les données entre les interfaces logicielles et matérielles.

Les valeures possibles sont les suivantes :
* enum GXAttr (4 octets)
** GX_VA_PNMTXIDX = 0, // position/normal matrix index
** GX_VA_TEX0MTXIDX, // texture 0 matrix index
** GX_VA_TEX1MTXIDX, // texture 1 matrix index
** GX_VA_TEX2MTXIDX, // texture 2 matrix index
** GX_VA_TEX3MTXIDX, // texture 3 matrix index
** GX_VA_TEX4MTXIDX, // texture 4 matrix index
** GX_VA_TEX5MTXIDX, // texture 5 matrix index
** GX_VA_TEX6MTXIDX, // texture 6 matrix index
** GX_VA_TEX7MTXIDX, // texture 7 matrix index
** GX_VA_POS = 9, // position
** GX_VA_NRM, // normal
** GX_VA_CLR0, // color 0
** GX_VA_CLR1, // color 1
** GX_VA_TEX0, // input texture coordinate 0
** GX_VA_TEX1, // input texture coordinate 1
** GX_VA_TEX2, // input texture coordinate 2
** GX_VA_TEX3, // input texture coordinate 3
** GX_VA_TEX4, // input texture coordinate 4
** GX_VA_TEX5, // input texture coordinate 5
** GX_VA_TEX6, // input texture coordinate 6
** GX_VA_TEX7, // input texture coordinate 7

** GX_POS_MTX_ARRAY, // position matrix array pointer
** GX_NRM_MTX_ARRAY, // normal matrix array pointer
** GX_TEX_MTX_ARRAY, // texture matrix array pointer
** GX_LIGHT_ARRAY, // light parameter array pointer
** GX_VA_NBT, // normal, bi-normal, tangent
** GX_VA_MAX_ATTR, // maximum number of vertex attributes

** GX_VA_NULL = 0xff // NULL attribute (to mark end of lists)

Toutes les données nécessaires pour représenter un mesh peuvent être spécifiées et indexées d'une manière ou d'une autre. De même, GX_VA_TEX0MTXIDX, GX_VA_CLR0, et autres sont aussi possibles - les valeurs les plus fréquentes dans les données SSBM sont : GX_VA_PNMTXIDX, GX_VA_POS, GX_VA_NRM, et GX_VA_TEX0. Which is to be expected as joint matrices, vertex positions/normals, and texture coordinates respectively are probably the most basic of elements needed to display a texture mesh, whether static or animated.

When the value of vtx_attr == GX_VA_NULL (0xFF), the end of the vertex attribute array has been reached.

The vtx_attr_type values is actually associated with how the value is indexed, and can thus also determine the size of the index value within the display list data.

* 4 octets - enum GXAttrType
** GX_NONE = 0,
** GX_DIRECT,
** GX_INDEX8,
** GX_INDEX16

* Structures COLL_DATA : (données de collisions)
** 4 octets - vertex_offset (2 float par entrée correspondant à des données 2D probablement)
** 4 octets - vertex_count
** 4 octets - index_offset
** 4 octets - index_count
** 4 octets [5] - tableau inconnu
*** 2 octets - index_start
*** 2 octets - index_count
** 4 octets - Inconnu
** 4 octets - Inconnu

[[Category:Implementations]]
[[Category:Gotcha Force]]

Implementations

2023-10-07T13:13:17Z

Algoflash: /* Borgs GET system */

[[Gotcha Force | ← Gotcha Force]]

<div style="text-align: center;">
<div style="color: rgb(241, 196, 15);">This section is a work in progress.</div>
<div style="color: rgb(241, 196, 15); text-align: center;">Research is still needed and some paragraphs may be wrong.</div>
</div>

== Implementation of the game elements ==

=== Borg ===
==== GUI elements ====
==== Borgs GET system ====
CrystalPixel who found the values.

During a fight in Story Mode, when fighting an enemy borg for a given colour you have two values:
* The GET value
* The GET counter

When you eliminate the enemy borg of a given colour, you have its GET counter which increments by a random value between 1 and 16. When the GET counter is greater than or equal to the GET value, we get the borg / Data Crystal at the end of the battle. Then the GET counter of this borg / colour combination is reset to 0. If one leaves or loses the battle, all GET counters are reset to the value they had before the battle started.

For a large number of borgs it is then impossible to get them without having fought a certain amount. For example, Gold Death Borg Alpha has a GET value of 40. In two battles, for example, you can only get 36 in the best case.

1 borg has a GET value of -1:
* Galactic Emperor

The rest has no GET value:
* Cyber Death Dragon (Fusion Borg)
* Machine Dragon
* Cyber Machine Seiryu (Fusion Borg)
* Cyber Machine Suzaku (Fusion Borg)
* Cyber Machine Byakko (Fusion Borg)
* Cyber Machine Genbu (Fusion Borg)
* G Red (One of the borg we have)
* Neo G Red (One of the borgs we have)
* G Black (It is obtained in a special event)

By changing the GET value to a positive value, you can get the borgs in the scenario: Galactic Emperor for example.

The list of GET values for the EU version is available on [https://github.com/Virtual-World-RE/NeoGF/blob/main/data/eu_borgs_GET_values.csv github].

==== Files and operation ====
Borgs are implemented with a set of files, each with a specific function. These files are duplicated in the pzz of the borg and in the afs_data. The different _mdl define the different colours of the Borg. It seems that they are used with additional values in other files (the displays are not always correct when exchanging positions in the iso). The main _mdl is loaded from the pzz (collection or story menu). <span style="color: rgb(241, 196, 15);">One theory would be that part of the duplicate files would be used to load enemies and the other part allies.</span>

For each borg we have:<br>
plxxxx.pzz
├─ 000 file [[Borg - data file|plxxxxdata.bin]] -> always present
├─ 001? -> often not present
├─ 002 file plxxxxhit.bin -> always present
├─ 003 file [[Motions|plxxxxmot.bin]] -> often not present
├─ 004 file [[Models|plxxxx_mdl.arc]] -> always present
├─ 005 file [[Models|plxxxxb_mdl.arc]] -> always present -> blue model
├─ 006 file [[Models|plxxxxg_mdl.arc]] -> always present
├─ 007 file [[Models|plxxxxs_mdl.arc]] -> always present -> silver model
├─ 008 file [[Models|plxxxxc_mdl.arc]] -> always present
├─ 009 file [[Models|plxxxxk_mdl.arc]] -> always present -> black model
├─ 010 [[TPL (File format)|TPL]] -> name of the borg in Japanese
├─ 011 [[TPL (File format)|TPL]] -> name of the borg in Japanese (small format)
├─ 012 [[TPL (File format)|TPL]] -> borg name in the language of the game
└─ 013 file mnxxxx.tpl -> [[TPL (File format)|TPL]] -> name of the borg in the game language (small format)
[[Borg - data file|plxxxxdata.bin]] -> file can be named data2 or data3 (only one of the three is present), sometimes missing from the afs_data
plxxxxhit.bin -> always present in the afs_data and pzz
[[Motions|plxxxxmot.bin]] -> often absent from the afs_data
[[Models|plxxxx_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxb_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxg_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxs_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxc_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxk_mdl.arc]] -> sometimes missing from afs_data
mnxxxx.tpl

Position 002: for borg pl0507 and pl0513, file 2 and hit differ (USA/NTSC version)

Position 003: for the borg pl0009, file 3 and the word differ (USA/NTSC version) (MOT - ''Mot'''ion) - It can be observed that for these files, there are references that could make one think of ''plxxxx_xx_animjoint''. The investigation conducted by the [https://smashboards.com/threads/melee-dat-format.292603/ Smash Bros Brawl] community shows a similar file structure. This is another version of HSD (the basic structures are the same).

Position 004 to 009: contain '''scene_data''' at the end of the data section, and are ''''"Scene"'' files (HSDLib) which contain lights, cameras, vertices, bones in the manner of a .blend.

Position 004 to 008: files with values corresponding to 3D. In particular, we can cite '''pl0300.pzz''' where they have a header <span style="color: rgb(241, 196, 15);">with flags</span> as well as an adjustable padding if need be to have more elements '''For example for '''pl0629.pzz''' the amount <span style="color: rgb(241, 196, 15);">of flags</span> in the headers is more consistent.'' The origin <span style="color: rgb(241, 196, 15);">of the flags</span> and values in the header is currently unknown but these header fields <span style="color: rgb(241, 196, 15);">might constitute a list of available meshes in the file.</span> The software used to read the files in position 004 to 009 in plxxxx.pzz are 3D Model Researcher and HSDRawLibrary.

'''Unimplemented borgs''': pl0803 - pl080b - pl0f07<br>
Only the pl0803hit.bin and pl080bhit.bin files remain, and none of their associated files (notably, no associated pzz), which indicates that they are remnants of unimplemented borgs... Also the pzz pl0f07 has no hit file, no 4 internal TPLs (but 4 empty files instead) and just its pl0f07_mdl.arc file, which indicates that this borg is not implemented either (USA/NTSC version).

The 2 dpxxxx.pzz files are similar files to plxxxx.pzz but without the final TPL files. Their usefulness is still to be determined.

Files dpxxxx.pzz (2)
├─ 000 -> [[Borg - data file|plxxxxdata.bin]] from afs_data
├─ 001 -> empty file
├─ 002 -> plxxxxhit.bin from the afs_data
├─ 003 -> [[Motions|plxxxxmot.bin]] from the afs_data
├─ 004 -> [[Models|plxxxx_mdl.arc]] of the afs_data
├─ 005 -> [[Models|plxxxxb_mdl.arc]] of the afs_data
├─ 006 -> [[Models|plxxxxg_mdl.arc]] of the afs_data
├─ 007 -> [[Models|plxxxxs_mdl.arc]] of the afs_data
├─ 008 -> [[Models|plxxxxc_mdl.arc]] of the afs_data
└─ 009 -> [[Models|plxxxxk_mdl.arc]] of the afs_data

==== Memory backups ====

=== Data Crystals ===
The itxxxx_mdl.arz, once unpacked with pzztool.py are the templates for the data crystals.

==== Graphical interface elements ====

unitall_mdl.arc contains all the borg thumbnails used in the force creation/modification menu as well as in the post-combat scene showing which team/borgs VS team/borgs, and in the data crystals.

==== Files and operation ====
==== Memory saves ====

[[Category:Implementations]]
[[Category:Gotcha Force]]

Implementations

2023-10-07T13:12:47Z

Algoflash: /* Borgs GET system */

[[Gotcha Force | ← Gotcha Force]]

<div style="text-align: center;">
<div style="color: rgb(241, 196, 15);">This section is a work in progress.</div>
<div style="color: rgb(241, 196, 15); text-align: center;">Research is still needed and some paragraphs may be wrong.</div>
</div>

== Implementation of the game elements ==

=== Borg ===
==== GUI elements ====
==== Borgs GET system ====
CrystalPixel who found the values.

During a fight in Story Mode, when fighting an enemy borg for a given colour you have two values:
* The GET value
* The GET counter

When you eliminate the enemy borg of a given colour, you have its GET counter which increments by a random value between 1 and 16. When the GET counter is greater than or equal to the GET value, we get the borg / Data Crystal at the end of the battle. Then the GET counter of this borg / colour combination is reset to 0. If one leaves or loses the battle, all GET counters are reset to the value they had before the battle started.

For a large number of borgs it is then impossible to get them without having fought a certain amount. For example, Gold Death Borg Alpha has a GET value of 40. In two battles, for example, you can only get 36 in the best case.

1 borg has a GET value of -1:
* Galactic Emperor

The rest has no GET value:
* Cyber Death Dragon (Fusion Borg)
* Machine Dragon
* Cyber Machine Seiryu (Fusion Borg)
* Cyber Machine Suzaku (Fusion Borg)
* Cyber Machine Byakko (Fusion Borg)
* Cyber Machine Genbu (Fusion Borg)
* G Red (One of the borg we have)
* Neo G Red (One of the borgs we have)
* G Black (It is obtained in a special event)

By changing the GET value to a positive value, you can get the borgs in the scenario: Galactic Emperor for example.

The list of GET values for the EU version is available at [https://github.com/Virtual-World-RE/NeoGF/blob/main/data/eu_borgs_GET_values.csv github].

==== Files and operation ====
Borgs are implemented with a set of files, each with a specific function. These files are duplicated in the pzz of the borg and in the afs_data. The different _mdl define the different colours of the Borg. It seems that they are used with additional values in other files (the displays are not always correct when exchanging positions in the iso). The main _mdl is loaded from the pzz (collection or story menu). <span style="color: rgb(241, 196, 15);">One theory would be that part of the duplicate files would be used to load enemies and the other part allies.</span>

For each borg we have:<br>
plxxxx.pzz
├─ 000 file [[Borg - data file|plxxxxdata.bin]] -> always present
├─ 001? -> often not present
├─ 002 file plxxxxhit.bin -> always present
├─ 003 file [[Motions|plxxxxmot.bin]] -> often not present
├─ 004 file [[Models|plxxxx_mdl.arc]] -> always present
├─ 005 file [[Models|plxxxxb_mdl.arc]] -> always present -> blue model
├─ 006 file [[Models|plxxxxg_mdl.arc]] -> always present
├─ 007 file [[Models|plxxxxs_mdl.arc]] -> always present -> silver model
├─ 008 file [[Models|plxxxxc_mdl.arc]] -> always present
├─ 009 file [[Models|plxxxxk_mdl.arc]] -> always present -> black model
├─ 010 [[TPL (File format)|TPL]] -> name of the borg in Japanese
├─ 011 [[TPL (File format)|TPL]] -> name of the borg in Japanese (small format)
├─ 012 [[TPL (File format)|TPL]] -> borg name in the language of the game
└─ 013 file mnxxxx.tpl -> [[TPL (File format)|TPL]] -> name of the borg in the game language (small format)
[[Borg - data file|plxxxxdata.bin]] -> file can be named data2 or data3 (only one of the three is present), sometimes missing from the afs_data
plxxxxhit.bin -> always present in the afs_data and pzz
[[Motions|plxxxxmot.bin]] -> often absent from the afs_data
[[Models|plxxxx_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxb_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxg_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxs_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxc_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxk_mdl.arc]] -> sometimes missing from afs_data
mnxxxx.tpl

Position 002: for borg pl0507 and pl0513, file 2 and hit differ (USA/NTSC version)

Position 003: for the borg pl0009, file 3 and the word differ (USA/NTSC version) (MOT - ''Mot'''ion) - It can be observed that for these files, there are references that could make one think of ''plxxxx_xx_animjoint''. The investigation conducted by the [https://smashboards.com/threads/melee-dat-format.292603/ Smash Bros Brawl] community shows a similar file structure. This is another version of HSD (the basic structures are the same).

Position 004 to 009: contain '''scene_data''' at the end of the data section, and are ''''"Scene"'' files (HSDLib) which contain lights, cameras, vertices, bones in the manner of a .blend.

Position 004 to 008: files with values corresponding to 3D. In particular, we can cite '''pl0300.pzz''' where they have a header <span style="color: rgb(241, 196, 15);">with flags</span> as well as an adjustable padding if need be to have more elements '''For example for '''pl0629.pzz''' the amount <span style="color: rgb(241, 196, 15);">of flags</span> in the headers is more consistent.'' The origin <span style="color: rgb(241, 196, 15);">of the flags</span> and values in the header is currently unknown but these header fields <span style="color: rgb(241, 196, 15);">might constitute a list of available meshes in the file.</span> The software used to read the files in position 004 to 009 in plxxxx.pzz are 3D Model Researcher and HSDRawLibrary.

'''Unimplemented borgs''': pl0803 - pl080b - pl0f07<br>
Only the pl0803hit.bin and pl080bhit.bin files remain, and none of their associated files (notably, no associated pzz), which indicates that they are remnants of unimplemented borgs... Also the pzz pl0f07 has no hit file, no 4 internal TPLs (but 4 empty files instead) and just its pl0f07_mdl.arc file, which indicates that this borg is not implemented either (USA/NTSC version).

The 2 dpxxxx.pzz files are similar files to plxxxx.pzz but without the final TPL files. Their usefulness is still to be determined.

Files dpxxxx.pzz (2)
├─ 000 -> [[Borg - data file|plxxxxdata.bin]] from afs_data
├─ 001 -> empty file
├─ 002 -> plxxxxhit.bin from the afs_data
├─ 003 -> [[Motions|plxxxxmot.bin]] from the afs_data
├─ 004 -> [[Models|plxxxx_mdl.arc]] of the afs_data
├─ 005 -> [[Models|plxxxxb_mdl.arc]] of the afs_data
├─ 006 -> [[Models|plxxxxg_mdl.arc]] of the afs_data
├─ 007 -> [[Models|plxxxxs_mdl.arc]] of the afs_data
├─ 008 -> [[Models|plxxxxc_mdl.arc]] of the afs_data
└─ 009 -> [[Models|plxxxxk_mdl.arc]] of the afs_data

==== Memory backups ====

=== Data Crystals ===
The itxxxx_mdl.arz, once unpacked with pzztool.py are the templates for the data crystals.

==== Graphical interface elements ====

unitall_mdl.arc contains all the borg thumbnails used in the force creation/modification menu as well as in the post-combat scene showing which team/borgs VS team/borgs, and in the data crystals.

==== Files and operation ====
==== Memory saves ====

[[Category:Implementations]]
[[Category:Gotcha Force]]

Implementations

2023-10-07T13:11:35Z

Algoflash: /* Files and operation */

[[Gotcha Force | ← Gotcha Force]]

<div style="text-align: center;">
<div style="color: rgb(241, 196, 15);">This section is a work in progress.</div>
<div style="color: rgb(241, 196, 15); text-align: center;">Research is still needed and some paragraphs may be wrong.</div>
</div>

== Implementation of the game elements ==

=== Borg ===
==== GUI elements ====
==== Borgs GET system ====
CrystalPixel who found the values.

During a fight in Story Mode, when fighting an enemy borg for a given colour you have two values:
* The GET value
* The GET counter

When you eliminate the enemy borg of a given colour, you have its GET counter which increments by a random value between 1 and 16. When the GET counter is greater than or equal to the GET value, we get the borg / Data Crystal at the end of the battle. Then the GET counter of this borg / colour combination is reset to 0. If one leaves or loses the battle, all GET counters are reset to the value they had before the battle started.

For a large number of borgs it is then impossible to get them without having fought a certain amount. For example, Gold Death Borg Alpha has a GET value of 40. In two battles, for example, you can only get 36 in the best case.

1 borg has a GET value of -1:
* Galactic Emperor

The rest have no GET value:
* Cyber Death Dragon (Fusion Borg)
* Machine Dragon
* Cyber Machine Seiryu (Fusion Borg)
* Cyber Machine Suzaku (Fusion Borg)
* Cyber Machine Byakko (Fusion Borg)
* Cyber Machine Genbu (Fusion Borg)
* G Red (One of the borg we have)
* Neo G Red (One of the borgs we have)
* G Black (It is obtained in a special event)

By changing the GET value to a positive value, you can get the borgs in the scenario: Galactic Emperor for example.

The list of GET values for the EU version is available at [https://github.com/Virtual-World-RE/NeoGF/blob/main/data/eu_borgs_GET_values.csv github].

==== Files and operation ====
Borgs are implemented with a set of files, each with a specific function. These files are duplicated in the pzz of the borg and in the afs_data. The different _mdl define the different colours of the Borg. It seems that they are used with additional values in other files (the displays are not always correct when exchanging positions in the iso). The main _mdl is loaded from the pzz (collection or story menu). <span style="color: rgb(241, 196, 15);">One theory would be that part of the duplicate files would be used to load enemies and the other part allies.</span>

For each borg we have:<br>
plxxxx.pzz
├─ 000 file [[Borg - data file|plxxxxdata.bin]] -> always present
├─ 001? -> often not present
├─ 002 file plxxxxhit.bin -> always present
├─ 003 file [[Motions|plxxxxmot.bin]] -> often not present
├─ 004 file [[Models|plxxxx_mdl.arc]] -> always present
├─ 005 file [[Models|plxxxxb_mdl.arc]] -> always present -> blue model
├─ 006 file [[Models|plxxxxg_mdl.arc]] -> always present
├─ 007 file [[Models|plxxxxs_mdl.arc]] -> always present -> silver model
├─ 008 file [[Models|plxxxxc_mdl.arc]] -> always present
├─ 009 file [[Models|plxxxxk_mdl.arc]] -> always present -> black model
├─ 010 [[TPL (File format)|TPL]] -> name of the borg in Japanese
├─ 011 [[TPL (File format)|TPL]] -> name of the borg in Japanese (small format)
├─ 012 [[TPL (File format)|TPL]] -> borg name in the language of the game
└─ 013 file mnxxxx.tpl -> [[TPL (File format)|TPL]] -> name of the borg in the game language (small format)
[[Borg - data file|plxxxxdata.bin]] -> file can be named data2 or data3 (only one of the three is present), sometimes missing from the afs_data
plxxxxhit.bin -> always present in the afs_data and pzz
[[Motions|plxxxxmot.bin]] -> often absent from the afs_data
[[Models|plxxxx_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxb_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxg_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxs_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxc_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxk_mdl.arc]] -> sometimes missing from afs_data
mnxxxx.tpl

Position 002: for borg pl0507 and pl0513, file 2 and hit differ (USA/NTSC version)

Position 003: for the borg pl0009, file 3 and the word differ (USA/NTSC version) (MOT - ''Mot'''ion) - It can be observed that for these files, there are references that could make one think of ''plxxxx_xx_animjoint''. The investigation conducted by the [https://smashboards.com/threads/melee-dat-format.292603/ Smash Bros Brawl] community shows a similar file structure. This is another version of HSD (the basic structures are the same).

Position 004 to 009: contain '''scene_data''' at the end of the data section, and are ''''"Scene"'' files (HSDLib) which contain lights, cameras, vertices, bones in the manner of a .blend.

Position 004 to 008: files with values corresponding to 3D. In particular, we can cite '''pl0300.pzz''' where they have a header <span style="color: rgb(241, 196, 15);">with flags</span> as well as an adjustable padding if need be to have more elements '''For example for '''pl0629.pzz''' the amount <span style="color: rgb(241, 196, 15);">of flags</span> in the headers is more consistent.'' The origin <span style="color: rgb(241, 196, 15);">of the flags</span> and values in the header is currently unknown but these header fields <span style="color: rgb(241, 196, 15);">might constitute a list of available meshes in the file.</span> The software used to read the files in position 004 to 009 in plxxxx.pzz are 3D Model Researcher and HSDRawLibrary.

'''Unimplemented borgs''': pl0803 - pl080b - pl0f07<br>
Only the pl0803hit.bin and pl080bhit.bin files remain, and none of their associated files (notably, no associated pzz), which indicates that they are remnants of unimplemented borgs... Also the pzz pl0f07 has no hit file, no 4 internal TPLs (but 4 empty files instead) and just its pl0f07_mdl.arc file, which indicates that this borg is not implemented either (USA/NTSC version).

The 2 dpxxxx.pzz files are similar files to plxxxx.pzz but without the final TPL files. Their usefulness is still to be determined.

Files dpxxxx.pzz (2)
├─ 000 -> [[Borg - data file|plxxxxdata.bin]] from afs_data
├─ 001 -> empty file
├─ 002 -> plxxxxhit.bin from the afs_data
├─ 003 -> [[Motions|plxxxxmot.bin]] from the afs_data
├─ 004 -> [[Models|plxxxx_mdl.arc]] of the afs_data
├─ 005 -> [[Models|plxxxxb_mdl.arc]] of the afs_data
├─ 006 -> [[Models|plxxxxg_mdl.arc]] of the afs_data
├─ 007 -> [[Models|plxxxxs_mdl.arc]] of the afs_data
├─ 008 -> [[Models|plxxxxc_mdl.arc]] of the afs_data
└─ 009 -> [[Models|plxxxxk_mdl.arc]] of the afs_data

==== Memory backups ====

=== Data Crystals ===
The itxxxx_mdl.arz, once unpacked with pzztool.py are the templates for the data crystals.

==== Graphical interface elements ====

unitall_mdl.arc contains all the borg thumbnails used in the force creation/modification menu as well as in the post-combat scene showing which team/borgs VS team/borgs, and in the data crystals.

==== Files and operation ====
==== Memory saves ====

[[Category:Implementations]]
[[Category:Gotcha Force]]

Implementations

2023-10-07T13:11:28Z

Algoflash: /* Files and operation */

[[Gotcha Force | ← Gotcha Force]]

<div style="text-align: center;">
<div style="color: rgb(241, 196, 15);">This section is a work in progress.</div>
<div style="color: rgb(241, 196, 15); text-align: center;">Research is still needed and some paragraphs may be wrong.</div>
</div>

== Implementation of the game elements ==

=== Borg ===
==== GUI elements ====
==== Borgs GET system ====
CrystalPixel who found the values.

During a fight in Story Mode, when fighting an enemy borg for a given colour you have two values:
* The GET value
* The GET counter

When you eliminate the enemy borg of a given colour, you have its GET counter which increments by a random value between 1 and 16. When the GET counter is greater than or equal to the GET value, we get the borg / Data Crystal at the end of the battle. Then the GET counter of this borg / colour combination is reset to 0. If one leaves or loses the battle, all GET counters are reset to the value they had before the battle started.

For a large number of borgs it is then impossible to get them without having fought a certain amount. For example, Gold Death Borg Alpha has a GET value of 40. In two battles, for example, you can only get 36 in the best case.

1 borg has a GET value of -1:
* Galactic Emperor

The rest have no GET value:
* Cyber Death Dragon (Fusion Borg)
* Machine Dragon
* Cyber Machine Seiryu (Fusion Borg)
* Cyber Machine Suzaku (Fusion Borg)
* Cyber Machine Byakko (Fusion Borg)
* Cyber Machine Genbu (Fusion Borg)
* G Red (One of the borg we have)
* Neo G Red (One of the borgs we have)
* G Black (It is obtained in a special event)

By changing the GET value to a positive value, you can get the borgs in the scenario: Galactic Emperor for example.

The list of GET values for the EU version is available at [https://github.com/Virtual-World-RE/NeoGF/blob/main/data/eu_borgs_GET_values.csv github].

==== Files and operation ====
Borgs are implemented with a set of files, each with a specific function. These files are duplicated in the pzz of the borg and in the afs_data. The different _mdl define the different colours of the Borg. It seems that they are used with additional values in other files (the displays are not always correct when exchanging positions in the iso). The main _mdl is loaded from the pzz (collection or story menu). <span style="color: rgb(241, 196, 15);">One theory would be that part of the duplicate files would be used to load enemies and the other part allies.</span>

For each borg we have:<br>
plxxxx.pzz
├─ 000 file [[Borg - data file|plxxxxdata.bin]] -> always present
├─ 001? -> often not present
├─ 002 file plxxxxhit.bin -> always present
├─ 003 file [[Motions|plxxxxmot.bin]] -> often not present
├─ 004 file [[Models|plxxxx_mdl.arc]] -> always present
├─ 005 file [[Models|plxxxxb_mdl.arc]] -> always present -> blue model
├─ 006 file [[Models|plxxxxg_mdl.arc]] -> always present
├─ 007 file [[Models|plxxxxs_mdl.arc]] -> always present -> silver model
├─ 008 file [[Models|plxxxxc_mdl.arc]] -> always present
├─ 009 file [[Models|plxxxxk_mdl.arc]] -> always present -> black model
├─ 010 [[TPL (File format)|TPL]] -> name of the borg in Japanese
├─ 011 [[TPL (File format)|TPL]] -> name of the borg in Japanese (small format)
├─ 012 [[TPL (File format)|TPL]] -> borg name in the language of the game
└─ 013 file mnxxxx.tpl -> [[TPL (File format)|TPL]] -> name of the borg in the game language (small format)
[[Borg - data file|plxxxxdata.bin]] -> file can be named data2 or data3 (only one of the three is present), sometimes missing from the afs_data
plxxxxhit.bin -> always present in the afs_data and pzz
[[Motions|plxxxxmot.bin]] -> often absent from the afs_data
[[Models|plxxxx_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxb_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxg_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxs_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxc_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxk_mdl.arc]] -> sometimes missing from afs_data
mnxxxx.tpl

Position 002: for borg pl0507 and pl0513, file 2 and hit differ (USA/NTSC version)

Position 003: for the borg pl0009, file 3 and the word differ (USA/NTSC version) (MOT - ''Mot'''ion) - It can be observed that for these files, there are references that could make one think of ''plxxxx_xx_animjoint''. The investigation conducted by the [https://smashboards.com/threads/melee-dat-format.292603/ Smash Bros Brawl] community shows a similar file structure. This is another version of HSD (the basic structures are the same).

Position 004 to 009: contain '''scene_data''' at the end of the data section, and are ''''"Scene"'' files (HSDLib) which contain lights, cameras, vertices, bones in the manner of a .blend.

Position 004 to 008: files with values corresponding to 3D. In particular, we can cite '''pl0300.pzz''' where they have a header <span style="color: rgb(241, 196, 15);">with flags</span> as well as an adjustable padding if need be to have more elements '''For example for '''pl0629.pzz''' the amount <span style="color: rgb(241, 196, 15);">of flags</span> in the headers is more consistent.'' The origin <span style="color: rgb(241, 196, 15);">of the flags</span> and values in the header is currently unknown but these header fields <span style="color: rgb(241, 196, 15);">might constitute a list of available meshes in the file.</span> The software used to read the files in position 004 to 009 in plxxxx.pzz are 3D Model Researcher and HSDRawLibrary.

'''Unimplemented borgs''': pl0803 - pl080b - pl0f07<br>
Only the pl0803hit.bin and pl080bhit.bin files remain, and none of their associated files (notably, no associated pzz), which indicates that they are remnants of unimplemented borgs... Also the pzz pl0f07 has no hit file, no 4 internal TPLs (but 4 empty files instead) and just its pl0f07_mdl.arc file, which indicates that this borg is not implemented either (USA/NTSC version).

The 2 dpxxxx.pzz files are similar files to plxxxx.pzz but without the final TPL files. Their usefulness is still to be determined.

Files dpxxxx.pzz (2)
├─ 000 -> [[Borg - data file|plxxxxdata.bin]] from afs_data
├─ 001 -> empty file
├─ 002 -> plxxxxhit.bin from the afs_data
├─ 003 -> [[Motions|plxxxxmot.bin]] from the afs_data
├─ 004 -> [[Models|plxxxx_mdl.arc]] of the afs_data
├─ 005 -> [[Models|plxxxxb_mdl.arc]] of the afs_data
├─ 006 -> [[Models|plxxxxg_mdl.arc]] of the afs_data
├─ 007 -> [[Models|plxxxxs_mdl.arc]] of the afs_data
├─ 008 -> [[Models|plxxxxc_mdl.arc]] of the afs_data
└─ 009 -> [[Models|plxxxxk_mdl.arc]] of the afs_data

==== Memory backups ====

=== Data Crystals ===
The itxxxx_mdl.arz, once unpacked with pzztool.py are the templates for the data crystals.

==== Graphical interface elements ====

unitall_mdl.arc contains all the borg thumbnails used in the force creation/modification menu as well as in the post-combat scene showing which team/borgs VS team/borgs, and in the data crystals.

==== Files and operation ====
==== Memory saves ====

[[Category:Implementations]]
[[Category:Gotcha Force]]

Implementations

2023-10-07T13:11:17Z

Algoflash: /* Files and operation */

[[Gotcha Force | ← Gotcha Force]]

<div style="text-align: center;">
<div style="color: rgb(241, 196, 15);">This section is a work in progress.</div>
<div style="color: rgb(241, 196, 15); text-align: center;">Research is still needed and some paragraphs may be wrong.</div>
</div>

== Implementation of the game elements ==

=== Borg ===
==== GUI elements ====
==== Borgs GET system ====
CrystalPixel who found the values.

During a fight in Story Mode, when fighting an enemy borg for a given colour you have two values:
* The GET value
* The GET counter

When you eliminate the enemy borg of a given colour, you have its GET counter which increments by a random value between 1 and 16. When the GET counter is greater than or equal to the GET value, we get the borg / Data Crystal at the end of the battle. Then the GET counter of this borg / colour combination is reset to 0. If one leaves or loses the battle, all GET counters are reset to the value they had before the battle started.

For a large number of borgs it is then impossible to get them without having fought a certain amount. For example, Gold Death Borg Alpha has a GET value of 40. In two battles, for example, you can only get 36 in the best case.

1 borg has a GET value of -1:
* Galactic Emperor

The rest have no GET value:
* Cyber Death Dragon (Fusion Borg)
* Machine Dragon
* Cyber Machine Seiryu (Fusion Borg)
* Cyber Machine Suzaku (Fusion Borg)
* Cyber Machine Byakko (Fusion Borg)
* Cyber Machine Genbu (Fusion Borg)
* G Red (One of the borg we have)
* Neo G Red (One of the borgs we have)
* G Black (It is obtained in a special event)

By changing the GET value to a positive value, you can get the borgs in the scenario: Galactic Emperor for example.

The list of GET values for the EU version is available at [https://github.com/Virtual-World-RE/NeoGF/blob/main/data/eu_borgs_GET_values.csv github].

==== Files and operation ====
Borgs are implemented with a set of files, each with a specific function. These files are duplicated in the pzz of the borg and in the afs_data. The different _mdl define the different colours of the Borg. It seems that they are used with additional values in other files (the displays are not always correct when exchanging positions in the iso). The main _mdl is loaded from the pzz (collection or story menu). <span style="color: rgb(241, 196, 15);">One theory would be that part of the duplicate files would be used to load enemies and the other part allies.</span>

For each borg we have:<br>
plxxxx.pzz
├─ 000 file [[Borg - data file|plxxxxdata.bin]] -> always present
├─ 001? -> often not present
├─ 002 file plxxxxhit.bin -> always present
├─ 003 file [[Motions|plxxxxmot.bin]] -> often not present
├─ 004 file [[Models|plxxxx_mdl.arc]] -> always present
├─ 005 file [[Models|plxxxxb_mdl.arc]] -> always present -> blue model
├─ 006 file [[Models|plxxxxg_mdl.arc]] -> always present
├─ 007 file [[Models|plxxxxs_mdl.arc]] -> always present -> silver model
├─ 008 file [[Models|plxxxxc_mdl.arc]] -> always present
├─ 009 file [[Models|plxxxxk_mdl.arc]] -> always present -> black model
├─ 010 [[TPL (File format)|TPL]] -> name of the borg in Japanese
├─ 011 [[TPL (File format)|TPL]] -> name of the borg in Japanese (small format)
├─ 012 [[TPL (File format)|TPL]] -> borg name in the language of the game
└─ 013 file mnxxxx.tpl -> [[TPL (File format)|TPL]] -> name of the borg in the game language (small format)
[[Borg - data file|plxxxxdata.bin]] -> file can be named data2 or data3 (only one of the three is present), sometimes missing from the afs_data
plxxxxhit.bin -> always present in the afs_data and pzz
[[Motions|plxxxxmot.bin]] -> often absent from the afs_data
[[Models|plxxxx_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxb_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxg_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxs_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxc_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxk_mdl.arc]] -> sometimes missing from afs_data
mnxxxx.tpl

Position 002: for borg pl0507 and pl0513, file 2 and hit differ (USA/NTSC version)

Position 003: for the borg pl0009, file 3 and the word differ (USA/NTSC version) (MOT - ''Mot'''ion) - It can be observed that for these files, there are references that could make one think of ''plxxxx_xx_animjoint''. The investigation conducted by the [https://smashboards.com/threads/melee-dat-format.292603/ Smash Bros Brawl] community shows a similar file structure. This is another version of HSD (the basic structures are the same).

Position 004 to 009: contain '''scene_data''' at the end of the data section, and are ''''"Scene"'' files (HSDLib) which contain lights, cameras, vertices, bones in the manner of a .blend.

Position 004 to 008: files with values corresponding to 3D. In particular, we can cite '''pl0300.pzz''' where they have a header <span style="color: rgb(241, 196, 15);">with flags</span> as well as an adjustable padding if need be to have more elements '''For example for '''pl0629.pzz''' the amount <span style="color: rgb(241, 196, 15);">of flags</span> in the headers is more consistent.'' The origin <span style="color: rgb(241, 196, 15);">of the flags</span> and values in the header is currently unknown but these header fields <span style="color: rgb(241, 196, 15);">might constitute a list of available meshes in the file.</span> The software used to read the files in position 004 to 009 in plxxxx.pzz are 3D Model Researcher and HSDRawLibrary.

'''Unimplemented borgs''': pl0803 - pl080b - pl0f07<br>
Only the pl0803hit.bin and pl080bhit.bin files remain, and none of their associated files (notably, no associated pzz), which indicates that they are remnants of unimplemented borgs... Also the pzz pl0f07 has no hit file, no 4 internal TPLs (but 4 empty files instead) and just its pl0f07_mdl.arc file, which indicates that this borg is not implemented either (USA/NTSC version).

The 2 dpxxxx.pzz files are similar files to plxxxx.pzz but without the final TPL files. Their usefulness is still to be determined.

Files dpxxxx.pzz (2)
├─ 000 -> [[Borg - data file|plxxxxdata.bin]] from afs_data
├─ 001 -> empty file
├─ 002 -> plxxxxhit.bin from the afs_data
├─ 003 -> [[Motions|plxxxxmot.bin]] from the afs_data
├─ 004 -> [[Models|plxxxx_mdl.arc]] of the afs_data
├─ 005 -> [[Models|plxxxxb_mdl.arc]] of the afs_data
├─ 006 -> [[Models|plxxxxg_mdl.arc]] of the afs_data
├─ 007 -> [[Models|plxxxxs_mdl.arc]] of the afs_data
├─ 008 -> [[Models|plxxxxc_mdl.arc]] of the afs_data
└─ 009 -> [[Models|plxxxxk_mdl.arc]] of the afs_data

==== Memory backups ====

=== Data Crystals ===
The itxxxx_mdl.arz, once unpacked with pzztool.py are the templates for the data crystals.

==== Graphical interface elements ====

unitall_mdl.arc contains all the borg thumbnails used in the force creation/modification menu as well as in the post-combat scene showing which team/borgs VS team/borgs, and in the data crystals.

==== Files and operation ====
==== Memory saves ====

[[Category:Implementations]]
[[Category:Gotcha Force]]

Implementations

2023-10-07T13:11:08Z

Algoflash: /* Files and operation */

[[Gotcha Force | ← Gotcha Force]]

<div style="text-align: center;">
<div style="color: rgb(241, 196, 15);">This section is a work in progress.</div>
<div style="color: rgb(241, 196, 15); text-align: center;">Research is still needed and some paragraphs may be wrong.</div>
</div>

== Implementation of the game elements ==

=== Borg ===
==== GUI elements ====
==== Borgs GET system ====
CrystalPixel who found the values.

During a fight in Story Mode, when fighting an enemy borg for a given colour you have two values:
* The GET value
* The GET counter

When you eliminate the enemy borg of a given colour, you have its GET counter which increments by a random value between 1 and 16. When the GET counter is greater than or equal to the GET value, we get the borg / Data Crystal at the end of the battle. Then the GET counter of this borg / colour combination is reset to 0. If one leaves or loses the battle, all GET counters are reset to the value they had before the battle started.

For a large number of borgs it is then impossible to get them without having fought a certain amount. For example, Gold Death Borg Alpha has a GET value of 40. In two battles, for example, you can only get 36 in the best case.

1 borg has a GET value of -1:
* Galactic Emperor

The rest have no GET value:
* Cyber Death Dragon (Fusion Borg)
* Machine Dragon
* Cyber Machine Seiryu (Fusion Borg)
* Cyber Machine Suzaku (Fusion Borg)
* Cyber Machine Byakko (Fusion Borg)
* Cyber Machine Genbu (Fusion Borg)
* G Red (One of the borg we have)
* Neo G Red (One of the borgs we have)
* G Black (It is obtained in a special event)

By changing the GET value to a positive value, you can get the borgs in the scenario: Galactic Emperor for example.

The list of GET values for the EU version is available at [https://github.com/Virtual-World-RE/NeoGF/blob/main/data/eu_borgs_GET_values.csv github].

==== Files and operation ====
Borgs are implemented with a set of files, each with a specific function. These files are duplicated in the pzz of the borg and in the afs_data. The different _mdl define the different colours of the Borg. It seems that they are used with additional values in other files (the displays are not always correct when exchanging positions in the iso). The main _mdl is loaded from the pzz (collection or story menu). <span style="color: rgb(241, 196, 15);">One theory would be that part of the duplicate files would be used to load enemies and the other part allies.</span>

For each borg we have:<br>
plxxxx.pzz
├─ 000 file [[Borg - data file|plxxxxdata.bin]] -> always present
├─ 001? -> often not present
├─ 002 file plxxxxhit.bin -> always present
├─ 003 file [[Motions|plxxxxmot.bin]] -> often not present
├─ 004 file [[Models|plxxxx_mdl.arc]] -> always present
├─ 005 file [[Models|plxxxxb_mdl.arc]] -> always present -> blue model
├─ 006 file [[Models|plxxxxg_mdl.arc]] -> always present
├─ 007 file [[Models|plxxxxs_mdl.arc]] -> always present -> silver model
├─ 008 file [[Models|plxxxxc_mdl.arc]] -> always present
├─ 009 file [[Models|plxxxxk_mdl.arc]] -> always present -> black model
├─ 010 [[TPL (File format)|TPL]] -> name of the borg in Japanese
├─ 011 [[TPL (File format)|TPL]] -> name of the borg in Japanese (small format)
├─ 012 [[TPL (File format)|TPL]] -> borg name in the language of the game
└─ 013 file mnxxxx.tpl -> [[TPL (File format)|TPL]] -> name of the borg in the game language (small format)
[[Borg - data file|plxxxxdata.bin]] -> file can be named data2 or data3 (only one of the three is present), sometimes missing from the afs_data
plxxxxhit.bin -> always present in the afs_data and pzz
[[Motions|plxxxxmot.bin]] -> often absent from the afs_data
[[Models|plxxxx_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxb_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxg_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxs_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxc_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxk_mdl.arc]] -> sometimes missing from afs_data
mnxxxx.tpl

Position 002: for borg pl0507 and pl0513, file 2 and hit differ (USA/NTSC version)

Position 003: for the borg pl0009, file 3 and the word differ (USA/NTSC version) (MOT - ''Mot'''ion) - It can be observed that for these files, there are references that could make one think of ''plxxxx_xx_animjoint''. The investigation conducted by the [https://smashboards.com/threads/melee-dat-format.292603/ Smash Bros Brawl] community shows a similar file structure. This is another version of HSD (the basic structures are the same).

Position 004 to 009: contain '''scene_data''' at the end of the data section, and are ''''"Scene"'' files (HSDLib) which contain lights, cameras, vertices, bones in the manner of a .blend.

Position 004 to 008: files with values corresponding to 3D. In particular, we can cite '''pl0300.pzz''' where they have a header <span style="color: rgb(241, 196, 15);">with flags</span> as well as an adjustable padding if need be to have more elements '''For example for '''pl0629.pzz''' the amount <span style="color: rgb(241, 196, 15);">of flags</span> in the headers is more consistent.'' The origin <span style="color: rgb(241, 196, 15);">of the flags</span> and values in the header is currently unknown but these header fields <span style="color: rgb(241, 196, 15);">might constitute a list of available meshes in the file.</span> The software used to read the files in position 004 to 009 in plxxxx.pzz are 3D Model Researcher and HSDRawLibrary.

'''Unimplemented borgs''': pl0803 - pl080b - pl0f07<br>
Only the pl0803hit.bin and pl080bhit.bin files remain, and none of their associated files (notably, no associated pzz), which indicates that they are remnants of unimplemented borgs... Also the pzz pl0f07 has no hit file, no 4 internal TPLs (but 4 empty files instead) and just its pl0f07_mdl.arc file, which indicates that this borg is not implemented either (USA/NTSC version).

The 2 dpxxxx.pzz files are similar files to plxxxx.pzz but without the final TPL files. Their usefulness is still to be determined.

Files dpxxxx.pzz (2)
├─ 000 -> [[Borg - data file|plxxxxdata.bin]] from afs_data
├─ 001 -> empty file
├─ 002 -> plxxxxhit.bin from the afs_data
├─ 003 -> [[Motions|plxxxxmot.bin]] from the afs_data
├─ 004 -> [[Models|plxxxx_mdl.arc]] of the afs_data
├─ 005 -> [[Models|plxxxxb_mdl.arc]] of the afs_data
├─ 006 -> [[Models|plxxxxg_mdl.arc]] of the afs_data
├─ 007 -> [[Models|plxxxxs_mdl.arc]] of the afs_data
├─ 008 -> [[Models|plxxxxc_mdl.arc]] of the afs_data
└─ 009 -> [[Models|plxxxxk_mdl.arc]] of the afs_data

==== Memory backups ====

=== Data Crystals ===
The itxxxx_mdl.arz, once unpacked with pzztool.py are the templates for the data crystals.

==== Graphical interface elements ====

unitall_mdl.arc contains all the borg thumbnails used in the force creation/modification menu as well as in the post-combat scene showing which team/borgs VS team/borgs, and in the data crystals.

==== Files and operation ====
==== Memory saves ====

[[Category:Implementations]]
[[Category:Gotcha Force]]

Implementations

2023-10-07T13:10:48Z

Algoflash: /* Files and operation */

[[Gotcha Force | ← Gotcha Force]]

<div style="text-align: center;">
<div style="color: rgb(241, 196, 15);">This section is a work in progress.</div>
<div style="color: rgb(241, 196, 15); text-align: center;">Research is still needed and some paragraphs may be wrong.</div>
</div>

== Implementation of the game elements ==

=== Borg ===
==== GUI elements ====
==== Borgs GET system ====
CrystalPixel who found the values.

During a fight in Story Mode, when fighting an enemy borg for a given colour you have two values:
* The GET value
* The GET counter

When you eliminate the enemy borg of a given colour, you have its GET counter which increments by a random value between 1 and 16. When the GET counter is greater than or equal to the GET value, we get the borg / Data Crystal at the end of the battle. Then the GET counter of this borg / colour combination is reset to 0. If one leaves or loses the battle, all GET counters are reset to the value they had before the battle started.

For a large number of borgs it is then impossible to get them without having fought a certain amount. For example, Gold Death Borg Alpha has a GET value of 40. In two battles, for example, you can only get 36 in the best case.

1 borg has a GET value of -1:
* Galactic Emperor

The rest have no GET value:
* Cyber Death Dragon (Fusion Borg)
* Machine Dragon
* Cyber Machine Seiryu (Fusion Borg)
* Cyber Machine Suzaku (Fusion Borg)
* Cyber Machine Byakko (Fusion Borg)
* Cyber Machine Genbu (Fusion Borg)
* G Red (One of the borg we have)
* Neo G Red (One of the borgs we have)
* G Black (It is obtained in a special event)

By changing the GET value to a positive value, you can get the borgs in the scenario: Galactic Emperor for example.

The list of GET values for the EU version is available at [https://github.com/Virtual-World-RE/NeoGF/blob/main/data/eu_borgs_GET_values.csv github].

==== Files and operation ====
Borgs are implemented with a set of files, each with a specific function. These files are duplicated in the pzz of the borg and in the afs_data. The different _mdl define the different colours of the Borg. It seems that they are used with additional values in other files (the displays are not always correct when exchanging positions in the iso). The main _mdl is loaded from the pzz (collection or story menu). <span style="color: rgb(241, 196, 15);">One theory would be that part of the duplicate files would be used to load enemies and the other part allies.</span>

For each borg we have:<br>
plxxxx.pzz
├─ 000 file [[Borg - data file|plxxxxdata.bin]] -> always present
├─ 001? -> often not present
├─ 002 file plxxxxhit.bin -> always present
├─ 003 file [[Motions|plxxxxmot.bin]] -> often not present
├─ 004 file [[Models|plxxxx_mdl.arc]] -> always present
├─ 005 file [[Models|plxxxxb_mdl.arc]] -> always present -> blue model
├─ 006 file [[Models|plxxxxg_mdl.arc]] -> always present
├─ 007 file [[Models|plxxxxs_mdl.arc]] -> always present -> silver model
├─ 008 file [[Models|plxxxxc_mdl.arc]] -> always present
├─ 009 file [[Models|plxxxxk_mdl.arc]] -> always present -> black model
├─ 010 [[TPL (File format)|TPL]] -> name of the borg in Japanese
├─ 011 [[TPL (File format)|TPL]] -> name of the borg in Japanese (small format)
├─ 012 [[TPL (File format)|TPL]] -> borg name in the language of the game
└─ 013 file mnxxxx.tpl -> [[TPL (File format)|TPL]] -> name of the borg in the game language (small format)
[[Borg - data file|plxxxxdata.bin]] -> file can be named data2 or data3 (only one of the three is present), sometimes missing from the afs_data
plxxxxhit.bin -> always present in the afs_data and pzz
[[Motions|plxxxxmot.bin]] -> often absent from the afs_data
[[Models|plxxxx_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxb_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxg_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxs_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxc_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxk_mdl.arc]] -> sometimes missing from afs_data
mnxxxx.tpl

Position 002: for borg pl0507 and pl0513, file 2 and hit differ (USA/NTSC version)

Position 003: for the borg pl0009, file 3 and the word differ (USA/NTSC version) (MOT - ''Mot'''ion) - It can be observed that for these files, there are references that could make one think of ''plxxxx_xx_animjoint''. The investigation conducted by the [https://smashboards.com/threads/melee-dat-format.292603/ Smash Bros Brawl] community shows a similar file structure. This is another version of HSD (the basic structures are the same).

Position 004 to 009: contain '''scene_data''' at the end of the data section, and are ''''"Scene"'' files (HSDLib) which contain lights, cameras, vertices, bones in the manner of a .blend.

Position 004 to 008: files with values corresponding to 3D. In particular, we can cite '''pl0300.pzz''' where they have a header <span style="color: rgb(241, 196, 15);">with flags</span> as well as an adjustable padding if need be to have more elements '''For example for '''pl0629.pzz''' the amount <span style="color: rgb(241, 196, 15);">of flags</span> in the headers is more consistent.'' The origin <span style="color: rgb(241, 196, 15);">of the flags</span> and values in the header is currently unknown but these header fields <span style="color: rgb(241, 196, 15);">might constitute a list of available meshes in the file.</span> The software used to read the files in position 004 to 009 in plxxxx.pzz are 3D Model Researcher and HSDRawLibrary.

'''Unimplemented borgs''': pl0803 - pl080b - pl0f07<br>
Only the pl0803hit.bin and pl080bhit.bin files remain, and none of their associated files (notably, no associated pzz), which indicates that they are remnants of unimplemented borgs... Also the pzz pl0f07 has no hit file, no 4 internal TPLs (but 4 empty files instead) and just its pl0f07_mdl.arc file, which indicates that this borg is not implemented either (USA/NTSC version).

The 2 dpxxxx.pzz files are similar files to plxxxx.pzz but without the final TPL files. Their usefulness is still to be determined.

Files dpxxxx.pzz (2)
├─ 000 -> [[Borg - data file|plxxxxdata.bin]] from afs_data
├─ 001 -> empty file
├─ 002 -> plxxxxhit.bin from the afs_data
├─ 003 -> [[Motions|plxxxxmot.bin]] from the afs_data
├─ 004 -> [[Models|plxxxx_mdl.arc]] of the afs_data
├─ 005 -> [[Models|plxxxxb_mdl.arc]] of the afs_data
├─ 006 -> [[Models|plxxxxg_mdl.arc]] of the afs_data
├─ 007 -> [[Models|plxxxxs_mdl.arc]] of the afs_data
├─ 008 -> [[Models|plxxxxc_mdl.arc]] of the afs_data
└─ 009 -> [[Models|plxxxxk_mdl.arc]] of the afs_data

==== Memory backups ====

=== Data Crystals ===
The itxxxx_mdl.arz, once unpacked with pzztool.py are the templates for the data crystals.

==== Graphical interface elements ====

unitall_mdl.arc contains all the borg thumbnails used in the force creation/modification menu as well as in the post-combat scene showing which team/borgs VS team/borgs, and in the data crystals.

==== Files and operation ====
==== Memory saves ====

[[Category:Implementations]]
[[Category:Gotcha Force]]

Implementations

2023-10-07T13:10:30Z

Algoflash: /* Files and operation */

[[Gotcha Force | ← Gotcha Force]]

<div style="text-align: center;">
<div style="color: rgb(241, 196, 15);">This section is a work in progress.</div>
<div style="color: rgb(241, 196, 15); text-align: center;">Research is still needed and some paragraphs may be wrong.</div>
</div>

== Implementation of the game elements ==

=== Borg ===
==== GUI elements ====
==== Borgs GET system ====
CrystalPixel who found the values.

During a fight in Story Mode, when fighting an enemy borg for a given colour you have two values:
* The GET value
* The GET counter

When you eliminate the enemy borg of a given colour, you have its GET counter which increments by a random value between 1 and 16. When the GET counter is greater than or equal to the GET value, we get the borg / Data Crystal at the end of the battle. Then the GET counter of this borg / colour combination is reset to 0. If one leaves or loses the battle, all GET counters are reset to the value they had before the battle started.

For a large number of borgs it is then impossible to get them without having fought a certain amount. For example, Gold Death Borg Alpha has a GET value of 40. In two battles, for example, you can only get 36 in the best case.

1 borg has a GET value of -1:
* Galactic Emperor

The rest have no GET value:
* Cyber Death Dragon (Fusion Borg)
* Machine Dragon
* Cyber Machine Seiryu (Fusion Borg)
* Cyber Machine Suzaku (Fusion Borg)
* Cyber Machine Byakko (Fusion Borg)
* Cyber Machine Genbu (Fusion Borg)
* G Red (One of the borg we have)
* Neo G Red (One of the borgs we have)
* G Black (It is obtained in a special event)

By changing the GET value to a positive value, you can get the borgs in the scenario: Galactic Emperor for example.

The list of GET values for the EU version is available at [https://github.com/Virtual-World-RE/NeoGF/blob/main/data/eu_borgs_GET_values.csv github].

==== Files and operation ====
Borgs are implemented with a set of files, each with a specific function. These files are duplicated in the pzz of the borg and in the afs_data. The different _mdl define the different colours of the Borg. It seems that they are used with additional values in other files (the displays are not always correct when exchanging positions in the iso). The main _mdl is loaded from the pzz (collection or story menu). <span style="color: rgb(241, 196, 15);">One theory would be that part of the duplicate files would be used to load enemies and the other part allies.</span>

For each borg we have:<br>
plxxxx.pzz
├─ 000 file [[Borg - data file|plxxxxdata.bin]] -> always present
├─ 001? -> often not present
├─ 002 file plxxxxhit.bin -> always present
├─ 003 file [[Motions|plxxxxmot.bin]] -> often not present
├─ 004 file [[Models|plxxxx_mdl.arc]] -> always present
├─ 005 file [[Models|plxxxxb_mdl.arc]] -> always present -> blue model
├─ 006 file [[Models|plxxxxg_mdl.arc]] -> always present
├─ 007 file [[Models|plxxxxs_mdl.arc]] -> always present -> silver model
├─ 008 file [[Models|plxxxxc_mdl.arc]] -> always present
├─ 009 file [[Models|plxxxxk_mdl.arc]] -> always present -> black model
├─ 010 [[TPL (File format)|TPL]] -> name of the borg in Japanese
├─ 011 [[TPL (File format)|TPL]] -> name of the borg in Japanese (small format)
├─ 012 [[TPL (File format)|TPL]] -> borg name in the language of the game
└─ 013 file mnxxxx.tpl -> [[TPL (File format)|TPL]] -> name of the borg in the game language (small format)
[[Borg - data file|plxxxxdata.bin]] -> file can be named data2 or data3 (only one of the three is present), sometimes missing from the afs_data
plxxxxhit.bin -> always present in the afs_data and pzz
[[Motions|plxxxxmot.bin]] -> often absent from the afs_data
[[Models|plxxxx_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxb_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxg_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxs_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxc_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxk_mdl.arc]] -> sometimes missing from afs_data
mnxxxx.tpl

Position 002: for borg pl0507 and pl0513, file 2 and hit differ (USA/NTSC version)

Position 003: for the borg pl0009, file 3 and the word differ (USA/NTSC version) (MOT - ''Mot'''ion) - It can be observed that for these files, there are references that could make one think of ''plxxxx_xx_animjoint''. The investigation conducted by the [https://smashboards.com/threads/melee-dat-format.292603/ Smash Bros Brawl] community shows a similar file structure. This is another version of HSD (the basic structures are the same).

Position 004 to 009: contain '''scene_data''' at the end of the data section, and are ''''"Scene"'' files (HSDLib) which contain lights, cameras, vertices, bones in the manner of a .blend.

Position 004 to 008: files with values corresponding to 3D. In particular, we can cite '''pl0300.pzz''' where they have a header <span style="color: rgb(241, 196, 15);">with flags</span> as well as an adjustable padding if need be to have more elements '''For example for '''pl0629.pzz''' the amount <span style="color: rgb(241, 196, 15);">of flags</span> in the headers is more consistent.'' The origin <span style="color: rgb(241, 196, 15);">of the flags</span> and values in the header is currently unknown but these header fields <span style="color: rgb(241, 196, 15);">might constitute a list of available meshes in the file.</span> The software used to read the files in position 004 to 009 in plxxxx.pzz are 3D Model Researcher and HSDRawLibrary.

'''Unimplemented borgs''': pl0803 - pl080b - pl0f07<br>
Only the pl0803hit.bin and pl080bhit.bin files remain, and none of their associated files (notably, no associated pzz), which indicates that they are remnants of unimplemented borgs... Also the pzz pl0f07 has no hit file, no 4 internal TPLs (but 4 empty files instead) and just its pl0f07_mdl.arc file, which indicates that this borg is not implemented either (USA/NTSC version).

The 2 dpxxxx.pzz files are similar files to plxxxx.pzz but without the final TPL files. Their usefulness is still to be determined.

Files dpxxxx.pzz (2)
├─ 000 -> [[Borg - data file|plxxxxdata.bin]] from afs_data
├─ 001 -> empty file
├─ 002 -> plxxxxhit.bin from the afs_data
├─ 003 -> [[Motions|plxxxxmot.bin]] from the afs_data
├─ 004 -> [[Models|plxxxx_mdl.arc]] of the afs_data
├─ 005 -> [[Models|plxxxxb_mdl.arc]] of the afs_data
├─ 006 -> [[Models|plxxxxg_mdl.arc]] of the afs_data
├─ 007 -> [[Models|plxxxxs_mdl.arc]] of the afs_data
├─ 008 -> [[Models|plxxxxc_mdl.arc]] of the afs_data
└─ 009 -> [[Models|plxxxxk_mdl.arc]] of the afs_data

==== Memory backups ====

=== Data Crystals ===
The itxxxx_mdl.arz, once unpacked with pzztool.py are the templates for the data crystals.

==== Graphical interface elements ====

unitall_mdl.arc contains all the borg thumbnails used in the force creation/modification menu as well as in the post-combat scene showing which team/borgs VS team/borgs, and in the data crystals.

==== Files and operation ====
==== Memory saves ====

[[Category:Implementations]]
[[Category:Gotcha Force]]

Implementations

2023-10-07T13:10:19Z

Algoflash: /* Files and operation */

[[Gotcha Force | ← Gotcha Force]]

<div style="text-align: center;">
<div style="color: rgb(241, 196, 15);">This section is a work in progress.</div>
<div style="color: rgb(241, 196, 15); text-align: center;">Research is still needed and some paragraphs may be wrong.</div>
</div>

== Implementation of the game elements ==

=== Borg ===
==== GUI elements ====
==== Borgs GET system ====
CrystalPixel who found the values.

During a fight in Story Mode, when fighting an enemy borg for a given colour you have two values:
* The GET value
* The GET counter

When you eliminate the enemy borg of a given colour, you have its GET counter which increments by a random value between 1 and 16. When the GET counter is greater than or equal to the GET value, we get the borg / Data Crystal at the end of the battle. Then the GET counter of this borg / colour combination is reset to 0. If one leaves or loses the battle, all GET counters are reset to the value they had before the battle started.

For a large number of borgs it is then impossible to get them without having fought a certain amount. For example, Gold Death Borg Alpha has a GET value of 40. In two battles, for example, you can only get 36 in the best case.

1 borg has a GET value of -1:
* Galactic Emperor

The rest have no GET value:
* Cyber Death Dragon (Fusion Borg)
* Machine Dragon
* Cyber Machine Seiryu (Fusion Borg)
* Cyber Machine Suzaku (Fusion Borg)
* Cyber Machine Byakko (Fusion Borg)
* Cyber Machine Genbu (Fusion Borg)
* G Red (One of the borg we have)
* Neo G Red (One of the borgs we have)
* G Black (It is obtained in a special event)

By changing the GET value to a positive value, you can get the borgs in the scenario: Galactic Emperor for example.

The list of GET values for the EU version is available at [https://github.com/Virtual-World-RE/NeoGF/blob/main/data/eu_borgs_GET_values.csv github].

==== Files and operation ====
Borgs are implemented with a set of files, each with a specific function. These files are duplicated in the pzz of the borg and in the afs_data. The different _mdl define the different colours of the Borg. It seems that they are used with additional values in other files (the displays are not always correct when exchanging positions in the iso). The main _mdl is loaded from the pzz (collection or story menu). <span style="color: rgb(241, 196, 15);">One theory would be that part of the duplicate files would be used to load enemies and the other part allies.</span>

For each borg we have:<br>
plxxxx.pzz
├─ 000 file [[Borg - data file|plxxxxdata.bin]] -> always present
├─ 001? -> often not present
├─ 002 file plxxxxhit.bin -> always present
├─ 003 file [[Motions|plxxxxmot.bin]] -> often not present
├─ 004 file [[Models|plxxxx_mdl.arc]] -> always present
├─ 005 file [[Models|plxxxxb_mdl.arc]] -> always present -> blue model
├─ 006 file [[Models|plxxxxg_mdl.arc]] -> always present
├─ 007 file [[Models|plxxxxs_mdl.arc]] -> always present -> silver model
├─ 008 file [[Models|plxxxxc_mdl.arc]] -> always present
├─ 009 file [[Models|plxxxxk_mdl.arc]] -> always present -> black model
├─ 010 [[TPL (File format)|TPL]] -> name of the borg in Japanese
├─ 011 [[TPL (File format)|TPL]] -> name of the borg in Japanese (small format)
├─ 012 [[TPL (File format)|TPL]] -> borg name in the language of the game
└─ 013 file mnxxxx.tpl -> [[TPL (File format)|TPL]] -> name of the borg in the game language (small format)
[[Borg - data file|plxxxxdata.bin]] -> file can be named data2 or data3 (only one of the three is present), sometimes missing from the afs_data
plxxxxhit.bin -> always present in the afs_data and pzz
[[Motions|plxxxxmot.bin]] -> often absent from the afs_data
[[Models|plxxxx_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxb_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxg_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxs_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxc_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxk_mdl.arc]] -> sometimes missing from afs_data
mnxxxx.tpl

Position 002: for borg pl0507 and pl0513, file 2 and hit differ (USA/NTSC version)

Position 003: for the borg pl0009, file 3 and the word differ (USA/NTSC version) (MOT - ''Mot'''ion) - It can be observed that for these files, there are references that could make one think of ''plxxxx_xx_animjoint''. The investigation conducted by the [https://smashboards.com/threads/melee-dat-format.292603/ Smash Bros Brawl] community shows a similar file structure. This is another version of HSD (the basic structures are the same).

Position 004 to 009: contain '''scene_data''' at the end of the data section, and are ''''"Scene"'' files (HSDLib) which contain lights, cameras, vertices, bones in the manner of a .blend.

Position 004 to 008: files with values corresponding to 3D. In particular, we can cite '''pl0300.pzz''' where they have a header <span style="color: rgb(241, 196, 15);">with flags</span> as well as an adjustable padding if need be to have more elements '''For example for '''pl0629.pzz''' the amount <span style="color: rgb(241, 196, 15);">of flags</span> in the headers is more consistent.'' The origin <span style="color: rgb(241, 196, 15);">of the flags</span> and values in the header is currently unknown but these header fields <span style="color: rgb(241, 196, 15);">might constitute a list of available meshes in the file.</span> The software used to read the files in position 004 to 009 in plxxxx.pzz are 3D Model Researcher and HSDRawLibrary.

'''Unimplemented borgs''': pl0803 - pl080b - pl0f07<br>
Only the pl0803hit.bin and pl080bhit.bin files remain, and none of their associated files (notably, no associated pzz), which indicates that they are remnants of unimplemented borgs... Also the pzz pl0f07 has no hit file, no 4 internal TPLs (but 4 empty files instead) and just its pl0f07_mdl.arc file, which indicates that this borg is not implemented either (USA/NTSC version).

The 2 dpxxxx.pzz files are similar files to plxxxx.pzz but without the final TPL files. Their usefulness is still to be determined.

Files dpxxxx.pzz (2)
├─ 000 -> [[Borg - data file|plxxxxdata.bin]] from afs_data
├─ 001 -> empty file
├─ 002 -> plxxxxhit.bin from the afs_data
├─ 003 -> [[Motions|plxxxxmot.bin]] from the afs_data
├─ 004 -> [[Models|plxxxx_mdl.arc]] of the afs_data
├─ 005 -> [[Models|plxxxxb_mdl.arc]] of the afs_data
├─ 006 -> [[Models|plxxxxg_mdl.arc]] of the afs_data
├─ 007 -> [[Models|plxxxxs_mdl.arc]] of the afs_data
├─ 008 -> [[Models|plxxxxc_mdl.arc]] of the afs_data
└─ 009 -> [[Models|plxxxxk_mdl.arc]] of the afs_data

==== Memory backups ====

=== Data Crystals ===
The itxxxx_mdl.arz, once unpacked with pzztool.py are the templates for the data crystals.

==== Graphical interface elements ====

unitall_mdl.arc contains all the borg thumbnails used in the force creation/modification menu as well as in the post-combat scene showing which team/borgs VS team/borgs, and in the data crystals.

==== Files and operation ====
==== Memory saves ====

[[Category:Implementations]]
[[Category:Gotcha Force]]

Implementations

2023-10-07T13:09:59Z

Algoflash: /* Files and operation */

[[Gotcha Force | ← Gotcha Force]]

<div style="text-align: center;">
<div style="color: rgb(241, 196, 15);">This section is a work in progress.</div>
<div style="color: rgb(241, 196, 15); text-align: center;">Research is still needed and some paragraphs may be wrong.</div>
</div>

== Implementation of the game elements ==

=== Borg ===
==== GUI elements ====
==== Borgs GET system ====
CrystalPixel who found the values.

During a fight in Story Mode, when fighting an enemy borg for a given colour you have two values:
* The GET value
* The GET counter

When you eliminate the enemy borg of a given colour, you have its GET counter which increments by a random value between 1 and 16. When the GET counter is greater than or equal to the GET value, we get the borg / Data Crystal at the end of the battle. Then the GET counter of this borg / colour combination is reset to 0. If one leaves or loses the battle, all GET counters are reset to the value they had before the battle started.

For a large number of borgs it is then impossible to get them without having fought a certain amount. For example, Gold Death Borg Alpha has a GET value of 40. In two battles, for example, you can only get 36 in the best case.

1 borg has a GET value of -1:
* Galactic Emperor

The rest have no GET value:
* Cyber Death Dragon (Fusion Borg)
* Machine Dragon
* Cyber Machine Seiryu (Fusion Borg)
* Cyber Machine Suzaku (Fusion Borg)
* Cyber Machine Byakko (Fusion Borg)
* Cyber Machine Genbu (Fusion Borg)
* G Red (One of the borg we have)
* Neo G Red (One of the borgs we have)
* G Black (It is obtained in a special event)

By changing the GET value to a positive value, you can get the borgs in the scenario: Galactic Emperor for example.

The list of GET values for the EU version is available at [https://github.com/Virtual-World-RE/NeoGF/blob/main/data/eu_borgs_GET_values.csv github].

==== Files and operation ====
Borgs are implemented with a set of files, each with a specific function. These files are duplicated in the pzz of the borg and in the afs_data. The different _mdl define the different colours of the Borg. It seems that they are used with additional values in other files (the displays are not always correct when exchanging positions in the iso). The main _mdl is loaded from the pzz (collection or story menu). <span style="color: rgb(241, 196, 15);">One theory would be that part of the duplicate files would be used to load enemies and the other part allies.</span>

For each borg we have:<br>
plxxxx.pzz
├─ 000 file [[Borg - data file|plxxxxdata.bin]] -> always present
├─ 001 ? -> often not present
├─ 002 file plxxxxhit.bin -> always present
├─ 003 file [[Motions|plxxxxmot.bin]] -> often not present
├─ 004 file [[Models|plxxxx_mdl.arc]] -> always present
├─ 005 file [[Models|plxxxxb_mdl.arc]] -> always present -> blue model
├─ 006 file [[Models|plxxxxg_mdl.arc]] -> always present
├─ 007 file [[Models|plxxxxs_mdl.arc]] -> always present -> silver model
├─ 008 file [[Models|plxxxxc_mdl.arc]] -> always present
├─ 009 file [[Models|plxxxxk_mdl.arc]] -> always present -> black model
├─ 010 [[TPL (File format)|TPL]] -> name of the borg in Japanese
├─ 011 [[TPL (File format)|TPL]] -> name of the borg in Japanese (small format)
├─ 012 [[TPL (File format)|TPL]] -> borg name in the language of the game
└─ 013 file mnxxxx.tpl -> [[TPL (File format)|TPL]] -> name of the borg in the game language (small format)
[[Borg - data file|plxxxxdata.bin]] -> file can be named data2 or data3 (only one of the three is present), sometimes missing from the afs_data
plxxxxhit.bin -> always present in the afs_data and pzz
[[Motions|plxxxxmot.bin]] -> often absent from the afs_data
[[Models|plxxxx_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxb_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxg_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxs_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxc_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxk_mdl.arc]] -> sometimes missing from afs_data
mnxxxx.tpl

Position 002: for borg pl0507 and pl0513, file 2 and hit differ (USA/NTSC version)

Position 003: for the borg pl0009, file 3 and the word differ (USA/NTSC version) (MOT - ''Mot'''ion) - It can be observed that for these files, there are references that could make one think of ''plxxxx_xx_animjoint''. The investigation conducted by the [https://smashboards.com/threads/melee-dat-format.292603/ Smash Bros Brawl] community shows a similar file structure. This is another version of HSD (the basic structures are the same).

Position 004 to 009: contain '''scene_data''' at the end of the data section, and are ''''"Scene"'' files (HSDLib) which contain lights, cameras, vertices, bones in the manner of a .blend.

Position 004 to 008: files with values corresponding to 3D. In particular, we can cite '''pl0300.pzz''' where they have a header <span style="color: rgb(241, 196, 15);">with flags</span> as well as an adjustable padding if need be to have more elements '''For example for '''pl0629.pzz''' the amount <span style="color: rgb(241, 196, 15);">of flags</span> in the headers is more consistent.'' The origin <span style="color: rgb(241, 196, 15);">of the flags</span> and values in the header is currently unknown but these header fields <span style="color: rgb(241, 196, 15);">might constitute a list of available meshes in the file.</span> The software used to read the files in position 004 to 009 in plxxxx.pzz are 3D Model Researcher and HSDRawLibrary.

'''Unimplemented borgs''': pl0803 - pl080b - pl0f07<br>
Only the pl0803hit.bin and pl080bhit.bin files remain, and none of their associated files (notably, no associated pzz), which indicates that they are remnants of unimplemented borgs... Also the pzz pl0f07 has no hit file, no 4 internal TPLs (but 4 empty files instead) and just its pl0f07_mdl.arc file, which indicates that this borg is not implemented either (USA/NTSC version).

The 2 dpxxxx.pzz files are similar files to plxxxx.pzz but without the final TPL files. Their usefulness is still to be determined.

Files dpxxxx.pzz (2)
├─ 000 -> [[Borg - data file|plxxxxdata.bin]] from afs_data
├─ 001 -> empty file
├─ 002 -> plxxxxhit.bin from the afs_data
├─ 003 -> [[Motions|plxxxxmot.bin]] from the afs_data
├─ 004 -> [[Models|plxxxx_mdl.arc]] of the afs_data
├─ 005 -> [[Models|plxxxxb_mdl.arc]] of the afs_data
├─ 006 -> [[Models|plxxxxg_mdl.arc]] of the afs_data
├─ 007 -> [[Models|plxxxxs_mdl.arc]] of the afs_data
├─ 008 -> [[Models|plxxxxc_mdl.arc]] of the afs_data
└─ 009 -> [[Models|plxxxxk_mdl.arc]] of the afs_data

==== Memory backups ====

=== Data Crystals ===
The itxxxx_mdl.arz, once unpacked with pzztool.py are the templates for the data crystals.

==== Graphical interface elements ====

unitall_mdl.arc contains all the borg thumbnails used in the force creation/modification menu as well as in the post-combat scene showing which team/borgs VS team/borgs, and in the data crystals.

==== Files and operation ====
==== Memory saves ====

[[Category:Implementations]]
[[Category:Gotcha Force]]

Implementations

2023-10-07T13:09:44Z

Algoflash: /* Borgs GET system */

[[Gotcha Force | ← Gotcha Force]]

<div style="text-align: center;">
<div style="color: rgb(241, 196, 15);">This section is a work in progress.</div>
<div style="color: rgb(241, 196, 15); text-align: center;">Research is still needed and some paragraphs may be wrong.</div>
</div>

== Implementation of the game elements ==

=== Borg ===
==== GUI elements ====
==== Borgs GET system ====
CrystalPixel who found the values.

During a fight in Story Mode, when fighting an enemy borg for a given colour you have two values:
* The GET value
* The GET counter

When you eliminate the enemy borg of a given colour, you have its GET counter which increments by a random value between 1 and 16. When the GET counter is greater than or equal to the GET value, we get the borg / Data Crystal at the end of the battle. Then the GET counter of this borg / colour combination is reset to 0. If one leaves or loses the battle, all GET counters are reset to the value they had before the battle started.

For a large number of borgs it is then impossible to get them without having fought a certain amount. For example, Gold Death Borg Alpha has a GET value of 40. In two battles, for example, you can only get 36 in the best case.

1 borg has a GET value of -1:
* Galactic Emperor

The rest have no GET value:
* Cyber Death Dragon (Fusion Borg)
* Machine Dragon
* Cyber Machine Seiryu (Fusion Borg)
* Cyber Machine Suzaku (Fusion Borg)
* Cyber Machine Byakko (Fusion Borg)
* Cyber Machine Genbu (Fusion Borg)
* G Red (One of the borg we have)
* Neo G Red (One of the borgs we have)
* G Black (It is obtained in a special event)

By changing the GET value to a positive value, you can get the borgs in the scenario: Galactic Emperor for example.

The list of GET values for the EU version is available at [https://github.com/Virtual-World-RE/NeoGF/blob/main/data/eu_borgs_GET_values.csv github].

==== Files and operation ====
Borgs are implemented with a set of files, each with a specific function. These files are duplicated in the pzz of the borg and in the afs_data. The different _mdl define the different colours of the Borg. It seems that they are used with additional values in other files (the displays are not always correct when exchanging positions in the iso). The main _mdl is loaded from the pzz (collection or story menu). <span style="color: rgb(241, 196, 15);">One theory would be that part of the duplicate files would be used to load enemies and the other part allies.</span>

For each borg we have:<br>
plxxxx.pzz
├─ 000 file [[Borg - data file|plxxxxdata.bin]] -> always present
├─ 001 ? -> often not present
├─ 002 file plxxxxhit.bin -> always present
├─ 003 file [[Motions|plxxxxmot.bin]] -> often not present
├─ 004 file [[Models|plxxxx_mdl.arc]] -> always present
├─ 005 file [[Models|plxxxxb_mdl.arc]] -> always present -> blue model
├─ 006 file [[Models|plxxxxg_mdl.arc]] -> always present
├─ 007 file [[Models|plxxxxs_mdl.arc]] -> always present -> silver model
├─ 008 file [[Models|plxxxxc_mdl.arc]] -> always present
├─ 009 file [[Models|plxxxxk_mdl.arc]] -> always present -> black model
├─ 010 [[TPL (File format)|TPL]] -> name of the borg in Japanese
├─ 011 [[TPL (File format)|TPL]] -> name of the borg in Japanese (small format)
├─ 012 [[TPL (File format)|TPL]] -> borg name in the language of the game
└─ 013 file mnxxxx.tpl -> [[TPL (File format)|TPL]] -> name of the borg in the game language (small format)
[[Borg - data file|plxxxxdata.bin]] -> file can be named data2 or data3 (only one of the three is present), sometimes missing from the afs_data
plxxxxhit.bin -> always present in the afs_data and pzz
[[Motions|plxxxxmot.bin]] -> often absent from the afs_data
[[Models|plxxxx_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxb_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxg_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxs_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxc_mdl.arc]] -> sometimes missing from afs_data
[[Models|plxxxxk_mdl.arc]] -> sometimes missing from afs_data
mnxxxx.tpl

Position 002 : for borg pl0507 and pl0513, file 2 and hit differ (USA/NTSC version)

Position 003: for the borg pl0009, file 3 and the word differ (USA/NTSC version) (MOT - ''Mot'''ion) - It can be observed that for these files, there are references that could make one think of ''plxxxx_xx_animjoint''. The investigation conducted by the [https://smashboards.com/threads/melee-dat-format.292603/ Smash Bros Brawl] community shows a similar file structure. This is another version of HSD (the basic structures are the same).

Position 004 to 009: contain '''scene_data''' at the end of the data section, and are ''''"Scene"'' files (HSDLib) which contain lights, cameras, vertices, bones in the manner of a .blend.

Position 004 to 008 : files with values corresponding to 3D. In particular, we can cite '''pl0300.pzz''' where they have a header <span style="color: rgb(241, 196, 15);">with flags</span> as well as an adjustable padding if need be to have more elements '''For example for '''pl0629.pzz''' the amount <span style="color: rgb(241, 196, 15);">of flags</span> in the headers is more consistent.'' The origin <span style="color: rgb(241, 196, 15);">of the flags</span> and values in the header is currently unknown but these header fields <span style="color: rgb(241, 196, 15);">might constitute a list of available meshes in the file.</span> The software used to read the files in position 004 to 009 in plxxxx.pzz are 3D Model Researcher and HSDRawLibrary.

'''Unimplemented borgs''': pl0803 - pl080b - pl0f07<br>
Only the pl0803hit.bin and pl080bhit.bin files remain, and none of their associated files (notably, no associated pzz), which indicates that they are remnants of unimplemented borgs... Also the pzz pl0f07 has no hit file, no 4 internal TPLs (but 4 empty files instead) and just its pl0f07_mdl.arc file, which indicates that this borg is not implemented either (USA/NTSC version).

The 2 dpxxxx.pzz files are similar files to plxxxx.pzz but without the final TPL files. Their usefulness is still to be determined.

Files dpxxxx.pzz (2)
├─ 000 -> [[Borg - data file|plxxxxdata.bin]] from afs_data
├─ 001 -> empty file
├─ 002 -> plxxxxhit.bin from the afs_data
├─ 003 -> [[Motions|plxxxxmot.bin]] from the afs_data
├─ 004 -> [[Models|plxxxx_mdl.arc]] of the afs_data
├─ 005 -> [[Models|plxxxxb_mdl.arc]] of the afs_data
├─ 006 -> [[Models|plxxxxg_mdl.arc]] of the afs_data
├─ 007 -> [[Models|plxxxxs_mdl.arc]] of the afs_data
├─ 008 -> [[Models|plxxxxc_mdl.arc]] of the afs_data
└─ 009 -> [[Models|plxxxxk_mdl.arc]] of the afs_data

==== Memory backups ====

=== Data Crystals ===
The itxxxx_mdl.arz, once unpacked with pzztool.py are the templates for the data crystals.

==== Graphical interface elements ====

unitall_mdl.arc contains all the borg thumbnails used in the force creation/modification menu as well as in the post-combat scene showing which team/borgs VS team/borgs, and in the data crystals.

==== Files and operation ====
==== Memory saves ====

[[Category:Implementations]]
[[Category:Gotcha Force]]

AFS (Gotcha Force)

2023-10-07T13:06:46Z

Algoflash:

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force AFS file format and ongoing researches on it. See [[AFS (File format)]] for AFS file format description.''

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

Files packed in the Gotcha Force AFSs are loaded using their index in the suite of (offset / length) in the Table Of Content. We verify that by running the game after removing empty spaces at the end of the TOC which represent several empty blocks changing every offsets of files packed into it. Also removing Filename Directory of the game and running it starts the game without bugs.

---------------------------------
Researches:
The assembly code unpacking the afs could be found by diffs of a collection of dols parsing the AFS with the same structures, by studying offsets rather than bits:
* FD present ?
* ?
We could build a csv with dol names with presence or not of AFS with errors tolerances.

[[Category:File format]]
[[Category:Gotcha Force]]

AFS (Gotcha Force)

2023-10-07T13:06:22Z

Algoflash:

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force AFS file format and ongoing researches on it. See [[AFS (File format)]] for AFS file format description.''

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

Files packed in the Gotcha Force AFSs are loaded using their index in the suite of (offset / length) in the Table Of Content. We verify that by running the game after removing empty spaces at the end of the TOC which represent several empty blocks changing every offsets of files packed into it. Also removing Filename Directory of the game and running it starts the game without bugs.

---------------------------------
Researches:
The assembly code unpacking the afs could be found by diffs of a collection of dols parsing the AFS with the same structures, by studying offsets rather than bits:
* FD present ?
* ?
We could build a csv with dol names with presence or not of AFS with errors tolerences.

[[Category:File format]]
[[Category:Gotcha Force]]

AFS (Gotcha Force)

2023-10-07T13:05:27Z

Algoflash:

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force AFS file format and ongoing researches on it. See [[AFS (File format)]] for AFS file format description.''

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

Files packed in the Gotcha Force AFSs are loaded using their index in the suite of (offset / length) in the Table Of Content. We verify that by running the game after removing empty spaces at the end of the TOC which represent several empty blocks changing every offsets of files packed into it. Also removing Filename Directory of the game and running it starts the game without bugs.

---------------------------------
Researches:
The assembly code unpacking the afs could be find by diffs of a collection of dols parsing the AFS with the same structures, by studiying offsets rather than bits:
* FD present ?
* ?
We could build a csv with dol names with presence or not of AFS with errors tolerences.

[[Category:File format]]
[[Category:Gotcha Force]]

DOL (Gotcha Force)

2023-10-07T13:04:10Z

Algoflash: /* Strings JAP */

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force DOL file format and ongoing researches on it. See [[DOL (File format)]] for DOL file format description.''

{{Research | 3| Research on how functions works and how the dol works is nedded. }}

== Memory map ==
The dol file is mapped in memory and the free available space remaining is next used to create the Arena containing Heaps. For instance we found Warehouse variables in the EU dol mapped in the interval [80593190:80598044[.

So patching the dol is hard because we have to find unused free space in the memory. The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that max dol mapping addresses in memory are:
* 0x80700000 // production boards
* 0x81200000 // development boards

<div style="color: rgb(241, 196, 15);">
In production we can override MetroTRK memory areas or even override apploader trailer before the bootrom/IPL area. Further investigations have to be done on the [[GCM (File format)|iso/GCM]] sys to see how debug memory is mapped in debug mode (apploader vars used in the apploader).
* Is it possible to know where exactly MetroTRK is mapped?
* Is there any other libs/datas unused in dol?
</div>

Note:
* It's perfectly possible and tested to patch the apploader trailer and raise the trailer size with [[GCM (File format)|GCM/iso]] patch. It gives us 0x100000 bytes available.

The dol entry_point call the __init_registers procedure which will set the reserved following General Purpose Registers:
* R1 (stack)
* R2 (_SDA2_BASE_) - This is the read only _SDA2_.
* R13 (_SDA_BASE_) - This is the read / write _SDA_.
'''S'''mall '''D'''ata '''A'''nchors are used with a signed short offset (-0x8000 à +0x7fff).
* -0x8000(R13) = address of .sdata followed by .sbss
* -0x8000(R2) = address of .sdata2 followed by .sbss2
* R1 = often the .sbss2 end address + 0x10000

So often only a part of available SDA negative offsets are used for R2 and R13 using -0x8000 at start.

<div class="toccolours mw-collapsible mw-collapsed">
=== USA: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab80 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad160 | 802b0160 | 00000020 | True |
| data8 | 002ad180 | 802b0180 | 00000020 | True |
| data9 | 002ad1a0 | 802b01a0 | 0000acc0 | True |
| data10 | 002b7e60 | 802bae60 | 000f42c0 | True |
| data11 | 003ac120 | 804335a0 | 00002b20 | True |
| data12 | 003aec40 | 80436a20 | 00006ae0 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803af140 length:0008e3e8
* R1 = 8044d528
* R2 = 8043ea20
* R13 = 8043b5a0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0160 | 002aab80 |
| .ctors | 802b0160 | 802b0180 | 00000020 |
| .dtors | 802b0180 | 802b01a0 | 00000020 |
| .rodata | 802b01a0 | 802bae60 | 0000acc0 |
| .data | 802bae60 | 803af120 | 000f42c0 |
| empty | 803af120 | 803af140 | 00000020 |
| .bss | 803af140 | 804335a0 | 00084460 |
| .sdata | 804335a0 | 804360c0 | 00002b20 |
| .sbss | 804360c0 | 80436a20 | 00000960 |
| .sdata2 | 80436a20 | 8043d500 | 00006ae0 |
| .sbss2 | 8043d500 | 8043d528 | 00000028 |
| stack | 8043d528 | 8044d528 | 00010000 |
| empty | 8044d528 | 8044d540 | 00000018 |
| ArenaLo | 8044d540 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00500000 |
|----------------------------------------------|
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== EU: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002ac800 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002aede0 | 802b1de0 | 00000020 | True |
| data8 | 002aee00 | 802b1e00 | 00000020 | True |
| data9 | 002aee20 | 802b1e20 | 0000f060 | True |
| data10 | 002bde80 | 802c0e80 | 000f5d40 | True |
| data11 | 003b3bc0 | 8043cbe0 | 00002b20 | True |
| data12 | 003b66e0 | 80440080 | 00006d20 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803b6bc0 length:00090208
* R1 = 80456dc8
* R2 = 80448080
* R13 = 80444be0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b1de0 | 002ac800 |
| .ctors | 802b1de0 | 802b1e00 | 00000020 |
| .dtors | 802b1e00 | 802b1e20 | 00000020 |
| .rodata | 802b1e20 | 802c0e80 | 0000f060 |
| .data | 802c0e80 | 803b6bc0 | 000f5d40 |
| .bss | 803b6bc0 | 8043cbe0 | 00086020 |
| .sdata | 8043cbe0 | 8043f700 | 00002b20 |
| .sbss | 8043f700 | 80440080 | 00000980 |
| .sdata2 | 80440080 | 80446da0 | 00006d20 |
| .sbss2 | 80446da0 | 80446dc8 | 00000028 |
| stack | 80446dc8 | 80456dc8 | 00010000 |
| empty | 80456dc8 | 80456de0 | 00000018 |
| ArenaLo | 80456de0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fff40 | |
| FST | 817fff40 | 81800000 | 000000C0 |
|----------------------------------------------|
80593A00 -> 80598040 Wharehouse
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== JAP: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab20 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad100 | 802b0100 | 00000020 | True |
| data8 | 002ad120 | 802b0120 | 00000020 | True |
| data9 | 002ad140 | 802b0140 | 0000a2e0 | True |
| data10 | 002b7420 | 802ba420 | 000f3e60 | True |
| data11 | 003ab280 | 804326e0 | 00002b00 | True |
| data12 | 003add80 | 80435b40 | 00006b60 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803ae280 length:0008e448
* R1 = 8044c6c8
* R2 = 8043db40
* R13 = 8043a6e0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0100 | 002aab20 |
| .ctors | 802b0100 | 802b0120 | 00000020 |
| .dtors | 802b0120 | 802b0140 | 00000020 |
| .rodata | 802b0140 | 802ba420 | 0000a2e0 |
| .data | 802ba420 | 803ae280 | 000f3e60 |
| .bss | 803ae280 | 804326e0 | 00084460 |
| .sdata | 804326e0 | 804351e0 | 00002b00 |
| .sbss | 804351e0 | 80435b40 | 00000960 |
| .sdata2 | 80435b40 | 8043c6a0 | 00006b60 |
| .sbss2 | 8043c6a0 | 8043c6c8 | 00000028 |
| stack | 8043c6c8 | 8044c6c8 | 00010000 |
| empty | 8044c6c8 | 8044c6e0 | 00000018 |
| ArenaLo | 8044c6e0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00000060 |
|----------------------------------------------|
</div></div>

== Symbol map ==
The symbol map allows to put names on procedures and data. It can be loaded into dolphin emulator in debug mode with the .map file format.

Symbol map USA: https://github.com/Virtual-World-RE/NeoGF/blob/main/data/GG4E-CSM-20220412.map

== MetroTRK ==

MetroTRK can be activated by patching the bi2.bin DebugFlag and also by patching the following addresses to start the debugger in BBA ('''B'''road'''B'''and '''A'''dapter?) mode:
* USA: Put a breakpoint at 80003190 then set r3 to 1
* EU: Put a breakpoint at 800031C0 then set r7 to 4

<div style="color: rgb(241, 196, 15);">
The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that there are debug vars in [[GCM (File format)|GCM/iso]] system files. [https://github.com/Virtual-World-RE/NeoGF/tree/main/gcmtool gcmtool.py] allow to patch them.
</div>

== SDK & libs ==
All libs and SDK are staticly linked inside the dol.

We found these libs and SDK:
* GCN SDK - Base dolphin SDK.
* Sysdolphin base library: Hal SysDolphin (HSD) Graphic and physic engine - https://github.com/doldecomp/melee/tree/master/src/sysdolphin/baselib
* MetroTRK: Target Resident Debugging Kernel for embedded systems. It's an embedded Kernel for debug.
* Metrowerks CW Runtime library: CodeWarrior: Metrowerks Standard Library and C/C++ Runtime
* And from ADXT/GC to CRI CFT/GC: It seems to be audio and video codecs.

<div class="toccolours mw-collapsible mw-collapsed">
=== H and C files ===
<div class="mw-collapsible-content">
All 3 iso contain followings .h and .c symbols in the .data, .rodata, .sdata and .sdata2. The EU version contains also the symbol "objalloc.h".
aobj.h
cobj.h
jobj.h
lobj.h
object.h

GCN_Mem_Alloc.c
aobj.c
bytecode.c
class.c
cobj.c
displayfunc.c
dobj.c
dvd.c
dvdfs.c
fobj.c
fog.c
hash.c
id.c
initialize.c
jobj.c
list.c
lobj.c
memory.c
mobj.c
mtx.c
objalloc.c
perf.c
pobj.c
robj.c
tev.c
texp.c
texpdag.c
tobj.c
tpl.c
util.c
vi.c
video.c
wobj.c
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings USA ===
<div class="mw-collapsible-content">
String list found in the dol and allowing to find libs / SDK:
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK – OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : %s %s Apr 17 2003 12:33:06
<< Dolphin SDK – EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== Strings EU ===
<div class="mw-collapsible-content">
String list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library initializing default heap
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
DSPInit(): Build Date: Apr 17 2003 12:34:16
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
HSD_INIT_HEAP_MAX_NUM is obsolete since 1.3.0.0.
HSD_INIT_AUDIO_HEAP_SIZE is obsolete since 1.3.0.0.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== Strings JAP ===
<div class="mw-collapsible-content">
String list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

[[Category:File format]]
[[Category:Gotcha Force]]

DOL (Gotcha Force)

2023-10-07T13:04:01Z

Algoflash: /* Strings EU */

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force DOL file format and ongoing researches on it. See [[DOL (File format)]] for DOL file format description.''

{{Research | 3| Research on how functions works and how the dol works is nedded. }}

== Memory map ==
The dol file is mapped in memory and the free available space remaining is next used to create the Arena containing Heaps. For instance we found Warehouse variables in the EU dol mapped in the interval [80593190:80598044[.

So patching the dol is hard because we have to find unused free space in the memory. The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that max dol mapping addresses in memory are:
* 0x80700000 // production boards
* 0x81200000 // development boards

<div style="color: rgb(241, 196, 15);">
In production we can override MetroTRK memory areas or even override apploader trailer before the bootrom/IPL area. Further investigations have to be done on the [[GCM (File format)|iso/GCM]] sys to see how debug memory is mapped in debug mode (apploader vars used in the apploader).
* Is it possible to know where exactly MetroTRK is mapped?
* Is there any other libs/datas unused in dol?
</div>

Note:
* It's perfectly possible and tested to patch the apploader trailer and raise the trailer size with [[GCM (File format)|GCM/iso]] patch. It gives us 0x100000 bytes available.

The dol entry_point call the __init_registers procedure which will set the reserved following General Purpose Registers:
* R1 (stack)
* R2 (_SDA2_BASE_) - This is the read only _SDA2_.
* R13 (_SDA_BASE_) - This is the read / write _SDA_.
'''S'''mall '''D'''ata '''A'''nchors are used with a signed short offset (-0x8000 à +0x7fff).
* -0x8000(R13) = address of .sdata followed by .sbss
* -0x8000(R2) = address of .sdata2 followed by .sbss2
* R1 = often the .sbss2 end address + 0x10000

So often only a part of available SDA negative offsets are used for R2 and R13 using -0x8000 at start.

<div class="toccolours mw-collapsible mw-collapsed">
=== USA: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab80 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad160 | 802b0160 | 00000020 | True |
| data8 | 002ad180 | 802b0180 | 00000020 | True |
| data9 | 002ad1a0 | 802b01a0 | 0000acc0 | True |
| data10 | 002b7e60 | 802bae60 | 000f42c0 | True |
| data11 | 003ac120 | 804335a0 | 00002b20 | True |
| data12 | 003aec40 | 80436a20 | 00006ae0 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803af140 length:0008e3e8
* R1 = 8044d528
* R2 = 8043ea20
* R13 = 8043b5a0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0160 | 002aab80 |
| .ctors | 802b0160 | 802b0180 | 00000020 |
| .dtors | 802b0180 | 802b01a0 | 00000020 |
| .rodata | 802b01a0 | 802bae60 | 0000acc0 |
| .data | 802bae60 | 803af120 | 000f42c0 |
| empty | 803af120 | 803af140 | 00000020 |
| .bss | 803af140 | 804335a0 | 00084460 |
| .sdata | 804335a0 | 804360c0 | 00002b20 |
| .sbss | 804360c0 | 80436a20 | 00000960 |
| .sdata2 | 80436a20 | 8043d500 | 00006ae0 |
| .sbss2 | 8043d500 | 8043d528 | 00000028 |
| stack | 8043d528 | 8044d528 | 00010000 |
| empty | 8044d528 | 8044d540 | 00000018 |
| ArenaLo | 8044d540 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00500000 |
|----------------------------------------------|
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== EU: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002ac800 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002aede0 | 802b1de0 | 00000020 | True |
| data8 | 002aee00 | 802b1e00 | 00000020 | True |
| data9 | 002aee20 | 802b1e20 | 0000f060 | True |
| data10 | 002bde80 | 802c0e80 | 000f5d40 | True |
| data11 | 003b3bc0 | 8043cbe0 | 00002b20 | True |
| data12 | 003b66e0 | 80440080 | 00006d20 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803b6bc0 length:00090208
* R1 = 80456dc8
* R2 = 80448080
* R13 = 80444be0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b1de0 | 002ac800 |
| .ctors | 802b1de0 | 802b1e00 | 00000020 |
| .dtors | 802b1e00 | 802b1e20 | 00000020 |
| .rodata | 802b1e20 | 802c0e80 | 0000f060 |
| .data | 802c0e80 | 803b6bc0 | 000f5d40 |
| .bss | 803b6bc0 | 8043cbe0 | 00086020 |
| .sdata | 8043cbe0 | 8043f700 | 00002b20 |
| .sbss | 8043f700 | 80440080 | 00000980 |
| .sdata2 | 80440080 | 80446da0 | 00006d20 |
| .sbss2 | 80446da0 | 80446dc8 | 00000028 |
| stack | 80446dc8 | 80456dc8 | 00010000 |
| empty | 80456dc8 | 80456de0 | 00000018 |
| ArenaLo | 80456de0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fff40 | |
| FST | 817fff40 | 81800000 | 000000C0 |
|----------------------------------------------|
80593A00 -> 80598040 Wharehouse
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== JAP: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab20 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad100 | 802b0100 | 00000020 | True |
| data8 | 002ad120 | 802b0120 | 00000020 | True |
| data9 | 002ad140 | 802b0140 | 0000a2e0 | True |
| data10 | 002b7420 | 802ba420 | 000f3e60 | True |
| data11 | 003ab280 | 804326e0 | 00002b00 | True |
| data12 | 003add80 | 80435b40 | 00006b60 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803ae280 length:0008e448
* R1 = 8044c6c8
* R2 = 8043db40
* R13 = 8043a6e0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0100 | 002aab20 |
| .ctors | 802b0100 | 802b0120 | 00000020 |
| .dtors | 802b0120 | 802b0140 | 00000020 |
| .rodata | 802b0140 | 802ba420 | 0000a2e0 |
| .data | 802ba420 | 803ae280 | 000f3e60 |
| .bss | 803ae280 | 804326e0 | 00084460 |
| .sdata | 804326e0 | 804351e0 | 00002b00 |
| .sbss | 804351e0 | 80435b40 | 00000960 |
| .sdata2 | 80435b40 | 8043c6a0 | 00006b60 |
| .sbss2 | 8043c6a0 | 8043c6c8 | 00000028 |
| stack | 8043c6c8 | 8044c6c8 | 00010000 |
| empty | 8044c6c8 | 8044c6e0 | 00000018 |
| ArenaLo | 8044c6e0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00000060 |
|----------------------------------------------|
</div></div>

== Symbol map ==
The symbol map allows to put names on procedures and data. It can be loaded into dolphin emulator in debug mode with the .map file format.

Symbol map USA: https://github.com/Virtual-World-RE/NeoGF/blob/main/data/GG4E-CSM-20220412.map

== MetroTRK ==

MetroTRK can be activated by patching the bi2.bin DebugFlag and also by patching the following addresses to start the debugger in BBA ('''B'''road'''B'''and '''A'''dapter?) mode:
* USA: Put a breakpoint at 80003190 then set r3 to 1
* EU: Put a breakpoint at 800031C0 then set r7 to 4

<div style="color: rgb(241, 196, 15);">
The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that there are debug vars in [[GCM (File format)|GCM/iso]] system files. [https://github.com/Virtual-World-RE/NeoGF/tree/main/gcmtool gcmtool.py] allow to patch them.
</div>

== SDK & libs ==
All libs and SDK are staticly linked inside the dol.

We found these libs and SDK:
* GCN SDK - Base dolphin SDK.
* Sysdolphin base library: Hal SysDolphin (HSD) Graphic and physic engine - https://github.com/doldecomp/melee/tree/master/src/sysdolphin/baselib
* MetroTRK: Target Resident Debugging Kernel for embedded systems. It's an embedded Kernel for debug.
* Metrowerks CW Runtime library: CodeWarrior: Metrowerks Standard Library and C/C++ Runtime
* And from ADXT/GC to CRI CFT/GC: It seems to be audio and video codecs.

<div class="toccolours mw-collapsible mw-collapsed">
=== H and C files ===
<div class="mw-collapsible-content">
All 3 iso contain followings .h and .c symbols in the .data, .rodata, .sdata and .sdata2. The EU version contains also the symbol "objalloc.h".
aobj.h
cobj.h
jobj.h
lobj.h
object.h

GCN_Mem_Alloc.c
aobj.c
bytecode.c
class.c
cobj.c
displayfunc.c
dobj.c
dvd.c
dvdfs.c
fobj.c
fog.c
hash.c
id.c
initialize.c
jobj.c
list.c
lobj.c
memory.c
mobj.c
mtx.c
objalloc.c
perf.c
pobj.c
robj.c
tev.c
texp.c
texpdag.c
tobj.c
tpl.c
util.c
vi.c
video.c
wobj.c
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings USA ===
<div class="mw-collapsible-content">
String list found in the dol and allowing to find libs / SDK:
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK – OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : %s %s Apr 17 2003 12:33:06
<< Dolphin SDK – EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== Strings EU ===
<div class="mw-collapsible-content">
String list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library initializing default heap
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
DSPInit(): Build Date: Apr 17 2003 12:34:16
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
HSD_INIT_HEAP_MAX_NUM is obsolete since 1.3.0.0.
HSD_INIT_AUDIO_HEAP_SIZE is obsolete since 1.3.0.0.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== Strings JAP ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

[[Category:File format]]
[[Category:Gotcha Force]]

DOL (Gotcha Force)

2023-10-07T13:03:40Z

Algoflash: /* Strings USA */

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force DOL file format and ongoing researches on it. See [[DOL (File format)]] for DOL file format description.''

{{Research | 3| Research on how functions works and how the dol works is nedded. }}

== Memory map ==
The dol file is mapped in memory and the free available space remaining is next used to create the Arena containing Heaps. For instance we found Warehouse variables in the EU dol mapped in the interval [80593190:80598044[.

So patching the dol is hard because we have to find unused free space in the memory. The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that max dol mapping addresses in memory are:
* 0x80700000 // production boards
* 0x81200000 // development boards

<div style="color: rgb(241, 196, 15);">
In production we can override MetroTRK memory areas or even override apploader trailer before the bootrom/IPL area. Further investigations have to be done on the [[GCM (File format)|iso/GCM]] sys to see how debug memory is mapped in debug mode (apploader vars used in the apploader).
* Is it possible to know where exactly MetroTRK is mapped?
* Is there any other libs/datas unused in dol?
</div>

Note:
* It's perfectly possible and tested to patch the apploader trailer and raise the trailer size with [[GCM (File format)|GCM/iso]] patch. It gives us 0x100000 bytes available.

The dol entry_point call the __init_registers procedure which will set the reserved following General Purpose Registers:
* R1 (stack)
* R2 (_SDA2_BASE_) - This is the read only _SDA2_.
* R13 (_SDA_BASE_) - This is the read / write _SDA_.
'''S'''mall '''D'''ata '''A'''nchors are used with a signed short offset (-0x8000 à +0x7fff).
* -0x8000(R13) = address of .sdata followed by .sbss
* -0x8000(R2) = address of .sdata2 followed by .sbss2
* R1 = often the .sbss2 end address + 0x10000

So often only a part of available SDA negative offsets are used for R2 and R13 using -0x8000 at start.

<div class="toccolours mw-collapsible mw-collapsed">
=== USA: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab80 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad160 | 802b0160 | 00000020 | True |
| data8 | 002ad180 | 802b0180 | 00000020 | True |
| data9 | 002ad1a0 | 802b01a0 | 0000acc0 | True |
| data10 | 002b7e60 | 802bae60 | 000f42c0 | True |
| data11 | 003ac120 | 804335a0 | 00002b20 | True |
| data12 | 003aec40 | 80436a20 | 00006ae0 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803af140 length:0008e3e8
* R1 = 8044d528
* R2 = 8043ea20
* R13 = 8043b5a0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0160 | 002aab80 |
| .ctors | 802b0160 | 802b0180 | 00000020 |
| .dtors | 802b0180 | 802b01a0 | 00000020 |
| .rodata | 802b01a0 | 802bae60 | 0000acc0 |
| .data | 802bae60 | 803af120 | 000f42c0 |
| empty | 803af120 | 803af140 | 00000020 |
| .bss | 803af140 | 804335a0 | 00084460 |
| .sdata | 804335a0 | 804360c0 | 00002b20 |
| .sbss | 804360c0 | 80436a20 | 00000960 |
| .sdata2 | 80436a20 | 8043d500 | 00006ae0 |
| .sbss2 | 8043d500 | 8043d528 | 00000028 |
| stack | 8043d528 | 8044d528 | 00010000 |
| empty | 8044d528 | 8044d540 | 00000018 |
| ArenaLo | 8044d540 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00500000 |
|----------------------------------------------|
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== EU: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002ac800 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002aede0 | 802b1de0 | 00000020 | True |
| data8 | 002aee00 | 802b1e00 | 00000020 | True |
| data9 | 002aee20 | 802b1e20 | 0000f060 | True |
| data10 | 002bde80 | 802c0e80 | 000f5d40 | True |
| data11 | 003b3bc0 | 8043cbe0 | 00002b20 | True |
| data12 | 003b66e0 | 80440080 | 00006d20 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803b6bc0 length:00090208
* R1 = 80456dc8
* R2 = 80448080
* R13 = 80444be0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b1de0 | 002ac800 |
| .ctors | 802b1de0 | 802b1e00 | 00000020 |
| .dtors | 802b1e00 | 802b1e20 | 00000020 |
| .rodata | 802b1e20 | 802c0e80 | 0000f060 |
| .data | 802c0e80 | 803b6bc0 | 000f5d40 |
| .bss | 803b6bc0 | 8043cbe0 | 00086020 |
| .sdata | 8043cbe0 | 8043f700 | 00002b20 |
| .sbss | 8043f700 | 80440080 | 00000980 |
| .sdata2 | 80440080 | 80446da0 | 00006d20 |
| .sbss2 | 80446da0 | 80446dc8 | 00000028 |
| stack | 80446dc8 | 80456dc8 | 00010000 |
| empty | 80456dc8 | 80456de0 | 00000018 |
| ArenaLo | 80456de0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fff40 | |
| FST | 817fff40 | 81800000 | 000000C0 |
|----------------------------------------------|
80593A00 -> 80598040 Wharehouse
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== JAP: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab20 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad100 | 802b0100 | 00000020 | True |
| data8 | 002ad120 | 802b0120 | 00000020 | True |
| data9 | 002ad140 | 802b0140 | 0000a2e0 | True |
| data10 | 002b7420 | 802ba420 | 000f3e60 | True |
| data11 | 003ab280 | 804326e0 | 00002b00 | True |
| data12 | 003add80 | 80435b40 | 00006b60 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803ae280 length:0008e448
* R1 = 8044c6c8
* R2 = 8043db40
* R13 = 8043a6e0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0100 | 002aab20 |
| .ctors | 802b0100 | 802b0120 | 00000020 |
| .dtors | 802b0120 | 802b0140 | 00000020 |
| .rodata | 802b0140 | 802ba420 | 0000a2e0 |
| .data | 802ba420 | 803ae280 | 000f3e60 |
| .bss | 803ae280 | 804326e0 | 00084460 |
| .sdata | 804326e0 | 804351e0 | 00002b00 |
| .sbss | 804351e0 | 80435b40 | 00000960 |
| .sdata2 | 80435b40 | 8043c6a0 | 00006b60 |
| .sbss2 | 8043c6a0 | 8043c6c8 | 00000028 |
| stack | 8043c6c8 | 8044c6c8 | 00010000 |
| empty | 8044c6c8 | 8044c6e0 | 00000018 |
| ArenaLo | 8044c6e0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00000060 |
|----------------------------------------------|
</div></div>

== Symbol map ==
The symbol map allows to put names on procedures and data. It can be loaded into dolphin emulator in debug mode with the .map file format.

Symbol map USA: https://github.com/Virtual-World-RE/NeoGF/blob/main/data/GG4E-CSM-20220412.map

== MetroTRK ==

MetroTRK can be activated by patching the bi2.bin DebugFlag and also by patching the following addresses to start the debugger in BBA ('''B'''road'''B'''and '''A'''dapter?) mode:
* USA: Put a breakpoint at 80003190 then set r3 to 1
* EU: Put a breakpoint at 800031C0 then set r7 to 4

<div style="color: rgb(241, 196, 15);">
The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that there are debug vars in [[GCM (File format)|GCM/iso]] system files. [https://github.com/Virtual-World-RE/NeoGF/tree/main/gcmtool gcmtool.py] allow to patch them.
</div>

== SDK & libs ==
All libs and SDK are staticly linked inside the dol.

We found these libs and SDK:
* GCN SDK - Base dolphin SDK.
* Sysdolphin base library: Hal SysDolphin (HSD) Graphic and physic engine - https://github.com/doldecomp/melee/tree/master/src/sysdolphin/baselib
* MetroTRK: Target Resident Debugging Kernel for embedded systems. It's an embedded Kernel for debug.
* Metrowerks CW Runtime library: CodeWarrior: Metrowerks Standard Library and C/C++ Runtime
* And from ADXT/GC to CRI CFT/GC: It seems to be audio and video codecs.

<div class="toccolours mw-collapsible mw-collapsed">
=== H and C files ===
<div class="mw-collapsible-content">
All 3 iso contain followings .h and .c symbols in the .data, .rodata, .sdata and .sdata2. The EU version contains also the symbol "objalloc.h".
aobj.h
cobj.h
jobj.h
lobj.h
object.h

GCN_Mem_Alloc.c
aobj.c
bytecode.c
class.c
cobj.c
displayfunc.c
dobj.c
dvd.c
dvdfs.c
fobj.c
fog.c
hash.c
id.c
initialize.c
jobj.c
list.c
lobj.c
memory.c
mobj.c
mtx.c
objalloc.c
perf.c
pobj.c
robj.c
tev.c
texp.c
texpdag.c
tobj.c
tpl.c
util.c
vi.c
video.c
wobj.c
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings USA ===
<div class="mw-collapsible-content">
String list found in the dol and allowing to find libs / SDK:
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK – OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : %s %s Apr 17 2003 12:33:06
<< Dolphin SDK – EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== Strings EU ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library initializing default heap
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
DSPInit(): Build Date: Apr 17 2003 12:34:16
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
HSD_INIT_HEAP_MAX_NUM is obsolete since 1.3.0.0.
HSD_INIT_AUDIO_HEAP_SIZE is obsolete since 1.3.0.0.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings JAP ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

[[Category:File format]]
[[Category:Gotcha Force]]

DOL (Gotcha Force)

2023-10-07T13:02:59Z

Algoflash: /* SDK & libs */

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force DOL file format and ongoing researches on it. See [[DOL (File format)]] for DOL file format description.''

{{Research | 3| Research on how functions works and how the dol works is nedded. }}

== Memory map ==
The dol file is mapped in memory and the free available space remaining is next used to create the Arena containing Heaps. For instance we found Warehouse variables in the EU dol mapped in the interval [80593190:80598044[.

So patching the dol is hard because we have to find unused free space in the memory. The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that max dol mapping addresses in memory are:
* 0x80700000 // production boards
* 0x81200000 // development boards

<div style="color: rgb(241, 196, 15);">
In production we can override MetroTRK memory areas or even override apploader trailer before the bootrom/IPL area. Further investigations have to be done on the [[GCM (File format)|iso/GCM]] sys to see how debug memory is mapped in debug mode (apploader vars used in the apploader).
* Is it possible to know where exactly MetroTRK is mapped?
* Is there any other libs/datas unused in dol?
</div>

Note:
* It's perfectly possible and tested to patch the apploader trailer and raise the trailer size with [[GCM (File format)|GCM/iso]] patch. It gives us 0x100000 bytes available.

The dol entry_point call the __init_registers procedure which will set the reserved following General Purpose Registers:
* R1 (stack)
* R2 (_SDA2_BASE_) - This is the read only _SDA2_.
* R13 (_SDA_BASE_) - This is the read / write _SDA_.
'''S'''mall '''D'''ata '''A'''nchors are used with a signed short offset (-0x8000 à +0x7fff).
* -0x8000(R13) = address of .sdata followed by .sbss
* -0x8000(R2) = address of .sdata2 followed by .sbss2
* R1 = often the .sbss2 end address + 0x10000

So often only a part of available SDA negative offsets are used for R2 and R13 using -0x8000 at start.

<div class="toccolours mw-collapsible mw-collapsed">
=== USA: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab80 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad160 | 802b0160 | 00000020 | True |
| data8 | 002ad180 | 802b0180 | 00000020 | True |
| data9 | 002ad1a0 | 802b01a0 | 0000acc0 | True |
| data10 | 002b7e60 | 802bae60 | 000f42c0 | True |
| data11 | 003ac120 | 804335a0 | 00002b20 | True |
| data12 | 003aec40 | 80436a20 | 00006ae0 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803af140 length:0008e3e8
* R1 = 8044d528
* R2 = 8043ea20
* R13 = 8043b5a0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0160 | 002aab80 |
| .ctors | 802b0160 | 802b0180 | 00000020 |
| .dtors | 802b0180 | 802b01a0 | 00000020 |
| .rodata | 802b01a0 | 802bae60 | 0000acc0 |
| .data | 802bae60 | 803af120 | 000f42c0 |
| empty | 803af120 | 803af140 | 00000020 |
| .bss | 803af140 | 804335a0 | 00084460 |
| .sdata | 804335a0 | 804360c0 | 00002b20 |
| .sbss | 804360c0 | 80436a20 | 00000960 |
| .sdata2 | 80436a20 | 8043d500 | 00006ae0 |
| .sbss2 | 8043d500 | 8043d528 | 00000028 |
| stack | 8043d528 | 8044d528 | 00010000 |
| empty | 8044d528 | 8044d540 | 00000018 |
| ArenaLo | 8044d540 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00500000 |
|----------------------------------------------|
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== EU: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002ac800 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002aede0 | 802b1de0 | 00000020 | True |
| data8 | 002aee00 | 802b1e00 | 00000020 | True |
| data9 | 002aee20 | 802b1e20 | 0000f060 | True |
| data10 | 002bde80 | 802c0e80 | 000f5d40 | True |
| data11 | 003b3bc0 | 8043cbe0 | 00002b20 | True |
| data12 | 003b66e0 | 80440080 | 00006d20 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803b6bc0 length:00090208
* R1 = 80456dc8
* R2 = 80448080
* R13 = 80444be0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b1de0 | 002ac800 |
| .ctors | 802b1de0 | 802b1e00 | 00000020 |
| .dtors | 802b1e00 | 802b1e20 | 00000020 |
| .rodata | 802b1e20 | 802c0e80 | 0000f060 |
| .data | 802c0e80 | 803b6bc0 | 000f5d40 |
| .bss | 803b6bc0 | 8043cbe0 | 00086020 |
| .sdata | 8043cbe0 | 8043f700 | 00002b20 |
| .sbss | 8043f700 | 80440080 | 00000980 |
| .sdata2 | 80440080 | 80446da0 | 00006d20 |
| .sbss2 | 80446da0 | 80446dc8 | 00000028 |
| stack | 80446dc8 | 80456dc8 | 00010000 |
| empty | 80456dc8 | 80456de0 | 00000018 |
| ArenaLo | 80456de0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fff40 | |
| FST | 817fff40 | 81800000 | 000000C0 |
|----------------------------------------------|
80593A00 -> 80598040 Wharehouse
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== JAP: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab20 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad100 | 802b0100 | 00000020 | True |
| data8 | 002ad120 | 802b0120 | 00000020 | True |
| data9 | 002ad140 | 802b0140 | 0000a2e0 | True |
| data10 | 002b7420 | 802ba420 | 000f3e60 | True |
| data11 | 003ab280 | 804326e0 | 00002b00 | True |
| data12 | 003add80 | 80435b40 | 00006b60 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803ae280 length:0008e448
* R1 = 8044c6c8
* R2 = 8043db40
* R13 = 8043a6e0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0100 | 002aab20 |
| .ctors | 802b0100 | 802b0120 | 00000020 |
| .dtors | 802b0120 | 802b0140 | 00000020 |
| .rodata | 802b0140 | 802ba420 | 0000a2e0 |
| .data | 802ba420 | 803ae280 | 000f3e60 |
| .bss | 803ae280 | 804326e0 | 00084460 |
| .sdata | 804326e0 | 804351e0 | 00002b00 |
| .sbss | 804351e0 | 80435b40 | 00000960 |
| .sdata2 | 80435b40 | 8043c6a0 | 00006b60 |
| .sbss2 | 8043c6a0 | 8043c6c8 | 00000028 |
| stack | 8043c6c8 | 8044c6c8 | 00010000 |
| empty | 8044c6c8 | 8044c6e0 | 00000018 |
| ArenaLo | 8044c6e0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00000060 |
|----------------------------------------------|
</div></div>

== Symbol map ==
The symbol map allows to put names on procedures and data. It can be loaded into dolphin emulator in debug mode with the .map file format.

Symbol map USA: https://github.com/Virtual-World-RE/NeoGF/blob/main/data/GG4E-CSM-20220412.map

== MetroTRK ==

MetroTRK can be activated by patching the bi2.bin DebugFlag and also by patching the following addresses to start the debugger in BBA ('''B'''road'''B'''and '''A'''dapter?) mode:
* USA: Put a breakpoint at 80003190 then set r3 to 1
* EU: Put a breakpoint at 800031C0 then set r7 to 4

<div style="color: rgb(241, 196, 15);">
The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that there are debug vars in [[GCM (File format)|GCM/iso]] system files. [https://github.com/Virtual-World-RE/NeoGF/tree/main/gcmtool gcmtool.py] allow to patch them.
</div>

== SDK & libs ==
All libs and SDK are staticly linked inside the dol.

We found these libs and SDK:
* GCN SDK - Base dolphin SDK.
* Sysdolphin base library: Hal SysDolphin (HSD) Graphic and physic engine - https://github.com/doldecomp/melee/tree/master/src/sysdolphin/baselib
* MetroTRK: Target Resident Debugging Kernel for embedded systems. It's an embedded Kernel for debug.
* Metrowerks CW Runtime library: CodeWarrior: Metrowerks Standard Library and C/C++ Runtime
* And from ADXT/GC to CRI CFT/GC: It seems to be audio and video codecs.

<div class="toccolours mw-collapsible mw-collapsed">
=== H and C files ===
<div class="mw-collapsible-content">
All 3 iso contain followings .h and .c symbols in the .data, .rodata, .sdata and .sdata2. The EU version contains also the symbol "objalloc.h".
aobj.h
cobj.h
jobj.h
lobj.h
object.h

GCN_Mem_Alloc.c
aobj.c
bytecode.c
class.c
cobj.c
displayfunc.c
dobj.c
dvd.c
dvdfs.c
fobj.c
fog.c
hash.c
id.c
initialize.c
jobj.c
list.c
lobj.c
memory.c
mobj.c
mtx.c
objalloc.c
perf.c
pobj.c
robj.c
tev.c
texp.c
texpdag.c
tobj.c
tpl.c
util.c
vi.c
video.c
wobj.c
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings USA ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK – OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : %s %s Apr 17 2003 12:33:06
<< Dolphin SDK – EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings EU ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library initializing default heap
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
DSPInit(): Build Date: Apr 17 2003 12:34:16
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
HSD_INIT_HEAP_MAX_NUM is obsolete since 1.3.0.0.
HSD_INIT_AUDIO_HEAP_SIZE is obsolete since 1.3.0.0.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings JAP ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

[[Category:File format]]
[[Category:Gotcha Force]]

DOL (Gotcha Force)

2023-10-07T13:01:38Z

Algoflash: /* MetroTRK */

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force DOL file format and ongoing researches on it. See [[DOL (File format)]] for DOL file format description.''

{{Research | 3| Research on how functions works and how the dol works is nedded. }}

== Memory map ==
The dol file is mapped in memory and the free available space remaining is next used to create the Arena containing Heaps. For instance we found Warehouse variables in the EU dol mapped in the interval [80593190:80598044[.

So patching the dol is hard because we have to find unused free space in the memory. The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that max dol mapping addresses in memory are:
* 0x80700000 // production boards
* 0x81200000 // development boards

<div style="color: rgb(241, 196, 15);">
In production we can override MetroTRK memory areas or even override apploader trailer before the bootrom/IPL area. Further investigations have to be done on the [[GCM (File format)|iso/GCM]] sys to see how debug memory is mapped in debug mode (apploader vars used in the apploader).
* Is it possible to know where exactly MetroTRK is mapped?
* Is there any other libs/datas unused in dol?
</div>

Note:
* It's perfectly possible and tested to patch the apploader trailer and raise the trailer size with [[GCM (File format)|GCM/iso]] patch. It gives us 0x100000 bytes available.

The dol entry_point call the __init_registers procedure which will set the reserved following General Purpose Registers:
* R1 (stack)
* R2 (_SDA2_BASE_) - This is the read only _SDA2_.
* R13 (_SDA_BASE_) - This is the read / write _SDA_.
'''S'''mall '''D'''ata '''A'''nchors are used with a signed short offset (-0x8000 à +0x7fff).
* -0x8000(R13) = address of .sdata followed by .sbss
* -0x8000(R2) = address of .sdata2 followed by .sbss2
* R1 = often the .sbss2 end address + 0x10000

So often only a part of available SDA negative offsets are used for R2 and R13 using -0x8000 at start.

<div class="toccolours mw-collapsible mw-collapsed">
=== USA: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab80 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad160 | 802b0160 | 00000020 | True |
| data8 | 002ad180 | 802b0180 | 00000020 | True |
| data9 | 002ad1a0 | 802b01a0 | 0000acc0 | True |
| data10 | 002b7e60 | 802bae60 | 000f42c0 | True |
| data11 | 003ac120 | 804335a0 | 00002b20 | True |
| data12 | 003aec40 | 80436a20 | 00006ae0 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803af140 length:0008e3e8
* R1 = 8044d528
* R2 = 8043ea20
* R13 = 8043b5a0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0160 | 002aab80 |
| .ctors | 802b0160 | 802b0180 | 00000020 |
| .dtors | 802b0180 | 802b01a0 | 00000020 |
| .rodata | 802b01a0 | 802bae60 | 0000acc0 |
| .data | 802bae60 | 803af120 | 000f42c0 |
| empty | 803af120 | 803af140 | 00000020 |
| .bss | 803af140 | 804335a0 | 00084460 |
| .sdata | 804335a0 | 804360c0 | 00002b20 |
| .sbss | 804360c0 | 80436a20 | 00000960 |
| .sdata2 | 80436a20 | 8043d500 | 00006ae0 |
| .sbss2 | 8043d500 | 8043d528 | 00000028 |
| stack | 8043d528 | 8044d528 | 00010000 |
| empty | 8044d528 | 8044d540 | 00000018 |
| ArenaLo | 8044d540 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00500000 |
|----------------------------------------------|
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== EU: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002ac800 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002aede0 | 802b1de0 | 00000020 | True |
| data8 | 002aee00 | 802b1e00 | 00000020 | True |
| data9 | 002aee20 | 802b1e20 | 0000f060 | True |
| data10 | 002bde80 | 802c0e80 | 000f5d40 | True |
| data11 | 003b3bc0 | 8043cbe0 | 00002b20 | True |
| data12 | 003b66e0 | 80440080 | 00006d20 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803b6bc0 length:00090208
* R1 = 80456dc8
* R2 = 80448080
* R13 = 80444be0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b1de0 | 002ac800 |
| .ctors | 802b1de0 | 802b1e00 | 00000020 |
| .dtors | 802b1e00 | 802b1e20 | 00000020 |
| .rodata | 802b1e20 | 802c0e80 | 0000f060 |
| .data | 802c0e80 | 803b6bc0 | 000f5d40 |
| .bss | 803b6bc0 | 8043cbe0 | 00086020 |
| .sdata | 8043cbe0 | 8043f700 | 00002b20 |
| .sbss | 8043f700 | 80440080 | 00000980 |
| .sdata2 | 80440080 | 80446da0 | 00006d20 |
| .sbss2 | 80446da0 | 80446dc8 | 00000028 |
| stack | 80446dc8 | 80456dc8 | 00010000 |
| empty | 80456dc8 | 80456de0 | 00000018 |
| ArenaLo | 80456de0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fff40 | |
| FST | 817fff40 | 81800000 | 000000C0 |
|----------------------------------------------|
80593A00 -> 80598040 Wharehouse
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== JAP: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab20 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad100 | 802b0100 | 00000020 | True |
| data8 | 002ad120 | 802b0120 | 00000020 | True |
| data9 | 002ad140 | 802b0140 | 0000a2e0 | True |
| data10 | 002b7420 | 802ba420 | 000f3e60 | True |
| data11 | 003ab280 | 804326e0 | 00002b00 | True |
| data12 | 003add80 | 80435b40 | 00006b60 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803ae280 length:0008e448
* R1 = 8044c6c8
* R2 = 8043db40
* R13 = 8043a6e0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0100 | 002aab20 |
| .ctors | 802b0100 | 802b0120 | 00000020 |
| .dtors | 802b0120 | 802b0140 | 00000020 |
| .rodata | 802b0140 | 802ba420 | 0000a2e0 |
| .data | 802ba420 | 803ae280 | 000f3e60 |
| .bss | 803ae280 | 804326e0 | 00084460 |
| .sdata | 804326e0 | 804351e0 | 00002b00 |
| .sbss | 804351e0 | 80435b40 | 00000960 |
| .sdata2 | 80435b40 | 8043c6a0 | 00006b60 |
| .sbss2 | 8043c6a0 | 8043c6c8 | 00000028 |
| stack | 8043c6c8 | 8044c6c8 | 00010000 |
| empty | 8044c6c8 | 8044c6e0 | 00000018 |
| ArenaLo | 8044c6e0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00000060 |
|----------------------------------------------|
</div></div>

== Symbol map ==
The symbol map allows to put names on procedures and data. It can be loaded into dolphin emulator in debug mode with the .map file format.

Symbol map USA: https://github.com/Virtual-World-RE/NeoGF/blob/main/data/GG4E-CSM-20220412.map

== MetroTRK ==

MetroTRK can be activated by patching the bi2.bin DebugFlag and also by patching the following addresses to start the debugger in BBA ('''B'''road'''B'''and '''A'''dapter?) mode:
* USA: Put a breakpoint at 80003190 then set r3 to 1
* EU: Put a breakpoint at 800031C0 then set r7 to 4

<div style="color: rgb(241, 196, 15);">
The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that there are debug vars in [[GCM (File format)|GCM/iso]] system files. [https://github.com/Virtual-World-RE/NeoGF/tree/main/gcmtool gcmtool.py] allow to patch them.
</div>

== SDK & libs ==
All libs and SDK are staticly linked inside the dol.

We found these libs and SDK:
* GCN SDK - Base dolphin SDK.
* Sysdolphin base library: Hal SysDolphin (HSD) Graphic and physic engine - https://github.com/doldecomp/melee/tree/master/src/sysdolphin/baselib
* MetroTRK: Target Resident Debugging Kernel for embedded systems. It's an embedded Kernel for debug.
* Metrowerks CW Runtime library: CodeWarrior: Metrowerks Standard Library and C/C++ Runtime
* And from ADXT/GC to CRI CFT/GC: It seems to be audio and video codecs.

<div class="toccolours mw-collapsible mw-collapsed">
=== H and C files ===
<div class="mw-collapsible-content">
All 3 iso contains following .h and .c symbols in the .data, .rodata, .sdata and .sdata2. The EU version contains also the symbol "objalloc.h".
aobj.h
cobj.h
jobj.h
lobj.h
object.h

GCN_Mem_Alloc.c
aobj.c
bytecode.c
class.c
cobj.c
displayfunc.c
dobj.c
dvd.c
dvdfs.c
fobj.c
fog.c
hash.c
id.c
initialize.c
jobj.c
list.c
lobj.c
memory.c
mobj.c
mtx.c
objalloc.c
perf.c
pobj.c
robj.c
tev.c
texp.c
texpdag.c
tobj.c
tpl.c
util.c
vi.c
video.c
wobj.c
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings USA ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK – OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : %s %s Apr 17 2003 12:33:06
<< Dolphin SDK – EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings EU ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library initializing default heap
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
DSPInit(): Build Date: Apr 17 2003 12:34:16
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
HSD_INIT_HEAP_MAX_NUM is obsolete since 1.3.0.0.
HSD_INIT_AUDIO_HEAP_SIZE is obsolete since 1.3.0.0.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings JAP ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

[[Category:File format]]
[[Category:Gotcha Force]]

DOL (Gotcha Force)

2023-10-07T13:00:44Z

Algoflash: /* Symbol map */

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force DOL file format and ongoing researches on it. See [[DOL (File format)]] for DOL file format description.''

{{Research | 3| Research on how functions works and how the dol works is nedded. }}

== Memory map ==
The dol file is mapped in memory and the free available space remaining is next used to create the Arena containing Heaps. For instance we found Warehouse variables in the EU dol mapped in the interval [80593190:80598044[.

So patching the dol is hard because we have to find unused free space in the memory. The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that max dol mapping addresses in memory are:
* 0x80700000 // production boards
* 0x81200000 // development boards

<div style="color: rgb(241, 196, 15);">
In production we can override MetroTRK memory areas or even override apploader trailer before the bootrom/IPL area. Further investigations have to be done on the [[GCM (File format)|iso/GCM]] sys to see how debug memory is mapped in debug mode (apploader vars used in the apploader).
* Is it possible to know where exactly MetroTRK is mapped?
* Is there any other libs/datas unused in dol?
</div>

Note:
* It's perfectly possible and tested to patch the apploader trailer and raise the trailer size with [[GCM (File format)|GCM/iso]] patch. It gives us 0x100000 bytes available.

The dol entry_point call the __init_registers procedure which will set the reserved following General Purpose Registers:
* R1 (stack)
* R2 (_SDA2_BASE_) - This is the read only _SDA2_.
* R13 (_SDA_BASE_) - This is the read / write _SDA_.
'''S'''mall '''D'''ata '''A'''nchors are used with a signed short offset (-0x8000 à +0x7fff).
* -0x8000(R13) = address of .sdata followed by .sbss
* -0x8000(R2) = address of .sdata2 followed by .sbss2
* R1 = often the .sbss2 end address + 0x10000

So often only a part of available SDA negative offsets are used for R2 and R13 using -0x8000 at start.

<div class="toccolours mw-collapsible mw-collapsed">
=== USA: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab80 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad160 | 802b0160 | 00000020 | True |
| data8 | 002ad180 | 802b0180 | 00000020 | True |
| data9 | 002ad1a0 | 802b01a0 | 0000acc0 | True |
| data10 | 002b7e60 | 802bae60 | 000f42c0 | True |
| data11 | 003ac120 | 804335a0 | 00002b20 | True |
| data12 | 003aec40 | 80436a20 | 00006ae0 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803af140 length:0008e3e8
* R1 = 8044d528
* R2 = 8043ea20
* R13 = 8043b5a0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0160 | 002aab80 |
| .ctors | 802b0160 | 802b0180 | 00000020 |
| .dtors | 802b0180 | 802b01a0 | 00000020 |
| .rodata | 802b01a0 | 802bae60 | 0000acc0 |
| .data | 802bae60 | 803af120 | 000f42c0 |
| empty | 803af120 | 803af140 | 00000020 |
| .bss | 803af140 | 804335a0 | 00084460 |
| .sdata | 804335a0 | 804360c0 | 00002b20 |
| .sbss | 804360c0 | 80436a20 | 00000960 |
| .sdata2 | 80436a20 | 8043d500 | 00006ae0 |
| .sbss2 | 8043d500 | 8043d528 | 00000028 |
| stack | 8043d528 | 8044d528 | 00010000 |
| empty | 8044d528 | 8044d540 | 00000018 |
| ArenaLo | 8044d540 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00500000 |
|----------------------------------------------|
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== EU: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002ac800 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002aede0 | 802b1de0 | 00000020 | True |
| data8 | 002aee00 | 802b1e00 | 00000020 | True |
| data9 | 002aee20 | 802b1e20 | 0000f060 | True |
| data10 | 002bde80 | 802c0e80 | 000f5d40 | True |
| data11 | 003b3bc0 | 8043cbe0 | 00002b20 | True |
| data12 | 003b66e0 | 80440080 | 00006d20 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803b6bc0 length:00090208
* R1 = 80456dc8
* R2 = 80448080
* R13 = 80444be0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b1de0 | 002ac800 |
| .ctors | 802b1de0 | 802b1e00 | 00000020 |
| .dtors | 802b1e00 | 802b1e20 | 00000020 |
| .rodata | 802b1e20 | 802c0e80 | 0000f060 |
| .data | 802c0e80 | 803b6bc0 | 000f5d40 |
| .bss | 803b6bc0 | 8043cbe0 | 00086020 |
| .sdata | 8043cbe0 | 8043f700 | 00002b20 |
| .sbss | 8043f700 | 80440080 | 00000980 |
| .sdata2 | 80440080 | 80446da0 | 00006d20 |
| .sbss2 | 80446da0 | 80446dc8 | 00000028 |
| stack | 80446dc8 | 80456dc8 | 00010000 |
| empty | 80456dc8 | 80456de0 | 00000018 |
| ArenaLo | 80456de0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fff40 | |
| FST | 817fff40 | 81800000 | 000000C0 |
|----------------------------------------------|
80593A00 -> 80598040 Wharehouse
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== JAP: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab20 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad100 | 802b0100 | 00000020 | True |
| data8 | 002ad120 | 802b0120 | 00000020 | True |
| data9 | 002ad140 | 802b0140 | 0000a2e0 | True |
| data10 | 002b7420 | 802ba420 | 000f3e60 | True |
| data11 | 003ab280 | 804326e0 | 00002b00 | True |
| data12 | 003add80 | 80435b40 | 00006b60 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803ae280 length:0008e448
* R1 = 8044c6c8
* R2 = 8043db40
* R13 = 8043a6e0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0100 | 002aab20 |
| .ctors | 802b0100 | 802b0120 | 00000020 |
| .dtors | 802b0120 | 802b0140 | 00000020 |
| .rodata | 802b0140 | 802ba420 | 0000a2e0 |
| .data | 802ba420 | 803ae280 | 000f3e60 |
| .bss | 803ae280 | 804326e0 | 00084460 |
| .sdata | 804326e0 | 804351e0 | 00002b00 |
| .sbss | 804351e0 | 80435b40 | 00000960 |
| .sdata2 | 80435b40 | 8043c6a0 | 00006b60 |
| .sbss2 | 8043c6a0 | 8043c6c8 | 00000028 |
| stack | 8043c6c8 | 8044c6c8 | 00010000 |
| empty | 8044c6c8 | 8044c6e0 | 00000018 |
| ArenaLo | 8044c6e0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00000060 |
|----------------------------------------------|
</div></div>

== Symbol map ==
The symbol map allows to put names on procedures and data. It can be loaded into dolphin emulator in debug mode with the .map file format.

Symbol map USA: https://github.com/Virtual-World-RE/NeoGF/blob/main/data/GG4E-CSM-20220412.map

== MetroTRK ==

MetroTRK can be activated by patching the bi2.bin DebugFlag and also by patching the following addresses to start the debugger in BBA ('''B'''road'''B'''and '''A'''dapter?) mode:
* USA: Put a breakpoint at 80003190 then set r3 to 1
* EU: Put a breakpoint at 800031C0 then set r7 to 4

<div style="color: rgb(241, 196, 15);">
The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that there is debug vars in [[GCM (File format)|GCM/iso]] system files. [https://github.com/Virtual-World-RE/NeoGF/tree/main/gcmtool gcmtool.py] allow to patch them.
</div>

== SDK & libs ==
All libs and SDK are staticly linked inside the dol.

We found these libs and SDK:
* GCN SDK - Base dolphin SDK.
* Sysdolphin base library: Hal SysDolphin (HSD) Graphic and physic engine - https://github.com/doldecomp/melee/tree/master/src/sysdolphin/baselib
* MetroTRK: Target Resident Debugging Kernel for embedded systems. It's an embedded Kernel for debug.
* Metrowerks CW Runtime library: CodeWarrior: Metrowerks Standard Library and C/C++ Runtime
* And from ADXT/GC to CRI CFT/GC: It seems to be audio and video codecs.

<div class="toccolours mw-collapsible mw-collapsed">
=== H and C files ===
<div class="mw-collapsible-content">
All 3 iso contains following .h and .c symbols in the .data, .rodata, .sdata and .sdata2. The EU version contains also the symbol "objalloc.h".
aobj.h
cobj.h
jobj.h
lobj.h
object.h

GCN_Mem_Alloc.c
aobj.c
bytecode.c
class.c
cobj.c
displayfunc.c
dobj.c
dvd.c
dvdfs.c
fobj.c
fog.c
hash.c
id.c
initialize.c
jobj.c
list.c
lobj.c
memory.c
mobj.c
mtx.c
objalloc.c
perf.c
pobj.c
robj.c
tev.c
texp.c
texpdag.c
tobj.c
tpl.c
util.c
vi.c
video.c
wobj.c
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings USA ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK – OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : %s %s Apr 17 2003 12:33:06
<< Dolphin SDK – EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings EU ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library initializing default heap
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
DSPInit(): Build Date: Apr 17 2003 12:34:16
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
HSD_INIT_HEAP_MAX_NUM is obsolete since 1.3.0.0.
HSD_INIT_AUDIO_HEAP_SIZE is obsolete since 1.3.0.0.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings JAP ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

[[Category:File format]]
[[Category:Gotcha Force]]

DOL (Gotcha Force)

2023-10-07T12:59:53Z

Algoflash:

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force DOL file format and ongoing researches on it. See [[DOL (File format)]] for DOL file format description.''

{{Research | 3| Research on how functions works and how the dol works is nedded. }}

== Memory map ==
The dol file is mapped in memory and the free available space remaining is next used to create the Arena containing Heaps. For instance we found Warehouse variables in the EU dol mapped in the interval [80593190:80598044[.

So patching the dol is hard because we have to find unused free space in the memory. The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that max dol mapping addresses in memory are:
* 0x80700000 // production boards
* 0x81200000 // development boards

<div style="color: rgb(241, 196, 15);">
In production we can override MetroTRK memory areas or even override apploader trailer before the bootrom/IPL area. Further investigations have to be done on the [[GCM (File format)|iso/GCM]] sys to see how debug memory is mapped in debug mode (apploader vars used in the apploader).
* Is it possible to know where exactly MetroTRK is mapped?
* Is there any other libs/datas unused in dol?
</div>

Note:
* It's perfectly possible and tested to patch the apploader trailer and raise the trailer size with [[GCM (File format)|GCM/iso]] patch. It gives us 0x100000 bytes available.

The dol entry_point call the __init_registers procedure which will set the reserved following General Purpose Registers:
* R1 (stack)
* R2 (_SDA2_BASE_) - This is the read only _SDA2_.
* R13 (_SDA_BASE_) - This is the read / write _SDA_.
'''S'''mall '''D'''ata '''A'''nchors are used with a signed short offset (-0x8000 à +0x7fff).
* -0x8000(R13) = address of .sdata followed by .sbss
* -0x8000(R2) = address of .sdata2 followed by .sbss2
* R1 = often the .sbss2 end address + 0x10000

So often only a part of available SDA negative offsets are used for R2 and R13 using -0x8000 at start.

<div class="toccolours mw-collapsible mw-collapsed">
=== USA: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab80 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad160 | 802b0160 | 00000020 | True |
| data8 | 002ad180 | 802b0180 | 00000020 | True |
| data9 | 002ad1a0 | 802b01a0 | 0000acc0 | True |
| data10 | 002b7e60 | 802bae60 | 000f42c0 | True |
| data11 | 003ac120 | 804335a0 | 00002b20 | True |
| data12 | 003aec40 | 80436a20 | 00006ae0 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803af140 length:0008e3e8
* R1 = 8044d528
* R2 = 8043ea20
* R13 = 8043b5a0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0160 | 002aab80 |
| .ctors | 802b0160 | 802b0180 | 00000020 |
| .dtors | 802b0180 | 802b01a0 | 00000020 |
| .rodata | 802b01a0 | 802bae60 | 0000acc0 |
| .data | 802bae60 | 803af120 | 000f42c0 |
| empty | 803af120 | 803af140 | 00000020 |
| .bss | 803af140 | 804335a0 | 00084460 |
| .sdata | 804335a0 | 804360c0 | 00002b20 |
| .sbss | 804360c0 | 80436a20 | 00000960 |
| .sdata2 | 80436a20 | 8043d500 | 00006ae0 |
| .sbss2 | 8043d500 | 8043d528 | 00000028 |
| stack | 8043d528 | 8044d528 | 00010000 |
| empty | 8044d528 | 8044d540 | 00000018 |
| ArenaLo | 8044d540 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00500000 |
|----------------------------------------------|
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== EU: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002ac800 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002aede0 | 802b1de0 | 00000020 | True |
| data8 | 002aee00 | 802b1e00 | 00000020 | True |
| data9 | 002aee20 | 802b1e20 | 0000f060 | True |
| data10 | 002bde80 | 802c0e80 | 000f5d40 | True |
| data11 | 003b3bc0 | 8043cbe0 | 00002b20 | True |
| data12 | 003b66e0 | 80440080 | 00006d20 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803b6bc0 length:00090208
* R1 = 80456dc8
* R2 = 80448080
* R13 = 80444be0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b1de0 | 002ac800 |
| .ctors | 802b1de0 | 802b1e00 | 00000020 |
| .dtors | 802b1e00 | 802b1e20 | 00000020 |
| .rodata | 802b1e20 | 802c0e80 | 0000f060 |
| .data | 802c0e80 | 803b6bc0 | 000f5d40 |
| .bss | 803b6bc0 | 8043cbe0 | 00086020 |
| .sdata | 8043cbe0 | 8043f700 | 00002b20 |
| .sbss | 8043f700 | 80440080 | 00000980 |
| .sdata2 | 80440080 | 80446da0 | 00006d20 |
| .sbss2 | 80446da0 | 80446dc8 | 00000028 |
| stack | 80446dc8 | 80456dc8 | 00010000 |
| empty | 80456dc8 | 80456de0 | 00000018 |
| ArenaLo | 80456de0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fff40 | |
| FST | 817fff40 | 81800000 | 000000C0 |
|----------------------------------------------|
80593A00 -> 80598040 Wharehouse
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== JAP: ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab20 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad100 | 802b0100 | 00000020 | True |
| data8 | 002ad120 | 802b0120 | 00000020 | True |
| data9 | 002ad140 | 802b0140 | 0000a2e0 | True |
| data10 | 002b7420 | 802ba420 | 000f3e60 | True |
| data11 | 003ab280 | 804326e0 | 00002b00 | True |
| data12 | 003add80 | 80435b40 | 00006b60 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803ae280 length:0008e448
* R1 = 8044c6c8
* R2 = 8043db40
* R13 = 8043a6e0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0100 | 002aab20 |
| .ctors | 802b0100 | 802b0120 | 00000020 |
| .dtors | 802b0120 | 802b0140 | 00000020 |
| .rodata | 802b0140 | 802ba420 | 0000a2e0 |
| .data | 802ba420 | 803ae280 | 000f3e60 |
| .bss | 803ae280 | 804326e0 | 00084460 |
| .sdata | 804326e0 | 804351e0 | 00002b00 |
| .sbss | 804351e0 | 80435b40 | 00000960 |
| .sdata2 | 80435b40 | 8043c6a0 | 00006b60 |
| .sbss2 | 8043c6a0 | 8043c6c8 | 00000028 |
| stack | 8043c6c8 | 8044c6c8 | 00010000 |
| empty | 8044c6c8 | 8044c6e0 | 00000018 |
| ArenaLo | 8044c6e0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00000060 |
|----------------------------------------------|
</div></div>

== Symbol map ==
The symbol map allows to put names on procedures and datas. It can be loaded in dolphin emulator in debug mode with the .map file format.

Symbol map USA: https://github.com/Virtual-World-RE/NeoGF/blob/main/data/GG4E-CSM-20220412.map

== MetroTRK ==

MetroTRK can be activated by patching the bi2.bin DebugFlag and also by patching the following addresses to start the debugger in BBA ('''B'''road'''B'''and '''A'''dapter?) mode:
* USA: Put a breakpoint at 80003190 then set r3 to 1
* EU: Put a breakpoint at 800031C0 then set r7 to 4

<div style="color: rgb(241, 196, 15);">
The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that there is debug vars in [[GCM (File format)|GCM/iso]] system files. [https://github.com/Virtual-World-RE/NeoGF/tree/main/gcmtool gcmtool.py] allow to patch them.
</div>

== SDK & libs ==
All libs and SDK are staticly linked inside the dol.

We found these libs and SDK:
* GCN SDK - Base dolphin SDK.
* Sysdolphin base library: Hal SysDolphin (HSD) Graphic and physic engine - https://github.com/doldecomp/melee/tree/master/src/sysdolphin/baselib
* MetroTRK: Target Resident Debugging Kernel for embedded systems. It's an embedded Kernel for debug.
* Metrowerks CW Runtime library: CodeWarrior: Metrowerks Standard Library and C/C++ Runtime
* And from ADXT/GC to CRI CFT/GC: It seems to be audio and video codecs.

<div class="toccolours mw-collapsible mw-collapsed">
=== H and C files ===
<div class="mw-collapsible-content">
All 3 iso contains following .h and .c symbols in the .data, .rodata, .sdata and .sdata2. The EU version contains also the symbol "objalloc.h".
aobj.h
cobj.h
jobj.h
lobj.h
object.h

GCN_Mem_Alloc.c
aobj.c
bytecode.c
class.c
cobj.c
displayfunc.c
dobj.c
dvd.c
dvdfs.c
fobj.c
fog.c
hash.c
id.c
initialize.c
jobj.c
list.c
lobj.c
memory.c
mobj.c
mtx.c
objalloc.c
perf.c
pobj.c
robj.c
tev.c
texp.c
texpdag.c
tobj.c
tpl.c
util.c
vi.c
video.c
wobj.c
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings USA ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK – OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : %s %s Apr 17 2003 12:33:06
<< Dolphin SDK – EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings EU ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library initializing default heap
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
DSPInit(): Build Date: Apr 17 2003 12:34:16
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
HSD_INIT_HEAP_MAX_NUM is obsolete since 1.3.0.0.
HSD_INIT_AUDIO_HEAP_SIZE is obsolete since 1.3.0.0.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings JAP ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

[[Category:File format]]
[[Category:Gotcha Force]]

DOL (Gotcha Force)

2023-10-07T12:59:25Z

Algoflash: /* Memory map */

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force DOL file format and ongoing researches on it. See [[DOL (File format)]] for DOL file format description.''

{{Research | 3| Research on how functions works and how the dol works is nedded. }}

== Memory map ==
The dol file is mapped in memory and the free available space remaining is next used to create the Arena containing Heaps. For instance we found Warehouse variables in the EU dol mapped in the interval [80593190:80598044[.

So patching the dol is hard because we have to find unused free space in the memory. The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that max dol mapping addresses in memory are:
* 0x80700000 // production boards
* 0x81200000 // development boards

<div style="color: rgb(241, 196, 15);">
In production we can override MetroTRK memory areas or even override apploader trailer before the bootrom/IPL area. Further investigations have to be done on the [[GCM (File format)|iso/GCM]] sys to see how debug memory is mapped in debug mode (apploader vars used in the apploader).
* Is it possible to know where exactly MetroTRK is mapped?
* Is there any other libs/datas unused in dol?
</div>

Note:
* It's perfectly possible and tested to patch the apploader trailer and raise the trailer size with [[GCM (File format)|GCM/iso]] patch. It gives us 0x100000 bytes available.

The dol entry_point call the __init_registers procedure which will set the reserved following General Purpose Registers:
* R1 (stack)
* R2 (_SDA2_BASE_) - This is the read only _SDA2_.
* R13 (_SDA_BASE_) - This is the read / write _SDA_.
'''S'''mall '''D'''ata '''A'''nchors are used with a signed short offset (-0x8000 à +0x7fff).
* -0x8000(R13) = address of .sdata followed by .sbss
* -0x8000(R2) = address of .sdata2 followed by .sbss2
* R1 = often the .sbss2 end address + 0x10000

So often only a part of available SDA negative offsets are used for R2 and R13 using -0x8000 at start.

<div class="toccolours mw-collapsible mw-collapsed">
=== USA ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab80 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad160 | 802b0160 | 00000020 | True |
| data8 | 002ad180 | 802b0180 | 00000020 | True |
| data9 | 002ad1a0 | 802b01a0 | 0000acc0 | True |
| data10 | 002b7e60 | 802bae60 | 000f42c0 | True |
| data11 | 003ac120 | 804335a0 | 00002b20 | True |
| data12 | 003aec40 | 80436a20 | 00006ae0 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803af140 length:0008e3e8
* R1 = 8044d528
* R2 = 8043ea20
* R13 = 8043b5a0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0160 | 002aab80 |
| .ctors | 802b0160 | 802b0180 | 00000020 |
| .dtors | 802b0180 | 802b01a0 | 00000020 |
| .rodata | 802b01a0 | 802bae60 | 0000acc0 |
| .data | 802bae60 | 803af120 | 000f42c0 |
| empty | 803af120 | 803af140 | 00000020 |
| .bss | 803af140 | 804335a0 | 00084460 |
| .sdata | 804335a0 | 804360c0 | 00002b20 |
| .sbss | 804360c0 | 80436a20 | 00000960 |
| .sdata2 | 80436a20 | 8043d500 | 00006ae0 |
| .sbss2 | 8043d500 | 8043d528 | 00000028 |
| stack | 8043d528 | 8044d528 | 00010000 |
| empty | 8044d528 | 8044d540 | 00000018 |
| ArenaLo | 8044d540 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00500000 |
|----------------------------------------------|
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== EU ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002ac800 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002aede0 | 802b1de0 | 00000020 | True |
| data8 | 002aee00 | 802b1e00 | 00000020 | True |
| data9 | 002aee20 | 802b1e20 | 0000f060 | True |
| data10 | 002bde80 | 802c0e80 | 000f5d40 | True |
| data11 | 003b3bc0 | 8043cbe0 | 00002b20 | True |
| data12 | 003b66e0 | 80440080 | 00006d20 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803b6bc0 length:00090208
* R1 = 80456dc8
* R2 = 80448080
* R13 = 80444be0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b1de0 | 002ac800 |
| .ctors | 802b1de0 | 802b1e00 | 00000020 |
| .dtors | 802b1e00 | 802b1e20 | 00000020 |
| .rodata | 802b1e20 | 802c0e80 | 0000f060 |
| .data | 802c0e80 | 803b6bc0 | 000f5d40 |
| .bss | 803b6bc0 | 8043cbe0 | 00086020 |
| .sdata | 8043cbe0 | 8043f700 | 00002b20 |
| .sbss | 8043f700 | 80440080 | 00000980 |
| .sdata2 | 80440080 | 80446da0 | 00006d20 |
| .sbss2 | 80446da0 | 80446dc8 | 00000028 |
| stack | 80446dc8 | 80456dc8 | 00010000 |
| empty | 80456dc8 | 80456de0 | 00000018 |
| ArenaLo | 80456de0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fff40 | |
| FST | 817fff40 | 81800000 | 000000C0 |
|----------------------------------------------|
80593A00 -> 80598040 Wharehouse
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== JAP ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab20 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad100 | 802b0100 | 00000020 | True |
| data8 | 002ad120 | 802b0120 | 00000020 | True |
| data9 | 002ad140 | 802b0140 | 0000a2e0 | True |
| data10 | 002b7420 | 802ba420 | 000f3e60 | True |
| data11 | 003ab280 | 804326e0 | 00002b00 | True |
| data12 | 003add80 | 80435b40 | 00006b60 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803ae280 length:0008e448
* R1 = 8044c6c8
* R2 = 8043db40
* R13 = 8043a6e0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0100 | 002aab20 |
| .ctors | 802b0100 | 802b0120 | 00000020 |
| .dtors | 802b0120 | 802b0140 | 00000020 |
| .rodata | 802b0140 | 802ba420 | 0000a2e0 |
| .data | 802ba420 | 803ae280 | 000f3e60 |
| .bss | 803ae280 | 804326e0 | 00084460 |
| .sdata | 804326e0 | 804351e0 | 00002b00 |
| .sbss | 804351e0 | 80435b40 | 00000960 |
| .sdata2 | 80435b40 | 8043c6a0 | 00006b60 |
| .sbss2 | 8043c6a0 | 8043c6c8 | 00000028 |
| stack | 8043c6c8 | 8044c6c8 | 00010000 |
| empty | 8044c6c8 | 8044c6e0 | 00000018 |
| ArenaLo | 8044c6e0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00000060 |
|----------------------------------------------|
</div></div>

== Symbol map ==
The symbol map allows to put names on procedures and datas. It can be loaded in dolphin emulator in debug mode with the .map file format.

Symbol map USA: https://github.com/Virtual-World-RE/NeoGF/blob/main/data/GG4E-CSM-20220412.map

== MetroTRK ==

MetroTRK can be activated by patching the bi2.bin DebugFlag and also by patching the following addresses to start the debugger in BBA ('''B'''road'''B'''and '''A'''dapter?) mode:
* USA: Put a breakpoint at 80003190 then set r3 to 1
* EU: Put a breakpoint at 800031C0 then set r7 to 4

<div style="color: rgb(241, 196, 15);">
The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that there is debug vars in [[GCM (File format)|GCM/iso]] system files. [https://github.com/Virtual-World-RE/NeoGF/tree/main/gcmtool gcmtool.py] allow to patch them.
</div>

== SDK & libs ==
All libs and SDK are staticly linked inside the dol.

We found these libs and SDK:
* GCN SDK - Base dolphin SDK.
* Sysdolphin base library: Hal SysDolphin (HSD) Graphic and physic engine - https://github.com/doldecomp/melee/tree/master/src/sysdolphin/baselib
* MetroTRK: Target Resident Debugging Kernel for embedded systems. It's an embedded Kernel for debug.
* Metrowerks CW Runtime library: CodeWarrior: Metrowerks Standard Library and C/C++ Runtime
* And from ADXT/GC to CRI CFT/GC: It seems to be audio and video codecs.

<div class="toccolours mw-collapsible mw-collapsed">
=== H and C files ===
<div class="mw-collapsible-content">
All 3 iso contains following .h and .c symbols in the .data, .rodata, .sdata and .sdata2. The EU version contains also the symbol "objalloc.h".
aobj.h
cobj.h
jobj.h
lobj.h
object.h

GCN_Mem_Alloc.c
aobj.c
bytecode.c
class.c
cobj.c
displayfunc.c
dobj.c
dvd.c
dvdfs.c
fobj.c
fog.c
hash.c
id.c
initialize.c
jobj.c
list.c
lobj.c
memory.c
mobj.c
mtx.c
objalloc.c
perf.c
pobj.c
robj.c
tev.c
texp.c
texpdag.c
tobj.c
tpl.c
util.c
vi.c
video.c
wobj.c
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings USA ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK – OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : %s %s Apr 17 2003 12:33:06
<< Dolphin SDK – EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings EU ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library initializing default heap
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
DSPInit(): Build Date: Apr 17 2003 12:34:16
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
HSD_INIT_HEAP_MAX_NUM is obsolete since 1.3.0.0.
HSD_INIT_AUDIO_HEAP_SIZE is obsolete since 1.3.0.0.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings JAP ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

[[Category:File format]]
[[Category:Gotcha Force]]

DOL (Gotcha Force)

2023-10-07T12:58:40Z

Algoflash: /* Memory map */

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force DOL file format and ongoing researches on it. See [[DOL (File format)]] for DOL file format description.''

{{Research | 3| Research on how functions works and how the dol works is nedded. }}

== Memory map ==
The dol file is mapped in memory and the free available space remaining is next used to create the Arena containing Heaps. For instance we found Warehouse variables in the EU dol mapped in the interval [80593190:80598044[.

So patching the dol is hard because we have to find unused free space in the memory. The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that max dol mapping addresses in memory are:
* 0x80700000 // production boards
* 0x81200000 // development boards

<div style="color: rgb(241, 196, 15);">
In production we can override MetroTRK memory areas or even override apploader trailer before the bootrom/IPL area. Further investigations have to be done on the [[GCM (File format)|iso/GCM]] sys to see how debug memory is mapped in debug mode (apploader vars used in the apploader).
* Is it possible to know where exactly MetroTRK is mapped?
* Is there any other libs/datas unused in dol?
</div>

Note:
* It's perfectly possible and tested to patch the apploader trailer and raise the trailer size with [[GCM (File format)|GCM/iso]] patch. It gives us 0x100000 bytes available.

The dol entry_point call the __init_registers procedure which will set the reserved following General Purpose Registers:
* R1 (stack)
* R2 (_SDA2_BASE_) - This is the read only _SDA2_.
* R13 (_SDA_BASE_) - This is the read / write _SDA_.
'''S'''mall '''D'''ata '''A'''nchors are used with a signed short offset (-0x8000 à +0x7fff).
* -0x8000(R13) = address of .sdata followed by .sbss
* -0x8000(R2) = address of .sdata2 followed by .sbss2
* R1 = often the .sbss2 end address + 0x10000

So often only a part of available SDA negative offsets are used for R2 and R13 using -0x8000 as start.

<div class="toccolours mw-collapsible mw-collapsed">
=== USA ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab80 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad160 | 802b0160 | 00000020 | True |
| data8 | 002ad180 | 802b0180 | 00000020 | True |
| data9 | 002ad1a0 | 802b01a0 | 0000acc0 | True |
| data10 | 002b7e60 | 802bae60 | 000f42c0 | True |
| data11 | 003ac120 | 804335a0 | 00002b20 | True |
| data12 | 003aec40 | 80436a20 | 00006ae0 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803af140 length:0008e3e8
* R1 = 8044d528
* R2 = 8043ea20
* R13 = 8043b5a0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0160 | 002aab80 |
| .ctors | 802b0160 | 802b0180 | 00000020 |
| .dtors | 802b0180 | 802b01a0 | 00000020 |
| .rodata | 802b01a0 | 802bae60 | 0000acc0 |
| .data | 802bae60 | 803af120 | 000f42c0 |
| empty | 803af120 | 803af140 | 00000020 |
| .bss | 803af140 | 804335a0 | 00084460 |
| .sdata | 804335a0 | 804360c0 | 00002b20 |
| .sbss | 804360c0 | 80436a20 | 00000960 |
| .sdata2 | 80436a20 | 8043d500 | 00006ae0 |
| .sbss2 | 8043d500 | 8043d528 | 00000028 |
| stack | 8043d528 | 8044d528 | 00010000 |
| empty | 8044d528 | 8044d540 | 00000018 |
| ArenaLo | 8044d540 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00500000 |
|----------------------------------------------|
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== EU ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002ac800 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002aede0 | 802b1de0 | 00000020 | True |
| data8 | 002aee00 | 802b1e00 | 00000020 | True |
| data9 | 002aee20 | 802b1e20 | 0000f060 | True |
| data10 | 002bde80 | 802c0e80 | 000f5d40 | True |
| data11 | 003b3bc0 | 8043cbe0 | 00002b20 | True |
| data12 | 003b66e0 | 80440080 | 00006d20 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803b6bc0 length:00090208
* R1 = 80456dc8
* R2 = 80448080
* R13 = 80444be0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b1de0 | 002ac800 |
| .ctors | 802b1de0 | 802b1e00 | 00000020 |
| .dtors | 802b1e00 | 802b1e20 | 00000020 |
| .rodata | 802b1e20 | 802c0e80 | 0000f060 |
| .data | 802c0e80 | 803b6bc0 | 000f5d40 |
| .bss | 803b6bc0 | 8043cbe0 | 00086020 |
| .sdata | 8043cbe0 | 8043f700 | 00002b20 |
| .sbss | 8043f700 | 80440080 | 00000980 |
| .sdata2 | 80440080 | 80446da0 | 00006d20 |
| .sbss2 | 80446da0 | 80446dc8 | 00000028 |
| stack | 80446dc8 | 80456dc8 | 00010000 |
| empty | 80456dc8 | 80456de0 | 00000018 |
| ArenaLo | 80456de0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fff40 | |
| FST | 817fff40 | 81800000 | 000000C0 |
|----------------------------------------------|
80593A00 -> 80598040 Wharehouse
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== JAP ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab20 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad100 | 802b0100 | 00000020 | True |
| data8 | 002ad120 | 802b0120 | 00000020 | True |
| data9 | 002ad140 | 802b0140 | 0000a2e0 | True |
| data10 | 002b7420 | 802ba420 | 000f3e60 | True |
| data11 | 003ab280 | 804326e0 | 00002b00 | True |
| data12 | 003add80 | 80435b40 | 00006b60 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803ae280 length:0008e448
* R1 = 8044c6c8
* R2 = 8043db40
* R13 = 8043a6e0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0100 | 002aab20 |
| .ctors | 802b0100 | 802b0120 | 00000020 |
| .dtors | 802b0120 | 802b0140 | 00000020 |
| .rodata | 802b0140 | 802ba420 | 0000a2e0 |
| .data | 802ba420 | 803ae280 | 000f3e60 |
| .bss | 803ae280 | 804326e0 | 00084460 |
| .sdata | 804326e0 | 804351e0 | 00002b00 |
| .sbss | 804351e0 | 80435b40 | 00000960 |
| .sdata2 | 80435b40 | 8043c6a0 | 00006b60 |
| .sbss2 | 8043c6a0 | 8043c6c8 | 00000028 |
| stack | 8043c6c8 | 8044c6c8 | 00010000 |
| empty | 8044c6c8 | 8044c6e0 | 00000018 |
| ArenaLo | 8044c6e0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00000060 |
|----------------------------------------------|
</div></div>

== Symbol map ==
The symbol map allows to put names on procedures and datas. It can be loaded in dolphin emulator in debug mode with the .map file format.

Symbol map USA: https://github.com/Virtual-World-RE/NeoGF/blob/main/data/GG4E-CSM-20220412.map

== MetroTRK ==

MetroTRK can be activated by patching the bi2.bin DebugFlag and also by patching the following addresses to start the debugger in BBA ('''B'''road'''B'''and '''A'''dapter?) mode:
* USA: Put a breakpoint at 80003190 then set r3 to 1
* EU: Put a breakpoint at 800031C0 then set r7 to 4

<div style="color: rgb(241, 196, 15);">
The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that there is debug vars in [[GCM (File format)|GCM/iso]] system files. [https://github.com/Virtual-World-RE/NeoGF/tree/main/gcmtool gcmtool.py] allow to patch them.
</div>

== SDK & libs ==
All libs and SDK are staticly linked inside the dol.

We found these libs and SDK:
* GCN SDK - Base dolphin SDK.
* Sysdolphin base library: Hal SysDolphin (HSD) Graphic and physic engine - https://github.com/doldecomp/melee/tree/master/src/sysdolphin/baselib
* MetroTRK: Target Resident Debugging Kernel for embedded systems. It's an embedded Kernel for debug.
* Metrowerks CW Runtime library: CodeWarrior: Metrowerks Standard Library and C/C++ Runtime
* And from ADXT/GC to CRI CFT/GC: It seems to be audio and video codecs.

<div class="toccolours mw-collapsible mw-collapsed">
=== H and C files ===
<div class="mw-collapsible-content">
All 3 iso contains following .h and .c symbols in the .data, .rodata, .sdata and .sdata2. The EU version contains also the symbol "objalloc.h".
aobj.h
cobj.h
jobj.h
lobj.h
object.h

GCN_Mem_Alloc.c
aobj.c
bytecode.c
class.c
cobj.c
displayfunc.c
dobj.c
dvd.c
dvdfs.c
fobj.c
fog.c
hash.c
id.c
initialize.c
jobj.c
list.c
lobj.c
memory.c
mobj.c
mtx.c
objalloc.c
perf.c
pobj.c
robj.c
tev.c
texp.c
texpdag.c
tobj.c
tpl.c
util.c
vi.c
video.c
wobj.c
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings USA ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK – OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : %s %s Apr 17 2003 12:33:06
<< Dolphin SDK – EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings EU ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library initializing default heap
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
DSPInit(): Build Date: Apr 17 2003 12:34:16
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
HSD_INIT_HEAP_MAX_NUM is obsolete since 1.3.0.0.
HSD_INIT_AUDIO_HEAP_SIZE is obsolete since 1.3.0.0.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings JAP ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

[[Category:File format]]
[[Category:Gotcha Force]]

DOL (Gotcha Force)

2023-10-07T12:57:33Z

Algoflash: /* Memory map */

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force DOL file format and ongoing researches on it. See [[DOL (File format)]] for DOL file format description.''

{{Research | 3| Research on how functions works and how the dol works is nedded. }}

== Memory map ==
The dol file is mapped in memory and the free available space remaining is next used to create the Arena containing Heaps. For instance we found Warehouse variables in the EU dol mapped in the interval [80593190:80598044[.

So patching the dol is hard because we have to find unused free space in the memory. The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that max dol mapping addresses in memory are:
* 0x80700000 // production boards
* 0x81200000 // development boards

<div style="color: rgb(241, 196, 15);">
In production we can override MetroTRK memory areas or even override apploader trailer before the bootrom/IPL area. Further investigations have to be done on the [[GCM (File format)|iso/GCM]] sys to see how debug memory is mapped in debug mode (apploader vars used in the apploader).
* Is it possible to know where exactly MetroTRK is mapped?
* Is there any other libs/datas unused in dol?
</div>

Note:
* It's perfectly possible and tested to patch the apploader trailer and raise the trailer size with [[GCM (File format)|GCM/iso]] patch. It give us 0x100000 bytes available.

The dol entry_point call the __init_registers procedure which will set the reserved following General Purpose Registers:
* R1 (stack)
* R2 (_SDA2_BASE_) - This is the read only _SDA2_.
* R13 (_SDA_BASE_) - This is the read / write _SDA_.
'''S'''mall '''D'''ata '''A'''nchors are used with a signed short offset (-0x8000 à +0x7fff).
* -0x8000(R13) = address of .sdata followed by .sbss
* -0x8000(R2) = address of .sdata2 followed by .sbss2
* R1 = often the .sbss2 end address + 0x10000

So often only a part of available SDA negative offsets are used for R2 and R13 using -0x8000 as start.

<div class="toccolours mw-collapsible mw-collapsed">
=== USA ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab80 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad160 | 802b0160 | 00000020 | True |
| data8 | 002ad180 | 802b0180 | 00000020 | True |
| data9 | 002ad1a0 | 802b01a0 | 0000acc0 | True |
| data10 | 002b7e60 | 802bae60 | 000f42c0 | True |
| data11 | 003ac120 | 804335a0 | 00002b20 | True |
| data12 | 003aec40 | 80436a20 | 00006ae0 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803af140 length:0008e3e8
* R1 = 8044d528
* R2 = 8043ea20
* R13 = 8043b5a0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0160 | 002aab80 |
| .ctors | 802b0160 | 802b0180 | 00000020 |
| .dtors | 802b0180 | 802b01a0 | 00000020 |
| .rodata | 802b01a0 | 802bae60 | 0000acc0 |
| .data | 802bae60 | 803af120 | 000f42c0 |
| empty | 803af120 | 803af140 | 00000020 |
| .bss | 803af140 | 804335a0 | 00084460 |
| .sdata | 804335a0 | 804360c0 | 00002b20 |
| .sbss | 804360c0 | 80436a20 | 00000960 |
| .sdata2 | 80436a20 | 8043d500 | 00006ae0 |
| .sbss2 | 8043d500 | 8043d528 | 00000028 |
| stack | 8043d528 | 8044d528 | 00010000 |
| empty | 8044d528 | 8044d540 | 00000018 |
| ArenaLo | 8044d540 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00500000 |
|----------------------------------------------|
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== EU ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002ac800 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002aede0 | 802b1de0 | 00000020 | True |
| data8 | 002aee00 | 802b1e00 | 00000020 | True |
| data9 | 002aee20 | 802b1e20 | 0000f060 | True |
| data10 | 002bde80 | 802c0e80 | 000f5d40 | True |
| data11 | 003b3bc0 | 8043cbe0 | 00002b20 | True |
| data12 | 003b66e0 | 80440080 | 00006d20 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803b6bc0 length:00090208
* R1 = 80456dc8
* R2 = 80448080
* R13 = 80444be0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b1de0 | 002ac800 |
| .ctors | 802b1de0 | 802b1e00 | 00000020 |
| .dtors | 802b1e00 | 802b1e20 | 00000020 |
| .rodata | 802b1e20 | 802c0e80 | 0000f060 |
| .data | 802c0e80 | 803b6bc0 | 000f5d40 |
| .bss | 803b6bc0 | 8043cbe0 | 00086020 |
| .sdata | 8043cbe0 | 8043f700 | 00002b20 |
| .sbss | 8043f700 | 80440080 | 00000980 |
| .sdata2 | 80440080 | 80446da0 | 00006d20 |
| .sbss2 | 80446da0 | 80446dc8 | 00000028 |
| stack | 80446dc8 | 80456dc8 | 00010000 |
| empty | 80456dc8 | 80456de0 | 00000018 |
| ArenaLo | 80456de0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fff40 | |
| FST | 817fff40 | 81800000 | 000000C0 |
|----------------------------------------------|
80593A00 -> 80598040 Wharehouse
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== JAP ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab20 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad100 | 802b0100 | 00000020 | True |
| data8 | 002ad120 | 802b0120 | 00000020 | True |
| data9 | 002ad140 | 802b0140 | 0000a2e0 | True |
| data10 | 002b7420 | 802ba420 | 000f3e60 | True |
| data11 | 003ab280 | 804326e0 | 00002b00 | True |
| data12 | 003add80 | 80435b40 | 00006b60 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803ae280 length:0008e448
* R1 = 8044c6c8
* R2 = 8043db40
* R13 = 8043a6e0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0100 | 002aab20 |
| .ctors | 802b0100 | 802b0120 | 00000020 |
| .dtors | 802b0120 | 802b0140 | 00000020 |
| .rodata | 802b0140 | 802ba420 | 0000a2e0 |
| .data | 802ba420 | 803ae280 | 000f3e60 |
| .bss | 803ae280 | 804326e0 | 00084460 |
| .sdata | 804326e0 | 804351e0 | 00002b00 |
| .sbss | 804351e0 | 80435b40 | 00000960 |
| .sdata2 | 80435b40 | 8043c6a0 | 00006b60 |
| .sbss2 | 8043c6a0 | 8043c6c8 | 00000028 |
| stack | 8043c6c8 | 8044c6c8 | 00010000 |
| empty | 8044c6c8 | 8044c6e0 | 00000018 |
| ArenaLo | 8044c6e0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00000060 |
|----------------------------------------------|
</div></div>

== Symbol map ==
The symbol map allows to put names on procedures and datas. It can be loaded in dolphin emulator in debug mode with the .map file format.

Symbol map USA: https://github.com/Virtual-World-RE/NeoGF/blob/main/data/GG4E-CSM-20220412.map

== MetroTRK ==

MetroTRK can be activated by patching the bi2.bin DebugFlag and also by patching the following addresses to start the debugger in BBA ('''B'''road'''B'''and '''A'''dapter?) mode:
* USA: Put a breakpoint at 80003190 then set r3 to 1
* EU: Put a breakpoint at 800031C0 then set r7 to 4

<div style="color: rgb(241, 196, 15);">
The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that there is debug vars in [[GCM (File format)|GCM/iso]] system files. [https://github.com/Virtual-World-RE/NeoGF/tree/main/gcmtool gcmtool.py] allow to patch them.
</div>

== SDK & libs ==
All libs and SDK are staticly linked inside the dol.

We found these libs and SDK:
* GCN SDK - Base dolphin SDK.
* Sysdolphin base library: Hal SysDolphin (HSD) Graphic and physic engine - https://github.com/doldecomp/melee/tree/master/src/sysdolphin/baselib
* MetroTRK: Target Resident Debugging Kernel for embedded systems. It's an embedded Kernel for debug.
* Metrowerks CW Runtime library: CodeWarrior: Metrowerks Standard Library and C/C++ Runtime
* And from ADXT/GC to CRI CFT/GC: It seems to be audio and video codecs.

<div class="toccolours mw-collapsible mw-collapsed">
=== H and C files ===
<div class="mw-collapsible-content">
All 3 iso contains following .h and .c symbols in the .data, .rodata, .sdata and .sdata2. The EU version contains also the symbol "objalloc.h".
aobj.h
cobj.h
jobj.h
lobj.h
object.h

GCN_Mem_Alloc.c
aobj.c
bytecode.c
class.c
cobj.c
displayfunc.c
dobj.c
dvd.c
dvdfs.c
fobj.c
fog.c
hash.c
id.c
initialize.c
jobj.c
list.c
lobj.c
memory.c
mobj.c
mtx.c
objalloc.c
perf.c
pobj.c
robj.c
tev.c
texp.c
texpdag.c
tobj.c
tpl.c
util.c
vi.c
video.c
wobj.c
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings USA ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK – OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : %s %s Apr 17 2003 12:33:06
<< Dolphin SDK – EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings EU ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library initializing default heap
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
DSPInit(): Build Date: Apr 17 2003 12:34:16
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
HSD_INIT_HEAP_MAX_NUM is obsolete since 1.3.0.0.
HSD_INIT_AUDIO_HEAP_SIZE is obsolete since 1.3.0.0.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings JAP ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

[[Category:File format]]
[[Category:Gotcha Force]]

DOL (Gotcha Force)

2023-10-07T12:56:56Z

Algoflash: /* Memory map */

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force DOL file format and ongoing researches on it. See [[DOL (File format)]] for DOL file format description.''

{{Research | 3| Research on how functions works and how the dol works is nedded. }}

== Memory map ==
The dol file is mapped in memory and the free available space remaining is next used to create the Arena containing Heaps. For instance we found Warehouse variables in the EU dol mapped in the interval [80593190:80598044[.

So patching the dol is hard because we have to find unused free space in the memory. The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that max dol mapping addresses in memory are:
* 0x80700000 // production boards
* 0x81200000 // development boards

<div style="color: rgb(241, 196, 15);">
In production we can override MetroTRK memory areas or even override apploader trailer before the bootrom/IPL area. Further investigations has to be done on the [[GCM (File format)|iso/GCM]] sys to see how debug memory is mapped in debug mode (apploader vars used in the apploader).
* Is it possible to know where exactly MetroTRK is mapped?
* Is there any other libs/datas unused in dol?
</div>

Note:
* It's perfectly possible and tested to patch the apploader trailer and raise the trailer size with [[GCM (File format)|GCM/iso]] patch. It give us 0x100000 bytes available.

The dol entry_point call the __init_registers procedure which will set the reserved following General Purpose Registers:
* R1 (stack)
* R2 (_SDA2_BASE_) - This is the read only _SDA2_.
* R13 (_SDA_BASE_) - This is the read / write _SDA_.
'''S'''mall '''D'''ata '''A'''nchors are used with a signed short offset (-0x8000 à +0x7fff).
* -0x8000(R13) = address of .sdata followed by .sbss
* -0x8000(R2) = address of .sdata2 followed by .sbss2
* R1 = often the .sbss2 end address + 0x10000

So often only a part of available SDA negative offsets are used for R2 and R13 using -0x8000 as start.

<div class="toccolours mw-collapsible mw-collapsed">
=== USA ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab80 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad160 | 802b0160 | 00000020 | True |
| data8 | 002ad180 | 802b0180 | 00000020 | True |
| data9 | 002ad1a0 | 802b01a0 | 0000acc0 | True |
| data10 | 002b7e60 | 802bae60 | 000f42c0 | True |
| data11 | 003ac120 | 804335a0 | 00002b20 | True |
| data12 | 003aec40 | 80436a20 | 00006ae0 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803af140 length:0008e3e8
* R1 = 8044d528
* R2 = 8043ea20
* R13 = 8043b5a0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0160 | 002aab80 |
| .ctors | 802b0160 | 802b0180 | 00000020 |
| .dtors | 802b0180 | 802b01a0 | 00000020 |
| .rodata | 802b01a0 | 802bae60 | 0000acc0 |
| .data | 802bae60 | 803af120 | 000f42c0 |
| empty | 803af120 | 803af140 | 00000020 |
| .bss | 803af140 | 804335a0 | 00084460 |
| .sdata | 804335a0 | 804360c0 | 00002b20 |
| .sbss | 804360c0 | 80436a20 | 00000960 |
| .sdata2 | 80436a20 | 8043d500 | 00006ae0 |
| .sbss2 | 8043d500 | 8043d528 | 00000028 |
| stack | 8043d528 | 8044d528 | 00010000 |
| empty | 8044d528 | 8044d540 | 00000018 |
| ArenaLo | 8044d540 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00500000 |
|----------------------------------------------|
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== EU ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002ac800 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002aede0 | 802b1de0 | 00000020 | True |
| data8 | 002aee00 | 802b1e00 | 00000020 | True |
| data9 | 002aee20 | 802b1e20 | 0000f060 | True |
| data10 | 002bde80 | 802c0e80 | 000f5d40 | True |
| data11 | 003b3bc0 | 8043cbe0 | 00002b20 | True |
| data12 | 003b66e0 | 80440080 | 00006d20 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803b6bc0 length:00090208
* R1 = 80456dc8
* R2 = 80448080
* R13 = 80444be0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b1de0 | 002ac800 |
| .ctors | 802b1de0 | 802b1e00 | 00000020 |
| .dtors | 802b1e00 | 802b1e20 | 00000020 |
| .rodata | 802b1e20 | 802c0e80 | 0000f060 |
| .data | 802c0e80 | 803b6bc0 | 000f5d40 |
| .bss | 803b6bc0 | 8043cbe0 | 00086020 |
| .sdata | 8043cbe0 | 8043f700 | 00002b20 |
| .sbss | 8043f700 | 80440080 | 00000980 |
| .sdata2 | 80440080 | 80446da0 | 00006d20 |
| .sbss2 | 80446da0 | 80446dc8 | 00000028 |
| stack | 80446dc8 | 80456dc8 | 00010000 |
| empty | 80456dc8 | 80456de0 | 00000018 |
| ArenaLo | 80456de0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fff40 | |
| FST | 817fff40 | 81800000 | 000000C0 |
|----------------------------------------------|
80593A00 -> 80598040 Wharehouse
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== JAP ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab20 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad100 | 802b0100 | 00000020 | True |
| data8 | 002ad120 | 802b0120 | 00000020 | True |
| data9 | 002ad140 | 802b0140 | 0000a2e0 | True |
| data10 | 002b7420 | 802ba420 | 000f3e60 | True |
| data11 | 003ab280 | 804326e0 | 00002b00 | True |
| data12 | 003add80 | 80435b40 | 00006b60 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803ae280 length:0008e448
* R1 = 8044c6c8
* R2 = 8043db40
* R13 = 8043a6e0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0100 | 002aab20 |
| .ctors | 802b0100 | 802b0120 | 00000020 |
| .dtors | 802b0120 | 802b0140 | 00000020 |
| .rodata | 802b0140 | 802ba420 | 0000a2e0 |
| .data | 802ba420 | 803ae280 | 000f3e60 |
| .bss | 803ae280 | 804326e0 | 00084460 |
| .sdata | 804326e0 | 804351e0 | 00002b00 |
| .sbss | 804351e0 | 80435b40 | 00000960 |
| .sdata2 | 80435b40 | 8043c6a0 | 00006b60 |
| .sbss2 | 8043c6a0 | 8043c6c8 | 00000028 |
| stack | 8043c6c8 | 8044c6c8 | 00010000 |
| empty | 8044c6c8 | 8044c6e0 | 00000018 |
| ArenaLo | 8044c6e0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00000060 |
|----------------------------------------------|
</div></div>

== Symbol map ==
The symbol map allows to put names on procedures and datas. It can be loaded in dolphin emulator in debug mode with the .map file format.

Symbol map USA: https://github.com/Virtual-World-RE/NeoGF/blob/main/data/GG4E-CSM-20220412.map

== MetroTRK ==

MetroTRK can be activated by patching the bi2.bin DebugFlag and also by patching the following addresses to start the debugger in BBA ('''B'''road'''B'''and '''A'''dapter?) mode:
* USA: Put a breakpoint at 80003190 then set r3 to 1
* EU: Put a breakpoint at 800031C0 then set r7 to 4

<div style="color: rgb(241, 196, 15);">
The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that there is debug vars in [[GCM (File format)|GCM/iso]] system files. [https://github.com/Virtual-World-RE/NeoGF/tree/main/gcmtool gcmtool.py] allow to patch them.
</div>

== SDK & libs ==
All libs and SDK are staticly linked inside the dol.

We found these libs and SDK:
* GCN SDK - Base dolphin SDK.
* Sysdolphin base library: Hal SysDolphin (HSD) Graphic and physic engine - https://github.com/doldecomp/melee/tree/master/src/sysdolphin/baselib
* MetroTRK: Target Resident Debugging Kernel for embedded systems. It's an embedded Kernel for debug.
* Metrowerks CW Runtime library: CodeWarrior: Metrowerks Standard Library and C/C++ Runtime
* And from ADXT/GC to CRI CFT/GC: It seems to be audio and video codecs.

<div class="toccolours mw-collapsible mw-collapsed">
=== H and C files ===
<div class="mw-collapsible-content">
All 3 iso contains following .h and .c symbols in the .data, .rodata, .sdata and .sdata2. The EU version contains also the symbol "objalloc.h".
aobj.h
cobj.h
jobj.h
lobj.h
object.h

GCN_Mem_Alloc.c
aobj.c
bytecode.c
class.c
cobj.c
displayfunc.c
dobj.c
dvd.c
dvdfs.c
fobj.c
fog.c
hash.c
id.c
initialize.c
jobj.c
list.c
lobj.c
memory.c
mobj.c
mtx.c
objalloc.c
perf.c
pobj.c
robj.c
tev.c
texp.c
texpdag.c
tobj.c
tpl.c
util.c
vi.c
video.c
wobj.c
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings USA ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK – OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : %s %s Apr 17 2003 12:33:06
<< Dolphin SDK – EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings EU ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library initializing default heap
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
DSPInit(): Build Date: Apr 17 2003 12:34:16
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
HSD_INIT_HEAP_MAX_NUM is obsolete since 1.3.0.0.
HSD_INIT_AUDIO_HEAP_SIZE is obsolete since 1.3.0.0.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings JAP ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

[[Category:File format]]
[[Category:Gotcha Force]]

DOL (Gotcha Force)

2023-10-07T12:56:15Z

Algoflash: /* MetroTRK */

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force DOL file format and ongoing researches on it. See [[DOL (File format)]] for DOL file format description.''

{{Research | 3| Research on how functions works and how the dol works is nedded. }}

== Memory map ==
The dol file is mapped in memory and the free available space remaining is next used to create the Arena containing Heaps. For instance we found Warehouse variables in the EU dol mapped in the interval [80593190:80598044[.

So patching the dol is hard because we have to find unused free space in the memory. The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that max dol mapping address in memory are:
* 0x80700000 // production boards
* 0x81200000 // development boards

<div style="color: rgb(241, 196, 15);">
In production we can override MetroTRK memory areas or even override apploader trailer before the bootrom/IPL area. Further investigations has to be done on the [[GCM (File format)|iso/GCM]] sys to see how debug memory is mapped in debug mode (apploader vars used in the apploader).
* Is it possible to know where exactly MetroTRK is mapped?
* Is there any other libs/datas unused in dol?
</div>

Note:
* It's perfectly possible and tested to patch the apploader trailer and raise the trailer size with [[GCM (File format)|GCM/iso]] patch. It give us 0x100000 bytes available.

The dol entry_point call the __init_registers procedure which will set the reserved following General Purpose Registers:
* R1 (stack)
* R2 (_SDA2_BASE_) - This is the read only _SDA2_.
* R13 (_SDA_BASE_) - This is the read / write _SDA_.
'''S'''mall '''D'''ata '''A'''nchors are used with a signed short offset (-0x8000 à +0x7fff).
* -0x8000(R13) = address of .sdata followed by .sbss
* -0x8000(R2) = address of .sdata2 followed by .sbss2
* R1 = often the .sbss2 end address + 0x10000

So often only a part of available SDA negative offsets are used for R2 and R13 using -0x8000 as start.

<div class="toccolours mw-collapsible mw-collapsed">
=== USA ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab80 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad160 | 802b0160 | 00000020 | True |
| data8 | 002ad180 | 802b0180 | 00000020 | True |
| data9 | 002ad1a0 | 802b01a0 | 0000acc0 | True |
| data10 | 002b7e60 | 802bae60 | 000f42c0 | True |
| data11 | 003ac120 | 804335a0 | 00002b20 | True |
| data12 | 003aec40 | 80436a20 | 00006ae0 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803af140 length:0008e3e8
* R1 = 8044d528
* R2 = 8043ea20
* R13 = 8043b5a0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0160 | 002aab80 |
| .ctors | 802b0160 | 802b0180 | 00000020 |
| .dtors | 802b0180 | 802b01a0 | 00000020 |
| .rodata | 802b01a0 | 802bae60 | 0000acc0 |
| .data | 802bae60 | 803af120 | 000f42c0 |
| empty | 803af120 | 803af140 | 00000020 |
| .bss | 803af140 | 804335a0 | 00084460 |
| .sdata | 804335a0 | 804360c0 | 00002b20 |
| .sbss | 804360c0 | 80436a20 | 00000960 |
| .sdata2 | 80436a20 | 8043d500 | 00006ae0 |
| .sbss2 | 8043d500 | 8043d528 | 00000028 |
| stack | 8043d528 | 8044d528 | 00010000 |
| empty | 8044d528 | 8044d540 | 00000018 |
| ArenaLo | 8044d540 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00500000 |
|----------------------------------------------|
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== EU ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002ac800 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002aede0 | 802b1de0 | 00000020 | True |
| data8 | 002aee00 | 802b1e00 | 00000020 | True |
| data9 | 002aee20 | 802b1e20 | 0000f060 | True |
| data10 | 002bde80 | 802c0e80 | 000f5d40 | True |
| data11 | 003b3bc0 | 8043cbe0 | 00002b20 | True |
| data12 | 003b66e0 | 80440080 | 00006d20 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803b6bc0 length:00090208
* R1 = 80456dc8
* R2 = 80448080
* R13 = 80444be0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b1de0 | 002ac800 |
| .ctors | 802b1de0 | 802b1e00 | 00000020 |
| .dtors | 802b1e00 | 802b1e20 | 00000020 |
| .rodata | 802b1e20 | 802c0e80 | 0000f060 |
| .data | 802c0e80 | 803b6bc0 | 000f5d40 |
| .bss | 803b6bc0 | 8043cbe0 | 00086020 |
| .sdata | 8043cbe0 | 8043f700 | 00002b20 |
| .sbss | 8043f700 | 80440080 | 00000980 |
| .sdata2 | 80440080 | 80446da0 | 00006d20 |
| .sbss2 | 80446da0 | 80446dc8 | 00000028 |
| stack | 80446dc8 | 80456dc8 | 00010000 |
| empty | 80456dc8 | 80456de0 | 00000018 |
| ArenaLo | 80456de0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fff40 | |
| FST | 817fff40 | 81800000 | 000000C0 |
|----------------------------------------------|
80593A00 -> 80598040 Wharehouse
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== JAP ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab20 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad100 | 802b0100 | 00000020 | True |
| data8 | 002ad120 | 802b0120 | 00000020 | True |
| data9 | 002ad140 | 802b0140 | 0000a2e0 | True |
| data10 | 002b7420 | 802ba420 | 000f3e60 | True |
| data11 | 003ab280 | 804326e0 | 00002b00 | True |
| data12 | 003add80 | 80435b40 | 00006b60 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803ae280 length:0008e448
* R1 = 8044c6c8
* R2 = 8043db40
* R13 = 8043a6e0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0100 | 002aab20 |
| .ctors | 802b0100 | 802b0120 | 00000020 |
| .dtors | 802b0120 | 802b0140 | 00000020 |
| .rodata | 802b0140 | 802ba420 | 0000a2e0 |
| .data | 802ba420 | 803ae280 | 000f3e60 |
| .bss | 803ae280 | 804326e0 | 00084460 |
| .sdata | 804326e0 | 804351e0 | 00002b00 |
| .sbss | 804351e0 | 80435b40 | 00000960 |
| .sdata2 | 80435b40 | 8043c6a0 | 00006b60 |
| .sbss2 | 8043c6a0 | 8043c6c8 | 00000028 |
| stack | 8043c6c8 | 8044c6c8 | 00010000 |
| empty | 8044c6c8 | 8044c6e0 | 00000018 |
| ArenaLo | 8044c6e0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00000060 |
|----------------------------------------------|
</div></div>

== Symbol map ==
The symbol map allows to put names on procedures and datas. It can be loaded in dolphin emulator in debug mode with the .map file format.

Symbol map USA: https://github.com/Virtual-World-RE/NeoGF/blob/main/data/GG4E-CSM-20220412.map

== MetroTRK ==

MetroTRK can be activated by patching the bi2.bin DebugFlag and also by patching the following addresses to start the debugger in BBA ('''B'''road'''B'''and '''A'''dapter?) mode:
* USA: Put a breakpoint at 80003190 then set r3 to 1
* EU: Put a breakpoint at 800031C0 then set r7 to 4

<div style="color: rgb(241, 196, 15);">
The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that there is debug vars in [[GCM (File format)|GCM/iso]] system files. [https://github.com/Virtual-World-RE/NeoGF/tree/main/gcmtool gcmtool.py] allow to patch them.
</div>

== SDK & libs ==
All libs and SDK are staticly linked inside the dol.

We found these libs and SDK:
* GCN SDK - Base dolphin SDK.
* Sysdolphin base library: Hal SysDolphin (HSD) Graphic and physic engine - https://github.com/doldecomp/melee/tree/master/src/sysdolphin/baselib
* MetroTRK: Target Resident Debugging Kernel for embedded systems. It's an embedded Kernel for debug.
* Metrowerks CW Runtime library: CodeWarrior: Metrowerks Standard Library and C/C++ Runtime
* And from ADXT/GC to CRI CFT/GC: It seems to be audio and video codecs.

<div class="toccolours mw-collapsible mw-collapsed">
=== H and C files ===
<div class="mw-collapsible-content">
All 3 iso contains following .h and .c symbols in the .data, .rodata, .sdata and .sdata2. The EU version contains also the symbol "objalloc.h".
aobj.h
cobj.h
jobj.h
lobj.h
object.h

GCN_Mem_Alloc.c
aobj.c
bytecode.c
class.c
cobj.c
displayfunc.c
dobj.c
dvd.c
dvdfs.c
fobj.c
fog.c
hash.c
id.c
initialize.c
jobj.c
list.c
lobj.c
memory.c
mobj.c
mtx.c
objalloc.c
perf.c
pobj.c
robj.c
tev.c
texp.c
texpdag.c
tobj.c
tpl.c
util.c
vi.c
video.c
wobj.c
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings USA ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK – OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : %s %s Apr 17 2003 12:33:06
<< Dolphin SDK – EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings EU ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library initializing default heap
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
DSPInit(): Build Date: Apr 17 2003 12:34:16
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
HSD_INIT_HEAP_MAX_NUM is obsolete since 1.3.0.0.
HSD_INIT_AUDIO_HEAP_SIZE is obsolete since 1.3.0.0.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings JAP ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

[[Category:File format]]
[[Category:Gotcha Force]]

DOL (Gotcha Force)

2023-10-07T12:56:04Z

Algoflash: /* Symbol map */

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force DOL file format and ongoing researches on it. See [[DOL (File format)]] for DOL file format description.''

{{Research | 3| Research on how functions works and how the dol works is nedded. }}

== Memory map ==
The dol file is mapped in memory and the free available space remaining is next used to create the Arena containing Heaps. For instance we found Warehouse variables in the EU dol mapped in the interval [80593190:80598044[.

So patching the dol is hard because we have to find unused free space in the memory. The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that max dol mapping address in memory are:
* 0x80700000 // production boards
* 0x81200000 // development boards

<div style="color: rgb(241, 196, 15);">
In production we can override MetroTRK memory areas or even override apploader trailer before the bootrom/IPL area. Further investigations has to be done on the [[GCM (File format)|iso/GCM]] sys to see how debug memory is mapped in debug mode (apploader vars used in the apploader).
* Is it possible to know where exactly MetroTRK is mapped?
* Is there any other libs/datas unused in dol?
</div>

Note:
* It's perfectly possible and tested to patch the apploader trailer and raise the trailer size with [[GCM (File format)|GCM/iso]] patch. It give us 0x100000 bytes available.

The dol entry_point call the __init_registers procedure which will set the reserved following General Purpose Registers:
* R1 (stack)
* R2 (_SDA2_BASE_) - This is the read only _SDA2_.
* R13 (_SDA_BASE_) - This is the read / write _SDA_.
'''S'''mall '''D'''ata '''A'''nchors are used with a signed short offset (-0x8000 à +0x7fff).
* -0x8000(R13) = address of .sdata followed by .sbss
* -0x8000(R2) = address of .sdata2 followed by .sbss2
* R1 = often the .sbss2 end address + 0x10000

So often only a part of available SDA negative offsets are used for R2 and R13 using -0x8000 as start.

<div class="toccolours mw-collapsible mw-collapsed">
=== USA ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab80 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad160 | 802b0160 | 00000020 | True |
| data8 | 002ad180 | 802b0180 | 00000020 | True |
| data9 | 002ad1a0 | 802b01a0 | 0000acc0 | True |
| data10 | 002b7e60 | 802bae60 | 000f42c0 | True |
| data11 | 003ac120 | 804335a0 | 00002b20 | True |
| data12 | 003aec40 | 80436a20 | 00006ae0 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803af140 length:0008e3e8
* R1 = 8044d528
* R2 = 8043ea20
* R13 = 8043b5a0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0160 | 002aab80 |
| .ctors | 802b0160 | 802b0180 | 00000020 |
| .dtors | 802b0180 | 802b01a0 | 00000020 |
| .rodata | 802b01a0 | 802bae60 | 0000acc0 |
| .data | 802bae60 | 803af120 | 000f42c0 |
| empty | 803af120 | 803af140 | 00000020 |
| .bss | 803af140 | 804335a0 | 00084460 |
| .sdata | 804335a0 | 804360c0 | 00002b20 |
| .sbss | 804360c0 | 80436a20 | 00000960 |
| .sdata2 | 80436a20 | 8043d500 | 00006ae0 |
| .sbss2 | 8043d500 | 8043d528 | 00000028 |
| stack | 8043d528 | 8044d528 | 00010000 |
| empty | 8044d528 | 8044d540 | 00000018 |
| ArenaLo | 8044d540 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00500000 |
|----------------------------------------------|
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== EU ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002ac800 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002aede0 | 802b1de0 | 00000020 | True |
| data8 | 002aee00 | 802b1e00 | 00000020 | True |
| data9 | 002aee20 | 802b1e20 | 0000f060 | True |
| data10 | 002bde80 | 802c0e80 | 000f5d40 | True |
| data11 | 003b3bc0 | 8043cbe0 | 00002b20 | True |
| data12 | 003b66e0 | 80440080 | 00006d20 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803b6bc0 length:00090208
* R1 = 80456dc8
* R2 = 80448080
* R13 = 80444be0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b1de0 | 002ac800 |
| .ctors | 802b1de0 | 802b1e00 | 00000020 |
| .dtors | 802b1e00 | 802b1e20 | 00000020 |
| .rodata | 802b1e20 | 802c0e80 | 0000f060 |
| .data | 802c0e80 | 803b6bc0 | 000f5d40 |
| .bss | 803b6bc0 | 8043cbe0 | 00086020 |
| .sdata | 8043cbe0 | 8043f700 | 00002b20 |
| .sbss | 8043f700 | 80440080 | 00000980 |
| .sdata2 | 80440080 | 80446da0 | 00006d20 |
| .sbss2 | 80446da0 | 80446dc8 | 00000028 |
| stack | 80446dc8 | 80456dc8 | 00010000 |
| empty | 80456dc8 | 80456de0 | 00000018 |
| ArenaLo | 80456de0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fff40 | |
| FST | 817fff40 | 81800000 | 000000C0 |
|----------------------------------------------|
80593A00 -> 80598040 Wharehouse
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== JAP ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab20 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad100 | 802b0100 | 00000020 | True |
| data8 | 002ad120 | 802b0120 | 00000020 | True |
| data9 | 002ad140 | 802b0140 | 0000a2e0 | True |
| data10 | 002b7420 | 802ba420 | 000f3e60 | True |
| data11 | 003ab280 | 804326e0 | 00002b00 | True |
| data12 | 003add80 | 80435b40 | 00006b60 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803ae280 length:0008e448
* R1 = 8044c6c8
* R2 = 8043db40
* R13 = 8043a6e0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0100 | 002aab20 |
| .ctors | 802b0100 | 802b0120 | 00000020 |
| .dtors | 802b0120 | 802b0140 | 00000020 |
| .rodata | 802b0140 | 802ba420 | 0000a2e0 |
| .data | 802ba420 | 803ae280 | 000f3e60 |
| .bss | 803ae280 | 804326e0 | 00084460 |
| .sdata | 804326e0 | 804351e0 | 00002b00 |
| .sbss | 804351e0 | 80435b40 | 00000960 |
| .sdata2 | 80435b40 | 8043c6a0 | 00006b60 |
| .sbss2 | 8043c6a0 | 8043c6c8 | 00000028 |
| stack | 8043c6c8 | 8044c6c8 | 00010000 |
| empty | 8044c6c8 | 8044c6e0 | 00000018 |
| ArenaLo | 8044c6e0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00000060 |
|----------------------------------------------|
</div></div>

== Symbol map ==
The symbol map allows to put names on procedures and datas. It can be loaded in dolphin emulator in debug mode with the .map file format.

Symbol map USA: https://github.com/Virtual-World-RE/NeoGF/blob/main/data/GG4E-CSM-20220412.map

== MetroTRK ==

MetroTRK can be activated by patching the bi2.bin DebugFlag and also by patching the following addresses to start the debugger in BBA ('''B'''road'''B'''and '''A'''dapter ?) mode:
* USA: Put a breakpoint at 80003190 then set r3 to 1
* EU: Put a breakpoint at 800031C0 then set r7 to 4

<div style="color: rgb(241, 196, 15);">
The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that there is debug vars in [[GCM (File format)|GCM/iso]] system files. [https://github.com/Virtual-World-RE/NeoGF/tree/main/gcmtool gcmtool.py] allow to patch them.
</div>

== SDK & libs ==
All libs and SDK are staticly linked inside the dol.

We found these libs and SDK:
* GCN SDK - Base dolphin SDK.
* Sysdolphin base library: Hal SysDolphin (HSD) Graphic and physic engine - https://github.com/doldecomp/melee/tree/master/src/sysdolphin/baselib
* MetroTRK: Target Resident Debugging Kernel for embedded systems. It's an embedded Kernel for debug.
* Metrowerks CW Runtime library: CodeWarrior: Metrowerks Standard Library and C/C++ Runtime
* And from ADXT/GC to CRI CFT/GC: It seems to be audio and video codecs.

<div class="toccolours mw-collapsible mw-collapsed">
=== H and C files ===
<div class="mw-collapsible-content">
All 3 iso contains following .h and .c symbols in the .data, .rodata, .sdata and .sdata2. The EU version contains also the symbol "objalloc.h".
aobj.h
cobj.h
jobj.h
lobj.h
object.h

GCN_Mem_Alloc.c
aobj.c
bytecode.c
class.c
cobj.c
displayfunc.c
dobj.c
dvd.c
dvdfs.c
fobj.c
fog.c
hash.c
id.c
initialize.c
jobj.c
list.c
lobj.c
memory.c
mobj.c
mtx.c
objalloc.c
perf.c
pobj.c
robj.c
tev.c
texp.c
texpdag.c
tobj.c
tpl.c
util.c
vi.c
video.c
wobj.c
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings USA ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK – OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : %s %s Apr 17 2003 12:33:06
<< Dolphin SDK – EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings EU ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library initializing default heap
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
DSPInit(): Build Date: Apr 17 2003 12:34:16
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
HSD_INIT_HEAP_MAX_NUM is obsolete since 1.3.0.0.
HSD_INIT_AUDIO_HEAP_SIZE is obsolete since 1.3.0.0.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings JAP ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

[[Category:File format]]
[[Category:Gotcha Force]]

DOL (Gotcha Force)

2023-10-07T12:55:56Z

Algoflash: /* SDK & libs */

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force DOL file format and ongoing researches on it. See [[DOL (File format)]] for DOL file format description.''

{{Research | 3| Research on how functions works and how the dol works is nedded. }}

== Memory map ==
The dol file is mapped in memory and the free available space remaining is next used to create the Arena containing Heaps. For instance we found Warehouse variables in the EU dol mapped in the interval [80593190:80598044[.

So patching the dol is hard because we have to find unused free space in the memory. The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that max dol mapping address in memory are:
* 0x80700000 // production boards
* 0x81200000 // development boards

<div style="color: rgb(241, 196, 15);">
In production we can override MetroTRK memory areas or even override apploader trailer before the bootrom/IPL area. Further investigations has to be done on the [[GCM (File format)|iso/GCM]] sys to see how debug memory is mapped in debug mode (apploader vars used in the apploader).
* Is it possible to know where exactly MetroTRK is mapped?
* Is there any other libs/datas unused in dol?
</div>

Note:
* It's perfectly possible and tested to patch the apploader trailer and raise the trailer size with [[GCM (File format)|GCM/iso]] patch. It give us 0x100000 bytes available.

The dol entry_point call the __init_registers procedure which will set the reserved following General Purpose Registers:
* R1 (stack)
* R2 (_SDA2_BASE_) - This is the read only _SDA2_.
* R13 (_SDA_BASE_) - This is the read / write _SDA_.
'''S'''mall '''D'''ata '''A'''nchors are used with a signed short offset (-0x8000 à +0x7fff).
* -0x8000(R13) = address of .sdata followed by .sbss
* -0x8000(R2) = address of .sdata2 followed by .sbss2
* R1 = often the .sbss2 end address + 0x10000

So often only a part of available SDA negative offsets are used for R2 and R13 using -0x8000 as start.

<div class="toccolours mw-collapsible mw-collapsed">
=== USA ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab80 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad160 | 802b0160 | 00000020 | True |
| data8 | 002ad180 | 802b0180 | 00000020 | True |
| data9 | 002ad1a0 | 802b01a0 | 0000acc0 | True |
| data10 | 002b7e60 | 802bae60 | 000f42c0 | True |
| data11 | 003ac120 | 804335a0 | 00002b20 | True |
| data12 | 003aec40 | 80436a20 | 00006ae0 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803af140 length:0008e3e8
* R1 = 8044d528
* R2 = 8043ea20
* R13 = 8043b5a0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0160 | 002aab80 |
| .ctors | 802b0160 | 802b0180 | 00000020 |
| .dtors | 802b0180 | 802b01a0 | 00000020 |
| .rodata | 802b01a0 | 802bae60 | 0000acc0 |
| .data | 802bae60 | 803af120 | 000f42c0 |
| empty | 803af120 | 803af140 | 00000020 |
| .bss | 803af140 | 804335a0 | 00084460 |
| .sdata | 804335a0 | 804360c0 | 00002b20 |
| .sbss | 804360c0 | 80436a20 | 00000960 |
| .sdata2 | 80436a20 | 8043d500 | 00006ae0 |
| .sbss2 | 8043d500 | 8043d528 | 00000028 |
| stack | 8043d528 | 8044d528 | 00010000 |
| empty | 8044d528 | 8044d540 | 00000018 |
| ArenaLo | 8044d540 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00500000 |
|----------------------------------------------|
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== EU ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002ac800 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002aede0 | 802b1de0 | 00000020 | True |
| data8 | 002aee00 | 802b1e00 | 00000020 | True |
| data9 | 002aee20 | 802b1e20 | 0000f060 | True |
| data10 | 002bde80 | 802c0e80 | 000f5d40 | True |
| data11 | 003b3bc0 | 8043cbe0 | 00002b20 | True |
| data12 | 003b66e0 | 80440080 | 00006d20 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803b6bc0 length:00090208
* R1 = 80456dc8
* R2 = 80448080
* R13 = 80444be0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b1de0 | 002ac800 |
| .ctors | 802b1de0 | 802b1e00 | 00000020 |
| .dtors | 802b1e00 | 802b1e20 | 00000020 |
| .rodata | 802b1e20 | 802c0e80 | 0000f060 |
| .data | 802c0e80 | 803b6bc0 | 000f5d40 |
| .bss | 803b6bc0 | 8043cbe0 | 00086020 |
| .sdata | 8043cbe0 | 8043f700 | 00002b20 |
| .sbss | 8043f700 | 80440080 | 00000980 |
| .sdata2 | 80440080 | 80446da0 | 00006d20 |
| .sbss2 | 80446da0 | 80446dc8 | 00000028 |
| stack | 80446dc8 | 80456dc8 | 00010000 |
| empty | 80456dc8 | 80456de0 | 00000018 |
| ArenaLo | 80456de0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fff40 | |
| FST | 817fff40 | 81800000 | 000000C0 |
|----------------------------------------------|
80593A00 -> 80598040 Wharehouse
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">

=== JAP ===
Entry point: 80003154
<div class="mw-collapsible-content">
|--------------------------------------------------|
| Section | Offset | Address | Length | Used |
|---------|----------|----------|----------|-------|
| text0 | 00000100 | 80003100 | 000024e0 | True |
| text1 | 000025e0 | 800055e0 | 002aab20 | True |
| text2 | 00000000 | 00000000 | 00000000 | False |
| text3 | 00000000 | 00000000 | 00000000 | False |
| text4 | 00000000 | 00000000 | 00000000 | False |
| text5 | 00000000 | 00000000 | 00000000 | False |
| text6 | 00000000 | 00000000 | 00000000 | False |
| data7 | 002ad100 | 802b0100 | 00000020 | True |
| data8 | 002ad120 | 802b0120 | 00000020 | True |
| data9 | 002ad140 | 802b0140 | 0000a2e0 | True |
| data10 | 002b7420 | 802ba420 | 000f3e60 | True |
| data11 | 003ab280 | 804326e0 | 00002b00 | True |
| data12 | 003add80 | 80435b40 | 00006b60 | True |
| data13 | 00000000 | 00000000 | 00000000 | False |
| data14 | 00000000 | 00000000 | 00000000 | False |
| data15 | 00000000 | 00000000 | 00000000 | False |
| data16 | 00000000 | 00000000 | 00000000 | False |
| data17 | 00000000 | 00000000 | 00000000 | False |
|--------------------------------------------------|

* bss: address:803ae280 length:0008e448
* R1 = 8044c6c8
* R2 = 8043db40
* R13 = 8043a6e0

|----------------------------------------------|
| Section | beg_addr | end_addr | length |
|-------------|----------|----------|----------|
| system | 80000000 | 80003100 | 00003100 |
| .text0 | 80003100 | 800055e0 | 000024e0 |
| .text1 | 800055e0 | 802b0100 | 002aab20 |
| .ctors | 802b0100 | 802b0120 | 00000020 |
| .dtors | 802b0120 | 802b0140 | 00000020 |
| .rodata | 802b0140 | 802ba420 | 0000a2e0 |
| .data | 802ba420 | 803ae280 | 000f3e60 |
| .bss | 803ae280 | 804326e0 | 00084460 |
| .sdata | 804326e0 | 804351e0 | 00002b00 |
| .sbss | 804351e0 | 80435b40 | 00000960 |
| .sdata2 | 80435b40 | 8043c6a0 | 00006b60 |
| .sbss2 | 8043c6a0 | 8043c6c8 | 00000028 |
| stack | 8043c6c8 | 8044c6c8 | 00010000 |
| empty | 8044c6c8 | 8044c6e0 | 00000018 |
| ArenaLo | 8044c6e0 | | |
| apploader | 81200000 | ? | ? |
| Bootrom/IPL | 81300000 | ? | ? |
| ArenaHi | | 817fffa0 | |
| FST | 817fffa0 | 81800000 | 00000060 |
|----------------------------------------------|
</div></div>

== Symbol map ==
The symbol map allows to put names on procedures and datas. It can be loaded in dolphin emulator in debug mode with the .map file format.

Symbol map USA : https://github.com/Virtual-World-RE/NeoGF/blob/main/data/GG4E-CSM-20220412.map

== MetroTRK ==

MetroTRK can be activated by patching the bi2.bin DebugFlag and also by patching the following addresses to start the debugger in BBA ('''B'''road'''B'''and '''A'''dapter ?) mode:
* USA: Put a breakpoint at 80003190 then set r3 to 1
* EU: Put a breakpoint at 800031C0 then set r7 to 4

<div style="color: rgb(241, 196, 15);">
The [https://www.gc-forever.com/wiki/index.php?title=Apploader apploader reverse engineering] shows that there is debug vars in [[GCM (File format)|GCM/iso]] system files. [https://github.com/Virtual-World-RE/NeoGF/tree/main/gcmtool gcmtool.py] allow to patch them.
</div>

== SDK & libs ==
All libs and SDK are staticly linked inside the dol.

We found these libs and SDK:
* GCN SDK - Base dolphin SDK.
* Sysdolphin base library: Hal SysDolphin (HSD) Graphic and physic engine - https://github.com/doldecomp/melee/tree/master/src/sysdolphin/baselib
* MetroTRK: Target Resident Debugging Kernel for embedded systems. It's an embedded Kernel for debug.
* Metrowerks CW Runtime library: CodeWarrior: Metrowerks Standard Library and C/C++ Runtime
* And from ADXT/GC to CRI CFT/GC: It seems to be audio and video codecs.

<div class="toccolours mw-collapsible mw-collapsed">
=== H and C files ===
<div class="mw-collapsible-content">
All 3 iso contains following .h and .c symbols in the .data, .rodata, .sdata and .sdata2. The EU version contains also the symbol "objalloc.h".
aobj.h
cobj.h
jobj.h
lobj.h
object.h

GCN_Mem_Alloc.c
aobj.c
bytecode.c
class.c
cobj.c
displayfunc.c
dobj.c
dvd.c
dvdfs.c
fobj.c
fog.c
hash.c
id.c
initialize.c
jobj.c
list.c
lobj.c
memory.c
mobj.c
mtx.c
objalloc.c
perf.c
pobj.c
robj.c
tev.c
texp.c
texpdag.c
tobj.c
tpl.c
util.c
vi.c
video.c
wobj.c
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings USA ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK – OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : %s %s Apr 17 2003 12:33:06
<< Dolphin SDK – EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings EU ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
Metrowerks CW runtime library initializing default heap
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
DSPInit(): Build Date: Apr 17 2003 12:34:16
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
HSD_INIT_HEAP_MAX_NUM is obsolete since 1.3.0.0.
HSD_INIT_AUDIO_HEAP_SIZE is obsolete since 1.3.0.0.
</div></div>

<div class="toccolours mw-collapsible mw-collapsed">
=== Strings JAP ===
<div class="mw-collapsible-content">
Strings list found in the dol and allowing to find libs / SDK:
Metrowerks Target Resident Kernel for PowerPC
MetroTRK for GAMECUBE v2.0
ADXT/GC Ver.8.57 Build:Feb 6 2003 18:03:46
SKG/GC Ver.0.61 Build:Feb 6 2003 18:03:49
ADXGC Ver.1.21 Build:Feb 6 2003 18:04:00
ADXGCSDK Ver.05Sep2002 Build:Feb 6 2003 18:04:01
ADXF/GC Ver.7.01 Build:Feb 6 2003 18:02:45
CVFS/GC Ver.2.33 Build:Feb 6 2003 18:02:35
GCCI Ver.1.09 Build:Feb 6 2003 18:02:33
LSC/GC Ver.2.10 Build:Feb 6 2003 18:02:32
SJ/GC Ver.6.10 Build:Feb 6 2003 18:02:53
SVM/GC Ver.1.51 Build:Feb 6 2003 18:02:51
MFCI/GC Ver.1.04 Build:Feb 6 2003 18:03:11
AXRNA Ver.1.02 Build:Feb 6 2003 18:03:43
CRI SUD/GC Ver.0.02 Build:Feb 6 2003 14:30:18
CRI SFX/GC Ver.1.22 Build:Feb 6 2003 14:30:16
CRI DCT/GC Ver.1.803 Build:Feb 6 2003 14:28:46
Append: MW2407 GC05Sep2002Patch1
CRI MPS/GC Ver.1.669 Build:Feb 6 2003 14:28:50
CRI MPV/GC Ver.1.840 Build:Feb 6 2003 14:28:53
Append: MW2407 GC05Sep2002Patch1
CRI SFD/GC Ver.1.842 Build:Feb 6 2003 14:29:53
Append: MW2407 GC05Sep2002Patch1
CRI SFH/GC Ver.1.12 Build:Feb 6 2003 14:30:00
MWSFD/GC Ver.2.62 Build:Feb 6 2003 14:28:42
Append: MW2407 GC05Sep2002Patch1
CRI CFT/GC Ver.1.24 Build:Feb 6 2003 14:28:33
<< Dolphin SDK - OS release build: Apr 17 2003 12:33:06 (0x2301) >>
Dolphin OS Kernel built : Apr 17 2003 12:33:06
<< Dolphin SDK - EXI release build: Apr 17 2003 12:33:17 (0x2301) >>
<< Dolphin SDK - SI release build: Apr 17 2003 12:33:19 (0x2301) >>
<< Dolphin SDK - DVD release build: Apr 22 2003 15:49:00 (0x2301) >>
<< Dolphin SDK - VI release build: Apr 17 2003 12:33:22 (0x2301) >>
<< Dolphin SDK - PAD release build: Apr 17 2003 12:33:44 (0x2301) >>
<< Dolphin SDK - AI release build: Apr 17 2003 12:33:54 (0x2301) >>
<< Dolphin SDK - AR release build: Apr 17 2003 12:33:55 (0x2301) >>
<< Dolphin SDK - ARQ release build: Apr 17 2003 12:33:56 (0x2301) >>
<< Dolphin SDK - AX release build: Apr 17 2003 12:33:57 (0x2301) >>
<< Dolphin SDK - DSP release build: Apr 17 2003 12:34:16 (0x2301) >>
<< Dolphin SDK - CARD release build: Apr 17 2003 12:34:19 (0x2301) >>
<< Dolphin SDK - GX release build: Apr 21 2003 14:55:46 (0x2301) >>
sysdolphin_base_library
</div></div>

[[Category:File format]]
[[Category:Gotcha Force]]

TXG (File format)

2023-10-07T12:54:06Z

Algoflash:

[[Gotcha Force | ← Gotcha Force]]

''This article is about the TXG file format. See [[TXG (Gotcha Force)]] for current research on Gotcha Force TXG.''

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

TXG file format is an archive which contains [[TPL (File format)|TPL]]. The following class is interesting for documenting the file format:

https://github.com/Struggleton/TXG2TPL/blob/master/TXG.cs

Further investigations are needed.

[[Category:File format]]
[[Category:Gotcha Force]]

TXG (File format)

2023-10-07T12:53:34Z

Algoflash:

[[Gotcha Force | ← Gotcha Force]]

''This article is about the TXG file format. See [[TXG (Gotcha Force)]] for current research on Gotcha Force TXG.''

{{Research | 2| Researches on headers / bodies structures are partially achieved. }}

TXG file format is an archive which contains [[TPL (File format)|TPL]]. Following class is interesting for documenting the file format:

https://github.com/Struggleton/TXG2TPL/blob/master/TXG.cs

Further investigations are needed.

[[Category:File format]]
[[Category:Gotcha Force]]

TSB (Gotcha Force)

2023-10-07T12:52:47Z

Algoflash:

[[Gotcha Force | ← Gotcha Force]]

''This article is about Gotcha Force TSB file format and ongoing researches on it. See [[TSB (File format)]] for TSB file format description.''

{{Research | 3| Researches on headers / bodies structures has to be done. }}

TSB files contain the magic number "TSDB". They have a fixed length of 0x810 bytes (2064 bytes).

[[Category:File format]]
[[Category:Gotcha Force]]

TPL (File format)

2023-10-07T12:52:06Z

Algoflash: /* Header */

[[Gotcha Force | ← Gotcha Force]]

''This article is about the TPL file format.''

{{Research | 1| The structure of this file is well known. }}

'''TPL''' file format ('''T'''exture '''P'''alette '''L'''ibrary) is a folder with [https://www.gc-forever.com/yagcd/chap15.html#sec15.3 one or several texture].

== Format ==

A TPL file contains one or several texture:

{| class="wikitable"
! colspan=2 | General format
|-
| colspan=2 align=center | TPL header file
|-
| colspan=2 align=center | Image offset table
|-
| rowspan=4 align=center | All images || align=center | Palette header (optional)
|-
| align=center | Palette data (optional)
|-
| align=center | Image header
|-
| align=center | Image data
|}

=== Header ===

In general the header has a length of 12 bytes. All offsets are relative to the header.

Header:

{| class="wikitable"
! colspan=3 | Header
|-
! Offset !! Length !! Description
|-
| 0x00 || 4 || FileMagic. Always "\x00\x20\xAF\x30" (big endian)
|-
| 0x04 || 4 || Image count.
|-
| 0x08 || 4 || Image table offset
|}

=== Gotcha Force TPLs length ===

All TPLs are aligned to 32 bytes. (NTSC/USA version)

== Softwares ==

Softwares below handle TPLs files:
* [https://github.com/marco-calautti/Rainbow Rainbow], credits Marco Calautti.
* [https://github.com/libertyernie/brawltools BrawlBox], contributors: libertyernie, Sammi Husky, and BlackJax96
* [https://github.com/Nightcaat/CTools CTools Pack], credits Chadderz
* [https://github.com/Wiimm/wiimms-szs-tools Wiimms SZS Tools], credits Wiimm: can contain BREFT, BTI, TEX0, TPL and PNG.
* [https://wiki.tockdom.com/wiki/Wexos%27s_Toolbox Wexos's Toolbox], credits Wexos

[[Category:File format]]
[[Category:Gotcha Force]]

TPL (File format)

2023-10-07T12:51:33Z

Algoflash: /* Header */

[[Gotcha Force | ← Gotcha Force]]

''This article is about the TPL file format.''

{{Research | 1| The structure of this file is well known. }}

'''TPL''' file format ('''T'''exture '''P'''alette '''L'''ibrary) is a folder with [https://www.gc-forever.com/yagcd/chap15.html#sec15.3 one or several texture].

== Format ==

A TPL file contains one or several texture:

{| class="wikitable"
! colspan=2 | General format
|-
| colspan=2 align=center | TPL header file
|-
| colspan=2 align=center | Image offset table
|-
| rowspan=4 align=center | All images || align=center | Palette header (optional)
|-
| align=center | Palette data (optional)
|-
| align=center | Image header
|-
| align=center | Image data
|}

=== Header ===

In general the header has a length of 12 bytes. All offsets are relative to the header.

Header:

{| class="wikitable"
! colspan=3 | Header
|-
! Offset !! Length !! Description
|-
| 0x00 || 4 || FileMagic. Allways "\x00\x20\xAF\x30" (big endian)
|-
| 0x04 || 4 || Image count.
|-
| 0x08 || 4 || Image table offset
|}

=== Gotcha Force TPLs length ===

All TPLs are aligned to 32 bytes. (NTSC/USA version)

== Softwares ==

Softwares below handle TPLs files:
* [https://github.com/marco-calautti/Rainbow Rainbow], credits Marco Calautti.
* [https://github.com/libertyernie/brawltools BrawlBox], contributors: libertyernie, Sammi Husky, and BlackJax96
* [https://github.com/Nightcaat/CTools CTools Pack], credits Chadderz
* [https://github.com/Wiimm/wiimms-szs-tools Wiimms SZS Tools], credits Wiimm: can contain BREFT, BTI, TEX0, TPL and PNG.
* [https://wiki.tockdom.com/wiki/Wexos%27s_Toolbox Wexos's Toolbox], credits Wexos

[[Category:File format]]
[[Category:Gotcha Force]]

TPL (File format)

2023-10-07T12:51:14Z

Algoflash: /* Format */

[[Gotcha Force | ← Gotcha Force]]

''This article is about the TPL file format.''

{{Research | 1| The structure of this file is well known. }}

'''TPL''' file format ('''T'''exture '''P'''alette '''L'''ibrary) is a folder with [https://www.gc-forever.com/yagcd/chap15.html#sec15.3 one or several texture].

== Format ==

A TPL file contains one or several texture:

{| class="wikitable"
! colspan=2 | General format
|-
| colspan=2 align=center | TPL header file
|-
| colspan=2 align=center | Image offset table
|-
| rowspan=4 align=center | All images || align=center | Palette header (optional)
|-
| align=center | Palette data (optional)
|-
| align=center | Image header
|-
| align=center | Image data
|}

=== Header ===

In general the header has a length of 12 bytes. All offsets are relative to the header.

Header :

{| class="wikitable"
! colspan=3 | Header
|-
! Offset !! Length !! Description
|-
| 0x00 || 4 || FileMagic. Allways "\x00\x20\xAF\x30" (big endian)
|-
| 0x04 || 4 || Image count.
|-
| 0x08 || 4 || Image table offset
|}

=== Gotcha Force TPLs length ===

All TPLs are aligned to 32 bytes. (NTSC/USA version)

== Softwares ==

Softwares below handle TPLs files:
* [https://github.com/marco-calautti/Rainbow Rainbow], credits Marco Calautti.
* [https://github.com/libertyernie/brawltools BrawlBox], contributors: libertyernie, Sammi Husky, and BlackJax96
* [https://github.com/Nightcaat/CTools CTools Pack], credits Chadderz
* [https://github.com/Wiimm/wiimms-szs-tools Wiimms SZS Tools], credits Wiimm: can contain BREFT, BTI, TEX0, TPL and PNG.
* [https://wiki.tockdom.com/wiki/Wexos%27s_Toolbox Wexos's Toolbox], credits Wexos

[[Category:File format]]
[[Category:Gotcha Force]]

TPL (File format)

2023-10-07T12:51:02Z

Algoflash: /* Format */

[[Gotcha Force | ← Gotcha Force]]

''This article is about the TPL file format.''

{{Research | 1| The structure of this file is well known. }}

'''TPL''' file format ('''T'''exture '''P'''alette '''L'''ibrary) is a folder with [https://www.gc-forever.com/yagcd/chap15.html#sec15.3 one or several texture].

== Format ==

A TPL file contains one or several textures:

{| class="wikitable"
! colspan=2 | General format
|-
| colspan=2 align=center | TPL header file
|-
| colspan=2 align=center | Image offset table
|-
| rowspan=4 align=center | All images || align=center | Palette header (optional)
|-
| align=center | Palette data (optional)
|-
| align=center | Image header
|-
| align=center | Image data
|}

=== Header ===

In general the header has a length of 12 bytes. All offsets are relative to the header.

Header :

{| class="wikitable"
! colspan=3 | Header
|-
! Offset !! Length !! Description
|-
| 0x00 || 4 || FileMagic. Allways "\x00\x20\xAF\x30" (big endian)
|-
| 0x04 || 4 || Image count.
|-
| 0x08 || 4 || Image table offset
|}

=== Gotcha Force TPLs length ===

All TPLs are aligned to 32 bytes. (NTSC/USA version)

== Softwares ==

Softwares below handle TPLs files:
* [https://github.com/marco-calautti/Rainbow Rainbow], credits Marco Calautti.
* [https://github.com/libertyernie/brawltools BrawlBox], contributors: libertyernie, Sammi Husky, and BlackJax96
* [https://github.com/Nightcaat/CTools CTools Pack], credits Chadderz
* [https://github.com/Wiimm/wiimms-szs-tools Wiimms SZS Tools], credits Wiimm: can contain BREFT, BTI, TEX0, TPL and PNG.
* [https://wiki.tockdom.com/wiki/Wexos%27s_Toolbox Wexos's Toolbox], credits Wexos

[[Category:File format]]
[[Category:Gotcha Force]]

TPL (File format)

2023-10-07T12:50:45Z

Algoflash: /* Format */

[[Gotcha Force | ← Gotcha Force]]

''This article is about the TPL file format.''

{{Research | 1| The structure of this file is well known. }}

'''TPL''' file format ('''T'''exture '''P'''alette '''L'''ibrary) is a folder with [https://www.gc-forever.com/yagcd/chap15.html#sec15.3 one or several texture].

== Format ==

A TPL file can contain one or several textures:

{| class="wikitable"
! colspan=2 | General format
|-
| colspan=2 align=center | TPL header file
|-
| colspan=2 align=center | Image offset table
|-
| rowspan=4 align=center | All images || align=center | Palette header (optional)
|-
| align=center | Palette data (optional)
|-
| align=center | Image header
|-
| align=center | Image data
|}

=== Header ===

In general the header has a length of 12 bytes. All offsets are relative to the header.

Header :

{| class="wikitable"
! colspan=3 | Header
|-
! Offset !! Length !! Description
|-
| 0x00 || 4 || FileMagic. Allways "\x00\x20\xAF\x30" (big endian)
|-
| 0x04 || 4 || Image count.
|-
| 0x08 || 4 || Image table offset
|}

=== Gotcha Force TPLs length ===

All TPLs are aligned to 32 bytes. (NTSC/USA version)

== Softwares ==

Softwares below handle TPLs files:
* [https://github.com/marco-calautti/Rainbow Rainbow], credits Marco Calautti.
* [https://github.com/libertyernie/brawltools BrawlBox], contributors: libertyernie, Sammi Husky, and BlackJax96
* [https://github.com/Nightcaat/CTools CTools Pack], credits Chadderz
* [https://github.com/Wiimm/wiimms-szs-tools Wiimms SZS Tools], credits Wiimm: can contain BREFT, BTI, TEX0, TPL and PNG.
* [https://wiki.tockdom.com/wiki/Wexos%27s_Toolbox Wexos's Toolbox], credits Wexos

[[Category:File format]]
[[Category:Gotcha Force]]