[rtextures] DDS / DXT1, DXT3 and DXT5: unit 0 GLD_TEXTURE_INDEX_2D is unloadable

[aboeglin]

Issue description

I have a sprite sheet that works fine when loaded as png but fails when loaded as DXT. I've tried different softwares to generate it. Texture packer, gimp and online converters all leads to the same issue, the texture seems to load fine:

INFO: FILEIO: [./assets/spritesheets/barbarian_jump.dds] File loaded successfully
INFO: IMAGE: Data loaded successfully (1473x1473 | DXT3_RGBA | 1 mipmaps)
INFO: TEXTURE: [ID 7] Texture loaded successfully (1473x1473 | DXT3_RGBA | 1 mipmaps)

I've also tried DXT1, 3 and 5 compression, all leading to the same issue:

UNSUPPORTED (log once): POSSIBLE ISSUE: unit 0 GLD_TEXTURE_INDEX_2D is unloadable and bound to sampler type (Float) - using zero texture because texture unloadable

Environment

INFO: GL: OpenGL device information:
INFO:     > Vendor:   Apple
INFO:     > Renderer: Apple M1 Pro
INFO:     > Version:  4.1 Metal - 86
INFO:     > GLSL:     4.10

Example file causing the issue

Here is one such image: barbarian_jump.dds.zip.

[raysan5]

@aboeglin I'm testing the shared image and I get the following info about it, please could you confirm it is correct:

INFO: IMAGE: Data loaded successfully (1473x1473 | DXT5_RGBA | 1 mipmaps)

The image size looks a bit strange to me, please, could you try converting it to power-of-two?

Image and texture get loaded but I get a black image; I think the internally computed size could not be correct...

[raysan5]

Definitely the issue is related to image not being POT, I tried to resize canvas to POT and now it loads correctly.
Could you test the attached file?
barbarian_scaled_to_pot.zip

[aboeglin]

@raysan5 yes correct, the provided image was compressed with DXT5. And your POT version does work although I'm pretty sure I tried that when exporting from texture packer already. Is it expected that non POT DXT compressed images can't be bound? Well given how the compression works it does make some sense but also I'd rather expect it to need to be like a multiple of 4 or something.

[raysan5]

Is it expected that non POT DXT compressed images can't be bound?

Actually I'm not sure, I tried opening the DDS image with Paint.NET and it was able to open it but I don't know if there is some internal magic to convert it to POT or just decompress the image data on loading (raylib tries to load the compressed data as GPU compresed texture)... I reviewed the DDS loading code in raylib , and I couldn't see any issue with it, the information it gets from the DDS image header is actually the data used when trying to load it as a texture.

I'd also expect it to be, at least, multiple of 4 in size and 1473 it's not...

[aboeglin]

Actually it seems to work with non POT dimensions that are multiples of 4. Would it be complicated to report an error while loading the texture for DXT formats if it doesn't comply? I'm happy to look into it if given pointers.

[raysan5]

Would it be complicated to report an error while loading the texture for DXT formats if it doesn't comply?

It could log some warning message if size is not multiple of 4 (point where you get that info from the file).

I'm investigating the issue and I think the data_size is not correctly calculated when image data is compressed. It needs to be reviewed more carefully. Here some reference code.

[aboeglin]

Should I try to open a PR to log a warning when the size isn’t a multiple of 4 for now until we try to see if we can make all sizes work?