HSD Documentation
Melee was built on the HAL sysdolphin engine, or HSD for short. Developed in secret, the aim was to produce working development-kits for developers before Nintendo had done so themselves. It took the Yamanashi studio about three weeks to create. More information can be found here.
From here on out, I will be referring to the underlying engine Melee runs on as HSD.
INSERT GRAPHIC HERE EXPLAINING PIPLELINE
HSD has many object types. Nearly everything in the game is built on and using these objects. For the purpose of Training Mode, not all object types are needed. I will be describing the relevant ones below.
The GObj is the most fundamental object in HSD. It can be seen as the "building block" of HSD, as other objects must be linked to a GObj to function. Below will detail some of the data a GObj contains. This will contain some information not yet explained, so if this is your first reading it is recommended to come back to this after learning about the different object types.
| Value | Description |
|---|---|
entity_class |
The major classification of the object. There exists a linked list of GObj's for every entity_class. |
gx_link |
How a CObj identifies a GObj to decide if it should render it's contents. |
gx_pri |
Draw priority for this GObj within the CObj. |
next |
Points to the next created GObj. |
previous |
Points to the previously created GObj. |
gx_cb |
Function pointer that handles drawing the GObj contents onscreen. |
proc |
Structure pointer that contains various callbacks that dictate this GObj's per frame behavior. |
hsd_object |
Points to the object this GObj contains. A GObj can only contain one hsd_object, either model data or a camera. If neither are needed, it can also contain no hsd_object. |
userdata |
Points an allocation containing all data this GObj needs to function. Oftentimes this points to a structure |
Creating a GObj will insert it into the process queue, which will make the game update it once every frame. It is updated by firing off the procs assigned to it upon initialization. All logic this GObj need should be handled via these procs. A GObj can contain many procs and each is assigned a priority number so its order of operation can be defined. It is also important to note that GObj's are self contained, and upon being updated, will only have access to it's own data (userdata) (and any static variables of course), therefore it is important to give a GObj most everything it needs upon initialization.
GObj's become very powerful when an hsd_object is assigned to it. A GObj can only contain one hsd_object, either model data (JOBJ) or a camera (COBJ). When assigned a JObj, the GObj's gx_cb will be used to draw the JObj onscreen when a CObj requests it to. When assigned a CObj, the GObj's gx_cb will be used to fire off all GObj's gx_cbs with a matching gx_link, effectively rendering them all.
When a GObj contains a JObj as its hsd_object, it must be rendered using a gx_cb. You can add a gx_cb by calling GObj_AddGXLink.
| Arg | Description |
|---|---|
gobj |
Pointer to the GObj. |
gx_cb |
Pointer to the function to render. |
gx_link |
int, Identifier for a CObj to know whether or not to render this GObj's contents. |
gx_pri |
int, Draw priority for this GObj within the CObj. Lower = drawn sooner. |
If you require no additional logic and want to unconditionally render its JObj, you can use function GXLink_Common as the gx_cb.
JObj's are joints which can be linked to form skeleton-like structures. Each JObj has its own scale, rotation, and transform values, which will be passed onto children JObj's. By themselves, JObj's cannot do much from a visual perspective. They must contain DObj's which will be detailed below.
DObj's ultimately contain all visual information. Without going into much detail, they are comprised of MObj's (material data), TObj's (texture info), and PObj's (polygon info). All of these combined allow for the creation of detailed 3D objects.
In short, AObj's contain different "tracks" that animate aspects of JObj's and MObj's and TObj's, e.g. animating scale of a JObj, swapping texture of a TObj, changing color/alpha of an MObj.
CObj's render an entire scene's worth of visuals. They are capable of rendering multiple gx_links (up to 64) by setting the the appropriate flags in the GObj field cobj_links. This is useful when multiple CObj's need to render the same visual (e.g. items and effects in the FoD reflection).
This section will contain details related to how the "fight engine" is structured. The "fight engine" refers to the game scene where matches occur.