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

Max Horn max at quendi.de
Wed Nov 12 22:25:55 CET 2008

Hi Oystein,

true enough, I guess. Ading a basic 16bit "API" to OSystem shouldn't  
be too hard:

* add a way to request a 16bit (or even 32bit) game screen (say, add  
an extra optional param to initScreen)
* add a way to query the current screen depth (possibly via a method  
returning a PixelFormat)
* if in 16bit mode, then..
  - copyRectToScreen, setMouseCursor would assume the data passed in  
is 16bit data
  - palette changing calls would be ignored
* make sure that existing backends do not have to do *anything* to  
continue working (albeit w/o 16bit support)
* decide whether to (1) always force a 565 screen (or 555?), or (2)  
force Engines adapt to whatever bitformat the backend supports  
"natively" (drawback of (1): forces some backends to do pixel  
conversions for blitting; and some games may want 555, some may want  
565,; drawback of (2): burden on the engine authors)

All that (except maybe for the last point) shouldn't be too hard. Of  
course, there are some complications with games which need both 8bit  
and 16bit GFX at the same time (see <http://wiki.scummvm.org/index.php/Humongous_Entertainment/Progress/16bits_Support 
 >), but I wonder whether we shouldn't let the engine deal with that,  
it seems to be a very engine specific thing.


More information about the Scummvm-devel mailing list