Closed IonSwitz closed 10 years ago
I'm fascinated by this extension for some reason, but never actually tried it. I wanted to include it into CitrusEngine as a way to grab shapes into loaded swf's (cause why not do that instead of transforming the shape into a texture) but how reliable would that be (using flash shape graphicsdata) ? I'm fine with losing bitmap fills or line alpha , is there any big limitations or commands/strokes/fills or even point orders to be careful with?
Triangulating arbitrary fills gets very CPU intensive - but only needs to be done once per shape. Also, the triangulator doesn't support holes. Bitmap fills and line alphas are supported though (per-vertex alphas if you want). I don't think anyone has really tried pushing complex commands at this yet though - so you'd be stepping into unknown territory, and it may well fall over.
Right now, the APIs are less than reliable. Winding isn't supported at all, GraphicsStroke isn't implemented (at some point, I would want to) and instead I added a simpler GraphicsLine. The goal would be to support as much of the API as is reasonable, but I wanted to get the ball rolling.
When I have better time (crunching at the day job, gotta get that game out) I will look into if there are any trivial things that aren't working, but yes, it would be great to get a small example of this added to the project as well.
gsynuh, I found an older thread over here where you were participating:
http://forum.starling-framework.org/topic/starling-graphics-extension-performance
Would it be possible to get a SWF of one of your puzzle pieces for experimentation?
I have found some issues and I have decided to move the drawGraphicsData code out of the Graphics glass, and to the GraphicEx class. The reason for this being that the drawGraphicsData code now also includes the flash.display.GraphicsPath etc classes, and users should be able to include a "Clean" Graphics class, without unnecessary code bulk from flash graphics.
The code (currently only available on my IonSwitz fork) is now accessed through a ShapeEx class, calling it's graphics, same as a Shape class.
This now allows code like this:
var starlingShape:ShapeEx = new ShapeEx(); var flashShape:flash.display.Shape = new flash.display.Shape(); flashShape.graphics.lineStyle(3, 0xFFFF00, 1); flashShape.graphics.drawRect(340, 40, 180, 180); starlingShape.graphics.drawGraphicsData(flashShape.graphics.readGraphicsData());
The support will be expaned, but currently the following flash primitives have been tested and found working through readGraphicsData, if displayed with slight graphical glitches:
moveTo curveTo cubicCurveTo lineStyle drawRect drawRoundedRect drawCircle drawEllipse beginFill beginBitmapFill ** endFill
(* draws with a slight hole in the edge, a bug in our triangulation, I believe. Elliptical fills work fine. ) (\ Currently re-creates a new Starling Texture for each call, so that needs to be cached in some way)
It is also possible to create similar graphics data for Starling primitives, these can be drawn using drawGraphicsDataEx the following syntax:
var v:Vector.
var starlingShape:ShapeEx = new ShapeEx(); starlingShape.graphics.drawGraphicsDataEx(v);
I have added support for the already existing GradientTexture class for Gradient Fill scenarios, but it is very very buggy. UV mapping is not correct at all.
Updated SWC to match with Master Branch. Still haven't merged in the stuff mentioned above from IonSwitz/Starling-Extension-Graphics
As of today, 31st of October, the SWC and the code tree are now in sync.
The new SWC includes: