{"id":3128,"date":"2026-01-01T21:59:58","date_gmt":"2026-01-01T21:59:58","guid":{"rendered":"https:\/\/timallanwheeler.com\/blog\/?p=3128"},"modified":"2026-01-02T00:51:08","modified_gmt":"2026-01-02T00:51:08","slug":"into-depth-unified-triangle-shader","status":"publish","type":"post","link":"https:\/\/timallanwheeler.com\/blog\/2026\/01\/01\/into-depth-unified-triangle-shader\/","title":{"rendered":"Into Depth – Unified Triangle Shader"},"content":{"rendered":"\n

Into Depth is the name of a little game project I have been working on for over a year now. Its roots go back even further, to the 2D platformer I had started working on two years ago<\/a>. The platformer ended up teaching me a lot about OpenGL, which I have continued to use in a fairly low-level manner in this new project.<\/p>\n\n\n

\n
\"Concept<\/figure>\n<\/div>\n\n\n

Concept image by ChatGPT.<\/p>\n\n\n\n

In a nutshell, the game is a simplification of the 2D platformer born both from managing complexity and wanting something I could reasonably make multiplayer and play with my friends online. Into Depth is a turn-based 2D sidescroller on a grid. Kind of like Gloomhaven<\/a>, but vertical:<\/p>\n\n\n

\n
\"A<\/figure>\n<\/div>\n\n\n

An early mockup from my Google slides design doc.<\/p>\n\n\n\n

The team of heroes descends into dungeons (e.g., down the rope in the image above) with the goal of retrieving relics. Oftentimes these relics are heavy and require hauling to get them back to the surface. Collected relics can be equipped and used in other levels, and teams may revisit levels in order to get even deeper. That’s the rough idea.<\/p>\n\n\n\n

There are additional details, of course. For example, I want non-Euclidean geometry to play a role. In the screen above, the two edges labeled ‘a’ are joined, such that the hero’s view is:<\/p>\n\n\n

\n
\"Similar<\/figure>\n<\/div>\n\n\n

The hero can see the key from two different vantage directions because of the portal.<\/p>\n\n\n\n

This is made more interesting by having each hero only be able to see what is in their line of sight. Not only does that add an element of discovery and the need to juggle teammates’ perspectives, it also enables stealth mechanics.<\/p>\n\n\n

\n
\"An<\/figure>\n<\/div>\n\n\n

Solid geometry blocks the view of what is behind it. This image was from before I went orthographic.<\/p>\n\n\n\n

I am writing this myself, for fun, in my spare time. My primary goal is to learn how things work, and to actually get something playable for myself and my friends. <\/p>\n\n\n\n

I am using C++ and VS Code<\/a>, on Linux. I try to minimize library use, but leverage SDL2<\/a> as my platform library, use GLAD<\/a> for OpenGL, the GLM<\/a> types, and several Sean Barrett STB libraries<\/a>. This includes avoiding the standard libraries, such as std::vector and std::map, and I’m trying to use my own string view s8 as defined by Chris Wellons instead of std::string<\/a>. I actually haven’t been using ImGui<\/a> in this project, but I probably will once I have more of an editor.<\/p>\n\n\n\n

Why these restrictions? Because I am a big fan of Casey Muratori<\/a>, Jonathan Blow<\/a>, and the do-it-yourself attitude of understanding your code. It is a great way to learn how it all works, and it is fun! Presumably it leads to smaller executables and faster code too.<\/p>\n\n\n\n

The art you see here is programmer art, since I am a programmer. That is good enough for now. My long-term vision is to have a low-poly aesthetic and mostly not<\/em> use sprites, since I should be able to author low-poly meshes myself. The scene will be 3D with effects like lighting, but will be rendered in orthographic since that just makes it so much easier to see and work with the grid. <\/p>\n\n\n\n

Font Glyphs + Sprites<\/h1>\n\n\n\n

I was most recently working on some basic shaders for the game. I had just added font rendering with its own shader for rendering glyph quads. A UI system typically needs things beyond just font glyphs, like UI panels and sprite icons, and those are mostly just basic quads as well. It seemed obvious that I could share a shader for the dual uses of rendering font quads and rendering sprite quads:<\/p>\n\n\n

\n
\"A<\/figure>\n<\/div>\n\n\n

<\/p>\n\n\n\n

The shader is really simple. In the vertex shader, the position is just:<\/p>\n\n\n\n

gl_Position = proj_view * vec4(aPosWorld, 1.0);<\/code><\/pre>\n\n\n\n
And then the fragment shader uses the input color as  a componentwise multiplier after looking up the texture value via the UV coordinate:<\/p>\n\n\n\n
vec4 tex_color = texture(u_texture, uv);
FragColor = color * texture_rgba;<\/code><\/pre>\n\n\n\n
<\/p>\n\n\n\n
The font atlas has white glyphs, which means this color multiplier produces fonts that look like we want. Colored sprites are typically rendered with color<\/code> = [1,1,1,1] so that we don’t affect them, but you can also tint them by changing up the values.<\/p>\n\n\n\n
Rendering quads is also straightforward, but when you’re doing it all yourself, there is still a fair amount of stuff to keep track of. Every glyph in the font has a packed quad that tells us its size and its UV coordinates in the font atlas. We write the quad vertices into a VBO<\/a>, and rather than writing six vertices to get the two triangles per quad, we only write the four unique ones and use an EBO<\/a> to define the quads by indexing into the vertex array (as is standard practice):<\/p>\n\n\n
\n
\"A<\/figure>\n<\/div>\n\n\n
<\/p>\n\n\n\n
Each frame, the backend fills up a vertex buffer and sends it to the VBO for rendering. This only needs to happen once, if the sprites and the font glyphs are all packed into the same texture and everything uses the same projection and view matrix.<\/p>\n\n\n\n
Render Commands<\/h1>\n\n\n\n
The core game code does not directly fill the vertex buffer. Instead the core game code issues more simple render commands<\/em>. These commands are simple, higher-level descriptions of what we want rendered, making the core game code fast and separating out the task of deciding how to render everything up to the backend.<\/p>\n\n\n
\n
\"A<\/figure>\n<\/div>\n\n\n
<\/p>\n\n\n\n
For example, a render text command is:<\/p>\n\n\n\n
struct RenderCommandTextLine {\n    FontHandle font_handle;\n    glm::vec2 pos;       \/\/ Bottom-left of the first glyph\n    f32 letter_size;     \/\/ Multiplier off of default\n    f32 letter_spacing;  \/\/ Multiplier off of default\n    s8 text;             \/\/ Must last until rendered\n    glm::vec4 color;     \/\/ RGBA componentwise color multipliers\n};<\/code><\/pre>\n\n\n\n
It is up to the backend to convert that higher-level specification into the actual quad vertices, moving that non-trivial logic out of the core game loop and into its own location. The render command thus acts as an API between the game and the backend. Any new backend that we support in the future must be able to render these things.<\/p>\n\n\n\n
In the future, when I might have partially transparent objects, the backend can do more sophisticated things like render all opaque geometry first and then sort the transparent objects by depth and render them in a second pass. Something like that is very hard to do when the core logic is rendering as it goes.<\/p>\n\n\n\n
Including Triangles<\/h1>\n\n\n\n
So far, we have a shader that can render both font glyphs and sprites. That’s nice, but I want Into Depth to have a low-poly, flat-color aesthetic. I wanted to add UI panels that underlay the text, and I want those to be tessellated:<\/p>\n\n\n
\n
\"A<\/figure>\n<\/div>\n\n\n
<\/p>\n\n\n\n
A panel like that is comprised of a relatively small number of triangles when compared to a modern 3D character mesh (~40 vs. 1000’s). It should be cheap enough for us to directly write that geometry out every frame.<\/p>\n\n\n\n
Our font + sprite shader can actually be used to draw basic triangles, we just need to point all three vertices of the triangle to all-white uv coordinates so that we get the color we want. This is achieved by including a \\(1 \\times 1\\) white sprite<\/mark><\/span><\/span>This technique was mentioned in the Wookash Podcast with Omar Cornut of Dear ImGui.<\/span><\/span><\/span><\/span>.<\/p>\n\n\n\n
I thus define some additional render commands, such as RenderCommandPanel<\/code>, that act as high-level descriptions of what should be rendered, and then have the backend construct the mesh live in the vertex buffer and send it over. Doing this does not<\/em> use the quad-specific EBO, so for now I’m just using a glDrawArrays<\/code> call instead of a glDrawElements<\/code> call.<\/p>\n\n\n\n
I did make one adjustment to the shader – rather than switching out the textures depending on my use, I just have an array of textures that I can leave bound and have each vertex declare which one its UV coordinate applies to: <\/p>\n\n\n
\n
\"The<\/figure>\n<\/div>\n\n\n
<\/p>\n\n\n\n
I pack my fonts into a font atlas that is uploaded as the first texture, then have a series of sprite atlases.<\/p>\n\n\n\n
Sprite Packing<\/h1>\n\n\n\n
I need to bake my font glyphs and my sprites into a series of textures that my shader can then use. There are plenty of tools that do sprite packing for you. I was already using stb_truetype<\/code> and stb_rect_pack<\/code> to create my font atlas, so I decided to write my own sprite packer on top of stb_rect_pack<\/code>.<\/p>\n\n\n
\n
\"A<\/figure>\n<\/div>\n\n\n
<\/p>\n\n\n\n
Conceptually, it is really simple. I give it a set of individual sprites, and it keeps trying to pack as many as possible into a new texture until everything is packed. The only little gotcha is that a \\(w \\times h\\) sprite is packed as a \\(w+2 \\times h+2\\) rectangle in order for it to be padded with a 1-pixel extended border to fight edge bleeding caused by inaccuracies in UV coordinates between mipmap levels.<\/p>\n\n\n\n
Shader Code Organization<\/h1>\n\n\n\n
Beyond assets, shaders themselves tend to more complexity than you’d think because the code to use them ends up spread all over the codebase. The vertex and fragment shader definitions are often two separate .glsl<\/code> files, which live in their own folder alongside the other shaders. The C++ side typically needs a vertex struct defined somewhere, and then we need both CPU-side vertex buffers and references to the GPU-side shader program IDs, VAO, VBO, and EBOs. Whenever we use a shader, we need to activate it, which involves more code that has to use these references and set various shader uniforms.<\/p>\n\n\n\n
I’ve adopted a few enhancements to reduce the degree of code spread.<\/p>\n\n\n\n
The first thing I did was unify the vertex and fragment shaders into a single .glsl<\/code> file. Since we just read in the file and upload it to the GPU before calling glCompileShader<\/code>, we can actually process out the necessary portions ourselves. Writing both shaders in the same file helps keep their interdependencies consistent.<\/p>\n\n\n\n
\n
\n