While no consensus has yet been reached on the concerns regarding the API, I am going ahead and starting work one of the possibilites that has begun to feel fully formed in my head:
This model uses an enum type, (temporarily Graphics::ColorFormat) which is divided into two parts, FormatType and ColorOrder, which are ORed together.
To start with, I am providing ten values for FormatType:
- kFormat8Bit = 0
- kFormatRGB555 = 1
- kFormatARGB1555 = 2
- kFormatRGB556 = 3
- kFormatRGB565 = 4
- kFormatRGB655 = 5
- kFormatARGB4444 = 6
- kFormatRGB888 = 7
- kFormatARGB6666 = 8
- kFormatARGB8888 = 9
and 31 values for ColorOrder
- kFormatPalette = 0 << 8
- kFormatRGB = 1 << 8
- kFormatRBG = 2 << 8
- kFormatGRB = 3 << 8
- kFormatGBR = 4 << 8
- kFormatBRG = 5 << 8
- kFormatBGR = 6 << 8
- kFormatARGB = 7 << 8
- …
- kFormatBGRA = 30 << 8
For this tentative model, the optional parameter to Engine::InitGraphics will be a Common::List of formats the game supports. The backend will iterate through this list and test each entry for compatibility, using a pair of switches, as per the following simplified example:
OSystem::TransactionError checkFormatCompatibility(Graphics::ColorFormat format)
{
switch(format & kFormatTypeMask) {
case kFormat8Bit:
case kFormatRGB555:
break;
default:
return kTransactionPixelFormatNotSupported;
}
switch (format & kFormatOrderMask) {
case kFormatRGB:
case kFormatARGB:
return kTransactionSuccess;
default:
return kTransactionPixelFormatNotSupported;
}
}
NOTE FOR DEVELOPERS: I do not really expect this to be an acceptable final implementation, as it is a combination of overkill (who’s ever heard of BAGR6666 color?) and underkill (no YUV support), so, pending further notice do not use information from this post to make any plans or modifications to your engine or your backend. I am only using this as a direction for me to pursue while I await a final decision from full developers.