[SDL] SDL_UpdatesRects - how to use it right

Sik the hedgehog sik.the.hedgehog at gmail.com
Sat Mar 16 12:00:59 PDT 2013


If you don't like the old code anymore you may want to figure out ways
to avoid those pitfalls from the get-go if you decide to restart it
with SDL2. May also help to make the whole thing cleaner :P

2013/3/16, Csala Tamás <tomius1994 at gmail.com>:
> 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
> rects.
>
> 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
> anymore.
>
> Thanks for the replies again!
>
> Cheers!
>
> 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
>



More information about the SDL mailing list