Just for example, here is what i get when i open a simple image with Gem (without alpha) with a recent Pd-extended (20080524) and GEM: ver: 0.91.0 'tigital' on PowerBook G4 (PowerPC) and MacOSX.4.11. All works fine with Pd-extended (20080315) and GEM: ver: 0.91-cvs. So i only use this Pd and Gem now on my PowerPC. I also send an email about a problem with [pix_mask] too. ++
Jack
Le 28 mai 08 à 18:54, IOhannes m zmoelnig a écrit :
chris clepper wrote:
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.
the problem is most likely not with openGL. however, the problem is not only with SIMD code, even after your changes.
a test of [pix_mask] revealed a lot of weirdnesses (but unfortunately i don't have access to my test-patch right now, so i try to reconstruct it by heart) the tests have been done on an i686 (OSX-10.4.?) i got different results when using [pix_image], [pix_film] and [pix_video] as pix-source; i also get different results when using [colorspace RGBA( vs [pix_rgba] the results differ in both swapping color-channels _and_ having different "types". iirc, images in RGBA space with type GL_UNSIGNED_INT_8_8_8_8_REV where almost certain to yield blueish results with alpha mask not working. finally, [pix_mask] does _not_ involve any MMX/SSE2 code.
i am pretty sure that on macIntel images of type GL_BGRA_EXT are _not_ of type GL_UNSIGNED_INT_8_8_8_8_REV, is this correct?
anyhow, i thought before i start thinking about changing things and making them worse, i would rather now what the target layout of the colors is, that's why i started the wiki.
and yes, i also think that having some macros for the SSE/MMX code will help us (but i am not that far yet...)
fgmadsr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev