Problems after lastest update on Linux (3.0.0-beta and Lime 2.2.1)

Since latest update I’m having some dispaly issues on my Linux box:

  • Some <window> settings not working (eg. antialiasing - looks like its always off, background - has no effect or different color as set),
  • Sprites disappearing semi-randomly after rotation,
  • TextFields are not appearing at all (including openfl.display.FPS),
  • using Nape Physics Engine rotation conversion of object requires now - (minus) value (conversion from rads to degrees),
  • Window creation is lagged (window decorations, top-bar and frame is visible with empty window content for about 0.5-1s.

Tested with different targets (neko, linux, android) and of course with openfl-samples. Anyone experiencing such issues now?

I tried to restore previuos versions of libs and Haxe itself, but ended up at removing everything and reinstalling newest versions, so now I got:

$ haxe -version

$ haxelib list
actuate: [1.8.3]
box2d: [1.2.3]
haxelib_client: [3.2.0-rc.3]
hxcpp: [3.2.37]
layout: [1.2.0]
lime-samples: [2.2.0]
lime: [2.2.1]
monax: 1.4.0 [1.5.1]
nape-symbolic: [2.0.1]
nape: [2.0.16]
openfl-samples: [2.2.2]
openfl: [3.0.0-beta]
Parsex: [1.4.0]
swf: [1.8.0]

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?

I tried those too, sorry I didn’t mention it earlier - using v2 and legacy makes no difference.

I also tried changing whatever I could, eg. in windows: vsync, hardware, allow-shaders, fullscreen, resizable…

Also with some projects, on default -dce (without it) compilation fails with return code 1 and error:

Uncaught exception - [email protected]_read

Probably depending what libs is the project using.

P.S. Another glitch: setting stage.frameRate has no effect.

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

Oh, I din’t know that!
Indeed, using “legacy” properly fixes the issues.

P.S. Thanks so far, at least I can keep coding :smile:

Going through the issues

  • I believe <window antialiasing="" /> is not hooked up in the newer code, this is helpful to know :smile:
  • 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)
    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 :smile:

P.S. I updated Haxe to 3.2.0, but that doesn’t make any difference.

Ok, looks like its easy to reproduce - rotating a Sprite thats all what it takes indeed.

import openfl.display.Sprite;

class Main extends Sprite {

    var sprites:Array<Sprite> = new Array();

    public function onEnterFrame( {
        var i:Int = 0;
        for (sprite in sprites) {
            // option 1:
            sprite.rotation = sprite.rotation + ++ i;
            // option 2:
            // sprite.rotation = sprite.rotation + 1;

    public function new () {
        super ();

        var i:Int = 0;
        while (i ++ < 100) {
            var sprite:Sprite = new Sprite();

            sprite.x = Math.random() * stage.stageWidth;
            sprite.y = Math.random() * stage.stageHeight;

                (Math.round(Math.random() * 127) << 16) +
                (Math.round(Math.random() * 127) << 8) +
                (Math.round(Math.random() * 127))

            var size:Float = Math.random() * 20 + 40;
   size / 2, - size / 2, size, size);



        stage.addEventListener(, onEnterFrame);

I made no changes in project.xml:

<?xml version="1.0" encoding="utf-8"?>
    <meta title="CrazySprites" package="com.sample.crazysprites" version="1.0.0" company="Company Name" />
    <app main="Main" path="Export" file="CrazySprites" />
    <source path="Source" />
    <haxelib name="openfl" />
    <assets path="Assets" rename="assets" exclude="openfl.svg" />
    <icon path="Assets/openfl.svg" />

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 :slight_smile:

1 Like

Thanks for the example!

The background color should be fixed, as well as _sans as system font handling as well. We’ll look into the rotation issue, thanks :slight_smile:

Sorry, my bad, I screwed up the matrix calculations :sweat_smile: it should be fixed on git

Thanks for fix, I’m waiting for zipped build… :wink: