Hi Eero,
Yesterday, I come back from my summer vacation so sorry for the dalay of
my answer.
> There has been some reports on R and B colours getting
> mixed in glDrawPixels/glReadPixels on win32/glide based
> Mesa. (In my case with V2, which might be significant
> also)
>
> I am now seeing this bug "reliably" on my application:
>
> -when doing glReadPixels the R and B channel
> datas are swapped.
>
> -the bug seems to "get started" when I do a
> glDrawPixels operation.
>
> -after the pixels start reading in swapped fashion
> they stay like that.
>
> I searched around in Mesa sources but could not find an
> obvious reason for this. I currently suspect that
> it is Glide which is somehow losing its "state".
>
> In Glide2 (at least) I did not find a way to directly
> set the RGB/BGR state (or to inquire it) so I couldn't
> do any tricks with the state directly.
There could be two possible explanations:
- someone has changed the grSstWinOpen() parameter for selecting RGB/BGR
without changing the driver code for pixel operations (I'm at work
without the Mesa sources at hand so I can not check);
- the problem could be in the grLfbWriteColorFormat(GR_COLORFORMAT_ABGR)
calls in driver functions for pixel operations. Some 3Dfx hardware
doesn't support all color formats (i.e. I know it is true for the Voodoo
Rush) and the Glide doesn't internally swap the color bytes for
unsupported GR_COLORFORMAT. The driver is not handling this case and it
always uses the some color format assuming it is supported.
Are you using a Voodoo 3 ?
David
--
David Bucciarelli
[EMAIL PROTECTED]
Humanware S.r.l.
Via delle Belle Torri 18, Pisa, Italy
Tel: +39-050-576033
Fax: +39-050-973270
WWW: http://www-hmw.caribel.pisa.it
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev