Un newbies de Plus (^_^) - Page 8

-

bah de toute façon laisse tomber, ce que je lui ai donné est plus rapide

-

Mais pourquoi as-tu modifié ma routine, elle était parfaitement correcte En plus, tel que tu l'as trafiquée, elle est moins rapide !
'faudrait peut-être faire confiance à ceux qui t'aident parcequ'ils maîtrisent un peu mieux l'ASM68k que toi

-

-

je n'ai pas lu tout le topic mais n'empeche que tu en poses des questions,perso je te trouves relou,surtout que tu passes beaucoups de temps sur le forum.

-

-

Effectivement j'ai fait une petite erreur d'inattention, pardon     moveq     #99,d7          ; 100 lignes loop:     move.l     (a1)+,(a2)+     ;  4 octets     move.l     (a1)+,(a2)+     ;  8 octets     move.l     (a1)+,(a2)+     ; 12 octets     move.l     (a1)+,(a2)+     ; 16 octets     move.l     (a1)+,(a2)      ; 20 octets     lea        14(a2),a2       ; a2 a été incrémenté de 16, il manque 14 pour faire 30     dbf        d7,loop

Orion_
a écrit : c t avec koi sa ? extgraph ?

Oui.

en fait je voudrais plutôt savoir comment
afficher une image en gray compréssé avec shrnklib
[...]
shrnklib parceque d'aprés PpHd et gugus, c la lib qui compresse le mieux et qui décompresse le plus vite les imgs

Quand est-ce que PpHd deviendra-t-il enfin objectif??? ttpack compresse mieux que shrnklib!!!
En particulier, voici les résultats sur une image, le keymap de XtraKeys converti en 89i, puis en binaire avec ttstrip:
non compressé: 1547 octets
compressé avec shrnklib: 1008 octets
compressé avec pk92lib: 992 octets
compressé avec ttpack: 888 octets
ttpack donne de loin le meilleur résultat!

Kevin Kofler a écrit :
Quand est-ce que PpHd deviendra-t-il enfin objectif??? ttpack compresse mieux que shrnklib!!!

Oui mais il a dit "qui compresse le mieux et qui décompresse le plus vite les imgs". Tu pourrais faire des tests de rapidité également pour qu'on soit tous fixés une bonne fois pour toute ?
(oui je sais je suis chiant)

Kevin Kofler a écrit :
Quand est-ce que PpHd deviendra-t-il enfin objectif??? ttpack compresse mieux que shrnklib!!!
En particulier, voici les résultats sur une image, le keymap de XtraKeys converti en 89i, puis en binaire avec ttstrip:
non compressé: 1547 octets
compressé avec shrnklib: 1008 octets
compressé avec pk92lib: 992 octets
compressé avec ttpack: 888 octets
ttpack donne de loin le meilleur résultat!

J'ai fait des tests avec mes images (Source de Cf, sma), et shrnklib a compresse mieux ces images que ttpack (A peu pres, 200 fichiers) dans plus de 80% des cas. C'est tout. Si tu n'es pas content, c'est pareil.

-

le coup de la libraire marche tres bien. Mais dans ce cas, rajoute xdef _readonly (Ou _flag_3) pour specifier a preos de ne pas desarchiver ta libraire.
Tu peux meme l'importer dynamiquement avec kernel::LibsBegin, LibsPtr et LibsEnd.

Je ne comprends pas ta macro ?

-

Ben dans la lib tu fais un
include "tios.h'
xdef _library
xdef _readonly
xdef gfxdata@0000

gfxdata@0000 incbin "toto.bin"

end

Puis dans l'autre, compiles tu en kernel ?

-

Ben mets le
arcdata equ gfxlib@0000 tout en haut deja.
Ensuite neleve le PC, ce n'ést pas PC relatif, mais absolu comme adresse.

-

Orion utilise le code que je t'ai donné au post 219, il est légèrement plus rapide

Orion_ a écrit :
m'enfin, perso, je prefere (pour l'asm) pk92lib
c bien mieux que shrnklib, déja pk92lib gére le freemem
direct, alors que c sa qui me plantait tout sous shrnklib
et aussi pour extraire c mieux, pk92lib > 1 fonction shrnklib> 3 fonction

Tu as oublié une possibilité:
Project / Add files / extgraph.a / OK
bsr UnpackBuffer
(ExtGraph 1.00 contient la fonction de désarchivage de ttunpack.)
Et ça aussi, c'est une seule fonction.

PpHd a écrit :
Ben mets le
arcdata equ gfxlib@0000 tout en haut deja. Ensuite neleve le PC, ce n'ést pas PC relatif, mais absolu comme adresse.

... ce qui est un des désavantages des librairies dynamiques. Pour les librairies statiques, si le programme fait moins de 32 KO en tout, on peut utiliser de l'adressage PC-relatif (en assembleur seulement, GCC ne l'utilise pas parce qu'il ne sait pas si le programme fait moins de 32 KO).

Kevin Kofler
a écrit : ... ce qui est un des désavantages des librairies dynamiques. Pour les librairies statiques, si le programme fait moins de 32 KO en tout, on peut utiliser de l'adressage PC-relatif (en assembleur seulement, GCC ne l'utilise pas parce qu'il ne sait pas si le programme fait moins de 32 KO).

Sauf que tu as oublie que c'etait une librairie de données, donc du gaspillage de RAM

C'est vrai. D'ailleurs, c'est vraiment idiot de mettre ses données dans une librairie dynamique. Les fichiers de type personnalisé sont faits pour ça. Tu n'aurais jamais dû mettre ce flag _readonly (ou _flag_3 comme il s'appelle chez nous - avec un equate pour la compatibilité dans les nouveaux headers sur lesquels je travaille encore).

Kevin Kofler a écrit :
C'est vrai. D'ailleurs, c'est vraiment idiot de mettre ses données dans une librairie dynamique. Les fichiers de type personnalisé sont faits pour ça. Tu n'aurais jamais dû mettre ce flag _readonly (ou _flag_3 comme il s'appelle chez nous - avec un equate pour la compatibilité dans les nouveaux headers sur lesquels je travaille encore).

Pkoi ? Ca bouffe du code pour rien, de faire la recherche, le lokkage, la relocation.
Et tout ca pour un flag T'es jaloue, avoue Je peux deplacer tres facilement des donnees externes dans la librairie. Sinon faut se faire des fonctions specialisees, et ca prend de la place pour rien

On n'a pas besoin de fonctions personnalisées, juste de SymFindPtr et de HeapDeref.
Et les relogements de librairie bouffent de la place pour rien alors qu'on peut utiliser un simple x(an) si on ouvre un fichier de données normalement.

Et si le fichier de donnees change sans arret ? Toujours se recalculer les offsets

Il suffit de stocker les offsets au début du fichier (facile, dc.l data3-begin suffit). Et pour y accéder, on fait par exemple:

;place l'adresse de la 3ème entrée sur la pile
 move.l 8(a0),d0
 pea.l 0(a0,d0.l)

Ce n'est pas difficile.

Ca bouffe des registres et j'en dispose pas forcement Je prefere vraiment mes peittes libs en read_only. Plus simple d'emploie.

-