Emetteur de particules : optimisation de code

[Titan]

Ben en regardant avec ILSpy, le Stack<T> utilise un array et lors du push il le redimensionne comme une List<T> :

Ok, c'est une implémentation surprenante et c'est bon à savoir, mais ça se défend, puisque on ne peut pas supprimer un élément au milieu, y'a jamais besoin de décaler quoi que ce soit, il faut simplement penser à l'initialiser suffisamment grande au début du coup.

La solution la plus simple serait pas d'utiliser une classe Particle custom ? Parce que gérer les pointeurs à la main pour ça, faut être courageux quand même .

J'avais pas regarder sa fonction "draw" et j'ai supposer qu'il y avais une raison pour qu'il utilise les ParticleSystem.Particle du moteur, mais effectivement il suffit de créer une classe

[Alesk]

La solution la plus simple serait pas d'utiliser une classe Particle custom ? Parce que gérer les pointeurs à la main pour ça, faut être courageux quand même .

Je suis parti sur l'utilisation des particules native d'unity car je voudrais faire un truc qui peut se connecter à shuriken, pour remplacer son renderer... mais bon, je sens bien que je risque de faire sans finalement... ça sera pour plus tard... Et c'est pas si compliqué de gérer les pointeurs à la main, la preuve :p

Ma solution avec les arrays semble bien fonctionner et me permet de ne jamais faire de copie des objets "particle" lors de mes traitements (puisque je passe par un tableau de pointeurs), excepté lorsque j'opère un resize bien sûr, ce qui peut être fait très rarement (et qui ne provoque aucune incidence sur les perfs, de ce que j'ai pu voir, même en le faisant au taquet),
Garder en mémoire un pool de 20000 particules dans un array ou dans une linkedlist, ça ne changera pas drastiquement grand chose à la conso de ram non ?

Je vais regarder du coté du Stack pour voir si ça change quelque chose...

Pour info, j'utilise la versions free, donc pas de profiler pour moi...

[ZJP]

Personnellement, la version à 1.5ms pour 20000 particules est ok.

[Alesk]

Oui pour moi aussi :p
Surtout qu'au final je peux afficher que 16000 particules sur un même mesh (mais je vais répartir les particules sur plusieurs meshes)

Mais bon là je cherche vraiment à optimiser les perfs à fond.

1.5ms à 60fps ça représente 9% du temps de calcul alloué à une frame, sachant que j'ai ensuite le Z sorting à gérer par dessus, je ne voudrais pas que la conso de cpu s'envole juste pour ça, le but c'est tout de même de pouvoir l'utiliser dans un jeu avec d'autres trucs autour

[Titan]

Tu n'utilise pas de pointeur dans la version array, tu fait juste moins de copie.
Pour utiliser des pointeurs, il faut déclarer la classe unsafe, modifier les informations de compilation d'unity pour qu'il accepte et ensuite déclarer un tableau de "Particle*" plutôt qu'un tableau de "Particle". tu déréférence avec * et tu référence avec & lors de tes manipulations, sans oublier les parenthèse si tu le manipule avec les opérateur [] ou . parce qu'ils ont la priorité sur les opérations de pointeurs. Mais c'est pas nécessaire^^

ZJP n'a pas tord dans le sens ou même si on fait fonctionner correctement la LinkedList, les perfs ne seront probablement pas meilleur, c'est juste moins de code, beaucoup moins de mémoire alloué et plus de problème de spike et comme tu l'a dit pour défendre ta fonction Resize, "c'est stimulant pour ton ptit cerveau" ^^.
En revanche remplacer la structure c'est impératif au moins pour gagner de la place; ça devrait pas changer grand chose pour ton array vu que tes particules restent très longtemps.

[ZJP]

Disons que j'ai une dizaine de missiles ou roquettes dans ma scène, 1000 particules par objet me semble très largement suffisant. Cela dit, je comprend que tu veuilles optimiser ton projet pour tenir compte d'un plus large éventail d'utilisateurs.
Cependant, je ne suis pas le seul dans ce cas. Il te faudra à un moment donné couper la poire en deux pour éviter de frustrer les potentiels clients du forum officiel qui attendent depuis plusieurs mois une release "acceptable" de ton produit.

Tu donnes trop d’à coup à ton développement : je m'y mets, j'arrête car pas de temps, je m'y remets cette fois sérieusement....etc. Des questions légitimes sur la qualité future de ta hot-line sont ou seront d'actualité. Livres un truc potable en version 1.x. Par la suite, une lignée 2.x avec un changement de paradigme, facturée autrement est jouable. Tout les clients n'auront pas forcement besoin de cette nouvelle version.


JP

[Alesk]

Quand je dis que j'utilise des pointeurs, c'est un abus de langage au sens "informatique pur" du terme, c'est vrai...
Si on oublie la fonction Resize, j'ai un array qui contient les objets Particle (le pool), qui ne sont jamais déplacés ni copiés d'aucune façon (donc aucune perte de performances là dessus, et accès random O(1) si je ne m'abuse)
Et à coté de ça j'ai un autre array avec des int (mes "pointeurs") qui eux sont réagencés (échange de deux d'entre eux) à la mort de chaque particule, et qui me permettent de savoir où piocher dans le pool.

Sinon question comme ça : en quoi une LinkedList occupe moins de place mémoire qu'un array ? Je ne suis pas expert en entrailles de structures de données, mais dans une LinkedList on a des LinkedListNodes qui ont chacun un pointeur vers le node précédent et suivant, donc rien que ça déjà j'aurais tendance à dire que ça occupe plus de ram qu'un array, non ?

Autre question dans le même genre : pourquoi un objet "class" est plus léger qu'un "struct" selon vous ? J'aurais eu tendance à croire l'opposé...

[ZJP]

Tu as lu mon message?!

[Alesk]

Cependant, je ne suis pas le seul dans ce cas. Il te faudra à un moment donné couper la poire en deux pour éviter de frustrer les potentiels clients du forum officiel qui attendent depuis plusieurs mois une release "acceptable" de ton produit.

Tu donnes trop d’à coup à ton développement : je m'y mets, j'arrête car pas de temps, je m'y remets cette fois sérieusement....etc. Des questions légitimes sur la qualité future de ta hot-line sont ou seront d'actualité. Livres un truc potable en version 1.0 et optimises ensuite.

Oui je sais bien... sauf que ma démo actuelle n'était vraiment pas exploitable telle quelle dans un vrai projet, c'est pour ça que je dois en repenser une partie.
C'est bien beau de pouvoir faire un rendu sympa des particules, mais si on ne peut pas gérer leurs déplacements correctement ça sert pas à grand chose, c'est pour ça que je voulais vérifier la possibilité de greffer ça sur shuriken avant.

Coté régularité, la vie a fait que c'était assez chaotique pour moi ces derniers temps. Mais ça va mieux maintenant, et ça ira encore mieux dans un mois

EDIT : oui j'ai lu, on s'est croisé :p

[ZJP]

Coté régularité, la vie a fait que c'était assez chaotique pour moi ces derniers temps. Mais ça va mieux maintenant, et ça ira encore mieux dans un mois

M'en parle pas!!!

EDIT : oui j'ai lu, on s'est croisé :p

M'en doutais quand même.

Oui je sais bien... sauf que ma démo actuelle n'était vraiment pas exploitable telle quelle dans un vrai projet, c'est pour ça que je dois en repenser une partie.

Ah chapeau l’illusionniste, tu montrais de la...fumée.