About

What is CNA?

A native C++ framework that mirrors the XNA 4.0 programming model - without a managed runtime, without a virtual machine, just clean C++23 on SDL3.

⚠

CNA implements 227 of the 245 public types in the XNA 4.0 API, measured against FNA. Every type in Graphics, Audio, Input, Media, Storage and the math namespace is present. Two things are deliberately absent and will shape any port: the .xnb content pipeline (raw assets plus JSON descriptors are used instead) and compiled .fx shader bytecode (custom shaders must be hand-written GLSL/SPIR-V). Verification is real: 4,373 unit tests and 490 GPU pixel-readback tests across four backends, plus differential testing against a running FNA build. 63 of the 86 official XNA samples build on it. APIs are still evolving — good for research, demos and porting experiments, not yet for shipping a commercial game.

Background - the XNA programming model

Microsoft XNA Game Studio was a managed game development framework targeting Windows, Xbox 360, and Windows Phone. Released around 2006–2013, it offered developers a clean, well-structured API for 2D and 3D game development. The framework's game loop (Initialize, LoadContent, Update, Draw), its sprite batching system, content pipeline, and the Microsoft.Xna.Framework namespace hierarchy were widely praised for their clarity.

XNA was discontinued by Microsoft in 2014. The open-source community responded with notable projects:

  • FNA - a fully managed C# reimplementation that is binary-compatible with XNA 4.0, built on SDL2.
  • MonoGame - a cross-platform C# successor to XNA, used commercially to this day.

Both FNA and MonoGame are excellent projects. However, both remain in the managed C# ecosystem. There was no mature native C++ reimplementation of the XNA 4.0 API.

Why CNA?

CNA was created to fill a specific niche: native C++ implementation of the XNA 4.0 API. The reasons this is useful:

  • No managed runtime: C++ avoids garbage collection pauses, managed heap overhead, and JIT warmup costs. Useful for performance-critical or embedded scenarios.
  • Toolchain flexibility: C++ integrates directly with any C or C++ codebase, LLVM toolchains, and embedded/console targets that may not support .NET.
  • API preservation: The XNA programming model is genuinely good design. Preserving it in C++ keeps the conceptual clarity that game developers appreciated while moving to a native runtime.
  • Portability: Built on SDL3, CNA targets Linux, Android, WebAssembly/browser, and Windows (SDL_RENDERER backend, cross-compiled with MinGW-w64 and verified under Wine) today.

What problem does CNA solve?

If you are building a game or engine in C++ and you want:

  • A familiar, well-structured game loop modelled after XNA
  • A SpriteBatch API for 2D rendering and BasicEffect-powered 3D rendering
  • A GraphicsDevice abstraction that hides backend details (SDL_Renderer, OpenGL, Vulkan)
  • Complete input handling — Keyboard, Mouse, GamePad, Touch, Gestures
  • Audio via SoundEffect, SoundEffectInstance, and MediaPlayer — plus a real XACT (AudioEngine/SoundBank/WaveBank/Cue) implementation
  • Real cross-platform multiplayer via GamerServices/NetworkSession, backed by genuine ENet networking
  • Portability across Linux, Android, browser via WebAssembly, and Windows (cross-compiled/Wine-verified) — all working today
  • The ability to swap rendering backends without changing game code

…then CNA provides all of these today while keeping the implementation in native C++23.

What CNA is not

  • CNA is not a C# framework or a .NET library.
  • CNA is not affiliated with or endorsed by Microsoft Corporation.
  • CNA does not use any Microsoft, Xbox, or XNA branding assets. XNA is referenced only as the compatibility target and API inspiration.
  • CNA is not a game - it is a framework and runtime abstraction layer.
  • CNA is not yet recommended for shipping commercial games, though it is suitable for research, demos, and open-source development.

Relationship to FNA and MonoGame

📝

Attribution - based in part on FNA (C#): CNA is partially based on the FNA project, a managed C# reimplementation of the XNA 4.0.4 API. Portions of CNA's design, API structure, and implementation logic are derived from or inspired by FNA's C# source code. FNA is authored by Ethan Lee and contributors, and is likewise licensed under the Microsoft Public License (Ms-PL). CNA's use of FNA as a basis is permitted by and compliant with the Ms-PL. The full attribution is in NOTICE.md and THIRD_PARTY_NOTICES.md.

In practical terms: where FNA provides a C# class implementing a particular XNA behaviour, CNA translates that behaviour into C++23 idioms - replacing managed types with RAII, delegates with virtual methods, and properties with getter/setter methods. The game-facing API shape follows FNA's C# surface as the authoritative XNA 4.0 reference, while the internal implementation is native C++ throughout.

Both FNA and MonoGame remain excellent choices for managed C# game development. CNA serves the C++ ecosystem specifically.

C++ API differences — the NOXNA marker

Methods and types marked with NOXNA in CNA's source code are not part of the XNA 4.0 public API. These are C++ additions required for idiomatic C++ usage: iterator support (begin()/end() for collections), GetTypeName() for RTTI, RAII helpers, and other C++ glue. When consuming the API as a game developer, you can use NOXNA methods freely — the marker just indicates they have no XNA counterpart.

Technology stack

  • Language: C++23 — requires GCC 12+, Clang 15+, or MSVC 2022 v17.8+
  • Platform foundation: SDL3 (vendored submodule) — windowing, input, audio initialisation
  • Image loading: SDL3_image (vendored submodule) — PNG, JPG, BMP, and more
  • Audio: SDL3_mixer (vendored submodule) — SoundEffect, SoundEffectInstance, MediaPlayer/Song
  • OpenGL backend: easy-gl — a helper library over OpenGL ES 3.0; required only for the EASYGL backend
  • Runtime support: sharp-runtime — a sibling library providing .NET-style type aliases (bytecs, intcs, Single), interfaces (IDisposable, IEquatable<T>), events, and collections that bridge C#/.NET conventions into C++23
  • Video playback: FFmpeg — YUV→RGBA frame decoding for VideoPlayer; excluded on Emscripten and Android
  • Build system: CMake 3.20+ with CNA_GRAPHICS_BACKEND flag selecting the rendering backend at compile time
  • Test suite: GoogleTest (CnaTests target) — 4,373 tests covering math types, geometry, curves, game loop semantics, PackedVector precision, and more

Real-world validation

Unit tests only prove that the code does what its author expected. CNA is checked against three things it does not control:

  • The official XNA sample collection. cna-samples ports Microsoft's XNA Game Studio 4.0 samples to C++ on CNA. 63 of the 86 addressable samples build today; the 23 that don't are nearly all blocked on the same missing feature (compiled .fx shaders).
  • A running FNA build. A C# harness links the real FNA.dll, dumps reference values to JSON, and a script diffs them against CNA's own output. Ground truth comes from executing the reference implementation, not from reading its source.
  • Real XNA 4.0 on Windows 7. Where FNA itself might be wrong, disputed behaviour has been settled by running genuine XNA in a VM — that is how CNA's default CullMode was confirmed correct.

Beyond that, CNA Craft (a voxel game) and the browser demos exercise the API under real game-code conditions, including in WebAssembly. See Verification & Known Issues for the full picture, including what is currently broken.

Licence Ms-PL License

CNA is licensed under the Microsoft Public License (Ms-PL). See the LICENSE file for full terms. Portions of CNA are derived from or based on FNA, which is also licensed under the Ms-PL.