SDL ... clip rect lists?
Author
Does a 'clip rectangle list' system exist for SDL? I've been googl'ing for a while now, and haven't come up with anything solid. It'd be real handy for my GUI window renderer to not have to unnecessarily overdrawn controls.
I guess this would mean a change to the core SDL code, since any other means would be bogus and useless (if one wanted to maintain double-buffered flipping functionality), so unless some hardcore coder went and did us all a favor, I guess it looks like it'll stay the way it is :)
[Edited by - MatrixCubed on March 26, 2005 5:52:03 PM]
Yes, take a look at SDL_SetClipRect. Is that what you are looking for? I don't know if there is a way to use multiple clipping rects on the same surface though. If you think about that, it would just require way more processing and by that time the user could do it themselves.
Author
Oops, I guess I should have mentioned I was aware of SDL_SetClipRect. What I meant was, since it only permits one rect to be assigned to a surface, hence it's relatively useless when one is building up a surface comprised of many rects :)
I figured it would at least save a bit of overdraw, especially when the screen size gets upward of 1024x768 and there's an overdraw factor of 1.5+ ... probably easier on the frame rate, to do a little arithmetic than blit thousands of bytes of pixel data ;)
I figured it would at least save a bit of overdraw, especially when the screen size gets upward of 1024x768 and there's an overdraw factor of 1.5+ ... probably easier on the frame rate, to do a little arithmetic than blit thousands of bytes of pixel data ;)
[smile] Wait a minute, what are you taking as overdraw then? If you set the clip rect on the main screen, only that portion will be blitted to. Can you explain why you need multiple clip rects?
Author
Well let's say that I am drawing a standard "OK | Cancel" dialog.
Right now I draw back-to-front. I'd blit the main dialog window bitmap to the back buffer, then two buttons on top of that.
Ideally what would be feasable is to reverse-draw... blit the button, then add their visible rects to the master clip list. Then blit the dialog bitmap, omitting the two rects for the buttons, then add its rect to the master list. Then anything else drawn to the screen, gets blitted around this dialog clip rect.
Does that make sense? Maybe my logic is b0rked.
Right now I draw back-to-front. I'd blit the main dialog window bitmap to the back buffer, then two buttons on top of that.
Ideally what would be feasable is to reverse-draw... blit the button, then add their visible rects to the master clip list. Then blit the dialog bitmap, omitting the two rects for the buttons, then add its rect to the master list. Then anything else drawn to the screen, gets blitted around this dialog clip rect.
Does that make sense? Maybe my logic is b0rked.
That makes sense now. I cannot follow the proper order of drawing, so how about trying this out:
Set clip rect of screen with proper rect
blit the button
Set clip rect of screen with proper rect
blit the dialog bitmap
Set clip rect of screen with proper rect
Then anything else drawn to the screen
So basically, you set the clip rect of the main surface, then you blit to it. When you want to do another control, you just set the new blit rect and then blit to the main surface again. Since you've already blitted to the screen with a clip rect, the contents will still be there. You just do this down the line, basically simulating the process of blit lists - you just break it down and do it on a per object basics rather than all at once.
How does that sound?
Set clip rect of screen with proper rect
blit the button
Set clip rect of screen with proper rect
blit the dialog bitmap
Set clip rect of screen with proper rect
Then anything else drawn to the screen
So basically, you set the clip rect of the main surface, then you blit to it. When you want to do another control, you just set the new blit rect and then blit to the main surface again. Since you've already blitted to the screen with a clip rect, the contents will still be there. You just do this down the line, basically simulating the process of blit lists - you just break it down and do it on a per object basics rather than all at once.
How does that sound?
Author
That would work, except I'm afraid it would only allow for one top-most dialog to exist; otherwise any other top-level dialogs would be helplessly and mercilessly plowed over by the blitter :-)
I've set up a hierarchy as follows:
Lvl1) desktop window: parent window of all
|
+--- Lvl2) dialog "level", where main GUI windows exist; can be dragged around screen
So if more than one Lvl2 dialog exists, the clip rect can only "protect" one of them at a time.
I've set up a hierarchy as follows:
Lvl1) desktop window: parent window of all
|
+--- Lvl2) dialog "level", where main GUI windows exist; can be dragged around screen
So if more than one Lvl2 dialog exists, the clip rect can only "protect" one of them at a time.
Ok I see. What you may want to do is take a look at SDL_Gui and see what they did. Maybe you could find something of use there. I've never used it before though. Or perhaps take a look at using SDL_UpdateRects to somehow achieve what you are doing for, just some ideas.
Author
I'll have to take a look at it. SDL_GUI is actually on a list of things I've investigated, but I nerfed it due to its layout and lack of features.
I'm progressing rather well as it is, moving on to buttons tonight. :)
I'm progressing rather well as it is, moving on to buttons tonight. :)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
