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

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:


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.

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?

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;

Does this do it?

byteArray.endian = BIG_ENDIAN;
byteArray.position = pos;

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

Okay, created an issue:

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.

Thanks! I’ve opened an issue:

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

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