Closed icculus closed 1 month ago
This seems like a good idea to me, as long as sdl2-compat works.
Okay, I just reread all of #5061, which gave me both PTSD and cold feet about making this change.
Sending my thoughts and prayers @icculus 👏. I have shied away from the line functions for all these reasons. I like the idea of dumping them for SDL3, and just including basic geometry rendered lines. Do whatever's needed to keep the current lines in sdl2-compat.
Let's not do this. It's only going to bring pain and misery.
We have four different ways to draw lines in the 2D renderer:
Partially this was to deal with the painful end-point laws on native lines, and partially this was to make several different camps happy (see #5061, where we beat this topic--and nearly ourselves--to death). One of the problems is that existing games could break with the geometry version, because they might be expecting specific (incorrect?) line end points, and they are very slightly thicker than native lines, but otherwise they seem to be pretty good.
Since we don't have to worry about existing games, I propose that we change this to do the following:
The new intention of a backend supporting native lines isn't so much to pass stuff through to draw with
GL_LINES
on the GPU but to signal intention; this will let the software renderer draw a line faster than it could with the generic geometry; everything else backed by a GPU won't care either way so they don't implement it. We delete a bunch of code. Future backends have less to implement.sdl2-compat will probably need to eat the Bresenham code from SDL_render.c to support existing games with specific pixel-perfect demands, but it would still be able to replicate everything but native lines with the public SDL3 API.