Import openfl or flash? - newbie question -

#1

I am the newbie of the week :smile:
I have studied the Pong tutorial and noticed that in the Main class it is importing

import flash.display.Sprite;
import flash.Lib;
etc...

while other classes are importing

import openfl.display.Sprite;
etc...

What is the difference? In the complete tutorial I am importing all flash.* classes. I read OpenFl mimics AS3 DisplayList architecture, but I didnā€™t think it could also import and use its classes directly! Am I missing something? Does this mean that I can import other AS3 classes likeā€¦ greensocks?

Thanks

Why most of open-fl samples use flash package, but not open-fl package itself?
Openfl objects and flash objects in the same project
#2

Before all classes were in the flash.* package with the exception of a couple of classes openfl added.
But people were confused about using say flash.Lib when they wanted to target neko or html5.
So now everything is in the openfl.* package though there is an alias for the flash package to still work for backward compatibility reasons.

You canā€™t just import AS3 classes, but you can make an extern, basically the same thing as a class except the functions donā€™t have code, which tells the compiler that the class will exists. And you associate that with a swc which you can link to your swf (so flash target only).

#3

Ok, now it is clear, I have to use openfl.* to be uptodate :wink:

For what concerns SWC, well, it is clear Iā€™d better use native HaXe code, otherwise I would create projects totally dependent from Flash platform, and I couldnā€™t target the other ones without a lot of adaptation work.

#4

The openfl package also allows us to make little adjustments to the Flash API, such as graphics.drawTiles :slight_smile:

#5

How is drawTiles converted when targeting Flash? copyPixels?

#6

drawRect or drawTriangles, Iā€™ve been thinking of a Tilesheet API re-design that allows for a BitmapData and copyPixels for Flash, rather than using a Graphics object, but currently thatā€™s done in a few third-party libraries.

This is just a little example, there are other cases where we can make small additions and make them consistent with Flash (object equality still works, but we snuck a few inlined add-ons into it) and to hide methods and properties that are only supported in Flash

#7

ā€¦while flash.* are 1:1 mirroring/wrapping without cute additions, right?
Ok, now it is clear, I just have to study these openfl.* bonus features.
Thank you!

#8

Sometimes.

If you type flash.* and compile for Flash, you wonā€™t get any bonus features.

If you type flash.* and compile for Neko, Android, HTML5, etc., youā€™ll get all the bonus features, because the compiler will remap ā€œflashā€ to ā€œopenfl.ā€

#9

And similarly:

If you type openfl.* you will get code completion that is (increasingly) consistent across all targets. If you use flash.* (depending on your editor) you may be provided with additional options that are specific only to Flash, and will break your build when you change targets, so it goes both ways :slight_smile:

#10

This means I am safer with openfl.*?

#11

Yep, weā€™re heading towards where everything openfl.* gives you in code completion works consistently on all platforms. Itā€™s what Iā€™d recommend :slight_smile:

#12

UNLESS ā€“ you are writing a Haxe library, which is intended to work either for OpenFL or for standard Flash projects. In which case, using flash.* will make it work for both environments. Thatā€™s the real time Iā€™d consider using import flash instead

#13

Uh, maybe flash.* will be the initial choice then: if we add HaXe+OpenFl to the workflow we will need to keep AS3 projects and HaXe as parallel as possible, unless we definitely leave AS3 for HaXe, but it would be a very big jump.

#14

Well, that ā€œunlessā€ is only if you plan to use Haxeā€™s Flash target, without using OpenFL. If you are writing in Haxe already, why not using OpenFL? It extends the same API to HTML5 and native targets, so I donā€™t think it would be a detriment.

#15

Well yes, youā€™re right, we could definitely go with OpenFl.
Today I explained my idea of introducing HaXe (with OpenFl) in the workflow: letā€™s see what happens, then we will decide how to proceed.

#16

what about mx packages? should we also change it to openfl ? can we do that also ? the targeted output is html 5

#17

There is some work to support the ā€œflā€ package in under the draft APIs for OpenFL (available if you <define name="draft" /> before <haxelib name="openfl" /> in your project or openfl test html5 -Ddraft) but none for ā€œmxā€ (though weā€™d accept them)

I see Haxe header files for Flex 4.1 on the internet but Iā€™m not sure if we have a real port as Iā€™m not sure if the ActionScript sources were ever available in open-source outside of Apache Royale (but perhaps Iā€™m wrong?) though a subset of Flex might not be hard to support depending on how much you need