Flash-CORE
Next generation of Flash development.
Genome2D v0.9.1 released
12Hi there guys just a quick post today as I am swamped with work. As some of you that use nightly know the Genome2D version 0.9.1 is here so I just want to make it official. I also udpated the examples on github as not all of them were compatible, also added DepthSortExample which shows the ease of use of the Genome2D native depth sorting for nodes.
Whats new in 0.9.1? Fixes mainly and small changes based on the feedback I got from the community, one of the major changes is the option to separate shaders for sprites that don’t need dynamic alpha as pointed out by Daniel from Starling the simple color transform multiplication inside pixel shader on low end iOS devices is a fillrate killer. First tests show that using this can bring up performance up around 80% which is almost twice the speed. Unfortunately I don’t own low end iOS devices so I am grateful for any feedback from users that do, thanks. As for low end android devices the problem seem to be somewhere else like interpolation of varying registers between vertex and pixel shaders which was optimized by this change as well as there is one less register send for non dynamic alpha sprites. My own tests on HTC Desire showed up to 60% performance increase which is awesome and it shows that its possible to do 60FPS games on low end devices indeed. So all of you out there enjoy and don’t forget to update your projects with the version 0.9.1 as it will almost double your FPS on these devices. I sure will update Geometry Arena which is already over optimized anyway, this will just bring it up a notch ;)
Another thing that was brought to my attention is that the exanples on GitHub are not suitable enough as a starting point as they are overly complex with their inheritance based test suite implementation. So what I will do in near future is to release a Hello World type of examples which will be standalone, very similar to the 0.3.5 tutorials hopefully this will help.
[EDIT] Oh I almost forgot there are new stats inside Genome2D you can enable them by setting enableStats = true for GContextConfig during Genome2D initialization. They will show in the left right corner and for now they show FPS, MEM/MAXMEM, Number of DrawCalls per frame, Number of Textures on GPU. It can be usefull to finetune your performance, just don’t forget that number of drawcalls isn’t always the bottleneck there can be implementation with 300 drawcalls that is faster than one with 3 ;)
Last but not least I would like to post another poll, as time is always the issue I would like to ask the community what should I prioritize until there is an option to clone myself and work on everything :D
Loading ...Links as usual:
Documentation: ASDocs
GitHub: Examples
Library: Download
So guys enjoy and as always any feedback, bug report, suggestion or just a beer is welcome :D
Genome2D rendering the display list
7I had an entirely different plan on what to work on during this weekend. What happened were various discussions on how hard it is to work with Stage3D compared to native display list as many people can’t grasp the different pipeline, so me being me I asked myself is there a way to offer some nice intuitive rendering for those that can’t say farewell to the native display list? The answer is YES.
And that is what GNativeRenderer does, it will render your native display list to Stage3D through Genome2D renderer. Nope it doesn’t recreate your list in Genome2D render graph nor does it instantiates components and stuff what it does is simply render to avoid any overhead. So it iterates your list, manages texture creation for bitmap assets and then draws it to the Stage3D. So if your entire game is made of bitmaps which probably is you can simply convert your game to Stage3D with ONE LINE OF CODE. Yes its that easy ;)
To demonstrate this feature I took Shawn’s RunnerMark the display list version and run it through GNativeRenderer. Click the image to start.
Ok now don’t go jump through the roof, remember it can render only bitmaps. I may decide to add rendering of other stuff as well but it would be very tricky and impossible to tell when it should invalidate as native classes don’t support this kind of functionality, maybe by a hack through prototype chain. Next remember that once the renderer encounters a bitmap data that is not there it will create a texture for it and upload it to gpu. You want to avoid this as much as possible during runtime so pool everything and whats more reuse bitmapdata references, a hundred of bitmaps using the same bitmapdata will allocate just single texture. There are plenty of tutorials and posts about this bitmap caching a reusage technique for native display list out there so stick to them.
Now whats great is that you can mix it with Genome2D render graph and genome2d low level render calls like draw and blit as well if you want to. You can’t however interlace it as native sprite then GSprite then native sprite. Same applies to draw/blit even though this can be done with a bit of work on your side.
DON’T FORGET TO HIDE THE STUFF YOU ARE RENDERING THOUGH GNATIVERENDERER! Yes you heard me you need to turn the visibility to false otherwise you will render both stage3d and native version at the same time :) This also means no mouse/touch interaction is possible with the items, I guess there can be tricks around it and people will come up with some.
The speed is good, its not as good as GPU render mode obviously where simple context clear is faster than in direct mode. Personally I don’t know why and Adobe may be looking into it as Stage3D should be able to render up to speed with GPU mode especially when we are talking about single large bitmap or a simple clear where the AS3 overhead isn’t an issue.
Another impact on the speed is the iteration, the renderer needs to reiterate which another thing that will be negligible once AS3 speed is improved. When comparing this to an implementation purely based on Genome2D diretly the Genome2D implementation would obviously come on top the difference depending on the case but again GNativeRenderer is aimed for people that want to use native display list as much as possible and easily render it to Stage3D.
Currently the GNativeRenderer allocates a single texture per single bitmapdata which is what GPU mode does as well, I am looking into dynamic packing which I already implemented but the overhead of repacking atlases on runtime may be huge again depending on use case, maybe something that can be enabled/disabled.
I am also thinking, if there is a huge interest in this, of releasing it outside of Genome2D with some Genome2D parts needed obviously but something like Genome2DLite as it would be really small library.
Now here is the code to the RunnerMark with Genome2D GNativeRender implemented.
As you can see nothing much changed, obviously we need to initialize Genome2D thats why the init method.
-
Genome2D.getInstance().onInitialized.addOnce(onInitialized);
-
Genome2D.getInstance().init(stage, new GContextConfig());
Thats it, after that there is only a single line that will render everything going on and that is:
-
Genome2D.getInstance().initNativeRenderer(s);
And don’t forget about the
-
s.visible = false;
Otherwise it will render twice, once natively and once though G2D :)
The Genome2D version 0.9.0.1105 that supports this can be found among nightly builds here
Thats it folks, enjoy and once again I am glad for any feedback.
Genome2D GShape component.
1One of the most sought after features many people want is definitely vector rendering, so there was no question about if its going to be implemented but when it will be added. So I decided to introduce first implementation and it can be found in nightly starting from 1102 version. I wouldn’t use it in production yet, its after all just first draft and may not even be in the next stable version even though that is unlikely to happen.
Now to the implementation, it doesn’t work as the standard native shape graphics api, as I wanted to avoid implementing triangulation into the framework which would be an unnecessary bloat. So basically you need to triangulate your vectors by yourself and then pass it to the GShape class. You may ask why, the answer is pretty simple there are specialized libraries out there for triangulation from simple triangle fan algorithms for convex polygons to complex Delaunay triangulation algorithms that can triangulate even concave polygons with holes. And implementing all of them would be redundant so its up to you to chose. For example Nape library has great geom utilities that can be used for this so once you are using Nape you have all you need.
In the example below I use Nape GeomPoly class to use marchingsquares not only to generate vectors from bitmaps but for triangluar decompositions as well. You can also use specialized libraries such as poly2tri I am afraid there is no example source or tutorial yet but I may answer a question or two on forums. At the moment its just a presentation of new feature that I am working on.
Genome2D 0.9.0 is OUT
46Hi there guys so its finally here a new version of Genome2D. First thing that comes to your mind is probably why the version number 0.9.0? Wasn’t the last one 0.3.5? Yep it was but since Genome2D is becaming more clear and polished I decided to go for the final 1.0 version. So why didn’t you, you ask. Simple this version is not much about new features as it is about refactoring, polishing, class structure changes etc. I just want all of you out there that use Genome2D to try it out if there are any major flaws with the structure and API, if I get a nod from most of the guys I am talking with the version 1.0 may come very soon. So this is just a preemptive versioning step from my side just to be safe there isn’t anything major I overlooked when it comes to API structure.
Lets take a closer look at what changed, as I said this is not much about new features as there are hardly any as it is about refactoring and removal/change of some of the API.
There is only single renderer now and that is Stage3D
As I already said the viability of custom software fallback has diminished with AIR 3.2 and especially Adobe pushing for Stage3D to support older drivers. When we count into the incredible overhead of managing and implementating my own custom software renderer I think it was a no brainer. With it removed I can fully focus on new features you people are asking for without worrying about implementation apects of software renderer. This also means I was able to get rid of some of the abstract layers in the engine, it has not much of an impact on performance but it sure simplified things.
Linked lists everywhere
Even though I used linked lists in previous versions as well for best performance possible there were some redundant array references used as well for functionality that I deemed necessary back then. For example child nodes are in a linked list but as I wanted to have getChildAt/setChildIndex they would be really slow so there was an array reference for childs created as well. This introduced overhead in other areas as anytime you manipulated a list you worked on both structures. I finally decided to get rid of the arrays. This means you have no longer access to familiar api as getChildAt/setChildIndex but I don’t find them necessary at all. For iteration purposes you should work directly on a list which is way faster than getChildAt and scenarios where you would use setChildIndex can almost always be implemented using swapChildren. For unique cases like sorting I decided to implement them natively, so now you can call native Genome2D sorting methods to sort your children in a node based on X,Y or a custom userData property. These sorts are ultra fast and were designed to work with linked lists, way faster than native flash array sort. ;)
What the hell are these names.
First thing that you may notice is that package and class names were changed. Now everything is in com.genome2d package instead of my old com.flash-core for more convenience but whats more the G2D prefix was substituted for simple G as many people requested this.
Factories are the future.
Next refactoring step was to move most of the constructing methods outside of their classes as I found them to be chaotic. New factory classes were created that contain these, it simply brings peace to my mind and its way more understandable. There are now three factories GTextureFactory, GTextureAtlasFactory and GNodeFactory which you will work with. Its recommended to work with factory even if you can use constructor directly such as new GNode() should be GNodeFactory.createNode() as there may be some dependency involved in the future so it may spare you headache and refactoring issues if you stick to using factories now.
www.genome2d.com
I had to mention this here, its a new domain I activated that will be specially dedicated for the Genome2D framework. At the moment it still redirects to my blog but there will be just framework related information and stuff in near future. As many of you know I hate all this non-coding stuff and if someone volunteers with examples, documentation, tutorials or pretty much anything I am all for it.
OPEN SOURCE IS COMING
Yes I know many asked this and I didn’t have final answer but I do now. Genome2D will be open source, the sources will come with the 1.0 version. This is crucial to some of you out there that port games to my framework and as I promised this I will keep my promise. Hopefully we will see more and more awesome games using it.
LINKS
New examples are on GitHub: https://github.com/pshtif/Genome2D
Latest version of the library is there as well: https://github.com/pshtif/Genome2D/downloads
ASDoc documentation can be found here: http://www.genome2d.com/docs/
If anyone has any questions or need to ask something specific about their project they are maybe thinking about porting to G2D I am all ears and always willing to help. Many people did so and hopefully found me pleasant and helpful so don’t worry. :) This communication is a two way street and many changes may come from such discussions. Also please if you are porting your game or creating a new game using Genome2D let me know even if you don’t need any help, maybe we can get some gallery going ;)
Thanks to all of you that are providing feedback through mail, forum or skype. And even more thanks to all the donators its nice to feel appreciated ;)
Genome2D CPU fallback stays or goes?
11Its simple here is the poll:
Loading ...As for the reasoning I mentioned few times that having multiple renderers slows down the development of Genome2D quite a lot as a lot of stuff needs to be done two times with entirely different approach. The other downside is that its tricky to implement some stuff through abstract layers. Why am I asking this now? The thing is that release of AIR 3.2 and FP 11.2 is upon us and the need for the custom made software fallback is becoming questionable. Also taking into account the type of games you guys I talked with try to do it would be practically unmanageable to run in software mode anyway.
So all this great work is going to waste? Yes and no, after all I learned a lot during the decoupling but whats more it lead to a lot of optimizations that would never be there if I didn’t go this route. Now getting rid of the abstract layer it may boost performance even more although very slightly as its already pretty optimized but we’ll see. But the major thing is that I will be able to concentrate on implementation of other stuff you people asked that were hard or impossible to do for both renderers as masking, vectors and more ;)
Thats all guys, what do YOU think? :)