OBJET:

AVERTISSEMENT:

DISCLAIMER:

SOMMAIRE:

Design, car finalement la technique n'est pas très difficile à apprivoiser, et qu'après tout le résultat graphique et la beauté ou non de ce qui apparaît à l'écran dépend de plus de l'usage que l'on en fait. En d'autres termes, avoir des beaux graphismes dans ses programmes est surtout avoir un bon design graphique.

Motivation, car il ne faut pas hésiter à chercher longuement des nouvelles techniques, il ne faut pas avoir peur d'apprendre des nouvelles choses et en expérimenter pour chercher d'autres moyens de repousser les limites de vos programmes.

Si vous vous attendez à ce que ce texte vous donne un code source et qu'apres vous n'aurez plus qu'à faire un "affiche_image("mon_image"); ", passez votre chemin. Ce texte est ici pour ceux qui n'auront pas peur d'aller lobotomiser les registres du processeur pour voir ce qu'il pense quand vous jouez sans vergogne avec les interruptions du Bios. A ceux qui feront rebooter sans cesse leur machine parce qu'ils auront trop forcé la main sur une fonction obscure. A ceux qui créeront eux-mêmes des fonctions tellement puissantes qu'ils auront du mal à les faire avaler à la machine...

Bon, là je vois qu'il n'y a plus personne pour me lire... hey, revenez !

Tout ça ne veut pas dire être un dieu en assembleur... Il n'y a pas de rapport en fait. Ca veut tout simplement dire que vous êtes prêts à fournir l'effort nécessaire pour comprendre un domaine nouveau, en l'ocurrence le graphisme. L'Assembleur, sujet tabou, n'est là en réalité que pour mieux comprendre le fonctionnement interne du processeur. A long terme, vous pourrez vous en servir pour optimiser vos programmes, les faire tenir en moins de place et tourner plus vite. Mais cela va très en dehors du cadre de ce texte. Référez-vous à la bibliographie à la fin si vous voulez des livres sur le sujet. Mais à plus court terme, vous n'aurez à utiliser qu'episodiquement l'assembleur, et il est même possible de remplacer dans la plupart des cas les maigres fonctions en assembleur que vous verrez ici par du code en pur C... alors ne vous en faites pas. ça aboie mais ça ne mord pas.

En fait, le plus important est de voir comment marche le PC au niveau electronique, c'est à dire comment manipuler les interruptions du BIOS et quels Ports matériels appeller pour obtenir les informations que l'on cherche, ou l'effet désiré. Ce sont des choses que l'on voit très facilement quand on programme en Assembleur, et qu'il faut avoir en tête quand on programme du graphisme. D'où l'utilité de ne pas partir en courant à chaque fois que l'on entend le nom de ce complexe langage...
 

Tout le graphisme sur PC a vraiment décollé quand la carte VGA est sortie. Nommée "Versatile Graphics Adapter", elle permettait le mode standard 320*200*8, mais le plus important de cette carte (dont découlent toutes les cartes modernes, ce qui signifie qu'elles sont toutes compatibles avec celle-ci) est qu'elle est très facilement reprogrammable. Ce qui permet une myriade d'astuces intéressantes. On ne les abordera pas dans ce texte, on ne se tiendra qu'au standard, mais si vous voulez plus d'informations, cherchez sur le net des informations sur un mode graphique nommé "Mode X", qui a longtemps été utilisé pour des jeux, et reste encore tout à fait intéressant aujourd'hui. C'est un bon exemple des possibilités qu'offre un PC avec son Bios.

Dans le mode graphique 8 bits, on verra revenir parfois la notion de palette de couleurs. En fait, comme on ne dispose que de 256 couleurs, on ne pourrait à priori pas faire de belles images. Mais, et si on pouvait choisir ces 256 couleurs affichables simultanément parmi une myriade d'autres ? C'est ce que se sont dit les concepteurs de la carte VGA, et du coup, chaque couleur codée sur 8 bits fait référence à ce que l'on appelle un Registre de Palette.
A l'intérieur de la carte graphique, il existe un ensemble de registres qui contiennent les informations sur la palette. Chaque couleur est codée avec trois composantes, la Rouge, la Verte (Green) et la Bleue, qui peuvent avoir des valeurs allant de 0 à 63. Pour modifier la palette, il suffit de regarder dans le registre de palette, choisir une couleur, et modifier ses composantes. On peut donc ainsi avoir 256 nuances de bleu en même temps si l'on veut montrer une photo de la mer, ou avoir plus de choix de couleurs si la photo est plus complexe. On peut même faire des effets en faisant tourner les couleurs de la palette, mais ça, ce sera pour un autre texte.

Il ne reste plus qu'à indiquer, toujours avant l'appel de l'interruption, quel mode graphique on veut lancer. Dans notre cas, on veut le mode graphique 320*200*8, ce qui correspond à la valeur 13h. Cette valeur a été choisie par les concepteurs du BIOS, pour connaitre les autres valeurs, il faut se réferer à une liste d'interruptions.

Si vous avez tout suivi depuis le début, vous remarquerez pourquoi le mode 320*200*8 s'appelle le mode 13h. On placera cette valeur dans le registre AL.
 

Et voilà, nous sommes en mode graphique !  Simple, non ?

D'accord, on ne voit rien, mais c'est parce qu'on n'a pas encore dessiné quoi que ce soit... Tout d'abord, il vaudrait mieux se soucier de  comment revenir au mode texte, parce que sinon, ça va faire désordre: on reviendrait sous DOS avec le mode VGA... si ça vous arrive, tapez la commande DOS "mode co80" pour revenir au mode texte normal.
 
Pour revenir proprement au mode texte, on utilisera le mode 3h, ce qui correspond au mode texte en 80x25 colonnes en 16 couleurs. Sinon, c'est exactement la même fonction, il suffit de remplacer la deuxième instruction par:
 

Pour clore ce chapitre, je signale juste qu'il existe une fonction en C et C++ qui permet l'appel à une interruption, cette fonction se nomme int86() sur le Borland C++. Pour les autres compilateurs, il faut chercher. Mais en tous cas elles existent et ça vous évite d'avoir à mettre de l'assembleur dans vos programmes. Ce qui est surtout utile pour ceux qui y sont allergiques.
 
Récapitulons: il suffit d'appeller l'interruption 10h, fonction 0h (dans AH) et ensuite 13h (dans AL) pour le mode graphique ou 03h (dans AL) pour le mode texte.
 
 

Comme chaque ligne horizontale dispose de 320 pixels, il suffit de multiplier 320*Y. Ensuite il suffit d'ajouter la valeur de X pour obtenir l'emplacement du tableau à écrire:
 

for(i=X1,i<=X2,i++)
  { video_buffer[320*Y+i]=couleur;
  }

Pour faire un rectangle, il suffit de répeter le dessin de ligne horizontale plusieurs fois... A vous de voir comment faire les triangles, les cercles, et le remplissage. Cherchez des documents, ce n'est pas si dur...
 
 

On peut "jeter" les premiers 128 octets:
 

 while(compteur<=64000)
          { data=(unsigned char)getc(imagePCX);
            if ( data>=192 )
              { nombre_octets=data-192;
                data=(unsigned char)getc(image);
                while(nombre_octets-- > 0)
                  { image_en_memoire[compteur++]=data;
                  }
              }
            else
              { image_en_memoire[compteur++]=data;
              }
         }

Maintenant il suffira de copier le contenu de image_en_memoire à l'écran. Mais avant cela, il va falloir décoder la palette de l'image, parce que sinon les couleurs à l'écran seront faussées. En d'autres termes, il faut que les couleurs de l'écran soient les mêmes que celles qui composent l'image, pour des raisons évidentes de cohérence... à quoi ça servirait de faire des belles images sinon ?
 
Tout d'abord, on ira à la fin du fichier PCX où sont situés les informations de palette. Ces informations sont codées sur trois octets par couleurs, chaque représentant une composante RGB de la couleur. Dans le mode 8 bits (8 bpp), ces octets ont des valeurs allant de 0 à 63.
 
On doit donc aller à la fin du fichier moins (256*3)=768 octets.
 

Pour se simplifier la vie dans la manipulation des couleurs, il convient de créer une structure de données qui contiendra les informations de chaque couleur. On appellera cette structure couleur_RGB et on en mettra 256 dans un tableau que l'on nommera palette.

typedef struct { unsigned char red;     // Composante rouge  (0-63)
                 unsigned char green;   // Composante verte  (0-63)
                 unsigned char blue;    // Composante blueue (0-63)
               } couleur_RGB;

couleur_RGB palette[256];

Une fois que l'on a défini cette structure de données, récuperer les informations de l'image devient très simple (n'oubliez pas le fseek cité plus haut).

for(index=0;index<256;index++)
  { palette[index].red   = (unsigned char)(getc(imagePCX) >> 2 );
    palette[index].green = (unsigned char)(getc(imagePCX) >> 2 );
    palette[index].blue  = (unsigned char)(getc(imagePCX) >> 2 );
  }

Une fois que l'on a fini avec l'image PCX, n'oubliez pas de faire le ménage en mémoire:

fclose(imagePCX);
imagePCX=NULL;

Il ne nous reste plus qu'à mettre les informations de la palette dans la carte graphique. C'est une petite technique assez particulière qui merite quelques expliquations, mais une fois que vous l'aurez comprise, vous devriez être capable de vous en servir facilement.

On utilisera ce que l'on appelle des Port Calls, des appels à ports matériels du PC. Dans le cas qui nous concerne, on utilisera deux ports de la carte graphique (j'en inclus un troisième pour les raisons que vous verrez un peu plus bas).  Pour cela, on utilise les commandes C outp et inp (qui existent aussi en assembleur), en appellant le port pour lire ou écrire une valeur.
 
Pour écrire la valeur des trois composantes, il suffit en fait de faire deux pas très simples:
 
1. On ecrit la valeur de la couleur à modifier dans le port "Ecriture couleur"
2. On écrit à la suite les valeurs R, G, et B dans le port "Données Couleur"
 
Le fait d'écrire quoi que ce soit dans le port "écriture couleur" indique à la carte graphique que la couleur entrée va recevoir trois valeurs consécutivement, qu'il faudra placer dans les registres R, G et B de la couleur.
 
Pour vous faciliter la tâche et ne pas avoir à cherche les valeurs des ports à chaque fois, il vaut mieux en faire des DEFINE au début du programme, comme suit:
 
#define LIRE_REGISTRE_COULEURS   0x3C7
#define ECRIRE_REGISTRE_COULEURS 0x3C8
#define DATA_COULEUR             0x3C9
 
J'ai volontairement inclus le port "lecture couleur", qui marche de manière inverse: c'est à dire on y met la valeur de la couleur à lire et ensuite on lit trois fois dans "donnees couleur" pour avoir les trois composantes. Ces trois ports devraient vous permettre de manipuler à votre aise les palettes et de faire des effets déments.
 
Mais revenons à notre cas. Pour écrire la palette de couleurs dans les registres de carte graphique, il suffit de faire:
 
      for(index=0; index<256; index++)
        { outp(ECRIRE_REGISTRE_COULEURS, index);
          outp(DATA_COULEUR, palette[index].red  );
          outp(DATA_COULEUR, palette[index].green);
          outp(DATA_COULEUR, palette[index].blue );
        }
 
Pour lire à partir de la carte, c'est la même chose mais avec "inp". L'autre interêt de faire un tableau "palette", est que l'on peut créer plusieurs et ainsi faire des jeux de couleurs dans le programme... Expérimentez un peu et vous verrez que ça peut être impressionnant.
 
Vous pouvez aussi découper vos images pour en faire des sprites, ou mettre plusieurs images dans la même... toutes les portes vous sont ouvertes... mais le principal est fait, vous voilà avec une image à l'écran ! Le monde est beau, non ?
 

Mais ce n'est pas très beau... on ne dispose que d'une seule police de caractères. Une solution, qui ne sera pas détaillée ici (mais rien ne vous empêche de chercher par vous mêmes, au contraire) consiste à prendre des caractères à partir d'une image PCX, que vous découperez en morceaux pour stocker dans un tableau. Ce tableau sera une sorte de table ascii, et vous construirez des fonctions de sorte que la chaine "Salut !" apparaisse à l'écran avec un seul appel de fonction: elle prendra chaque caractère de la chaîne et imprimera l'image correspondante.

Suivant cet exemple, des tonnes de possibilités existent:

Vous pouvez gérer la souris et lui doter un pointeur graphique.
Vous pouvez calculer une table de sinus puis générer un déplacement d'images suivant les courbes, pour obtenir des animations du plus bel effet.
Vous pouvez fabriquer une structure de données qui gérera plusieurs images pour un même objet et ainsi créer ce que l'on appelle un sprite (lutin), un objet animé que vous pouvez déplacer à l'écran.
Vous pouvez gérer des gros fichiers d'animation en prenant connaissance de la structure du fichier et en affichant image par image le fichier à l'écran.
Vous pouvez aussi vous lancer dans le calcul et affichage d'objets 3D texturée en temps réel avec gestion des effets de lumière, mais là je prends l'exemple extrême. :-)
 
 

Les compilateurs du CRIO Inter-UFR suffisent amplement pour l'appliquation des notions ici abordées, mais il existe des compilateurs beaucoup plus puissants et gratuits:

1. DJGPP: compilateur C/C++ 32 bits freeware pour DOS, Windows et Linux.                     ( disponible sur http://www.delorie.com )

2. NASM: Netwide Assembler, assembleur freeware pour DJGPP. ( disponible sur: http://www.cryogen.com/Nasm )

3. HelpPC: Petit utilitaire assez ancien mais qui recense beaucoup d'interruptions du BIOS, de fonctions C, des commandes Assembleur, et d'autres trucs sur les entrailles de nos PCs ( disponible dans de nombreuses de pages web, me le demander sinon )

1. N'importe quel livre de C et de C++.
2. La bible PC: programmation système, Michael Tischer.
3. Programmer en Assembleur sur PC, Holger Schakel.

1. Zen of Graphics Programming, par Michael Abrash.
2. Black Art of 3D Game Programming, par André Lamothe.
3. Zen of Code Optimisation, par Michael Abrash.
4. Master Class: Assembly Language, par Wrox Press.

Il existe des ouvrages encore plus avancés, où sont abordés par exemple la programmation 3d par une approche mathématique. Mais c'est plutôt destiné à d'autres type de programmeurs... ceux qui programment des logiciels comme Adobe Photoshop... ça reste intéressant, mais ça va un peu trop loin. A chacun de voir.
 
 

Tout d'abord Xavier Vu-Van-Xung qui m'a donné l'idée de taper ce texte.  J'ai aimé l'idée et je m'y suis lancé... comme d'habitude j'ai écrit un peu trop, mais considérez ceci comme un petit livre. J'espère que ça vous servira, et surtout que vous mettrez à contribution tout ce que vous aurez appris.
 
Ensuite je voudrais remercier M. Bernard Quément, professeur d'Algorithmique, qui m'a fait découvrir et comprendre le fabuleux langage qu'est le C et le C++. Avant d'assister à ses cours, je ne savais même pas ce qu'était un pointeur ou un héritage de classes...
 
Je continue par M. Marc Csernel, et ses cours d'assembleur, qui m'ont permis d'approfondir mes connaissances dans ce langage difficile, et dont le dernier TD m'a permis de developper les bases de ce qui ensuite allaient être les techniques ici utilisées...
 
Ainsi, bien entendu, qu'à tous ceux qui m'ont lu et qui me connaissent en Miage. Notamment à tous ceux qui se sont intéressés au graphisme et n'ont pas hésité (et n'hésiteront pas, je suppose) à me poser des questions sur le sujet.
 
Plus généralement, je voudrais remercier Michael Abrash pour ses fantastiques ouvrages, ainsi qu'André Lamothe pour les conseils qu'ils prodigue dans son livre. Je dois aussi beaucoup à Diana Gruber qui m'a appris à voir comment marche un jeu vidéo et les implications sur la programmation.
 
Un petit coucou à tous les membres de mon demogroup, à savoir Fahruz et Mad Process (un jour, oui, un jour, on sortira une démo ! yay !), ainsi qu'à tous les autres demomakers que je connais... surtout Light Show/Eclipse, Random/Lithium et Roudoudou/Flower Corp qui m'ont appris quelques astuces en Assembleur lors de la Wired '97. Finalement, un gigantesque "Arf!" à tous les membres de Arf!Studios.