<br><br><div class="gmail_quote">On Sat, Jun 13, 2009 at 3:12 AM, Marcus Comstedt <span dir="ltr"><<a href="mailto:marcus@mc.pp.se">marcus@mc.pp.se</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
J Northup <<a href="mailto:upthorn@gmail.com">upthorn@gmail.com</a>> writes:<br>
<br>
> bool isABGR(void): true if the backend uses ABGR color order, false if<br>
> backend uses RGBA.<br>
<br>
</div>And if the color order is ARGB?  I don't quite understand the need for<br>
this method, as you can already query the PixelFormat, which contains<br>
both ordering and number of bits.  Just knowing "ABGR or not ABGR"<br>
does not give enough information anyway.</blockquote><div>I have been told by _sev that RGBA and ABGR are the only orders supported by any backend. Is this incorrect?<br>
<br>
<br>
<div class="gmail_quote">On Sat, Jun 13, 2009 at 3:29 AM, Filippos Karapetis <span dir="ltr"><<a href="mailto:philipk79@hotmail.com">philipk79@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">




<div>
I don't understand why the backend would need to support both RGBA and ABGR modes. <br>Wouldn't it be easier to have a fixed order? Are there any specific benefits when specifying ABGR over RGBA, or vice versa?<br>
<br>Regards<br><font color="#888888">Filippos</font></div></blockquote></div>
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.<br> 

<br></div></div><br><br><div class="gmail_quote">On Sat, Jun 13, 2009 at 3:55 AM, Travis Howell <span dir="ltr"><<a href="mailto:kirben@optusnet.com.au">kirben@optusnet.com.au</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Johannes Schickel wrote:<br>
<div class="im">> J Northup wrote:<br>
>> When loading graphical resources, engines call a generic color-order<br>
>> swapping function as necessary.<br>
><br>
> Kirben told me that those conversions would make the SCUMM code much<br>
> more complex, but I'm not exactly sure. Kirben, maybe you can comment on<br>
> this again? Anyway since the backend is forced to do conversion, this<br>
> isn't exactly needed, it might be used by engine authors when they<br>
> expire performance problems on certain backends. (See the mail from Max<br>
> on 9th of July 10:54 AM).<br>
<br>
</div>The problem is the resources used for wizImages in HE games are<br>
manipulated on the fly.<br>
<br>
A resource can be created or loaded, then have the screen buffer (front<br>
or back) copied or another resource drawn (sometimes via memory buffer)<br>
into that resource, and then finally drawn to screen at later point. It<br>
is even possible for modified resources, to be based off other modified<br>
resources.</blockquote><div></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
So modified resources still need to be kept in their native format, and<br>
   additional conversions would be required (ie when copying from the<br>
screen buffers), meaning more complex code.</blockquote><div><br><div>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?<br>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?<br>
<br>
</div></div></div>