[SDL] SDL_UpdatesRects - how to use it right

Csala Tamás tomius1994 at gmail.com
Sat Mar 16 04:18:04 PDT 2013

Thanks for the answers everyone!

When I said my program has low level accesses I wasn't so verbose. It
started with only per-pixel collision. But not for detecting hits, I still
use hit boxes for them, and it's definitely better for the gameplay
experience. The per-pixel CD was only for making characters unable to go
through each other. Maybe only I'm too dumb for it, but is was close to
impossible to do that with boxes and circles.

But after I found out how simple low access was, I started
to experience the possibilities with it, now objects get deformed upon
collision, if characters walk into fire they get burnt (their texture gets
changed), if they are hit they get bloody (the last too uses some particle
effects obviously). Altough Sik's idea would still work even with these, I
just had to create an Sw_surf copy for CD and an sw_surf "mask" for the
changes in the picture and a hw_surf mask for blitting the changes. And if
I were lucky my program wouldn't even explode on converting changes from
sw_surfs to hw_surfs (happily it wouldn't happen too often).

@However, my recommendation with regards to optimizing SDL_UpdateRects would
be to check for intersections with other rects each time you add a rect to
be updated; and then replace that rect with the union of the two rects. Some
extra pixels might get updated, but far less than the union of all the

The problem with that is that I capture rects with calling an own
BlitSurface that saves its parameters. But as far as its copying to the
screen it can not be run in the same time as the flip thread. So that it
has to be run in the main function's thread, therefore the slowdown in it
gets more crucial than the slowdown in the flip thread. But apart from
this, and even if I forget that I have 2 lists of rects to be updated, and
I only care about the changes in the current frame (this algorith only
opimalizes for only these) and forget the ones in the last frame it will
still be slow. This algorithm usually ends up with about 35-50 rectangles
(from the 200). But SDL_UpdateRects slows down with the number of rects
pretty fast, and the result will be slower than updating the whole screen.

By the way, I started using SDL 2.0. And I have to say, I like it so much
more than the SDL 1.2.5 that I don't even wanna go back to this project

Thanks for the replies again!


2013/3/16 Jared Maddox <absinthdraco at gmail.com>

> > Date: Fri, 15 Mar 2013 21:16:52 -0300
> > From: Sik the hedgehog <sik.the.hedgehog at gmail.com>
> > To: sdl at lists.libsdl.org
> > Subject: Re: [SDL] SDL_UpdatesRects - how to use it right
> > Message-ID:
> >       <CAEyBR+WWsi1gnQX=
> wxfbYCUnYyiO6WN-Jcm5ywFfP9YzUtg9OQ at mail.gmail.com>
> > Content-Type: text/plain; charset=UTF-8
> >
> > Pixel-level collision detection is something for which you'd want to
> > keep SDL out of it anyway (leave SDL to do the rendering and handle
> > collision without relying on it). I imagine the collision is done by
> > looking up the data in the surface?
> >
> > In any case what I'd do is keep two separate bitmaps: the one used to
> > render in SDL and the one used for collision (which can be even
> > optimized for the algorithm!). Yeah, there's some waste of space, but
> > seems like the easiest way to handle it.
> >
> Note that with render targets, there's even the possibility of using
> hardware acceleration for the collision detection.
> _______________________________________________
> SDL mailing list
> SDL at lists.libsdl.org
> http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

Csala Tamás
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130316/cb588a7a/attachment-0009.htm>

More information about the SDL mailing list