The SDL forums have moved to discourse.libsdl.org.
This is just a read-only archive of the previous forums, to keep old links working.

... seems like a very bad idea. I assume there is some sort of rationale behind this, and I'd like to understand, but here's my concern:

In principle, being able to draw a rotated and scaled texture should allow us to implement a global transform system, which is very convenient for having a display tree and simulate moving camera in our scene. However, the destination SDL_Rect in SDL_RenderCopyEx has integer members (position and size), meaning that most scalings and most positions that derive from global rotation will have to be rounded to integers. Except in specific cases (scaling by a divisor of both width and height of the sprite, or drawing at an actual integer position), the sprite will have a translation error of +/-1 pixel in both directions, and its dimensions as well (possibly even changing the aspect ratio a bit). Even the center of rotation point is given in ints, which of course makes it difficult to achieve the exact rotation needed by your global transform.

This is quite fine for individual sprites, because the naked eye probably won't see a 1 pixel error, especially with the high definition displays we have nowadays. My biggest concern is when you want to apply scale/rotation/translation to *groups* of sprites. Typically, tile maps. In these, a 1 pixel error will almost systematically be visible, as a seam between tiles. Example of a tilemap scaled by a factor of 0.7, on a white background:



Oooh, the drama! Having smooth zooming on a tilemap (and everything on it) is something you'd expect possible from a hardware accelerated 2D library.

I checked the source to see if there was a specific reason for these integer arguments, other than "legacy". Of course, when doing software blitting, having to align pixels is just the most simple way. But now that SDL2 actually has a hardware accelerated backend, this restriction has no reason to be. In fact, the SDL_RenderCopyEx function immediately converts its integer SDL_Rect and SDL_Point arguments into internal float-based SDL_FRect and SDL_FPoint, and passes them to the renderer's RenderCopyEx, which *does* take float arguments! Even the software renderer does.

I am simply puzzled as to why the API doesn't expose these floaty rects and points, defined in SDL_sysrender.h, and why the texture copy functions don't make use of them, or for that matter, the graphics primitives (lines, rectangles, etc.)

Of course, there are solutions to this issue:

1. patching SDL to expose and use floaty rects in the API. That forces me to ship a non standard SDL with my games, or compile it statically with my source. Also, there might be deeper reasons that I don't know about, that would come back to bite me in the ass later.
2. write my own GL-based 2D renderer with built-in transform stack. That seems stupid, given that most of it is already there in SDL, and that I would have to write a GL and a GLES version (I plan on targeting Android as well as desktop). Plus there's lots of really cool features already implemented (like the virtual resolution in fullscreen).
3. batch render all my "groups of sprites" to textures, and then draw these textures rotated-translated-scaled. It should work, but it probably complexifies the code a tad, and adds some overhead.
4. one simply does not use smooth scaling.

Has anyone encountered this conundrum, and how would you have solved it? And also, does anyone know the reason for this limitation?

Thanks for reading this far

2013/9/4 Tenoch


I made most of the RenderCopyEx code, it is what it is... simplicity, legacy and functionality across all backends are basically the main concerns.


In my repo I have a SDL_RenderGeometry function that sort of does what you want (sort of!) https://bitbucket.org/gabomdq/sdl-1.3-experimental/commits/branch/RenderGeometry and it's quite faster if there's a sizable number of quads that you want to render.


What I can tell you for certain is that there's heavy resistance to add new features to the rendering system as it is supposed to be bare bones, and the recommendation you'll get is to just roll your own GL code :)





--
Gabriel.

I have been working on SDL_gpu (https://code.google.com/p/sdl-gpu/) as an alternative rendering API wrapping OpenGL.  It's an option for use, reference, or contribution.

Jonny D



On Wed, Sep 4, 2013 at 1:43 PM, Gabriel Jacobo wrote:

2013/9/4, Gabriel Jacobo:

All of the resistance I've seen was against implementing new features
unless they were implemented in all renderers. The problem is that
somebody sends in a patch for a new feature but it's only for OpenGL
or Direct3D (and of course never the software renderer), and having
things that don't work in all renderers* is not a good idea.

(*exception: stuff that has fallbacks, e.g. I don't know if the
software renderer doesn't support texture filtering, but if it doesn't
it's probably still OK since the worst that can happen is you get
blocky texels, rather than outright missing graphics)

Back on-topic: as for fixing this: I don't see this happening anytime
soon just because of ABI concerns. The only alternative I see is
making alternate versions of the functions that take floating point
values.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

IIRC, the reason SDL uses integer arguments is that the API wants to be
pixel perfect across all renderers. This is not an important
consideration for me, but it was for the earlier SDL Devs.

Real problem with integer coordinates, from my perspective, is that
movement animations are always jerky. One frame your sprite moves 6
pixels, other frame it moves 7.

The seam you're seeing is likely because of texture sampling. Check this:

http://stackoverflow.com/questions/7894802/opengl-texture-atlas-bleeding
and this:
http://www.opengl.org/discussion_boards/showthread.php/165688-Texture-Atlas-edge-artifacts-how-to-fix




On 9/4/2013 12:25 PM, Tenoch wrote:

--
*Pallav Nawani*
*Game Designer/CEO*
http://www.ironcode.com
Twitter: http://twitter.com/Ironcode_Gaming
Facebook: http://www.facebook.com/Ironcode.Gaming
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Gabriel, Jonny D: I understand the need for simplicity, but a bare bones system that is just one tiny step short of being great seems a bit disappointing Like you said, if it's not "good enough", people are forced to write their own glue code or use an external library like yours. SDL 2 could have been a good occasion to actually have one standard implementation that concentrated the effort. But again, I don't know the whole story, nor the design and development policies for SDL, so it's probably easy for me to say "it should have been better" :)

Pallav: it's true that integer coordinates also bring an animation smoothness problem. However, since the days of Mario on the SNES, and before the advent of hardware accelerated 2D, I suppose that most video games were blitting sprites at integer coordinates, and we still had the illusion of "smooth" movement. But nowadays, yes, I'd expect to actually have the game coordinates and screen coordinates completely independent, and abandon the idea of pixel-perfect blitting. Especially - in my case - because my reference target is 1920x1080, and frankly, that's a *lot* of very small pixels.

About the seams in the picture, although your links are indeed interesting, I'm quite sure that here the problem is only related to integer coordinates and sizes: my 32x32 tile scaled by 0.7 gives a size of 22.4, which is rounded to 22. After three tiles, the cumulated width is 66, but the next position is floor(3*32*0.7), which is 67. There is an actual 1 pixel gap. In this specific case, I could of course always make sure that a tile's width is adjusted to touch the next tile, but it's not a general solution to the issue, as then the tiles wouldn't all be the same size, and it doesn't handle "everything else" that would be on screen.

2013/9/5 Tenoch



Personally, I was very surprised that SDL 2.0 actually improved and expanded their surface code,
I was expecting them to just deprecate and remove it to finally make OpenGL the real and only path
for graphics programming. To me it still feels more like a "toy API" that's meant for getting your
feet wet with 2D programming.


Rolling your own OpenGL code for 2D graphics really isn't that hard you know..

I'm sure it's not very hard, it's just tedious, if it's been done and re-done before countless times. Also, having to have separate code for GL and GLES is annoying. But I suppose I'll have to get there eventually, when the standard SDL renderer becomes not enough for my needs.

Yeah, I started SDL_gpu before we settled on SDL2's extra rendering APIs.  I haven't actually used them.  SDL_gpu does work for both GL and GLES without changes (though I haven't added any shader interfaces).

I was (am) a proponent of stripping out the SDL rendering API into a new satellite library.  It's not possible to get every subsystem to satisfy SDL's "simple" goal and still make everyone happy.  We shouldn't let anyone believe that the core SDL rendering API is as good as SDL can do, but some people get stuck using it until they find out it doesn't do what they need it to.  You'll hear it frequently that you should "just use OpenGL", so why build a biggish API into the core when you expect most users to replace it?


Jonny D




On Thu, Sep 5, 2013 at 8:22 AM, Tenoch wrote:

I guess the reason why SDL now has renderer functions is that before
everybody would complain about the fact you always needed to use
something else (which resulted in things like all of those being
redirected to things like SFML and such - though when I looked at SFML
I barfed immediately at how it handled the keyboard... yuck).

As for using integers: remember SDL_SetRenderLogicalSize was a
relatively late addition to SDL2, so don't be surprised everything was
made on the assumption only pixel-aligned coordinates would be used.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2013/9/6 Sik the hedgehog


Are you referring to the fact that any time you query a key status, SFML
makes a connection and roundtrip to the XServer? =P


And yeah, what SDL had before was even simpler (mostly software blitting).
In wake of the more complex renderer API, I too would be in favor of what
Jonathan described, ie. factoring it out into something like SDL_render.

2013/9/6, Jonas Kulla:

No, to the fact it used virtual key codes instead of scan codes
*facepalm* This rendered it unable to detect some keys, something
which I wasn't going to tolerate. That was idiotic. This was long time
ago so I assume (hope!) that may have changed since then.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Technically it could have been done better, but Valve presumably
wanted to use SDL pretty soon (and is currently paying Sam, which
makes things go MUCH faster than when he's busy job-hunting ), so
an official release was needed. API development won't stop here, this
is just where things were when the push-to-release was started.





Actually, it's more intended to "reduce the platform specific stuff" a
lot more than to serve as an introduction to graphics. And why would
the surface code get thrown away? As I best recall, it's actually used
in the software renderer.




Perhaps something like SDL_InvalidateRenderState() would work as the name?




Actually, if someone wanted to add a lower-level rendering api for
"extension code" to interface with, then THIS part of it would just be
a matter of copying the data from one instance of a SDL-specific
datastructure, into another. Any time you want to load another state
you hand the appropriate instance to the proper function, it compares
SDL's current state to the provided state, and changes what it needs
to. Any time you want to set some quirk of the state, you just call
the appropriate SDL function. It might even be possible to make it
work with DirectX, though I don't know the apis for that and thus
can't be certain.

The only real caveat with this approach is that code would need to be
written to use it, which might pose some problems with e.g. using Qt
in conjunction with SDL.



I do think that some sort of "extension api" (probably as an official
add-on library, and maybe as a "permanent beta") would be an excellent
idea. However, it would need to be designed.



Something I'd love to do some day is build a translating-compiler to
take some generic shading language and translate it to whatever target
language (I even know what I'd use for the software renderer: TCC),
but there's a catch: for shader support to be built-in, it probably
needs to work like how I just described. You'd probably need to write
a translating compiler to translate the SDL shader language to
whichever one your target renderer uses. This might be a small
project... but I wouldn't want to place any bets.



Well, in many ways, that IS it's primary purpose.




"Take" as in "as a list of arguments"? That would certainly be one approach.




Too late, and besides which, then people would complain that it isn't
a graphics library, because you can't do anything other than image
manipulation (and that only if surfaces got left in). You could point
them over to your fancy SDL_render library that's been pitched before,
but they'd already have a poor opinion (after all, if you've already
written it, then WHY is this FOUNDATIONAL capability not included?),
AND a large number would have already skipped it without visiting the
mailinglist or forums because they didn't see any mention of graphics
rendering, and thus wrote SDL off as little better than vaporware.
Ideally it would be mentioned on the front page, along with SDL_image,
etc., but not only are none of the other directly-affiliated libraries
given prominent billing, the entire "libraries" page seems to have
floated away in the website redesign.

No, having a restricted capability in SDL is better than not.
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

2013/9/7, Jared Maddox:

Almost nobody cares about the software renderer (I don't want it to go
away though, for 2D stuff it's still useful, especially since some
accessibility tools can't cope with programs that use the GPU).

However, surfaces are still used by SDL_image if I recall correctly,
and SDL_ttf as well. These days they aren't really meant to be used to
render directly, but rather as a somewhat "standard" way to pass
around bitmaps between libraries.


Yeah. Could also be just a single argument that's an OR of flags, each
flag indicating what got invalidated. Or it could be just a single
argument indicating what got invalidated, and then one could call the
function several times for each thing.

But yes, ultimately it would boil down to "pass it as arguments".


Really, can't we argue the same about all the satellite libraries? I
mean, I bet a lot of people wonder why isn't SDL_mixer built into the
core SDL library, when sound playback is a rather basic need for
multimedia applications, which are the main target of SDL (I don't
have issues skipping SDL_mixer and doing mixing on my own, but others
do...).
_______________________________________________
SDL mailing list

http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org