... | ... | @@ -18,6 +18,8 @@ Collision detection happens in P_CheckPosition, called by code that moves the mo |
|
|
|
|
|
D_Display handles most/all drawing in the game. Drawing the level is done by calling R_RenderPlayerView in software mode and HWR_RenderPlayerView in OpenGL mode.
|
|
|
|
|
|
# HWR_RenderPlayerView
|
|
|
|
|
|
HWR_RenderPlayerView draws the player's view of the level in OpenGL mode. Most of the rendering process actually happens twice, first the skybox is rendered and then the level itself is rendered on top. After clearing the frame buffer and initializing various variables, the rendering begins with HWR_RenderBSPNode((INT32)numnodes-1). This iterates through the BSP tree recursively, starting from the root node. (todo: link to bsp article) During the iteration, HWR_Subsector is called for all subsectors that are visible from the current view.
|
|
|
|
|
|
HWR_Subsector renders the floor and ceiling planes of the subsector by calling HWR_RenderPlane. Planes belonging to FOFs are also rendered. The polyobjects occupying the subsector are rendered entirely in this function. The sector's sprites are checked and retrieved, but their actual rendering will happen later in the process. Finally the linesegs belonging to the subsector are processed by calling HWR_AddLine for them.
|
... | ... | @@ -30,4 +32,32 @@ After the topmost HWR_RenderBSPNode call has returned, sprites (gathered from HW |
|
|
|
|
|
After sprites the translucent surfaces are rendered. While the level geometry was being rendered in HWR_RenderBSPNode, all walls and planes that are translucent were added to a list instead of immediately rendering them. These surfaces are called "drawnodes" in the code. (note: drawnodes are also used in software mode but they do not mean exactly the same thing) The drawnode list is also sorted before rendering for correct translucency.
|
|
|
|
|
|
Finally, after rendering the contents of the level, currently enabled postprocessing effects are applied to the screen. This includes screen flashing (armageddon shield blast) and screen waving. (underwater and heat wave) |
|
|
\ No newline at end of file |
|
|
Finally, after rendering the contents of the level, currently enabled postprocessing effects are applied to the screen. This includes screen flashing (armageddon shield blast) and screen waving. (underwater and heat wave)
|
|
|
|
|
|
# R_RenderPlayerView
|
|
|
|
|
|
R_RenderPlayerView draws the player's view of the level in software mode. After clearing the screen and initializing some variables R_RenderBSPNode((INT32)numnodes - 1) is called. This iterates through the BSP tree recursively, starting from the root node. (todo: link to bsp article) During the iteration, R_Subsector is called for all subsectors that are visible from the current view.
|
|
|
|
|
|
R_Subsector prepares the floor, ceiling, fof and polyobject planes of the subsector for later drawing. Sprites from the sector are also retrieved for later use. Then polyobject linesegs are drawn and lastly all regular linesegs belonging to the subsector are handled with R_AddLine.
|
|
|
|
|
|
R_AddLine handles culling logic for linesegs. R_ClipPassWallSegment is called for linesegs that are not added to the culling system and R_ClipSolidWallSegment is called for those that are. These two functions also cull the lineseg based on what has previously been added to the culling system. After culling R_StoreWallRange is called for the visible parts of the linesegs.
|
|
|
|
|
|
R_StoreWallRange makes further preparations for planes and fofs and draws the lineseg's bottom and top textures to the screen.
|
|
|
|
|
|
After the topmost HWR_RenderBSPNode call has returned, sprites (gathered from R_Subsector) are clipped against walls they are occluded by in R_ClipSprites. They are however not rendered yet.
|
|
|
|
|
|
Then floor and ceiling planes prepared earlier are rendered by R_DrawPlanes. FOF planes are rendered later.
|
|
|
|
|
|
The last major part of level rendering is R_DrawMasked. This function renders all fof walls and planes, sprites and midtextures. (?) (drawnodes) These have been gathered and prepared earlier during rendering. Before rendering, they are sorted into back-to-front order so that they display correctly.
|
|
|
|
|
|
# File/add-on loading
|
|
|
|
|
|
The core files are loaded at game startup with W_InitFile. Any files loaded later while the game is already running are loaded with P_AddWadFile, which also begins with a call to W_InitFile. For loading files at the startup, calling W_InitFile is enough since the game is not fully loaded and there is nothing else to update besides what W_InitFile does. But when the game is fully loaded, certain parts of the game need to be updated to handle the new content added by the add-on. This is handled by P_AddWadFile.
|
|
|
|
|
|
W_InitFile starts with error checking: the file is not added if an identical file is already added, or if there is not enough room for more files in the game.
|
|
|
|
|
|
Next the lump information of the file is retrieved, including the location, length and names of the lumps. (todo: link to something about WAD files) PK3 files are also handled as if their files were lumps. Lua and SOC files are treated as single-lump wad files. This information is added to the list of loaded files. (wadfiles) The lump and patch caches of the file are initialized.
|
|
|
|
|
|
All SOC, Lua and shader data in the file is loaded at the end of W_InitFile.
|
|
|
|
|
|
After P_AddWadFile has called W_InitFile, it does various things needed to get the engine to recognize the newly added content. Sounds that were replaced are unloaded. Cached sprite graphics and all hardware renderer graphics are cleared. Some content is loaded from the file with the functions R_AddSpriteDefs, R_AddSkins, R_PatchSkins, S_LoadMusicDefs and R_LoadSpriteInfoLumps. Some content is loaded by resetting parts of the engine by calling R_LoadTextures, P_InitPicAnims, HWR_ReloadModels and HUD functions, which scan all loaded files, including the new file, for content. |
|
|
\ No newline at end of file |