basic sRGB sampling with SG_PIXELFORMAT_SRGB8A8 format

[allcreater]

SG_PIXELFORMAT_SRGB8A8 texture format is introduced

This is the first separate part towards full sRGB support, as specified in #562.

The SRGB8A8 format is a non-linear RGB format with linear alpha. This format is the most universal and the most supported sRGB format, with the exception of the compressed DXT family. DXT family is out of scope of this pull request but could be implemented separately. The proposed implementation is supposed to work on all backends except WebGL1 and WGPU

[floooh]

Thanks for the PR! I'm currently on vacation and do some emulator coding (only do some very simple drive-by PR merges here and there), but this one I want to test properly :) I'll try to take care of this when I'm back from vacation (January). If nothing has happened mid January though, please 'at' me :)

[allcreater]

@floooh so sorry to bother you, but I wanted to remind you of the request, looks like mid-January is already over :)

Also during this time, another of my requests appeared, it would be great if you can take a look at it too :)

[floooh]

Yep, delayed but not forgotten ;) (also saw your other PR, but didn't form enough of an opinion yet to provide useful feedback)

[floooh]

Going to look into this now...

[floooh]

Hmm, interesting. I've added the SRGBA8 pixel format to the pixelformats-sapp sample, and with the GL backend I can see a clear difference, while with the Metal backend, RGBA8 and SRGBA8 look absolutely identical 🤔

GL:

Metal:

this is on macOS ...I'll check the other platforms too...

...the difference only exists for render targets though...

PS: WebGL2 (Chrome on macOS): looks identical, unlike GL(!) and like Metal. At least it's consistent across browsers (Chrome, Safari and Firefox):

OpenGL on Linux is consistent with OpenGL on Mac (looks different).

On Windows, OpenGL is consistent with GL on macOS and Linux, and D3D11 is consistent with Metal and WebGL2.

I'll look into this issue tomorrow and decide whether I'll add a fix or merge the PR as is, I seem to remember that GL framebuffer objects need to be made 'sRGB aware', maybe it's easy to fix (and in the long distant past I also had weird problems with sRGB framebuffers on GL, but hopefully it's more robust nowadays).

[floooh]

Ok, I can get the same behaviour in GL as in D3D11 and Metal by enabling GL_FRAMEBUFFER_SRGB for offscreen rendertargets, but disabling it for the default framebuffer (I guess that NSOpenGLView creates an SRGB frambuffer, while the D3D11 and Metal probably create a non-SRGB framebuffer).

I'll enforce that behaviour for in the sokol-gfx GL backend, to properly fix this, an update in sokol_app.h would be needed later (basically an init param for sokol_app.h whether the default framebuffer should be in SRGB format or not).

I'll add a fix to the sokol-gfx GL backend in my merge branch, test on Linux and Windows, and then merge.

PS: I looked around a bit in the GLFW source code, and on macOS it's not possible to configure the SRGB behaviour (it's always enabled), while on other platforms, there are extensions to get SRGB framebuffers. This will be a bit tricky to resolve because sokol-gfx needs to know whether the default framebuffer is SRGB-enabled or not in order to do the right thing.

[floooh]

Ok merged! Many thanks for the PR!