Direct comparison of medium sized game Flash/AS3 vs. OpenFL/Haxe + Issues

#123

That’s awesome! Great to hear!

2 Likes
#124

Hi,

I have a stupid question.
How to quit a OpenFL/Android Application when OpenFL application is build for Android/iOS?

Many thanx and

Best regards
Andreas

#125

I am using the Android API moveTaskToBack method.

1 Like
#126

We have lime.system.System.exit (), but it might be disabled on iOS/Android, as killing an application is discouraged on these platforms. If there is API access to backgrounding the application, it would be great to support this

1 Like
#127

Hi,

I really want to quit the application!
So I might try “lime.system.System.exit()” first.

Any additional hints are highly appreciated.

Many thanx and

Best regards
Andreas

#128

Hi,

I have a short question. I have some code that originally produced a animated glow filter by changing filter strength over time.

See here

This used to work for a while but now it stopped working.
Is it possible that bitmap cache is not getting reset on setting filters or such?
How to invalidate it? Or is there maybe something else wrong?

No idea.

Many thanx and

Best regards
Andreas

#129

Yes, it’s possible that our dirty algorithm is not catching the changes. We used to render every frame, but increasingly rely on caching to know whether to flip frame buffers. Try running invalidate () on your object each time the filter changes, and see if that helps? If you think there’s a way for us to automatically detect a dirty render here (and we aren’t), let me know

1 Like
#130

Hi,

I investigated a bit. Is it possible that you guys changed GlowFilter? Strength does not seem to have a effect anymore. Only blurX and blurY affect the bitmap.

invalidate() is required as you said. Before the display object was rerendered after DisplayObject.filters = someNewFilterArray. This is also what I got from api.openfl.org.

Many thanx and

Best regards
Andreas

#131

Seems like DisplayObject.invalidate() is not required. Hmm.

This works now:

#132

We did add hardware support. Does using -Dcanvas on your project (just as a test) make a difference in the appearance of the filter?

#133

Hi,

nice to hear. In the openfl “8.4.1-LlyE3A”?. With -Dcanvas the appearance is much different. Some objects with filters or without(need to debug) are even not rendered at all. If you want details I can dig this a bit.

So is the hardware acceleration available for filters with -Dcanvas or without -Dcanvas?

Best regards
Andreas

#134

What about -Dopenfl-disable-gl-cacheasbitmap instead?

#135

with “-Dopenfl-disable-gl-cacheasbitmap” it looks wrong and similar like with “-Dcanvas”.

#136

I can create videos of all 3 builds if required.

#137

Hi,

I have a GlowFilter related bug. See this video:

Just see the ships on world map. First time and second times the GlowFilter on them do work, third time not :frowning:

Many thanx and

Best regards
Andreas

#138

Is this with dev, or the latest release?

#139

I updated via

    haxelib update openfl
    haxelib update lime

some days ago.

#140

Okay, I think that cacheAsBitmap (used by filters) had a regression that’s resolved in the dev builds

#141

Hi,

ok. Thank you! How can I test the dev build?

Many thanx and

Best regards
Andreas

#142

Here’s the directions for Lime:

You might not need a dev version of Lime, though.

Here’s the directions for OpenFL (which is simpler):

1 Like