J'utilise .png
s pour mes textures et j'utilise un système de fichiers virtuel dans un .zip
fichier pour mon projet de jeu. Cela signifie que mes textures sont compressées et décompressées deux fois. Quelles sont les solutions à ce problème de double compression? Une solution dont j'ai entendu parler est d'utiliser .tga
s pour les textures, mais cela semble il y a longtemps, depuis que j'ai entendu cela. Une autre solution consiste à implémenter la décompression sur le GPU
et, puisque c'est rapide, à oublier la surcharge.
textures
assets
compression
user1095108
la source
la source
Réponses:
Le format zip prend en charge plusieurs algorithmes de compression différents. Vous pouvez utiliser un algorithme différent pour chaque fichier de l'archive. Lorsque vous souhaitez stocker des fichiers déjà compressés qui ne bénéficient pas d'une compression supplémentaire (comme PNG) dans une archive zip, vous pouvez encoder ces fichiers avec l'algorithme "stocké" qui ne se comprime pas du tout. La boîte de dialogue "Ajouter aux archives" de 7-zip vous permet de choisir ceci sous "Force de compression".
Mais lorsque vous avez non seulement des images mais également d'autres ressources plus compressibles dans vos archives, il peut être assez fastidieux de choisir l'algorithme pour chaque fichier. Dans ce cas, vous pouvez plutôt opter pour un format d'image non compressé dans une archive compressée.
Le format TGA connaît de nombreux modes différents, dont certains sont compressés et d'autres non. Lorsque vous ne souhaitez pas utiliser la compression, assurez-vous de choisir la bonne dans les options d'exportation de l'éditeur graphique que vous utilisez. Un autre format d'image non compressé est BMP (Windows Bitmap).
Voici un test que j'ai fait. J'ai ajouté plusieurs fois la même image (un atout de mon projet actuel) dans différents formats à une archive zip, certaines avec l'algorithme "dégonfler" à force normale et une avec "stocker". Désolé pour l'interface graphique allemande. La 2e colonne est de taille non compressée, la 3e colonne est un algorithme de compression et la 4e colonne est de taille compressée.
Comme vous pouvez le voir, l'encodage dégonflé du PNG n'a enregistré qu'une maigre 0,3%, tandis que le BMP encodé dégonflé est réduit à un dixième du fichier d'origine, ce qui est encore plus petit que la version PNG. Cela m'a vraiment surpris. Je m'attendais à ce que le PNG soit plus petit car la méthode de compression du PNG devrait être optimisée pour les données d'image alors que le ZIP ne l'est pas. Une explication probable est que mon éditeur d'images (GIMP) a ajouté beaucoup de méta-informations aux fichiers PNG, ce qu'il ne fait pas pour BMP.
TGA non compressé se comportait de manière similaire à BMP en ce qui concerne la taille des fichiers avant et après la fermeture éclair tandis que la compression du fichier TGA compressé était encore améliorée par ZIP, mais pas autant que les versions non compressées.
Il pourrait être utile d'expérimenter avec d'autres algorithmes que le dégonflage et avec d'autres paramètres de résistance à la compression. La combinaison qui donnera les meilleurs résultats dépendra probablement du style de vos textures. Mais vous pouvez également envisager de comparer le chargement des ressources de votre jeu et faire en sorte que les performances de décompression influencent votre décision concernant le paramètre que vous utilisez.
Conclusion: lorsque vous souhaitez éviter la double compression tout en ayant une taille de fichier faible, utilisez-la
PNG
avec unStore
algorithme zip ouBMP
avec un algorithme de compression zip.la source
Ne t'en fais pas.
Lorsque l'algorithme de «dégonflage» utilisé dans les fichiers .zip rencontre un bloc de données déjà bien compressé, comme les données de pixels d'une image .png, il constate qu'il ne peut pas le compresser efficacement, et il le stockera comme littéral données non compressées. Cela prend très peu de temps à la fin de la décompression pour copier.
http://en.wikipedia.org/wiki/DEFLATE
la source
store
au lieu dedeflate
gagner du temps, puisdeflate
tout pour les versions.On dirait que de très bonnes réponses ont déjà été données, mais j'ai pensé en donner une de plus:
Solution: ne faites rien.
Justification: Aucun problème n'a été signalé - oui, vous compressez les informations deux fois, mais pourquoi vous en inquiétez-vous? La taille des données est-elle trop grande? La décompression est-elle trop lente? Est-ce plus ou moins important que les dizaines de fonctionnalités que vous pourriez ajouter, affiner, tester et / ou déboguer en ce moment?
la source
Si vous utilisez des formats spécialisés tels que PNG et OGG, vous n'aurez pas besoin de la compression de ZIP.
PNG, OGG et autres formats déjà compressés ne seront pas beaucoup plus petits en les compressant à nouveau au format ZIP. 100 Mo de PNG compressés sont toujours ~ 100 Mo.
Les scripts, les fichiers de configuration et d'autres formats basés sur du texte bénéficient grandement de la compression, cependant, ils sont généralement minuscules en comparaison, ils ne stockent pas autant de données. Si votre jeu est de 100 Mo, alors les fichiers texte peuvent faire 1 Mo de l'ensemble du jeu, même si vous pouvez les faire 100 Ko par compression, vous n'avez gagné que 900 Ko, moins de 1%, cela ne vaut vraiment pas la peine.
Vous pourriez même vouloir utiliser le système de fichiers directement au lieu d'utiliser un système de fichiers virtuel basé sur zip. Cela rendrait les correctifs très faciles: vous pouvez simplement échanger tous les fichiers que vous avez modifiés.
la source
.zip
ou non un fichier. Par exemple, sur la plateforme Android, le.apk
est un.zip
fichier, qui peut contenir des ressources.