Sven:<br>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.<br>
<br>Eugene:<br>I am not sure that an engine shouldn't ever request a new bit depth after its first request fails.<br>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. <br>
As I see it, there are basically three ways to support this behavior:<br>1) Provide a method for engines to query, and recieve a list of formats supported by current backend.<br>2) Have engines provide a list of supported formats to backend on init, so backend can iterate through and check for any compatible formats<br>
3) Provide a clean way for engines to retry a bitdepth initialization upon failure.<br><br>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).<br>
<br>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 <br>
<blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">switch(format) { <br>    case kFormat8Bit: <br>       doStuff(kFormat8Bit); <br>       return kTransactionSuccess;<br>
    case kFormatRGB555;<br>       doStuff(kFormatRGB555);<br>       return kTransactionSuccess;<br>   
default:<br>       return kTransactionPixelFormatUnsupported;<br>}</blockquote><div>Although perhaps that is overly simplified. It is <br><br>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.<br>
</div><br>Johannes:<br>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.<br>
<br><br>