Versatil Archives auto-extractibles - Page 2

MacIntoc a écrit :
et tu peut pas compiler en _nostub

J'ai déjà fait un programme pour Kernel ???

tu devrais comme ca tu utilise shrnklib et ca resoud pas mal de problèmes.
C'est Kevin qui serait content

edit: non pas shrnklib je viens de me rendre compte qu'elle ne fait de décompresser, il faut un PC pour compresser mais il y a pas mal de lib de compressions qui doivent marcher dans les 2 sens

Oué mais :

1) J'aime pas le mode Kernel
2) Si il faut une lib, ce ne sont plus des archives autonomes, donc ça perd une grande partie de son interet

bah, ca sert a koi ? pke si c pour ajouter le décompresseur ppg en plus, bh ca fait pareil, mais en 1 fichier et c plus long

Il doit bien exister des libs statiques de compression/décompression non?

ttpack existe en statique, mais seulement pour la décompression...

lib statique, KOMP de FL (à passer en statique) et surement bientot PackLib de TICT

Vertyos a écrit :
Oué mais :
J'aime pas le mode Kernel

Vertyos
a écrit : J'ai déjà fait un programme pour Kernel ???

alors t'aimes pas le kernel, mais t'as jamais essayé !? ya contradiction là !

sinon il manque un truc : arc("mot de passe")
archvie auto mais protégée par mdp, quoique...........

Hum... C plutot moyen comme interet... Et puis ça va augmenter la taille de l'auto extractible que j'essaye de maintenir au plus bas

Quand au kernel > Je n'aime pas le principe, cad d'avoir un Kernel sur sa calc (generalement j'en ai pas sur la mienne). Donc forcément puisque j'aime pas je vais pas faire un programme qui en nécessite un !
La SEULE justification ça serait d'utiliser Genlib (parceque XLib me gave serieusement), mais si je peux éviter c'est pas plus mal, donc j'attends que TiMad annonce soit que XLib est abandonnée, soit qu'une nouvelle version est en préparation.

et y'a moyen que la décompression lance automatiquement une appli à la fin (ja pense pour faire des install par exemple, tu dézip et ça lance l'install ou le prog tout seul..)

nEUrOne
a écrit : lib statique, KOMP de FL (à passer en statique) et surement bientot PackLib de TICT

J'ai plus ou moins intégré KOMP à PackLib, avec la permission de FL. Je ne l'ai pas testée complètement (notamment en décompression).

Mais ni Tom ni moi n'avons vraiment le temps de nous occuper de PackLib .
Si d'autres veulent nous aider (comme hibou qui s'est déjà proposé), pas de problème.
TICT n'est pas opposée à ce que des programmeurs extérieurs contribuent: il n'y a pas si longtemps, janjan2 a fait une version 92+ pour tictex; un programmeur avait adapté tthedit dans tictex... et il y a d'autres exemples.

Xlib continu, une nouvelle version devrait sortir si TiMad dit vrai

vince
a écrit : et y'a moyen que la décompression lance automatiquement une appli à la fin (ja pense pour faire des install par exemple, tu dézip et ça lance l'install ou le prog tout seul..)

Oué ça par contre c'est déjà plus interessant
Faudra que je voie quand j'aurais un peu de temps

Aghnar a écrit :
y a pas moyen de faire des auto extractibles pour ppg a ce moment la ? (plus besoin de lanceur )

Certains ont déjà regardé ça (y compris Thomas Nussbaumer lui-même). Le problème, c'est surtout de supprimer le twin du lanceur pour éviter d'avoir 2 fois le programme en RAM (une double-recopie est peut-être acceptable pour JM - cf. Universal OS -, mais pas pour nous!).

Et puis il y a le problème de la limite de 24 KO.

Vertyos a écrit :
Oué mais :

1) J'aime pas le mode Kernel 2) Si il faut une lib, ce ne sont plus des archives autonomes, donc ça perd une grande partie de son interet

Entièrement d'accord pour les 2 points.

Vertyos a écrit :
Hum... C plutot moyen comme interet... Et puis ça va augmenter la taille de l'auto extractible que j'essaye de maintenir au plus bas

ton prgm n'a aucun intéret pour stckoer des sauvegardes alors puisque l'utilisateur pourra les modif [pub]c'est pour ça qu'avec miam je gere direct la valeurs ds un fichier et je n'extracte rien, comme ça pas de problème [/pub]

Et puis il y a le problème de la limite de 24 KO.

Une raison de plus d'aimer le kernel

Vertyos> faudrait que tu nous dises ce qui te gonfle sous XLib ... pke sinon, comment evoluer (XLib ne peut qu'évoluer pendant les vacances !)

les vacnces sont finies là non ?

PS : je suis plus étudiant...

nEUrOne
a écrit : Vertyos> faudrait que tu nous dises ce qui te gonfle sous XLib ... pke sinon, comment evoluer (XLib ne peut qu'évoluer pendant les vacances !)

Ça fait jamais que 15 fois que je le dis mais bon...
- XSpriteEditor qui ne fait pas tous les formats
- XPicEditor qui ne marche pas du tout
- Pas de sprites 32*32
- Format stupide "16*8" qui prend plein de place pour rien
- Affichage "XTGB" qui affiche des "XTGW"
- Pas de mode "remplace" pour les sprites

C'est tout ce qui me vient à l'esprit pour l'instant

Erf tu fais ce que tu veux... Y'a pas à critiquer.
De toute façon en _nostub statique y'a pas vraiment bcp de possibilités :

- Extgraph : Ext-ra lente
- GraphX : Légerement plus rapide, mais d'après Vark et Nerick pleine de contraites assez chiantes
- Xlib : Incomplete

ExtGraph n'est pas si lente que ça! Vive ExtGraph!

Et sinon, il y a une quatrième solution: coder sa propre routine de sprites.

Très bonne solution d'ailleurs

Ouais mais alors la ça va être encore pire qu'Extgraph...
Faudrait le faire en ASM or je n'y connais strictement rien, et puis je n'arriverais jamais à faire aussi rapide que XLib ou GraphX en si peu de temps

Alors, arrête de te plaindre et utilise ExtGraph.

Surement pas

- Pas de clipping
- Perte de 6fps en moyenne
- Pas de mode transparence

(dans l'ordre d'importance)

Si tu veux, j'ai adapté les fonctions d'Extgraph pour qu'elles gèrent le clipping, mais c'est super lent (presqu'aussi lent que les fonctions de tigcclib.h, je ne dois pas avoir utilisé la meilleure technique, probablement), par contre, les fonctions sont à peine plus grosses que celles d'extgraph (cad bcp moins que celles d'xlib).

Oui j'ai fait ça moi aussi, mais même constatation : c'est ultra-lent

il existe une version de certaines fonctions d'extgraph qui ont le clipping dans le GDK de la TICT
(les passages de params ne sont pas tout à fait pareil, et il y a utilisation de variables globales pour les plans... et les plans doivent être à la suite en mem...)

Vertyos> il me semble que je te l'avais envoyé, d'ailleurs

Dans les prochaines versions d'extgraph, le clipping devrait être géré. (enfin, c'est ce qu'ils disent dans le fichier TODO.txt)