[SDL] SDL_UpdatesRects - how to use it right

Csala Tamás tomius1994 at gmail.com
Fri Mar 15 14:06:04 PDT 2013


I'll try that, thanks!

2013/3/15 Sam Lantinga <slouken at libsdl.org>

> 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 <tomius1994 at gmail.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20130315/4ee06a56/attachment-0009.htm>


More information about the SDL mailing list