[Scummvm-devel] Bitdepth/pixel format API concerns

J Northup upthorn at gmail.com
Tue Jun 9 03:04:18 CEST 2009


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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090608/a036db33/attachment.html>


More information about the Scummvm-devel mailing list