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

Max Horn max at quendi.de
Wed Nov 12 10:40:03 CET 2008


Am 12.11.2008 um 08:37 schrieb Filippos K:

> The work done on this engine is wonderful, and I'm up for adding it
> to the ScummVM tree
>
> 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.

>
> 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.

> There is even a patch
> that aims to add 32bpp color support:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1664514&group_id=37116&atid=418822

That patch is about adding 32bit support to the overlay. *Not* to game  
screens.

>
> Also, the later Zork games (Nemesis, Grand Inquisitor etc) use a
> similar engine as MADE, if I'm not mistaken, but use 16bpp colors.
> Moreover, QuickTime videos used in games (e.g. Myst and Riven) need
> more than 256 colors to be shown correctly. Finally, many newer
> adventure games that could potentially be added to ScummVM in the
> future had 16bpp colors (if memory serves right, Star Trek: The next
> generation, a finaly unity had 16bpp).

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. :)

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 :)


> 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... :)


> 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 :)

> Some platforms and non-SDL
> backends might not support that many colors, but not all the games
> that ScummVM supports run under all platforms anyway (due to other
> constraints, like for example memory).

This has been discussed before. Yeah, adding 16bit support has been on  
our TODO list for a long time. But it has to be done right. In  
particular, it doesn't just have to be optional for devies not  
supporting it; it should in fact also be possible to turn it off  
completely, so that it doesn't cause overhead for systems with low  
resources (in terms of binary size, memory usage, CPU usage). In  
particular, the 8bit graphics mode should not be slowed down by being  
made more generic for 16bit support.
I am not willing to accept any hacks that quickly add 16bit support  
without taking care of these issues. It has to satisfy the  
requirements above, and ideally, shouldn't bloat OSytem too much more  
(it's already quite complicated these days).

With PixelFormats, we are slowly moving into a direction that one day  
might make it possible to smoothly add optional 16bit support. But  
nobody is actively working on it.



Bye,
Max




More information about the Scummvm-devel mailing list