[Scummvm-devel] Bitdepth/pixel format API concerns

Travis Howell kirben at optusnet.com.au
Sat Jun 13 15:29:47 CEST 2009


J Northup wrote:
  > On Sat, Jun 13, 2009 at 3:55 AM, Travis Howell <kirben at optusnet.com.au
> <mailto:kirben at optusnet.com.au>> wrote:
> 
>     Johannes Schickel wrote:
>      > J Northup wrote:
>      >> When loading graphical resources, engines call a generic color-order
>      >> swapping function as necessary.
>      >
>      > Kirben told me that those conversions would make the SCUMM code much
>      > more complex, but I'm not exactly sure. Kirben, maybe you can
>     comment on
>      > this again? Anyway since the backend is forced to do conversion, this
>      > isn't exactly needed, it might be used by engine authors when they
>      > expire performance problems on certain backends. (See the mail
>     from Max
>      > on 9th of July 10:54 AM).
> 
>     The problem is the resources used for wizImages in HE games are
>     manipulated on the fly.
> 
>     A resource can be created or loaded, then have the screen buffer (front
>     or back) copied or another resource drawn (sometimes via memory buffer)
>     into that resource, and then finally drawn to screen at later point. It
>     is even possible for modified resources, to be based off other modified
>     resources.
> 
> 
> 
>     So modified resources still need to be kept in their native format, and
>       additional conversions would be required (ie when copying from the
>     screen buffers), meaning more complex code.
> 
> 
> I'm confused as to how this necessitates keeping the resources in the 
> original pixelformat at all times: if the modifications just copy or 
> overwrite what is there, why couldn't the modification data be converted 
> to match the backend format?

Because the same functions (usually through drawWizImage) are used to 
write wizImage data to memory or resource or screen. So changing the 
native format would cause problems, after the resource was first 
converted. Unless I tracked the pixel format of every single wizImage.

An example:
A wizImage resource could be created, then an image drawn to that 
resource through drawWizImage, then that resource is drawn to screen by 
drawWizImage. If the native format wasn't kept, it would fail when been 
drawn to the screen, unless we track the pixel format of every single 
resource.

> Are there cases where the RGB color channels are manipulated separately? 
> Are there cases where the original color values are taken and some 
> operation is performed on those, rather than being overwritten?

There are palette related opcodes in HE games which might cause issues 
too, see code in engines/scumm/he/palette_he.cpp, which is currently 
based on RGB 555.




More information about the Scummvm-devel mailing list