Error: Unsupported display object: starling.display.graphics::Stroke

[FlashSoft]

Game.class

package
{

    import starling.display.Shape;
    import starling.display.Sprite;
    import starling.events.Event;

    public class Game extends Sprite
    {
        public function Game()
        {
            super();
            this.addEventListener(Event.ADDED_TO_STAGE, onAddToStage);
        }

        private function onAddToStage(event:Event):void
        {
            this.removeEventListener(Event.ADDED_TO_STAGE, onAddToStage);

            var shape:Shape=new Shape();
            shape.graphics.lineStyle(1, 0x000000);
            shape.graphics.lineTo(100, 100);
            var sprite:Sprite=new Sprite();
            sprite.flatten();
            sprite.addChild(shape);
            this.addChild(sprite);
        }
    }
}

This class has a compile error

Error: Unsupported display object: starling.display.graphics::Stroke

But I just use the flatten method Why will complain.

[jonathanrpace]

Some details here http://forum.starling-framework.org/topic/flatten-custom-displayobjects

The short answer is that Starling only knows how to 'flatten' its own display objects, not the Shapes/Strokes/Fills from the Graphics Extension.

I may add this feature in future - however you would only able to call 'flatten()' on a Shape instances, not on containing Sprites. ie

var shape:Shape = new Shape(); shape.graphics.doSomeStuff() ... ... shape.flatten()

[FlashSoft]

Thank you for your help, I can try it.

[konsnos]

I have the same problem unfortunately :( Is there a possibility to create a compatible version if it's easier than to create the whole feature?

[IonSwitz]

In order for a Sprite to be able to flatten a Shape, the base Starling code would have to know about the Shape class, so that is impossible.

What scenario do you have today that requires this to work? I guess it is possible to create a flatten that only works within the Graphics Extension family of objects, but I'm not entirely sure what the benefit would be and what scenarios that would help.

What is your current scenario, konsnos? Can you please describe the situation you are facing and why flatten support would help?

[konsnos]

Of course, and thank you for the reply IonSwitz. I don't undestand the internals of gpu rendering so my description will be a bit more summarized than what you would expect.

My situation is that I have a sprite which contains movable objects and buttons, a minimap to be exact. In that minimap I draw a rectangle from the Extension Graphics to simulate the position of the camera. That minimap contains the background map, the rest of the gui, some Quads to represent the position of several objects which periodically change their x and y, and some buttons, all added to the same sprite. So far I used to flatten this sprite when the objects positions have been updated, or a button is pressed to show the animation. I hope my description is descriptive enough.

[IonSwitz]

The problem isn't as much the internals of GPU rendering, but the problem of code dependency. If Starling is dependent on a Starling Extension, we get a circular dependency, since the Starling Extension obviously is dependent on Starling.

I will look at this and eventually see if something can be suggested to Daniel at the Starling team, but as I see it now, it won't be simple. I will get back to you, in this thread, though.

[konsnos]

Thank you IonSwitz, and since I didn't have the chance to thank you and the previous team for the Extension Graphics, I thank you now. It's very helpful! Veri nice work.

[IonSwitz]

As I think of this, though, I would say that it is really very little that can be done. There is no benefit to be had from flattening the sprite this way, in the scenario you describe. I assume the objects on the minimap all use textures that differ from the rectangle you draw with the Graphics Extension, so the state changes will have to occur anyway, and the benefit of the flatten call would be broken. My suggestion would be to do the following (in pseudo code):

var minimapSprite:Sprite = new Sprite(); // the root sprite of the minimap var mapObjectSprites:Sprite = new Sprite(); // the sprite that will get flattened, holding all Images and Quads var gfxExtensionSprite:Sprite = new Sprite(); // the sprite that holds the Graphics Extension entities.

mapObjectSprites.addChild( all map objects that are sprites, images, etc) mapObjectSprites.flatten(); minimapSprite.addChild(mapObjectSprites);

gfxExtensionSprite.addChild( all the Graphics extension Shapes you need); minimapSprite.addChild(gfxExtensionSprite);

Basically, it boils down to this: The benefit of flattening a Sprite would completely break if non-quad objects were to be allowed in the Sprite, so it would all be for nothing to support this kind of functionality.

There could potentially be something done at some point to support "flattening" of Strokes, for example, basically allowing many Strokes that are added to one parent to be batched in one huge piece of geometry, but that would still not help in the scenario of mixing Sprites/Images and Strokes/Fills.

[konsnos]

I'll do something like this for the time being.

I didn't know that were such kind of restrictions on the flatten functionality. I guess that the ability to flatten a sprite which contains both quads and strokes isn't solvable. The batching of such geometries sounds useful, although not in my case :) .