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?<br>
<br>I don't think there are any GL alpha problems at all. <br><br><div class="gmail_quote">On Wed, May 28, 2008 at 11:25 AM, IOhannes m zmoelnig <<a href="mailto:zmoelnig@iem.at">zmoelnig@iem.at</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">as hinted in my last email, Gem seems to have different hardcoded ideas<br>
about what RGBA means (esp. on OSX)<br>
<br>
the main confusion is about which "type" to use:<br>
GL_UNSIGNED_INT_8_8_8_8_REV vs GL_UNSIGNED_INT_8_8_8_8<br>
the solution seems to be simple (_REV on ppc, normal on i686) but it<br>
seems to be done inconsistently in the source code, thus resulting in<br>
all the alpha problems marius has reported.<br>
<br>
i have created a wiki-page that tries to explain the technical<br>
implementation of Gem's standard colorspaces, which can be found at<br>
<a href="http://gem.iem.at/documentation/GemWiki/ColorSpace" target="_blank">http://gem.iem.at/documentation/GemWiki/ColorSpace</a><br>
<br>
i have filled this page to my best knowledge, but i would be glad if<br>
somebody who knows what they are doing could have a look at it and<br>
confirm (or correct) everything (esp. those lines marked with "?")<br>
<br>
fgmasdr<br>
IOhannes<br>
<br>
_______________________________________________<br>
GEM-dev mailing list<br>
<a href="mailto:GEM-dev@iem.at">GEM-dev@iem.at</a><br>
<a href="http://lists.puredata.info/listinfo/gem-dev" target="_blank">http://lists.puredata.info/listinfo/gem-dev</a><br>
</blockquote></div><br>