[Scummvm-devel] Bitdepth/pixel format API concerns

[J Northup]

Hello all,
I am now in the phase of the 16-bit game support project where I have to
design and implement an API for game engines to request a certain bitdepth
from the backend. Eugene  (Sev... my mentor), and I agree that it is a good
idea to get input from as many affected developers as possible. I have made
a post on my development blog (
http://scummvmupthorn09.wordpress.com/2009/06/07/first-outlines-of-an-api/)
regarding what has already been determined, and asking a few questions about
how it should work, which I will be reposting here so that I can get
feedback from as many of you as possible.

What has already been determined:
* The pixel format will be initially requested of the backend by means of an
optional parameter to OSystem::InitGraphics.
* The default pixel format (in case of no parameter), will be 8-bit,
paletted, to minimize changes required to existing engines.

What has yet to be determined:
* What happens when the engine requests an unsupported format?
    * Does InitGraphics fall back to 8 bit, or fail entirely?
    * How does the game engine learn that its request was denied?
    * How does the game engine request an alternate format, if the game
supports multiple formats: a second call to InitGraphics,
        or a second method meant specifically for specifying bitdepth?
* What format should the parameter take?
    * Should it be a pair specifying bitdepth (8,16,24,32) and format
(palette, rgb, grb, bgr, etc)?
    * Should it be a generic format specifier (8, 555, 1555, 565, 888, 8888,
etc)?
    * Should it be a fully formed Graphics::PixelFormat object?
    * Should it be some other format designed and implemented specifically
for this task?
        * What should this format look like?
* What should happen if the backend and engine cannot agree on a directly
supported format?
    * Should the game engine simply error out?
    * Should pixel format conversions be performed?
        * Should these conversions be performed by the engine, so that a
"convert once, use multiple" approach can be taken?
        * Should these conversions be performed by the backend, so that it
can take advantage of hardware conversion support,
          where available?
    * Should the engine and backend developers have free choice among these
optioins, so that they can choose the case  that makes
      the most sense for their engine or backend?
* Are there any concerns or questions that you have, which I failed to
account for?

I hope you will respond promptly, so that I can continue with coding as soon
as possible.

Thank you,
Jody Northup
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090608/3e62c79b/attachment.html>