Le probleme va etre sur l'algo de decompression. Avec nos methode propose precedemment a part la premiere (vectorielle) la voix est fermé. Il faudrait utilisé des mathematique avance. Je rentre en Terminale S SI spe Math, peut etre que je verra ca pendant l'année. Pour l'instant c'est wait ant see.
Avec des fichiers aussi petit, ca va etre dur, compresser des truc lourd ok, mais compresser que des 1 et des 0, un peu plus dur.
Suite tres rapide en fait d'année.... :cry:
Comment veux tu mettre l'image sous forme de suite avec la méthode que tu as propose ? Car dans tous les cas avec la méthode du pi tu vas obtenir un alternance de un et de zero !
Donc pas possible !!!!!
Des qu'il y a compression, il y a mathematiques.
Ok pour l'alternance des pixels.
Deus si tu code l'algo comme dit precedemment tu vas avoir un probleme pour les retour a la lignes. Il faut que tu indique la taille de la sprites au debut.
A mon avis, la vectorisation d'image n'est pas adaptée à la puissance du z80, et à la petite taille de l'écran, dès que l'image est complexe, ça ne fonctionne pas... pour compresser des images, il faut utiliser les algos de compression classiques:
RLE:le plus simple, il supprime les suites de plusieurs octets identiques (1,1,1,1,1,1 remplacé par un truc du genre 3,*,1)
LZW:adaptation du RLE, il recherche en gros des suites identiques d'octets (et non suites d'octets identiques) pour supprimer une redondance de ce genre 1,2,3,4,1,2,3,4,1,2,3,4 Plus compliqué que le RLE, mais beaucoup plus performant. (c'est surement le plus adapté à la calculette)
HUFFMAN:là ça se complique, on fait un checksum des 256 octets possibles présents dans l'image, l'octet le plus fréquent sera remplacé par un seul bit, le secont par 2 bits...le moins fréquent sera alors une suite de bits assez longue.... enfin c'est assez compliqué à faire, surtout en asm Z80... donc vautm mieux pas trop chercher par là...
le mieux serait de faire une combinaison de RLE et de LZW (et autres algos pourquoi pas!) c'est d'ailleurs ce que font les formats ZIP,GZIP,RAR,......
en fait ces algos compressent plusieurs fois un même fichier en utilisant deux algos, c'est ça ?
enfin on travaille sur des suites d'octets et non de pixels, donc faut pas compter le nombre de pixels alumés, mais le nombre d'octets identiques, ce qui est beaucoup plus facile à faire, pour le RLE en fait il faut avoir 2 octets de controle,si possible, les octets les moins fréquents dans la suite d'octets à compresser.
si on a comme octets de controle A et B (A pour indiquer une suite redondante, et B pour indiquer un A ou un B)la suite en dessous va etre compressée comme ça:
E E E F A R R R R R R R R R R B I O
->A 4 E B A A A 10 R B B I O (5 octets de gagné)
on gagne pas grand chose comme ça, on doit pouvoir améliorer légerement la compression en faisant un checksum de chaque octet de la liste, et utiliser comme octet de controle les 2 moins fréquents... d'ailleurs, si les octets de controle sont mal choisis, la suite compressée peut etre plus grosse que la suite non compressée! l'idéal est de disposer d'un octet jamais présent dans la liste qui peut servir d'unique octet de controle vu que dans ce cas, y a pas de confusuion possible....
bah la boucle de décompression est pourtant assez simple,
on recopie betement tous les octets sauf les A et B. si on rencontre un A, on va recopier autant de fois l'octet qui se trouve après le nombre de fois à recopier (si c pas très clair, si on a A 5 D, on va recopier D 5 fois...)
Et si on rencontre un B, on recopie l'octet suivant qui est un A ou un B ici
évidemment, ce n'est qu'un exemple, et on pourait mettre A D 5 pour une suite de 5*D au lieu de A 5 D, c'est juste un principe...
pour la boucle de compression, c'est pas plus compliqué, il faut compter le nombre de fois qu'un octet est présent à la suite, si il est présent plus de 2 fois (en dessous, ça va faire grossir au lieu de compresser), on va remplacer la suite par A XX YY (avec XX et YY l'octet et le nombre d'occurences) on regarde si l'octet à recopier est un A ou un B, dans ce cas on doit mettre un B devant...
joe14 Le 07/08/2003 à 19:38 La routine de David Phillips a été optimisée par Clem V. et Aaron Curtis. (voir site Void Productions).
;Input:
;HL = Compress From
;DE = Compress To
;BC = Bytes to Decompress
Decompress:
ld a, (hl)
cp $91
jr z,DispRLERun
ldi
DispRLEC:
ret po
jr Decompress
DispRLERun:
inc hl
inc hl
ld a,(hl)
DispRLERunL:
dec hl
dec a
ldi
jr nz, DispRLERunL
inc hl
jr DispRLEC
Mais à première vue, cette routine a un problème: l'octet de controle choisi pour indiquer une suite de n octets identiques est $91, ça me pose pas de problème, mais le cas où un $91 est présent dans la chaine à décompresser en tant qu'octet "normal" et non octet de controle n'est pas pris en compte, il faut pour éviter ce bug (qui arrive une fois tous les 256 octets en moyenne, c'est ennorme..) avoir un second octet de controle,par exemple $92 qui indique que le prochain octet de la chaine est soit un $91, soit un $92.....
mais ce problème est pris en compte lors de la compression:
si on doit compresser l'octet $91, on écrit alors
$91 $91 $01
ce qui veut dire qu'on a recontré 1 fois l'octet $91. seulement dans ce cas, ça ne compresse plus grand chose. mais ça n'arrive que lorsq'on rencontre l'octet $91
ops: