From 49d6e90919bbc4f287013e429048afaf340d13b9 Mon Sep 17 00:00:00 2001 From: salmonik Date: Wed, 4 Nov 2026 00:07:36 +0100 Subject: Skybox image: upload via procedural texture, not CreateTextureFromBits The crash was CreateTextureFromBits: this build's IMaterialSystem interface stops at GetDisplayDeviceName, and the slots after it are CMaterialSystem's own virtuals, so index 134 was an unrelated function. Use CreateProceduralTexture (81, verified by disassembling the interface vtable) together with an ITextureRegenerator (SetTextureRegenerator 12, Download 13) that fills mip 0 via IVTFTexture::ImageData (39; IVTFTexture has a two-slot virtual destructor, so Width=15, Height=16, RowSizeInBytes=19). --- CONTEXT.md | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) (limited to 'CONTEXT.md') diff --git a/CONTEXT.md b/CONTEXT.md index a490403..669c1fb 100644 --- a/CONTEXT.md +++ b/CONTEXT.md @@ -364,8 +364,13 @@ vocabulary / decisions. the INI). Not `sv_skyname`: that did not take effect at runtime in this build, so the skybox card now works on materials instead. - PNG is decoded with libpng16's simplified API (`dlopen`ed, no link - dependency); the RGBA pixels become an `ITexture` via - `IMaterialSystem::CreateTextureFromBits` (RGBA8888, one mip). + dependency). This build's `IMaterialSystem` interface ends at + `GetDisplayDeviceName` (the slots after it belong to `CMaterialSystem` + itself), so there is **no `CreateTextureFromBits`**. The pixels are uploaded + through `CreateProceduralTexture` (vtable 81) + an `ITextureRegenerator` + (`SetTextureRegenerator` 12, `Download` 13), which fills mip 0 through + `IVTFTexture::ImageData(frame,face,mip)` (39). `IVTFTexture`'s virtual + destructor occupies two slots, so Width=15, Height=16, RowSizeInBytes=19. - The texture is assigned with `IMaterialVar::SetTextureValue` to `$basetexture`, plus `$hdrbasetexture` / `$hdrcompressedtexture` when those vars exist, on every material in the `SkyBox textures` group or named -- cgit v1.2.3