Yes, but not yet in a ‘stable’ release (which will presumably be SDL 2.0.12). The current ‘stable’ SDL 2.0.10 has actually made things worse because of the ‘misplotted end-point’ regression, making it effectively impossible for me to use SDL_RenderDrawLine() (or the float version) for any of my antialiased graphics.
Even when 2.0.12 is released it’s going to be quite a while before the buggy versions have been flushed from the various Linux repositories.
Try persuading the author of SDL2_gfx of that!
I heard a rumour that the SDL devs were looking at using a surface to draw the lines instead of what they’re doing at the moment, which would change everything.
But yes, your problem won’t go away any time soon, but you can start the ball rolling on bugzilla now if it’s important to you.
This is the second time I’ve seen people mentioning problems with SDL_RenderSetLogicalSize recently. This function is broken and should not be used.
I created SDL_RenderSetLogicalSize several years ago and submitted it as a patch. Ryan added it, but he rather badly misunderstood what it’s supposed to be for and reimplemented the whole thing in a completely wrong way, then refused to fix it when I called attention to the problems with it, citing other “valuable” use cases that had nothing to do with what the concept of Logical Size is actually supposed to do. And now problems like this pop up because the function is fundamentally broken.
2 Likes
Yes, and rotated textures get scaled by logical size functions BEFORE being rotated, so they get all distorted and skewed.
Ryan is pretty savvy; give him credit - I’m sure there is a good reason behind his decisions. Changing the logical size functions now will break compatibility of a lot of games.
This is something that needs to be reworked for the next major version for sure.
Given the extreme reluctance even to increment the ‘minor’ version number (every new version is simply a ‘patch’ according to the usual interpretation) I can’t see there ever being another ‘major’ version! But seriously, I do wish SDL used the version numbering properly so one can tell when new functionality is added.
There was a highly specific reason: he wanted to have something that was able to deal with full-screen letterboxing for ports of old games that were written assuming a 4:3 aspect ratio. The problem is, completely rewriting something that was never intended to be for full-screen use in the first place (again, I can say this with authority, because I’m the one who create it) to shoehorn it into one very specific use case ended up breaking it for general use. Also:
Yes, and rotated textures get scaled by logical size functions BEFORE being rotated, so they get all distorted and skewed.
Yeah. There’s the “pretty savvy good reason” at work. 
The original implementation was much, much simpler, just changing the size of the viewport and letting the hardware take care of getting the scaling right. Introducing extra complexity ends up breaking stuff. Who knew?
I use a target texture (rather than rendering to the default target) so it’s trivial to accomodate things like pillarboxing or letterboxing at the point at which the target texture is eventually blitted to the default target, prior to the SDL_RenderPresent().
As a result my app can handle any ‘logical’ screen size (and it needs to because it is running legacy BASIC programs) simply by adjusting the scaling at that final ‘SDL_RenderCopy()’ step, without any need for SDL_RenderSetLogicalSize() or similar functionality.