[Scummvm-devel] Bitdepth/pixel format API concerns

[J Northup]

On Thu, Jun 11, 2009 at 7:08 AM, Max Horn <max at quendi.de> wrote:

>
> So far, I see no actual cons to using Graphics::PixelFormat -- I think
> LordHoto refuted all claims otherwise so far. Maybe we miss something,
> though -- then I'd like to hear concrete arguments, though ;).
>
>
> Bye,
> Max
>


Sigh, I should have made a posting to the list right after the conversation
LordHoto and I had on IRC wednesday night.
The cons to using Graphics::PixelFormat are
1) It is overkill -- it easily allows engines to specify a format that is
completely impossible, by mistake
2) It requires the engine to specify color order, meaning that a minor
oversight on the part of the engine developer could result in it being
unusable on all backends with a different color order.
3) Additionally, the wide range of color orders that the engine could
potentially request necessitate a great deal of sanity checking on the part
of engines that only support one.
4) Setting up a Graphics::PixelFormat structure takes a minimum of 8 lines
of code per structure. Engines like gob and groovie which convert from YUV
have to set up a list of several, and the difference in coding required adds
up over the course of three current and an unknown number of future
supported engines.

The compromise that LordHoto and I came to on IRC is thus:
Engines use the colormode enum type, and pass a list of supported colormodes
to initGraphics.
initGraphics gets the color order (RGBA, ABGR) from the backend, and
converts the colormode enums.
into Graphics::PixelFormat structures using a generic function provided for
this purpose.
initGraphics queries the backend regarding format compatibility, and passes
the first compatible format to the backend for initialization during the gfx
transaction.
initGraphics errors out if endGfxTransaction returns an error in setting up
the screen with requested pixel format
engines query backend to determine the accepted pixel format
When loading graphical resources, engines call a generic color-order
swapping function as necessary.

This way, engines get the simplicity of the enum type, but backends do not
have to worry about dealing with any format but Graphics::PixelFormat.
I am working on the proof of concept for this, but if there are any
complaints about this remaining, I will go ahead with one that uses
Graphics::PixelFormat exclusively.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090612/c4bb5ea3/attachment.html>