Le 17 janvier 2019 à 15:49:18 TossTheFeathers a écrit :
Petit panda roux, toi qui voulais tester, j'ai compilé une pièce en fichier .exe pour que tu puisses voir ce que ça donne.

https://www.mediafire.com/file/dik2o7oonnqfqox/test1.7z/file

Evidemment tout le monde peut donner son avis.

merci

Ça confirme ce que je pensais du coup, c'est sympa pour une session courte mais sur la longueur ça va vraiment donner envie de vomir
Faire un niveau ou une altération d'état genre empoisonné/drogué avec ça ça peut être cool mais un jeu entier s'il dure plus de 15 minutes ça va me donner mal à la tête perso Après peut-être que mon impression a été accentuée parce que t'as mis une lampe qui clignote, et je trouve qu'elle clignotait assez violemment, je sais pas si l'effet est accentué à cause du shader ou pas

Le 17 janvier 2019 à 18:27:41 lokilok a écrit :

[22:32:01] <Arkwolf>
je me souviens que j'avais bien galéré à atteindre de bonnes performances en mobile sur le premier starrows quand il y avait plein d'unités (et ça m'avait tellement appris sur la programmation et comment ça marche derrière )

T'as 2-3 trucs à dire là dessus qui seraient valables de manière générale ?

Les trucs classiques qui me viennent en tête, beaucoup sont peut-être évident mais moi je savais pas, ou je pensais pas que c'était si important

- éviter de créer des objets dans le update, et si on a besoin d'en créer (genre des projectiles), il faut faire du spooling (en gros ne pas détruire les projectile créés, mais les garder dans la mémoire dans une liste par exemple et quand tu veux créer un projectile, regarder s'il y en a un de libre dans le tableau pour le réutiliser le réinitialiser celui-là), la création d'un nouvel objet ça coûte cher.
Dans Starrows j'ai utilisé ça pour les flèches et projectiles magique des troupes. et comme c'est fait avec un langage qui a un garbage collector que tu peux pas trop controller, ça permet d'éviter le suttering vu que ça , ça joue beaucoup sur les smartphones, ça a aidé
J'ai aussi fait un truc du genre pour certains petits objets spécifiques que je réutilise tout le temps comme les Vecteurs. Mais c'est spécifique à Java pour ces derniers pour le coup, si tu fais ça en c# avec les structs y'a pas besoin.

- les collisions le point le plus difficile et qui demande le plus de perf
Au début je pensais que c'était pas si grave de vérifier sur toute la map si les objets entraient en collision avec le décor, donc j'avais une liste de rectangle en gros, et quand une unité bougeait je regardais si elle allait toucher un rectangle. Je savais bien sûr que c'était pas le mieux mais je pensais que vu qu'on a des PC et smartphones puissant ça serait pas si grave, que nos processeurs peuvent calculer ça rapidement. Méga erreur, surtout dans un jeu où y'a plein d'unités
Du coup, vu que ma map utilise des tile, j'ai tout mis dans un tableau 2D (avec j'avais mis ça dans une liste parce que c'est facile y'a pas besoin de se prendre la tête ), et l'avantage avec un tableau 2D c'est que sans coût je peux regarder les collisions sur les 8 cases autour d'un personnage (je prend les coordonnés du perso et je divise par la taille des tiles pour récupérer l'index du tableau) du coup ça m'a fait gagner énormément d'appels.
Dans le cas de Starrows pour les bâtiments qui prennent + qu'un tile, j'ai fait un autre système, je vérifie en amont si l'unité est dans sa base (et pour ce faire, dans chaque tile j'ai rajouté un attribut qui dit à quelle base elle appartient. Comme ça vu que je regarde forcément le tile pour les collisions j'ai même pas besoin d'itérer sur des rectangles qui représentent la zone de la base), et s'il est dans sa base je rajoute les structures de la base dans les collisions à vérifier.
Souvent, je vérifie même plus du tout les collisions parce que ça bouffe tellement des ressources donc j'ai fait des astuces du genre : si c'est un perso de l'ia qui suit son chemin sans être dérangé, je vérifie plus vu que son chemin est fait à l'avance pour pas toucher le décor. S'il se fait attaquer par une unité qui suit un chemin pas conventionnel (le joueur, ou un héro dirigé par l'ia qui a un vrai algo de pathfinding) et qu'il souhaite le poursuivre pour riposter, alors là j'active les collisions. Pareil pour les cas simple genre une unité qui bouge pas etc.

- Pareil pour les vérifications diverses d'unités les plus proches. Au début, quand une unité a une aptitude pour tirer plusieurs flèches sur les ennemis à sa portée par exemple, bah je parcourais toutes les unités et je gardais que celle à portée. Mais quand tu as genre 1000 unités, ça fait 1000 vérifs pour 1 tir, du coup ça fait des saccades énormes, et je te dis pas quand ces 1000 unités ont une aptitude du genre, c'est la cata vu qu'ils tirent tout le temps
Là j'ai testé plusieurs solutions pour trouver les objets les plus proches sans les parcourir : quadtree / octree / kdtree... mais au final ces méthodes m'ont soulé parce que pas fun à faire pour moi donc j'ai fait un truc dans le genre, mais à ma sauce, en moins bien mais ça a bien tout amélioré de parcourir moins le tableau

- dans le même genre, les opérations qui peuvent être un peu lourdes mais qu'on est obligé d'appeler dans la boucle principale. Par exemple, le pathfinding de l'IA : ici les héros ennemis utilisent el famouso a* mais ça prend quelques ms et ça se ressentait sur la fluidité, donc j'ai mis ça dans des threads à par vu que j'ai pas besoin du résultat instantanément. Par contre un truc que j'ai toujours pas compris c'est qu'en desktop ça fait grave ramer de spawner des thread en java mais en mobile c'est différent, donc sur la version desktop je laisse dans boucle principale vu que c'est hyper rapide de toute façon et en mobile, hop un thread

- après le coup classique d'utiliser des batch. Tous les bâtiments sont dans une même image, toutes les unités sont dans une même image, comme ça je peux dessiner tous les bâtiments d'un coup sans avoir à changer de texture, pareil pour les unités, pareil pour le décor etc pour que ça fasse le moins d'appel possible. Les cartes graphiques sont hyper fortes pour prendre une texture et en dessiner des "bouts" par ci par là, par contre si tu dois envoyer une image seule (genre un bâtiment seul) et qu'après elle doit dessiner un autre bâtiment et que tu lui envoi une autre image ça fait utiliser des ressources pour rien sur mobile

- je dessine rien du tout qui sort de la caméra

C'est tout ce qui me passe par la tête là, mais j'aime bien ce sujet, c'est hyper gratifiant quand ton jeu tourne mieux même sur des telephones plus vieux mais après vu que ça tournait mieux j'ai fait des maps plus grande et rajouté + d'unités (ça produit plus vite) et du coup faut que je retrouve des optimisations à faire pour les vieux téléphones mais flemme

ça m'a vraiment fait prendre conscience du poids de chaque ligne que j'écris, je suis moins bourrin maintenant j'avais confiance en la puissance démesurée de nos processeurs / cartes graphique mais en mobile ça se passe pas aussi facilement.

là sur unity je sais pas encore trop comment tout ça est géré, mais j'espère que plein de trucs sont automatisés

(houla je me suis emballé j'ai écrit pendant 30 min un pavé plein de banalités )

Mince, je trouvais ça sympa moi. T'as jamais joué à des jeux PS1 ?
Du coup je sais pas vraiment quoi faire, d'après l'auteur du shader je peux pas l'atténuer mais je peux le désactiver complètement par contre.

En tout cas il faut que je garde le style pixelisé, c'est très important.

Arkwolf, je trouve ça intéressant quand même, je savais pas que créer des nouveaux objets pour les projectiles pouvait autant impacter les perfs.

Pour les threads en desktop qui sont lents c'est peut-être parce que tu créais un nouveau thread a chaque fois plutôt que de réutiliser des threads déjà créés peut-être ? Et sous windows je crois que la création de thread tout ça c'est moins opti que sous linux.

Le 19 janvier 2019 à 05:27:07 TossTheFeathers a écrit :
Mince, je trouvais ça sympa moi. T'as jamais joué à des jeux PS1 ?
Du coup je sais pas vraiment quoi faire, d'après l'auteur du shader je peux pas l'atténuer mais je peux le désactiver complètement par contre.

En tout cas il faut que je garde le style pixelisé, c'est très important.

Si j'ai joué énormément à la PS1, mais ça me paraissait moins violent. Pour moi ce qui caractérisait plus la ps1 c'était + les polygones très brute / triangulaire que la pixelisation
mais après c'est juste mon avis, je suis sûr que tu peux quand même arriver à faire un truc cool avec ça

Le 19 janvier 2019 à 11:22:19 lokilok a écrit :
Arkwolf, je trouve ça intéressant quand même, je savais pas que créer des nouveaux objets pour les projectiles pouvait autant impacter les perfs.

Pour les threads en desktop qui sont lents c'est peut-être parce que tu créais un nouveau thread a chaque fois plutôt que de réutiliser des threads déjà créés peut-être ? Et sous windows je crois que la création de thread tout ça c'est moins opti que sous linux.

Pour les threads ouais ça doit être ça, en fait j'aurais dû en garder un seul pour le pathfinding par exemple, c'est évident maintenant que tu le dis Comme j'ai rarement l'occasion d'en utiliser "à la main" pour les jeux j'ai fait n'importe quoi en fait Et 3 paragraphes plus haut je disais qu'il fallait éviter de faire des new, sans commentaire

(houla je me suis emballé j'ai écrit pendant 30 min un pavé plein de banalités )

Nonnon c'est intéressant de parfois lire deux/trois tricks assez classiques d'optimisation. Je savais pas que ça s'appelait du "spooling" de faire ça, je ne le fais pas d'usage mais je devrai probablement. Ca me rappelle un post sur twitter d'un gars qui disait qu'on devait penser notre code en terme de matrices, on alloue tout d'un coup et on travaille de façon fixe dessus. C'est typiquement ce qu'on fait dans des logiciels style tensorflow vu qu'en IA on veut vraiment maximiser les perfs, mais pour les jeux vidéo j'ai jamais eu le reflexe. En même temps c'est pas intuitif d'avoir des instances fantômes qu'on va genre réincarner quand on en aura rebesoin, et dès qu'elles meurent on garde leur cadavre dans la RAM

en fait j'aurais dû en garder un seul pour le pathfinding par exemple, c'est évident maintenant que tu le dis

C'est horrible de savoir qu'on a un mauvais design dans un code hein ? Tu vas arriver à dormir ? Va corriger vite ou ça te hantera toute la nuit

Alors du coup, je m'adresse aux gens qui ont essayé ma démo (si on peut appeler ça comme ça), l'affine texture mapping c'est pas agréable, c'est ça ? (j'ai du mal à trancher, en toute honnêteté)

Bah ouais ya un côté psychédélique qui passe pour un niveau/statut spécial mais pas pour tout un jeu

Mais au temps de la PS1 ça gênait personne, en tout cas personne pensait ça. Je trouve ça bizarre.

Je pense que c'est pou ca que plein de jeu PS1 n'etait pas a camera libre.
Repense a Resident Evil ou a FF7. Les cameras etaient fixes. Je pense que c'etait pour pouvoir pre-rendre les scenes et eviter ces algos de texturing qui etait un peu pourri.

C'est horrible de savoir qu'on a un mauvais design dans un code hein ? Tu vas arriver à dormir ? Va corriger vite ou ça te hantera toute la nuit

grave, c'est une sensation horrible mais bon vu que ça fait des années que ça tourne comme ça et j'en ai marre de le mettre à jour (la première version date d'il y a 6 ans que ça passe vite ) donc ça ira quand même, je vais laisser ça comme ça

Le 19 janvier 2019 à 19:32:03 TossTheFeathers a écrit :
Mais au temps de la PS1 ça gênait personne, en tout cas personne pensait ça. Je trouve ça bizarre.

Et dans mes souvenirs les jeux qui utilisaient de la full 3D comme medal of honor mettaient un brouillard énorme ou se passaient dans la nuit, on bougeait pas trop vite et l'effet était pas si prononcé que ça, là on voit que de la "pixelisation uniforme", c'est pas exactement le même effet je trouve
Et les jeux 3D les plus beaux comme Metal Gear Solid étaient pas vraiment pixelisés, c'était "carré", les bords étaient rugueux, mais pas pixelisés. MGS1 j'y rejoue sans problème même aujourd'hui
Et même sur les jeux plus anciens que la ps1 hyper pixelisé, genre le premier wolfenstein, ils mettaient pas trop de textures partout pour que ce soit pas trop chargé du coup

medal of honor mettaient un brouillard énorme ou se passaient dans la nuit

On s'en rappelle du famoso brouillard breton qui a sauvé pas mal de jeux vidéo de l'époque hein
"Le débarquement en Normandie!"
"Mais on voit rien"
"Tais toi c'est la pluie"

Le 20 janvier 2019 à 06:46:28 TossTheFeathers a écrit :
Je comprends pas

j'ai enlevé le warping, c'est mieux là ?

ça a l'air oui

unordered_map<string, any> __dict__;

Le 20 janvier 2019 à 20:27:27 blackapplex a écrit :
unordered_map<string, any> __dict__;

edit: Ah, mon compilateur crie à l'agonie, c'était ptet une mauvaise idée

C'est du C++ ? C'est quoi le "any" ?

probablement un type variant maison

Le 21 janvier 2019 à 15:54:59 godrik a écrit :
probablement un type variant maison

maison c++17 ( https://en.cppreference.com/w/cpp/utility/any , moi non plus je savais pas que ça existait avant de l'utiliser)
Du coup ça permet de faire certains trucs aussi salement qu'en Python. Après la mentalité C++ du "JE VEUX CONNAITRE LE TYPE A LA COMPILATION" te rattrape toujours

probablement un type variant maison

maison c++17 ( https://en.cppreference.com/w/cpp/utility/any , moi non plus je savais pas que ça existait avant de l'utiliser)

Ah, je n'avais pas vu qu'il avait foutu un type varaiatn dans C++ 17.

Du coup ça permet de faire certains trucs aussi salement qu'en Python. Après la mentalité C++ du "JE VEUX CONNAITRE LE TYPE A LA COMPILATION" te rattrape toujours

En meme temps, la presence de typing fort et toujours non ambigu est l'une des raison qui faiat que C++ a de meilleur perf que la plupart des languages de script.

Le 21 janvier 2019 à 23:33:15 godrik a écrit :

probablement un type variant maison

maison c++17 ( https://en.cppreference.com/w/cpp/utility/any , moi non plus je savais pas que ça existait avant de l'utiliser)

Ah, je n'avais pas vu qu'il avait foutu un type varaiatn dans C++ 17.

Du coup ça permet de faire certains trucs aussi salement qu'en Python. Après la mentalité C++ du "JE VEUX CONNAITRE LE TYPE A LA COMPILATION" te rattrape toujours

En meme temps, la presence de typing fort et toujours non ambigu est l'une des raison qui faiat que C++ a de meilleur perf que la plupart des languages de script.

Bah ouais je sais bien, faudrait un entre-deux, ou un compilateur qui devine un peu mieux ce qu'on veut faire
Et en fait il y a un std::variant qui représente un union https://en.cppreference.com/w/cpp/utility/variant , mais je crois que le any gère mieux la mémoire (sauf erreur les unions vont créer des places mémoires pour tous les types possibles ce qui est un peu sale je trouve)

Dans mes souvenirs la taille d'un union c'est juste la taille du plus grand de ses sous-type, et tout est stocké au même endroit c'est juste réinterprété selon le type auquel tu veux accéder, après je suis pas sur.