This test file would only compile in C11 mode on a libc which implements annex K, which is none of the ones I have access to. Thankfully, that was used only for strcpy_s(), which can be replaced with strncpy() with no issue.

I also made it reflect argv[0] because my bcdec doesn’t have a .exe suffix.

Hello! Your library is excellent and I wanted to report this warning we got from integrating bcdec into our engine.

Warning C4701 potentially uninitialized local variable 'partition' https://github.com/iOrange/bcdec/blob/main/bcdec.h#L870

It seems like there's a very rare case that could happen where partition is uninitialized. I noticed the if-else block above on L829 sets it to 0 but only in the if, not the else. I'm not too knowledgeable on BC formats so I wouldn't know what the proper value to set it here would be, hence me reporting this warning we get in an issue rather than submitting a PR. 😅

When built into a shared library, this prevents them from getting their own symbol, duplicating code that would otherwise get inlined into the actual entrypoints.

The gain is of about 4 KiB when built using gcc 12 on Linux.

I am the team lead for Compressonator Tool, and would like to consider adding your single header decoder code into the repo. In order to do this can your license terms be updated to the same as Compressonator source code which is MIT licensed.?

The endpoint unquantize work does not depent on actual pixel index values, so it can be moved outside of the final pixel loop.

On my machine this makes BC6HU decoding go 82 -> 115 Mpix/s.

Disclaimer: my C++ experience is limited in comparison to my C# experience.

Thank you for making this! I ported your code to C#.

As part of porting your code, I replaced most uses of pointers with Span, which enables automatic bounds checking. I found a bug whilst testing on files with mipmaps. It overruns the output buffer when the decompressed image would be 2x2 or 1x1 pixels.

Example images which exhibit this issue can be found here. Each file contains an image and its mipmaps. The original is 256x256, and each mip is half the size of the previous image, ie 9 images in total. The 2x2 and 1x1 images each take up one block (8 bytes for BC 1 and 16 bytes for BC 2/3) at the end of the file.

Previously was always into a "float". Some use cases might need half precision as destination, e.g. decoding a texture on a GPU that can't do BC6H, but can do FP16 just fine. So now it has two functions bcdec_bc6h_float and bcdec_bc6h_half.

Curiously enough, even when using the "float", the new code is a bit faster in my tests -- it first decodes the block into half's, and then converts all of them into full floats. My guess is that the previous code was either harder on the branch predictor or on the code cache due to many expanded inlines -- the new one has all the half->float conversions in one place, outside of all the BC6H decoding logic.

On my Apple M1 Max, decoding BC6H unsigned into floats goes from ~79 Mpix/s up to ~85 Mpix/s.

The actual changes are fairly simple, and most of them are like "instead of doing work at byte level, do it at integer level".

In my tests, on windows (vs2022, ryzen 5950x):

• BC1 821->1327 Mpix/s
• BC3 516->694
• BC6H 65->85
• BC7 91->143

On mac (clang 13, M1 Max):

• BC1 804->2037
• BC3 585->1062
• BC6H 63->76
• BC7 113->212

With the speed bump, this makes it one of the fastest BCn decoders out there, actually (with some exceptions in some formats). I plan to write about this more somewhere, but here's a sneak peek (higher numbers are better; bcdec is upstream repo, bcdec_opt is with this PR)

Hi iOrange. I'm thinking of using bcdec over at https://github.com/bluescan/tacentview. Would it be possible to put the version number at the top of the header as a define after the include guards... maybe same for etcdec too?