outil de dessin Orixel en développement

ici un exemple de dessin réalisé à l'aide d'ORIXEL:

Je ne sais pas ce que vaut l'outil (il a l'air puissant) En tout cas toi, tu sembles un trés bon dessinateur   

Le gros problème de l'oric, c'est la taille de la mémoire vive.
Je suis en train d'analyser une routine de décompactage de paramètres graphiques utilisée dans un jeu de la belle époque de l'oric.
L'auteur a pris le parti de ne dessiner qu'en utilisant l'ordre CURSET. (au détriment de draw, circle, curmov,...)et en stockant uniquement les différences de coordonnées entre deux points consécutifs
Bien sûr ce choix est surtout pertinent pour les dessins plutot "curvilignes" (avec peu de lignes toute droites) Exactement comme l'exemple que tu as posté ci dessus.
Cette methode permet de compacter d'un facteur 4 environ la taille des données nécessaires au dessin.

Dans le jeu évidemment, il n'y a que la routine de décompactage des données. Je me demandais si tu serais intéressé par le fait d'ajouter une option à ton programme qui permettrait de générer ce type de données.

Si oui, je t'enverrais la routine de décompactage commentée (en assembleur) pour que tu comprennes mieux ce que j'essaie de dire   

Dom50 a écrit:Le gros problème de l'oric, c'est la taille de la mémoire vive.
Je suis en train d'analyser une routine de décompactage de paramètres graphiques utilisée dans un jeu de la belle époque de l'oric.
L'auteur a pris le parti de ne dessiner qu'en utilisant l'ordre CURSET. (au détriment de draw, circle, curmov,...)et en stockant uniquement les différences de coordonnées entre deux points consécutifs
Bien sûr ce choix est surtout pertinent pour les dessins plutot "curvilignes" (avec peu de lignes toute droites) Exactement comme l'exemple que tu as posté ci dessus.
Cette methode permet de compacter d'un facteur 4 environ la taille des données nécessaires au dessin.

Dans le jeu évidemment, il n'y a que la routine de décompactage des données. Je me demandais si tu serais intéressé par le fait d'ajouter une option à ton programme qui permettrait de générer ce type de données.

Si oui, je t'enverrais la routine de décompactage commentée (en assembleur) pour que tu comprennes mieux ce que j'essaie de dire   

Oui ce serait intéressant, j'avais pensé à ça.
Je connais la routine de compression simple dont le principe est le suivant:
tant que l'on rencontre le même octet on incrémente un compteur jusqu’à ce que l'on rencontre un octet différent. A ce moment on stock l'octet répété et le compteur (2 octets) puis on recommence. Cet algorithme et intéressant lorsque que l'on a beaucoup de lignes horizontales.

Gweg a écrit:Cet algorithme et intéressant lorsque que l'on a beaucoup de lignes horizontales.

c'est vrai, en fonction du type de dessin l'algorithme le plus efficace change.
Pour les lignes droites, qui peuvent être déssinées par un DRAW, la méthode dont tu parles est meilleure.
 
Pour les lignes courbes, l'agorithme auquel je faisais allusion est différent. De ce que j'en ai compris, il s'agit de réaliser le dessin uniquement avec des instructions CURSET. Entre deux pixels sur l'écran, il ne peut y avoir, sur chaque axe, X et Y, que trois possibilités. Pour X : à gauche, à droite ou au même endroit (-1,0,+1). Pour Y, au dessus, au dessous, ou au même endroit (-1,0,+1)
Constantant que chacune de ces trois valeurs peut être codée sur 2 bits ( 00, 01, 11) Pour 0 et 1 c'est immédiat. Moins un est codé 11 (3) par convention.
 
Résultat, sur un octet (8 bits) on peu coder la position de 2 pixels ( 2 x 4 bits ) avec 4bits par pixel, 2 pour le décalge sur les X et 2 pour le décalage sur les Y.
 
Tout cela fonctionne tant qu'on ne "lève pas le crayon" . Dans ce cas, un octet nul dans les données signale que les deux octets suivants sont des coordonnées X,Y "complètes" pour démarrer un nouveau "trait continu" de pixels toujours grâce à l'instruction CURSET.
 
Grossièrement, 2 pixels par octet au lieu de deux octets par pixel, cela fait un facteur 4 de compression (en négligeant les levées de crayon)

Dom50 a écrit:

Gweg a écrit:Cet algorithme et intéressant lorsque que l'on a beaucoup de lignes horizontales.

c'est vrai, en fonction du type de dessin l'algorithme le plus efficace change.
Pour les lignes droites, qui peuvent être déssinées par un DRAW, la méthode dont tu parles est meilleure.
 
Pour les lignes courbes, l'agorithme auquel je faisais allusion est différent. De ce que j'en ai compris, il s'agit de réaliser le dessin uniquement avec des instructions CURSET. Entre deux pixels sur l'écran, il ne peut y avoir, sur chaque axe, X et Y, que trois possibilités. Pour X : à gauche, à droite ou au même endroit (-1,0,+1). Pour Y, au dessus, au dessous, ou au même endroit (-1,0,+1)
Constantant que chacune de ces trois valeurs peut être codée sur 2 bits ( 00, 01, 11) Pour 0 et 1 c'est immédiat. Moins un est codé 11 (3) par convention.
 
Résultat, sur un octet (8 bits) on peu coder la position de 2 pixels ( 2 x 4 bits ) avec 4bits par pixel, 2 pour le décalge sur les X et 2 pour le décalage sur les Y.
 
Tout cela fonctionne tant qu'on ne "lève pas le crayon" . Dans ce cas, un octet nul dans les données signale que les deux octets suivants sont des coordonnées X,Y "complètes" pour démarrer un nouveau "trait continu" de pixels toujours grâce à l'instruction CURSET.
 
Grossièrement, 2 pixels par octet au lieu de deux octets par pixel, cela fait un facteur 4 de compression (en négligeant les levées de crayon)

Hello !
je suis désolé mais je n'ai pas bien compris ton algorithme, aurais tu un lien vers une page web qui l'explique ou une vidéo ?

Si j'ai bien compris le principe, on ne prend en compte que le déplacement relatif entre 2 points, un peu comme un CURMOV sur une distance maximale de 1 point à chaque fois.

Le dernier point tracé est au centre dans le tableau suivant, chaque case indique les valeurs à ajouter à x et y pour atteindre la case en question.

x-1 y-1	x+0, y-1	x+1, y-1
x-1, y+0	0	x+1, y+0
x-1, y+1	x+0, y+1	x+1, y+1

Exemple, pour aller vers la case ligne 1, colonne 3: il faut ajouter 1 à x et -1 à y

Si les valeurs -1, 0, +1 sont codées sur 2 bits par 11, 00, 01, le tableau devient:

11 11	00 11	01 11
11 00	x	01 00
11 01	00 01	01 01

Et on recommence à partir du nouveau point tracé.

Comme un octet contient 8 bits, on peut coder 2 points par octet au lieu d'utiliser 2 fois 2 octets pour le même résultat.
Si il faut "lever le crayon", il suffit de mettre un octet nul suivi de 2 octets contenant les coordonnées du prochain point de référence.

C'est ça, en beaucoup plus clair   
Merci assinie.

Merci assinie , je trouve ton explication parfaite ! , du coup bien j'ai compris
Aurais tu le nom de cet algorithme ? afin que je puisse trouver des sources à ce sujet.

Mise en ligne de la release alpha 0.4 de l'outil de dessin ORIXEL ! :

http://rari.free.fr/ORIXEL/

nouveauté :

- fonctions Load et Save au format Orixel (Binaire)

en cours d'amélioration :

- fonction FILL . comporte encore de nombreux bugs   

futures intégrations possibles :   

- police d'Oric
- fonction Polygone rempli
- fonction capture & animation de sprite vers fichier binaire Oric.  

enfin je suis preneur d'infos sur la structure d'un fichier TAP

Le format d'un fichier .tap n'a rien de bien compliqué:

[0x16] [0x16] [0x16] [0x16] [0x24] [0xff] [0xff] [type] [fAutostart] [adresse de fin] [adresse de debut] [??] [nom du fichier] [0x00] [données...]

Les 0x16 servent pour la syncho (au moins 3)
Le 0x24 indique le début de l'entête.
Les 2 octets mis à 0xff ici ne sont utilisés que par l'Atmos pour indiquer le type de tableau sauvegardé par la commande STORE.

Pour le type de fichier:
0x00 : BASIC
0x40 : Array
0x80 : Data (programme en langage machine par exemple)

Pour l'autostart:
0x00 : Pas d'autostart

L'octet [??] est inutilisé, sa valeur n'a pas d'importance.

Seuls les 16 premiers caractères du nom du fichier sont pris en compte (même si le ROM 1.0 ne tronque pas le nom lors du CSAVE contrairement à la v1.1).

ATTENTION:

1. Les adresses de début et de fin sont indiquées avec le poids fort en premier (ie 0x0501 => 05 01 et non 01 05 comme il est de coutume pour le 6502).
   
2. Pour les programmes BASIC, il faut ajouter un octet à la fin de fichier pour que la routine CLOAD puisse mettre correctement à jour les pointeurs de variables.
   

assinie a écrit:Le format d'un fichier .tap n'a rien de bien compliqué:

[0x16] [0x16] [0x16] [0x16] [0x24] [0xff] [0xff] [type] [fAutostart] [adresse de fin] [adresse de debut] [??] [nom du fichier] [0x00] [données...]

Les 0x16 servent pour la syncho (au moins 3)
Le 0x24 indique le début de l'entête.
Les 2 octets mis à 0xff ici ne sont utilisés que par l'Atmos pour indiquer le type de tableau sauvegardé par la commande STORE.

Pour le type de fichier:
0x00 : BASIC
0x40 : Array
0x80 : Data (programme en langage machine par exemple)

Pour l'autostart:
0x00 : Pas d'autostart

L'octet [??] est inutilisé, sa valeur n'a pas d'importance.

Seuls les 16 premiers caractères du nom du fichier sont pris en compte (même si le ROM 1.0 ne tronque pas le nom lors du CSAVE contrairement à la v1.1).

ATTENTION:

1. Les adresses de début et de fin sont indiquées avec le poids fort en premier (ie 0x0501 => 05 01 et non 01 05 comme il est de coutume pour le 6502).
   
2. Pour les programmes BASIC, il faut ajouter un octet à la fin de fichier pour que la routine CLOAD puisse mettre correctement à jour les pointeurs de variables.
   

Merci Assinie ! effectivement ça n'a pas l'air très compliqué.
Je vais pouvoir intégrer la possibilité de sauvegarder le code Basic directement dans un fichier TAP !

Le mieux pour ça c'est de s'inspirer du code de bas2tap :
http://miniserve.defence-force.org/svn/public/pc/tools/osdk/main/bas2tap/sources/bas2tap.cpp

C'est en C mais pas très compliqué à comprendre.

Hialmar a écrit:Le mieux pour ça c'est de s'inspirer du code de bas2tap :
http://miniserve.defence-force.org/svn/public/pc/tools/osdk/main/bas2tap/sources/bas2tap.cpp

C'est en C mais pas très compliqué à comprendre.

Merci avec ça y a plus de secret sur le sujet !  

Je suis en train de corriger les problèmes relatifs à la simulation d'affichage de la fonction FILL dans l'outil ORIXEL.
Voici un exemple d'utilisation de FILL. Je découvre en même temps les possibilités de cette commande.


Dommage que les concepteur de l'Oric n'ont pas fait aussi bien que pour le ZX Spectrum qui a un système de couleur très proche de celui de l'Oric mais qui apparemment ne condamne pas les octets bloqués du contrôleur vidéo.



Enfin je ne dois pas avoir tout compris encore lorsque je vois les graphismes de Stormlord qui ressemblent beaucoup à ceux du ZX Spectrum. Il semble qu'il a pu passer outre les octets bloqués non !! ???   

Absolument pas. Il n'y a pas de trucs. Si tu faisait une copie d'écran et observait les pixels, tu trouverais les octets bloqués par les attributs.
Pour Stormlord comme pour tous ses programmes, Jonathan raffinait au plus haut point ses graphismes.
Du pixel art à l'état pur.

De mon coté, je crois que je vais devoir attendre les vacances pour avancer. Pas le temps avec le boulot et le mag en ce moment.

didierv a écrit:Absolument pas. Il n'y a pas de trucs. Si tu faisait une copie d'écran et observait les pixels, tu trouverais les octets bloqués par les attributs.
Pour Stormlord comme pour tous ses programmes, Jonathan raffinait au plus haut point ses graphismes.
Du pixel art à l'état pur.

De mon coté, je crois que je vais devoir attendre les vacances pour avancer. Pas le temps avec le boulot et le mag en ce moment.

Dans Stormlord je ne vois pas comment il a pu aligner la série de couleurs suivantes sans bloquer un octet d'attribut tout en noir devant ?  je crois que ne j'ai pas tout compris au codage des couleurs !! :o

Quand on voit 12 pixels consecutifs avec 4 couleurs différentes (donc deux octets avec six pixels visibles) on remarquera le fait que les deux premières couleurs sont les "opposées" aux deux suivantes. Donc le deuxième octet est en "couleurs inversées", il n'est pas nécessaire de refaire appel à un octet d'attribut pour celà, mais celà réduit les possibilités de compression de fichiers HIRES (bon là je m"égare  ). Ce qui donne cette impression de passer outre les règles d'attributs, mais en fait, les contraintes du vidéoprocesseur sont incontournables, on ne peut pas choisir la couleur de chaque pixel comme on veut, par contre avec le jeu des inversions de couleurs on peut faire illusion... 

Dans l exemple graphique que tu proposes on a en début de ligne:
1 attribut "fond noir" non inversé (s affiche en noir et demande du noir pour le fond qui suit)
1 attribut "texte bleu clair" non inversé (s affiche en noir et demande la colorisation des pixels a "1" suivants en bleu clair)

Ensuite en "visible"

1 motif non inversé, donc fond noir et pixel bleu clair
1 motif inversé, donc fond blanc et pixel rouge
1 motif non inversé, fond noir et pixel bleu clair.

Paper 0
Ink 6
soit les 6 premiers points en noir et cyan
puis inversé soit paper blanc et ink rouge pour les points suivants
puis retour en paper 0 et ink 6 pour un octet normal.

(je confirme donc - j'avais pas vu - l'explication de kenneth)

Jonathan avait fait des tas d'essais afin de controler les mélanges de couleurs. Dans certains cas, les écarts s'estompent et deviennent peu visibles d'ou la sensation de couleurs multiples.

didierv a écrit:
Paper 0
Ink 6
soit les 6 premiers points en noir et cyan
puis inversé soit paper blanc et ink rouge pour les points suivants
puis retour en paper 0 et ink 6 pour un octet normal.

(je confirme donc - j'avais pas vu - l'explication de kenneth)

Jonathan avait fait des tas d'essais afin de controler les mélanges de couleurs. Dans certains cas, les écarts s'estompent et deviennent peu visibles d'ou la sensation de couleurs multiples.

ça mettrait donc ces 3 octets aux valeurs suivantes ?
(+ un octet encre CYAN devant ces trois octets pour définir la couleur INK )

[(0,0),0,0,0,1,1,0][(0,1),0,1,0,1,0,1] [(1,1),0,1,0,1,1,1] [(0,1),1,0,1,0,0,0] ?
[FILL 6][ 3 pixels][ 4 pixels inversés ][2 pixels]

pour reproduire ces quelques pixels de Stormlord, ça donnerait les pokes suivants :

Code:

 
10 HIRES                            
20 POKE 48000,6    ' encre CYAN                  
30 POKE 48001,85                    
40 POKE 48002,215                    
50 POKE 48003,104                                                    


intéressant si on peut inverser les couleurs, dans les couleurs opposées c'est bien ça ?

a tester sur un oric ou un emulateur, je ne pense pas que l'octet à 0 pour le fond soit indispensable.

Sinon, je pense que tu es clair maintenant pour les couleurs.
Le bit d'inversion permet d'associer les couleurs complémentaires sur un octet tant pour le papier que pour l'encre.
Didier

En 2010 j'avais interviewé Jonathan pour Stormlord. Il m'avait envoyé une bafouille sur son système de couleurs, que je reproduis ici (j'ai le droit, j'ai signé l'article )

"La technique graphique utilisée dans Pulsoids, Stormlord, le tableau des scores de 1337 et Mission Impossible, et probablement tous les futurs jeux, utilise une nouvelle technique graphique très simple qui permet de supprimer la plupart des problèmes d'attribut des précédents jeux Oric.
Le premier qui a utilisé cette technique a été Pulsoids. J'ai compris que, si je voulais avoir de la couleur, je devais créer un terrain de jeu qui ne souffre pas des conflits d’attributs classiques de la plupart des jeux précédents.
Donc la première étape était d'utiliser le bit inverse. En HIRES cela permet d’utiliser un seul octet pour afficher la logique inverse des attributs encre et papier de l’écran actuel. Mais pour une seule ligne cela veut dire seulement deux couleurs de plus. Avec une ligne dont l'encre et le papier sont noir et cyan, la logique inverse est rouge sur blanc.
Cependant, j'ai découvert qu’au lieu d'utiliser les mêmes papier et encre sur chaque ligne, en alternant entre le cyan et (disons) jaune, j'ai presque toutes les couleurs, bien qu’un peu limitées par les changements d’octets. Mais c'est là l'atout majeur de la création graphique, sur la conversion d’image. En le recréant, vous avez l’avantage de pouvoir adapter le dessin à ces contraintes de couleur plutôt que de devoir ajouter des couleurs à un dessin directement converti ne tenant pas compte des contraintes graphiques de l’Oric.

Ainsi, l’Oric initialise un papier noir et une encre blanche (pour utiliser tout l’écran) et avec Stormlord je définis simplement, en première colonne, une alternance avec une ligne de cyan et une de jaune.

Donc un seul octet sur chaque ligne impaire peut produire cyan sur noir ou, inversé, rouge sur blanc. Et un seul octet sur une ligne paire peut produire jaune sur noir ou, inversé, bleu sur blanc. Cela offre 6 couleurs. Les couleurs manquantes sont le magenta et le vert. Mélanger cyan et jaune crée un vert moucheté, et mélanger rouge et bleu crée un magenta sur une grande surface.

Maintenant tracer des sprites sur un fond coloré n'est pas tout à fait un jeu d'enfant, mais beaucoup moins pénible qu’en ayant des attributs couleur à traiter.
On doit se définir quelques règles. Par exemple si le fond est bleu et que le sprite contient du noir alors ne pas supprimer l'arrière-plan, mais le faire si le fond est rouge. En effet, à l'œil nu le bleu est moins visible que le rouge."

Mise en ligne de la version 0.5 de l'outil ORIXEL

nouveautés :

-amélioration de la gestion de la couleur (commande FILL). Nécessite l'utilisation de l'icône 'Redraw' pour voir l'affichage réel.
-fonction de dessin de TEXT (CHAR)
-modif de la grille d'aide aux tracés de la couleur (FILL)

download : http://rari.free.fr/ORIXEL/

Superbe !

Merci.

Désolé de ne pas avoir donné de nouvelles d'Orixel depuis longtemps mais je suis en train de refaire complètement son algorithme de dessin/écran car il y a trop de bugs. Je vais devoir faire une sorte d'émulateur du système d'affichage d'Oric pour avoir un résultat optimal et ça va me pendre plus de temps que tout ce que j'ai déjà passé sur cet outil :x  

wait and see !

Gweg