Do Sprites need children? You decide!

[xerver]

Hey all,

 

Mat and I are trying to decide if Sprites (and Graphics) should inherit from DisplayObject instead of DisplayObjectContainer for PIXI v3.

 

If you have thoughts about it, please post them here: https://github.com/GoodBoyDigital/pixi.js/issues/1380

 

We don't think Sprites need to have children, let us know what you think!

 

-Chad

[jpdev]

How would I build a tank with a rotation turret and animated trails?

 

(Example here: http://jppresents.net/games/tanks/ - this is using phaser 2.x and pixi through that).

 

My tank is a sprite with the turret and the trails as children.

(With offsets and in case of the turret with their own rotation).

 

Everything transforms (moves, rotates) together with the main sprite (the tank body), without any additional code.

 

How would this work without children?

 

(Another example would be equipment like a gun on a player sprite.)

 

[Edit: also posted on github]

[achexi]

How would I build a tank with a rotation turret and animated trails?

 

(Example here: http://jppresents.net/games/tanks/ - this is using phaser 2.x and pixi through that).

 

My tank is a sprite with the turret and the trails as children.

(With offsets and in case of the turret with their own rotation).

 

Everything transforms (moves, rotates) together with the main sprite (the tank body), without any additional code.

 

How would this work without children?

 

(Another example would be equipment like a gun on a player sprite.)

 

[Edit: also posted on github]

Could you not place it all inside of a DisplayObjectContainer and perform transforms on that?

 

Also my vote - yes to sprites, they definitely don't need them, but as its already been said it would require making more DOC's. It looks like it all just comes down to performance vs development, are the performance gains that noticeable?

[InsOp]

I always root for performance if there is still a workaround with DOCS to any possibility i could achieve with sprites with children

[hubert]

YES. Sprites need children. For example my main player sprite has children with info about his health, name etc. for other players to see in myltiplayer game.

So when moving my sprite I simply change the position and don't pay attention to metadata about the player contained as children text and graphics.

 

My question to you is will it improve the rendering speed significantly?

 

http://www.sevenative.com

[xerver]

YES. Sprites need children. For example my main player sprite has children with info about his health, name etc. for other players to see in myltiplayer game.

So when moving my sprite I simply change the position and don't pay attention to metadata about the player contained as children text and graphics.

 

My question to you is will it improve the rendering speed significantly?

 

http://www.sevenative.com

 

The point of this question is that your use case is common, and easily done with DOCs instead of sprites. We don't need to know what you can do with children in sprites, we wanted to know what you do with children in sprites that you can not do with a DOCs with sprite children.

[alex_h]

Lot's of people seem to have misinterpreted the question as meaning 'should Pixi use a scene graph?' or 'should DisplayObjectContainers exist?'

 

Personally I vote for keeping texture display and child ownership logically separate. Make Sprite extend DisplayObject so its responsibility is purely about textures, if you want children use a DOC. Simple and clean.

[msha]

Lot's of people seem to have misinterpreted the question as meaning 'should Pixi use a scene graph?' or 'should DisplayObjectContainers exist?'

 

Personally I vote for keeping texture display and child ownership logically separate. Make Sprite extend DisplayObject so its responsibility is purely about textures, if you want children use a DOC. Simple and clean.

+1

[xerver]

 

Lot's of people seem to have misinterpreted the question as meaning 'should Pixi use a scene graph?' or 'should DisplayObjectContainers exist?'

 

Personally I vote for keeping texture display and child ownership logically separate. Make Sprite extend DisplayObject so its responsibility is purely about textures, if you want children use a DOC. Simple and clean.

 

 

 

That is how we felt, but the overwhelming majority of people wanted children in Sprites :/

[hubert]

 

 

 

 

 

That is how we felt, but the overwhelming majority of people wanted children in Sprites :/

 

 

 

 

Will removing children from sprites have significant impact on rendering speed?

[xerver]

Will removing children from sprites have significant impact on rendering speed?

 

Probably not.

[InsOp]

will it be easier then to develop pixijs?

[chalgoman]

I've always wondered why Sprites and Graphics in pixi can have children. I think they should be just DisplayObjects, not DisplayObjectContainers. I've previously used EaselJS and it's equivalent of PIXI's sprites is Bitmap which don't have children. I've never had any problems with this - when I need to transform more objects together, just put all in same container and transform this container.

[kartung]

Based on AS3 I would say yes.  The abstraction was that sprites can contain children and be drawn upon and graphics can only be drawn upon.  If this is no longer the abstraction you wish, I would suggestion updating the documentation to clearly express this to those devs coming from a Flash background (and once the docs let people know, it probably doesn't matter either way). 

 

(Just as a side note: in the current version of pixi (2.2.8), it appears that there are bugs in computing the bounds of graphics objects that contain children (code in: PIXI.Graphics.prototype.updateLocalBounds = function()). Additionally, it appears that the bounds/transform of a display object container is not updated when a child is added.  This is probably because the development model is to use a DOC.)

 

To balance the post from InsOp.  I cast a vote for code maintainability and understandability over performance.

 

cheers