[Scummvm-devel] 16bit support (Was: The 7th Guest)

Filippos K philipk79 at hotmail.com
Wed Nov 12 11:20:31 CET 2008

> > As for 16bpp color support... well, the GUI does use 16bpp color,
> Indeed. It uses the overlay. Which is separate from the game screen,  
> and should not be used to display game content.

True, but then again 16bpp colors are used in the main menus of ScummVM, even if only the overlay is used. I never said that we support 16bpp for games, I merely mentioned that parts of ScummVM (but not the game engines themselves) can use 16bpp colors already

> >
> > plus there are already supported games, such as Ween: The Prophecy,
> > which would need that many colors to work.
> Ween does not need 16bit colors.

Actually, I got a bit confused about this, after reading this closed bug report:

It seems that the overlay's palette is affecting the palette in-game, as mentioned in the patch

My bad.

> Those games are not supported by ScummVM, so that argument is moot. I  
> mean, there are also 3D adventures out there, like Grim, we all know  
> that -- it's no argument for adding 3D support to ScummVM. :)
I mentioned this cause I wanted to say that people are reluctant to work on games with more than
256 colors because we don't support them. I'm not saying that if 16bpp is implemented, 16bpp games
will magically start appearing in ScummVM (apart from some Humongous games, since they are SCUMM
based)... I'm just saying that there are many games out there that people could potentially work on,
but currently they are left out of ScummVM. The fan made Broken Sword 2.5 game comes to mind:

> Just to stress this once more: I am saying it's no argument *for*  
> anything, but I am not saying it's an argument *against* anything  
> either. People tend to be confused by that a lot and think that just  
> because I call their arguments non-sense/invalid/irrelevant, that I am  
> against their goal. Not necessarily - I just don't like false/fake  
> arguments :)

Point taken

> > So in my opinion it would be better to aim for support of resolutions
> > with a higher number of colors in the future, instead of not adding
> > games that need more than 256 colors,
> Actually, we *can't* add support for games that need more than 256  
> colors as long as we don't support more than 256 colors... :)

Erm, that's what I said, I believe?

> > since SDL itself has support
> > for more than 256 colors anyway.
> SDL is not relevant here. We are ScummVM, not SDL. Oh, SDL also has  
> OpenGL support, BTW :)

But we are based on SDL for most of our ports, and SDL does provide
functionality for 16bpp. I understand that the task of adding 16bpp color
support for games is quite a major task to undertake, and that it won't
happen any time soon, however a chunk of the work needed is already
in SDL. Nothing more, nothing less.

The main point in my e-mail was to stress that in the future, 16bpp
(and 24bpp, 32bpp) support in ScummVM would be a nice new addition,
and the fact that the groovie engine was used in both 8bpp and 16bpp
games is not a reason not to include it, that's all.


See how Windows® connects the people, information, and fun that are part of your life
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20081112/3370e25e/attachment.html>

More information about the Scummvm-devel mailing list