[Scummvm-devel] Bitdepth/pixel format API concerns

Johannes Schickel lordhoto at gmail.com
Sat Jun 13 17:30:07 CEST 2009


Willem Jan Palenstijn wrote:
> Hi,
>
> I was wondering, is there any situation in which an engine would want to
> ask something other than:
>
> * a 8bpp indexed mode (the current situation),
> * a mode given by a specific PixelFormat (HE?), or
> * any 16bpp/32bpp mode that's fast/convenient for the backend? (Gob?)
>   

Don't think so.

> This last one might be significantly more convenient for both the engine
> and the backend. In case more control is wanted, we could also add a
> queryNativeFormats as was suggested earlier.
>   

Actually in all cases queryNativeFormat might be a good idea, since 
first of all engines which do have support for different modes, could 
try to check one that also has native supported by the backend. I guess 
most 16bpp should usually have support for RGB565 and RGB555, since 
those are the most common modes, so they might pass native data via that 
to the backend.

For GOB and Groovie, both doing YUV->RGB conversion, any mode might be 
ok (as you said). Thus I proposed initFormat taking an pointer to 
PixelFormat and when it's zero the backend should setup the mode with 
the highest bits per channel count it supports.

// Johannes




More information about the Scummvm-devel mailing list