LZ4 is a very fast compressor, based on well-known LZ77 (Lempel-Ziv) algorithm. Originally a fork from LZP2, it provides better compression ratio for text files and reaches impressive decompression speed, in the range and beyond 1GB/s per core (!), especially for binary files. These speeds are scalable with multi-threading modes, quickly reaching RAM speed limits on multi-core systems.
Hum, pas si sûr que cela soit sans intérêt. La vitesse de décompression est aussi un facteur intéressant (je pense par exemple à des images de jeux d'aventure).
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
La fin de l'intro de R-Type utilise 3 frames de 16K compressées avec appack. La décompression et l'affichage de chaque frame se fait en un dixième de seconde.
Mais si tu fais un jeu d'aventure en ROM avec des animations en plus de 12fps je dis pas non...
C'est un peu réducteur. La compression de frame n'est jamais qu'un exemple de compression possible, et pas nécessairement le meilleur pour comprendre l'intérêt de LZ4.
L'intérêt d'un algo comme LZ4, c'est qu'il est si rapide en décompression qu'on peut l'utiliser sur des ressources qu'on n'aurait jamais envisagées de garder compressées en mémoire auparavant. Il suffit d'aller sur les forum anglophones ou russes pour voir des commentaires du genre "c'est si rapide que c'est compétitif avec memcpy()".
Du coup, on peut à peu prêt tout compresser (les sprites, les background, les maps, etc.) puis décompresser à la volée uniquement ce qui est nécessaire pour fabriquer la frame en cours. 30% par là, 50% par ici, et rapidement, on se retrouve avec 10-15Ko en plus à exploiter sur la machine. Ca peut faire la différence pour afficher plus d'objets et/ou créer des animations plus fluides dans le même budget mémoire.
Cette technique n'est pas limitée aux CPU "vintage", même les consoles modernes l'utilisent : LZ4 est cité sur XboX, sur PSP, et même sur PC (Guild Wars 2). Pourtant, ces machines sont sensiblement plus balaises, elles auraient pu passer direct à la compression LZMA par exemple ? Et bien non, car le temps réel, c'est important. La décompression ultra-rapide, c'est bien ce que ces jeux sont venus chercher.
> Exomizer et appack (que l'on utilise déjà) sont plus performants sur notre CPC.
C'est bien possible, mais n'oubliez pas que pour des ressources "packagées" qu'on ne fait que lire, la comparaison se fait avec LZ4 HC (Haute Compression). C'est une variante qui compresse très sensiblement plus, tout en augmentant encore la vitesse de décompression !
Inscription : 20 Août 2007, 18:21 Message(s) : 5103
J'ai fais un essai avec le compresseur lz4 en ligne de commande , avec le paramètre "-9" (High compression) : j'ai obtenu 13964 octets sur le binaire de boulder dash, pas terrible, c'est loin derrière exomizer
Inscription : 13 Jan 2010, 14:25 Message(s) : 2282
Merci. Parfois, c'est plus le temps d'accès de mise à disposition des données qui importe, même si le taux de compression est moindre. A chaque usage son algo !
On peut gagner quelques octets en extrayant le format "brut" (donc ça vire les entêtes et les checksums), mais bon, pas de quoi s'emballer, ça fera gagner 30 octets tout au plus.
D'après l'auteur, son algo de décompression LZ4 est environ 2x plus rapide que ZX7. Alors OK, c'est plus gros, mais c'est aussi plus "réactif". Au final, ça peut dépendre de l'usage qu'on veut.
Utilisateur(s) parcourant ce forum : Aucun utilisateur inscrit et 32 invité(s)
Vous ne pouvez pas publier de nouveaux sujets dans ce forum Vous ne pouvez pas répondre aux sujets dans ce forum Vous ne pouvez pas éditer vos messages dans ce forum Vous ne pouvez pas supprimer vos messages dans ce forum Vous ne pouvez pas insérer de pièces jointes dans ce forum
Connexion
Inscription
FAQ
