Flash-CORE
Next generation of Flash development.
Genome2D 0.3.5 is HERE.
4Yay, finally after over a month the next version of Genome2D is going public. I am sure most of you already know what the new features are from my WiP blog but lets reiterate, as I didn’t mention all of them in the WiP posts.
Genome2D
- [ADDED] texture filtering, it is now possible to set texture filtering mode per texture (NEAREST, LINEAR). You can also set default value through G2DTextureBase.defaultFilteringType which will be the default value for any newly created texture
- [ADDED] texture resampling scale, now you can set a resampling scale how textures will be created from your asset sources, lets say you have a 512×512 bitmap but for performance reasons you want it to generate only 128×128 texture and resample the bitmap into it so you can set resampling for that particular texture to 4. As with filtering it is possible to set default value through G2DTextureBase.defaultResamplingSize
- [ADDED] texture resampling type it is now possible to set resampling type used for non-power of 2 textures for more info check WiP post here http://blog.flash-core.com/?p=691
- [ADDED] texture pivots, now every texture can have pivot point defined during creation, this pivot point specified how its transform will be handled. So if you have a 32×32 texture by default its pivot is 0,0 which is center. If you want to rotate this texture around its top-left cornet you should set its pivot to 16,16 but more than that its crucial for non-uniform sub textures inside texture atlas that want to have correct animation sequence positioning.
- [ADDED] new renderable component G2DNativeObject, it can be used to render native flash display objects through G2D renderers, what it does is internally generate a G2DTexture takes snapshots of the native object into it. You can specify how often the update is being done. For example Stats class in the new 0.3.5 examples on Github is rendered this way.
- [ADDED] new renderable component G2DNativeText, extends G2DNativeObject and can be used to render native flash text fields, for example all of the UI in the new 0.3.5 examples is rendered using this component
- [ADDED] new rendereble component G2DVideo, extends G2DNativeObject and can be used to render Video viz VideoExample in the new 0.3.5 examples
- [ADDED] new renderable component G2DEmitterGPU, creates and renders particle system entirely managed by GPU shaders viz ParticlesGPUExample in the new 0.3.5 examples. (Doesnt work when using CPU blitting renderer obviously)
- [ADDED] new renderable component G2DTextureText enables single line text rendering build from sprites per character textured using a G2DTextureAtlas
- [ADDED] G2DTextureAtlasUtils.createFromFont method to create a texture atlas from native font
- [ADDED] G2DTextureAtlasUtils.createFromMovieClip method to create a texture atlas from native movieclip
- [ADDED] G2DTextureAtlas.createFromBitmapDataAndRegions method to create texture atlas from any specified bitmap data and any amount of specified regions, pivots, ids within it, can be used to implement any form of texture atlas creation and packing algorithms
- [ADDED] G2DComponent.createWithNode method that will create an empty G2DNode with specified component
- [ADDED] Blendmodes now added to G2DBlitting renderer as well.
- [CHANGED] Device loss management refactored and speeded-up, textures/shaders/buffers are now reinitialized only once per device loss in the pipeline where before they were reinitialized per each object that referenced them. Also device loss will no longer crash application that tries to initialize textures during lost device for example an application that uses on-event texture creation which may get fired during lost device.
- [CHANGED] further pipeline optimization and refactoring, average speed gain of up to 15% from previous version
- [CHANGED] G2DMovieClip component update cycle optimization up to 50% speed gain.
- [CHANGED] G2DNodePool refactored and optimized, now supports non-sequential pooling as well
- [CHANGED] All shaders are now precompiled and embedded instead of being compiled at runtime to speed up the initialization and device loss.
- [REMOVED] G2DBitmap renderer will be no longer supported from this version on
EXAMPLES
- [ADDED] VideoExample show usage of G2DVideo
- [ADDED] GPUParticlesExample show usage of G2DEmitterGPU
- [CHANGED] completely refactored, changed asset management, everything even the UI is now rendered through Genome2D
GitHub have been updated, and examples demo as ususal, enjoy.
Test as much as possible, any feedback is welcome. I will also update the docs once I am back from Switzerland. Once that is done I will try to focus on documentation more as many of you kept asking me for it and I feel the time has come ;)
Attending gotoAndSki() Switzerland
3
Hi there just want to mention that I’ve finally bought my ticket to gotAndSki today so you will see me there. So if anyone wants to chat about Genome2D or anything really I’ll see you there, hopefully I will be able to publish the next version of Genome2D till then as well. The thing is I tried to add too many cool features and need to scratch some of them from my 0.3.5 TODO list so I can eventually finish it ;)
Genome2D still working on physics
0Just a quick post about my experimentations with physics and Genome2D as some people are asking if I am working on the physics extension. Yes there is a Genome2D extension being worked on by me at the same time I work on the core Genome2D. Its about Nape physics library implementation, as Genome2D core already has an abstract layer for physics implementation i am building on top of it. Actually its a two way street as i encounter problems I change and update the abstract layer accordingly, hopefully all the people that will implement another physics libraries into Genome2D will be thankful :D
Some of you who attended my session about 2D implementation of Stage3D and Genome2D at AUG meeting already saw some of the physics examples but I didn’t put them live, and I am still not going to. I am actually working on a whole set of physics examples same as the core examples and once its done I will publish it. So don’t worry I didn’t abandon it and its still under progress ;) Ok I am not going to be that selfish and publish atleast one of the examples, here it goes.
Its a custom physics particles demo, its not something that would be implemented out of the box but its an example what can be done with G2DEmitter and custom extended G2DNapeParticle. Nothing too extravagant its an emitter emitting physics particles that scale along their velocity vector and also gain incadescency upon collision as they try to imitate real sparks. It utilizes Genome2D’s prototype pooling for particles as now even G2DNapeBody component is prototypable and therefore can be easily pooled, this is great new not only for particle systems but for pretty much anything that utilizes pooling and physics, spawning enemies anyone? ;)
Its not finished yet and I will probably play with it further. May be slower on some computers as there are many full dynamic bodies, those are not some kind of washed down particle colliders, but so far it was running at 60FPS everywhere I tried. Move it around using mouse and enjoy.
Genome2D WiP GPU particles and more texture stuff
0So we have a new year lets start it with a new Work in Progress post.
G2DEmitterGPU (only applies to G2DStage3D renderer)
This is a GPU based particle system component, its similar to ND2D and Starling particle systems, everything is pregenerated during emitter initialization and only variable that is sent each frame is the time and based on this value shaders interpolate the state of each particle. So whats this good for you say? Actually not much, nah i am kidding the great thing is that it has almost zero impact on CPU except the initialization precalcucation phase so its a “cheap” way of simulating simple particle systems such as explosions, fire, rain etc. without the need of complex calcucations on CPU side. It is also capable of rendering a lot of particles without much of fuss. Since Genome2D already has a GPU not CPU bottleneck the performance difference is not that huge in simple test case scenarios since the rendergraph and especially low level blit methods are optimized to such extent that GPU particles can’t render that much more than CPU particles using core shaders. But still its highly usable especially when mobile and particle systems pooling comes to mind.
The thing is that user needs to take into account the rigidness of the implementation, since its precaluclated there is no randomness in the behavior, no state memory since its calculated from base values each time and also at the moment it doesn’t support any external forces which may be added in future releases such as gravity, wind etc.
It does support scene hierarchy and camera system, so it inherits parent space as well as color transformations. Precaluclation and shader generation is also optimized so it doesn’t generate redundant structures when two separate emitters have the exact same settings. It will reuse the same structures/shader instead. So for example we can have two fires with the exact same settings and differentiate it visually simply by changing the time offset. You can reuse the same emitter with multiple textures as well, changing the texture doesn’t need to reinitialize anything. Its great for pooling stuff like explosions.
GPU particles are not visible when using G2DBlitting renderer for obvious reason.
Texture pivots
I was playing with the idea of pivots for a long time and i finally implemented them. First i was thinking about implementation in G2DSprite and G2DMovieClip but after thinking it over it came to me as a realisation that its actually a texture issue, for example different texture pivots for frames within an atlas sequence. By default all pivots are at 0,0 which is a center of the texture. Setting a pivot to -textureWidth/2, -textureHeight/2 will set the pivot to top-left corner. Pivot affects all transformations of such texture so a sprite having a 24×24 texture with a pivot set to -12,-12 will rotate around its top left corner ;) It will be easy to implement inherent or overriden pivots for G2DSprite/G2DMovieClip as well if there is a need for it but still keep in mind that it doesn’t affect node transformations.
Texture atlas creation from bitmap, regions and pivots
As i mentioned in one of the comments there will be a new method for texture atlas creation it has three parameters, bitmap data, regions vector containing all the regions information and pivots vector containing the new pivots data. This method also means one huge thing and that is that anyone can actually implement custom atlas building algorithms such as creating atlas from movieclips etc.
Thats all for now folks. And here is a demo of G2DEmitterGPU component:
Genome2D WiP native objects and texture stuff
14As usual this is a post about what is coming in next version of Genome2D, among other things there are additional optimizations and what i want to say first is that i broke the magic barrier of hundred thousands sprites!
I was able to render 100.500 individual 32×32 sprites at 60FPS !!! using genome’s low level blit method.
So yep further optimizations are coming up to 80% in some cases. But thats not all folks, there are new features coming as well.
Texture Filtering (Doesn’t apply to G2DBlitting renderer)
Textures can now have filtering type specified, NEAREST, LINEAR, BILINEAR, user can now specify it using G2DTextureBase.defaultFilteringType which will then be applied to any new texture or specify it per texture instance through texture.filteringType.
If people really want i can also implement override for renderable components so user will be able to specify filtering type even per rendered object so objects sharing same texture can have different filtering so far i am not sure this is needed as i can’t come up with a use case where it would be useful.
Texture Custom Resampling (Doesn’t apply to G2DBlitting renderer)
Textures can now have resample type specified this applies to textures that are created from bitmaps which are not power of 2 size. Users should avoid creating such textures but if they can’t this is a way to specify how it should be handled, it also applies to the new G2DNativeObject rendering. Resample types are UP_CROP, UP_RESAMPLE, DOWN_RESAMPLE, NEAREST_RESAMPLE, NEAREST_DOWN_RESAMPLE_UP_CROP
Yep i know it may seem confusing but its quite simple.
UP_CROP means that if a bitmap isn’t power of 2 size it will look for next larger power of 2 size and draw this bitmap into it without any resampling updating UV coordinates only.
UP/DOWN/NEAREST_RESAMPLE are resampling modes which look for larger/smaller/nearest power of 2 size and resample the bitmap into it.
NEAREST_DOWN_RESAMPLE_UP_CROP is very specific it looks for nearest power of 2 size and if its larger it will crop resampled and if its smaller it will resample ans update UV coordinates accordingly.
Texture Resampling Scale (Doesn’t apply to G2DBlitting renderer)
Textures can now resample to context at a custom scale. What this means is that user can specify resample scale that will be applied during context texture creation. So lets say we have a 256×256 bitmap but for some reason we want it to allocate only 128×128 texture and resample to it. Easy now we can specify this either through G2DTextureBase.defaultResampleScale which applies to all new textures or per instance through texture.resampleScale
This can be for example used that if we want to use same resources for desktop and mobile game but for performance reasons we want the mobile to allocate smaller textures. We can easily check this at runtime and set the default resample scale which will not affect our instances that we want to maintain at a specific resample scale as it can be easily override per instance.
It also works seamplessly with the texture resampling type for non power of 2 sizes.
G2DBlitting renderer ignore all these texture settings for obvious reason due to different pipeline not to mention that it would be useless.
Native object rendering through G2DNativeObject
G2DNativeObject is new renderable component that can be used for rendering of native flash display objects. What it does is render the display object into a texture and then render it onto screen through renderer. User can specify how it should resample or how often it should be invalidated, manual invalidation is possible as well. Works in both renderers but if user is going to work exclusively with G2DBlitting renderer he should probably use native objects directly unless not possible, like custom interlacing of native/g2d content.
Text rendering through G2DNativeText
G2DNativeText is new rendereble component that inherits G2DNativeObject and can be used for text rendering, it handles instancing of native text field and settings in the background and provides transparent properties for the user to set.
Video rendering through G2DVideo
G2DVideo is new renderable component that inherits G2DNativeObject and can be used for video rendering. I was able to render FullHD 1920×1080 video at 60FPS without changing resample scale.
These are all updates that are already done and work in the WiP version. There is also other stuff, for example device loss handling was refactored to handle even specific cases which weren’t handled at all before, for example when user invoked texture creation during device loss. This also fixed the problem with device loss invalidation of textures which weren’t part of rendering graph during device loss invalidation.
So thats all for now folks back to work ;) I am hoping to release the next version of Genome2D this year if everything goes smoothly ;)