While Flash is operational, js and else conditional compilation is throwing an error on __image field of OpenFL’s BitmapData:
Error:(72, 36) openfl.display.BitmapData has no field __image
Also, position and readUnsignedByte():
/Users/jasonsturges/Projects/away3d-core-openfl/away3d/textures/BitmapTexture.hx:74: characters 8-21 : haxe.io.Bytes has no field position
/Users/jasonsturges/Projects/away3d-core-openfl/away3d/textures/BitmapTexture.hx:78: characters 15-28 : haxe.io.Bytes has no field position
/Users/jasonsturges/Projects/away3d-core-openfl/away3d/textures/BitmapTexture.hx:80: characters 34-55 : haxe.io.Bytes has no field readUnsignedByte
From Away3D’s BitmapTexture.hx, data is defined as:
#if flash
var data = BitmapData.getRGBAPixels (_bitmapData);
#elseif js
var data = ByteArray.__ofBuffer (@:privateAccess (bitmapData.__image).data.buffer);
#else
var data = @:privateAccess (bitmapData.__image).data.buffer;
#end
I moved bitmapData.__image to bitmapData.image in the last release and made it public. You can remove the @:privateAccess and just reference bitmapData.image.data.buffer directly
A while ago, in Lime we updated the ArrayBuffer implementation, it should work much better but it is abstracted over haxe.io.Bytes and is no longer based on a ByteArray
You can probably do data[0] instead of data.position = 0; data.readUnsignedByte (); to check the first byte?
@jasonsturges I’ve now updated the BitmapTexture.hx in the Away3D repo to use the .image rather than __image. I’ve also implemented a conversion from RGBA to BGRA for cpp (non-legacy) targets until the BGRA_EXT is implemented in Lime GL.hx.
BTW @singmajesty I’ve seen that in Lime, there is a set of GL constants defined in GLRenderContext.hx and another set in GL.hx. Is there a particular reason for this, or did it just kind of happen? Just seems a little redundant, especially as they are slightly different.
Let me know if there are differences, primarily, GL is static, and GLRenderContext is an instance. There might be a few things added in GL that aren’t WebGL that keep creeping in, I still feel cautioned about adding things that aren’t cross-platform
The only differences between the two that I’ve seen are :
In GLRenderContext (at line 164) but not in GL.hx :
public var BGR_EXT = 0x80E0;
public var BGRA_EXT = 0x80E1;
In GL.hx ( at line 27 ) but not in GLRenderContext :
public static inline var MIN = 0x8007;
public static inline var MAX = 0x8008;
As for whether they are/aren’t cross-platform, I’m not sure, but adding the BGRA_EXT is certainly one of getting the correct colour format (from what I’m aware of) without having to manipulate the image with byte swapping (as I’m currently doing).
It sounds like we should not use MIN or MAX in GLRenderContext, they are not supported by WebGL (or GLES?) and will just lead to broken code.
As for BGR_EXT, BGRA_EXT, I think this extension may be available in browsers, I’m not sure? For now, perhaps it’s safe to leave in GL, but leave out of GLRenderContext, so you don’t usually/generally use it, but we have the static defined so you don’t have to hunt around for the int value yourself
I’ve not used MIN/MAX - just noted the differences.
As for the BGRA_EXT, from what I’ve seen so far with the Away3D examples, the html5/dom target doesn’t use BGRA so isn’t required - it’s only the cpp targets that are affected (but not completely sure why and at what level the difference is at).
Having the static available would be useful and certainly better than a Uint
I hear that BGRA is what most graphics cards use, so it improves performance a bit. Cairo uses premultiplied BGRA internally, so using BGRA in OpenFL means we can go to/from Cairo without added conversion cost, I was not able to get BGRA to work in the browser, so it uses RGBA at the moment, which is just as well (likely) because canvas is RGBA, I think?
