OpenFL 8.0.1 Update

I’m joining the ranks of those who have trouble updating to the latest version of OpenFL.
I just tried updating from OpenFL 7.1.2 and Lime 6.2.0 to OpenFL 8.0.1 and Lime 6.3.0 using:

haxelib install openfl 8.0.1
haxelib install lime 6.3.0

and if I try to compile a project - even a fresh empty one - the compiler moans:
haxetoolkit/openfl/openfl/8,0,1/src/openfl/geom/Matrix3D.hx:387: characters 23-92 : Type not found : openfl._Vector.Vector_Impl
haxetoolkit/openfl/openfl/8,0,1/src/openfl/geom/Matrix3D.hx:398: characters 23-159 : Type not found : openfl._Vector.Vector_Impl
haxetoolkit/openfl/openfl/8,0,1/src/openfl/geom/Matrix3D.hx:540: characters 12-111 : Type not found : openfl._Vector.Vector_Impl
haxetoolkit/openfl/openfl/8,0,1/src/openfl/geom/Matrix3D.hx:761: characters 30-136 : Type not found : openfl._Vector.Vector_Impl

Are you using an older Haxe version perhaps, such as 3.2.x? You should be using at least Haxe 3.4.0, but ideally 3.4.7.

Hi Gama11.

Yeah, I’m using Haxe 3.2.1. After updating to 3.4.7 the fresh empty project compiles just fine.
Thanks! Unfortunately another simple test project utilizing Starling 1.8.13 fails now.
This time it says:
HaxeToolkit/openfl/starling/1,8,13/starling/events/TouchProcessor.hx:76: characters 60-81 : Abstract openfl.Vector has no @:to function that accepts openfl._Vector.IVector

Oh, I had to do this on the Starling 2.0 branch:

Perhaps we can do something similar for 1.8.

We used to have a @:from that accepted Dynamic, but it introduced problems on the C++ target

Nice singmajesty! That fixed the problem. :grinning:
Will you make a commit to the 1.8 branch?

Okay, the fix has been committed :slight_smile:

1 Like

Hi , im struggle with the filters with this update ( 8.0.1) with the colormatrixfilter in specific,. with the past version, the framerate drops in neko, but in html worked very well if i applied the colormatrixfilter to an sprite , . this version fix that, now run very fast and smooth but now in neko and also in html looks like internally all the sprite have the cachebitmap activate or something like that after the use of the filter because the render gets corrupted,. this occur even if i use this to an bitmap that i dont add to the stage, . anyone can help me with this. you can check this issue in this link ,
press the red buttons , and close the dialog to see this weird behavior

Hi! Thanks for the link. I don’t see anything getting corrupted, but you are right, filters implies cacheAsBitmap. Perhaps we can try and figure out why cacheAsBitmap is hurting the render. Does using cacheAsBitmap = true without a filter create the same result? What kind of object is being rendered, that appears to render improperly?

Hi singmajesty thanks for u reply , im posting an image

i show you there the renderers issues than im having , .i did test the link using the latest firefox browser, chromium and also chrome, so the results that im having is reflected in the image. NOTE: in the google chrome of my table (Asus transformer tf101) i can see the bad rendering issue , when you press other button to show a different dialog. the issue also appear in neko

the weird thing here is the issue occur even if i apply the filter to a displayobject that is not added in any moment to the stage, i mean only doing this displayObject.filters=[new ColorMatrixFilter( desaturationMatrix) ], trigger the issue.

you can compare this other link where i dont apply any filter and theres not any render issue.

link with no filter applied So not render issue :slight_smile:

this is the link with issue :frowning:

The only difference between this two links is that in the openfl filter issue link, before the dialog is show i applied the filter to all the elements in the stage, sprites and bitmaps and when i close the dialog all the filters of the elements in the stage get this filters=[]; also i tried with filters=null;

and yes cacheAsBitmap = true has the same weird behavior if i dont use any filter, i fixed this applying the cacheAsBitmap option not the sprite container but intead to their childs. and when i need to update something i follow this structure

cacheAsBitmap = false
update the element.

so im dont having any issue using of rendering using cacheAsBitmap in this ways now , only with the colormatrixfilter

Does building with -Dopenfl-disable-gl-cacheasbitmap make any difference?

Noup nothing this is my command line for html
openfl build “project.xml” html5 -final -Dopenfl-disable-gl-cacheasbitmap -verbose

in neko theres not difference, and gets slow.
openfl build project.xml neko -debug -verbose -clean -Dopenfl-disable-gl-cacheasbitmap

So it looks the same when you add the flag, it just performs more slowly on Neko?

thats totally right!

I’m not sure how to test this, unfortunately I don’t know of another project that reproduces this problem right now. I don’t know if there’s any way I could try to test your project directly?

Hi joshua

this isnt the original project , i created a new project with an ultra really reduced basic funcionality where you can see the colormatrix filter issue, in this project the only thing that you have to do is press in any part of the stage and then the filter is applied if you press again the filter is removed so on so forth , like an on and off filter switch

also you can move the mouse up and dow for a bg scrolling.

Well, this is the issue in this case, the first time when i press click , the filter is successfull aplied to the background and also to the others sprites, BUT the second time , the render freeze-stops,in this steps im applying filters=[] to the bg and other sprites

i also upload the export html version of this project , for a quick revision this is the link ( i uploader this link before , nows its different , i mention that in case the cache still show you the last project or freeze meanwhile is loading or something )

this is the command line that im using to generate the html openfl build “project.xml” html5 -final -verbose

Thank you so much for the sample! I think I fixed it here:

1 Like

Hi Joshua , men thanks to you for your amazing work and support. it works in neko and html5 and in neko its super fast. thanks u so much again

1 Like

You’re welcome! Have a great day :smiley: