FR EN DE ES IT PT
Naviguer dans les forums 
Trackers Ankama

Optimisations et allègement des images de Dofus

Par LingCo - ABONNÉ - 02 Juin 2020 - 20:11:09
Bonjour,

Plutôt que de pester sur les problèmes d'optimisation du jeu Dofus, j'aimerais plutôt proposer une amélioration pour le jeu, amélioration dont l'impact sera sans doute minime sur les performances, mais qui pourra peut-être faire gagner quelques millisecondes de chargement... ou qui permettra à minima au jeu d'être un peu plus léger sur un Disque Dur (et moins gros à télécharger).

De nature curieuse et étant "joueur" avec les images, j'ai effectué quelques tests sur quelques images de Dofus pour m'amuser. Il existe beaucoup d'outils d'optimisation des images gratuits, et par optimisation, j'entends "optimisation sans perte de données / qualité" (lossless). Je connais plusieurs outils en fonction du format des images, que ce soit .png, .jpg, .svg ou .webp (même si je n'ai vu aucune image de ce format dans les dossiers d'installation).

Je vais déjà montrer ce que ça pourrait donner sur une image, celle présente dans le dossier Ankama\zaap\dofus\content\gfx\challenges et qui s'appelle 1.png.
Cette image est au format PNG, elle fait 12,5 Ko (12 839 octets) de base.

Je vais la faire passer dans deux outils qui permettent l'optimisation sans perte de données / qualité pour ce format PNG.Premier outil : pingo.exe (disponible sur https://css-ig.net/pingo), que je vais utiliser avec les options les plus agressives -sb (on cherche la meilleure optimisation, celle qui prendra le plus de temps à calculer) et -strip (pour retirer les metadata) :

C:\Users\utilisateur\Desktop>pingo.exe -sb -strip 1pingo.png  
pingo - (0.02s):
  
-----------------------------------------------------------------
  
1 file => 10.78 KB - (85.97%) saved
  
-----------------------------------------------------------------


Image résultante :

Deux informations :
- l'optimisation de l'image a duré 0.02 secondes
- on a gagné 10,78 Ko sur les 12,5 Ko que faisait le fichier au départ => nouveau fichier à 1,75 Ko (1 801 octets)


On peut enchainer sur un deuxième outil d'optimisation plus poussé : ect.exe (Efficient-Compression-Tool, disponible sur https://github.com/fhanau/Efficient-Compression-Tool/releases), que je vais utiliser avec les options les plus aggressives -9 --allfilters sur l'image déjà optimisée par le premier outil :
 
C:\Users\utilisateur\Desktop>ect.exe -9 --allfilters 1pingoect.png
Processed 1 file
Saved 39B out of 1.76KB (2.1655%)

Image résultante :

Deux informations :
- la durée a été assez courte, même si elle n'est pas notée explicitement
- on a encore gagné 39 octets sur les 1.76 Ko que pesait le nouveau fichier déjà optimisé => nouveau fichier à 1,72 Ko (1 762 octets)


Maintenant, il faut vérifier que l'image générée est bien parfaitement identique à l'image de base. Pour cela, soit on compare en utilisant l'outil compare.exe de ImageMagick (disponible sur https://imagemagick.org/index.php), soit on code son propre petit programme pour tester l'égalité des pixels 1 à 1. J'ai personnellement testé les deux solutions pour être sûr :

C:\Users\utilisateur\Desktop>compare.exe -metric AE 1.png 1pingoect.png difference.png
0

Résultat : il y a 0 pixels de différence entre l'image de base 12,5 Ko (12 839 octets) et l'image générée 1,72 Ko (1 762 octets), soit un gain de 10,78 Ko (soit une perte de poids égale à 86,24%) instantanément sans perte de qualité aucune. Alors effectivement, j'ai pris un exemple qui fonctionne très bien... pour certaines images, le gain sera bien évidemment beaucoup moins impressionnant... mais je propose de tester ça sur un ensemble d'images, comme celles contenues dans le fichier worldmap0_2.d2p (1 381 Fichiers, soit 29,1 Mo (30 603 580 octets)). Je décompresse tout dans un dossier nommé "maps".

Repassons tous ces fichiers avec le premier outil pingo.exe avec les options les plus agressives -sb (on cherche la meilleure optimisation, celle qui prendra le plus de temps à calculer) et -strip (pour retirer les metadata) :

C:\Users\utilisateur\Desktop>pingo.exe -sb -strip ./maps
pingo - (6.70s):  
-----------------------------------------------------------------
  
1381 files => 11674.64 KB - (39.06%) saved
  
-----------------------------------------------------------------


Pour 1381 fichiers, le traitement d'optimisation aura duré 6.70 secondes.On aura réussi à compresser les images sans perte de données / qualité et désormais, la taille de ces fichiers est de 17,7 Mo (18 648 747 octets). Les images étant cette fois en .jpg contrairement au premier exemple, je ne passe pas le programme ect.exe (Efficient-Compression-Tool) parce qu'il se spécialise plutôt dans les .png et ne saura pas compresser davantage. Dernière étape, on vérifie que les images sont toujours identiques et pour cela, on va prendre au hasard l'image 52.jpg (53,5 Ko (54 830 octets) avant et 37,5 Ko (38 458 octets) après) :

Image de base :


Image résultante :

C:\Users\utilisateur\Desktop>compare.exe -metric AE 52.jpg 52pingo.jpg diff.png
0

Là encore, les pixels sont strictements égaux sur les deux images, il n'y a aucune perte de qualité, alors que la seconde image a été allégée de 30% environ. C'est donc un gain de place qui permet : un téléchargement de l'application et des mises à jour plus rapide, et éventuellement, quelques millisecondes de moins de chargement pour chaque image... ce qui reste une petite amélioration, non négligeable dans le monde informatique (quand on passe des soirées à gagner quelques secondes sur un traitement, ça ne compte pas, c'est que du bonheur).

Sachant que le jeu est composé d'images, je pense que le gain peut être non négligeable. Entre un PNG qui serait 80% plus léger, des JPG qui seraient 40% plus légers, il doit être possible d'alléger les fichiers du jeu d'environ 10 à 15%, si on prend ces résultats avec des pincettes et en imaginant qu'on a eu beaucoup de chance. N'est-ce pas bon à prendre ?

Il existe aussi des outils qui permettent d'optimiser les fichiers au format SVG, mais la vérification pixel par pixel est plus difficile à gérer... je préfère ne rien proposer à ce propos. Si vous retenez les idées précédentes, sachez tout de même que les auteurs des programmes pingo.exe et ect.exe préviennent qu'il faut toujours faire des sauvegardes des fichiers originaux, au cas où des erreurs venaient à altérer les données des images. Si vous trouvez des images qui entrent dans ce cas, n'hésitez pas à contacter les personnes qui gèrent ces projets pour les aider à les améliorer : tout le monde sera gagnant !

En espérant avoir pu vous apporter quelque chose,
Bien cordialement

PS : les images postées sur ce sujet sont celles qui ont été utilisées pour les tests. Elles ont les mêmes noms et mêmes propriétés (poids) que j'ai décrites. Elles ne m'appartiennent évidemment pas, je les supprime quand vous le voudrez.
4 0
Réactions 3
Score : 10605

Bonjour,

Déjà je salue la méthode et l'implication, c'est une proposition bien argumentée.
Mais je vais être un peu plus critique sur le fond :

Une image compressée doit être décompressée pour être utilisable. Et pour faire ça, il faut de la puissance de calcul. Malheureusement Dofus est déjà très gourmand sur ce point, et en rajouter une couche ne serait pas forcément pertinent.
Les images décompressées sont ensuite stockées dans la ram, pour être utilisées rapidement. Donc que la compression soit bonne ou pas, l'utilisation de ram sera strictement la même.
Au final, l'intérêt de ta proposition se limite à réduire la taille du téléchargement et de l'installation du jeu, contre une perte de performances. Pour un jeu qui pèse 80Go je ne dis pas, mais pour Dofus... Je doute sincèrement de la pertinence de la compression.

A titre personnel, je serais plus pour la solution inverse (si elle n'est pas déjà en place ?) : décompresser tous les fichiers pour diminuer la charge de calcul ridiculement élevée de Dofus, quitte à faire grimper la taille du jeu. D'autres jeux ont déjà fait ce choix, notamment sur console, pour diminuer les calculs de décompressions et augmenter les FPS.

5 0
Score : 215
Bonjour, 

Bonnes remarques, j'ai voulu faire les tests pour vérifier tout ça. Pour moi, un accès disque dur sera toujours plus long que tout (même sur un SSD) et c'est le seul aspect que j'avais retenu… donc je viens de me créer un petit programme Java qui charge 1000 fois une image et j'ai comparé l'ouverture de l'image de base et l'ouverture de l'image après compression.

Pour le fichier .png, j'ai comparé l'ouverture 1.png et 1pingoect.png : 

Elapsed time 1.png : 314
Elapsed time 1pingoect.png : 242
Elapsed time 1.png : 303
Elapsed time 1pingoect.png : 232


Le Java étant ce qu'il est (difficile de tester les performances, ce qui est fait en second étant toujours plus rapide que ce qui est fait en premier), j'ai codé 4 boucles de lectures, deux fois sur le fichier de base et deux fois sur le fichier compressé. Pour ce cas, le résultat montre que non seulement, le .png compressé est plus léger, mais aussi plus rapide à ouvrir (environ 25% plus rapide).

Pour le fichier .jpg, j'ai comparé l'ouverture 52.jpg et 52pingo.jpg : 

Elapsed time 52.jpg : 1769
Elapsed time 52pingo.jpg : 13272
Elapsed time 52.jpg : 1816
Elapsed time 52pingo.jpg : 13430 


Alors là, par contre, résultat sans appel : il ne faut effectivement pas compresser les .jpg, sans quoi on multiplie par 10 les temps de chargement… ce n'est pas vraiment souhaitable, j'ai proposé une mauvaise solution… 

Après prise de renseignement, ça vient du fait que la compression en jpg progressive est plus longue à décompresser qu'une compression en sequential. En utilisant ect.exe, sans utiliser l'option -progressive, on restera en sequential. Je teste donc de compresser 52.jpg de base : 

C:\Users\toryu\Desktop>ect.exe 52ect.jpg
Processed 1 file
Saved 13.71KB out of 53.54KB (25.6009%) 


On gagne 25% de place.

Je compare pour vérifier qu'aucun pixel n'a été modifié :

C:\Users\toryu\Desktop>compare.exe -metric AE 52.jpg 52ect.jpg diff.png
0

Et avec mon programme Java, je compare l'ouverture 52.jpg et 52ect.jpg : 

Elapsed time 52.jpg : 1864
Elapsed time 52ect.jpg : 1839
Elapsed time 52.jpg : 1881
Elapsed time 52ect.jpg : 1829


On gagne quelques millisecondes sur 1000 ouvertures d'image, et on gagne environ 25% sur le poids de l'image. En définitive, c'est un peu moins bien que l'utilisation de pingo.exe (qui compresse en progressive, rends moins lourd mais plus long à décompresser), mais ça reste un petit gain je pense. 

Donc pour résumer, on pourrait utiliser pingo.exe -sb -strip 1.png puis ect.exe -9 --allfilters 1.png pour optimiser les png sans perte de temps sur la décompression (petit gain d'ailleurs), et ect.exe 1.jpg pour optimiser les jpg tout en restant en compression sequential, là encore sans perte de temps sur la décompression (petit gain, peut-être négligeable il est vrai). Il faudrait voir s'il existe encore meilleure solution, je continue de m'amuser en cherchant un peu !
 
2 0
Score : 215

Juste pour le délire, j'ai testé avec tous les formats d'images, pour voir jusqu'où on pourrait aller dans l'optimisation de l'affichage de celles-ci dans le jeu. Deux ont retenus mon attention : bmp compressé et bmp non compressé.

On prend la même image au format .jpg (53,5 Ko (54 830 octets)), .bmp compressé (183 Ko (188 054 octets), soit une taille x3.5) et .bmp non compressé (244 Ko (250 138 octets), soit une taille x4.5) :


Les trois images sont parfaitement identiques, tous les pixels sont égaux.
Après le test d'ouverture de 1000 images déjà utilisé dans mes posts précédents, voici les résultats de l'ouverture de 1000 JPG, 1000 BMP compressés et 1000 BMP non compressés :

Elapsed time 52.jpg : 1864
Elapsed time 52_compressed.bmp : 1243
Elapsed time 52_notcompressed.bmp : 956
Elapsed time 52.jpg : 1881
Elapsed time 52_compressed.bmp : 1231
Elapsed time 52_notcompressed.bmp : 969


Le bmp non compressé s'ouvre donc 2 fois plus rapidement que les jpg utilisés dans le jeu. En revanche, il est tout de même 4.5 fois plus volumineux... et encore, l'image testée est assez petite, j'imagine ce que ça pourrait donner sur les plus grands jpg comme les maps... (spoiler : quelque chose d'infernal).

Pour des éléments comme la map dézoomée, composée de plein de petites vignettes, ce serait sans doute utile : elle prendrait un peu plus de place sur le Disque dur, mais pourrait s'ouvrir deux fois plus rapidement. Pour le reste, ça prendrait tellement plus de place sur le Disque que je n'oserais pas me prononcer sur la question.

Pour toutes les autres images, il reste la petite amélioration déjà décrite dans le premier post, qui permet d'optimiser la place prise par les images sur le Disque dur et d'accélérer légèrement leur chargement en mémoire. Ca resterait une petite amélioration bienvenue et plutôt simple à mettre en place (si on voit la durée des conversions décrites dans mon premier message) !
0 0
Réagir à ce sujet