OpenFL3 problems and thoughts

#1

especially @singmajesty

OpenFL 3 is “set” to stable with the new 3.0.1 (no alpha or beta tags). This is great!
I’m happy this big effort is put to go Next and have a better OpenFL, thanks a lot for that.

But here I have to talk about the downside of this transition.

My haxelib

lime: 2.2.2 2.3.0 [2.3.1]
openfl: 2.2.8 [3.0.1]

Minors

A lot of stuff changed, and some API as well. This is normal and it is not a big deal since I can see the errors, check the API docs or even the source very easily. Annoying but necessary.

TextField

Issue #583
Still having issues with Text. For example alignment problems if different from LEFT, but there are many other. I suppose the TextField is an hard matter.

Matrix

Issue #555
The Matrix transformations (displayObject.transform) are not working as expected.
The skew is not applied at all.

Slowness

If just a simple app with just a Main.hx there are no difference. But I am experiencing lots of problems with more complicated environments that loads stuff at the boot.
The app freeze a takes long time to start (5s) when it is no more than 1sec on Legacy.
After that trying to animate the translation (with Actuate) on sprites is quite slow (when fluid on Legacy).

Scaling sprites

The quality of the scaling in Legacy was not amazing actually. Quite sharp also with smoothness to true. Flash handle that beautifully, OpenFL on other targets not so much. I’ve avoided the problem using multi-res graphic assets (also to optimise memory consumption)

In the new Next the scaling are quite blurry instead. Actually too blurry. Have you change the renderer? I suppose is OpenGL 100% now. Are you applying any filter or shader when a bitmap is scaled with smoothness=True?

Hybrid

This new hybrid compile is great. It should help a lot when people rely on some old library.
I suppose that both Next and Legacy will be compiled and the payload of your app will increase. Am I right?

Conclusion

Are you experiencing problems as well with the new OpenFL or am I not following a good practice to handle this transition?
Is it OpenFL 3.0.x ready for production? I feel like not so much.
I was thinking about new developers: could they be keep away from embracing OpenFL trying the new 3.0 and experiencing problems without knowing the previous stable environment?

PS: This post is not intended as a complain but rather as some thoughts and highlights of current problems to open a discussion and understand better the project current status.
I really appreciate all the work around OpenFL and his great community :wink:

1 Like
#2

In my personal experience, I have some trouble with the new release on native, the app just crash at start. I don’t know what its happening, but to be fair I didn’t had the chance to look at it.

I do understand the concerns about newcomers but I think the new addition of conditional compilation in the project.xml solved the problem, specially if you are using flashdevelop were you can’t change the compilation command.

The changes in the architecture are not minor, so we cant expect 100% stability and compatibility. I think this changes will make a huge difference in maintaining and supporting the code. So this transition state is a small price to pay for some awesome new times.

#3

The changes in the architecture are not minor, so we cant expect 100% stability and compatibility.

Doesn’t that mean exactly what the top poster is saying, that OpenFL3 doesn’t seem to be stable enough to be out of Beta? It seems like legacy should be the default behaviour while the new version should be explicitly enabled, since due to the existing problems it should probably be used only by experienced devs that know exactly that they want the new version even if it performs poorly for some things, or is buggy in others.
Currently everyone running haxelib upgrade or anyone that is starting with the platform, will be faced with slowness and lack os stability, and possibly be put off by it.

2 Likes
#4

I think you are right but that is not easy to understand if you just approached OpenFL. I think about myself two months ago when I’ve started using OpenFL. Testing performances and problems are the first thing you do when you are look if something suit your needs.
This is why I decided not to use the beautiful HaxeFlixel and HaxePunk. They are great, but I can get better performances with an ad-hoc library written by myself for my needs.

In the same situation (testing a new tool to see if I want to use it) now probably I would have rejected OpenFL, when in fact it is a great “framework”.

I am digging in the snowkit framework lately because I like the approach and the cleaningness. That is still in alpha stage and is clearly highlighted. I hope it will grow and flourish because I like it, but I’ve judged that based on the alpha status.

Maybe this is just bullshit and I am overthinking. It was just a thought I wanted to share with you guys :wink:

PS: I think mlopes got my point perfectly.

1 Like
#5

I said in the blog post that OpenFL was being promoted from the “beta” flag, because some newer versions of haxelib distribute with a setting to install stable version numbers only. As a result, it is installing the latest Lime with OpenFL 2.2, which are not compatible. This version of haxelib also does not upgrade to a new OpenFL beta release until you manually insert the version number.

It is a chicken-and-egg problem. I have been workinig on the new OpenFL for over a year. While we have been under OpenFL 2.x, legacy has been the default. During this time, I’ve developed the new version while I’ve maintained the older version. While the legacy version is default, bugs continue to be filed, and no one reports issues or fixes (generally) to the new code. The code comes with a promise, but unfortunately the legacy code is a promise I cannot keep, as some major issues have consumed hours of my time and were never resolved. The updated architecture already made a number of these problems easy to fix.

I know this is a difficult transition.

-Dv2 or -Dlegacy should provide full backward compatibility

-Dhybrid should provide half-way support between the older OpenFL and the newer Lime 2 backend, enabling the new Lime features and making it simpler to transition

I’m not sure what else you think should be done. I really appreciate the feedback, and hope OpenFL has been a benefit to you

4 Likes
#6

I think here you make a point (I haven’t thought about), and a very strong one.
Looking at the topic from this point of view makes the situation quite different.

Actually this move could speed up the reach of a more stable stage of OpenFL3.

Maybe, if I can express it without seem annoying, you could blog more about the development to keep people aware of the situation (what are you working on, what needs more…)
I would really appreciate that.

Thanks for the answer josh :wink:

1 Like