Frequently Asked Questions

CNA is the project name. CNA's own repository never spells it out and no source in it says what the letters stand for, so this site claims no official expansion. The name plainly echoes XNA, which CNA reimplements in C++; an informal gloss (this site's own, not the project's) is "C++ native approach to XNA", or treat it simply as the project identifier for this open-source effort.

CNA is a pre-release. This site documents CNA snapshot c1c316b9 (branch apple/m4-stabilization, 9 October 2026), a development snapshot 3,687 commits after the v0.1.0-alpha.1 tag; its product version string is still 0.1.0-alpha.1. It is suitable for C++ porting experiments, research and demos, but public APIs may still change before 1.0. Its experimental native C ABI (version 0.46.0) is not built by CNA’s CI and its own release gate reports “Not ready”; the C# binding CNA.NET builds and uses it on Linux.

What is real: CNA represents the public XNA 4.0 runtime API in full — all 331 documented types and all 3,627 documented members have a matching C++ declaration, including the Framework.Design converters (opt-in; this is representation, not a claim of identical behaviour) — and Graphics, Input, Audio, Net, Media and Storage contain genuine implementations rather than only API-shaped shims. Achievements and leaderboards persist to disk, and MediaLibrary scans real user folders.

What to plan around: renderer capabilities vary widely (14 identities); the default Reach graphics profile is enforced on every renderer, so HiDef features must be requested; compiled XNA/FNA Effect Framework bytecode works on 11 of the 14 identities (FNA3D always, the rest behind default-off build options) and HLSL .fx source is not compiled at run time; multi-renderer selection is opt-in and latches on the first successful renderer creation; and the Web target has real threading and media caveats. Start from Releases, XNA Compatibility and Verification & Known Issues.

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++ project. CNA itself is a C++ library. Its C# binding, CNA.NET (repository cna-dotnet, beta), exposes the Microsoft.Xna.Framework API over CNA’s experimental C ABI and admits exactly ABI 0.46.0, the version this snapshot exports; eight further bindings are archived in CNA Lab and do not follow new ABI versions. CNA targets engineers who need or want native C++ - no managed runtime, no garbage collector. CNA shares the Ms-PL licence with FNA and used it as a day-to-day readable reference, but the two projects are independent and serve different ecosystems. Since September 2026 the project rule is that where a measured behaviour of Microsoft's real XNA 4.0 and FNA disagree, XNA wins, and each divergence is recorded.

A couple of places where CNA deliberately goes further than FNA: FNA's GamerServices is a permanent no-op shim, while CNA persists achievements and leaderboards to local disk, and FNA's Guide message-box and keyboard-input paths are stubs where CNA draws a real overlay. CNA also uses a running FNA build as one of its verification oracles — a harness dumps FNA's reference values to JSON and a script diffs CNA's against them (a manual harness, not a CI job).

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.

One practical relationship worth knowing: MonoGame's content pipeline is a perfectly good way to produce the .xnb files that CNA reads. CNA also has a build-time content tool of its own, cna-content, which writes .xnb and CNA's .cnb (there is no .mgcb route), so MonoGame's pipeline is one way to produce content, not the only one.

CNA is written in C++23, its native implementation language. Besides C++, CNA actively maintains two language bindings: C (its experimental C ABI) and C# through CNA.NET, a Microsoft.Xna.Framework-compatible facade over that ABI that runs XNA 4.0 C# source on CNA’s native runtime. CNA.NET is beta and pairs with exactly the ABI version this snapshot exports (0.46.0).

CNA also has Rust, Python, Ruby, Swift and Go bindings. They were developed to an advanced state and are now archived: they are no longer maintained, are not kept in step with new CNA releases and have no forward compatibility guarantee, and their source code and Git history are being preserved in CNA Lab. See Language bindings: maintained and archived.

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.

CNA is built to the C++23 standard and needs CMake 3.20 or newer. If you want to build games in C# today, FNA and MonoGame are the right tools. CNA fills a different niche.

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.

Start with the default for your platform and change it only when you have a reason. The defaults are WEBGL2 under Emscripten, OPENGLES3 on Linux, and SDL_RENDERER everywhere else. You pick one at configure time with -DCNA_GRAPHICS_RENDERER=<NAME>, or the equivalent -DCNA_RENDERER_<NAME>=ON — do not mix the two forms.

Things that will narrow the choice for you before taste does:

• Platform gates are hard errors. Two renderers are Windows-only — DIRECTX9 and DIRECTX11. METAL is Apple-only (macOS and iOS). WEBGL2 is Emscripten-only. Configuring the wrong one stops CMake with a FATAL_ERROR, and a name outside the 14 supported identities is a configure-time error too.
• One renderer is 2D-only by design and throws deterministically on 3D calls (or, if you ask, logs and stubs) — SDL_RENDERER. STUB also reports no 3D but is a no-op renderer rather than a 2D one.
• Two produce no pixels at all by design: HEADLESS and STUB, which are for validating game logic and call correctness. SOFTWARE rasterizes for real but stays off-screen (you read pixels back with GetBackBufferData()); only SOFTWARE on the TERMINAL platform is displayed.
• The default Reach profile applies to every renderer: multiple render targets, occlusion queries, 32-bit indices, float render targets and large cubes throw unless you request HiDef.
• Custom shaders do not run everywhere. See the shader question below.

CNA itself declares a maturity for each of the 14 identities in code (six Production, five Supported, three Experimental), and this site does not add a ranking of its own. The renderer reference records checkable platform, dependency and capability boundaries.

The 14 public renderer identities live in 12 implementation families. CNA keeps a deliberately curated set: each identity covers a platform, an API or a testing need the others do not, and the set is not a promise that all 14 are equally complete. If a single IGraphicsRenderer interface can be satisfied by Direct3D 9, WebGPU, a CPU rasterizer and Metal, then the interface is genuinely doing its job.

Two details explain the count. First, the Direct3D line is covered by DIRECTX9 (the API real XNA 4.0 ran on) and DIRECTX11. Second, three identities — OPENGLES3, OPENGL33 and WEBGL2 — share one internal implementation (EasyGL) distinguished by a CNA_GL_PROFILE_* define, because OpenGL ES, desktop OpenGL and WebGL each need their own context, shader dialect and platform gate.

The default keeps one renderer per build. CNA_GRAPHICS_RENDERERS can opt into several compatible implementations with pre-device runtime selection and fallback, at the cost of additional dependencies, build time and binary size. CNA's 18 workflows still do not cover every identity, driver and platform combination.

Yes. Two renderers are Windows-only — DIRECTX9 and DIRECTX11 — and the portable ones (VULKAN, the GL profiles, SDL_GPU, SOFTWARE and others) build there too. SDL_RENDERER is the default there. Windows windows come from SDL3’s windows video driver, which hands the Direct3D renderers their HWND.

Two caveats to hold on to. First, there is no automatic Windows evidence: native MSVC builds (Direct3D 11, the SDL3 platform suite, the content pipeline) are manual-dispatch workflows and Linux-to-Windows cross-builds run under Wine + DXVK are manual procedures, not continuous gates; the recorded MSVC dispatch of 2026-10-06 passed. Second, video decoding is not built on Windows — Video and VideoPlayer link, but playing a file-backed video throws System::NotSupportedException (metadata-only Video and the XNB video reader still work). Direct3D 11 was validated by hand on one physical Windows 11 machine; more reproducible real-Windows-hardware results remain especially valuable.

Yes, on Apple silicon. CNA’s Apple campaign tested it on a physical Mac mini M4 (macOS 27.0.1, Xcode 27): seven renderer trees — METAL, OPENGL33, WEBGPU, SDL_GPU, FNA3D, SOFTWARE and SDL_RENDERER — passed their full CTest suites with no failing test, and the 91 ported XNA samples passed the automated renderer matrix on METAL, OPENGL33 and WEBGPU. The console was locked during those runs, so on-screen presentation was not observed, and no Intel Mac was run. CI on GitHub’s macos-26 runners builds the SDL_RENDERER configuration with portable tests and an app-bundle launch, and builds METAL with its tests. FFmpeg is an optional dependency: with CNA_ENABLE_VIDEO=AUTO video decoding is enabled when FFmpeg is found (for example through Homebrew), but a binary linked against Homebrew’s FFmpeg does not start on a macOS older than the one that FFmpeg was built for. Online Gamer Services sessions need a libcurl with WebSocket support, such as Homebrew’s; Apple’s system libcurl lacks it.

iOS is experimental: SDL_RENDERER and METAL are admitted, networking must be off, and the evidence is the iOS Simulator (iPhone 17 profile), where a smoke app runs and a METAL pixel probe reads back exact frames; device apps final-link, but no physical iPhone or iPad has run CNA. tvOS remains unsupported.

Both, with caveats you should read before you start.

For the browser, CNA builds through Emscripten and offers WEBGL2 (the default) and WEBGPU through an Emscripten WebGPU port, declared experimental; both can share one bundle. The caveats are real and none of them produce a helpful error message:

• Saves persist through the browser’s IndexedDB, mounted for StorageDevice and isolated storage and restored before main(). Threaded builds need -DCNA_EMSCRIPTEN_USE_WASMFS=OFF for it, and browser storage remains per origin and clearable by the user.
• There is no video decoding. FFmpeg is never built for Emscripten. Video/VideoPlayer code compiles and links, but playing a file-backed video throws NotSupportedException at run time; use the HTML5 <video> element instead.
• No LAN discovery. NetworkSession discovery is excluded on Emscripten.

One caveat that older versions of this page listed is gone: Game no longer has to be heap-allocated. Game::Run() now blocks on the caller's stack through Asyncify, so a stack-allocated Game is fine (an external project that links CNA itself must link CNA::EmscriptenAsyncify; CNA's own application executables do it automatically).

For Android, the code paths and the NDK sensor implementations exist, and Compass and Motion are implemented there specifically. But Android has no automatic CI and no CMake preset, and the FFmpeg video backend is never built for Android (video throws NotSupportedException at run time). See Platforms for the per-platform detail.

This snapshot has 813 C++ test sources and 11,380 statically discoverable GoogleTest-family definitions (the alpha.1 tag had 568 and 8,263 by the same counting method), plus 781 standalone pixel-test programs under examples/ that those figures do not include. They are source-inventory counts, not a universal executable or pass count. CTest registration varies with renderer set, platform, audio implementation, host and feature options; report ctest -N for the configuration you actually built.

The most rigorous check is the 39-scene XNA oracle corpus: reference images captured by running the genuine XNA 4.0 runtime under Wine with DXVK on Linux (not on Windows). The repository records all 39 scenes as pixel-exact on the DIRECTX9 oracle path (the same Wine + DXVK stack, tolerance 0); the last consolidated dated report covers 31 of them and later per-scene notes record the rest. No 39-scene run was executed for this documentation, it has not been repeated on native Windows, and none of it runs in CI. That is a statement about DIRECTX9 specifically — the EasyGL and SOFTWARE renderers have a CTest on two line scenes only (the EasyGL test fails on any pixel difference, the SOFTWARE test only if a scene does not render; SOFTWARE measured 18 of 39 byte-exact), and CNA does not claim that all renderers are pixel-perfect. Separate, smaller instruments exist for framework packing, math and the content pipeline.

The snapshot contains 18 workflow files covering important Linux, Apple, Emscripten, platform-abstraction (including SDL3 on X11 and Wayland, and an SDL-free lane), multi-renderer and C API gate workflows; Windows lanes are manual. The C API's own gates are build-free and no CNA CI job builds the C API library, and the inventory still does not exhaust every renderer/driver combination or the full GPU pixel/oracle matrix. Verification & Known Issues has the scoped inventory.

CNA is open source under Ms-PL. The most valuable contributions at this stage are:

• Reproducible native-Windows verification for the DirectX renderers; the tag's Wine/DXVK and vkd3d-proton paths and MSVC workflows are manual, not continuous gates
• CI coverage for renderer, driver and platform combinations not exercised by the current workflows (for example real Windows hardware, Android and the GPU pixel/oracle corpus)
• Tests for the thin spots, above all Storage, whose module now carries 14 test macros (path containment, DeleteContainer, exception serialization) but none that writes a file and reads it back
• glTF follow-through — remove the reported mixed skin/rigid Tag carrier boundary and close renderer-qualified extension gaps
• Reviewing and porting the remaining sample directories in cna-samples, whose plan (pinned here at 5db32e6, 2026-10-03) lists 91 complete C++ ports and 8 relevant XNA 4.0 C# programs still to finish
• Porting games to CNA to expose API gaps

Open a GitHub issue or pull request at github.com/libcna/cna. Check the existing issues first.

sharp-runtime is a C++ reimplementation of a practical subset of the .NET System.* API that CNA's internals depend on. It is organised as about 41 independently selectable CMake components with a large test suite of its own (its README reports a passing count, a moving number this site does not restate). It provides primitives CNA uses internally but does not expose through the game-facing API.

It must be cloned as a sibling directory next to CNA before building — it is a separate checkout, not a submodule, and every CNA build needs it. For this snapshot use its next branch (git clone -b apple/m4-stabilization https://github.com/libcna/sharp-runtime.git): the default branch main lacks components CNA now requires (Resources and Xml.Serialization).

Siblings next to cna/, all separate clones rather than submodules. For this snapshot clone CNA and sharp-runtime from their next branches (git clone -b apple/m4-stabilization …, or check out CNA commit c1c316b9c7a846ce8002809c151fcd1af14942c9): a plain git clone of CNA gives the default branch develop, which is the alpha.1 tag. easy-gl and meta-gl use their default develop branches.

• ../sharp-runtime — required by every build.
• ../easy-gl (which itself needs ../meta-gl) — required by the three GL-profile renderers, which includes the Linux default OPENGLES3. So a plain default Linux build needs three siblings, not one.

FFmpeg is optional now: CNA_ENABLE_VIDEO=AUTO (the default) uses it on Linux and macOS when the libavcodec, libavformat, libavutil and libswresample development packages are found and silently falls back otherwise; ON requires them; OFF never touches them. A default Linux build does need the X11/GL/audio development packages instead. Inside the repository, git submodule update --init is correct; the recursive form is unnecessary and much slower. See Building.

Not for every architectural layer. CNA separates host platform integration, graphics rendering and audio-device selection. CNA_PLATFORM selects one of three implementations: SDL3 (the default, and the one windowing implementation — Windows, X11, Wayland, macOS, iOS, Android and the web through SDL’s video drivers), HEADLESS, and POSIX TERMINAL; any other name is refused. With CNA_ENABLE_SDL=OFF a windowless build contains no SDL at all. CNA_AUDIO_PLATFORM independently accepts SDL3 (the default), NULL and ALSA; OPENAL and WASAPI are reserved and refused. The mixer that defines SOUND_ENABLED — used by XNA playback, decoding, MediaPlayer and XACT — exists for the SDL3 and ALSA audio choices; Null is a real low-level device/configuration selection, not an equivalent high-level audio engine. Some combinations are rejected — for example, three renderer families require SDL3 and cannot be combined with an SDL-free build. See Platforms.

Yes, for reading — and, new in this snapshot, for writing at build time. CNA has an XNB loader with 61 built-in type readers (60 in a build without native 128-bit integer support, which drops DecimalReader; the video reader is registered in every build), covering the primitives, the math types, textures, SpriteFont, SoundEffect, Song, the five stock effects and the model family, behind a real LZX decompressor.

Three things to know before your first load:

• A Game registers the readers for you. Its constructor calls CNA::Internal::Xnb::RegisterAllBuiltInXnbReaders(). A stand-alone ContentManager (a tool, a test) starts with an empty registry and needs that call itself. C++ has no reflection to discover custom readers the way XNA does.
• CNA can now write .xnb, at build time. The cna-content command-line tool (and the XNA-shaped Microsoft::Xna::Framework::Content::Pipeline façade behind it: importers, processors, compilers) turns source files into .xnb or CNA's own .cnb. That pipeline is a separate build-time module that is never linked into a running game; the runtime ContentManager only loads. There is no .mgcb route.
• Load order. Load<T> tries .xnb, then .cnb, then loose files, and returns T by value.

Alongside .xnb and .cnb, ContentManager reads CNA's .cnj descriptors (the old .model.json name is gone: a model descriptor is a .cnj with cnjVersion and type); models can also load from .gltf/.glb. EffectReader is real for XNA/FNA D3D9 Effect Framework bytecode when the active renderer supports compiled effects. Custom XNB readers can be registered explicitly (or declared once with ReflectiveTypeReaderBuilder<T>), though CNA has no reflection-based discovery. See XNB Loading and ContentManager.

Yes, with no tooling step. Drop a .gltf or .glb into the content root and call getContentProperty().Load<Model>("name") (the model comes back by value). The importer uses vendored cgltf 1.15 and is unconditional. It handles skeletal and rigid animation, morph targets, LINEAR/STEP/CUBICSPLINE interpolation, build-dependent Draco decoding and the material/scene extensions classified by its source-owned registry.

The runtime path imports every mesh group into one Model, exposes every skin through getSkinsEXTProperty(), retains unskinned scene-node clips through ModelAnimationsEXT, and preserves factor-only and vertex-coloured PBR materials. It also converts strip/fan/loop topologies and rejects unsupported required extensions up front.

Use cna_tool_gltf_to_cnj when you need a unit scale other than 1.0 or prefer one output asset per mesh group. Read getGltfImportReportEXTProperty() for named diagnostics. One boundary remains important: when skins and extra rigid tracks share a file, Tag is occupied by the compatibility SkinningData, so the additional rigid tracks are omitted with a diagnostic. See Model Loading.

Yes, with the SDL3 (default) or ALSA audio implementation. XACT is implemented rather than stubbed: the .xgs/.xsb/.xwb binary formats are parsed and played back through the audio mixer (SDL3_mixer on SDL3, CNA's own mixer on ALSA), with real category and cue lifecycle management and 3D positioning. Basic playback through SoundEffect, SoundEffectInstance, DynamicSoundEffectInstance and MediaPlayer/Song uses the same path. The Null audio selection compiles the XACT classes but has no audible engine.

The boundaries worth knowing: 3D audio accepts any positive number of AudioListeners and the nearest listener decides (zero or a null array throws; Cue::Apply3D never had a limit); a wave bank containing XMA or WMA data does not throw but logs to stderr and returns nullptr, so the sound is simply missing (the XNB SoundEffectReader path does throw on the same content); the reverb send is a no-op; and .m4a/.aac cannot be decoded at all. See Audio System.

Yes, through two distinct paths. CNAEXT ShaderEffect accepts renderer-native source or binaries and works with SpriteBatch, post-processing and direct 3D draws. The XNA-compatible Effect(GraphicsDevice&, bytecode) and XNB EffectReader accept XNA/FNA D3D9 Effect Framework binaries on FNA3D and on builds that opt in to a compiled-effect option (11 of the 14 identities; the option names are listed on Effects). CNA does not compile HLSL .fx source or parse DXBC/MGFX at run time (the build-time cna-content tool can compile .fx through an external legacy fxc, unverified against a genuine Microsoft one).

Where ShaderEffect source actually executes: the three GL-profile renderers (GLSL), WEBGPU (WGSL), and DIRECTX11 (HLSL); DIRECTX9 also compiles HLSL, and METAL compiles SpriteBatch-scoped custom effects written in MSL. VULKAN takes SPIR-V words rather than GLSL text, and SDL_GPU supports the path only in builds that found libshaderc (GLSL) or with SPIR-V. HEADLESS records them without drawing. SOFTWARE accepts the source and silently never executes it, which is the failure mode most likely to waste your afternoon. FNA3D and the 2D-only SDL_RENDERER report no custom-effect capability. Query GraphicsDevice::ExecutesShaderEffectSourceEXT() and the RendererCapabilityProfile rather than guessing. See Shader Effects.

On desktop, yes. This page and others used to say the opposite, and that was wrong. Achievements and leaderboard entries are written as JSON under <StorageDevice root>/GamerServices/ with an atomic temp-file-and-rename, and they reload in a later process. The storage root comes from an environment-variable chain — XDG_DATA_HOME, then LOCALAPPDATA, then HOME (~/Library/Application Support on macOS, ~/.local/share elsewhere) — not from SDL_GetPrefPath, and the application folder is the literal name game unless you call StorageDevice::SetAppNameEXT("YourGame"). LeaderboardWriter and LeaderboardReader are real, with sorting, ranks and paging. Storage is real std::filesystem IO with correct per-player namespacing and, new in this snapshot, path containment. See Storage and Tutorial 141.

Three qualifications. Without a configured server, persistence is local; the optional self-hosted CNA Gamer Services server adds accounts, social features, server achievements and leaderboards and online sessions (it is not Xbox LIVE, and there is no cloud sync of local saves). See Gamer Services & Avatars. The Begin*/End* pairs on Storage, and for local profiles the GamerServices achievement, profile and leaderboard pairs, are synchronous: the callback runs inline before Begin* returns, faithful to XNA's own fake-async but no way to move work off the frame. For a server account the same GamerServices pairs complete later, on the game thread during GamerServicesDispatcher::Update. The exceptions are Guide::BeginShowKeyboardInput and Guide::BeginShowMessageBox, which complete later, when the player responds. On the Web, StorageDevice saves persist through the browser’s IndexedDB; see Storage.

easy-gl is a toolkit-independent C++ wrapper over OpenGL and OpenGL ES (its README says C++20; its CMake requires C++23). It is a sibling repository to CNA (../easy-gl, itself needing ../meta-gl) and is required by the three GL-profile renderers: OPENGLES3, OPENGL33 and WEBGL2. Since OPENGLES3 is the Linux default and WEBGL2 the Emscripten default, most people need it.

"EasyGL" is also the name used for that shared internal implementation inside CNA — it is not itself a selectable renderer value. Passing -DCNA_GRAPHICS_RENDERER=EASYGL is a configure error today; name the profile you want instead.

CNAEXT marks the declarations in CNA's XNA-shaped headers that are not part of the XNA 4.0 public API. Some are small ergonomics — C++ iterator support, convenience constructors — and some are substantial capabilities XNA never had: ShaderEffect, PbrEffect and SkinnedPbrEffect, skeletal animation, the post-process effects (AsciiPostProcessEffect, CRTEffect, DepthEffect, ColorMatrixEffect) and the whole CNA:: desktop-application surface. The CNA::Graphics extensions and the other CNA:: namespaces are not tagged declaration by declaration: they are gated by CNA_CNAEXT or carry an EXT suffix in their names.

The marker is checkable, but only where you check it: CNA_STRICT_XNA_API is a compile definition (not a CMake option — passing -DCNA_STRICT_XNA_API=ON to CMake configure does nothing). Define it on a target with target_compile_definitions(my_game PRIVATE CNA_STRICT_XNA_API) and any use of a CNA extension becomes a [[deprecated]] warning (an error under -Werror), which answers "would this code also compile against real XNA?" mechanically for the code you compile that way. CNA's own automated check of this mode covers only Microsoft::Devices/Sensors. Note that the CNA::Graphics extensions are opt-in — CNA_CNAEXT defaults to OFF, as does CNA_DEVICES for the CNA::Devices extension layer. (The older name for this marker was NOXNA; it is CNAEXT now.)

Both. The XNA gesture types are genuinely detected by a real state machine wired end-to-end to SDL3's touch events, and the TouchPanel API is fully connected to it. Mouse-to-touch emulation exists as an opt-in CNA extension (off by default, as in XNA/FNA).

Sensors are not Android-only, contrary to what this site used to say: Accelerometer and Gyroscope use a real sensor whenever the selected CNA platform reports one (a hardware probe on desktop Linux, Windows and macOS as well as on Android — though most desktops have none). They are instance classes: construct one, Start() it and read getCurrentValueProperty(); there is no GetState() or AccelerometerState. Compass and Motion genuinely are Android-only, built on an NDK sensor fusion, and report NotSupported elsewhere rather than faking values. These Microsoft::Devices::Sensors classes are always built; CNA_DEVICES=ON, which is not the default, gates only the CNA::Devices extensions (camera, clipboard, power, message boxes, file dialogs and similar). See Sensors.

The mechanical changes are: (1) namespace syntax, Microsoft.Xna.Framework → Microsoft::Xna::Framework; (2) properties become getter/setter methods, game.GraphicsDevice → game.getGraphicsDeviceProperty() and Content.Load<T>(…) → getContentProperty().Load<T>(…) (which returns the asset by value); (3) memory management, replacing new/IDisposable patterns with std::unique_ptr or values; (4) events, where C# delegates become virtual method overrides or event objects; (5) no LINQ, extension methods or reflection.

Content is easier than it used to be: your existing .xnb files load directly (a Game registers the built-in readers for you). You can also author .cnj descriptors, drop glTF files straight into the content root, or build .xnb/.cnb at build time with cna-content. XNA/FNA D3D9 Effect Framework binaries can come across on FNA3D or an explicitly enabled compiled-effects build (11 of the 14 renderer identities). HLSL .fx source, DXBC, MGFX and renderer-native shaders are different inputs; use the active renderer's ShaderEffect path when an effect does not fit the compatible binary path. The porting checklist in the CNA repository (CHECKLIST.md) documents the systematic deviations from FNA/XNA conventions, and Migration from MonoGame walks through the process.