Gain de place - Page 1

Mon nouveau projet va prendre BEAUCOUP de graphiques. Je voulais savoir si il était possible de compresser avant les sprites, qui ne sont en fait que des 0 et des 1

des sprites du style:
dc.b %00000000,%00000000,%00000000...,%00000000
ou
dc.b %11111111,%11111111,...,%11111111
Tu peux tjrs les recréer en RAM avec des handles
mais il est possible de les compresser, et compresser tout type de sprites avant m'interesse.

Fo utiliser shrnklib pour compresser des graphismes

>Asterix: Fo utiliser shrnklib pour compresser des graphismes

Non.
On peut aussi utiliser ttpack.
Si ton programme est en un fichier et en _nostub, il suffit d'utiliser l'ExePack automatique de TIGCC (facile à utiliser même pour l'assembleur, cf. mon tutorial).
Sinon, il te faudra utiliser les routines de ttunpack.h ( c'est du C).
[edit]Edité par Kevin Kofler le 09-09-2001 à 22:20:53[/edit]

Ouai, cela va de soi, je parlais en mode kernel

t'as pas la même chose en nostub & ASM?

Tu attend que je finalise l'AMC2 (les routines de décompression on-calc sont sur papier, c'est l'encodeur qu'il faut que je bosse)

L'ExePack automatique, ça ne te convient pas?

Ouai mais l'avantage que shrnklib, c que tu peux stocker tes graphismes compressés dans le prog lui-même, et ainsi n'avoir k1 seul fichier (dans la limite des 65Ko (environ) biensûr)

Je ne vois pas ce que vous avez contre l'ExePack il permet:

- d'avoir un fichier tres leger et un fichier de donnée plus lourd, et on peut ainsi sauter la limitation 24k sans patch
- a l'utilisateur de pouvoir archiver sans soucis le fichier de données (d'habitude on reflechit longtemps avant d'archiver un prog C/ASM)
- de pouvoir programmer en nostub

Et franchement la decompression est tres rapide et c'est un systeme qui je crois a fait ses preuves (Queue, CTC, ...)

>Asterix: Ouai mais l'avantage que shrnklib, c que tu peux stocker tes graphismes compressés dans le prog lui-même

Même chose pour l'ExePack.

L'avantage de shrnklib est d'etre une librarie exploitable dans ton programme, pas comme ttpack.
Meme si tu peux te debrouiller.

L'avantage que je vois dans shrinklib, c'est justement que les graphismes et données compressés n'ont pas besoin d'être dans l'exécutable. A partir du moment où on a plusieurs fichiers, l'exepack ne suffit pas. Pour ce que j'en ai vu, il ne peut compresser que les exécutable.

Blue-Z, tu te trompes
J'ai une beta du Pang d'Aghnar, il y a le fichier graphique qui est externe, et il est compresse avec ttpack
--> Suce Ma Bite pourra aussi en profiter

Et comment procède-t-il ? Il appelle le décompresseur lui même ?
Ca m'interesse s'il est possible de ne décompresser qu'une partie du fichier, par exemple les sprites d'un niveau.

Oui, c'est possible.

Il suffit d'inclure ca :
#include <ttunpack.h>
#include <ttarchive.h>

Et puis, apres, tu n'as qu'a utiliser la fonction unpack().
Ca doit etre documente dans la doc de tigcc, je ne m'y suis jamais penche encore :]

Ok merci !
Je viens de compresser la dernière version de SMB3 avec ttpack et shrinklib :
_ sans compression : 64743
_ avec shrinklib : 29904
_ avec ttpack : 27652

J'opte donc pour ttpack

C'est exactement pareil avec BomberMaze : qd il etait en kernel, compresse avec RunC (donc ShrnkLib) il faisait 29Ko)
Et maintenant compresse avec ttpack --> 27Ko

Euh Kevin, je proteste là Avec l'Exepack, ça crée un 2ème fichier (le décompresseur en fait), donc en fait, on a 2 fichiers, pas un seul

>BlueZ, FlashZ

En effet, ttpack compresse mieux que shrnklib (même si PpHd prétend le contraire à plusieurs reprises).

>Asterix

Le lanceur serait nécessaire de toute façon si le programme dépasse 8 KO (8 pour la compatibilité avec AMS 2.00-2.03).

Kevin> Pas si on a un kernel

Asterix> justement la on vient de montrer que malgré un deuxieme fichier (petit) ttpack compresse mieux que shrnklib et qu'en plus avec ca on peut le faire ne nostub. Alors s'embeter avec un kernel pour obtenir un resultat moindre, c'est vicieux...

Ouai mais imagine kelk1 qui ne prog ken kernel (comme la plupart des débutants en ASM), ben il est niké pour utiliser ttpack, donc il se rabattra préférentiellement sur shrnklib.

Je sais que Pphd utilise la combinaison shrinklib/packer92, ce qui lui permet d'obtenir de meilleures performances. Tout doit dépendre du type de donnée à compresser. De toute manière, shrinklib n'existe que pour kernel, et ttpack n'existe que pour _nostub. Ce qui règle à peut près le problème.

>Blue_Z: Je sais que Pphd utilise la combinaison shrinklib/packer92, ce qui lui permet d'obtenir de meilleures performances.

1. On ne peut pas combiner les 2 pour un seul fichier, mais seulement choisir une librairie différente selon le fichier.
2. Les versions récentes de runc de PpHd n'utilisent plus pk92lib.
3. Dans mes tests, ttpack a été meilleur que le choix pour chaque fichier du meilleur entre shrnklib et pk92lib.

>Asterix : qu'il y ait un kernel ou pas, le taux de compression sera le meme lol.. les donnees auront tjrs la meme structure, et se compresseront tjrs de la meme facon

Ca dépend si tu fais du deflate, du huffman, ou encore un autre...

FlashZ> Bah de toute façon, tu ne peux pas compresser un prog kernel avec l'Exepack.
Comme le dis Blue_Z, prog kernel = shrnklib (ou pk92lib ou ...) et prog nostub = Exepack.

Sauf que l'utilisation de ttpack pour compresser des donnees externes est idiot.
Un : 2Ko de routines pour le decompresseur de programme.
Deux : 2Ko de routines pour le decompresseur des images.
Donc le gain de 2 Ko est perdu pour le doublage de la routine...
Et de toute facon, je prepare un prog de compression qui mettra
tout le monde d'accord.
C plus proche des taux de compressions Pc, que calc.
Ca bat meme WinZip et WinRar sur certains fichiers :P
(Sc pour pas le nommer).

PpHd, si c'est utilisable en _nostub sans un 3ème fichier (librairie de décompression), si le décompresseur n'est pas plus gros que le gain de place par rapport à ttpack, et si ce n'est pas trop lent, peut-être qu'on l'utilisera.