The problem with the pix_ objects is the MMX code on is fixed to a different order than what OSX Intel uses.  For some objects this makes no difference, but others require the components in a specific order.  So to fix some bug complaints I swapped the byte order to match the MMX code, but this broke other things so it was switched back.  Perhaps defining some MMX/SSE macros for the order would sort this out?

I don't think there are any GL alpha problems at all. 

On Wed, May 28, 2008 at 11:25 AM, IOhannes m zmoelnig <zmoelnig@iem.at> wrote:
as hinted in my last email, Gem seems to have different hardcoded ideas
about what RGBA means (esp. on OSX)

the main confusion is about which "type" to use:
GL_UNSIGNED_INT_8_8_8_8_REV vs GL_UNSIGNED_INT_8_8_8_8
the solution seems to be simple (_REV on ppc, normal on i686) but it
seems to be done inconsistently in the source code, thus resulting in
all the alpha problems marius has reported.

i have created a wiki-page that tries to explain the technical
implementation of Gem's standard colorspaces, which can be found at
http://gem.iem.at/documentation/GemWiki/ColorSpace

i have filled this page to my best knowledge, but i would be glad if
somebody who knows what they are doing could have a look at it and
confirm (or correct) everything (esp. those lines marked with "?")

fgmasdr
IOhannes

_______________________________________________
GEM-dev mailing list
GEM-dev@iem.at
http://lists.puredata.info/listinfo/gem-dev