[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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130315/6cc06728/attachment-0009.htm>