Logicielsmoto.com

Oui je pense, Même avec mon code. 192 pixels ca fait 3*8octets, donc 96 cycles, qu'on groupe par 8 = 768cycles pour 8 lignes en écran "forme". +6 pour le inc <$C3, donc 1548 cycles pour 8 lignes formes + fond. 100 lignes ca fait 12 groupes de 8, donc 1548*13 = 18576cycles.

Donc effectivement 192 x 96 prend 18576 cycles. Si on affiche plutôt vers le bas de l'écran et qu'on commence la recopie alors que le spot commence sa remontée (début de VBL donc), on le devance toujours un peu et on a l'illusion d'un switch instantané.

@CloudStrife oui effectivement c'est moi qui me mélange les pinceaux entre frame/trame et vbl.

Reste que 96 lignes, c'est pas bcp pour de zolis dessins. Et il ne reste plus bezef de cycles pour faire des trucs intéressant.

@sam & CloudStrife
Sur Amiga, comme sur Thomson, on parle d'1 VBL pour une frame. 2 VBL=2 Frames, etc...
Normal, puisque par frame, on a qu'1 VBL. D'où l'extension de langage.
C'est devenu commun de parler en nombre de VBL qui est équivalent au nombre de frames.

[EDIT]
En me creusant un peu la tête, j'ai fini par trouver une méthode pour blitter une image 192x120. Ou en portrait 128x180.
Il faut commencer à blitter juste après le passage du spot bien entendu et ça ne me pose aucun problème.

Bon ça fait un certain moment que je n'ai pas converti d'images, aussi voici une série d'image extraites du jeu AGONY converti au format thomson 8 couleurs. Dommage qu'on ait jamais eu un jeu avec d'aussi beaux graphismes sur to7

Surprenant pour un TO7
Les images de départ sont belles, mais l'algorithme de conversion ajoute un charme particulier. Le résultat est une oeuvre d'art digne des impressionnistes
Peut-on avoir une image disque pour l'essayer sur les vraies machines ?
Une question : avec 16 couleurs le résultat est-il meilleur ? Parce que, à part le TO7, les Thomson ont plus de 8 couleurs, c'est dommage de ne pas les utiliser.
Et encore bravo !

En 16couls ca rend beaucoup moins bien car l'algo utilise trop à mon goût les couleurs rose-orange qui font apparaitre un aspect grisatre sur l'image. Avec les 8 couleurs de bases, par contre les couleurs explosent et le contraste est bien mieux. Il faudrait que je poste un comparatif 2 par 2 pour voir. Quant à assembler tout ca sur D7... il faut que je trouve mes archives car je n'ai plus de PC en ce moment (je squatte pour le mail).. mais je vais voir ce qui est possible de faire. Stay tuned comme ils disent aux states

Bon voici les mêmes mais avec les 16 couls thomson. Je les trouve moins jolies:



Bon j'ai ressorti les archives, et grace à la vitualisation j'ai remonté une partie du PC avec les trucs thomson dans une machine virtuelle. Aussi j'ai pu faire un ZIP avec les fichiers MAP thomson 8 couleurs.

/!\ comme je n'ai pas de site de stockage permanent, les liens sont sur tinypic et cjoint, donc disparaitrons à échéance relativement courte (60 jours typiquement).

Oui et non ... On gagne en piqué ce qu'on perd en couleur et vice-versa, je trouve les images en 16 couleurs moins precises colorimetriquement mais certains details apparaissent nettement mieux.

C'est toujours le meme compromis.

La challenge suivant c'est d'animer les sprites

Blague a part, y'aurait-il quelque chose a faire de concret avec tout ca ? Ne serait-ce qu'un jeu d'aventure par exemple. J'ai toujours reve de porter des jeux type Bard's tale ou les Sierra sur thomson ...

Merci pour le fichier .sap
Effectivement les images en 16 couleurs paraissent moins précises, mais il est difficile de donner un jugement définitif.

Chiche? Qui se charge de porter SCUMM-VM sur thomson? Je sens que ca ne va pas être pour tout de suite. Il faudra sans doute un compilo C 32bits capable de gérer les banques mémoires de façon transparentes.

Il est possible qu'elles soient plus proche des originaux.. En tout cas je préfère les 8couls. Les images ont plus de pèche.

sam.

En tout cas de belles images comme ca en quelques ko c'est sympa. reste presque a trouver un algo de compression efficace pour faire encore mieux.

Tu pourrais poster la mem forme et la mem couleur d'1 ou 2 images pour voir ce que ca donne ?

J'ai lu LZ77 et je pense qu'il doit facilement se porter sur 6809 (pour la décompression).


Image 1 (14Ko en MAP, 12Ko de GIF):


Image 2 (16Ko en MAP, 11Ko de GIF):


Notez que la taille du GIF et du MAP ne sont pas toujours en relation directe.

Remarque: dans l'algo je fais en sorte que l'une des couleur fond/forme soit préservée de la ligne précédente si cela n'influe pas l'erreur obtenue au groupe de 8pixels. Ceci explique que dans le bitmap du "fond", il y a des paquets de bits identiques d'une ligne sur l'autre (on voir apparaitre des lignes verticales).

Si on fait le XOR avec la ligne précédente, beaucoup de 0 apparaissent et cela peut être exploité avec un codage type HUFFMAN. En effet, les octets de la forme 00xxx000 sont beaucoup plus fréquents que les autres et ils pourraient être représenté sur un tout petit peu plus que 3 bits au lieu de 8. On gagnerait ainsi pas loin de 4Ko sur le plan forme.


sam (Et dire que c'est du simple FS... il faudra que je teste l'algo de Viktor dont je soupçonne qu'il évite les collisions de couleurs dans le même groupe de 8pixels du fait de la meilleure répartition spatiale).

Il y a en a deux autres tres interessants car concus pour des architectures 8 bits :

http://www.oberhumer.com/opensource/ucl/

et surtout:

http://hem.bredband.net/magli143/exo/

Je voulais porter le deuxieme (code assembleur z80 et 6502 fournis) mais vraiment pas le temps, tu t'y colles ? ou peut-etre un challenge pour prehisto ?

nb. si on porte cet algo, il deviendra une reference. en faisant mes recherches, j'ai vu pas mal de monde a la recherche d'un bon algo de compression sur 6809 et exomizer est deja pas mal connu sur z80 et 6502.

Ben pareil de mon coté.. j'ai des trucs sur le feu que j'aimerais sortir à la mi-juillet... Normalement c'est cool car je vais partir en congés et donc avoir du temps. Hélas voilà que je me retrouve sans machine pour poursuivre mon devel 6809 Je squatte celle du TAF avec une VM à l'intérieure, mais je ne pourrais pas l’emmener avec moi en congé. Scrogneugneu!

Une chose est sure, comme j'aimerais que le truc que je sors marche aussi sur K7 qui sont très très lentes sur TO7 (900bauds, 100octets/sec, 6ko/min, une image met 3mins... beurk!). Aussi un compresseur d'exe réduirait considérablement le temps de chargement.

As tu une idée de l'algo utilisé par EXOMIZER? J'ai regardé le site web et il n'y a pas d'explication technique sur la compression utilisée.

EDIT Bon j'ai trouvé ici des infos importantesLe dernier point est important surtout pour les graphismes où les mêmes blocs (et non les segments) sont répétés consécutivement. L'exemple typique sont les images avec un tramage "ordered", en RLE la compression est nulle, mais par blocs ca marche bien mieux. Cette propriété commune aux algos LZ77 inclue et surpasse le RLE souvent utilisé sur les petits CPU, et le plus de l'EXOMIZER est qu'il cherche un équilibre entre l'offset et la répétition ce qui est important: combien de bits en arrière peut-on aller chercher un motif, combien de fois peut-on le répéter, quelle option favoriser, etc. A priori EXOMIZER c'est du "tout bon".

Helas c'est le gros point noir des K7 sur TO7. Sur MO5, on pourrait faire des super algos tres rapides.

sinon, idee geniale mais contre-nature, utiliser un lecteur MO5 sur TO7, ca marcherait. ca permettrait de s'affranchir du codage 900 bauds. Les puristes risquent de critiquer ... mais c'est un bel exercice de style.

Pour Exomizer, je crois que Prehisto aurait le talent necessaire pour convertir le code en assembleur 6502 en assembleur 6809.