There's code in Mesa to byte swap the results after a grLfbRead* call
depending on how the buffer was initialized. The problem is that the
read call always returns the data in the board native format. The
grSstWinOpen controls only how writes to the board are handled. You
really want to always use
>I tried to track this down, and it certainly looked like the
>swapped pixels came from glide. I also could not find any
>place in mesa where the Glide ARGB/ABGR would be switched.
One thing that's been an off-and-on nitpick of mine, that I've not had the time
to finish coding a solution to, is
Daryll Strauss wrote:
>
> So, that puts it directly in the Mesa driver bug category. It can't be a
> Linux Glide bug, because you're not using Linux. :-)
>
My line of reasoning was:
The "original" glide was on Windows
You have "ported" it to Linux
Your port is so g
> Related to the original message, I ended up sending a test
> program to Daryll. I have not heard from him since, so
> I guess he is pretty busy with many issues...
> (it was about two weeks ago)
Yep, I'm still here. I'm trying to work through a bunch of bugs and this
one is on the list.
> my
Brian Paul wrote:
>
> mitch wrote:
> >
> > It seems that whenever you take a screenshot within a 3d game, the blue
> > and red colors are inversed from the color wheel. I have tested this on
> > Quake3, Quake2, and Kingpin and it happens on them all. I'm using a
> > voodoo3 and Kain, who is he
mitch wrote:
>
> It seems that whenever you take a screenshot within a 3d game, the blue
> and red colors are inversed from the color wheel. I have tested this on
> Quake3, Quake2, and Kingpin and it happens on them all. I'm using a
> voodoo3 and Kain, who is helping Daryll Strauss, does not bel
It seems that whenever you take a screenshot within a 3d game, the blue
and red colors are inversed from the color wheel. I have tested this on
Quake3, Quake2, and Kingpin and it happens on them all. I'm using a
voodoo3 and Kain, who is helping Daryll Strauss, does not believe it's
glide or the d
