Thanks, I’ll take a look at these. Could you try using the latest versions (2.2.1, 3.0.0-alpha) but adding “-Dv2” or “-Dlegacy”, and confirm that things still work there as it did before?
Make sure you use -Dv2 or -Dlegacy from the command-line, not your project file. If you need to modify the project file, use <set name="openfl-legacy" /> before you use <haxelib name="openfl" /> and do not include <haxelib name="lime" /> in your project
I believe <window antialiasing="" /> is not hooked up in the newer code, this is helpful to know
What <window background="" /> value are you using that does not look correct? Did this occur on all platforms, or only some platforms?
Could you share an example of the type of code that would reproduce disappearing sprites with rotation?
The “AddingText” sample should work, perhaps the issue is that default “_sans” text is not supported (which should be addressed)
The difference in Nape use, does that mean that a value in OpenFL was now using radians or degrees where it should have used the opposite? Do you know which API?
The lag is a known issue of using the Neko target. Been considering whether to use a different testing target that is faster (HTML5 and C++ don’t do this)
Tested on neko, Linux, Android. It looks like only 00 and ff are accepted for individual RGB values, meaning:
0x000000, 0x808080, 0xfefefe - all produces the same black background (looks like 0x000000)
0xfffefe - produces red (looks like 0xff0000)
0xfffffe - produces yellow (looks like 0xffff00)
etc.
And 0xffffff is full-white as it should be.
I can try to isolate some code, and post here if I succeed.
Indeed, unchanged “AddingText” sample displays text, but changing font to eg. “Arial” desn’t display it.
Its about changing Nape’s rads to Sprite.rotation (or back), the formula looks like this: sprite.rotation = body.rotation * 180 / Math.PI;
the bug is that the sprite rotates the other direction now, so “fix” is using minus
P.S. I updated Haxe to 3.2.0, but that doesn’t make any difference.
Sprites are being “cut” depending on the angle of rotation:
Whats interesting, is at the option 2 (in onEnterFrame), when there is the same rotation angle for every Sprite, whole Window is being “swept” with 1 moving line:
The Sprites re-appear the same way.
If it helps I could capture animation to some videclip