[Scummvm-devel] Bitdepth/pixel format API concerns

[J Northup]

On Sat, Jun 13, 2009 at 3:12 AM, Marcus Comstedt <marcus at mc.pp.se> wrote:

>
> J Northup <upthorn at gmail.com> writes:
>
> > bool isABGR(void): true if the backend uses ABGR color order, false if
> > backend uses RGBA.
>
> And if the color order is ARGB?  I don't quite understand the need for
> this method, as you can already query the PixelFormat, which contains
> both ordering and number of bits.  Just knowing "ABGR or not ABGR"
> does not give enough information anyway.

I have been told by _sev that RGBA and ABGR are the only orders supported by
any backend. Is this incorrect?


On Sat, Jun 13, 2009 at 3:29 AM, Filippos Karapetis
<philipk79 at hotmail.com>wrote:

>  I don't understand why the backend would need to support both RGBA and
> ABGR modes.
> Wouldn't it be easier to have a fixed order? Are there any specific
> benefits when specifying ABGR over RGBA, or vice versa?
>
> Regards
> Filippos
>
The backend would not need to support both modes. Each backend needs to
support one of those two modes, and the engine swaps order to meet the
backend's needs.



On Sat, Jun 13, 2009 at 3:55 AM, Travis Howell <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?
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.scummvm.org/pipermail/scummvm-devel/attachments/20090613/da180d0d/attachment.html>