[Scummvm-devel] Bitdepth/pixel format API concerns

Johannes Schickel lordhoto at gmail.com
Thu Jun 11 12:34:55 CEST 2009


J Northup wrote:
>
>     * Old bitformat:
>           o Pros:
>                 + Already defined and implemented
>                 + Values presented in a very readable and
>                   understandable format
>                 + Requires minimum of sanity checking by backends
>                 + Requires minimum of sanity checking by engines
>           o Cons:
>                 + Requires extra work for backends wanting to add
>                   support for a format not currently defined
>                 + Requires extra conversions to/from a format that can
>                   be understood by video interface
>                 + Viewed as outdated and "evil" by some menbers of the
>                   community
>           o Neutral/dependant:
>                 + Backend responsible for specifying color order
>

Another cons: The RGB order isn't defined. And it's hard to check the 
bits available for a color component code wise. DrMcCoy stated that his 
idea was to do that for GOB, because he only needs to do a YUV->RGB 
conversion in the engine.

>     * Bitdepth only
>           o Pros:
>                 + Already defined
>                 + Values presented in a very readable and
>                   understandable format
>                 + Minimum of sanity checking necessary for backend
>           o Cons
>                 + Disallows possibility of multiple formats in same
>                   bitdepth (ARGB1555/RGB555/RGB565/RGBA444)
>                 + Requires all engines with higher than 256 color
>                   modes to fully understand Graphics::PixelFormat values
>                 + Requires all engines with higher than 256 color
>                   modes to support color format conversions to match
>                   backend
>                 + Requires extra conversions to/from a format that can
>                   be understood by video interface
>           o Neutral/dependant:
>                 + Backend entirely responsible for specifying color format
>

Actually I see another cons here: if I get "Bitdepth only" right it'll 
be only a value like "8", "15" or "16"? If that's the case for example 
"16" is ambiguous, for example it could be either BGR565, RGB565, 
XRGB1555, ARGB1555 (the last two being RGB555 basically). This will let 
the engine later on worry about the exact format it needs to pass, via 
handling the return value of "getScreenFormat", which is ugly, since it 
would want to specify that beforehand. Thus I'm really against this one.

You might see all that under "Disallows possibility of multiple formats 
in the same bitdepth" though. :-)

>     * Graphics::PixelFormat
>           o Pros:
>                 + Already defined and implemented
>                 + Allows great flexibility in negotiation of color
>                   mode between engine and backend
>                 + No extra conversions necessary once format is agreed
>                   upon
>

Would allow easy checks for RGB vs BGR format too. Basically we could 
add a "querySupportedFormats" to OSystem, which returns a list of 
supported PixelFormats, which can then be searched by Gob (and Groovie), 
which'll do YUV->RGB anyway.

>           o Cons:
>                 + Complicated for engine to produce a list of
>                   supported formats
>

I don't see this, we can easily add a function "createPixelFormat", with 
the bits for each color component and maybe a flag to indicate RGB vs 
BGR order, which would make it  nearly as easy to create a list as with 
the other methods.

>                 + Requires backend developers to create and maintain a
>                   comprehensive list of supported formats or perform
>                   extensive checks to determine compatibility.
>

I would need to know *why* it is complicated? I don't see that matching 
the masks for the R, G, B color components against a table for example 
is complicated. :-) It sounds no more complicated than testing different 
enum values.

>                 + Requires engine to fully understand and work with
>                   Graphics::PixelFormat object
>           o Neutral/dependant:
>                 + Engine is primarily responsible for determining
>                   color format.
>

>     * Enum type (colormode and colororder fields)
>

I would rather call it an ORed combination of both than a single enum ;-).

>           o Pros:
>                 + Allows great flexibility in negotiation of color
>                   mode between engine and backend
>                 + Values presented in a very readable and
>                   understandable format
>                 + Requires minimum of sanity checking by backends
>                 + Requires minimum of sanity checking by engines
>           o Cons:
>                 + Slightly complicated for engine to produce list of
>                   supported formats.
>                 + Requires extra conversions to/from a format that can
>                   be understood by video interface.
>           o Neutral/dependant:
>                 + Engine is primarily responsible for determining
>                   color format.
>

>     * Enum type (colormode only)
>           o Pros:
>                 + Values presented in a very readable and
>                   understandable format
>                 + Requires minimum of sanity checking by backends
>                 + Requires minimum of sanity checking by engines
>           o Cons:
>                 + Requires extra conversions to/from a format that can
>                   be understood by video interface.
>

Another cons: No chance of allowing different RGB order (or even to 
determine it) As I stated on IRC tonight, some engines (like Gob), will 
only need to do YUV->RGB conversions. Thus there'll be no real reason to 
limit them to RGB instead of BGR order. The later might be used by some 
systems, which would have then have to do another conversion of the RGB 
data to BGR.


> Now, if I take Eugene's recommendation (from IRC) that color order 
> passed from engine to backend is always RGBA,

Well RGB555 isn't RGBA but XRGB(1555) (or ARGB1555, if it has an alpha 
channel). So RGBA isn't exactly always passed :-).

// Johannes




More information about the Scummvm-devel mailing list