zlib pour ti - Page 1

Salut à tous,

A moins que cela ne soit déjà fait, j'aimerais savoir si la librairie standard zlib (http://www.zlib.net/) écrite en C standard et adaptée sur plusieurs plateformes, serait adaptable facilement sur la ti?

Bien à vous.

Fred.

heu... je sais pas si c'est déjà fait (attends confirmation à tout hasard), mais si tu comptes l'adapter, va falloir plonger dans les sources donc c'est un peu à toi d'aller y jeter un oeil et déterminer si c'est faisable facilement ou pas ^^

Ce serait si intéressant que ça, par rapport à ce qui existe déjà ?

L'idée est plutôt d'archiver tous les fichiers de mon jeu en un seul, dans un format standard (zip) et de sortir au fur et à mesure les fichiers dont j'ai besoin. Donc, tant qu'à faire, autant faire quelque chose de générique pour que d'autres puissent en profiter.

Fred.

Ben je ne sais pas comment les autres compresseurs gèrent ça, mais la compression nécessite de grandes quantités de RAM : 256ko par défaut. Cela peut être réduit, au détriment de la qualité de compression...
Dans tous les cas, ce serait intéressant de bénéficier d'une grande partie de la RAM (128ko par exemple), mais ça risque d'être difficile à gérer sur AMS puisque ce système ne permet pas d'allouer plus de 64ko contigus.

Et puis l'API est peut-être un peu riche pour être portée sur TI.
Cela dit, tu peux faire un compresseur (enfin, un décompresseur surtout) exploitant le format en question, sans pour autant fournir la même API que celle de la vraie lib.

en fait ce qui se fait (enfin ce que moi j'ai fait en tous cas) pour le genre de choses que tu dis, c'est de faire la compression sur PC et d'avoir seulement la routine de décompression sur la calculette (a priori, tu n'as pas besoin de compresser oncalc ?)
Personnellement j'avais utilisé shrnklib pour la version kernel de mon programme et ttarchive/ttpack (bien que je n'aie théoriquement pas le droit parce que GPL gnagna) pour la version nostub.

tout à fait, je n'aurais besoin que de décompresser dans un premier temps, mais si je vois que ça marche bien, dans un second temps, pourquoi pas généraliser le process.

Ben pour la décompression les besoins en mémoire sont seulement de 44ko, donc c'est très facilement faisable
Reste à voir si c'est aussi petit et rapide que ce qui existe déjà...

Il existe en effet déjà quelques solutions pour la décompression d'"archives" on-calc, et quelques solutions de compression/décompression on-calc

'soir,

actuellement, j'utilise ce qu'il y a dans tigcc, et ça tourne bien.
mais le nouveau but que je me suis fixé, c'est d'archiver le tout dans 1 fichier (avec un archiveur classique - WinZip, WinRar etc.) et d'extraire uniquement les fichiers dont j'ai besoin au moment du chargement d'un niveau. Donc, je pense que le méchanisme des archives zip me paraît tout à fait adéquat. Egalement, si je souhaite mettre en place ce méchanisme, c'est dans un souci de distribution. C'est mieux de distribuer 3 fichiers que 180

fred.

Oui, l'idée de décompresser seulement un bout de fichier est adéquate, mais :
- le support des fichiers zip n'est pas inclus dans zlib à proprement parler je crois
- la compression zip n'est peut-être pas très adaptée aux TI

Ce dont tu parles rejoint en fait l'idée des packs archives, et shrnklib est très adaptée pour ça (puisqu'elle peut compresser les fichiers collectivement [donc avec un taux de compression meilleur qu'une compression individuelle] tout en les décompressant individuellement)... Si ton programme est en mode kernel tu n'as rien à implémenter puisque preos le fait, sinon je ne sais pas s'il y a une version nostub ?

non (ou alors il faut me prévenir pour que je l'utilise ) mais ttarchive+ttpack peut convenir (par contre chaque partie est compressée indépendamment donc ça ne tire pas avantage du fait qu'il y ait plein de fichiers, mais bon la différence est pas monstrueuse)

le jeu n'est rien du tout... on compile et ça tourne. Je cherche à faire en sorte qu'il n'y a rien à installer pour lancer le jeu: juste l'executable (compréssé) et le fichier de données.

j'ai effectivement vu que zlib ne supporte pas les archives.

L'archivage a effectivement pour but subsidiare de gagner de la place au niveau des clusters (je ne sais pas si on dit comme ça sur ti).

ttpack a un taux de compression en général meilleur que celui de shrnklib, ce qui doit limiter la différence entre les deux routines (voire rendre ttpack meilleure avec certaines entrées). Mais d'une façon générale, avoir de nombreux fichiers est moins efficace en taille données ET code, puisque c'est plutôt plus compliqué de gérer l'ouverture de nombreux fichiers que de gérer un seul fichier (ou quelques-uns, pour les jeux qui ont besoin de plus de 64K de données... ce qui n'est pas la majorité d'entre eux) contenant tout.

A noter que shrnklib est un des formats supportés par pstarter (les lanceurs spécifiques). Il avait été envisagé par Kevin au moment où ttpack n'était pas sous licence libre (maintenant, c'est le cas depuis plusieurs mois, mais je n'ai pas encore updaté la TIGCC Tools Suite et ttstart... ). Ce format présente néanmoins un intérêt limité: routine de décompression plus grosse que la routine ttunpack "super duper small"; décompression moins rapide que d'autres (je n'ai plus les chiffres en tête); base installée en nombre d'exécutables voisine de 0%...
[EDIT: donc accessoirement, oui, shrnklib est utilisable en AMS native. Et correction, je viens de regarder les sources, il n'y a pas de support shrnklib pour ttstart.]


On dit plutôt "blocs" pour l'archive

ok. bloc pour archive, cluster pour fichiers sur disque dur et oui, je sais ce qu'est un cluster: intersection entre cylindre et secteur.

ceci dit, tu as effectivement soulevé un problème que je rencontre dans mon projet. Du fait que chacune des tables d'animations des différents élément se trouvant dans des fichiers séparés, la gestion est hardue: il faut être TRES méthodique, de plus je perds systématiquement de la mémoire du fait que je dois maintenir des données pour chaques fichiers ouverts (handle du fichier etc.)

Pour te donner une idée, le personnage du jeu possède 9 tables différentes comprenant chacune 128 animations de 16x16 en niveau de gris: ça c'est juste pour les tables du poussin. Pour des raisons de programmation, les tables ont été ainsi faites. Biensur, les 9 tables ne sont pas ouvertes à chaque niveaux (heureusement). Au pire, 2 tables sont chargées, tout dépend des outils disponibles. Heureusement pour moi, l'ensemble des données du jeu est fini. Ce qui fait que je peux tout archiver et extraire uniquement ce dont j'ai besoin. Ce qui est mon but car ça libèrera de la ram et du code.

En taille mémoire, que représentent les données que tu veux compresser ?

boulifb :
L'archivage a effectivement pour but subsidiare de gagner de la place au niveau des clusters (je ne sais pas si on dit comme ça sur ti).

Tu ne gagneras rien du tout : les clusters sont en fait de la taille maximale d'un fichier (64 ko), donc contrairement aux filesystems sur PC l'archive est faite pour qu'on puisse mettre pleins de fichiers dans un seul cluster -- et donc ça ne coûte rien de couper un fichier en deux, à part un léger overhead parce que l'OS doit stocker le nom et le répertoire du fichier... Par contre, c'est effectivement plus sympa pour l'utilisateur d'avoir tout dans 1-2 fichiers plutôt que d'avoir 500 fichiers ^^

Hmm sinon quelle est la taille moyenne de tes fichiers ?

./15 (désolé pour le HS) > c'est pas que j'aie eu l'intention de vraiment changer de lib, mais c'est compatible gpl maintenant ? si oui j'ai le droit de l'utiliser, zut je n'ai plus de prétexte pour ne pas releaser . Sinon effectivement ttpack donne des résultats presque aussi bons que shrnklib malgré le fait que chaque élément soit compressé indépendamment (dans le cas de foblub c'est des blocs de 4K)

si je ne me trompe pas shrnklib a aussi la particularité qu'elle est obligatoirement installée avec preOs, donc si on est déjà en mode kernel pour une raison quelconque l'utilisateur sera de fait pratiquement obligé d'installer shrnklib, c'est en fait pour ça que je l'avais utilisée dans la version kernel de foblub (en fait au départ la version kernel c'était juste le même code mais compilé avec l'option kernel, et ensuite j'ai remplacé ttpack par shrnklib pour diminuer la taille de l'exécutable sachant que les utilisateurs auraient shrnklib par ailleurs... et que le but de la version kernel était justement de faire un exécutable plus petit pour les gens ayant un kernel (sinon c'était complètement inutile puisque la présence du kernel n'empêche pas la version nostub de marcher ^^).
Par contre je déconseille de faire comme moi parce qu'en fait c'est super chiant d'avoir 23 versions différentes du même programme à distribuer, surtout qu'en l'occurrence j'avais aussi le prog de compression (sur PC) qui devait exister en deux versions différentes suivant qu'on utilisait la version kernel ou nostub de foblub... ... tout ça pour gagner quelques centaines d'octets ^^)

(et shrinklib existe sur Fargo aussi #argument#)

pour le moment, j'ai en tout 144 fichiers de données. 73 fichiers correspondant aux niveaux qui sont compressés et 71 fichiers comprenant les sprites et les tiles ces derniers ne sont pas compressés.

Oui mais quelle taille les fichiers à compresser ?

./19:
> c'est pas que j'aie eu l'intention de vraiment changer de lib, mais c'est compatible gpl maintenant ? si oui j'ai le droit de l'utiliser, zut je n'ai plus de prétexte pour ne pas releaser .
Si, il y a encore un prétexte, c'est que je n'ai pas releasé de nouvelle version de TIGCC Tools Suite ni de ttstart... mais en principe, ça ne va pas durer encore longtemps !

./21: en TI-BASIC, on peut difficilement faire bien autrement (voir le SimCity de GLR), mais je pense que ce serait plus efficace avec moins de fichiers. Donc, même question que ./22

.21/ autant pour moi. Les données se répartissent comme suit:
- 73 fichiers contenant les niveaux utilisant 102223 octets non compressés et 50823 octets une fois compressés (séparément) avec ttpack
- 71 fichiers d'images non compressés utilisant 181824 octets.

OK, ça fait quand même pas mal de données...
Les niveaux font une taille moyenne de plus d'1 KB, donc les headers ttpack/ttarchive ne représentent pas une proportion trop importante de la taille (~2-3% de la taille moyenne compressée).
Tu as essayé de compresser les images avec ttpack/ttarchive ou une autre compression ?

.24/ j'ai essayé en effet mais j'ai obtenu des choses assez bizarres. Lorsque je décompresse les fichiers je récupère bien un pointeur sur un unsigned char (que j'appelle PBYTE). Lorsque je décompresse des niveaux (qui peuvent aller jusqu'à 4KB - décompressé - maps énormes) cela fonctionne bien et c'est ce que je fais actuellement. En revanche, j'ai un problème avec les tables d'images. Lorsque je décompresse et que j'affiche les images (après avoir casté le pointeur bien sur) je n'ai pas l'affichage escompté: ça affiche n'importe quoi. Ce, alors que je fais exactement le même procédé que pour la décompression des niveaux. Il se peut que je fasse mal une opération. Pour les tiles 8x8 je ne caste pas, ça reste du PBYTE car chaque ligne de l'image est codée sur un octet, et pour les images de 16x16, je cast en PWORD (unsigned short* - 2 octets). Actuellement les images ne sont pas compréssées. Mais le jeu utilisant beaucoup de mémoire, je crains fort qu'il y ait saturation si je compresse les images, en effet, il faut la place pour les décomprésser, et il y a beaucoup d'images par niveau. Comme vous avez pu le voir, l'environnement graphique est très riche.

Possible que tu consommes trop de RAM si tu compresses les images... mais tu réduiras la taille de ton code si tu regroupes les images en quelques fichiers.
Pour le problème que tu rencontres, je ne vois pas.