Next Previous Contents

9. Annotated Module Overview

9.1 The API Header

There is a limited set of headers/functions visible to both server and client. GAME_INCLUDE determines whether certain definitions are provided short (server) or full (client).

Module Purpose API information visible to serverand client.
Game API Header

Annotation: defines SVF flags, the edict SOLID flags, gclient_t and edict_s (short versions). Most importantly, it also declares game_export_t *GetGameApi (game_import_t *import); along with the game_export_t and game_import_t data structures. Leftovers: a linked list, MAX_ENT_CLUSTERS.

In summary, the game library requests the functions from the main engines whose pointers are in game_import_t (and thus cannot be changed within the scope of the game libary). This includes:

The functions within the scope of the game library and set in game_export_t (which thus can be changed within the scope of the game libary) include:

It also stores global variables shared between client and server, which can thus change from game to game. This is just the list of edicts, the current and maximum number of edicts, and edict_size, all of which are set by the InitGame function call.

9.2 The Quake2 DLL Shared Code

This code is independend of the game library as such, and also reference to by other programs, like server, ???development tools, editor, and preprocessors.

Module Purpose
q_shared.h q_shared.cCode shared between Q2 programs.
Shared Modules

Annotation: The only system/libc includes are here in the header file, as is the usual stuff (NULL, boolean). Loads of defines (not necessarily in this order):

Of particular interest is the pmtype_t classification to be take into account when processing pmove_state_t by client side movement prediction. The following attributes are there:

        // can accelerate and turn
        // no acceleration or turning
        PM_GIB,         // different bounding box

In addition, there are pmove->pm_flags, namely PMF_DUCKED and PMF_JUMP_HELD.

9.3 The Game (G) Modules

The bulk of behaviour animation code and physics simulation, with only a single header file to boot.

Module Purpose
g_local.h n/a Included by all game library modules.Local definitions/only header for all game modules.
n/a g_main.c GetGameApi, RunFrame
n/a g_phys.c Physics
n/a g_cmds.c Console Commands?
n/a g_func.c Functions?
n/a g_utils.c Utility functions?
n/a g_misc.c Miscellaneous
n/a g_weapon.c Weapons
n/a g_items.c Items, artifacts, powerups.
n/a g_combat.c Combat?
n/a g_target.c Targetting?
n/a g_trigger.c Trigger objects, events.
n/a g_spawn.c Spawning?
n/a g_ai.c Enemy AI?
n/a g_monster.c Enemy animation base code?
n/a g_turret.c Turret (composite, rotating objects).
n/a g_save.c Savegames, GameInit.
Game (G) Modules

Annotation: the single header file contains stuff so various as:

9.4 The Play/Client (P) Modules

Module Purpose
g_local.h n/a Local definitions for game module,does also cover these.
n/a p_client.c Player spawn spots, intermission view,player death and pain, body queue,client-server join.
n/a p_hud.c Intermission, scoreboard, help,stats navgational aids?
n/a p_trail.c Player trail, via points.
n/a p_view.c Roll, damage indicator, view offset,gun offset, display blend in water etc.,falling damage, environment dependendplayer sounds etc., client effects.Offsets?
n/a p_weapon.c Player noise objects for AI, weapon use,switch, drop, fire, hyperblaster rotationanimation.
Play (P) Modules

Annotation: None.

9.5 The Player

Module Purpose
m_player.h n/a player_x frames.
m_actor.h n/a player_y frames.
n/a m_actor.c Player avatar code.
The Player

Annotation: The m_player.h header is included in P (client, view, weapon) and G (commands) modules, but not in the actual m_actor.c implementation. The m_actor.h is used only there. Note that player_x and player_y actually correspond to the male/female models. The former has only 197 frames listed (and was created by another tool, qdata, only used for Tank and Iron Maiden, too), the latter has 480 frames listed, and was created by ModelGen as almost all the other monsters. The qdata tool was in the utils3 source release.

Note that players/male/tris.md2 is assigned by default. Bounding box dimensions are set in SP_misc_actor, question is whether this could be changed at runtime. While there is loading of gender specific sounds (in g_spawn.c), and switching the sound directory accordingly (in p_client.c), I fail to see where the model is patched for female players. It might not happen at all in single player. It seems to be done outside the game library in deathmatch.

9.6 The Miscellaneous (M) Monster Modules

Actually, these are shared/basic monster modules.

Module Purpose
g_local.h n/a Local definitions for game module,does also cover these.
n/a m_move.c Monster movement code, SV and Mfunctions, step, chase.
n/a m_flash.c Included in both in server and client code,LUT of muzzle offsets per monster.
Misc. (M) Monster Modules

Annotation: Don't think that these are tightly connected to the monster modules. There are only four direct calls in those modules:

The movement functions are mainly used in g_ai.c. The SV functions are actually used within the m_move.c, and there are a lot more in P and G modules (SV probably being a generic Server function prefix).

As for the muzzle flashes, the server uses the offset for shot spawn/tracing, the client for rendering the muzzle flashes. The file is just a single LUT, monster_flash_offset[]. As it happens, this is used by any monster module for a shooting monster, in a

G_ProjectSource ( self->s.origin, 
                  forward, right, start);

call, a function defined in g_utils.c and used in AI and item code (drop item?), too.

9.7 The Monsters

Module Purpose
m_berserk.h m_berserk.c Berserker (walker)
m_brain.h m_brain.c Brain (walker, tentacles)
m_chick.h m_chick.c Iron Maiden/Female Cyborg (walker)
m_flipper.h m_flipper.c Barracuda Shark (swimmer)
m_float.h m_float.c Technician (floater, rigid body)?
m_flyer.h m_flyer.c Flyer (floater, rigid body)
m_gladiator.h m_gladiator.c Gladiator (bird walker)
m_gunner.h m_gunner.c Gunner (walker)
m_hover.h m_hover.c Icarus/Hover (floater)
m_infantry.h m_infantry.c Enforcer (walker)?
m_insane.h m_insane.c Insane Player (walker)?
m_medic.h m_medic.c Medic (bird walker)
m_mutant.h m_mutant.c Mutant (dog walker)
m_parasite.h m_parasite.c Parasite (dog walker)
m_soldier.h m_soldier.c Light/Machinegun/Shotgun Guard (all walker)
m_supertank.h m_supertank.c Tank Commander (walker)
m_tank.h m_tank.c Tank (walker)
Monster Modules

Annotation: In all cases the header file is automatically generated und lists the animation frames. As with the m_player.h header, qdata was used only for Tank and Iron Maiden. All other monster header files were generated by ModelGen, supposedly the previous tool superseeded by qdata, which was in the utils3 source release.

In each case, the header file contains two comments added by the tool, a lot of FRAME defines for frame indices, and a final MODEL_SCALE, which is 1.0 except for the Gunner (1.15) and Guards/Soldier (1.2). The scale is assigned to self->monsterinfo.scale for each monster (SP functions).

The modelindex and bounding boxes are also assigned for each monster in the same function call.

9.8 The Bosses

In one case, the code provides an example of a composite.

Module Purpose
m_boss2.h m_boss2.c Boss2
n/a m_boss3.c Makron/Jorg composite, teleports.
m_boss31.h m_boss31.c Jorg
m_boss32.h m_boss32.c Makron - The Final Boss
Boss Monster Modules

Annotation: the formerly included file m_rider.h was not used, and is a leftover of the Boss3 development. All Boss3, Boss31 and Boss32 use the same models/monsters/boss3/rider/tris.md2 representation. The Boss31 also uses models/monsters/boss3/jorg/tris.md2 on the second modelindex.

The headers are generated by ModelGen, see remarks in the monsters section above. Same structure.

Next Previous Contents