Starling-Framework
Starling-Framework copied to clipboard
Gamua
Starling Graphics integration (Feature Request)
Hi!
I would like to have Your and the Community opinion about integrating Graphics drawing into Starling framework. While StarlingGraphics extension exists, I would like to have a well tested, bug free and highly optimized version which updated regurarly and tuned to perform as best with the core Starling enhancements.. I feel this functionality more tied into a graphics/render engine compared to Asset Manager for example.
Thanks!
it is good to intergrade with the official branch. But can it be a pug-in like before, else starling will become more bulky.
I'd love to see vector-graphics capabilities in Starling! Especially with the high resolution devices that are becoming normal nowadays, that would be super helpful. It is definitely not an easy task to make a really fast implementation, though: Adobe itself never managed to use GPU acceleration for those parts of the display list, either, after all.
Personally, I'd prefer if someone could take over the existing graphics extension and make sure it works well with new Starling releases. I could help where I can, e.g. by making changes to the Starling core where necessary.
Other than that, I'd maybe be able to look into it myself after I've finished the overhaul of the rendering architecture that I described in this recent blog post. For me, getting that done has the highest priority — because fast quad rendering is the most important thing for games; it's very likely that vector rendering will never get that fast, and will thus remain problematic for many use-cases.
In any case, I'm happy about any input about this topic! Thanks for the suggestion, and thanks in advance for any feedback.
Thanks for the feedback! A peer review of the extensions source code would be also superb!
About my actual use case I had to drop using Starling-Graphics-Ext. because I had to solve a rendering bug which could not wait any moment, and I don't have enough capacity to review the extensions internals and fix it so fast. Anyway I've created a BorderQuad class which extends a QuadBatch and consists of 4 sides as Quads, this is a working replacement to draw Borders, also with simple Quad I've switched off my drawn Rectangles. Anyway only Circle/Blob is missing but I'll render this form using the traditional Graphics drawing API.
Thanks for the additional info! Good to hear that you've got a working solution for now, so that this is not a show-stopper.
Hello, vpmedia. I do apologize for not responding quicker to the drawRect issue.I am also sorry to see that it blocked you.
The issue was part of a pre-existing issue, 109:
https://github.com/StarlingGraphics/Starling-Extension-Graphics/issues/109
and hailed from the fact that the strokeThickness wasn't used in the calculation of the y-coordinate of the last vertex in the rectangle. I was previously reluctant to check this in, for backwards compatability reasons, but today I decided that that wasn't an issue.
So that has been fixed
Furthermore: Nothing would make me happier than to see the Starling Extension Graphics be adopted to the general Starling package. It has some pretty nifty features, not only the vaguely working "Standard" Flash Graphics API (although, there is a sever problem with texture coordinates, and atlases), but also a number of good classes that can be used more efficiently than when used through the limiting boungs of the Graphics API. ( such as TriangleStrip, TriangleFan, the NGon (N-sided polygon class, to make circles, donuts, arcs, etc)
I have also implemented a simple shape based collision detection system that works fine for Polygon based mouse hits, for example. Or polygon shaped collision detection, between outlined shapes, used successfully in at least one game:
http://forum.starling-framework.org/topic/bounds-intersect-question
The problem with the extension is, however, that it suffers from being under-supported by the very few of us who have been working on it. I know Daniel is just one man, and we have been 3 or even 4, but we have, unfortunately, not had the time that we should have had, to spend on keeping this in development.
Also, as I am leaving the "Flash world" and going back to the AAA - "C++ world", (I'm heading to EA to make racing games), I am afraid the future is looking even bleaker for the project.
I would love to help, Daniel, if there is anything I can do, or provide an explanation for, I would love to do it, but I will have very little time to actually program features, or clean up the code. Let me know if there is anything else I can do to help.
best regards, IonSwitz (GitHub and Twitter)
Oh, and yes, the perpetual problem that will always arise when people use the SEG is anti-aliasing: Drawing diagonal lines by using untextured triangles in Starling will always produce jaggies. There are ways this could be made better, but it's a non-trivial problem.
My favorite solution would be a Distance Field approach, like the one used in Distance Field Fonts I have tried, but never got it to work in a good way, but I am far from a Distance Field expert. It should be doable, fast and produce amazing results.
The second is to texture the lines with ordinary textures with an alpha edge (hard to get good and general), the third is a tiny, tiny BlurFilter (not as fast as we want) and the fourth is the Starling.antiAliasing setting ( doesn't work on mobile devices)
Sorry for spamming this thread with my notes.
Thanks a lot for your comments, @IonSwitz! You are right, your extension contains a lot of extremely useful code, and it would make a lot of sense for me to adopt it and keep it up to date with Starling releases, especially since — as you say — you're moving to a different area of development.
As I wrote above, I'm planning an overhaul of the complete rendering architecture of Starling, and that would be a good time to look into your extension, as well; maybe I can simplify the code in the extension by moving some things over to the core or simply providing a better infrastructure for AGAL, etc.
I'm absolutely sure that some questions will pop up then — the vector math you're doing is very likely above my head. :grin: So thanks a lot for the offer to answer my questions!
Again, I can't promise anything yet, but I know that it would make a lot of sense to better integrate the graphics extension — so I'll do my best to make this happen.
One of the aspects that I believe that the Graphics Extension would benefit from is to break apart a bit more from the "old-school" Flash API. For example, the Shape.graphics API does not support any direct texture coordinate input, simply because the original Flash API has no such concept. Therefore, texturing graphics through the Shape.graphics.lineTexture and Shape.graphics.beginTextureFill is very very tricky. There is some uvMatrix support, but it is hard to use.
To tightly follow the Flash API has been one of the design principles, and I wonder if it isn't time to break away a bit from this. The Starling Extension Graphics provides a number of other helper classes that can be used as the foundation of this, but the result of this is that the SEG seems a bit schizophrenic, one aspect is the "old" Flash API, the other is the fairly large number of smaller support classes that exist.
Anyway, feel free to drop me a line with any questions, I am sure the other contributors, and the folks that started the SEG and who have written the bulk of the code and the structure, would be just as eager to see this go into the main Starling path. But I don't speak for them :)
Yeah, I totally agree; it would be awesome to have an API that's more suited to GPU logic. I think that's a great idea, actually! I'll get back to you when I'm on it. :smile:
Hi, thanks for all the responses, I think many Starling user would be happy if the library would be updated in the future. @IonSwitz Good luck with your new position, I'm sure working for a big company like EA can really give some good experience with AAA development, also thank you for all the contributions and the fix for my previous issue. Cheers!
@vpmedia - Thank you! :) I am not new to the AAA field, but it's been a decade or so since I was in that field, so it will have changed quite a bit. It'll be fun to be back :)
Hi!
I see there are updates (bd7a0249c8f9d7fe50473dd8a76aa8640efe2ebe) regarding the feature request, very nice, thank you!
Some feedback:
-as posted on the forum also the new starling.display.Shape class breaks compatibility with the graphics extenson, I've moved the extension outside the core starling package to solve this, I think thats the proper way..
-the new mask property breaks compatibility with the PixelMask extension, I've renamed the extensions property to masker..
-I'm still missing a line drawing feature to drop the graphics extension in my game framework and I've issues making a simple quad based solution: https://dl.dropboxusercontent.com/u/1375050/starling-quad-lineto.png Do you think it is something that will be implemented in the near future? Also I would like to ask for some advice about GPU based solutions for this, as you can see in the screenshot there are gap issues with the connecting lines, also the line aliasing looks bad if rotated with small angles..
Yeah, I'm sorry for that package/name clashes. As an alternative, I could rename the "Shape" class for now, until Starling 2.0, which will break a lot of code, anyway. ;-)
A line drawing feature is planned to be added to the Shape class, yes! I suppose this will require some tricky math, though, to avoid exactly the issues you are seeing.
What you could do in your case is to use an image of a line in the correct width (not length), complete with 1-2 pixels transparent border. You'll see that when you rotate that, aliasing will be much better. Corners will still be a little difficult, though.
The elbow joint math (the reason why the "corners" look bad) is solved in the Stroke class of the Starling Extension Graphics. The code lies in the buildGeometryPreAllocatedVectors() and createPolyLinePreAlloc() methods, which contain some of the most Scout:ed code paths that I have ever worked on :)
Making the elbows look good is pretty slow, unfortunately.
The problem with jaggies along the lines could be solved by drawing twice the number of triangles for each pass, with the outer vertices having a 0 alpha and the middle vertices have an alpha of 1, but that would require a double pass through the elbow math, and that is really expensive.
Solving anti-aliasing issues using only triangles is not simple, so a textured path is most likely the best way to go.
Thanks a lot for the overview about the "elbow joint math" (now I at least know how this is called! :grin:)! This is a part where I'll definitely let myself be heavily inspired by the graphics extension's code. You really did an amazing job on that! That becomes ever more clear the more I look at it ...! :smile:
I didn't do any of the real math on that, I only optimized the code path as much as I could without changing the logic around too much. I am sure things could be optimized further, to make special cases faster, but the math in itself is not of my doing. :)
Hehe, okay! Even that is impressive. =) I'm sure I'll find good documentation about the issue somewhere — definitely a good time to dust off some of my long forgotten math "skills". ;-)