Getting started with Haxe and Starling

Haxe
#1

Hi all. I recently built a sample mobile app with Adobe AIR + Starling in AS3, which worked well. You can see the code on github:

I’m trying to port this to Haxe + Starling but I’m not sure where to start. I’ve downloaded the latest FlashDevelop and created a new AIR Haxe app, and added the “starling” under project properties > Libraries.

How do I instantiate starling for Adobe AIR? Please note I’m NOT looking at publishing for HTML or any other targets, just Adobe AIR Desktop and Mobile. I’m not sure about OpenFL but I’d rather use Starling as I’m more familiar with the codebase and I’m specifically targeting the AIR platform, so I don’t need the “multi platform” features of OpenFL.

Thanks,
Zac

#2

Hey Zac Devon Welcome :smiley:

So First let me Clarify some Things Starling is built on Top of OpenFL so you need both Libraries as well as Lime which is the SDL equivalent for OpenFL.

You didn’t Mention anything About HaxeLib but If you’ve setup an Adobe Air application Already Then I assume you’ve already gotten OpenFL and Lime setup.

In Order to Get Starling you just need to open up Terminal/CMD and type

haxelib install starling

and then add into your project.xml like so

haxelib name=“starling” with the same xml Formatting as the set openfl haxelib name or lime.

Hopefully this helps in adding Starling if you need help understanding how to initialize look at it’s github page and look through some demo code.

1 Like
#3

Hey PX, thanks for the swift reply. I want to build an AIR app using Starling. I don’t understand why OpenFL is required, could you clarify? From what I understood OpenFL maps to the flash display list API in Flash/AIR (CPU rendered) and implements its own rendering on other platforms. I was looking at GPU rendered graphics which Starling excels at, so could you clarify where OpenFL fits on the haxling stack?

Also, I read some stuff about OpenFL being an alternative to Haxling, which I would have used but I wish to implement 3D graphics also, using Away3D or BabylonHx. Therefore I need a UI stack that accomodates that. I’m looking at building a primarily texty business app, with some 3D graphics here and there.

I have setup a new Haxe AIR app but FlashDevelop gave me only a .hxproj which contains the haxe XML options as well. I don’t have the project.xml exactly as you said. Mine currently looks like this: https://gist.github.com/zacdevon/ec906106cd905c31a8a5cb442e5c9038

Anyways I started porting my app to Haxe/Starling and it gives me the following errors:

image
image.png1047×431 40.1 KB

There are no compile errors in my code, and my current version looks like this : https://gist.github.com/zacdevon/5a26cc8020d5dd281d0b9bb406806517

I have included the following libs in my project : air3, starling, openfl, lime

All libs are up to date, and I’m using AIR 26 and Haxe 3.4.4

#4

Just to be on the same page. How did you install openfl? Did you follow the getting started page?

(running this)

haxelib install openfl
haxelib run openfl setup

can you run a sample?

on a console run

openfl create DisplayingABitmap
cd DisplayingABitmap
openfl test html5

What operative system are you running in your computer?

PS: As the original Starling runs on Flash (you can’t use it without flash), this Starling runs on OpenFL (you can’t use it without openFL).

OpenFL gives you a flash-like api for Lime.

Lime makes the hooks needed for you to use the different low level graphics api (Cairo, OpenGL, etc).

Haxe makes sure your code can be transpiled (like cross-compiled) into a lot of other formats (Including but not limited to: AIR, C++, JS, SWF)

#5

Thank you milton. I didn’t find that guide but did those 2 steps based on another guide. And yes, running the test displays the OpenFL Logo in HTML5. I’m running Windows 7 x64 and FlashDevelop 5.3.1, Haxe 3.4.4, AIR 26.

Just to be sure, the OpenFL Starling uses GPU rendering, right? And OpenFL without starling uses CPU rendering? Thanks for all the other explanations/clarifications.

I will upload my entire project to Github so you guys can see if it works on your end, and does not on mine.

#6

I have much less experience than everyone else here, and I’m sure someone will correct me if I’m wrong, but I think the way to think about this is to see the original Starling as just an AS3 framework that itself can’t add GPU support. It just leverages the Flash API to make the existing GPU support that the Flash API already provides (via Stage3D) more convenient to work with. The relationship is essentially the same on Haxe, with OpenFL and Lime together providing all of the underneath functionality with GPU support that Starling leverages in order to provide its own API.

This being said, I’m under the impression there are indeed differences between the original Flash and OpenFL in how they go about utilizing the GPU for the normal Display List API. I think OpenFL is designed to at least optionally take advantage of OpenGL/WebGL for the original Display List API on relevant platforms.

#7

Thank you everyone for the excellent explanations regarding the whole OpenFL stack. Its very confusing and even being a veteran I found myself unable to wrap my head around the most basic concepts. Perhaps the Haxe/OpenFL homepage could be upgraded to included a clearer stack diagram…

Okay I uploaded my simple Haxe/Starling test app. You can find it here:

https://github.com/zacdevon/StarlingDemoHaxe

These are the errors I get when I simply open the .hxproj in FD and build it:

image
image.png878×434 37.5 KB

1 Like
#8

Hey guys

I am sorry that there has been confusion here, I’ve been busy with the holidays, but I’m dropping in now to (hopefully!) help explain a little :slight_smile:

Haxe is a programming language. “Hello World” in C++ and JavaScript is possible, due to Haxe… but how do we get graphics and sound?

Lime is a library designed to provide a consistent “blank canvas” environment on all our supported targets, so Flash Player, HTML5, Windows, macOS, Linux, iOS, Android, and others have ported Lime to consoles and set-top boxes and other systems. Lime is our cross-platform graphics, sound, input, windowing and other components, which means OpenFL can focus on being a Flash API, and not handling all these specifics. Lime also includes command-line tools, which are pretty great.

OpenFL is the Flash API. It supports rendering in OpenGL, Cairo, Canvas and even HTML5 DOM. In the browser (for instance) OpenGL is our default renderer, unless the user’s browser doesn’t give us WebGL, so we fallback to canvas. Certain features (shape.graphics or bitmapData.draw) will use software, but others (such as the display list) remain GPU accelerated.

Starling runs on Stage3D, as well as Flash APIs (such as TextField, or the event model). Starling needs a Flash API to run. It uses our Stage3D implementation, and does not really use the OpenFL display list to work.

Have you tried the Starling sample?

haxelib install starling
openfl create starling:demo
cd demo
openfl test flash

There’s also a “particle-demo” included with Starling

2 Likes
#9

@zacdevon I just forked your repository, and made changes to help it compile. I wasn’t sure how some of the code was meant to translate, so I did my best. Now it builds and runs, and renders a grey screen. I’m sure there’s some piece of logic that is supposed to work a little differently?

I’m not sure if you’re using Starling 1.8 or 2.x, we have a stable port of Starling on haxelib, and a port of Starling 2 on the master branch on Github. I would test with Starling 1.8 first, if it doesn’t matter, or you can use the development version for 2 if you’re watchful.

Give it a try, now you should be able to run commands like this from the command-line:

openfl test flash
openfl test flash -debug
openfl test flash -debug -verbose
openfl test air
openfl test html5
openfl test windows

I also swapped out the FlashDevelop project file with one from another project, it should allow you to get some of these commands from the FlashDevelop UI, so you can drop-down and select a target platform, then Ctrl + Enter to build and run :slight_smile:

If you haven’t already, though, the existing Starling sample projects are a great example of something that already works and runs :slight_smile:

2 Likes
#10

@singmajesty Thank you for the technical info. Wikipedia updated. And the starling example works fine in flash (test flash) but crashes with some “missing sound asset” error in AIR (test air)

Big big thanks for forking my repo and taking the time and effort to go through my code and make it compile! There were some more compile errors (probably due to my newer and fussier haxe) but I was able to fix those trivially. Yes, all of your changes were perfect, including the addChild and Actuate.tween ones.

Debugging is now an issue. I have installed a debug flash player, and run the debug standalone player EXE to make it the default. Running in flash mode and debug mode in FlashDevelop shows “Internal Debugger Exception”. Running in air mode shows no errors, but no traces appear in the Output window either.

And when I run it from the command line, openfl test air -debug shows no logs. However, openfl test flash -debug shows my traces in the command prompt window, so I can debug (somewhat). I added that command as a post-built event in FD and I’m good to go.

So I can debug with flash but not with air. I will need AIR functionality soon since my app is dealing with files and stuff that only AIR provides. Is AIR debug support possible even with some freaky command line stuff?

#11

Thanks for finding that issue with the Starling sample! It was an easy fix:

As for debugging, openfl test flash -debug will compile using a Haxe debug configuration, and we will define fdb which creates a SWF that expects to connect to the Flash Debugger, if available. To my knowledge, openfl test air -debug creates the same kind of SWF, and runs it using adl when you target the desktop. We use adl configuration.xml -nodebug if you do a release build, but not on debug. I don’t think there’s anything additional needed?

Perhaps it is an issue of timing, in order to cooperate with an IDE that is expecting to debug the project. AIR support in OpenFL is somewhat new, so perhaps the IDE/debugger you are using is just not anticipating things correctly?

If it is FlashDevelop, perhaps “flash” has hard-coded behaviors that the custom “air” target does not in the IDE. I wonder if that would be hard to improve

I’m reading now about AIR trace output, and it looks like we might have a collision with our behavior on Flash Player:

Note: If your trace() statements do not display on the console, ensure that you have not specified ErrorReportingEnable or TraceOutputFileEnable in the mm.cfg file. For more information on the platform-specific location of this file, see Editing the mm.cfg file.

https://help.adobe.com/en_US/air/build/WSfffb011ac560372f20b57e08128cc91aa2f-7ffe.html#WS5b3ccc516d4fbf351e63e3d118666ade46-7f64

That’s exactly what we do on the Flash target, is ensure there’s an mm.cfg, and if not, we write one with both error and trace output enabled.

Do you know if AIR writes to the standard log output file when these are enabled? I believe I had tested and found that it did not, but perhaps I am wrong. If it does write to the log file (like Flash Player does) then we can tail that like we do on the Flash target

EDIT: It appears that openfl test air is printing to the console, but not openfl test air -debug.

I had a tail of the Flash log file running in a separate process, and it appears that neither command wrote to the same log file as Flash Player

EDIT 2: Actually, it appears that running ADL in debug mode is writing to the Flash Player log, but only on exit. That’s not super useful

1 Like
#12

@singmajesty Yes, all true. I tested with openfl test air -debug and no luck printing to the output window. My mm.cfg looks like this:

PolicyFileLog=1
PolicyFileLogAppend=0
ErrorReportingEnable=1
TraceOutputFileEnable=1

My app is finally working! I have pushed the final version to github, if you care to see how it functions. Thanks again…

#13

@singmajesty Can some please accept my PR so new users get a quick start project for starling/haxe/FD? https://github.com/openfl/starling/pull/81

It would prevent articles like this : https://www.gamasutra.com/blogs/TalhaKaya/20140407/214965/OpenFL__Haxe_A_Bumpy_Start.php