Nouvel utilitaire.... - Page 6

tres tres gros... non
mzisd plein plein de petit oui !

ça vaut mieux en fait, les gros on les fini jamais

heu les petit non plus

mais si mais si
bon moi j'ai presque fini de faire un bo menu

enfin bon ils seraient surement deja fini si je n'etait pas continuellement derangé par des gens sur ce forum

je dois me sentir visé ?

rah je vise tout le monde


(arg)


flood

bah moi je prog pendant ce temps... d'ailleurs voilà, j'ai un menu qui marche.

moi je DL uplink...

oué c une autre occupation...

Au fait Azerty83, je pense avoit trouver une soluce pour ton histoire de pack renomer.
Il suffit que tu modifie un octet bien precis du pack avec une valeur que t'es sur qu'elle serat jamais utiliser sur cette octet.
Par exemple, tu sauve le 1e octet du pack dans un autre coin du pack et tu la remplace par une autre valeur (0h13, par exmple). Comme ça, tu récupère avec FLib toute les varable du type du pack (je sais plus c'est quois) tu vérifie le 1e octet du fichier, si c'est 13, c'est le pack, tu remplace 13 par la valeur qui à été sauvegarder, et tu décompresses.

moui mais ce serait hyper long...
(c un typ prgm je te le rapelle)
je regarde seulement le nom du fichier
(j'avais penser a verifier la taille aussi mais ca pose un pb : je ne peux pas (a 100.0000000000000 savoir quelle taille fera le pak au final (et oui le taille du pak peu etre sur 1 ou 2 octets...)
enfin je pense que je pourrais me demerder (ceci permeterait de voir si le pak est bien valide ou si ce n'est pas un autre pak qui porte le meme nom mais qui a un contenu different)

Ah oui.
J'avais pas pensé à un pack différent et portant le même nom

et puis le gros pb de verifier la taille, c que je ne peut connaitre la taille que fera l'ensemble qu'une fois je prog de decompression tokenizé, ce qui signife qu'il faut que je reserve de la place dans la source et qu'ensuite je puisse retouver cette place dans le code tokenizé...

Je pense que la méthode MacIntoc est la meilleure...

oui masi si differentes version de pak sont presente sur la calc... bobo (ceci dit je peux utiliser les deux )
(enfin faut que j'arrive a implementer la verification de la taille)

Ouais, en recoupant toutes les données, tu devrait bien finir par tomber sur le bon pack.

EDIT : j'en ai marre de cte putaind de touche TAB de merde à la con
[edit]Edité par MacIntoc le 10-03-2002 à 16:38:45[/edit]

enleve-la

J'y ai pensé, mais elle résiste cette salope

revenons a nos moutons :
je viens de "finir" un algo qui permettrait de compresser plus de 64ko dans un fichier komp (et que j'implementerais bientot a mkpak)
il marche parfaitement (malgres un pauvre ratio : faudra pas esperer depasser les 80ko sauf si c avec des var entierement vide ), seul hic : flib
en effet komp: plante royalement (vive les hot reboot de PreOs !) quand j'essaye de kompresser des gros fichiers (+40ko) avec mon algo (mais tres rarement quand je les kompresse a la main), donc ca m'emmerde !

voila...
bob>envoie moi CMS2 pour que je vois a quel point je peut le compresser (il fait combien decompressé ?)

et vertel ca fait pas la compression ?

ché po
chcrois que c que des graphismes

non y a pas que des graphisme
je v regarder

non y a des trucs, mais pas la compression...

de toute facons, je ne le ferais qu'avec flib !
car si il n'y a que 2 personnes qui utilisent vertel contre xxxxxxx personnes pour flib,ca n'a pas d'interet

avantage:
vertel prends bcp moins de place que flib et est plus rapide

m'en fout ! ()
je veux que des millions de personnes utilisent mon prog et qu'ils m'aclament quand ils me croiseront dans la rue !

He bien justement preds Vertel, tu fera partie de l'élite

Bon CMS2 non compressé ça fait 108Ko, mais je c pas si je l'ai ici, sinon faudra attendre ce soir

mouais 108ko, ca me parrait chaud !