Ca fait déja un moment que je me suis lancé dans le compactage de données
je crois que j'ai déjà lancé une rubrique dessus mais voila la nouvelle,
j'espère que ça donnera et intéressera quelqu'un ou me (lui) donnera des idées ...
Je me suis attaqué pour le moment depuis quelques mois aux écrans 17K image de présentations je vous fait pas un dessin
J'ai déja fait quelques études et projets malheureusement pas toujours a la hauteur des
derniers compacteurs applib et exomizer. Mes débuts sont prometteurs... Mais le résultat n'est pas encore à la hauteur.
J'ai constaté qu'une réorganisation de l'écran en un sprite dont les octets sont en verticales donnait un très bon résultat après un compactage avec les compacteurs de dernières générations
la réorganisation horizontale est aussi meilleure qu'un écran 17 K mais moins bonne que le vertical.
J'ai fait quelques compacteurs
1. Chaque fois qu'il voit un octet il compare ce qu'il est après genre (methode RLE)
01 01 01 02 03 04 04 ff ff ff ff ff 03 05
compacte ca fait 01 03 02 01 03 01 04 02 ff 04
pas vraiment ergonomique
Technique 1
Comme je m'attaque qu'aux images en prenant compte que c'est un mode 1
les 4 couleurs primaires correspondent a &00 &0f &f0 &ff encre 0,1,2,3
ce sont les plus utilisées dans une images, statistiquement c'est pas loin des 70 %
d'où j'ai fait une version améliorée qui ne prenait compte que des 00 0f 0f f0
donc quand il il y a un 00 ou 0f f0 ff dans le compactage il copie le nombre après
c'est déjà beaucoup mieux mais le problème se pose quand il n'y a qu'un 00 ou 0f ou f0 ff ca prend 2
octets a la place d'un.
J'ai trouve un solution je scanne les octets de l'écran et dans 99% I il y a des octets non utilise
dans un écran. donc je fais un test de tous les octets et je prends des non utilises
et je les attribue l' un a &00 l'autre a &0f , l'autre &f0 et &ff
par ex pour la compréhension si dans l'écran il n'y a pas de 54 admettons je l'attribue dans mon compactage
a 00 comme ça s'il n'y a qu'un 00 je le laisse c'est bien mais pas assez...
Technique 2
En sachant que les 00 ou 0f f0 ou ff sont les plus présent dans un écran mode 1
j'ai pense que je plus pratique serait de les enlever
J'ai réalise le compactage qui enlevé par ex tous les 00
ma méthode est que j'ai employé les bits
donc par exemple 00 00 00 00 01 44 55 ff (image)
ça correspond a 01 44 55 ff (la source sans 00)
et l'autre partie du compactage par bits
0 0 0 0 1 1 1 1 =&15
donc pour c'est /8 une image prendra &800 de données et le reste de source
c'est bien mais pas assez
j'ai fait des tests en passant après par aplib et le résultat donnait mieux si je faisait
1 sur deux c'est a dire que c'est la même méthode mais il compare par 2 octets
un exemple
00 ff 44 f0 00 00 00 00 00 00 f0 11 55 00 00
résultat 1 sur 2
1 1 0 0 0 0 1 1 0
c'est mieux mais ça suffit pas comme ca ça fait &400 de donnes octets au lieu de &800 (normal 1/2)
j'ai essayé de faire une autre méthode
dans une image toujours mode 1 il y a 4 couleurs
donc j'ai fait une routine qui analisait les bits c à d si c'est du rouge on trace du rouge sur la longueur qui faut
ça va mais c'est pas aussi concurrentiel que les autres
c'est a dire que je scanne ligne par ligne 4 rouge 1 blanc 5 vert 1 blanc 2 gris 1 blanc 25 rouges
le problème c'est qu'il y a a 64000 octets par écran a (8*8*40*25) ça compacte mais pas assez
J'ai pensé qu'une image pouvait être affiche dans une autre mode qui ne lui correspondant pas donc
quand je l'affiche en mode 2 il n'y a plus que de 2 couleurs ça simplifie les choses il n'est pas compliqué
de la réachiffer dans le bon mode avec un call bc0e et ldir mais pas assez concluant
méthode 3
dictionnaire
j'ai pensé que mettre les octets différent de l'image en partant de c000 dans un dico serait intérressant
mais un dictionnaire de 16 octets dès qu'il est rempli on commence une autre page, le principe est d'attribuer un
chiffre sur 4 bits au nombre pour pouvoir a la fin diminuer de moitie l'image
donc une image 00 ff 44 00 44 22 11 f0 02 03 09 09 11 05
on attribue le premier 00 a 00
ff a 01
44 a 02
22 a 03
etc jusqu'à 0f ensuite les nouveaux.
Le principe est que je fusionne les deux octets en un.
Ca fait que pour une image c'est la moitie le problème c'est que le dictionnaire prends beaucoup de place
car lorsque que les 16 octets sont occupés le suivant fait une nouvelle série. Je sais pas si je suis clair...
Le principe est bon mais ...
A vos idées merci
Si quelqu'un veut mes sources pas des soucis je peux les mettre en ligne