[Scummvm-devel] Replacing gBitFormat, OSystem::colorToRGB etc.
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/
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