=Cinematic

Pour afficher des vidéos RoQ ; le format RoQ est le format des fichiers vidéo dans Doom 3.

=draw_arb.cpp, draw_arb2.cpp, draw_common.cpp, draw_nv10.cpp, draw_nv20.cpp, draw_r200.cpp

Ces fichiers représentent les back-end pour toutes les architectures (les cartes graphiques) supportées par Doom 3, qui sont, selon idDevNet :

• NV20 (Nvidia)
• R300 (Radeon)
• ARB
• ARB2
• CG (Nvidia)

Par contre, on semble y trouver du support pour la NV10 et la R200, alors qu'il n'y a pas de fichiers pour la R300, ni la CG. J'imagine que la R300 doit être rétrocompatible avec la R200. La gestion pour la CG est incertaine.

ARB est probablement le langage d'assembleur de l'OpenGL Architecture Review Board (en).

Tous ces fichiers définissent plusieurs fonctions globales, dont certaines sont des implémentations de prototypes définis dans neo/renderer/tr_local.h.

draw_common.cpp sert certainement à regrouper les fonctions qui sont identiques pour toutes les architectures.

=glext.h

Ce fichier d'OpenGL définit des macros, des prototypes de fonctions, etc. pour des extensions d'OpenGL ( GLext == GL extensions).

=GuiModel

La gestion des GUI. Cette classe ne contient pas beaucoup de méthodes :

• idGuiModel::EmitToCurrentView() affiche un GUI sur un écran.
• idGuiModel::EmitFullScreen() s'occupe des GUIS qui prennent tout l'écran (menus, hud).
• idGuiModel::SetColor() détermine la couleur de chaque pixel d'un gui (y compris les images reçues d'une caméra...?).
• La première version de idGuiModel::DrawStretchPic() affiche la console, et les GUI sur les écrans.
• La deuxième version semble seulement affecter la console dans le jeu.
• idGuiModel::DrawStretchTri() est appelée par idRenderSystemLocal::DrawStretchTri(), qui n'est utilisée que dans le projet « d3xp ».

=Image (+ description)

Gestion des textures. C'est ici qu'est définie la classe idImageManager.

Commentaire dans Image.h : idImages have a one to one correspondance with OpenGL textures.

=Image_files

Gestion des différents types d'image (jpeg, bmp, pcx, tga). Toutes les fonctions sont globales.

• R_LoadCubeImages() fait le rendu des skybox.

=Image_init

Initialisation des images. On trouve ici idImageManager::Init().

• La fonction globale R_BlackImage() crée une image noire pour les fondus d'entrée et de sortie.

=Image_load

Plusieurs fonctions d'idImage reliées au chargement d'images sont implémentées ici.

Ces fonctions de bas niveau communiquent beaucoup avec OpenGL.

=Image_process

Regroupement des opérations qui peuvent être appliquées sur des images (réflection [x / y], rotation, MIP mapping, etc.).

• R_HorizontalFlip() réflète une image sur l'axe horizontal (pour l'inverser verticalement).

=Image_program

D'autres manipulations d'image, comme la création de normal map, l'inversion des couleurs ou de l'alpha et le redimensionnement.

=Interaction

Les interactions entre les surfaces (idRenderEntityLocal) et les lumières (idRenderLightLocal).

• Par exemple, idInteraction::CreateInteraction() affiche les lumières sur les murs et les objets.

=Material

Un objet idMaterial est un matériau individuel qui sera appliqué sur une brush ou un objet ; les matériaux sont définis dans les fichiers .mtr.

• idMaterial::AddImplicitStages() ajoute des map implicites (génériques) pour des matériaux qui n'ont pas tous les types de texture (bumpmap, specular map). S'il n'y a pas de texture diffuse (la texture de base) ou de bumpmap, l'objet reste noir. Dépendamment des textures présentes dans le matériau analysé, certaines textures génériques y seront ajoutées pour les interactions avec la lumière.
• idMaterial::CheckForConstantRegisters() (méthode void) s'achève immédiatement si la définition du matériau contient une variable reconnue (voir idMaterial::ParseTerm()). Sinon, elle crée un tableau de float (shaderParms[]) et appelle EvaluateRegisters() en lui passant le tableau idMaterial::constantRegisters[].
• idMaterial::EvaluateRegisters() : idMaterial contient un tableau de float nommé constantRegisters. La mémoire pour ce tableau est allouée dans CheckForConstantRegisters(), mais ses valeurs sont assignées ici.Cette fonction permet au code C++ de modifier les propriétés d'un script de matériau qui ont comme valeur une variable, plutôt qu'une constante. Elle est nécessaire, car les matériaux récupérés via la fonction idDeclManagerLocal::FindMaterial() sont constants.
• idMaterial::GetDescription() retourne la propriété description d'un matériau.
• idMaterial::GetNumStages() retourne le nombre d'étapes, c'est-à-dire, de blocs {}, dans une définition de matériau (fichier .mat).
• idMaterial::HasGui() indique si le matériau contient un GUI.
• idMaterial::IsDrawn() indique si le matériau sera rendu (les trigger et les portails, entre autres, ne sont pas visibles dans les maps).
• idMaterial::ImageName() retourne le nom de l'image du matériau telle qu'écrite dans sa définition (sans l'extension).

enum expRegister_t

Énumération déclarée dans Material.h.

Contient 22 valeurs : EXP_REG_TIME, EXP_REG_PARM[0 à 11], EXP_REG_GLOBAL[0 à 7] et EXP_REG_NUM_PREDEFINED.

=MegaTexture

Une première tentative d'id Software pour la gestion de mégatextures. Celles-ci sont utilisées dans les jeux id Tech 4 plus récents, comme Enemy Territory: Quake Wars, mais pas dans Doom 3. Par conséquent, l'utilité et la fiabilité de la classe idMegaTexture sont douteuses.

=Model / Model_local.h

L'importation et l'exportation de modèles Maya.

La classe idRenderModel (abstraite, définie dans Model.h) dont héritent plusieurs classes spécialisées : idRenderModelStatic, idRenderModelMD5, idRenderModelMd3, idRenderModelLiquid, etc.

Toutes ces classes sont définies dans neo/renderer/Model_local.h et implémentées soit dans Model.cpp, soit dans leur propre fichier (Model_md5.cpp, Model_md3.cpp, Model_liquid.cpp...).

La classe idRenderModelStatic charge des modèles immobiles à partir de fichiers .ase (modèle statique Doom 3), .lwo (LightWave Object), .flt (OpenFlight) et .ma (Maya ASCII).

• Selon toute apparence, idRenderModelStatic::TouchData() servirait tout simplement à faire appel au matériau du modèle, sans l'utiliser ou le modifier, afin que le matériau soit conservé à l'avenir, au lieu d'être supprimé.

struct srfTriangles_s

Hypothèse : cette structure représenterait un modèle de la géométrie d'un niveau. Elle contient :

• une AABB (Axis-Aligned Bounding Box) pour le modèle (idBounds bounds)
• le nombre de sommets dans le modèle, et un tableau des sommets (idDrawVert * verts)

=RenderEntity.cpp

Les implémentations des classes idRenderEntityLocal (idRenderEntity) et idRenderLightLocal (idRenderLight).

Presque toutes les implémentations des fonctions sont totalement vides ; les classes de base, idRenderEntity et idRenderLight, sont toutes deux abstraites, et leurs méthodes virtuelles pures doivent être implémentées dans leurs sous-classes.

(Quoique je me demande pourquoi ces fonctions existent, car elles n'ont aucune implémentation concrète.)

=RenderSystem

idRenderSystem (abstraite) est héritée par idRenderSystemLocal dans neo/renderer/tr_local.h.

Ce fichier déclare aussi trois fonctions globales implémentées dans d'autres fichiers : R_RenderLightFrustum(), R_LightProjectionMatrix() et R_ScreenshotFilename().

Les constantes SCREEN_WIDTH et SCREEN_HEIGHT, qui indiquent la résolution des gui, sont déclarées ici. Selon des commentaires, les gui ont tous une résolution de base de 640 x 480, et sont redimensionnés pour avoir la résolution finale du jeu :

// all drawing is done to a 640 x 480 virtual screen size
// and will be automatically scaled to the real resolution

Voir tr_local.h.

=RenderSystem_init.cpp

Ce fichier crée les CVar pertinentes pour le moteur de rendu (celles débutant avec r_).

RenderSystem_init.cpp et RenderSystem.cpp contiennent les implémentations des méthodes d'idRenderSystemLocal.

=RenderWorld.h

idRenderWorld contient tous les objets visuels qui seront rendus. C'est une classe abstraite héritée par idRenderWorldLocal dans RenderWorld_local.h.

• La structure renderEntity_s / renderEntity_t contient le modèle d'une entité et des informations graphiques supplémentaires (coordonnées, propriétés, réglages). idEntity a un objet de ce type nommé renderEntity.
• La structure renderView_s représente l'image produite par une caméra, la vue du joueur y comprise, et est mise à jour à chaque image.

=RenderWorld_local.h

idRenderWorldLocal se charge des entités et lumières visibles, des portails (struct portal_s), et probablement des informations graphiques de débogage.

Trois fichiers s'occupent de l'implémentation de ses méthodes :

• RenderWorld_demo.cpp : pour les démos, probablement sans conséquence.
• RenderWorld_load.cpp : chargement et construction des modèles et de la map.
• RenderWorld_portals.cpp : gestion des portails, connexions entre les salles ; récupération d'informations (NumPortals(), FindPortal(), AreasAreConnected()).

=simplex.h

Quand la CVar g_showentityinfo a une valeur de 1, les noms des entités dans la map sont affichés à l'écran. Ce fichier spécifie les lignes vectorielles de ces caractères.

=tr_backend.cpp

Une liste de fonctions globales.

• GL_State() fait plusieurs vérifications à chaque image ; elle règle d'ailleurs les problèmes d'affichage comme les objets plus loins qui sont dessinés par-dessus les objets proches, par exemple.
• GL_Cull() inverse supposément l'image lorsqu'elle provient d'une vue inversée.

=tr_deform.cpp

Les déformations possibles pour les surfaces. Fonctions globales, pas de classe spécialisée.

=tr_font.cpp

Les polices de caractère.

• idRenderSystemLocal::RegisterFont() est la fonction qui tente de charger les polices, elle renvoie false si l'opération échoue.

=tr_guisurf.cpp

Les interactions avec les GUI.

• R_SurfaceToTextureAxis() : je crois que cette fonction convertit la direction de la vue du joueur en coordonnées 2D dans le GUI (pour les GUI dans le jeu, pas ceux dans les menus). Cela indiquerait donc où il faudrait dessiner le curseur sur l'écran.
• R_RenderGuiSurf() fait le rendu de la surface de l'écran.
• R_ReloadGuis_f() est la fonction qui retélécharge les GUI lorsqu'on utilise la commande reloadguis dans la console.
• R_ListGuis_f() dresse une liste de tous les GUI actifs, lorsqu'on utilise la commande de console listGuis.

=tr_light.cpp

Il y a ici plusieurs fonctions, mais seulement une d'entre elles n'est pas globale.

• idRenderWorldLocal::CreateLightDefInteractions() se charge des interactions entre toutes les lumières et les entités. Sans cette méthode, seules les surfaces qui ne nécessitent pas de lumière (comme les GUI) seront visibles.

Cette méthode contient plusieurs étapes, en voici quelques-unes :

• vérifier si chaque entité est visible
• vérifier si la lumière doit projeter des ombres
• vérifier si l'interaction a déjà été créée

Plusieurs des fonctions globales servent à créer des caches pour les ressources utilisées par les lumières et les ombres.

• J'ignore ce que fait R_CreateAmbientCache(), mais quand je mets son contenu en commentaire, rien ne s'affiche à l'écran (quoique je puisse encore ouvrir la console et taper quit pour fermer l'application).
• R_SkyboxTexGen() est nécessaire pour les skybox.

=tr_lightrun.cpp

Gestion des lumières et de l'affichage des entités (car leur visibilité dépend des sources lumineuses dans la scène).

• R_CheckForEntityDefsUsingModel() identifie les entités qui utilisent un modèle quelconque.
• R_RegenerateWorld_f() est la fonction qui est appelée lorsqu'on utilise la commande regenerateWorld dans la console. Cette fonction réinitialise les interactions (entre les lumières et les entités, certainement).

=tr_local

Contient les classes :

• idScreenRect
• idRenderLightLocal (idRenderLight)
• idRenderEntityLocal (idRenderEntity)
• idRenderSystemLocal (idRenderSystem)

La structure areaReference_s contient plusieurs informations sur ce qui se trouve à l'intérieur de chaque zone.

• R_ScreenRectFromViewFrustumBounds() pourrait peut-être servir pour cadrer (et identifier) des objets dans la scène...

struct drawSurf_s

Selon les commentaires, les drawSurf sont les faces visibles des viewEntity_s (les entités visibles) :

drawSurfs are the visible surfaces of the viewEntities, sorted by the material sort parameter

struct viewEntity_s

Contient les informations d'un idRenderEntityLocal nécessaires pour le back end.

struct viewDef_s

Cette structure semble rassembler des paramètres pour la vue courante. Elle contient les données nécessaires pour afficher une vue : un objet renderView_t, un pointeur vers un objet idRenderWorldLocal, des valeurs booléennes pour indiquer s'il s'agit d'un miroir, et un idFrustum pour la zone visible de la caméra, entre autres.

Objets membres notables :

• idRenderWorldLocal* renderWorld
• renderView_t renderView
• idVec3 initialViewAreaOrigin
• bool isSubview
• idScreenRect viewport
• idScreenRect scissor