-
-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Do Sprites need children? #1380
Comments
no, I never used it for PIXI.Sprite. |
To be clear, this is about making |
I've used this before. My use case was a Sprite that uses a 2x2 white opaque part of a texture atlas, so that I can render rectangles and lines without any shader/buffer/texture switches and take advantage of the sprite batcher. That acted as the opaque background of a widget, and I added children to the sprite. I'd be curious about the optimizations that could be made. To what extent do they fall into a "premature" category? |
I'll re-iterate my thoughts from Twitter, just to have them logged here: It would be really useful if say you had a space ship and you wanted blinking lights on it. You might also have physics set on the ship, and not be abstracted away from the ship to a I guess what I am trying to say is that I like the mental/model construct of interacting directly with a It's not a huge deal, but I guess if I had my ideal construct, I wouldn't want to have to 'special case' sprites that also contain children sprites. |
I wouldn't be opposed to this change, but I abuse this extensively https://github.com/serprex/openEtG/blob/master/views/Match.js#L241 |
I sometime use children of sprites. For example, when I need to create a button, to add the text inside. I do this without a solid reason, because I imitate the behavior of DOM and sometime find it easier to set the position of the children relative to its parent. TBH, when I started to learn PIXI, I had no idea if an event could be fired if a non-interactive sprite was over my interactive sprite. That's why I started to do this. |
I've used the functionality (in Graphics too) but mostly because of laziness and hackfestmood. I am for the change of extending only from DO instead, It would lead to a situation were all use cases I can think of can only be done in one way which is good imo, @mattdesl case/question is also good though. |
I think its useful when you want to do inherited rotation, for something like an arm for example, with an upper arm, lower arm and hand parented together. If you had to use containers it would involve 6 objects instead of 3. |
I think @beeglebug has hit on something pretty important in terms of usability. @GoodBoyDigital what kind of performance optimizations are we talking about? Would they have overall real world impact? Perhaps there's a good reason to have a sort of optimized |
One enthusiastic vote for sprites with |
My project is currently investigating using Pixi as a renderer (more details in phetsims/scenery#350). The complexity of our implementation would be considerably higher if Pixi nodes (including Graphics, Sprite and Text) couldn't have children. But it would also be good to quantify the performance tradeoffs. Just brainstorming here: one way to get improved performance where possible without complicating the API would be to have Pixi internally switch between the DisplayObject style and DisplayObjectContainer style when the first child is added. Or perhaps this would just increase Pixi's complexity too much and also the application startup time :( |
Do Sprites need children? Absolutely!! But think in an other way... Sprites are the only way to display a simple texture and they can have children. Why there isn't an Image class extending DisplayObject? It would be really convenient since in a first time most people would use Image object instead of Sprite. And then we could see if we mostly use a DisplayObjectContainer and push Image inside. Or just a Sprite with many others Sprite children. |
Sure they need children :) |
I have never added children to Sprite or MovieClip in any project I have worked on. |
I may have added children to Sprites in the past, but I don't recall that ever being a primary use-case. If that suddenly broke, I would just switch to DOCs full of Sprites. |
Yeh initially I thought this was odd its not what I expected, but it is handy as many of the comments above especially when you want the image on the background and other elements on top such as a button with a TextField for less interesting example!! Initially I did this always with DisplayObjectContainers but once I realised Sprite could do this then I thought I would use this instead when I wanted this type of functionality. I suggest create a new class for this i.e. Image or Bitmap. Thats what starling does for AIR otherwise yeah I imagine for v3 update will require many projects needed to refactor code in these cases. |
I am using pixi through phaser. And I love that I can attach sprites to other sprites. I mean, how else 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). The example tank is a sprite with the turret and the trails as children sprites. Everything transforms (moves, rotates) together with the main sprite (the tank body), without any additional code. |
Coming from a Starling & Adobe Air background I initially thought 'Sprites with children? Yuk!' |
For what it's worth I've never used a child of a Sprite either, in any Pixi/Phaser project. I used to do it a lot in Flash though, where it just felt more natural. Having said that I know a significant number of devs who do use this feature in their games. Part of me thinks if you're going to claim you support a true display list, then you need to actually support a true display list! Yet DOCs can do everything Sprite children can, they're just a bit more verbose in setting them up - they require more objects, and thus more memory, to achieve the exact same thing you can do currently. If this is all just about speeding-up batching then perhaps a non-container base object would make more sense? Like a Particle or Image class. |
The people have spoken! :) Thank you all for your feedback everyone! |
I'd like to add to this: If there's optimization potential for no-children DOCs, then perhaps detecting no-children DOCs dynamically is the route to go. If that works, why have both DisplayObject & DisplayObjectContainer? Why not have all DisplayObjects be capable of containing children? |
+1 I was curious about this as well. |
I don't see any performance plus or minus here. It seems to be an organization question for me. If sprites could have children, you could extend your code easier. But yes, a no-children sprite list would need to be easily accessible. And then, what's the point of DisplayObjectContainers? Just make everything a sprite that may or may not have children or may or may not have a texture attached to it. (Is that too retro)? |
My Phaser Terminology might be obscure, but for me, I never use Sprites. Basically if I need a DisplayObjectContainer, I use a Group. If its a DisplayObject, I use a Image. I know the relationships of what I am building in advance, and see no reason (other than confusion) why I would create a node that does both at the same time. I find it easier to just manage a display object container to build what I guess is a "Sprite". |
In PIXI a sprite is just a textured object. |
I realize this is a really old issue - but I'm playing around with abstracting PIXI into a react-renderer and the performance hit is significant there. Not on the PIXI side, but on the React side. My plan for now is to have two types of Sprite wrappers - those that can have children and those that can't, with the default Is this something that already has a naming convention or split in v5? My intent is to name the containerized version "SpriteContainer". Again this isn't touching any PIXI internals, and under the hood it's still Sprite in both cases - just wanted to make sure I'm not missing some pre-existing naming convention ;) |
Its difficult to explain DisplayObject and Container difference, they're kinda the same thing just with separated functionality, it comes from flash. And in flash, Sprite can have children too, its based on DisplayObjectContainer How your experiments are going? |
Experiments are going good so far... React is definitely a bottleneck but not a showstopper for most cases. If I can get this change working (edges can't be containers), then react+pixi performs at around 20,000 bunnies where pixi native performs at around 50,000 bunnies. totally useable! but I need to introduce this change first... |
Just wondering here but what's the use case? Can you give a link to your
work?
On Oct 4, 2017 12:32 AM, "David Komer" <notifications@github.com> wrote:
Experiments are going good so far... React is definitely a bottleneck but
not a showstopper for most cases.
If I can get this change working (edges can't be containers), then
react+pixi performs at around 20,000 bunnies where pixi native performs at
around 50,000 bunnies. totally useable! but I need to introduce this change
first...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1380 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ADFJWGJkslw1Nz1okGAM1BXMOm89XYVhks5sowpMgaJpZM4DW7sQ>
.
|
@agamemnus - use case is to drive PIXI with React I just finished some initial benchmarking stuff... writing a custom renderer did not help performance. But it did help usability :) Just submitted the topic on the PIXI forum with links to code and demo: http://www.html5gamedevs.com/topic/33240-react-fiber-renderer/ |
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Does anyone use the PIXI.Sprite's children functionality?
What are cases when you need it instead of just 2 sprites in a container?
If we remove this for v3 then we can optimize various sprite functions to be a little faster and cleaner. The same goes for graphics too.
Keen to get some opinions from you guys n gals on this one!
Cheers!
Mat
The text was updated successfully, but these errors were encountered: