Could you also test the Flash target? That will help us know whether it is an SVG parsing issue, or an issue in the OpenFL vector renderer. Thank you :smile:
may be it help you found the bug more faster ;)
https://github.com/openfl/svg/blob/master/format/svg/SVGData.hx#L691var d = inPath.exists ("points") ? ("M" + inPath.get ("points") + "z") : inPath.exists ("x1") ? ("M" + inPath.get ("x1") + "," + inPath.get ("y1") + " " + inPath.get ("x2") + "," + inPath.get ("y2") + "z") : inPath.get ("d");
if i right understand then this syntax add "z" in all case(except cases the element is ellipse or rectangle ) at the end of data... and this is look like bug, because the element started from "M" can be not closed(have no "z") , can have "x1" parameter and can be not ellipse and not rectangle in same time. But "z" will be added in case above. This is wrong.
openfl 3.6.1
lime 2.9.1
i use haxeflixel... other versions still can't work properly
when you say " desktop " you mean neko?... i test with cpp windows
new details... i test again all platform and have this result now:
use vscode 1.17.1 , win7 64
-flash ... done (right unclose rendering curve)
-lime build android ... done
-lime build neko ... done
-lime build cpp ... done
-lime build cpp -Ddebug -Dnext ... fail (was my default target settings for vscode at first testing above)
-lime build html5 ... fail
-lime build html5 -Ddebug ... fail
autchhh, this sounds worst then bug, because look like the openfl will not be upgraded... always :). I only hear sometimes something about the work in process but the result , as always null, we still have no new openfl version using way for haxeflixel. Openfl 3.6.1 is immortal lord of haxeflixel country.
The MODE demo worked properly with this fork, though occasionally an enemy jet would disappear, I'm not sure why. With a little help, it might be possible to fix that
With a little help, it might be possible to fix that
fix what? demo or flixel... english not my native
If this not hard for you, and need, can i try to help etc. Little piece. If i can't(because it hard to me) i just will understand it and will sure, and you too can be sure it not for my level. But i think this is level close pro, but not my level.
Flixel was working almost correctly. The issue where sometimes the enemy ship was disappearing is something based inside of Flixel itself... something my code didn't fully resolve. I was hoping someone using Flixel might know why it was happening
Without fixing that minor bug, it's possible that my fork of Flixel will still work properly for many projects, so it might be worth trying
Tested targeting ... html5 debug, windows cpp debug. Look like the path "z" parameter always ignoring. original svg
rendered svg
svg file code`<?xml version="1.0" encoding="UTF-8" standalone="no"?> <svg xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:cc="http://creativecommons.org/ns#" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:svg="http://www.w3.org/2000/svg" xmlns="http://www.w3.org/2000/svg" width="800" height="200" viewBox="0 0 800 200" version="1.1" id="svg8"> <defs id="defs2" /> <metadata id="metadata5">
Could you also test the Flash target? That will help us know whether it is an SVG parsing issue, or an issue in the OpenFL vector renderer. Thank you :smile:
flash (swf) work good. cpp still closed. i try to read and understand the library source, but not enought strong for this :|
this look like start point of broken logic https://github.com/openfl/svg/blob/master/format/svg/PathParser.hx#L36-L37 the svg Z and z no need to be adsolute and relative(as usual svg path syntax) this is closing command, have no coordinates
may be it help you found the bug more faster ;) https://github.com/openfl/svg/blob/master/format/svg/SVGData.hx#L691
var d = inPath.exists ("points") ? ("M" + inPath.get ("points") + "z") : inPath.exists ("x1") ? ("M" + inPath.get ("x1") + "," + inPath.get ("y1") + " " + inPath.get ("x2") + "," + inPath.get ("y2") + "z") : inPath.get ("d");if i right understand then this syntax add "z" in all case(except cases the element is ellipse or rectangle ) at the end of data... and this is look like bug, because the element started from "M" can be not closed(have no "z") , can have "x1" parameter and can be not ellipse and not rectangle in same time. But "z" will be added in case above. This is wrong.I just tried this locally, and it is working properly on HTML5 and desktop:
What version of OpenFL are you using?
new details... i test again all platform and have this result now: use vscode 1.17.1 , win7 64 -flash ... done (right unclose rendering curve) -lime build android ... done -lime build neko ... done -lime build cpp ... done -lime build cpp -Ddebug -Dnext ... fail (was my default target settings for vscode at first testing above) -lime build html5 ... fail -lime build html5 -Ddebug ... fail
Hmm, this must be something that was fixed in a later version, testing OpenFL 6 and Lime 5, the SVG renders properly
autchhh, this sounds worst then bug, because look like the openfl will not be upgraded... always :). I only hear sometimes something about the work in process but the result , as always null, we still have no new openfl version using way for haxeflixel. Openfl 3.6.1 is immortal lord of haxeflixel country.
I have a fork that mostly works:
https://github.com/jgranick/flixel
The MODE demo worked properly with this fork, though occasionally an enemy jet would disappear, I'm not sure why. With a little help, it might be possible to fix that
Flixel was working almost correctly. The issue where sometimes the enemy ship was disappearing is something based inside of Flixel itself... something my code didn't fully resolve. I was hoping someone using Flixel might know why it was happening
Without fixing that minor bug, it's possible that my fork of Flixel will still work properly for many projects, so it might be worth trying