Anyone has implemented some functions like drawLine() ?
drawLine() really needed(14 posts) (10 voices)
Have you tried to draw a line using the Graphics class from Flash and converting it to a Texture to use it in Starling?
"Have you tried to draw a line using the Graphics class from Flash and converting it to a Texture to use it in Starling?" It's a bit slow when you use dynamic draw.
The lack of a drawing class is really a must have for starling. Forgive my example, but a sparrow without a drawing and bitmap class, is like a plucking sparrow
Anyway, i really miss those class.
Not only a simple line. I'm talking about spline, bezier, circle, ellipse, plain and filled, maybe with gradientfill.
Agal is too hostile for me :(.
Anyway, please, consider to implement such features.
Thank you for all your hard work.
Daniel, In the tutorial you linked to, you mention that:
"One nice thing about Starling is that it was written in 100% ActionScript 3. It uses only public APIs, and does not depend on any C++ extension code."
I'm curious,does this mean we can use something like Adobe Alchemy to gain direct access to the OpenGL(and ES) API's through C++(or C in iOS) to import its "GL_POINTS","GL_LINES" primitives?
I'm guessing this would be a whole lot more efficient then faking lines/curves with polygons or pixel-shaders(upon a larger 'canvas' polygon)?
AmiFlash: All this makes me wonder if the native Flash lines might be more efficient anyway. I agree with you that there is no doubt a need for basic drawing primitives, especially for GUI's/HUDS.
"I'm curious,does this mean we can use something like Adobe Alchemy to gain direct access to the OpenGL(and ES) API's through C++(or C in iOS) to import its "GL_POINTS","GL_LINES" primitives?"
Interesting. Maybe there's a way to incorporate directly OGL features.
I.E. the starling particle extension uses pixels or textures for particles? How this extension works?
Well, you could of course use Adobe Alchemy to access OpenGL directly; but there would be no way to combine this with the stage3D code; because even though stage3D will use OpenGL in the background (or DirectX, depending on the system), it does not expose any the data we would need to extend it.
But I think we better motivate Adobe to make AGAL and AS3 as fast and efficient as possible, then we don't have to work on any hacks like that.
AmiFlash, the particle extension uses textures! Its rendering code is not much different than rendering Images, it's just optimized for particles.
You can't use Alchemy to access OpenGL.
Not that you need to as Stage3D mimicks OpenGL pretty much so its kind of pointless.
Ah, sorry, I mixed up Alchemy and Native Extensions.
Anyway, as sHTiF said, it's not much use.
Will the Custom display objects be a better choice for drawing paths as well, or will it be best to draw a path using the native flash API?
There's a fork over here that emulates the graphics API in starling (it uses a triangulator to turn strokes/fills into polys).
This is an interesting post about drawing shapes within a quad, what do you think? http://madskool.wordpress.com/2012/04/10/drawing-madcomponents-with-stage3d/
I have also made an implementation of Stroke as starling DisplayObject. have a look at https://github.com/jozefchutka/YCanvas/blob/master/YCanvasMapLibrary/src/main/actionscript/sk/yoz/ycanvas/map/display/Stroke.as . There is also a path simplify algorithm implemented for huge strokes in MapStroke.as
You must log in to post.