J’en ai déjà parlé, mais je vais détailler tout cela dans un article, le tout dans la langue qui fut molle hier (jeu de mot bidon: fait).
La micro-optimisation, c’est quoi?
Cher poney en diamant qui me lit, la micro-optimisation, c’est une très bonne intention, il s’agit d’optimiser les actions les plus basiques, ou les plus simples, afin de diminuer le temps de calcul dont le jeu a besoin. Mais ce genre de pratique entraîne trois soucis majeurs:
- Lisibilité réduite.
- Gain trop faible (généralement inexistant, voire résultat contraire à l’effet souhaité).
- Perte de temps.
Car en effet, même si la plupart de ses optimisations sont en theorie bonnes, eteindre un incendie de forêt avec des pchit-pchits remplis d’eau reste généralement inefficace, surtout que le nombre de micro-optimisations possibles est généralement bas.
Mais en quoi est-ce une perte de temps? Explique nous.
Je vais te le dire, petit pain au lait, dans l’univers de C2, un tick normal dure 1/60 de seconde (cette valeur pouvant varier selon le matériel utilisé), cela implique que tous les calculs du jeu doivent être faits en 1/60 de seconde, le calcul n’est pas une simple somme des temps cumulés, il y a 4 paramètres que nous pouvons regarder:
- T1, le temps de calcul de la logique du jeu
- T2, le temps de rendu visuel du jeu, influencé par le nombre de pixels a dessiner, ainsi que par les effets et blendmodes
- Tc, le temps de chargement et dechargement des assets dans la mémoire
- Tv, temps pour vider le garbage collector (par à-coups)
Pour se simplifier la vie, on va considérer 3 choses:
- On considere Tc nul, les assets étant déjà chargés
- On considère que le jeu utilise un rendu matériel, si ce n’était pas le cas, le temps résultant serait la somme des temps T1, T2, et Tc, avec T2 bien plus grand.
- On considère que Tv est négligeable, de plus C2 recycle discrètement les objets donc on peut le considerer généralement assez faible.
Au final, le temps pris par le jeu est assimilable au calcul suivant la plupart du temps:
Tjeu ~= clamp(min(T1, T2), 1/60, infinity)
Attention, si vous avez des assets trop gros, ou que le wrapper utilisé ne gère pas les assets d’une bonne façon avec C2 #CocoonJS #les_autres_en_canvas2d, les assets risquent de déborder de la mémoire, ce qui rendra la valeur Tc non négligeable/!\
Au final, si le rendu à l’écran prend trop de temps, la logique n’est généralement pas à optimiser (à moins que votre logique implique un nombre d’objets plus grand à afficher, par exemple).La valeur de cpuutilisation, ou passer par le debugger peut aider à se faire une idée.
Prenons T1 maintenant, on va supposer que il est la somme de la durée de chaque condition et action.
T1 =t1c + t1a +t2c + t2a …
Si T1 devient superieur à 1/60, le jeu ramera, maintenant, quel évenement ou quels évenements peuvent causer cela? La micro optimisation va faire gagner peut-être 1 petit fps , mais si dérriere les autres events prennent trop de temps, cela ne va pas aider…
Que pouvons-nous faire?il est écrit, seul link peut vaincre ganon
Pour te répondre gérard, l’oreiller doué de parole, il y a des moyens d’optimiser son code, sans pour autant être trop dérangé, une sorte de « première couche », qui reste parfois très efficace, voici la liste des choses pouvant être faites:
- Réorganiser les conditions, si une condition est fausse, celles qui suivent dans le même bloc ne sont pas vérifiées, cela ne reduira pas le temps de calcul lorsque toutes sont vraies, mais ça aide lorsque certaines sont fausse, afin de ne pas faire de calculs inutiles.
- Essayer d’utiliser les outils les plus adaptés, dans certains cas par exemple, une boucle vous fera gagner du temps de calcul car c’est le choix le plus judicieux.
- Eclaircir son code, cela aide non seulement à developper, mais aussi a traquer certains problèmes de performances localisés.
- Les groupes, ça peut se desactiver et se reactiver, ce qui permet de se passer de calculs inutiles assez facilement et rapidement.
- Les fonctions, ça permet de réutiliser, de corriger, d’éclaircir son code, et qui sait, optimiser une fonction utilisée dans de nombreux endroit pourrait éventuellement aider.
- Les includes, on peut les mettre sous des conditions, et cela permet d’organiser son code
- Les collisions, sont-elles toutes utiles? On peut voir a diminuer ça, a les faire moins souvent, ou sur moins d’objets
- Les morceaux de code répétés, à eviter, généralement, vérifier une condition une seule fois est suffisant dans tout le code, pourquoi la vérifier plusieurs fois si ce n’est pas justifié.
- Tester assez souvent, sur l’appareil visé, avec le wrapper visé (ou dans le navigateur selon le cas), autant ne pas agir quand il est deja trop tard.
- Lisez votre event sheet, vous-même, et voyez si il n’y a pas de choses répétées sans raisons, ou dures à comprendre.
Et un dernier conseil, codez proprement, optimiser un code dans lequel vous ne pouvez pas vous y retrouver, c’est une mauvaise chose, faites d’abord un code fonctionnel, puis rendez le propre, généralement ça permet d’enlever pas mal d’erreurs et de perte de temps, puisque vous savez ce que fait votre code, et vous pouvez agir en conséquence.
Pourquoi un poney en diamant, un pain au lait et un oreiller?
Parce que je suis fou Mouhahahahahaha *nuage de fumée*
Commentaires appréciés.