SDL_RenderCopyEx taking integer arguments

SDL Development
1

… 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:

[Image: http://i.imgur.com/Ah99rpR.png ]

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 :slight_smile:

2

2013/9/4 Tenoch <falzon.noe at gmail.com>

**
… 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 [image: Smile]

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.

3

I have been working on SDL_gpu (Google Code Archive - Long-term storage for Google Code Project Hosting.) as an
alternative rendering API wrapping OpenGL. It’s an option for use,
reference, or contribution.

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

2013/9/4 Tenoch <falzon.noe at gmail.com>

**
… 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 [image: Smile]

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 :slight_smile:

–
Gabriel.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

4

2013/9/4, Gabriel Jacobo :

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 :slight_smile:

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.

5

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:

and this:
OpenGL Discussion and Help Forums 9/4/2013 12:25 PM, Tenoch wrote:

… 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
tionhe 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 Smile

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Pallav Nawani
Game Designer/CEO

Twitter: x.com
Facebook: Ironcode Gaming

6

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 :slight_smile: 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” :slight_smile:

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(3320.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.

7

2013/9/5 Tenoch <falzon.noe at gmail.com>

**
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 [image: Smile] 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” [image:
Smile]

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(3320.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.

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…

8

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.

9

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 DOn Thu, Sep 5, 2013 at 8:22 AM, Tenoch <falzon.noe at gmail.com> wrote:

**
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.

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

10

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.

11

2013/9/6 Sik the hedgehog <sik.the.hedgehog at gmail.com>

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).

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.

12

2013/9/6, Jonas Kulla :

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

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.

13

Message-ID: <1378369163.m2f.39136 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

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 :slight_smile: 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” :slight_smile:

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 :slight_smile: ), 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.> Date: Thu, 05 Sep 2013 08:19:23 +0000

From: “Tenoch” <falzon.noe at gmail.com>
To: sdl at lists.libsdl.org
Subject: Re: [SDL] SDL_RenderCopyEx taking integer arguments…

Date: Thu, 5 Sep 2013 12:26:18 +0200
From: Jonas Kulla
To: SDL Development List
Subject: Re: [SDL] SDL_RenderCopyEx taking integer arguments…
Message-ID:
<CAK0i_72s56+focnRW2NQ9LVkfb9T77LV1kR1rcmtJ4f2UgTPow at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

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.

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.

Date: Thu, 5 Sep 2013 14:12:27 -0700 (PDT)
From: Mason Wheeler
To: SDL Development List
Subject: Re: [SDL] Mixing opengl and renderer?
Message-ID:
<1378415548.85568.YahooMailNeo at web122502.mail.ne1.yahoo.com>
Content-Type: text/plain; charset=“iso-8859-1”

Yes please.? There are several annoying little hacks I could take out of my
codebase if I had a SDL_PushRenderState() and SDL_PopRenderState(), or a
SDL_DeleteCachedRenderStateData() (needs a better name) at my disposal.

Mason

From: Sam Lantinga
To: SDL Development List
Sent: Thursday, September 5, 2013 12:18 PM
Subject: Re: [SDL] Mixing opengl and renderer?

It seems like that’s something we could do in SDL 2.0.1 if people are
interested.? Adding APIs in a minor revision is fine.

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

Date: Thu, 05 Sep 2013 23:01:46 +0000
From: “Sparks”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Mixing opengl and renderer?
Message-ID: <1378422106.m2f.39164 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”

Mason Wheeler wrote:

Looking at this code, I don’t see any reason why it should be expensive. A
simple linked list-based stack is trivial.

If you need to save all/most openGL states, not to mention all the matrix
modes, it becomes very expensive and if you have redundant state changes, it
becomes really, really messy.
Sure, a linked-list stack is trivial, but, saving & restoring a openGL state
is not a simple process, it must hit the driver to perform the task.
AFAIK the openGL video driver assumes people don’t do redundant state
changes, so when it gets a state change, it marks everything dirty, and it
does work to reset the dirty bit, which takes a long time which is why the
driver guys says don’t do it–ever!

That is why I said, it would be better to leave SDL2 out of this, and
continue to do what it does best (setup windows/screen/input/etc)

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.

It seems to me what we really need is a way to override SDL2’s built in
stuff, and supply our own routines that do whatever (like using shaders on
SDL2’s draw routines),

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.

or just have some kind of built in shader support
that we can turn on/off based on what we are drawing.

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.

Then again, it is
just easier to go full openGL to draw everything you need, and leave SDL 2
out of everything except creating the window/screen.

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

Date: Thu, 5 Sep 2013 21:28:07 -0300
From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
To: Mason Wheeler , SDL Development List

Subject: Re: [SDL] Mixing opengl and renderer?
Message-ID:
<CAEyBR+Ugy68Q=6aNAj4ozrs3P6XB+pKUC2XhgwynQBqToJ9rFw at mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

Or if you want to avoid all that (no idea how expensive querying the
state is!), you could just make the reset function take which stuff
was invalidated (taking this idea from how GCC handles clobbering with
inline asm, also how I implemented a ResetVideoEx function some days
ago for some framework).

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

Date: Fri, 6 Sep 2013 11:18:08 +0200
From: Jonas Kulla
To: SDL Development List
Subject: Re: [SDL] SDL_RenderCopyEx taking integer arguments…
Message-ID:
<CAK0i_71xmFS8CNtnd4g2uX21x9ky1uKViCovFirc9DdKKsvAVw at mail.gmail.com>
Content-Type: text/plain; charset=“iso-8859-1”

2013/9/6 Sik the hedgehog <sik.the.hedgehog at gmail.com>

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).

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.

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.

14

2013/9/7, Jared Maddox :

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.

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.

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

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”.

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?),

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…).