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
EDIT : replaced the preview link with the regular demo link
Massive was updated to 1.0.0-alpha.3 on github and haxelib
MassiveDisplay can now have up to 16 different textures (only 5 if profile is baseline, because of AGAL 1 limitations)
You have to call MassiveDisplay.init() once, after Starling is started. This lets Massive check for baseline profile and max textures (on non-flash targets : on flash I don’t know how to get this info and max textures is set to 16 if not baseline
MassiveDisplay now has functions to add/remove/get/set textures
added documentation
If you wanna try this version you will have to use the 2.8 branch on my fork, to get the ignoreLimits parameter and the new MultiTextureStyleGitHub - MatseFR/starling at v2.8 · GitHub
I’m waiting for Daniel to merge my PR on the as3 version before I push those on the haxe version
I also released the as3 version of Massive
While doing this I discovered that running starling from haxe on air target results in much better performance than running it from as3 : on the Massive demo with haxe I have 60fps when displaying 4000 classic MovieClips while I only have 20 fps with as3. To get down to 20 fps with haxe I have to display 16 000 classic MovieClips (!)
I was totally expecting the haxe version to be faster because the compiler is such a beast, but not by that much !
For anyone interested the MassiveDemo was updated with a revised version of MultiTextureStyle (that Massive doesn’t use : it only applies to the UI and classic starling clips)
You can clearly see the draw calls changing when enabling/disabling MultiTextureStyle or setting its maxTextures
Massive was updated to 1.0.0-alpha.4 on github and haxelib
DisplayData (base class for QuadData and ImageData) now has skewX and skewY properties
DisplayData’s rotation, scaleX, scaleY, skewX and skewY are now inlined get/set with a “dirty” system : MassiveLayer now use that to know if it needs to recalculate vertices positions, which are stored and re-used when nothing changed. This opens the way for very efficient vertex animations, which I plan to add in “soon”
MassiveDisplay now has a colorOffsetMode property, which takes values from the ColorOffsetMode class (default NONE). Color offset can occur at the MassiveDisplay level, affecting all displayed content, and/or at the “object” (ImageData/QuadData) level.
MassiveColorMode was renamed to ColorMode and has an additionnal DISPLAY value which enables color only at the display level
Program (shader) creation code had a rewrite and is now optimized for every case (color, color offset and texture(s)). Created programs are stored in a cache and reused untill MassiveDisplay.clearProgramCache() is called
ParticleSystem and ParticleSystemOptions have new settings to make use of skew and color offset. Several presets in the particle editor demo have been updated to use those.
ParticleSystem and ParticleSystemOptions have a new emitterMode property which takes values from the EmitterMode class : default is STREAM which is what we had already, and the other one is BURST, which comes with a few additionnal properties : numBursts (how many bursts before stopping, 0 = infinite), burstDuration (for how long the system emits particles for a single burst, 0 = instant), burstInterval (how much time between two bursts) and burstIntervalVariance
About color offset
Color multiplies with texel color, while color offset adds or substracts. If you have a black pixel and want to colorize it red color won’t work because the RGB values are zero, and the multiplied result will still be zero. Color offset will color it red because it adds to that zero value.
You can use the particle editor demo to play around with color offset
ColorOffsetMode has 4 possible values :
DISPLAY enables color offset on the MassiveDisplay object, affecting all displayed content in the same way. You can then control color offset using the redOffset, greenOffset, blueOffset and alphaOffset properties.
OBJECT enables color offset for “display objects” (ImageData and QuadData). You can control color offset individually for each object using the redOffset, greenOffset, blueOffset and alphaOffset properties.
DISPLAY_AND_OBJECT enables color offset for both
NONE disables color offset entirely
You can use any combination of colorMode and colorOffsetMode : for example you could have colorMode set to ColorMode.NONE, which will still display textures, and colorOffsetMode set to ColorOffsetMode.OBJECT if all you want is color offset (to make an enemy blink red when taking damage for example)
Remember that colorMode and colorOffsetMode (as well as using multiple textures) affects the Program (shader) complexity so for best performance you should use the minimum settings that you need.
An interesting side effect of color offset is that you can use negative alphaOffset values to achieve the exact same result as BlendMode.ADD but with more control : setting alphaOffset to -1.0 is like 100% ADD, while -0.5 is 50% ADD
I think this only works with textures that have premultiplied alpha, which is typically the case anyway.
You can see this in action by launching the ParticleEditor and load the animated fx, ghost donut or star geyser preset
That makes me want to do some kind of “Vampire Survivor” demo… but that’ll have to wait