renderCopy at floating point positions


renderCopy and renderCopyEx take integer values (in the rects) for positioning.
That means if you try to move things slowly and smoothly across the screen you get this jittering effect as the object jumps to the next pixel then waits to move again.

I think I’ve researched this as thoroughly as I can, and I’ve found two posts,
this on on stackoverflow, and this one here on this forum, and both of them come to the same conclusion: Underneath renderCopy, openGL takes floating point values, and so it should be trivial to modify SDL or to add a “renderCopyF” or something, but the rect structs are not public, so you really have to dig in and change things around, recompile everything, and lose compatibility in the process.

For my purposes I’ve found this to be a really silly and disappointing limitation of SDL.
So my question is, can we expect this feature anytime in the future?


I think SDL_Renderer is still “pixel-oriented” (as surfaces) and is not supposed to do such things. It is relatively simple blitting engine. If you do need really complex graphics you should use OpenGL directly.


What I was trying to express is that it seems to be in this case that it’s not so much a matter of keeping things simple, but more like just a gap in the interface.
I understand, of course, that for any more particular needs, developers are expected to produce their own tools, so I’m only suggesting this because I don’t think rendering to floating point positions is such a particular or complex need, and because (based on my research) it seems it would be trivial to implement, as the procedure on openGL’s end already takes floats.


The next version will have exactly that. “F” versions of all the 2D functions. Also slightly faster because there’s no int-to-float casting. These already exist in the latest source snapshot.


Ah! Great. Thank you for the good news!