SDL
SDL copied to clipboard
libsdl-org
Adjust SDL_RendererInfo.texture_formats limit for SDL3?
Hello, I saw SDL3 API finalization being talked about in another recent issue, so I wanted to be sure to raise this before that gets finalized.
I noticed that in SDL_RendererInfo, there is a limit of 16 entries in the texture_formats array. Will this be enough for the lifespan of SDL3?
Right now, the busiest render drivers seem to support 9 SDL pixelformats, but I feel that could go up quickly if more of the newly minted HDR formats / different RGBA byteorders were mapped in. It would suck to not be able to have the renderers map in more SDL pixelformats because of an ABI restriction in the number of supported pixel formats.
Good question. I was thinking about this the other day and didn't come up with a good solution. We can bump up the number of texture formats, but I don't know what a reasonable number would be, or how to make it extensible in the future.
Maybe it should have a function to query whether a format is supported by the renderer, instead of returning a list? Or a function that returns an allocated array the user should free.
From a slightly lower level perspective, it's not possible to know every format supported by a backend before some initialization is done, because support depends on hardware, drivers, etc. There's some guaranteed-to-be-supported formats for a given API but that list may be much smaller than the actual supported formats on a system.
If people are iterating through a list of renderer names/indices before creating one to pick based on what formats they support, maybe CreateRenderer could take an optional list of required formats instead, and fail for a given backend if it doesn't support them?
Actually it looks like the function to query this before a renderer is created was already removed in SDL3? The migration guide says one reason is because it couldn't be accurate.
One more consideration: a given pixel format might be supported for some types of things and not others - for example for drawing but not usable as a render target, or both of those but not bilinear-filterable. I don't know if SDL_Render should get too deep into the weeds with that sort of thing but it wouldn't be entirely reliable to have a list of supported formats without details about what features work with them.
I'm sure you both are more aware of the technical considerations of this than I am, but I feel like barring a more complex system is set in place, 64 texture formats is a nice safe number. Lots of room to grow into it from what is implemented now.