openfl
[Flash] Starling doesn't compile with Haxe 4.0 with Air or Flash target
Haxe 4.0 change the definition of flash.util.Object from a typedef to an abstract. On flash (and only flash), that is the underlying object for openfl.utils.Object.
That prevents it from being usable as a Dynamic so these errors prevent compilation/transpilation:
D:\temp>openfl create starling:demo
D:\temp>cd demo
D:\temp\demo>openfl test air D:/HaxeToolkit/haxe/lib/starling/2,5,1/src/starling/events/TouchProcessor.hx:265: characters 33-38 : openfl.utils.Object has no field touch D:/HaxeToolkit/haxe/lib/starling/2,5,1/src/starling/events/TouchProcessor.hx:265: characters 67-73 : openfl.utils.Object has no field target D:/HaxeToolkit/haxe/lib/starling/2,5,1/src/starling/events/TouchProcessor.hx:266: characters 49-60 : openfl.utils.Object has no field bubbleChain D:/HaxeToolkit/haxe/lib/starling/2,5,1/src/starling/core/Starling.hx:1075: characters 58-68 : openfl.utils.Object has no field horizontal D:/HaxeToolkit/haxe/lib/starling/2,5,1/src/starling/core/Starling.hx:1076: characters 56-64 : openfl.utils.Object has no field vertical D:/HaxeToolkit/haxe/lib/starling/2,5,1/src/starling/core/Starling.hx:1021: characters 95-105 : openfl.utils.Object has no field horizontal D:/HaxeToolkit/haxe/lib/starling/2,5,1/src/starling/core/Starling.hx:1022: characters 93-101 : openfl.utils.Object has no field vertical D:/HaxeToolkit/haxe/lib/starling/2,5,1/src/starling/core/Starling.hx:1044: characters 29-39 : openfl.utils.Object has no field horizontal D:/HaxeToolkit/haxe/lib/starling/2,5,1/src/starling/core/Starling.hx:1045: characters 29-37 : openfl.utils.Object has no field vertical
There doesn't appear to me any reason to use openfl.utils.Object in those two files. Just using Dynamic or DynamicAccess should suffice, or simply a StringMap
It's true openfl.utils.Object has been an abstract, but not the underlying ObjectType. I believe the change that broke this is in Haxe libraries made Jul 15, 2019, specifically this commit: https://github.com/HaxeFoundation/haxe/commit/fa57afc807819b3983f142c633589c2ff294a9bd
The flash.utils.Object in Haxe was changed from:
typedef Object = Dynamic
to
abstract Object from Dynamic to Dynamic {}
Perhaps it is an issue of taking an abstract of an abstract, but for whatever reason openfl.utils.Object can no longer be used as a Dynamic under flash.
The openfl.utils.Object definition changes depending on whether "flash" is defined. It is based on ObjectType. This has not changed but you can see when flash is defined it is just a typedef for flash.utils.object
from https://github.com/openfl/openfl/blob/develop/src/openfl/utils/Object.hx:
#if !flash
@:dox(hide) @:noCompletion typedef ObjectType = Dynamic;
#else
@:dox(hide) typedef ObjectType = flash.utils.Object;
#end
Because of the change to the haxe libraries with 4.0, starling no longer compiles for flash target. It's simple enough to show this.
After a little more investigation, it appears to be because the new Haxe definition of flash.utils.Object does not include @:forward
It's important to note that the flash target has been depreciated since haxe 4. Adobe has EOLed flash.
Edit** So its actually not true that the flash target was being depreciated for haxe, this was a misconception on my part.
@Gama11 https://github.com/HaxeFoundation/haxe/issues/3549
Why close the issues and say they're not going to fix flash related bugs if it's not being depreciated?
To me, "deprecated" means it's planned to be removed soon (like the Java target that will probably be replaced with the JVM target sometime in the future). This is currently not the case with the SWF target.
How do you even debug flash without flashplayer or browser? All majors browsers and operating systems are completely removing flash at the end of this year.
https://docs.microsoft.com/en-us/lifecycle/announcements/adobe-flash-end-of-support
regardless, this isn't a Haxe issue, really, and it doesn't just impact Flash, it impacts AIR. Haxe made a breaking change but it should probably be fixed both in OpenFL and Starling. Starling is making some assumptions about openfl.utils.object that are not documented.
@hunkydoryrepair sorry a bit confused, I thought you mentioned the issue was for flash only.
On flash (and only flash), that is the underlying object for openfl.utils.Object.
well, only when "flash" is defined, which happens to also be the case for the AIR target, apparently. The original bug title and the original reproduction steps refer to AIR.
@Dimensionscape What do you mean "without Flash Player"? The (debug) standalone flash player is a thing, you don't need a browser. :)
@Dimensionscape What do you mean "without Flash Player"? The (debug) standalone flash player is a thing, you don't need a browser. :)
How do you get the standalone flash player when:
- adobe no longer serves it at the end of this year
- no one has a license to distribute it
- there are no serious open source alternatives
Are you sure they're going to kill the download links? I can't imagine that would be the case... And even if so, and even if nobody has the license to distribute, you would definitely be able to still get it from somewhere...
Are you sure they're going to kill the download links? I can't imagine that would be the case... And even if so, and even if nobody has the license to distribute, you would definitely be able to still get it from somewhere...
I don't know why it comes as a surprise, they did the exact same thing after shockwave player was EOLed last year, and trust me, you wont find an official adobe link for Director or Shockwave (ok so I guess you can still get shockwave player for a limited time even though they verbatim said it would no longer be available after april 9,2019) anymore. https://helpx.adobe.com/shockwave/shockwave-end-of-life-faq.html
Effective April 9, 2019, Adobe Shockwave will be discontinued and the Shockwave player for Windows will no longer be available for download.
But we have come to a full circle. It doesn't make sense to support a target in which you have to pirate the the software to run and debug it. It also doesn't make sense to claim a target is supported when all of the related issues have been closed(with a disclaimer that they will no longer address flash bugs) so that independent developers cant become aware and fix them. When you deliberately stop supporting something, it becomes depreciated, in all sense of the word, unless you actually believe that one day they are going to wake up and have the funds to start supporting flash again and resume addressing flash bugs and open issues.
Anyway, we're beating a dead horse. AIR is still a viable target for the foreseeable future, I'll take a look at this further -- I have not used the AIR target in a long time.
Perhaps you should regress to haxe 3.4 in the mean time.
Sorry to get so far off topic. Anyways I was under the impression that haxe was following the same eol timeline given the circumstances and the bits of information gleaned from around the community and github responses.
At any rate, shouldn't it implement flash's Object after transpilation? Is this a haxe issue or an openfl issue. Gonna go reproduce and see whats up.
var object:Dynamic = new openfl.utils.Object(); solves the issue in the interim.
Actually, I created a base starling project without the changes and it compiled and ran just fine in flash player. I made sure to draw the starling stats and a button which utilizes the touchprocessor that was giving you an error.
package;
import starling.text.TextField;
import openfl.display.Sprite;
import starling.display.Button;
import starling.display.Sprite;
import openfl.Lib;
import starling.core.Starling;
import starling.events.Event;
import starling.textures.Texture;
class Main extends openfl.display.Sprite
{
public function new()
{
super();
var starling:Starling = new Starling(starling.display.Sprite, this.stage);
starling.addEventListener(Event.ROOT_CREATED, __onInit);
starling.showStats = true;
starling.start();
}
private function __onInit(e:Event):Void{
var starlingRoot:starling.display.Sprite = cast Starling.current.root;
var text:TextField = new TextField(100, 26, "Hello World");
var button:Button = new Button(Texture.fromBitmapData(text.drawToBitmapData()));
starlingRoot.addChild(button);
starlingRoot.stage.color = 0xFFFFFF;
}
}
Compiled with no problem haxe 4.0.5
I don't see how that's possible. I did a test on a simple abstract of dynamic without @:forward and it does not allow arbitrary properties, which starling uses. I tried your class and it gives the same errors. Of course, I don't have your hxml file, so maybe a difference there?
I have removed and reinstalled the starling and openfl libraries to verify. I had modified two of the files to workaround the issue so I had to revert to reproduce the problem.
Haxe --version gives 4.0.5 These are my library versions: D:\temp\test151> haxelib list actuate: [1.8.9] away3d: [5.0.9] box2d: [1.2.3] flixel-addons: [2.8.0] flixel-demos: [2.7.2] flixel-templates: [2.6.4] flixel-tools: [1.4.4] flixel-ui: [2.3.2] flixel: [4.6.3] hscript: [2.3.0] hxcpp-debug-server: [dev:c:\Users\garr.vscode\extensions\vshaxe.hxcpp-debugger-1.2.4\hxcpp-debug-server] hxcpp: [4.0.64] hxnodejs: [12.0.0] layout: [1.2.1] lime-samples: [7.0.0] lime: [7.7.0] openfl-samples: [8.7.0] openfl-tools: [1.0.10] openfl: [8.9.6] perf.js: [1.1.8] pixijs: [4.8.4] starling: [2.5.1] systools: [1.1.0] thx.core: [0.44.0] thx.culture: [0.5.0] thx.format: [0.6.0]
With every library updated, I'm still having the same problem. Is there any fix on this issue?
@devezas and @hunkydoryrepair have you tried the current latest commit on master?
https://github.com/openfl/starling/commit/02dbf8d9725c406fe76819cc631cf1a02b31c5c1
When using this entry in my haxelib.json Starling has compiled fine for me for the past few months: (I'm using Haxe 4.1.3 w/ OpenFL 8.9.6 and lime 7.8.0)
"starling": "git:https://github.com/openfl/starling.git#02dbf8d9725c406fe76819cc631cf1a02b31c5c1"
I noticed the latest release 2.5.1 has not been updated in quite some time (I'm not sure why either because master appears stable). Regardless of Flash being deprecated or not, compatibility with OpenFL and Haxe 4 seems important so I'm surprised a new release hasn't been tagged 🤔
Yes, the master with the latest commit works.
I believe that a new release using this master is needed, because anyone that only rely on haxelib releases will have a hard time to compile do Air/Flash.