Modern OpenGL Overhaul

This page is a technical document describing plans for the new OpenGL renderer.

Dropping src/hardware

All of the code here is gross, old and basically unmaintainable. The reason being, the interface was designed with the idea that the backend driver could be swapped out and replaced freely. This is completely unnecessary, and that driver's interface was designed for very old APIs with fixed function pipelines. We will replace it with an entire new system, and all hooks into the old code will be replaced.

Inspiration

The Strife: Veteran Edition source release shows a fantastic OpenGL 2.0 renderer for Strife. It is mechanically similar to my vertex array approach, but extremely well organized.

Doom iOS features a unique use of libtess from the GL reference implementation and a quicksort of triangles based on texture in order to minimize texture rebinds. Modeling ourselves after S:VE's renderer may enable us to do this later on down the road much more easily than I had been trying before.

Goals

• As minimal complexity for preprocessing as possible before sending the vertex information to the GPU.
• A single endpoint for drawing everything in the game world.
• A single endpoint for UI drawing.
• The ability to swap out these endpoints for rendering via GLES, GL 3.2, GL 2, etcetera (starting only with a GL 2 implementation).

Draw lists

When drawing, we will collect draw lists based on tags rather than immediately drawing out to the screen. Separate tags will be used for each of the major renderable types in the engine.

During the drawing step, the code will have the ability to consolidate these draw lists in efficient chunks (sorting like Doom iOS) after processing their vertices.

Shaders

The vertex and fragment shader for all world drawing, and the pair for UI drawing, will be predefined lumps within the game WADs. This way, they can be overridden by mods.

MD2s

Reimplementing MD2s is not a priority, but it shouldn't be hard to get them either. I suspect we'll be able to simply make them another draw list tag. They might use their own shader set.

API

Core

Structures

typedef struct {} hwTexture_t - Holds onto state for any texture uploaded to GL.

typedef struct {} hwDrawList_t -

typedef enum {} hwRenderType_t - Image source types (flat, patch, texture, etc)

typedef enum {} hwDrawListTag_t - Tags for render objects

Functions

hwTexture_t * HWR_GetTexture(hwRenderType_t, index)

void HWR_BindTexture(hwTexture_t)

void HWR_SetTextureProcessor() - function pointer assignment for processing texture uploads (converting lumps to usable texture data per render path)

void HWR_ProcessDrawLists()

void HWR_DrawElements()

void HWR_SetElementsProcessor() - func pointer for processing elements (binding VBO/arrays)

void HWR_SetElementsDrawer() - func pointer for drawing elements for a tag (glDrawElements for each list?)

hwDrawList_t * HWR_AddDrawList(hwDrawListTag_t) - get a new draw list to put data into and set processing function (to convert to vertices for uploading)

BSP Traversal

Structures

...

Functions

...

Shaders

Structures

typedef struct {} hwShaderProgram_t - shader program state info

Functions

...