Queue Game Library

Case study

Project details

Summary

Queue Game Library, or QGL, is a DirectX 12 game technology project built as an exercise in modern C++ architecture, performance-oriented design, and low-level Windows programming.

Description

QGL started as the foundation for a game engine. The idea was to build a library that could handle the unglamorous but important pieces of game technology: timing, commands, callback dispatching, component ownership, GPU messaging, pipeline state setup, and other systems that sit underneath the visible game.

I may never build a full game with it. That is fine. At this point, QGL is mostly a laboratory for writing the kind of C++ code I care about: fast, explicit, testable, RAII-friendly, and organized around clear responsibility boundaries. Game development is a fun problem space because it does not let the architecture hide from reality. The system has to be responsive. It has to manage hardware resources. It has to survive asynchronous work. It has to make expensive operations predictable. It has to expose powerful tools without making every caller assemble the entire machine by hand.

The main design philosophy behind QGL is that good systems should be fast, flexible, familiar, and friendly. Fast means the code should respect performance constraints and take advantage of modern hardware where it makes sense. Flexible means systems should be composed from replaceable parts instead of tangled together. Familiar means the APIs should feel like modern C++ and use established idioms instead of inventing a private language. Friendly means the code should help the caller use it correctly, with RAII, compile-time checks, clear ownership, and error handling that fails near the source of the problem.

Some parts of QGL are deliberately low-level. DirectX 12 exposes a lot of machinery, and QGL does not try to pretend that machinery does not exist. Instead, the project explores where to put the boundary between control and convenience. A pipeline state object still has to describe shaders, rasterizer state, blend state, depth-stencil state, render targets, and device details. The question is how much of that plumbing should leak into the rest of the program.

That makes QGL less of a product and more of an architectural study. It is a place where I can practice designing APIs, wrapping platform details, managing resources safely, and building systems that are honest about complexity without becoming hostile to use.

Highlights

• Built around modern C++ idioms, including RAII, templates, const-correctness, move semantics, and STL-style patterns.
• Targets DirectX 12 and x64 Windows.
• Explores game-engine systems such as timing, commands, replay control, callback dispatching, GPU diagnostics, and graphics pipeline setup.
• Uses game technology as a forcing function for performance, resource ownership, and asynchronous design.
• Applies the same “Fast, Flexible, Familiar, Friendly” philosophy that guides my broader approach to software systems.

Status

Paused. QGL is not currently a production game engine, and I do not want to pretend it is. It is still one of my most useful personal projects because it gave me a place to practice serious C++ design against a demanding problem domain.

Resources

Project links