??? justement j'ai fait le convertisseur pour crée des fichiers au format exelvision ????jester a écrit :Ne crée surtout pas un format propriétaire... autant lire directement du PCX ce qui permet de produire les fichiers sur PC.
Exelmax est effectivement pas evident.Si tu utilises ExelMax, Bon courage !
J'ai abandonné et suis passé au Cross Compiler...
Pour l'instant je fait mes routines directement dans l'emulateur en modifiant la ram !
Sinon si tu as un lien pour un cross compilateur, je suis preneur ?
je trouve pas specialement compliqué et plutout pratique pour certains cas !On peut aussi appeler les routines assembleurs du BASIC, mais ça risque d'être plus compliqué sur certains aspects.
Tu n'a pas bien lu, regarde bien la condition: Si caractere de controle..... SINON..... et tu peut voir que cela ne fait pas perdre d'octets et je pense même que l'on peut poussé jusqu'a dire que si un octet se repete moins de 3 fois => ne pas compressé, et la on a encore moins de pertes d'octet.PS: Avec ton algo si tu as une seule occurrence d'un octet à écrire qui a malencontreusement la même valeur que ton octet de contrôle, tu es dans le caca me semble-t'il ? Il te faut dans tous les cas <Rep, Code>+, même si Rep vaut 1... sinon Et donc tu perds plein de place si tu n'as pas beaucoup de répétition >1.
Tu te complique, a mon avis, on verras si j'arrive a finir, la decompression sur exelvision.De plus l'organisation mémoire du VDP me laisse penser qu'il vaut mieux considérer un pattern de 3 octets qu'on répète... ou bien il faut passer à un format PCX (par exemple) pour éviter ce problème.
Le mieux (peut être) pour un format propriétaire serait de placer la valeur de couleur et la répétition dans le même octet (3 bits pour la couleur, 5bits pour la répétition soit 32 répétition d'une couleur). On se retrouve avec un format séquentiel optimal, mais il faut reconstruire le pattern de 3 octets à envoyer au VDP.
Mais je suis pas sur que ce soit vraiment meilleur... à cogiter.
On peut aussi imaginer d'encoder avec cette technique par composante : 1 passe pour le Bleu, une passe pour le vert, une passe pour le rouge (1 bit pour la composante, 7bits pour la répétition). L'image devra être stocké en 3 parties: composante bleu, ensuite composante verte, enfin composante rouge. Pour éviter l'affichage chaotique des 3 passes, il suffit de swapper en mémoire VDP (je change le pointeur BAPA sur ma zone haute résolution qu'une fois mon image construite: il y a assez de mémoire VDP pour supporter un écran texte avec sa police + un écran bitmap 320x200).
Le RLE n'est pas pourri puisqu"il n'y a aucune perte de données avec la compression, d'ailleurs c'est la même technique que le PCX, c'est juste a mon avis la compression la moins lourde a gerer sur un 8 bits (en terme de temps/performance).Aucune de ces techniques ne donnera de résultats formidables, en général tu divises par 2 l'image (rarement plus, souvent moins). Et oui, le RLE c'est tout pourri mais décoder du GIF ou du PNG (coef 5 en compression) c'est compliqué et ça prend beaucoup trop de mémoire sur une vieillerie 8 bits.
Quand au GIF, PNG... , aucun interet sur un 8bits avec 8 couleurs
Si tu veut tu peut essayer de faire un decompresseur basé sur un autre format ?