Stefanos A. wrote:
In short, this can be significantly faster:
use texture 1
use texture 1
…
use texture 2
use texture 2
…than this:
use texture 1
use texture 2
use texture 1
use texture 2
…
Wait, so I’m still confused. Does it matter whether I’m using an atlas or individual textures in the case of SDL? Or is it merely an issue of providing one copy command after another in single file rather than interrupting it with intermediate commands?
Can I get some consensus here? Because it seems like there’s some debate whether sprite-batching with texture atlases would have any performance benefit at all with SDL, because (according to some but not others) it wouldn’t be operating at a low enough level to bypass a lot of the state changes.
Sprite batching with texture atlases in raw OpenGL would have a performance benefit.? Doing it with SDL render calls would not, because SDL doesn’t support sprite batching.
I tried to bring up the subject a few months ago, but implementing it properly would have required adding a parameter to SDL_RenderCopy, and folks said “no, we can’t do that; the ABI is frozen.”
Mason________________________________
From: mattbentley
To: sdl at lists.libsdl.org
Sent: Friday, October 25, 2013 2:21 AM
Subject: Re: [SDL] Surface vs Texture - optimal usage
Can I get some consensus here? Because it seems like there’s some debate whether sprite-batching with texture atlases would have any performance benefit at all with SDL, because (according to some but not others) it wouldn’t be operating at a low enough level to bypass a lot of the state changes.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Well, 2.x is out. If you’ve got a compelling argument to ADD to the
ABI, patches are useful. But it’s too late to change it.
JosephOn Fri, Oct 25, 2013 at 05:31:59AM -0700, Mason Wheeler wrote:
Sprite batching with texture atlases in raw OpenGL would have a performance benefit.? Doing it with SDL render calls would not, because SDL doesn’t support sprite batching.
I tried to bring up the subject a few months ago, but implementing it properly would have required adding a parameter to SDL_RenderCopy, and folks said “no, we can’t do that; the ABI is frozen.”
Message-ID: <1382692901.m2f.40186 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”Can I get some consensus here? Because it seems like there’s some debate
whether sprite-batching with texture atlases would have any performance
benefit at all with SDL, because (according to some but not others) it
wouldn’t be operating at a low enough level to bypass a lot of the state
changes.
Even if it doesn’t help, the only way that it can hurt is if you use
atlases that are too large. The solution to that is just to use
smaller atlases, so no big deal. Whether any of the overhead gets
bypassed will tend to depend on two things:
Also, sprite batching and texture atlases can benefit you when using
OpenGL, so if you decide that the Renderer api isn’t powerful enough
afterwards, you’ll already have the code in the right basic structure
for what you’ll wind up moving to.
All in all, I would recommend sprite batching + texture atlases for
most uses. If you just make certain to support more than one texture
atlas, you should be covered for the range of actual problems that you
might meet.> Date: Fri, 25 Oct 2013 09:21:41 +0000
From: “mattbentley”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Surface vs Texture - optimal usage
Date: Fri, 25 Oct 2013 05:31:59 -0700 (PDT)
From: Mason Wheeler
To: “sdl at lists.libsdl.org”
Subject: Re: [SDL] Surface vs Texture - optimal usage
Message-ID:
<1382704319.20830.YahooMailNeo at web122505.mail.ne1.yahoo.com>
Content-Type: text/plain; charset=“iso-8859-1”Sprite batching with texture atlases in raw OpenGL would have a
performance benefit.? Doing it with SDL render calls would not, because SDL
doesn’t support sprite batching.I tried to bring up the subject a few months ago, but implementing it
properly would have required adding a parameter to SDL_RenderCopy, and folks
said “no, we can’t do that; the ABI is frozen.”
As I best recall, we had to repeat it multiple times before you
actually paid attention (or maybe it was in multiple threads?).
Extensions aren’t a problem, but changes to existing APIs was already
officially barred by the time that you even made the proposal.
The biggest problem, though, was that your vision of how the API
should work (which was rather akin to Netscape’s Layer tag) was
incompatible with how the API was actually intended to work (each call
on top of the previous one). As Forest mentioned at the time (yes, I
looked it up), in a 2d graphics API the implication is that your
draw-order is sacred. I myself mentioned a way to adapt your idea to
the actual API by using dirty rect checking for the sake of flushing
when it was needed.
However, you couldn’t seem to accept any version other than the one
that you were suggesting (which was a non-starter). There was never
any opposition to faster rendering, only to your particular
implementation. If you want to implement Nathaniel’s
SDL_RenderCopyMulti() function (
http://forums.libsdl.org/viewtopic.php?p=36668#36668 ) then I don’t
think you’ll have trouble getting it into the code base, but your
particular solution was already unacceptable by that point, and you
would have realized it if you’d slowed down long enough to think about
it. “The ABI is frozen” is genuinely enough reason to keep anything
conflicting out, “3x faster than the current system” is not enough
reason for inclusion if it goes against ABI compatibility, which your
suggestion did.
Jared Maddox wrote:
Even if it doesn’t help, the only way that it can hurt is if you use
atlases that are too large. The solution to that is just to use
smaller atlases, so no big deal. Whether any of the overhead gets
bypassed will tend to depend on two things:
- Whether the render api gets optimized at some point in the future
(I don’t think this is on the agenda, but there has been a discussion
on how to do it: it is possible without API breakage),- Whether the total size of your textures is too large for the memory
of the GPU.
Either of these is enough to make sprite-batching (and, for the most
part, texture atlases) a genuine optimization. Will you get the full
speed-up that Mason talks about? No, but Mason’s method isn’t actually
compatible with the SDL render API (it breaks some of the rules that
renderer implementations need to follow), and was never going to be
part of SDL (it’s less a 2d rendering technique, and more a 2.5d
technique).Also, sprite batching and texture atlases can benefit you when using
OpenGL, so if you decide that the Renderer api isn’t powerful enough
afterwards, you’ll already have the code in the right basic structure
for what you’ll wind up moving to.
I have two main case scenarios:
Given that it’s not making multiple renders of the same texture, would texture atlasing speed anything up in this case?
BTW, thanks for the detailed explanation Jarod 
2013/10/27 mattbentley
I have two main case scenarios:
- Using large prerendered backgrounds which scroll.
- Using multiple copies of the same sprite, but at different phases of
their walk-cycle, ie. different textures.Given that it’s not making multiple renders of the same texture, would
texture atlasing speed anything up in this case?
What? Please don’t tell me you create a texture for each animation frame.
You are supposed to leave all animation frames of a character/whatever
in one bitmap/texture and then just use a different source rectangle when
drawing each frame.
Jonas Kulla wrote:
What? Please don’t tell me you create a texture for each animation frame.
You are supposed to leave all animation frames of a character/whatever
in one bitmap/texture and then just use a different source rectangle when
drawing each frame.
There’s no ‘supposed’ to about it. That’s the way you in particular want to do it, that’s absolutely fine. There are many reasons why you could choose not to do that. And by the sounds of it there’s no performance difference in either case with SDL, as what you’re talking about is small-scale texture-atlasing for your sprites.
At any rate, I was using ‘texture’ in the generic sense here, as in, ‘different pictures’, with no reference as to how those pictures would be stored…
2013/10/27 mattbentley
**
Jonas Kulla wrote:
What? Please don’t tell me you create a texture for each animation frame.
You are supposed to leave all animation frames of a character/whatever
in one bitmap/texture and then just use a different source rectangle when
drawing each frame.There’s no ‘supposed’ to about it. That’s the way you in particular want
to do it, that’s absolutely fine. There are many reasons why you could
choose not to do that. And by the sounds of it there’s no performance
difference in either case with SDL, as what you’re talking about is
small-scale texture-atlasing for your sprites.
At any rate, I was using ‘texture’ in the generic sense here, as in,
‘different pictures’, with no reference as to how those pictures would be
stored…
There’s no ‘supposed’ to about it. That’s the way you in particular want
to do it, that’s absolutely fine.
Yeah but then don’t ask “how do I make this faster”.
There are many reasons why you could choose not to do that.
Such as?
And by the sounds of it there’s no performance difference in either case
with SDL, as what you’re talking about is small-scale texture-atlasing for
your sprites.
It’s not even about performance. Why would you want to deal with multiple
textures if you can have just one.
At any rate, I was using ‘texture’ in the generic sense here, as in,
‘different pictures’, with no reference as to how those pictures would be
stored…
You said “ie. different textures”. There is no ambiguity in the word
"texture",
no “general sense”.
Message-ID: <1382834953.m2f.40207 at forums.libsdl.org>
Content-Type: text/plain; charset=“iso-8859-1”
I have two main case scenarios:
- Using large prerendered backgrounds which scroll.
- Using multiple copies of the same sprite, but at different phases of
their walk-cycle, ie. different textures.Given that it’s not making multiple renders of the same texture, would
texture atlasing speed anything up in this case?
At the moment, probably not (though if you have enough textures for
them to spill out of GPU memory into wherever else the driver can
store them, then maybe so: that particular sub-case lends itself to
corner-cases), but I advise implementing support anyways. The support
should be quite cheap (both in implementation effort and in
maintenance/support), and implementing right at the start should save
you from ever having to do a lot of unexpected changes later on.
Also, it can make it easier to deal with sprites if they’re all in the
same file, so you’ll be wanting this sooner or later anyways. Doubly
so if someone else winds up using the same engine later.
Still, there is a limit on how much this can help right now (and it’s
a pretty massive limit). If someone gets around to implementing a
MultiRender function then you’ll be in a position to benefit
massively, but for the moment it buys you little, when it buys you
anything.> Date: Sun, 27 Oct 2013 00:49:13 +0000
From: “mattbentley”
To: sdl at lists.libsdl.org
Subject: Re: [SDL] Surface vs Texture - optimal usage
Jonas Kulla wrote:
Yeah but then don’t ask “how do I make this faster”.
You’re not making any sense here buddy, come back without the chip on your shoulder.
Jared Maddox wrote:
Still, there is a limit on how much this can help right now (and it’s
a pretty massive limit). If someone gets around to implementing a
MultiRender function then you’ll be in a position to benefit
massively, but for the moment it buys you little, when it buys you
anything.
Thanks again Jared, for making sense of this!
Matt