Humongous Entertainment/Progress/16bits Support

From ScummVM

Jump to: navigation, search

Intro

Here are assorted ideas about 16bits support for ScummVM.

Currently it is required only for later HE games:

  • Backyard Baseball 2001
  • Backyard Baseball 2003
  • Backyard Basketball
  • Backyard Football 2002
  • Backyard Soccer 2004
  • Backyard Soccer MLS Edition
  • Blue's Art Time Activities
  • Blue's Reading Time Activities
  • Freddi Fish 5: The Case of the Creature of Coral Cave (demo)
  • Moonbase Commander
  • Pajama Sam: Games to Play On Any Day
  • SPY Fox 3: Operation Ozone

Overview

It shouldn't be hard to add 16bits support to OSystem. In fact we already support that for GUI. Currently only SCUMM engine needs to be enhanced.

From the other hand our implementation should meet several important requirements:

  • Code should be done optional. I.e. we should be able to disable 16bits support at compile time
  • It should have minimal performance impact to 8bits games, i.e. our lower platforms should not suffer from its existence
  • Code should be clean and readable
  • There could be both 8bits and 16bits objects in the same game and even on the same screen. I.e. if you'll take a look at current 16bits games, many of them already show correct graphics with our 8bit rendering, still some objects are rendered badly:
    • freddicove: Actors have 16bits palette, remaining 8bits
    • freddicove: backgrounds are 16bits raw 565 data in many locations

Possible solutions

  • Each object with a pixmap should have additional field "type" which will show either its pixmap data is 16bits or 8bits.
  • Templates. Some low-level, particularly offscreen rendering functions will be templated, and 16bits version written
  • Typedef. All graphics data should be moved to new, say, gfxData type. It will be selected between byte and uint16 on compilation stage, so it will have no impact on non-supporting platforms.
    • In 16bits engine mode all 8bits data is padded with 0'es. Then rendering functions will just ignore high byte before moving it to backbuffer

Still needs to be determined way of combining both 8 bits and 16 bits data. I.e. in our case 8 bits data is actually 24 bits as it is index to palette, and 16 bits should be copied as is. Then problem is to find a way of blending two together, so it will be somewhat distinguished before rendering and proper palettes applied.

Retrieved from "http://wiki.scummvm.org/index.php/Humongous_Entertainment/Progress/16bits_Support"
Personal tools