Logicielsmoto.com

Nous sommes le 15 Oct 2019, 08:16

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 161 messages ]  Aller à la page Précédente  1, 2, 3, 4, 5, 6 ... 11  Suivante
Auteur Message
 Sujet du message:
MessagePosté: 29 Juil 2010, 13:46 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1112
Localisation: Brest
Tomix3 a écrit:
Une image de 192x100, c'est possible.


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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 29 Juil 2010, 14:15 
Hors ligne

Inscription: 27 Avr 2006, 09:04
Messages: 101
@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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message: Agony
MessagePosté: 14 Juin 2011, 00:11 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1112
Localisation: Brest
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 :sol:
Image Image Image Image Image Image Image Image Image Image Image Image Image Image Image


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 18 Juin 2011, 10:46 
Hors ligne
M. DCMOTO

Inscription: 06 Juin 2004, 08:23
Messages: 591
Localisation: Provence (France)
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 :bien:
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 !


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 18 Juin 2011, 12:40 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1112
Localisation: Brest
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 :)


Dernière édition par Samuel Devulder le 19 Juin 2011, 00:06, édité 2 fois.

Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 18 Juin 2011, 21:26 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1112
Localisation: Brest
Samuel Devulder a écrit:
Il faudrait que je poste un comparatif 2 par 2 pour voir.

Bon voici les mêmes mais avec les 16 couls thomson. Je les trouve moins jolies:
Image Image Image Image Image Image Image Image Image Image Image Image Image Image Image
Citation:
Quant à assembler tout ca sur D7...

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).


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 20 Juin 2011, 08:34 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 373
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 :lol:

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 ...


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 20 Juin 2011, 09:19 
Hors ligne
M. DCMOTO

Inscription: 06 Juin 2004, 08:23
Messages: 591
Localisation: Provence (France)
Merci pour le fichier .sap :cool:
Effectivement les images en 16 couleurs paraissent moins précises, mais il est difficile de donner un jugement définitif.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 20 Juin 2011, 09:21 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1112
Localisation: Brest
Fool-DupleX a écrit:
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 ...
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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 20 Juin 2011, 09:23 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1112
Localisation: Brest
Fool-DupleX a écrit:
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.
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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 20 Juin 2011, 12:52 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 373
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 ?


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 20 Juin 2011, 13:55 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1112
Localisation: Brest
Fool-DupleX a écrit:
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.

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

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

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

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

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.
Image

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).


Dernière édition par Samuel Devulder le 20 Juin 2011, 14:34, édité 2 fois.

Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 20 Juin 2011, 14:30 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 373
Samuel Devulder a écrit:
J'ai lu LZ77 et je pense qu'il doit facilement se porter sur 6809 (pour la décompression).

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.


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 20 Juin 2011, 18:14 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1112
Localisation: Brest
Fool-DupleX a écrit:
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 ?

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... :L 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 importantes
Citation:
Exomizer uses a variant of LZ77 and tries to calculate an optimal encoding of
the lengths and offsets.

It also allows lengts that are longer than the offsets in order to compress repeating patterns and rle-sequences.
Le 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".


Haut
 Profil  
Répondre en citant le message  
 Sujet du message:
MessagePosté: 21 Juin 2011, 08:21 
Hors ligne

Inscription: 06 Juin 2004, 08:23
Messages: 373
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.


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 161 messages ]  Aller à la page Précédente  1, 2, 3, 4, 5, 6 ... 11  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 3 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com