bitmap.bitmapData.setPixels() no longer works on mac native

Help
#1

I’ve been away for some time, so I don’t know if this change is a feature of the new renderer or a bug, nonetheless, I’ve been updating my tile (Bitmap object) textures like this before:

 bitmaps[i].bitmapData.setPixels(bitmaps[i].bitmapData.rect, layer(i).textureBytes);

but it no longer works – it updates the Bitmap object texture with what appears like random data stored in RAM, not with the correct texture:

13

layer(i).textureBytes is correct, when I create BitmapData directly from it like this,

sprite.addChild(new Bitmap(BitmapData.fromBytes(layer(i).textureBytes)));

the texture looks as it should. Anyone else has this problem? Currently using latest haxelib versions of everything.

[EDIT]. Problem isn’t with setPixels() but with ByteArray, see next replies.

#2

Could this have something to do with endianness?

Could you try byteArray.endian = BIG_ENDIAN before the rest of your ByteArray code, and see if it helps?

#3

Well not exactly, but you are right that problem is with ByteArray, bitmapData.setPixels() works fine, sorry for misinformation. When I work on haxe.Bytes and then convert it to ByteArray which is only used for rendering, it appears as expected (at least so far I tested). Something with this is probably causing it:

byteArray.position = pos;
byteArray.writeInt(value);
#4

Does this do it?

byteArray.endian = BIG_ENDIAN;
byteArray.position = pos;
byteArray.writeInt(value);
#5

Yes, it does look a bit different (colors are different due byte swap) but still wrong data.

#6

Okay, created an issue: https://github.com/openfl/lime/issues/1018

#7

I have more information, probably not entirely related to the issue. When I get value from BitmapData like this:

var value = bitmapData1.getPixel();

I then need to do

bytes.setInt32(pos, ((value & 0xFF) << 24) | ((value & 0xFF00) << 8) | ((value & 0xFF0000) >> 8) | 0x000000FF);

instead of

bytes.setInt32(pos,  0xFF000000 | value);

to get correct image with this:

var byteArray = ByteArray.fromBytes(bytes);
bitmapData2.setPixels(bitmapData2.rect, byteArray);

Changing byteArray.endian does nothing after it is created, which is expected behaviour I think.

#8

Thanks! I’ve opened an issue: https://github.com/openfl/openfl/issues/1703

At first glance, this seems like an endianness issue, unless you think it’s a pixel order (RGBA vs ARGB) issue?

#9

I strongly believe it is endianness issue, because I needed to reverse all bytes to have correct colours, not just alpha channel.