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>
881 B
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.