Sam,
If I “dance on the screen bitmap”, am I guaranteed that the onscreen
image will NOT be updated until I do an SDL_UpdateRect or UpdateRects
that copies the change over? Also, will UpdateRect(s) guarantee to
only update the specified rectangle or might it update more if it is
"convenient"?
The reason I ask is that these are documented as follows:
“Makes sure the given list of rectangles is updated on the given screen.”
That tells me that the screen might get updated even w/out an UpdateRect,
and that UpdateRect is there just to ensure it gets updated. (Sorta like
how fflush() ensures a stream is flushed, but parts of it may have been
flushed anyway, subject to internal buffering behavior, etc.)
Regards,
–Joe–
– Joseph Zbiciak | “You can listen to thunder after lightning –
– j-zbiciak1 at ti.com | and tell how close you came to getting –
– #include <std_disc.h> | hit. If you didn’t hear it, you got hit, –
– Texas Instruments, Dallas | so nevermind.” – Unknown –
If I “dance on the screen bitmap”, am I guaranteed that the onscreen
image will NOT be updated until I do an SDL_UpdateRect or UpdateRects
that copies the change over? Also, will UpdateRect(s) guarantee to
only update the specified rectangle or might it update more if it is
"convenient"?
The reason I ask is that these are documented as follows:
“Makes sure the given list of rectangles is updated on the given screen.”
That tells me that the screen might get updated even w/out an UpdateRect,
and that UpdateRect is there just to ensure it gets updated. (Sorta like
how fflush() ensures a stream is flushed, but parts of it may have been
flushed anyway, subject to internal buffering behavior, etc.)
Currently, if SDL_HWSURFACE is not set in the video flags, then your changes
to the screen will not be displayed until you call SDL_UpdateRects().
The semantics of SDL_HWSURFACE are that if the screen has the flag set,
then the display surface is in video memory, and all changes to the screen
memory will show up immediately. If a surface has SDL_HWSURFACE set, then
it too is in video memory, and presumably it has accelerated blit capability
and has slow memory access. However, these are hardware-related semantics
and will probably change as hardware changes. SDL_Flip() complicates things
even more: if the screen has SDL_HWSURFACE and SDL_DOUBLEBUF set, then
you are dealing with hardware double-buffered memory and all the rules change.
All of these flags must be specially requested in SDL_SetVideoMode(),
otherwise you get a software surface that needs to be updated normally.
So, the simple answer is: Yes, you are free to dance on the bitmap,
and changes will only show up when you call SDL_UpdateRects().
That’s maybe more than you wanted to know…
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/
[…lots of nitty gritty deleted…]
|
| So, the simple answer is: Yes, you are free to dance on the bitmap,
| and changes will only show up when you call SDL_UpdateRects().
Ok, and the slightly-less-short-but-still-very-brief-answer would be
"Changes will only show up when you call SDL_UpdateRects() if
either SDL_HWSURFACE is unset or SDL_DOUBLEBUF is set."
| That’s maybe more than you wanted to know…
It’s actually not too bad.
Mainly, I’m interested in whether I can use a painter’s algorithm type
of approach to certain display elements without fear of flickering,
etc. For instance, I intend to completely render the STIC in an
off-screen bitmap, but I intend to do things like “movable-object
boxing” (eg. putting boxes around sprites for debug purposes) by
drawing the rectangles directly in the screen bitmap before doing
the UpdateRects.
Ahh yes, nothing is pure, everything is hybrid.
Regards,
–Joe–
– Joseph Zbiciak | “You can listen to thunder after lightning –
– j-zbiciak1 at ti.com | and tell how close you came to getting –
– #include <std_disc.h> | hit. If you didn’t hear it, you got hit, –
– Texas Instruments, Dallas | so nevermind.” – Unknown –