I’m using SDL_SetColors() to do palette animation in my project. Since
this is a reverse-
engineering attempt at a game (Ultima7) that’s in 8-bit color, I’m
always asking SDL for an
8-bit surface, and letting it do the conversion to the hardware color
depth when I blit with SDL_UpdateRects (and it does quite a quick job of
it too!).
Of course, when the hardware depth > 8-bits, I assume SDL_SetColors()
has to automatically do a blit to make the new colors appear. Am I
correct in this assumption? If so, it would be nice to know when this
happens, so I can skip an extraneous blit() demanded by other game
events.
Perhaps there should be another function (SDL_StoreColors()?) that
doesn’t do the blit, but just returns a flag saying whether a call to
SDL_UpdateRects() is needed.
Jeff Freedman wrote:
I’m using SDL_SetColors() to do palette animation in my project. Since
this is a reverse-
engineering attempt at a game (Ultima7) that’s in 8-bit color, I’m
always asking SDL for an
8-bit surface, and letting it do the conversion to the hardware color
depth when I blit with SDL_UpdateRects (and it does quite a quick job of
it too!).
Of course, when the hardware depth > 8-bits, I assume SDL_SetColors()
has to automatically do a blit to make the new colors appear. Am I
correct in this assumption?
Yes, absolutely.
If so, it would be nice to know when this
happens, so I can skip an extraneous blit() demanded by other game
events.
It happens somewhere inside of SDL_SetColors(), so AFAIK after calling
SDL_SetColors() you can skip all pending updates. Of course it is only applies
to the case when hardware color depth > 8bpp, so you have to distinguish it
somehow.
Perhaps there should be another function (SDL_StoreColors()?) that
doesn’t do the blit, but just returns a flag saying whether a call to
SDL_UpdateRects() is needed.
Sounds like a good idea.
-Maxim