[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