renderCopy at floating point positions

#1

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?

#2

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.

#3

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.

#4

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.

#5

Ah! Great. Thank you for the good news!

#6

But how would it be possible to blit something at a floating point position? As far as I know, pixels emplacement are integers!

#7

Pixels have an area, and rasterization hardware (a GPU) decides whether a pixel is filled or not based on whether the geometry you render/blit touches the pixel center. GPU rasterization has sub-pixel precision.

If the GPU has enough information (e.g. with MSAA, although that’s not super relevant to SDL_Render’s API) it can know the fraction of the pixel that’s covered by the geometry you render, and then it can blend the color of what you rendered with the existing color of that pixel based on that coverage information.

More importantly, if an object moves smoothly at sub-pixel resolution across a group of pixels, the object’s texture coordinates also move smoothly, which means a given pixel can show a color that smoothly changes (especially if linear texture filtering is used) as the object’s fractional position changes.

#8

Wow. I never heard about that concept before.