[Scummvm-devel] Bitdepth/pixel format API concerns

J Northup upthorn at gmail.com
Thu Jun 11 12:15:28 CEST 2009


Oh dear. That posting failed in more than one way (creating a new thread on
the archive page, and being rendered totally unreadable in the process), so
I am providing this link to a reposting of the same information on my blog:
http://scummvmupthorn09.wordpress.com/2009/06/11/bitdepthpixelformat-pros-and-cons/

On Thu, Jun 11, 2009 at 2:58 AM, J Northup <upthorn at gmail.com> wrote:

> I have recieved and reviewed the discussion in this thread, and I'm a bit
> worried by the results:
> One vote (Sven) for the old bitformat (8, 555, 565, 888) style of format
> specification
> One vote (Eugene) for the engine requesting only a bitdepth, not a full
> format
> Two votes (Johannes and Max) for the engine requesting a (list of) fully
> formed Graphics::PixelFormat object(s).
> One vote (Myself) for using an enumerated list
> Three people (Marcus, Joost, Oystein) contributing useful information about
> backend concerns, but no recommendations of their own
>
> Nothing resembling a consensus, and very little discussion on the pros and
> cons of each method.
>
> So, I'm going to list the pros and cons (as I see them) for each format:
>
>
>    - Old bitformat:
>       - 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
>       - 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
>       - Neutral/dependant:
>          - Backend responsible for specifying color order
>          - Bitdepth only
>       - Pros:
>          - Already defined
>          - Values presented in a very readable and understandable format
>          - Minimum of sanity checking necessary for backend
>       - 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
>       - Neutral/dependant:
>          - Backend entirely responsible for specifying color format
>       - Graphics::PixelFormat
>       - 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
>       - Cons:
>          - Complicated for engine to produce a list of supported formats
>          - Requires backend developers to create and maintain a
>          comprehensive list of supported formats or perform extensive checks to
>          determine compatibility.
>          - Requires engine to fully understand and work with
>          Graphics::PixelFormat object
>       - Neutral/dependant:
>          - Engine is primarily responsible for determining color format.
>          - Enum type (colormode and colororder fields)
>       - 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
>       - 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.
>       - Neutral/dependant:
>          - Engine is primarily responsible for determining color format.
>       - Enum type (colormode only)
>       - Pros:
>          - Values presented in a very readable and understandable format
>          - Requires minimum of sanity checking by backends
>          - Requires minimum of sanity checking by engines
>       - Cons:
>          - Requires extra conversions to/from a format that can be
>          understood by video interface.
>       - Neutral/dependant:
>          - Backend responsible for specifying color order
>       - New type (not yet defined)
>       - Pros:
>          - Can be designed specifically for this task
>       - Cons:
>          - May require significant effort to implement
>
> Now, if I take Eugene's recommendation (from IRC) that color order passed
> from engine to backend is always RGBA, then removing the ability from the
> engines to specify their own order is actually a plus, as it shields from
> potential future developer error. But, I don't know if that idea is
> universally agreed upon.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090611/39bf6da2/attachment.html>


More information about the Scummvm-devel mailing list