[Scummvm-devel] Bitdepth/pixel format API concerns

[J Northup]

On Mon, Jun 8, 2009 at 6:04 PM, J Northup <upthorn at gmail.com> wrote:

> Sven:
> I agree, that does look tempting, but I realize that it would still require
> a second param (enum or string), to specify the RGB order, just in case
> there's some game engine out there with resources in BGR, or something.
>
> Eugene:
> I am not sure that an engine shouldn't ever request a new bit depth after
> its first request fails.
> After all, there are certain games that can run in multiple bitdepths, but
> might prefer one over the others -- Urban runner, for instance, claims to
> support 24bit RGB, 16bit RGB, and 8bit paletted. The engine might,
> therefore, might first want to attempt a 24-bit initialization, then 16-bit,
> before falling back to 8bit mode, and I would like to do things in a way
> that doesn't create more work for people (or myself) when it comes time to
> implement support for 24 and 32 bit color.
> As I see it, there are basically three ways to support this behavior:
> 1) Provide a method for engines to query, and recieve a list of formats
> supported by current backend.
> 2) Have engines provide a list of supported formats to backend on init, so
> backend can iterate through and check for any compatible formats
> 3) Provide a clean way for engines to retry a bitdepth initialization upon
> failure.
>
> Of these, option (2) seems like it would require the least additional
> support because it doesn't require backends to generate an exhaustive list
> of supported possibilities, or to support initialization of bit depth
> independantly from screen resolution has been set (important because, on
> memory-limited systems, higher bit-depths may restrict the maximum supported
> resolution).
>
> A quick glance through system.h shows that the OSystem base class, from
> which all backends inherit, already includes a Graphics::PixelFormat, so I
> am not quite sure I understand what you mean about it requiring all backends
> to understand all formats. However, as I consider this specific issue
> further, it seems like it would make most sense to create an enum to cover
> this, so that backends can do a simple
>
>> switch(format) {
>>     case kFormat8Bit:
>>        doStuff(kFormat8Bit);
>>        return kTransactionSuccess;
>>     case kFormatRGB555;
>>        doStuff(kFormatRGB555);
>>        return kTransactionSuccess;
>>     default:
>>        return kTransactionPixelFormatUnsupported;
>> }
>
> Although perhaps that is overly simplified. It is
>
> I understand what you mean when you say that free choices can make
> development more difficult. However, I think that each of these options
> makes sense some of the time, but not all of the time.
>
> Johannes:
> Err, OSystem::InitGraphics was my misunderstanding. As I look through the
> code, I see I should say that it will be initialized via an optional
> parameter to Engine::InitGraphics, although, fortunately, that doesn't seem
> changes any of the concerns significantly.
>
>
>
In absence of further response, I am beginning work using a model based on
an enum type, divided into two sections, ORed together:
        kFormatTypeMask = 0xFF // AND by this to get the overall bit format
        kFormatOrderMask = 0xFF << 8 // AND by this to get the (RGB/BGR
order)

Currently providing ten values for Type: kFormat8Bit, kFormatRGB555,
kFormatARGB1555, kFormatRGB556, kFormatRGB565, kFormatRGB655,
kFormatARGB4444, kFormatRGB888, kFormatARGB6666, and kFormatARGB8888

And 31 values for Order: Palette, kFormatRGB, kFormatRBG, kFormatGRB,
kFormatGBR, kFormatBRG, kFormatBGR, kFormatARGB, ..., kFormatBGRA
I do not really expect this to be an acceptable final implementation, as it
is either overkill (who's ever heard of BAGR6666 color?) or underkill (what
about YUV?), but it will provide a direction for me to work towards while
awaiting further discussion and developer consensus (as daily commits are
expected of me), as well as a concrete example of the positive and negative
aspects of this model.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090608/a7469bdf/attachment.html>