Rendering Backends

CNA backend system — selection, tradeoffs, and implementation status

How backends work

CNA separates the game-facing rendering API from the underlying rendering implementation through a set of pure virtual interfaces (IGraphicsBackend, ISpriteBatchBackend, ITextureBackend). Game code never calls backend APIs directly.

A backend is selected at build time via the CMake variable CNA_GRAPHICS_BACKEND. Only one backend is compiled per build — there is no runtime dispatch overhead. Swapping backends requires only a CMake reconfiguration.

# SDL_Renderer
cmake -S . -B build -DCNA_GRAPHICS_BACKEND=SDL_RENDERER

# EasyGL (OpenGL via easy-gl)
cmake -S . -B build -DCNA_GRAPHICS_BACKEND=EASYGL

# bgfx
cmake -S . -B build -DCNA_GRAPHICS_BACKEND=BGFX

# Vulkan (scaffold only)
cmake -S . -B build -DCNA_GRAPHICS_BACKEND=VULKAN

Backend comparison

SDL_Renderer backend

CMake flag: -DCNA_GRAPHICS_BACKEND=SDL_RENDERER

The SDL_Renderer backend uses SDL3's built-in hardware-accelerated 2D renderer. SDL_Renderer targets OpenGL, OpenGL ES, Direct3D, Direct3D 11, Direct3D 12, Metal, or software rendering — depending on the platform and driver availability. SDL chooses automatically at runtime.

Advantages:

• Simplest integration — SDL handles all driver selection
• Widest platform portability, including mobile and web (via Emscripten)
• No additional dependencies beyond SDL3
• Good for straightforward 2D workflows

Limitations:

• Less control over rendering pipeline and shaders compared to raw OpenGL or bgfx
• Fixed-function pipeline — custom shaders require SDL3's shader support (still maturing)

Recommended for: Getting started, Windows development, broad platform portability, and 2D-focused applications.

EasyGL (OpenGL) backend

CMake flag: -DCNA_GRAPHICS_BACKEND=EASYGL

The EasyGL backend is a custom shader-driven rendering path using the easy-gl helper library over OpenGL. It provides finer control over rendering behaviour than the SDL_Renderer backend.

Advantages:

• Full shader-driven pipeline — custom vertex and fragment shaders
• Better rendering extensibility for more complex effects
• Explicit OpenGL API usage — good for learning and debugging

Limitations:

• Requires the easy-gl sibling repository
• OpenGL only — not Metal, DirectX, or Vulkan
• Less portable than SDL_RENDERER on some platforms (iOS, some Android configurations)

Recommended for: Linux development, custom shader work, and deeper rendering control.

bgfx backend

CMake flag: -DCNA_GRAPHICS_BACKEND=BGFX

The bgfx backend integrates bgfx — a cross-platform rendering library that supports Vulkan, Metal, DirectX 9/11/12, OpenGL, OpenGL ES, and WebGL from a single API. bgfx is fetched via CMake FetchContent.

Advantages:

• Same backend code targets Vulkan, Metal, DirectX, and OpenGL
• High-performance, production-proven rendering library
• Good mobile and console potential

Limitations:

• Implementation is ongoing — not all CNA features are complete in this backend
• More complex integration than SDL_RENDERER
• Requires internet access during CMake configure for FetchContent

Recommended for: Multi-API portability goals and once the implementation is more complete.

Vulkan backend

CMake flag: -DCNA_GRAPHICS_BACKEND=VULKAN

The Vulkan backend exists as an architecture scaffold in the CNA source. It defines the correct interface implementations but contains stub/TODO areas where actual Vulkan API calls would go. It is not usable for rendering at this time.

Current state: Architecture placeholder. Full implementation is a future milestone.

Recommended for: Not recommended for use until implementation is complete. The BGFX backend is a better path to Vulkan today, as bgfx uses Vulkan internally on supported platforms.

Which backend should I choose?