ScummVM RGB color progress blog

June 11, 2009

bitdepth/pixelformat pros and cons

Filed under: Planning — Upthorn @ 3:11 am

I have recieved and reviewed the discussion in the bitdepth/pixelformat mailing list thread that I started, 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.

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: