I’ve read the documentation repeatedly and can’t figure out what this
function does. The docs say “Makes sure the given area is updated on the
given screen. The rectangle must be confined within the screen boundaries
(no clipping is done).”
I’m able to blit from a memory surface to a display surface without
calling this function. How does SDL_UpdateRect actually work, or how would
it operate or be used when I’m using an in-system memory backbuffer and
blitting deltas to a hardware surface?
Thanks in advance!
–>Neil-------------------------------------------------------------------------------
Neil Bradley What are burger lovers saying
Synthcom Systems, Inc. about the new BK Back Porch Griller?
ICQ #29402898 “It tastes like it came off the back porch.” - Me
you know im not quite sure about this one, but i know from a little bit of
windows (ewww) programming, when one window is partialy on top of another,
it wouldnt draw to the bottom window portion thats hidden and when it was
shown again it would invalidate that portion so that the next draw cycle it
would be updated even if there was nothing new to draw there. I dont think
thats 100% accurate but thats the general gist and perhaps this function
serves a similar purpose…ie you might be able to use SDL_UpdateRect to
make a portion of the screen not updated at the next draw cycle (for unknown
reasons) etc…
Just a shot in the dark
-Atrix> ----- Original Message -----
From: nb@synthcom.com (Neil Bradley)
To:
Sent: Thursday, July 25, 2002 1:34 PM
Subject: [SDL] SDL_UpdateRect
I’ve read the documentation repeatedly and can’t figure out what this
function does. The docs say “Makes sure the given area is updated on the
given screen. The rectangle must be confined within the screen boundaries
(no clipping is done).”
I’m able to blit from a memory surface to a display surface without
calling this function. How does SDL_UpdateRect actually work, or how would
it operate or be used when I’m using an in-system memory backbuffer and
blitting deltas to a hardware surface?
Thanks in advance!
–>Neil
Neil Bradley What are burger lovers saying
Synthcom Systems, Inc. about the new BK Back Porch Griller?
ICQ #29402898 “It tastes like it came off the back porch.” - Me
I’ve read the documentation repeatedly and can’t figure out what this
function does. The docs say “Makes sure the given area is updated on the
given screen. The rectangle must be confined within the screen
boundaries
(no clipping is done).”
I’m able to blit from a memory surface to a display surface without
calling this function. How does SDL_UpdateRect actually work, or how
would
it operate or be used when I’m using an in-system memory backbuffer and
blitting deltas to a hardware surface?
If the display surface is SDL_HWSURFACE, then you don’t have to call
SDL_UpdateRect(). You are drawing directly to (visible) video memory. If
you also set SDL_DOUBLEBUF, you have to call SDL_Flip() since you are
drawing to offscreen video memory. SDL_UpdateRect() does nothing if the
surface is a hardware surface, since it has nothing to do.
Otherwise, you have to call SDL_UpdateRects(). In this case, you are not
drawing directly to video memory, you are drawing to some offscreen
(system) memory area; hence, you must tell the windowing system to
display the new area on the display (visible video memory).
So, if you always call SDL_UpdateRects() you don’t have to worry about
the situation where you run a system that doesn’t have hardware
surfaces; your program will still work if the system you run on can’t
get a hardware surface. This is what everyone should do,
because it works on every supported platform, and gives the best chance
for portability of your app. Realize that on most targets you can’t even get a hardware surface to scribble on.</soap box>.
In all actuality, drawing in system memory and using SDL_UpdateRects()
can be faster for most applications because SDL_UpdateRects() can update
video memory more efficiently than you (or SDL’s blitters) can. There
are also serious performance penalties to blits that must read pixels
from the screen (alpha blits, in particular) when the SDL surface is in
video memory.
-DOn Thursday, July 25, 2002, at 03:34 PM, Neil Bradley wrote:
it operate or be used when I’m using an in-system memory backbuffer and
blitting deltas to a hardware surface?
If the display surface is SDL_HWSURFACE, then you don’t have to call
SDL_UpdateRect(). You are drawing directly to (visible) video memory.
Ah - how about windowed hardware surfaces? Does that still apply?
So, if you always call SDL_UpdateRects() you don’t have to worry about
the situation where you run a system that doesn’t have hardware
surfaces; your program will still work if the system you run on can’t
get a hardware surface. This is what everyone should do,
because it works on every supported platform, and gives the best chance
for portability of your app. Realize that on most targets you can’t even get a hardware surface to scribble on.</soap box>.
Okay - so to be fully compatible, I should be calling SDL_UpdateRects() on
the TARGET display surface - hardware or software surface, correct?
There is no need for SDL_UpdateRects() to be called on the source
(system memory) backbuffer, right?
–>Neil-------------------------------------------------------------------------------
Neil Bradley What are burger lovers saying
Synthcom Systems, Inc. about the new BK Back Porch Griller?
ICQ #29402898 “It tastes like it came off the back porch.” - Me