CNA-GAP-023: On DIRECTX9 a Texture2D can only be created with SurfaceFormat::Color
Evidence basis: source-verified at the pinned commit; tests exist (not executed for this page). Claims on this page were checked by reading the CNA source at commit 009d40f5; unless a sentence says otherwise, nothing here was built or executed. Nothing on this page was executed unless the Evidence section says so.
DIRECTX9 leaves ClassifySurfaceFormatEXT at its Defer default, so Texture2D creation falls back to a Color-only check although the renderer maps D3D formats internally; DXT XNB textures still load because the reader converts them to RGBA, but XNB textures stored in any other non-Color format do not.
- Identifier
CNA-GAP-023- Category
- Functional gap
- Subsystem
- Graphics & renderers
- Status
- Open
- Verified against
- CNA
009d40f5(009d40f5dd085c4e674d3479675fac84b12b3e0a) - Evidence basis
- Source-verified: read at TARGET, not executed
- Tests touching this area
- Yes: see Current tests
- Affected contract
- Texture2D constructors with a SurfaceFormat other than Color on DIRECTX9
Expected behaviour
XNA HiDef on Direct3D 9 creates textures in the DXT, Bgr565, Bgra5551, Bgra4444, Alpha8, floating-point and other formats the device supports.
Actual behaviour at TARGET
The default ClassifySurfaceFormatEXT returns Defer; DIRECTX9 does not override it (the renderers that do are DIRECTX11/12, EasyGL, OPENGL4, SDL_GPU, SOFTWARE, VULKAN and WEBGPU). Texture2D.cpp then calls Texture.cpp, which throws std::runtime_error ("Texture: SurfaceFormat N is not implemented by the selected graphics renderer") for anything but Color, and D3D9TextureRenderer allocates D3DFMT_A8B8G8R8 only. The XNB Texture2D reader (CreateTexture2DFromXnbData) converts DXT1/3/5 data to RGBA when the renderer does not keep it compressed, so DXT content loads. Every other non-Color format the XNB reader accepts (Bgr565, Bgra5551, Bgra4444, Alpha8, NormalizedByte, Rgba1010102, Rg32, Rgba64, Single, Vector2/4, Half*, HdrBlendable, ColorBgraEXT) is passed through unchanged as the Texture2D format, so such an asset also fails to load on DIRECTX9 with the same std::runtime_error, as does programmatic creation.
Source locations
modules/graphics/src/Xna/Texture2D.cpp— format admission: RendererFormatVerdict::Defer -> Texture::ValidateFormatmodules/graphics/src/Xna/Texture.cpp— Texture::ValidateFormatmodules/graphics/include/CNA/Internal/Renderers/Common/IGraphicsRenderer.hpp— ClassifySurfaceFormatEXT default Defer
Evidence
Checked by reading the named sources at 009d40f5; nothing was built or executed for this entry.
Independent re-verification: Checked by reading the named sources at 009d40f5; nothing was built or executed for this entry. The XNB consequence is inferred from the reader's format handling (only compressed formats are converted); no non-DXT, non-Color asset was loaded on DIRECTX9.
Focused reproduction
No focused reproduction is known. Nothing has been invented here; the evidence above is what exists.
Current tests
DIRECTX9 texture fixtures use Color.
Regression test
A DIRECTX9 ClassifySurfaceFormatEXT backed by CheckDeviceFormat, with a creation test per supported format.
Blast radius
DIRECTX9 games that create non-Color textures at run time (procedural DXT, 565 lightmaps, float data textures).
Workaround
Create Color textures and convert the data.
Related pages
The same subject is explained at several altitudes. These are the neighbouring pages at each one.
- Deep dives
- Surface formats: the renderer verdict
- Known issues
- Functional gap index