Taille d'un sf::Vertex

[Lynix]

en règle générale, on alloue toute la mémoire nécessaire au fonctionnement lors de l'initialisation du jeu

Tu travail avec du matos d'il y a 20 ans ? 

C'est facile de dire ça quand ton ordinateur n'a aucun problème à gérer ce que tu lui donnes, cependant lorsque tu entres vraiment dans le temps réel, tu te retrouves très vite limité.

Pour un jeu à 60 FPS, tu n'as que 16ms pour générer une image, faire les calculs CPU et laisser la carte graphique faire ses propres calculs.

Une allocation dynamique est lourde, facilement plusieurs dizaines de microsecondes, tu te dis que ça n'est rien, mais même si ça ne prenait que 50us, ça signifie un vingtième de milliseconde, ça signifie qu'en enlevant tous les autres calculs et le rendu, tu ne pourrais faire que 320 allocations par frame pour tenir 60 FPS...

Bon après, le temps d'allocation varie de beaucoup, mais ça fait vraiment partie des opérations lourdes.

[Crone123]

OK, et quelque soit l'ordi (Tour ou portable) je tourne a minimum 300FPS avec 8000particules, je sais qu'allouer n'importe comment ralentit énormément le jeu, mais faut pas trop chipoter non plus non?

[Eroy]

Là c'est pas du chipotage Crone, c'est pas très performant ce que tu as fais, c'est certain que pour gérer ce genre de chose il ne faut pas faire d'allocations dynamiques.

Bon par contre je savais pas qu'on trouvait encore des pcs capables de ne faire que 320 allocations par 16ms, c'est une pièce de collection là carrément. Tu sauvegardes ton taff sur disquette ? (ouais ok je troll x) mais faut reconnaître que tes chiffres sont quand même vachement marseillais).

[Crone123]

Là c'est pas du chipotage Crone, c'est pas très performant ce que tu as fais, c'est certain que pour gérer ce genre de chose il ne faut pas faire d'allocations dynamiques.

Alors, je gère ça comment?
En sachant que sf::VertexArray est basé sur un std::vector<sf::Vertex>, et que std::vector est un tableau dynamique, j'en ferais dans tous les cas non?

Je vois pas trop où est le problème entre allouer des Vertex dans un tableau et devoir les copier si on veut les modifier, ou allouer des Vertex dans des pointeurs qui sont dans un tableau, et pouvoir utiliser directement le pointeur pour les modifier...

Si quelqu'un peut m'expliquer simplement l'exact problème de mon code ça serait sympa
Merci


EDIT:

Bon par contre je savais pas qu'on trouvait encore des pcs capables de ne faire que 320 allocations par 16ms, c'est une pièce de collection là carrément. Tu sauvegardes ton taff sur disquette ? (ouais ok je troll x) mais faut reconnaître que tes chiffres sont quand même vachement marseillais).

J'avoue, 320 c'est rien du tout. Mon PC en supporte bien 15000 - 30000 par seconde en dépassant les 250FPS...

[Eroy]

En fait souvent quand tu vas gérer des particules, par exemple avec des emitters tu sais de combien de particules tu auras besoin donc il vaux mieux jouer avec des particules active ou non pour les dessiner que d'en créer et supprimer à chaque foi. Après bon, on a pas le code sous les yeux non plus.

(non mais cherches pas pour les alloc, tu remplis un vecteur de string de 100k strings de cardinalité 50 en 23ms et on me dit là aussi 4Mo en 48ms donc oui il a dût se tromper)

[Crone123]

Niveau alloc j'en fais pas de trop.
Mais effectivement, trouver un système qui ré-utilise des anciens vertex ça peut être intéressant.
Mais bon, le recyclage monstre que ça ferait risque de générer pas mal de bugs....et au final le traitement des déchets sera peut être plus long que leurs allocation...

Si je fais ça, OK je garde des Vertex alloués, mais ça change rien dans le fait que de toutes façon il me faudra quand même un sf::VertexArray a allouer...


J'ai une idée en tête:
Je pourrais avoir un tableau qui alloue des Vertex vide la première fois, et les conserve.
Ensuite, je ne met dans mon sf::VertexArray que les Vertex dont j'ai besoin (par pointeurs) provenant du tableau de base.

Au second draw, si le nombre de particules est identique, les Vertex sont ressortit en pointant du tableau de stock.
Si il en manque, le moteur de particules en recréera.
Si il y en a en trop, le moteur de particules ne sortira que ce dont il a besoin.

Je rajouterais donc une fonction pour vider les stock alloué, histoire de faire face au problème du surplus dans le stock (si l'utilisateur alloue beaucoup de particules, puis n'en utilise plus, il peut alors vider le stock pour économiser la ram)

J'essaie ça dès que je peux

[gostron]

Je dirais que tout est dans le tuto sur les vertex ou les vertexArray.

Je crois qu'il suffit de faire un setTexture() sur ton vertex, puis de donner les coordonnées de texture sur chacun  des points.

[Lynix]

J'avoue, 320 c'est rien du tout. Mon PC en supporte bien 15000 - 30000 par seconde en dépassant les 250FPS...

Bon déjà, 320 c'était par frame et pas par seconde...

Dans mon scénario, 60 frames et 320 allocations par frame ça fait 19200 allocations par seconde.

Ce qui entre dans tes nombres (Quant aux 250 FPS, je rappelle qu'il s'agit d'une échelle logarithmique)

Pour reprendre ceci:

Tu sauvegardes ton taff sur disquette ? (ouais ok je troll x) mais faut reconnaître que tes chiffres sont quand même vachement marseillais).

Troller c'est bien mais réfléchir c'est encore mieux.

Surtout que, pour me citer moi-même:

Bon après, le temps d'allocation varie de beaucoup, mais ça fait vraiment partie des opérations lourdes.

[Eroy]

Réfléchir c'est mieux... Ok c'est la meilleur quand même, on parle de particules, d'allocations dynamiques serte, mais sur de petits objets. Là dessus tu balances "une allocation dynamique c'est lourd, on peut en faire que 320 par frame". Sans préciser à quelle taille d'objet tu te réfères on ne part pas du principe que tu te bases sur des gros objets, et même avec tes objets auxquels tu te réfères tu étais quand même 3 fois au dessus. Sinon dans ce cas je vais te dire qu'on ne peut faire qu'une allocation dynamique par frame sans préciser la taille de mon objet et j'aurais forcément raison mais se sera complètement hs... Bref, je pense pas que tu puisses me blâmer pour ce troll.

[Lynix]

Mon premier post contenait "par exemple", mon second "sensibilisation".

Faut arrêter de déconner, j'ai pas dis qu'on ne pouvait en faire qu'un nombre X par seconde, j'ai dis que c'était lourd et j'ai présenté un exemple qui, en comptant 50us par allocation, montrait que tu te retrouvais rapidement limité.

Au passage, j'ai aussi dit dans mon premier post que ça variait beaucoup, et ça varie tellement que j'ai préféré enlever mes chiffres du dernier post.

Edit: Gros objets ? Mes tests se sont basé sur du 64 octets, je doute même que tu puisses en obtenir moins de la part de l'OS.

[germinolegrand]

Bon, je vous suggère d'arrêter là ce troll.
A titre de comparaison, il est plus rapide d'allouer de grandes quantités de mémoire que plein de petites pour une même quantité finale. C'est la raison même d'existence du pooling.
La quantité minimum que peut vous allouer l'OS est d'une page. L'allocation dynamique n'est pas seulement le travail de l'OS, bien plus de votre programme qui va devoir gérer toutes les tailles allouées pour savoir combien il doit libérer.

[Eroy]

J'ai bien compris ce que tu disais hein x). Un troll c'est pas forcément motif à la prise de tête hein, c'était pas une insulte (surtout venant de moi), juste ma façon de dire que je trouvais que ton exemple était un peu trop sensibilisateur et qu'heureusement la marge de manoeuvre est un peu plus importante en réalité. Cela ne change bien sûr en rien le fait de devoir faire attention.
Enfin bref...

[domoi]

Bon, je vous suggère d'arrêter là ce troll.
A titre de comparaison, il est plus rapide d'allouer de grandes quantités de mémoire que plein de petites pour une même quantité finale. C'est la raison même d'existence du pooling.

C'est plus ou moins juste. L'allocation de petits blocs de mémoire peut rompre la consistance de ton cache si ton jeu essaie d'y accéder de manière séquentielle. Je ferme cette parenthèse.
Je me dois de nuancer mon propos précédent, que ce soit un petit jeu en 2d ou un jeu 3d AAA, tu gagneras toujours a utiliser les bonnes méthodes et les bons patterns notamment lorsqu'il s'agit de la gestion de la mémoire. Selon la complexité de ton jeu, ton budget et le temps qu'il t'es accordé, tu pourras toujours complexifier ton implémentation pour répondre aux contraintes imposés.
Si l'auteur du thread a eu les réponses désirées alors on peut clore ce sujet.

[Crone123]

J'ai pas eu le temps de répondre plus tôt ce Week end, ni de tester le système dont j'ai parlé.
Donc je pourrais poster le résultat ici si ça intéresse quelqu'un.

Sinon oui, concernant les tailles et formes de sf::Vertex j'ai eu effectivement des réponses claires je vous en remercie