Thanks :)
@jgranick thanks.. it's not so important for me now as I don't have much time to play with it anyway... so I don't mind waiting... looking at this http://www.openfl.org/documentation/api/openfl/Memory.html I don't see sign extension support as is in
avm2.intrinsics.memory. Also where I could find how it's implemented? I can see this https://github.com/openfl/openfl/blob/develop/openfl/_legacy/Memory.hx but it looks quite cryptic to me.
This is the exact code on Flash: https://github.com/openfl/openfl/blob/develop/extern/flash/Memory.hx
the __vmem stuff is Flash Player internals
if I recall
How do I set dropdown shadow to a sprite for C++ targets?
Hi @jgranick - I'm writing unit tests against a port of OpenFL and found a bug in the ColorTransform class, however, I'm not logging it immediately because I'd like to figure out if it has been fixed higher up in the display chain. Has anyone experienced ColorTransform issues in production?
I'm seeing some reports of inconsistency, but couldn't see anything directly relating to the colors being incorrect as a general state of the class.
Anyway, just for your reference:
/// <summary>
/// Concatenates the ColorTranform object specified by the second parameter with the current ColorTransform object and sets the current object as the result, which is an additive combination of the two color transformations. When you apply the concatenated ColorTransform object, the effect is the same as applying the second color transformation after the original color transformation.
/// </summary>
/// <param name="t">The ColorTransform to concat.</param>
public void Concat(ColorTransform t)
{
mRedOffset = t.RedOffset * mRedMultiplier + mRedOffset;
mGreenOffset = t.GreenOffset * mGreenMultiplier + mGreenOffset;
mBlueOffset = t.BlueOffset * mBlueMultiplier + mBlueOffset;
mAlphaOffset = t.AlphaOffset * mAlphaMultiplier + mAlphaOffset;
mRedMultiplier *= t.RedMultiplier;
mGreenMultiplier *= t.GreenMultiplier;
mBlueMultiplier *= t.BlueMultiplier;
mAlphaMultiplier *= t.mAlphaMultiplier;
}Fixes my own inconsistencies (tested against FlashPlayer 28)
As opposed to:
public function concat (second:ColorTransform):Void {
redMultiplier *= second.redMultiplier;
greenMultiplier *= second.greenMultiplier;
blueMultiplier *= second.blueMultiplier;
alphaMultiplier *= second.alphaMultiplier;
redOffset = second.redMultiplier * redOffset + second.redOffset;
greenOffset = second.greenMultiplier * greenOffset + second.greenOffset;
blueOffset = second.blueMultiplier * blueOffset + second.blueOffset;
alphaOffset = second.alphaMultiplier * alphaOffset + second.alphaOffset;
}In OpenFL. Hope that helps.
Can somebody check OpenFL/Lime with Away3D RealTimeEnvMap and it crashed because it doesn't see error messages. If I test with static and release. Than I open finish built executable and it will stop working
Did you not check if Lime latest version is not fixed?
I’m trying to figure out how I can make the background of an X11 window transparent. I know the AIR target will do it but I don’t want to build for AIR. I’ve downloaded the lime repo and trying to hack around with it a bit to see if I can add support for this. Do any of you have any thoughts on how I could do this?
I’d like to be able to add something like <window transparent=“true”/> or if we do <window background=“null” /> in the project.xml file it would basically set the os window to be transparent.
@jgranick - Very strange result from Flash:
var s: Sprite = new Sprite();
var t: Transform = new Transform(s);
trace(t.colorTransform);
trace(t.concatenatedColorTransform);
trace(t.concatenatedMatrix);
trace(t.matrix);
//(redMultiplier=1, greenMultiplier=1, blueMultiplier=1, alphaMultiplier=1, redOffset=0, greenOffset=0, blueOffset=0, alphaOffset=0)
//(redMultiplier=1, greenMultiplier=1, blueMultiplier=1, alphaMultiplier=1, redOffset=0, greenOffset=0, blueOffset=0, alphaOffset=0)
//(a=5, b=0, c=0, d=5, tx=0, ty=0)
//(a=1, b=0, c=0, d=1, tx=0, ty=0)a = d = 5 ?? WTF :worried:
Anyway, obviously that can't be correct? Also, of course, this is not the output from OpenFl.
Wow.... what funky behaviour!! Adding the Sprite to the stage normalizes the values :worried:
var s: Sprite = new Sprite();
addChild(s);
trace(s.transform.colorTransform);
trace(s.transform.concatenatedColorTransform);
trace(s.transform.concatenatedMatrix);
trace(s.transform.matrix);
//(redMultiplier=1, greenMultiplier=1, blueMultiplier=1, alphaMultiplier=1, redOffset=0, greenOffset=0, blueOffset=0, alphaOffset=0)
//(redMultiplier=1, greenMultiplier=1, blueMultiplier=1, alphaMultiplier=1, redOffset=0, greenOffset=0, blueOffset=0, alphaOffset=0)
//(a=1, b=0, c=0, d=1, tx=0, ty=0)
//(a=1, b=0, c=0, d=1, tx=0, ty=0)
hello. can anyone help? i want to configure project.xml with additional xmls. When i put the additional xml in the root directory and types <include name='my.xml' /> all works. When my.xml is in the other directory <include name='folder/my.xml' /> it does not work. Paths like ./folder/my.xml didnt work too.
haxe 3.4.2 openfl 6.5.0
For anyone interested, we know have a Discord chat too :)
@PluginIO Here's what we use internally
Is that too naive?
@AlexFrost47rus I forget if included files are relative to the root project, or relative to the included file
you should be able to get them from a subdirectory
@jgranick about xmls - all is okay now. I just didnt realized the order. If the main xml has some variables installed then the included xml cannot overwrite it. So i didnt get it that time.
@jgranick to my mind its a weird behaviour. Documentation said that the last value will be used. And with the included xml's this is not right.
The situation in short is that I have a buffer of 30 floats, which are interleaved x/y/u/v/color data (times 6 for 2 triangles), and I'm having a lot of trouble accessing that data in my shaders
I used the GL.vertexAttribPointer as per usual, using indexes returned by GL.getVertexAttribLocation ("aPosition" for the first two, "aTexCoord" for the next two, and "aColor" for the last one)
And while this all works great on any non-HTML5 target, said target in particular gives off a weird behaviour where "aPosition" and "aTexCoord" in my shaders both hold the same values, and where I'm not sure what "aColor" holds
Since the WebGL-based functions are different than the OpenGL-based ones, are there any quirks I'm supposed to be taking care of that is way different from how we do with OpenGL ? Basically right now I'm just using conditional compilations to turn all the unavailable bufferData and bufferSubData OpenGL calls into their WebGL-enabled equivalents, with similar parameters
eg :
#if (html5 && lime >= "5.0.0")
GL.bufferDataWEBGL(target, srcData, usage);
#elseif (lime >= "4.0.0")
GL.bufferData(target, size, srcData, usage);
#else
GL.bufferData(target, srcData, usage);
#end
Also for reference the buffer is X/Y/U/V/color (2 floats for position, 2 floats for texture coordinates, one 4-byte int for color) and the actual values right before GPU upload are :
Where the NaNs are just the integer 0xffffffff being displayed as a float (because typed arrays). All of this data is being described properly with
100 0 0 0 NaN 612 0 1 0 NaN 100 128 0 1 NaN 100 128 0 1 NaN 612 0 1 0 NaN 612 128 1 1 NaNWhere the NaNs are just the integer 0xffffffff being displayed as a float (because typed arrays). All of this data is being described properly with
GL.vertexAttribPointer (since this whole thing works as intended on non-HTML5 targets)
Again, the issue is that on HTML5 only,
aTexCoord and aPosition seem to read off the same bytes although they have been declared as different vertex attrib pointers
and I don't know what
aColor is doing, but it's probably the same problem
I'll try and get a reproducible example by tomorrow