Upgrade to OpenFL 3 broke two of my projects

Help
#1

Hi! I recently upgraded upgraded to OpenFL 3.0.2 and Lime 2.3.2 and got bad results. First of all, in one of them, that made heavy use of beginGradientFill, the effect is simply gone. And on the other, that had several Shapes being used (lines, curves, rectangles …) is very slow on native targets and segfaults when targeting neko.

I understand that such a major review in the API should bring instabilities. However, I saw the blog post and the roadmap for this new project version and these problems are not addressed in any of them. I would like to ask, if possible, for a list of features that are unstable or that we, as OpenFL users, should avoid. I reckon that it would also help those interested in contribuiting to the project to find the areas of the code that most need help.

#2

You can still get the last version behavior with -Dlegacy,
openfl test neko -Dlegacy.

#3

Or to keep them permanently using the legacy code you can add:

<set name="openfl-legacy" />

in your project.xml. This way you can use the default build options in your IDE but it will compile with the legacy code.

#4

Thank you for the quick replies. I forgot to mention, but I am already doing this.

However, I would like to keep using the latest version of OpenFL on my projects. I want to know what changed so I can contribute to the OpenFL project, at least with the features that I am missing.

#5

Openfl is now written entirely in haxe on top of the new lime code.
The new lime was made to be usable on its own and has now a completely different architecture than before.

So most code changed, which is one of the reasons things don’t behave exactly like before.

1 Like
#6

If there are any regressions using -Dv2/-Dlegacy, please let me know! The goal is to be able to continue to build your existing projects using the latest libraries, while the new codebase continues to develop

Is everything working fine on legacy, then, and we’re talking about the new code only?

#7

Yup, the problem happens only with the new codebase. Everything works on legacy!

#8

Would you mind trying HTML5? It uses the new codebase, but a canvas-based renderer by default, which helps separate issues with the new code vs. new GL renderer

I added gradient fill support to canvas recently, but it has not made it’s way to the new GL renderer yet. In the legacy GL renderer, it would use software if you used bitmapData.draw or cacheAsBitmap, which made it possible to use software-drawn shapes (with antialiasing) when desired. I’m debated whether we should have a software render path on native. Also, the newer GL renderer (I believe) uses stencils in GL in order to get better masking and support for certain complex shapes, but I’m not sure if it performs as well for basic squares or circles. That’s another thing we could think about

#9

I am very sorry it took so long for me to answer.

The HTML5 version worked like a charm!

#10

Okay, great! This is a very good sign :smile:

We’ll continue to work on the newer native renderer to bring it fully up-to-speed :slight_smile: