Frequently Asked Questions
CNA is the project name. It reflects the C++ nature of the reimplementation and draws on the XNA lineage. It is not an official acronym - think of it as "C++ native approach to XNA" or simply the project identifier for this open-source effort.
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.
FNA is an excellent managed C# reimplementation of XNA 4.0. It targets the .NET runtime, is binary-compatible with XNA 4.0, and is used commercially. CNA is a completely separate, C++-only project. It does not provide C# bindings. It targets engineers who need or want native C++ - no managed runtime, no garbage collector. CNA shares the Ms-PL licence with FNA and draws on it as a reference, but the two projects are independent and serve different ecosystems.
MonoGame is a cross-platform C# successor to XNA used commercially to ship games. It is mature, production-tested, and C#-based. CNA is a C++ project with a different target audience - engineers building in C++ who want an XNA-style framework without a managed runtime. Both MonoGame and FNA are better choices if you want to build games in C# today. CNA is for the C++ ecosystem specifically.
Several reasons:
- No managed runtime: C++ avoids garbage collection pauses, managed heap overhead, and JIT warmup. Useful for performance-critical or embedded scenarios.
- Toolchain flexibility: C++ integrates naturally with any C or C++ codebase, LLVM toolchains, console SDKs, and embedded targets that may not support .NET.
- API preservation: The XNA programming model is genuinely good design. Preserving it in C++ gives the XNA conceptual clarity to the C++ ecosystem.
No. CNA is an independent open-source project with no affiliation with or endorsement by Microsoft Corporation. XNA is referenced as the compatibility target and API inspiration only. XNA is a trademark of Microsoft. CNA does not use any Microsoft or XNA branding assets.
CNA is licensed under the Microsoft Public License (Ms-PL). This is the same licence used by FNA, reflecting that portions of CNA draw on FNA as a reference. The Ms-PL is a permissive open-source licence. See the LICENSE file for the full terms.
For getting started or Windows: SDL_RENDERER — simplest and most portable 2D option. For 3D rendering or browser/Emscripten targets: EASYGL — the most mature backend, full 2D+3D, all five stock effects, custom GLSL shaders, compiles to WebGL 2. For low-level GPU control with full 3D: VULKAN — second-most mature, all five stock effects real and pixel-tested; known gaps are BlendState For multi-API portability (Vulkan/Metal/DX): BGFX reached full 2D+3D pixel-verified parity with EasyGL/Vulkan; known gaps are custom ShaderEffect source compilation (unsupported) and OcclusionQuery correctness (unverifiable in this project's sandbox). See Rendering Backends for a full comparison.
Yes. Windows is supported via the SDL_RENDERER backend (MSVC 2022, clang-cl, or MinGW-w64) — it's cross-compiled with MinGW-w64 from Linux and verified running under Wine. It has not yet been validated on native Windows hardware or with continuous integration, so you may encounter rough edges there. See Platforms and Building for details.
Yes, both. The House 3D Demo and CNA Demo run in the browser today via EasyGL + WebGL 2. CNA also runs on Android via SDL3's native Android support — the NDK toolchain is configured and validated on hardware. See Platforms for details.
CNA is open source under Ms-PL. The most valuable contributions at this stage are:
- Implementing missing XNA API classes (see XNA Compatibility for the list)
- Improving backend feature parity (bgfx, Vulkan)
- Writing tests for existing implementation
- Testing on Windows, Android, or Emscripten
- Porting games to CNA to expose API gaps
sharp-runtime is a utility and runtime support library that CNA's internals depend on. It is a reimplementation of a very narrow subset of the .NET API in C++, providing primitives that CNA uses internally but does not expose to the game-facing API layer. It must be cloned as a sibling directory to CNA before building. It has no external dependencies and builds cleanly on all supported platforms.
CNA was designed from the start with SDL3, which is the active development branch of SDL. SDL3 brings API cleanups, improved mobile support, and a more consistent cross-platform experience compared to SDL2. Since CNA is a new project rather than a port, it was natural to start with the latest stable version of SDL.
No. CNA does not implement the XNB binary content pipeline. Instead, ContentManager uses a file-extension reader approach: PNG/JPG files load as Texture2D, OGG/MP3/WAV files as SoundEffect or Song, and JSON descriptor files (.font.json, .model.json, .shader.json) load as SpriteFont, Model, and Effect respectively. This means existing XNA/MonoGame games that rely on the Content Pipeline and .xnb assets will require manual asset conversion. The XNB format is intentionally deferred — CNA's JSON descriptor approach is simpler and avoids the build-time Content Pipeline tooling dependency.
Yes. The XACT audio runtime (AudioEngine, SoundBank, WaveBank, Cue) is now ~97% functional — a real .xgs/.xsb/.xwb parser plays back through SDL3_mixer, with real category/cue lifecycle management, 3D positioning, instance-limit enforcement with fade in/out (matching FAudio's shipped behavior), and continuous RPC volume/pitch curve re-evaluation. Basic audio playback is also fully working via SoundEffect, SoundEffectInstance, DynamicSoundEffectInstance, and MediaPlayer/Song using the same SDL3_mixer backend. The only documented gaps are accepted deviations, not missing implementation: no HRTF/elevation, and no AttackTime/ReleaseTime envelope tracking.
Yes, on the EasyGL and Vulkan backends. CNA provides a ShaderEffect class that accepts custom shader source: GLSL for EasyGL (pixel-tested) and SPIR-V for Vulkan (pixel-tested). You can use a ShaderEffect with both SpriteBatch (post-processing, 2D effects) and direct 3D draw calls. The BGFX backend does not yet support ShaderEffect (returns nullptr). The SDL_RENDERER backend is 2D-only and does not support custom shaders.
easy-gl is a helper library that wraps OpenGL ES 3.0/3.2 calls used by the EasyGL backend. It is a sibling repository to CNA (../easy-gl) and is required only when building with -DCNA_GRAPHICS_BACKEND=EASYGL. It is not needed for SDL_RENDERER, Vulkan, or bgfx builds. It compiles to WebGL 2 via Emscripten, enabling the browser demos.
macOS is not a current stated target and has not been officially validated. SDL3 does support macOS, so building CNA on macOS is technically possible and community members have reported success with the SDL_RENDERER backend. However, Apple deprecated OpenGL on macOS (so EasyGL may have issues), and Metal support would require the bgfx backend. macOS is not in the official roadmap, but PRs adding macOS CI validation would be welcome.
For production 3D on Linux or WebAssembly/browser: EasyGL is the most mature backend (passes 188 of 190 GPU pixel tests, all stock effects pixel-tested, context-loss recovery, MSAA 4×). For Vulkan-native deployments: VULKAN is the second-most mature backend and supports all five stock effects; known gaps are BlendState SDL_RENDERER is 2D-only (all 3D calls throw). BGFX reached full 2D+3D pixel-verified parity with EasyGL/Vulkan; known gaps are custom ShaderEffect source compilation (unsupported) and OcclusionQuery correctness (unverifiable in this project's sandbox). For browser/WebGL 2, EasyGL is the only supported backend today.
NOXNA is a marker in CNA headers that flags methods, fields, or types that are not part of the original XNA 4.0 public API. These are CNA-specific additions required to make the C++ port practical: C++ iterator support (begin()/end()), GetTypeName() for reflection, convenience constructors, and so on. If you want to write code that most closely mirrors XNA 4.0, avoid methods marked NOXNA. They are present in headers, so they compile, but they have no equivalent in XNA, FNA, or MonoGame.
Yes. Input::Touch is now ~98% behavior-complete: a byte-faithful FNA gesture-pipeline port (Tap, FreeDrag, Flick, Pinch…PinchComplete) wired end-to-end and tested against a deterministic clock. The TouchPanel API (GetState(), TouchCollection, TouchLocation, gesture detection) is fully connected to the SDL3 touch backend. The only documented deviations are intentional: GetState() is event-driven rather than poll-based, MaximumTouchCount reports 4, and GetState() caps at 8 touches — all matching FNA's own behavior.
The main mechanical changes are: (1) Namespace syntax: Microsoft.Xna.Framework → Microsoft::Xna::Framework. (2) Properties become getter/setter methods: game.GraphicsDevice → game.getGraphicsDeviceProperty(). (3) Memory management: replace new/IDisposable patterns with std::unique_ptr. (4) Content: replace .xnb asset loading with CNA's JSON descriptor format or raw file loading. (5) Events: C# event delegates become virtual method overrides. (6) No LINQ, extension methods, or reflection. The porting checklist in the CNA repository (CHECKLIST.md) documents every systematic deviation from FNA/XNA conventions.