What do you feel is still missing from Starling?

Fancy2209

I've been having tons of fun contributing to Starling, but due to it being a very mature project, who has been developed for over 14 years, I don't have a lot of ideas.
For this reason I'm making this blog post to ask what do you all feel Starling is missing to get ideas on what to work on.

Shaun_Max

Fancy2209 One thing I personally missed after switching to Starling is the full compatibility of GreenSock. While it's core tweening works well, several plugins, especially those involving text and filter-based effects—aren’t Starling-friendly. Improving and bridging that gap would be a huge win.

785597448

I hope the 'canvas' class supports drawing strokes and can obtain built-in real-time fps to display on custom text boxes

785597448

By the way, it seems that Starling's display objects do not have "rectangular border collision detection". It is recommended to add it

HaimSh

There are all kinds of optimizations I thought about doing.
One thing is to have the ability to have more than one viewPort like Unity does,
that way for DisplayObjects with no transform will render much faster and you could avoid reuploading and rebatch.
Also have a viewPort that has rotation.
Next have something like Unity SortingLayer.
There are also optimizations to be done to the particle system, instead of having DisplayObject
for each PDParticleSystem , have a an array of PDParticleSystem in one DisplayObject, that way you
don't need to batch them at all, on the way we can allow to use more than one MeshBatch so there will not be
particle count limitation per DisplayObject.
Next is to move the PDParticleSystem to be more SOA.
Next is better reusing of data
Lets say all your particles have the same UV and Color, so we ask starling for MeshBatch with
the color and size we want and give it back to starling after we are done with it, same thing for IndexData.
Or if we know the particles do not change position then reuse the VertexData from previous frame.
Other inefficacy we have is for each Image we render we call a function in the MeshStyle
instead of that have DisplayObjectContainer that all its children must have the same style,
then pass the array of children to the MeshStyle.
The next level after that is finding a way to have DisplayObjectContainer that
each of its children have static vertex size and must be visible, that way you can calculate
the MeshBatch size, that way you avoid ByteArray resizing, that will also be nice for my Starling version that use DomainMemory op codes.

2dguy

A generic high level "blit" helper that behind the scenes does all the low level batching, optimizing, state changes, drawing to the screen, etc, etc.

Blit_Start(); // Initialize blitting system
// Call a bunch of blits... blits from back to front....could be dozens, could be 1000s.
Blit(texture, srcx, srcy, width, height, x, y, xscale, yscale, rotation, red, green, blue, alpha, blendmode, xskew, yskew, center); // center = false then blit from top left
// Blit(...)
// Blit(...)
// etc, etc, etc
Blit_End(); //

I honestly don't know why this hasn't been added to Starling over the years. So many coders come from the copypixel() era, and this would be a 1:1 replacement for them. You could literally code an entire 2D game, with sprites, particles, bitmap fonts, etc, etc, using just that one high level call. I've actually been using a similar helper with a custom version of Genome2D/Stage3D for a long time, so I know the tech is doable. Granted this system redraws the entire frame every cycle from back to front (just like the old days) but it's fast enough to have 1000s of sprites, particles, bitmap fonts, etc, etc. So I know Starling could handle it.