[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