For efficiency reasons jME is using all buffers with the native byte order. When converting a direct byte buffer via asIntBuffer(), the resulting integer buffer uses the native endianness. However it seems the image formats such as RGBA are not dependent on endianness. So if you are trying to extract pixel data using integer buffer, you get endianness dependent code.
For example:
You have a pixel buffer, and you are reading the first pixel.
The order of bytes in the buffer is: r1, g1, b1, a1
You are using IntBuffer to read the pixel:
a = (pixelColor >> 24) && 0xff;
b = (pixelColor >> 16) && 0xff;
g = (pixelColor >> 8 ) && 0xff;
r = (pixelColor) && 0xff;
This works on little-endian processors, such as intel, but might give somewhat inverted image on big-endian processors such as PowerPC (mac).
Easy way to test this would be to run such code on a big endian processors.
This issues could be affecting: LWJGLRenderer.takeScreenshot(), LWJGLMouseInput.setHardwareCursor() and maybe others methods/classes.
Yeah, we do some checks for that in places we know it matters (OggInputerStream.java for example). I believe ??? takeScreenShot works fine on both though because the ordering is the same on boths sides of the transfer (BufferedImage and the ReadPixels).
Screenshot seems good provided readPixels handles the ordering. But setHardwareCursor doesn't seem to have anything to prevent the endianness issue.
Also looking at the code in setHarwareCursor, Ive noticed it expects image in RGBA8888 format, but never does any check for it. So you if you pass image in some other type, you'll get ArrayOutOfBoundsException.