[SDL] SDL_UpdatesRects - how to use it right

Sik the hedgehog sik.the.hedgehog at gmail.com
Fri Mar 15 19:01:45 PDT 2013

Those games you mention just use collision boxes though, no per-pixel
collision :P Even fighting games, they have different collision boxes
for the body, and in fact they are given different "types" that
determine whether they are a normal part of the body, a part that's
blocking or a part that's attacking. They're quite more complex than
they seem - look up about the debug mode in the Street Fighter II
games to get an idea.

Anyway (back on per-pixel collision), another advantage of having a
separate collision mask is that it doesn't have to match the object to
which it belongs. Pretty useful for those places for which you don't
want collision at all even though they're visible (e.g. loose clothing
and such).

2013/3/15, Nathaniel J Fries <nfries88 at yahoo.com>:
> [quote="Sik"]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.
> 2013/3/15, Nathaniel J Fries <nfries88 at yahoo.com>:
>> Pixel-level collision detection might be less simple in SDL 2.0; but
>> aside
>> for that it should be a fairly straightforward switch.
>> 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
>> rects.
> Of course that is generally the right way to handle it anyway -- sometimes
> (such as fighting games, platformers, or action side-scrollers) you even
> need to identify the type of collision somehow (I myself have used 8-bit
> bitmaps as a sort of collision mask; just binary-AND the appropriate pixels
> together to determine just what type of collision it is [for example, one
> bit might mean its a "damageable" pixel, another might mean its an "attack"
> pixel, yet another might be a "bounce" pixel [for projectiles or bouncing
> pads], etc). But many games don't bother with this; for example for a simple
> mario-style platformer you only need to know whether or not the player is
> "falling" to determine the type of collision; and for a sonic-style
> platformer you only need to know whether or not the player is "spinning".
> ------------------------
> Nate Fries

More information about the SDL mailing list