SDL_RenderPolygon's limit to the range 0 to 1 texture coordinates seems impractical and I don't get why it exists about sdl HOT 7 OPEN

#5369

If the limit is lifted, then SDL will need to expose at least clamp and repeat wrap modes (like in the above PR) instead of always using a repeat wrap mode, otherwise people will run into unexpected behaviour – for example geometry that uses 0-1 texture coordinates can end up sampling texture pixels past the edges of the texture depending on what the vertex positions are, which results in visual artifacts with the repeat wrap mode.

from sdl.

Okay, sadly I was able to confirm this in my opinion possibly destructive limit exists:

#include <SDL2/SDL.h>
#include <stdio.h>

int main(int argc, const char **argv) {
    SDL_Window *window = NULL;
    if (SDL_Init(SDL_INIT_VIDEO) < 0) return 1;
    const int w = 400;
    const int h = 500;
    window = SDL_CreateWindow("Test",
        SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED,
        w, h, SDL_WINDOW_SHOWN);
    if (window == NULL) return 1;
    SDL_Renderer *renderer = SDL_CreateRenderer(window, -1, 0);
    if (!renderer) return 1;

    SDL_Surface *srf = SDL_LoadBMP("test.bmp");
    SDL_Texture *tex = SDL_CreateTextureFromSurface(renderer, srf);

    while (1) {
        SDL_Event e;
        while (SDL_PollEvent(&e) != 0) {
            if (e.type == SDL_QUIT) {
                return 0;
            }
        }

        SDL_Vertex vertex_1 = {
            {0, 0},
            {255, 255, 255, 255},
            {-1, -1},
        };
        SDL_Vertex vertex_2 = {
            {w, 0},
            {255, 255, 255, 255},
            {3, -1},
        };
        SDL_Vertex vertex_3 = {
            {w, h},
            {255, 255, 255, 255},
            {3, 3},
        };
        SDL_Vertex vertices[] = {
            vertex_1,
            vertex_2,
            vertex_3
        };

        SDL_RenderGeometry(renderer, tex, vertices, 3, NULL, 0);

        SDL_Surface *srf = SDL_GetWindowSurface(window);
        SDL_RenderPresent(renderer);
    }
    return 0;
}

Expected result: Polygon shows up. I would even expect it to show up with seemingly nonsensical texture coordinates, e.g. all of them set to the same value resulting in a solid color. It should show up no matter what the coordinates are, with no exceptions other than maybe NaN or infinity.

Actual result: Nothing is visible, unless you edit the texture coordinates to be in the 0-to-1 range.

from sdl.

Interesting point and I understand the concern over clamp modes. However, you could default to something like clamp to given coordinates if input coordinates were in range 0 to 1 to start with (which I assume is how it behaves now for that range), otherwise sample past repeating points and texture edges. This wouldn't require any API change whatsoever. I know this behavior results in undesired artifacts in some cases, but I think this is still highly preferable to the geometry just not showing up at all. I can't think of any use case where that is the preferred outcome.

from sdl.

Actual result: Nothing is visible, unless you edit the texture coordinates to be in the 0-to-1 range.

SDL_RenderGeometry is returning an error result in your code, I think. So it's not silently failing at least.

you could default to something like clamp to given coordinates if input coordinates were in range 0 to 1 to start with (which I assume is how it behaves now for that range), otherwise sample past repeating points and texture edges.

I think the approach in the above PR (having an explicit API that defaults to clamp) would feel more consistent to users, although personally I'd remove the error/UV range check in all cases if that's added.

from sdl.

There is for sure nothing wrong with an explicit clamp API, but if you wanted to backport the fix to SDL2 I just wanted to suggest how to do that without breaking API compatibility.

from sdl.

It's a new feature rather than a bug to be fixed, so I don't think any change would go into SDL2 and there wouldn't be a need for adding a compatibility mode.

sdl2-compat would just need to re-add the previous range check.

from sdl.

It seems more like a bug to me, but fair enough. Reason being it renders the old API broken for some important use cases, e.g. rendering just arbitrary 3d models loaded up. While affine mapping and no z buffer also gets in the way of that in some way I suppose, it's not in a way where the model can't even show up in the first place. And fixing it shouldn't break existing renderings, unless someone really relies on polygons supposed to be drawn not showing up for some reason.

Edit: maybe to give a small incentive for back porting this, e.g. I might need to drop SDL2 entirely if this wasn't fixed since working around this seems uneconomical. If however it was backported but just with occasionally wrong clamping, it might look a little glitchy but at least everything would show up and work fine for the user to interact with. So leaving it in SDL2 as-is might force many applications to just not ever target SDL2 in its entirety. That seems sub-optimal since I imagine especially on embedded and other more obscure platforms, SDL3 might not be available for a while until everyone has moved over.

from sdl.