You can think of this lib as some kind of Tilemap for Starling : it renders lots of quads/images in a single DisplayObject with far better performance than regular Starling Quad/Image classes.
You are currently limited to 16383 quads per MassiveDisplay instance (I’m gonna remove that limit)
It’s available on haxelib : haxelib install massive-starling
I believe this lib has lots of potential and can be useful to many devs using Starling : feedback is warmly welcome !
Current version is 1.0.0-alpha, it should be pretty stable : only known issue is an error occuring with ParticleEmitter when building to cpp. It’s my first time with @:generic, I’ll welcome any help with that issue : the haxe part works fine, the error occurs when building the c++ source files
@Bink Thanks ! I’d love to get some feedback, good or bad
Massive was updated to 1.0.0-alpha.1 on github and haxelib
MassiveDisplay now has a renderMode property which is expecting values from MassiveRenderMode
Default renderMode is either MassiveRenderMode.FLOAT32ARRAY (non-flash targets) or MassiveRenderMode.BYTEARRAY_DOMAIN_MEMORY (flash/air target)
MassiveDisplay now has a colorMode property which is expecting values from MassiveColorMode. There is a new mode called REGULAR, which stores vertex color over 4 bytes. This prevents some cool color effects when setting color values higher than 1.0, but brings a small performance improvement (about 5-10% except with Vector render mode on flash/air target, where it’s slower)
Default colorMode is MassiveColorMode.EXTENDED
Note that there is an issue with MassiveColorMode.REGULAR which happens on Firefox but not on Chrome on my system : when using that color mode with FLOAT32ARRAY or VECTOR render modes quads with a blue color value over 0.5 appear all blue. I’ll have to look into it a bit more.
MassiveDisplay instances now share program, except when you set a custom one
MassiveDisplay index buffer creation was optimized
MassiveDisplay’s renderData and updateExactBounds methods were finalized
MassiveDisplay and DisplayData : colorAlpha, colorRed etc were renamed to simply alpha, red etc to avoid Starling’s Tween considering them as Ints
MassiveDisplay and DisplayData now have a color property (Int)
MassiveDisplay was reworked to be more flexible : setting rendering-related values after adding it to Stage could result in errors or weird results, this is no longer the case.
All demos were updated with those changes, particle editor demo now lets you set renderMode and colorMode
Massive was updated to 1.0.0-alpha.2 on github and haxelib
MassiveDisplay can now render an unlimited amount of quads, the 16K limit was removed. MassiveDisplay will make 1 draw call per 16383 quads
bufferSize and numBuffers properties were removed from MassiveDisplay
MassiveDisplay now has a maxQuads property (default 16383) which determines buffer size and how many buffers will be used (1 VertexBuffer3D for 16383 quads)
MassiveDisplay now has an autoUpdateBounds property (default false) : when set to true, bounds data is stored during rendering and exact bounds are calculated right after. When false you can call writeBoundsData() and then updateExactBounds()
MassiveDemo now has a button to toggle autoUpdateBounds
When I started removing the 16K limit I had worse performance at first, because I was using only one VertexBuffer3D : it turns out you have to upload a VertexBuffer3D only once per frame for best performance.
I’m really happy with the state of Massive now ! Next is multitexturing, I hope it won’t lower performance too much
No update yet, but a preview of the multitexturing feature MassiveDemo
Multitexturing is fully working with up to 16 textures on a single MassiveDisplay instance : it could go even higher if you GPU can handle it !
In baseline profile the shader can only handle 5 textures though
Performance is a bit lower when multitexturing is on, but still excellent
I duplicated and colorized the zombi atlas to have 16 of them : every zombi with a different color comes from a different atlas. The demo will automatically select as many atlases as possible.
This is far beyond my expectations to be honest : when I started working on Massive I never thought it would go that far That makes me want to do some kind of “Vampire Survivor” demo… but that’ll have to wait
Alpha3 update will require a small change on haxe-Starling in order to be able to set the ignoreLimits parameter when calling the AGALMiniAssembler’s assemble function
That makes me want to do some kind of “Vampire Survivor” demo… but that’ll have to wait