I’m doing some work on TuxType for GSoC and running into some problems with
its blit queue. Basically, it’s a dirty blitting system that was originally
adapted from an example by Sam Lantinga. I don’t think this code has been
touched in a long time, but it just works :). It’s now being moved into a
shared library and causing some hiccups, though–a segfault in a call to
SDL_LowerBlit, to be precise. This raises some caution flags, because the
function is documented as “semi-private.” I think the actual problem is some
silly oversight on my part, but here’s my question: is dirty blitting still
worthwhile? I recall hearing a few times that on modern hardware, it’s
actually less efficient than updating the entire screen. Can somebody
confirm/deny?
I’ve seen a benefit for a small number of sprites (<12) on Linux, but on
Windows for some reason I was getting a huge benefit even for a large number
of sprites (~100) using a dirty rect system. Now, if TuxType ever moves to
SDL 1.3’s texture API, then it might not be worth it.
Jonny DOn Fri, Jul 9, 2010 at 1:49 PM, Brendan Luchen wrote:
Hi all,
I’m doing some work on TuxType for GSoC and running into some problems with
its blit queue. Basically, it’s a dirty blitting system that was originally
adapted from an example by Sam Lantinga. I don’t think this code has been
touched in a long time, but it just works :). It’s now being moved into a
shared library and causing some hiccups, though–a segfault in a call to
SDL_LowerBlit, to be precise. This raises some caution flags, because the
function is documented as “semi-private.” I think the actual problem is some
silly oversight on my part, but here’s my question: is dirty blitting still
worthwhile? I recall hearing a few times that on modern hardware, it’s
actually less efficient than updating the entire screen. Can somebody
confirm/deny?
You can use the dirty rect system with SDL_UpperBlit(), and if that
works it means that you’re not clipping the surfaces properly before
passing them to SDL_LowerBlit().
As for whether it’s still useful, as long as you’re doing software
updates then dirty rects will always be useful, depending on your
usage patterns. If you’re using the SDL 1.3 texture APIs, then
everything is handled for you. :)On Fri, Jul 9, 2010 at 1:49 PM, Brendan Luchen wrote:
Hi all,
I’m doing some work on TuxType for GSoC and running into some problems with
its blit queue. Basically, it’s a dirty blitting system that was originally
adapted from an example by Sam Lantinga. I don’t think this code has been
touched in a long time, but it just works :).? It’s now being moved into a
shared library and causing some hiccups, though–a segfault in a call to
SDL_LowerBlit, to be precise. This raises some caution flags, because the
function is documented as “semi-private.” I think the actual problem is some
silly oversight on my part, but here’s my question: is dirty blitting still
worthwhile? I recall hearing a few times that on modern hardware, it’s
actually less efficient than updating the entire screen. Can somebody
confirm/deny?
Thanks for your time,
Brendan
