SDL_UpdatesRects - how to use it right

SDL Development
1

Hello there!

I’ve just created my first “bigger” SDL game in C (still barely 10
thousands line), and i found myself enjoying the optimalization more than
actually writing the game.

When I checked for the slowest part of it, SDL_Flip turned out to be an
undoubltable winner, on 1920*1080 resolution (and no HW_accel thanks to
some really fancy features that involves low level access, like pixel-depth
collision detection) SDL_Flip takes more time than all the other things in
my program together, every frame. And its not because I did something wrong
with DisplayFormats that would cause SDL to convert from different surface
types every frame, but even a simple program that initializes with 0 bpp
(which results 32), and SDL_ANYFORMAT|SDL_ASYNCBLIT flags do 1000 SDL_Flips
in 4.5 second which means, I can maximally reach 220 fps if i do nothing
else, yet my program runs with like 130 fps with 60 sprites (200 * 200)
doing crazy stuff on high definition background. Yeah i know 130 fps is
more than enough but still, this game has Playstation 1 like graphics and
is unplayably slow on an average laptop.

So that I decided to update only the parts that have changed on the map.
The changes cover about only the half of the screen, but usually there are
100-200 of them/frame. Also i have to count the places of the characters in
the last frame, because they are not there now, so I have to update those
too. But for this high number of rects, SDL_Flip is like 20% faster than
calling SDL_UpdateRects without any preoptimalization. (The capturing of
the rects is actually pretty smooth, if i just call SDL_UpdateRect on the
biggest area that covers all changes, i get like 10% performance increase
compared to not capturing them and calling SDL_Flip(), so the problem is
defeinitely inside SDL_UpdateRects).

But I just can’t get how to optimalize the about 300-400 rectangles. I
mean, with some simple programs, I figured out, that SDL_UpdateRects slow
down linearry to both the number of rects and the size of area covered.
Actually increasing the area with about 3500-4000 pixels has the same time
penalty than adding one new frame but covering exactly the same area.

From this comes a trivial optimalization algorithm, that if
with merging two rects the covered area increases by less than 3500 pixels,
the two rects should be merged, and if the intersection of two rects has
bigger area than 3500 pixels, one of the rects should be divided in to 3
parts, and the one that intersects should be ignored (like how SDL_BlitPool
does). But the problem is that everytime I merge or divide rects there may
become a new opportunity to optimalize between the rects I have already
checked and the newly created rect. And because of this, my algorithm will
either be by far slower than a bubble sort, and just slow down the program
even more than it was, or if I don’t fully run it just for ex. go through
all the elements let’s say 5 times, it won’t give out enough good results
and it will be still slow. And i just don’t have any time to make it run in
a thread. I mean the flip call happens just right after the last Blitting
is done, and my program still have to wait for the flip thread to end when
it wants to start Blitting in the next frame.

Any idea how to use it right?

Thanks in advance!

Yours faithfully
Tam?s Csala

2

First of all let’s solve the obvious problem, which is that you don’t
have hardware acceleration at all… Find a way to implement those
features you want without having to sacrifice hardware acceleration. I
bet you’re going to get a much bigger speed boost from that than from
messing with SDL_UpdateRects.

Is there any reason hardware acceleration gets in the way for you?

2013/3/15, Csala Tam?s :> Hello there!

I’ve just created my first “bigger” SDL game in C (still barely 10
thousands line), and i found myself enjoying the optimalization more than
actually writing the game.

When I checked for the slowest part of it, SDL_Flip turned out to be an
undoubltable winner, on 1920*1080 resolution (and no HW_accel thanks to
some really fancy features that involves low level access, like pixel-depth
collision detection) SDL_Flip takes more time than all the other things in
my program together, every frame. And its not because I did something wrong
with DisplayFormats that would cause SDL to convert from different surface
types every frame, but even a simple program that initializes with 0 bpp
(which results 32), and SDL_ANYFORMAT|SDL_ASYNCBLIT flags do 1000 SDL_Flips
in 4.5 second which means, I can maximally reach 220 fps if i do nothing
else, yet my program runs with like 130 fps with 60 sprites (200 * 200)
doing crazy stuff on high definition background. Yeah i know 130 fps is
more than enough but still, this game has Playstation 1 like graphics and
is unplayably slow on an average laptop.

So that I decided to update only the parts that have changed on the map.
The changes cover about only the half of the screen, but usually there are
100-200 of them/frame. Also i have to count the places of the characters in
the last frame, because they are not there now, so I have to update those
too. But for this high number of rects, SDL_Flip is like 20% faster than
calling SDL_UpdateRects without any preoptimalization. (The capturing of
the rects is actually pretty smooth, if i just call SDL_UpdateRect on the
biggest area that covers all changes, i get like 10% performance increase
compared to not capturing them and calling SDL_Flip(), so the problem is
defeinitely inside SDL_UpdateRects).

But I just can’t get how to optimalize the about 300-400 rectangles. I
mean, with some simple programs, I figured out, that SDL_UpdateRects slow
down linearry to both the number of rects and the size of area covered.
Actually increasing the area with about 3500-4000 pixels has the same time
penalty than adding one new frame but covering exactly the same area.

From this comes a trivial optimalization algorithm, that if
with merging two rects the covered area increases by less than 3500 pixels,
the two rects should be merged, and if the intersection of two rects has
bigger area than 3500 pixels, one of the rects should be divided in to 3
parts, and the one that intersects should be ignored (like how SDL_BlitPool
does). But the problem is that everytime I merge or divide rects there may
become a new opportunity to optimalize between the rects I have already
checked and the newly created rect. And because of this, my algorithm will
either be by far slower than a bubble sort, and just slow down the program
even more than it was, or if I don’t fully run it just for ex. go through
all the elements let’s say 5 times, it won’t give out enough good results
and it will be still slow. And i just don’t have any time to make it run in
a thread. I mean the flip call happens just right after the last Blitting
is done, and my program still have to wait for the flip thread to end when
it wants to start Blitting in the next frame.

Any idea how to use it right?

Thanks in advance!

Yours faithfully
Tam?s Csala

3

I’m running linux and i have never ever got hardware acceleration make any
difference in any of my programs. I wonder if its even working in SDL 1.2.5
on linux?
On Windows Hw_accel works really fine, I get 3 times better results than on
linux, but with this game, I just can’t have it.
I mean low level access is inevitable in one of the core features in the
game.

2013/3/15 Sik the hedgehog <sik.the.hedgehog at gmail.com>> First of all let’s solve the obvious problem, which is that you don’t

have hardware acceleration at all… Find a way to implement those
features you want without having to sacrifice hardware acceleration. I
bet you’re going to get a much bigger speed boost from that than from
messing with SDL_UpdateRects.

Is there any reason hardware acceleration gets in the way for you?

2013/3/15, Csala Tam?s <@Csala_Tamas>:

Hello there!

I’ve just created my first “bigger” SDL game in C (still barely 10
thousands line), and i found myself enjoying the optimalization more than
actually writing the game.

When I checked for the slowest part of it, SDL_Flip turned out to be an
undoubltable winner, on 1920*1080 resolution (and no HW_accel thanks to
some really fancy features that involves low level access, like
pixel-depth
collision detection) SDL_Flip takes more time than all the other things
in
my program together, every frame. And its not because I did something
wrong
with DisplayFormats that would cause SDL to convert from different
surface
types every frame, but even a simple program that initializes with 0 bpp
(which results 32), and SDL_ANYFORMAT|SDL_ASYNCBLIT flags do 1000
SDL_Flips
in 4.5 second which means, I can maximally reach 220 fps if i do nothing
else, yet my program runs with like 130 fps with 60 sprites (200 * 200)
doing crazy stuff on high definition background. Yeah i know 130 fps is
more than enough but still, this game has Playstation 1 like graphics and
is unplayably slow on an average laptop.

So that I decided to update only the parts that have changed on the map.
The changes cover about only the half of the screen, but usually there
are
100-200 of them/frame. Also i have to count the places of the characters
in
the last frame, because they are not there now, so I have to update those
too. But for this high number of rects, SDL_Flip is like 20% faster than
calling SDL_UpdateRects without any preoptimalization. (The capturing of
the rects is actually pretty smooth, if i just call SDL_UpdateRect on the
biggest area that covers all changes, i get like 10% performance increase
compared to not capturing them and calling SDL_Flip(), so the problem is
defeinitely inside SDL_UpdateRects).

But I just can’t get how to optimalize the about 300-400 rectangles. I
mean, with some simple programs, I figured out, that SDL_UpdateRects slow
down linearry to both the number of rects and the size of area covered.
Actually increasing the area with about 3500-4000 pixels has the same
time
penalty than adding one new frame but covering exactly the same area.

From this comes a trivial optimalization algorithm, that if
with merging two rects the covered area increases by less than 3500
pixels,
the two rects should be merged, and if the intersection of two rects has
bigger area than 3500 pixels, one of the rects should be divided in to 3
parts, and the one that intersects should be ignored (like how
SDL_BlitPool
does). But the problem is that everytime I merge or divide rects there
may
become a new opportunity to optimalize between the rects I have already
checked and the newly created rect. And because of this, my algorithm
will
either be by far slower than a bubble sort, and just slow down the
program
even more than it was, or if I don’t fully run it just for ex. go through
all the elements let’s say 5 times, it won’t give out enough good results
and it will be still slow. And i just don’t have any time to make it run
in
a thread. I mean the flip call happens just right after the last Blitting
is done, and my program still have to wait for the flip thread to end
when
it wants to start Blitting in the next frame.

Any idea how to use it right?

Thanks in advance!

Yours faithfully
Tam?s Csala

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Csala Tam?s

4

I would suggest using SDL 2.0 which takes advantage of hardware
acceleration (and completely changes the optimization areas.)

Cheers!On Fri, Mar 15, 2013 at 1:51 PM, Csala Tam?s wrote:

Hello there!

I’ve just created my first “bigger” SDL game in C (still barely 10
thousands line), and i found myself enjoying the optimalization more than
actually writing the game.

When I checked for the slowest part of it, SDL_Flip turned out to be an
undoubltable winner, on 1920*1080 resolution (and no HW_accel thanks to
some really fancy features that involves low level access, like pixel-depth
collision detection) SDL_Flip takes more time than all the other things in
my program together, every frame. And its not because I did something wrong
with DisplayFormats that would cause SDL to convert from different surface
types every frame, but even a simple program that initializes with 0 bpp
(which results 32), and SDL_ANYFORMAT|SDL_ASYNCBLIT flags do 1000 SDL_Flips
in 4.5 second which means, I can maximally reach 220 fps if i do nothing
else, yet my program runs with like 130 fps with 60 sprites (200 * 200)
doing crazy stuff on high definition background. Yeah i know 130 fps is
more than enough but still, this game has Playstation 1 like graphics and
is unplayably slow on an average laptop.

So that I decided to update only the parts that have changed on the map.
The changes cover about only the half of the screen, but usually there are
100-200 of them/frame. Also i have to count the places of the characters in
the last frame, because they are not there now, so I have to update those
too. But for this high number of rects, SDL_Flip is like 20% faster than
calling SDL_UpdateRects without any preoptimalization. (The capturing of
the rects is actually pretty smooth, if i just call SDL_UpdateRect on the
biggest area that covers all changes, i get like 10% performance increase
compared to not capturing them and calling SDL_Flip(), so the problem is
defeinitely inside SDL_UpdateRects).

But I just can’t get how to optimalize the about 300-400 rectangles. I
mean, with some simple programs, I figured out, that SDL_UpdateRects slow
down linearry to both the number of rects and the size of area covered.
Actually increasing the area with about 3500-4000 pixels has the same time
penalty than adding one new frame but covering exactly the same area.

From this comes a trivial optimalization algorithm, that if
with merging two rects the covered area increases by less than 3500 pixels,
the two rects should be merged, and if the intersection of two rects has
bigger area than 3500 pixels, one of the rects should be divided in to 3
parts, and the one that intersects should be ignored (like how SDL_BlitPool
does). But the problem is that everytime I merge or divide rects there may
become a new opportunity to optimalize between the rects I have already
checked and the newly created rect. And because of this, my algorithm will
either be by far slower than a bubble sort, and just slow down the program
even more than it was, or if I don’t fully run it just for ex. go through
all the elements let’s say 5 times, it won’t give out enough good results
and it will be still slow. And i just don’t have any time to make it run in
a thread. I mean the flip call happens just right after the last Blitting
is done, and my program still have to wait for the flip thread to end when
it wants to start Blitting in the next frame.

Any idea how to use it right?

Thanks in advance!

Yours faithfully
Tam?s Csala

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

5

I’ll try that, thanks!

2013/3/15 Sam Lantinga > I would suggest using SDL 2.0 which takes advantage of hardware

acceleration (and completely changes the optimization areas.)

Cheers!

On Fri, Mar 15, 2013 at 1:51 PM, Csala Tam?s <@Csala_Tamas> wrote:

Hello there!

I’ve just created my first “bigger” SDL game in C (still barely 10
thousands line), and i found myself enjoying the optimalization more than
actually writing the game.

When I checked for the slowest part of it, SDL_Flip turned out to be an
undoubltable winner, on 1920*1080 resolution (and no HW_accel thanks to
some really fancy features that involves low level access, like pixel-depth
collision detection) SDL_Flip takes more time than all the other things in
my program together, every frame. And its not because I did something wrong
with DisplayFormats that would cause SDL to convert from different surface
types every frame, but even a simple program that initializes with 0 bpp
(which results 32), and SDL_ANYFORMAT|SDL_ASYNCBLIT flags do 1000 SDL_Flips
in 4.5 second which means, I can maximally reach 220 fps if i do nothing
else, yet my program runs with like 130 fps with 60 sprites (200 * 200)
doing crazy stuff on high definition background. Yeah i know 130 fps is
more than enough but still, this game has Playstation 1 like graphics and
is unplayably slow on an average laptop.

So that I decided to update only the parts that have changed on the map.
The changes cover about only the half of the screen, but usually there are
100-200 of them/frame. Also i have to count the places of the characters in
the last frame, because they are not there now, so I have to update those
too. But for this high number of rects, SDL_Flip is like 20% faster than
calling SDL_UpdateRects without any preoptimalization. (The capturing of
the rects is actually pretty smooth, if i just call SDL_UpdateRect on the
biggest area that covers all changes, i get like 10% performance increase
compared to not capturing them and calling SDL_Flip(), so the problem is
defeinitely inside SDL_UpdateRects).

But I just can’t get how to optimalize the about 300-400 rectangles. I
mean, with some simple programs, I figured out, that SDL_UpdateRects slow
down linearry to both the number of rects and the size of area covered.
Actually increasing the area with about 3500-4000 pixels has the same time
penalty than adding one new frame but covering exactly the same area.

From this comes a trivial optimalization algorithm, that if
with merging two rects the covered area increases by less than 3500 pixels,
the two rects should be merged, and if the intersection of two rects has
bigger area than 3500 pixels, one of the rects should be divided in to 3
parts, and the one that intersects should be ignored (like how SDL_BlitPool
does). But the problem is that everytime I merge or divide rects there may
become a new opportunity to optimalize between the rects I have already
checked and the newly created rect. And because of this, my algorithm will
either be by far slower than a bubble sort, and just slow down the program
even more than it was, or if I don’t fully run it just for ex. go through
all the elements let’s say 5 times, it won’t give out enough good results
and it will be still slow. And i just don’t have any time to make it run in
a thread. I mean the flip call happens just right after the last Blitting
is done, and my program still have to wait for the flip thread to end when
it wants to start Blitting in the next frame.

Any idea how to use it right?

Thanks in advance!

Yours faithfully
Tam?s Csala

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org

–
Csala Tam?s

6

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.------------------------
Nate Fries

7

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 :> 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.

Nate Fries

8

[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 <@Nathaniel_J_Fries>:

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

9

Those games you mention just use collision boxes though, no per-pixel
collision :stuck_out_tongue: 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 :> [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 :

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

10

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.> 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

11

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 > > 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

12

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 :stuck_out_tongue:

2013/3/16, Csala Tam?s :> 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

Date: Fri, 15 Mar 2013 21:16:52 -0300
From: Sik the hedgehog <@Sik_the_hedgehog>
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