[Scummvm-devel] Replacing gBitFormat, OSystem::colorToRGB etc.

Eugene Sandulenko sev at scummvm.org
Wed Apr 12 01:48:00 CEST 2006

On Mon, 10 Apr 2006 20:13:15 +0200
Max Horn <max at quendi.de> wrote:

> This API has a big disadvantage, too: It's slow by design. If you  
> need to use it for color fades, for example, you have to (1) call  
> OSystem::colorToRGB (a virtual method call, thus extremely slow),
> (2) play with the RGB data, (3) call OSystem::RGBToColor (another
> virtual method call). Ouch.
Ouch. Really ouch.

> This issue so far was pretty unimportant, but with the new GUI code,  
> we actually *want* to do pixel operations, like dimming or color  
> gradients. Due to the slow nature of colorToRGB etc., the new GUI  
> code was forced to introduce a color cache. But this causes new  
> problems: It takes lots of memory (a couple hundred kb), which is
> bad for low end devices. And it takes some time to compute it --
> which forced LordHoto to introduce a file cache for the color cache.
> Ouch again.
Yes, that is used for custom inactive dialog dimming now which can go
away in fact. However it will be difficult to avoid that in gradients.

> overlay). Similar in spirt to <http://www.libsdl.org/cgi/docwiki.cgi/ 
> SDL_5fPixelFormat>.
Sounds really good.

> In the future, beyond what we need now, I would like to change our  
> backends to allow direct access to the screen /overlay surfaces, *if  
> that's possible (not sure*), and also change our struct Surface to  
> use a pixelformat, too.
Afaik, all current backends use memory buffers for keeping the data, so
that could be possible.


More information about the Scummvm-devel mailing list