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