[Scummvm-devel] Bitdepth/pixel format API concerns
Johannes Schickel
lordhoto at gmail.com
Tue Jun 9 00:32:30 CEST 2009
Eugene Sandulenko wrote:
>> * What happens when the engine requests an unsupported format?
>> * Does InitGraphics fall back to 8 bit, or fail entirely?
>>
> I think yes. I.e. 16-bit has to be special. Same as our GUI code falls
> back to classic scheme when 16-bits surface is not available.
>
Actually that's no longer true for our latest VectorRenderer based GUI
code, which will only work with 16bpp surfaces. Of course we could still
implement some palette based fallback. As far as I know all of our
backends do support 16bpp overlay these days though, which was one of
the reasons why we don't support 8bpp palette based overlays anymore.
>> * How does the game engine learn that its request was denied?
>>
> By querying backend feature. Something like kFeatureHas16bitsColor to
> feature flag and make it return current state.
>
>
>> 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)?
>>
> ask for number of bits, not the specific format. Then engine code will
> query established format, similar to currently implemented
> getOverlayFormat() call and perform on the fly color transformation.
>
I don't see why we should need something like "kFeatureHas16BitsColor",
when we will have an extra function to query the PixelFromat setup
anyway. The client code could just call that function and check the
return value instead.
Of course in the end it would be best to check the return value of
"endGFXTransaction". Since this is the place where errors will be
reported so far. We could easily add another "TransactionError" for that
say "kTransactionPixelFormatNotSupported".
BTW. ::initGraphics does use this return value currently too. Just check
engines/engine.cpp lines 128 to 171 for that.
> Alternatively we could assume that engines always feed 565 and perform
> the transition in the backend if needed. Note, that we already have all
> required transformation methods implemented.
>
I would really vote against this. If we might in the future also allow
24bit data (useful for GOB and GROOVIE as I got told, since they will do
only YUV->RGB conversion) we would need to make yet another backend
internals change. That would just load more work onto the porters.
>> * Should it be a fully formed Graphics::PixelFormat object?
>>
> That would be an overkill in the sense that every backend will need to
> understand all formats.
>
The backend would still be able to just reject the format and fail
setting up the requested video mode with this one too. See my comment
above for more details on how the client code could possibly check
whether that is the case.
// Johannes
More information about the Scummvm-devel
mailing list