[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