I’m not familiar enough with graphics API’s to know this question, less so for SDL-
you can copy a texture to -10, -20 as x, y,
will it make a performance difference if you
(a) check whether the entire texture is going to be offscreen and therefore not render it?
(b) if it’s partially onscreen, only copy the Rect which is onscreen rather than the whole thing?
Or will SDL more or less do the exact same thing in it’s backend, pretty much duplicating the effort?
This may be something than on a SDL dev can answer…
The best advice is to do what wastes the least of your time. Worry about
performance if performance ever becomes a legitimate concern.
But to answer the questions…
(a) Checking to see if a sprite will be offscreen is a pretty simple
calculation (only a little less simple if it’s being drawn rotated). As
the user of SDL, you have the most info about which things are being drawn
and where, so you should cull these sprites before SDL has to do even more
calculations that end up drawing nothing.
(b) If the sprite is partially offscreen, SDL will handle it just as well
as you could by clipping the rect. The clipping code will run even if you
pass in a pre-clipped rect, so you don’t really gain anything by doing it
yourself.
Jonny DOn Wed, Oct 23, 2013 at 1:15 AM, mattbentley wrote:
**
I’m not familiar enough with graphics API’s to know this question, less so
for SDL-
you can copy a texture to -10, -20 as x, y,
will it make a performance difference if you
(a) check whether the entire texture is going to be offscreen and
therefore not render it?
(b) if it’s partially onscreen, only copy the Rect which is onscreen
rather than the whole thing?
Or will SDL more or less do the exact same thing in it’s backend, pretty
much duplicating the effort?
This may be something than on a SDL dev can answer…
Oh, and in case you haven’t used one before, many people use spatial
partitioning algorithms/containers to cull sprites. An octree is a common
example.
Jonny DOn Wed, Oct 23, 2013 at 1:57 AM, Jonathan Dearborn <@Jonathan_Dearborn>wrote:
The best advice is to do what wastes the least of your time. Worry about
performance if performance ever becomes a legitimate concern.
But to answer the questions…
(a) Checking to see if a sprite will be offscreen is a pretty simple
calculation (only a little less simple if it’s being drawn rotated). As
the user of SDL, you have the most info about which things are being drawn
and where, so you should cull these sprites before SDL has to do even more
calculations that end up drawing nothing.
(b) If the sprite is partially offscreen, SDL will handle it just as well
as you could by clipping the rect. The clipping code will run even if you
pass in a pre-clipped rect, so you don’t really gain anything by doing it
yourself.
Jonny D
On Wed, Oct 23, 2013 at 1:15 AM, mattbentley wrote:
**
I’m not familiar enough with graphics API’s to know this question, less
so for SDL-
you can copy a texture to -10, -20 as x, y,
will it make a performance difference if you
(a) check whether the entire texture is going to be offscreen and
therefore not render it?
(b) if it’s partially onscreen, only copy the Rect which is onscreen
rather than the whole thing?
Or will SDL more or less do the exact same thing in it’s backend, pretty
much duplicating the effort?
This may be something than on a SDL dev can answer…
(a) Checking to see if a sprite will be offscreen is a pretty simple calculation (only a little less simple if it’s being drawn rotated). ?As the user of SDL, you have the most info about which things are being drawn and where, so you should cull these sprites before SDL has to do even more calculations that end up drawing nothing.
(b) If the sprite is partially offscreen, SDL will handle it just as well as you could by clipping the rect. ?The clipping code will run even if you pass in a pre-clipped rect, so you don’t really gain anything by doing it yourself.