Orkuncakilkaya
8cc4bdf66b
The device's textureCompressionBC is asked for and remembered (gvk_has_bc). tex_load_ex prefers a DX10 .dds with the full chain beside the .png (not for an edge-padded cut-out atlas): texture_dds.ludic reads BC7 / BC5 / BC4, gpu_tex_compressed makes the image with every level and no colour-attachment use (a compressed image is only sampled and copied into), and gvk_tex_upload_blocks copies each level's blocks from one staging buffer. A colour map is BC7 sampled as sRGB, a data map BC7 read as it is. examples/rendering/bc.ludic holds it, in the suite; ludic.lab's plate carries its .dds (its three shots render at 56-60 dB against the .png's). ludic-dev test 307/307, no Vulkan SDK in the environment. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
11 lines
881 B
Markdown
11 lines
881 B
Markdown
bump: minor
|
|
type: feature
|
|
**A texture with a `.dds` beside its `.png` goes to the GPU BC-compressed, its mips included.**
|
|
`tex_load` (and everything built on it: glTF materials, the terrain's materials, ludic.ui's
|
|
pictures) looks for `<name>.dds` when the device has `textureCompressionBC` - every desktop GPU,
|
|
Apple silicon through MoltenVK too - and uploads its blocks as they are: BC7 (colour in sRGB,
|
|
or data read as it is), BC5 or BC4, a quarter of RGBA8 or less in video memory, no decoding and
|
|
no mipmapping on the load. Only a DX10 `.dds` carrying the whole chain to 1x1 is taken; anything
|
|
else is reported and the `.png` is used, as it is for a cut-out atlas (padded from the `.png`).
|
|
`gpu_tex_compressed` and `R3D_BC7` / `R3D_BC7_SRGB` / `R3D_BC5` / `R3D_BC4` are the backend's
|
|
entry; `examples/rendering/bc.ludic` is the check, and ludic.lab's plate carries its `.dds`.
|