Niveaux de gris à 3 plans (7 ou 8 niveaux de gris) pour TIGCC - Page 2

Ce n'est pas si simple que ça:
- il y a beaucoup de RAM_CALLs
- ça utilise des fonctions bizarres de filelib
- il y a plein d'accès directs à la VAT, et on n'en veut pas!

Les RAM_CALL et filelib, c'est pas tres dure a convertir en nostub...
Mais bon, il suffit de definir le format KOmf (? je sais pas si c'est ca) comme le format nostub..

sans déconner, un jeu tel que CF serait mieux en 7/8 gris qu'en 3/4

certe, mais t'as vu la taille que prennent déjà les sprites en gray4 ?

y'a qu'a faire un autre format de sprite

ziplib a été faite il y a longtemps, par des programmeurs qui connaissaient à peu près le peu qui était connu sur la 89/92+ à l'époque. Mais c'est très mal programmé (accès direct en VAT et fonctions de filelib, ce qui est très moche et dangereux: filelib n'est pas exempte de bugs comme la plupart des librairies kernels, du moins celles qui n'ont pas été refaites depuis cette époque)...

j'ai regarder comment était fait ziplib: j'en conclut que c'est pas du tout compatible avec komp... Mais bon, y'a un seul truc que je comprend pas : cf ici
sinon j'ai adapter KOMP en librairie statique pour mon Hib-Text : j'aurais déjà pu vous montrer ce que j'ai fait mais mon site est down
En plus je pars en vacances très bientot, donc il risque d'être down longtemp

C'est bien d'avoir adapté KOMP en librairie statique... Moi aussi, je l'ai adaptée pour le projet de TICT PackLib (pas encore releasé avec le port de KOMP).

Pour ce qui est de la compression, je ne peux pas aider dans les algorithmes: je n'y connais rien...

LZ aurait été plus rapide pour un programme comme HibText (decompression tres rapide) mais faut tout coder ...

de toute manière, si je veux faire quelque chose de compatible ziplib, il faut tout recoder ! Par exemple : ziplib compresse à l'envers ! il commence par la fin et remonte tout le fichier
je vais voir ce que c'est que LZ...

sinon, faut tout simplement passer ZipLib en librairie statique ... comme l'a dis TiMad

LZ: t'aurais une meilleure compression (mais plus lente) et une decompression plus rapide, ca fontionne avec un dictionnaire...

l'embêtant dans cette solution est que ziplib a besoin de filelib, graphlib et userlib aussi...
comme j'ai besoin que de la (dé)compression : c'est pas du tout interessant...
Et puis apparement, d'après XDanger (je ne m'y connait pas assez en asm), ces librairies ne font pas des trucs tellement propres...

lz semble plus s'adatper à mon type d'utilisation : principalement de la décompression : je regarderai ça à la rentrée...

Ca fait des années que l'on utilise ZipLib, c'est donc que son utilisation est bonne.
Mais rien n'empèche de prendre KomF comme compresseur.

timad> c parce que les temps de compression d'un LZ sur calculatrices ne sont pas bons ... mais si c des textes par exemples compressé sur PC et envoyé sur TI (comme tous les textes zippé) ben c parfait là

si tu savais le nombre de textes que j'ai tapé sur la TI, et zippé sur la TI...
(en encore, j'ai un PC avec le TIGL ! alors que 3 gars de ma classe faisaient tout on-ti !)

heurf .. bon, ben je parlais pour moi alors

-