There appears to be a regression in SDL 2.0.10 (when running on Windows 10 with the OpenGL backend) because SDL_RenderDrawLine() renders nothing if the start and end coordinates are the same. Reverting to SDL 2.0.9 causes a single pixel to be plotted, as would be expected according to the documentation. Is this a known issue?
Would it not make more sense to use SDL_RenderDrawPoint() if you want a single point drawn?
A line with the same start and end point is a line with zero length, and maybe some new optimization in SDL_RenderDrawLine() detects it and considers it a no-op.
It would be extra work, which ought to be unnecessary. My application is a programming language (BBC BASIC) and the LINE statement in that language maps directly to the SDL_RenderDrawLine() function. If in the LINE statement you specify the same coordinates for the beginning and end, the expected behavior is to plot a single point, and that has always worked (up to 2.0.9) without me having to special-case it.
Not according to the documentation: “SDL_RenderDrawLine() draws the line to include both end points”. In other words the length of the line isn’t the distance between the specified points, it’s that distance plus one.
I’ve identified what I believe to be the underlying issue: SDL_RenderDrawLine() is drawing the last point in the wrong place! Specifically, it is drawing it at coordinates (0,0) rather than where it should be, as can be seen here (greatly enlarged for clarity):
SDL 2.0.9 works correctly in this respect:
I have reported this at Bugzilla.
1 Like
As confirmation that it’s the last point that gets plotted in the wrong place, this is what happens if you swap the beginning and end points of the line:
I also noticed this with my vector font at some point between version changes; switching to Direct3D would produce different results. But using a recent version (2.0.11) I’m not seeing any problems. Could it be fixed in the mercurial?
I have no easy way to find out, because I’m not building SDL2 from source: I’m using the downloadable pre-built binaries (DLL for Windows, Framework for MacOS and repository install for Linux). I did search for bugs related to SDL_RenderDrawLine() and couldn’t find one that described this issue, but I suppose it might have been fixed as a side-effect of another change.
I guess it’s not easy to build from source with that setup? It’s easy with Visual Studio; I’ve noticed a couple of differences with the VS DLL (the software renderer is buggy, for example), so that might also affect the line drawing). Can you get someone to build a new DLL from mercurial? I’m happy to get one to you.
I’m more than happy to try it if somebody can build one for me (32-bit DLL preferred). I should add that I’m not enabling render batching, in case that makes a difference.