Pixi.js: Les Sprites ont-ils besoin d'enfants ?

non, je ne l'ai jamais utilisé pour PIXI.Sprite.
Mais je l'utilise pour PIXI.DisplayObjectContainer (exemple : supprimer tous les enfants)

Pour être clair, il s'agit de faire en sorte que Sprite hérite de DisplayObject au lieu de DisplayObjectContainer afin qu'il ne puisse pas avoir d'enfants. Ce sera un changement pour Sprite et Graphics , rien d'autre ne serait affecté.

J'ai déjà utilisé ça. Mon cas d'utilisation était un Sprite qui utilise une partie opaque blanche 2x2 d'un atlas de texture, afin que je puisse rendre des rectangles et des lignes sans aucun commutateur shader/buffer/texture et tirer parti du batcher de sprite. Cela a agi comme l'arrière-plan opaque d'un widget, et j'ai ajouté des enfants au sprite.

Je serais curieux de connaître les optimisations qui pourraient être faites. Dans quelle mesure entrent-ils dans une catégorie « prématurée » ?

Je vais réitérer mes réflexions sur Twitter, juste pour les enregistrer ici :

Ce serait vraiment utile si vous aviez un vaisseau spatial et que vous vouliez des lumières clignotantes dessus. Vous pouvez également avoir la physique définie sur le navire et ne pas être soustrait du navire à un DisplayObjectContainer .

Je suppose que ce que j'essaie de dire, c'est que j'aime la construction mentale/modèle d'interagir directement avec un Sprite , qu'ils aient ou non des enfants Sprite s.

Ce n'est pas un gros problème, mais je suppose que si j'avais ma construction idéale, je ne voudrais pas avoir à utiliser des sprites « cas spéciaux » qui contiennent également des sprites enfants.

Je ne serais pas opposé à ce changement, mais j'en abuse abondamment

https://github.com/serprex/openEtG/blob/master/views/Match.js#L241
https://github.com/serprex/openEtG/blob/master/gfx.js#L118
https://github.com/serprex/openEtG/blob/master/views/Shop.js#L89

J'utilise parfois des enfants de sprites. Par exemple, lorsque j'ai besoin de créer un bouton, d'ajouter le texte à l'intérieur. Je le fais sans raison solide, car j'imite le comportement de DOM et je trouve parfois plus facile de définir la position des enfants par rapport à son parent. TBH, quand j'ai commencé à apprendre PIXI, je n'avais aucune idée si un événement pouvait être déclenché si un sprite non interactif était sur mon sprite interactif. C'est pourquoi j'ai commencé à faire ça.

J'ai utilisé la fonctionnalité (dans les graphiques aussi) mais surtout à cause de la paresse et de l'ambiance hackfest. Je suis pour le changement d'étendre uniquement à partir de DO à la place, cela conduirait à une situation où tous les cas d'utilisation auxquels je peux penser ne peuvent être effectués que d'une manière qui est bonne imo, @mattdesl case/question est également bon cependant.

Je pense que c'est utile lorsque vous voulez faire une rotation héritée, pour quelque chose comme un bras par exemple, avec un bras supérieur, un bras inférieur et une main parentés ensemble. Si vous deviez utiliser des conteneurs, cela impliquerait 6 objets au lieu de 3.

Je pense que @beeglebug a touché quelque chose d'assez important en termes de convivialité.

@GoodBoyDigital de quel type d'optimisation des performances parlons-nous ? Auraient-ils un impact global sur le monde réel ? Il y a peut-être une bonne raison d'avoir une sorte de Sprite optimisé qui ne peut pas avoir d'enfants, tout en conservant le comportement Sprite existant. Similaire à SpriteBatch vs DisplayObjectContainer

Un vote enthousiaste pour les sprites avec children . :+1:
C'est un modèle d'API sensé et simple avec lequel un utilisateur final comme moi peut travailler.
Je sacrifierais volontiers un peu de performance pour cette commodité.

Mon projet étudie actuellement l'utilisation de Pixi comme moteur de rendu (plus de détails sur https://github.com/phetsims/scenery/issues/350). La complexité de notre implémentation serait considérablement plus élevée si les nœuds Pixi (y compris Graphics, Sprite et Text) ne pouvaient pas avoir d'enfants. Mais il serait également bon de quantifier les compromis de performance.

Juste un remue-méninges ici : une façon d'améliorer les performances dans la mesure du possible sans compliquer l'API serait de faire basculer en interne Pixi entre le style DisplayObject et le style DisplayObjectContainer lorsque le premier enfant est ajouté. Ou peut-être que cela augmenterait trop la complexité de Pixi et aussi le temps de démarrage de l'application :(

Les Sprites ont-ils besoin d'enfants ? Absolument!!

Mais pensez autrement... Les sprites sont le seul moyen d'afficher une texture simple et ils peuvent avoir des enfants. Pourquoi n'y a-t-il pas de classe Image étendant DisplayObject ?

Ce serait vraiment pratique car dans un premier temps, la plupart des gens utiliseraient l'objet Image au lieu de Sprite. Et puis nous pourrions voir si nous utilisions principalement un DisplayObjectContainer et poussions Image à l'intérieur. Ou juste un Sprite avec beaucoup d'autres enfants Sprite.

Bien sûr, ils ont besoin d'enfants :)
Et Pixi a peut-être besoin d'un DisplayObject supplémentaire comme une classe Bitmap ( tout comme l'API flash :) )

Je n'ai jamais ajouté d'enfants à Sprite ou MovieClip dans aucun projet sur lequel j'ai travaillé.

J'ai peut-être ajouté des enfants à Sprites dans le passé, mais je ne me souviens pas que cela ait jamais été un cas d'utilisation principal.

Si cela se brisait soudainement, je passerais simplement à des DOC remplis de Sprites.

Ouais au départ je pensais que c'était étrange ce n'est pas ce à quoi je m'attendais, mais c'est pratique comme beaucoup de commentaires ci-dessus surtout quand on veut l'image en arrière-plan et d'autres éléments en haut comme un bouton avec un TextField pour un exemple moins intéressant !! Au départ, je l'ai toujours fait avec DisplayObjectContainers, mais une fois que j'ai réalisé que Sprite pouvait le faire, j'ai pensé l'utiliser à la place lorsque je voulais ce type de fonctionnalité.

Je suggère de créer une nouvelle classe pour cela, c'est-à-dire Image ou Bitmap. C'est ce que fait Starling pour AIR, sinon oui, j'imagine que la mise à jour v3 nécessitera de nombreux projets nécessaires pour refactoriser le code dans ces cas.

J'utilise pixi via phaser. Et j'aime pouvoir attacher des sprites à d'autres sprites.

Je veux dire, comment pourrais-je construire un char avec une tourelle rotative et des pistes animées ?

(Exemple ici : http://jppresents.net/games/tanks/ - cela utilise phaser 2.x et pixi à travers cela).

L'exemple de char est un sprite avec la tourelle et les traînées comme des sprites pour enfants.
(Avec des décalages et dans le cas de la tourelle avec sa propre rotation).

Tout se transforme (se déplace, tourne) avec le sprite principal (le corps du réservoir), sans aucun code supplémentaire.
Comment cela fonctionnerait-il sans enfants ?

Venant d'un milieu Starling & Adobe Air, j'ai d'abord pensé « Sprites avec des enfants ? Beurk ! »
Mais à l'occasion, j'ai découvert que j'avais besoin d'un autre sprite supplémentaire où j'en avais initialement mis un seul et j'ai fini par utiliser la fonctionnalité par pure paresse, plutôt que d'échanger laborieusement le premier sprite pour un DisplayObjectContainer et ainsi de suite. C'est donc le seul avantage que je peux voir - fournir une option paresseuse pour les paresseux. Je suis sûr qu'il serait en quelque sorte plus propre d'étendre DisplayObject à la place. Je ne vois aucun scénario dans lequel avoir des enfants d'un Sprite pourrait apporter des avantages qui ne pourraient pas être obtenus plus ou moins également simplement en utilisant DisplayObjectContainers, même si cela signifie avoir un ou deux objets d'affichage supplémentaires.

Pour ce que ça vaut, je n'ai jamais utilisé un enfant de Sprite non plus, dans aucun projet Pixi/Phaser. J'avais l'habitude de le faire beaucoup en Flash, où cela me paraissait plus naturel.

Cela dit, je connais un nombre important de développeurs qui utilisent cette fonctionnalité dans leurs jeux. Une partie de moi pense que si vous prétendez soutenir une vraie liste d'affichage, alors vous devez réellement soutenir une vraie liste d'affichage ! Pourtant, les DOC peuvent faire tout ce que les enfants Sprite peuvent faire, ils sont juste un peu plus verbeux dans leur configuration - ils nécessitent plus d'objets, et donc plus de mémoire, pour réaliser exactement la même chose que vous pouvez faire actuellement.

S'il ne s'agit que d'accélérer le traitement par lots, alors peut-être qu'un objet de base sans conteneur aurait plus de sens ? Comme une classe Particle ou Image.

Le peuple a parlé ! :)
Sprites avec des enfants c'est ça !

Merci à tous pour vos retours à tous !

Je voudrais ajouter à ceci :

S'il existe un potentiel d'optimisation pour les DOC sans enfants, alors peut-être que la détection dynamique des DOC sans enfants est la voie à suivre. Si cela fonctionne, pourquoi avoir à la fois DisplayObject et DisplayObjectContainer ? Pourquoi ne pas avoir tous les DisplayObjects capables de contenir des enfants ?

+1 J'étais également curieux à ce sujet.

Je ne vois aucune performance plus ou moins ici. Cela semble être une question d'organisation pour moi.

Si les sprites pouvaient avoir des enfants, vous pourriez étendre votre code plus facilement.

Mais oui, une liste de sprites sans enfants devrait être facilement accessible.

Et puis, quel est l'intérêt des DisplayObjectContainers ? Faites simplement de tout un sprite qui peut ou non avoir des enfants ou peut ou non avoir une texture qui lui est attachée. (Est-ce trop rétro) ?

Ma terminologie Phaser est peut-être obscure, mais pour moi, je n'utilise jamais de Sprites. Fondamentalement, si j'ai besoin d'un DisplayObjectContainer, j'utilise un groupe. Si c'est un objet DisplayObject, j'utilise une image. Je connais à l'avance les relations de ce que je construis et ne vois aucune raison (autre que la confusion) pour laquelle je créerais un nœud qui fait les deux en même temps. Je trouve plus facile de gérer simplement un conteneur d'objets d'affichage pour créer ce que je suppose être un "Sprite".

Dans PIXI, un sprite n'est qu'un objet texturé. Phaser.Group hérite de PIXI.DisplayObjectContainer . Phaser.Image hérite de PIXI.Sprite (qui hérite de PIXI.DisplayObjectContainer ) et affiche une texture. Phaser.Sprite hérite également de PIXI.Sprite et affiche une texture et inclut la physique et les animations.

Je me rends compte qu'il s'agit d'un _vraiment_ vieux problème - mais je m'amuse à faire abstraction de PIXI dans un moteur de rendu réactif et les performances sont importantes là-bas. Pas du côté PIXI, mais du côté React.

Mon plan pour le moment est d'avoir deux types de wrappers Sprite - ceux qui peuvent avoir des enfants et ceux qui ne le peuvent pas, avec la valeur par défaut Sprite étant ceux qui _ne peuvent pas_.

Est-ce quelque chose qui a déjà une convention de nommage ou qui est divisé en v5 ? Mon intention est de nommer la version conteneurisée "SpriteContainer".

Encore une fois, cela ne touche aucun élément interne PIXI, et sous le capot, c'est toujours Sprite dans les deux cas - je voulais juste m'assurer que je ne manque pas une convention de nommage préexistante ;)

Il est difficile d'expliquer la différence entre DisplayObject et Container, c'est un peu la même chose avec des fonctionnalités séparées, cela vient du flash.

Et en flash, Sprite peut aussi avoir des enfants, c'est basé sur DisplayObjectContainer

Comment se déroulent vos expérimentations ?

Les expériences se déroulent bien jusqu'à présent... React est certainement un goulot d'étranglement mais pas un obstacle dans la plupart des cas.

Si je peux faire fonctionner ce changement (les bords ne peuvent pas être des conteneurs), alors react+pixi fonctionne à environ 20 000 lapins alors que pixi native fonctionne à environ 50 000 lapins. totalement utilisable ! mais je dois d'abord introduire ce changement...

Je me demande juste ici, mais quel est le cas d'utilisation? Pouvez-vous donner un lien vers votre
travailler?

Le 4 octobre 2017 à 00h32, "David Komer" [email protected] a écrit :

Les expériences se déroulent bien jusqu'à présent... React est certainement un goulot d'étranglement, mais
pas un écueil pour la plupart des cas.

Si je peux faire fonctionner ce changement (les bords ne peuvent pas être des conteneurs), alors
react+pixi se produit à environ 20 000 lapins où pixi native se produit à
environ 50 000 lapins. totalement utilisable ! mais je dois introduire ce changement
première...

-
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/pixijs/pixi.js/issues/1380#issuecomment-334047182 , ou couper le son
le fil
https://github.com/notifications/unsubscribe-auth/ADFJWGJkslw1Nz1okGAM1BXMOm89XYVhks5sowpMgaJpZM4DW7sQ
.

@agamemnus - le cas d'utilisation consiste à piloter PIXI avec React

Je viens juste de terminer quelques trucs de benchmarking initiaux... écrire un moteur de rendu personnalisé n'a pas amélioré les performances.

Mais cela a aidé la convivialité :)

Je viens de soumettre le sujet sur le forum PIXI avec des liens vers le code et la démo : http://www.html5gamedevs.com/topic/33240-react-fiber-renderer/

Ce fil a été automatiquement verrouillé car il n'y a eu aucune activité récente après sa fermeture. Veuillez ouvrir un nouveau problème pour les bogues liés.