DP Tool Club 9/CD_ASCQ_09_1193.iso/news/557/animate/animage.txt

Text File | 1993-09-03 | 27KB | 443 lines

┌───────────────────────────────────────────────────────────────────────────┐
│ ANIMAGE: Unité pour Turbo Pascal permettant d'animer des sprites, de faire│
│          des scrolls, zooms, cyclages, splits, en VGA 256 couleurs.       │
│                                                                           │
│ Info...: Ce package est un produit shareware qui ne doit pas être modifié.│
│          Si vous en obtenez  entière satisfaction  ou si vous  l'utilisez │
│          souvent, effectuez donc votre contrat moral en envoyant un chèque│
│          de 50FF (vous recevrez une licence d'utilisation) à l'adresse:   │
│                                                                           │
│          Patrick RUELLE                                                   │
│          163 rue de Charonne                                              │
│          75011 Paris                                                      │
│          (France)                                                         │
│                                                                           │
│ CE FICHIER CONTIENT DES INFOS GENERALES SUR LES TECHNIQUES D'ANIMATION ET │
│ EGALEMENT LES INFOS DETAILLEES SUR LES CONSTITUANTS DE L'UNITE "ANIMAGE". │
└───────────────────────────────────────────────────────────────────────────┘



1 INTRODUCTION

        Voici un domaine qui demeure encore quelque peu fermé, aussi bien
  parce que l'information n'est pas toujours facile à trouver soi-même que
  par le fait que de nombreux programmeurs pratiquant ce type de technique
  préfèrent conserver leurs découvertes à l'abri des nombreux intéressés. Cet
  article est très loin d'être exhaustif et n'a pour unique prétention que
  d'expliquer le plus simplement du monde (du moins je l'espère!) certaines
  techniques fondamentales d'animation graphique.



2 PRINCIPES

  a) LA CARTE VGA

        Tout d'abord, il faut savoir qu'une carte VGA est constituée de
  plusieurs éléments: des registres généraux, le contrôleur CRT (Cathode Ray
  Tube), le séquenceur, le contrôleur d'attributs et le DAC (Digital/
  Analogic Converter). Parmi les registres généraux on peut d'ailleurs
  trouver le registre 3DAh contenant des informations sur la VBL ou la HBL.
  Le contrôleur CRT (25 registres) a par contre la difficile tâche de
  configurer convenablement l'écran selon les modes graphiques utilisés. Le
  séquenceur (5 registres) permet de convertir les accès à la RAM vidéo en
  les dirigeant vers les bons plans de bits; le rafraîssement de la RAM vidéo
  fait également partie de son travail. Puis, finalement le DAC qui convertit
  les codes couleur digitaux en signaux analogiques. Que peut-on trouver
  d'autre? Et bien, de la RAM vidéo, et ce de 256Ko jusqu'à généralement 1 ou
  2Mo, voire plus.


  b) LES ANIMATIONS : GENERALITES

        Le PC a souvent été l'enfant pauvre en matière d'animation
  (surtout face à des concurrents comme l'Amiga ou l'Atari). Cependant, ce
  handicap tend un petit peu moins à se remarquer grâce à l'avènement de
  cartes graphiques assez performantes et de PC puissants (malgré certains
  goulots d'étranglement...). Imaginons par exemple le déplacement d'un
  petit bonhomme sur un écran. Qu'est-ce qui crée l'illusion de l'animation?
  Et bien, exactement le même phénomène que l'on retrouve lors de la
  projection d'un film cinématographique. Différentes étapes d'animation du
  petit bonhomme sont en fait affichées successivement (et suffisamment
  rapidement) afin de créer l'illusion du mouvement.

        En informatique, chaque étape d'animation d'un objet est définie dans
  une zone rectangulaire que l'on appelle un Sprite. Généralement cette zone
  est donc un peu plus grande que le dessin de l'objet (puisque les contours
  des dessins sont rarement rectangulaires!). Néanmoins, il existe un cas de
  figure où des dessins remplissent complètement une zone rectangulaire; dans
  ce cas on les appelle plus communément des Tiles, c-à-d des entités de base
  permettant par exemple de construire un décor entier en réduisant par la
  même occasion son encombrement mémoire à ces quelques Tiles servant à
  décrire le décor (comme dans Mario Bros...).

        Mais revenons plutôt à nos sprites. Supposons que nous ayons à notre
  disposition en mémoire centrale un ensemble de données constituant un
  sprite. Pour l'afficher à l'écran il faut alors transférer cette zone
  rectangulaire complète vers la mémoire vidéo. Mais que se passe t-il si
  un décor quelconque se trouvait déjà à cet emplacement? Et oui! on aura bel
  et bien un recouvrement rectangulaire du sprite sur le décor. Si la couleur
  de fond du sprite est le noir, alors toute la partie noire du sprite qui
  est inoccupée par le dessin apparaîtra à l'écran en créant un effet
  indésirable! Pour pallier à cet inconvénient il faut pouvoir tranférer les
  pixels décrivant uniquement le dessin et non ceux qui décrivent le fond.
  Dans ce cas on transfèrera tous les pixels du sprite qui ne sont pas de
  couleur noire (donc en masquant le fond).


  c) LES ANIMATIONS : TECHNIQUES

        La plupart des programmes qui effectuent de nombreuses animations
  (démos, jeux) utilisent généralement des modes vidéo permettant de
  disposer de plusieurs pages graphiques au sein de la mémoire vidéo.
  Dans l'univers des PC il existe un mode non documenté appelé mode X qui
  permet de configurer les cartes VGA standards (à condition de disposer
  d'au moins 256Ko) de manière à obtenir en quelque sorte des variantes bien
  plus performantes que le mode 13h classique. Il est ainsi possible de
  disposer de 4 pages en 320 X 200, 2 pages en 320 X 400, 3 pages en
  360 X 240, 1 page en 360 X 480, etc... Bien évidemment on y perd quelque
  part puisque du coup l'adressage ne sera plus linéaire; mais l'intérêt de
  pouvoir disposer de plusieurs pages rattrappe vite ce soit disant
  inconvénient.

        Quel intérêt a t-on de disposer de plusieurs pages en mémoire vidéo?
  C'est très simple; Tout d'abord il s'agira d'autant de place en mémoire
  centrale qui sera économisée puisqu'avec 4 pages on pourra allègrement en
  attribuer une première pour les sprites et une deuxième pour les décors par
  exemple. Supposons que les 4 pages soient numérotées de 0 à 3; les sprites
  et les décors seront respectivement attribués aux pages 2 et 3; Les deux
  premières pages vont donc pouvoir nous servir à effectuer le travail
  d'animation proprement dite selon une technique bien connue du "Two Pages
  Buffering".

        En fait, comme une seule page sur les quatre ne peut être qu'activée à
  la fois à l'écran (par exemple la page 0), on effectuera la construction
  du décor et les positions des sprites sur la page cachée (la page 1).
  Ensuite, on bascule cette page à la place de l'autre pour la rendre visible
  à l'écran (en ayant soin d'attendre la VBL pour éviter tout problème de
  parasitage tel que le flicking). Maintenant, on construit le décor et les
  étapes d'animation suivantes sur la page 0, etc... On construit donc
  alternativement une page pendant que l'autre est active à l'écran, puis on
  bascule. Il s'agit de loin la technique la plus usitée! De plus les
  transferts de RAM vidéo vers la RAM vidéo sont assez rapides. Par contre
  dans un mode ne comportant par exemple que de 2 pages il faudra se résoudre
  à mémoriser les décors et les sprites en mémoire centrale.

        Il est souvent plus rapide de reconstruire entièrement ou
  partiellement l'écran suivant que de sauvegarder les portions de décors qui
  seront masqués par des sprites. En effet, puisque l'on peut supposer
  pouvoir conserver par exemple un décor entier dans une autre page, il
  suffira d'écraser les sprites de la page devenue inactive par les zones
  rectangulaires du décor à ces endroits précis (il n'est donc pas nécessaire
  dans ce cas de sauvegarder les zones rectangulaires des endroits où seront
  affichés les sprites!). Evidemment, pour un décor qui se déplace cela se
  complique, mais en réfléchissant un peu on arrive assez vite à trouver des
  astuces permettant de s'en sortir assez facilement. Imaginez devoir
  sauvegarder des tas de Tiles dynamiquement à l'aide des routines
  d'allocation du DOS... Le temps perdu est énorme et le but est toujours de
  privilégier une méthode efficace et rapide même au détriment de
  l'encombrement mémoire (ce qui n'est plus réellement un problème car
  actuellement on peut facilement disposer de 600Ko sous DOS).

        Une dernière petite chose à ajouter. Il est également possible de
  créer des effets d'animation en faisant cycler des sous-ensembles de
  couleurs de la palette. Pour ce faire il suffit de décaler chaque couleur
  (donc les 3 composantes) à la place de la couleur suivante (ou précédente
  selon le sens du cyclage), et la dernière du sous-ensemble prenant alors
  évidemment la place de la première (ou inversement selon le sens).



3 CHOIX TECHNIQUES

        Dans le cadre de cet article et par souçi de simplicité il a été
  convenu d'utiliser le mode 13h du BIOS vidéo. Ce mode est en fait un
  sous-système du mode VGA appelé MCGA (Memory Controller Gate Array). Il
  a été porté sur les petits modèles PS/2 d'IBM ne se contentant que de
  64Ko de RAM vidéo. Les cartes graphiques dotées d'une mémoire de capacité
  supérieure sont évidemment compatibles avec ce mode. Donc si vous disposez
  d'une capacité de 256Ko ou plus, l'activation de ce mode via le BIOS ne
  vous permettra pas d'utiliser plus de 64Ko de RAM vidéo. Pourquoi? Et bien
  vraisemblablement pour garantir la compatibilité avec les anciens modèles
  dotés uniquement de 64Ko (quel lourd boulet que cette sempiternelle
  compatibilité!). Cela dit, comme nous l'avons évoqué précédemment il est
  entièrement possible de disposer de plusieurs pages de 64000 octets ou plus
  à condition de programmer certains registres soi-même, c-à-d sans passer
  par le BIOS (c'est le fameux mode X), mais ceci dépasse le cadre de cet
  article.

        Mais revenons alors à ce mode MCGA. Que possède t-il d'intéressant?
  Outre une assez faible résolution de 320 * 200 pixels il permet néanmoins
  d'afficher 256 couleurs simultanément à l'écran! Comme 256 éléments sont
  codifiables sur 1 octet et que 320 * 200 font 64000 points, un écran
  représente donc 64000 octets adressables depuis le segment A000h. La grande
  quantité de couleurs compensera en quelque sorte la faible résolution de ce
  mode. Chacune des 256 couleurs est codifiée par des proportions de
  composantes de Rouge, de Vert et de Bleu (RVB), et chaque composante
  couleur accepte une codification sur 6 bits (de 0 à 63). Il est donc
  possible de choisir 256 parmi 2^6 * 2^6 * 2^6 c-à-d 256 parmi 262144
  couleurs possibles (suffisant n'est-ce pas?). Mais il y a encore plus
  intéressant! Les 64000 octets de l'écran sont de plus adressables de manière
  complètement linéaire (en fait il s'agit d'un leurre dû à l'activation du
  mode Chain4 et Odd/Even du registre 4 du séquenceur par le BIOS, de même que
  chaque ligne de l'écran est en fait dédoublée comme un faux mode 320 * 400,
  mais ce serait trop long à expliquer...).

        Finalement, quels sont les avantages que l'on peut tirer de ce mode?
  En fait, une extrême simplicité de l'adressage (écrire un pixel aux
  coordonnées x et y avec une couleur correspondant aux composantes RVB n°26
  sur les 256 actives sera traduit en PASCAL par : Mem[$A000:320*y+x]:=26;).
  Attention!, lors de l'activation du mode MCGA, une palette système de 256
  couleurs est utilisée par défaut. En plus, comme dans ce mode on ne dispose
  que d'une page graphique (donc toujours active à l'écran!) il faudra
  donc prendre garde à toujours attendre la VBL avant d'actualiser les parties
  de l'écran qui le nécessitent! Cependant on aura tout le loisir de
  travailler parallèlement avec des écrans virtuels de 64000 octets (pour
  palier à la présence d'une page graphique unique) pour effectuer toutes
  sortes de mémorisations (sprites et décors) et de traitements cachés.
  Rappellons aussi que selon le moniteur il peut y avoir en général entre
  50 et 70 VBL par seconde; Ainsi le couple constitué du moniteur et de la
  carte graphique est-il déterminant pour la vitesse des animations (un
  moniteur avec un rafraîchissement de 70hz et une carte vidéo assez lente
  donneront d'assez mauvais résultats).



4 LE PROGRAMME

  a) L'UNITE ANIMAGE

        Afin d'être certain de pouvoir faire fonctionner le programme sur les
  IBM PC comportant un adaptateur muni uniquement de 64Ko on utilise
  la fonction 0 (et sous-fonction 13h pour activer le mode MCGA) du BIOS
  video (10h). Le seul inconvénient réside dans le fait que si ce mode n'est
  pas disponible il n'y a aucune information en sortie permettant de s'en
  rendre compte. Il faut alors utiliser la fonction Fh (toujours avec la
  sous-fonction 13h) pour lire si le mode 13h a effectivement été activé.
  C'est cette solution qui a été utilisée pour la fonction Activation_MCGA.
  Pour la procédure Activation_Texte (qui permet de revenir au mode texte)
  seul le principe de la première étape est suffisant puisque l'on dispose
  forcément au minimum du mode texte!

        La procedure Attente_Synchro consiste à examiner le registre général
  3DAh. Si le bit 0 est à 1 alors une HBL (Horizontal BLanking) est en cours.
  Et si le bit 3 est à 1 alors une VBL (Vertical BLanking) est en cours. Il
  suffit donc d'attendre qu'il n'y ait plus de HBL après la VBL, ce que fait
  donc la procedure Attente_Synchro.

        La procédure Ecriture_Palette permet d'activer une palette de 256
  couleurs ou partie de palette personnelle. Pour cela on considère que
  chaque composante Rouge, Vert et Bleu doit être codée sur un octet. Comme
  256 X 3 octets font 768 octets alors le tableau passé en paramètre devra
  obligatoirement faire 768 octets de telle sorte à ce que les triplets de
  composantes couleur se suivent linéairement (RVBRVB...RVB). Le premier
  triplet correspond à la couleur 0 et le dernier à la couleur 255. Pour
  modifier 32 couleurs à partir de la couleur 128 (les 768 octets étant
  mémorisés dans le tableau PALET de 0 à 767) on écrira :

        Ecrire_Palette(PALET[128*3],128,32);

        Pour ce faire on utilise les registres du DAC 3C8h et 3C9h. Sur le
  port 3C8h on indique le code couleur à modifier et sur le port 3C9h on
  écrit successivement chaque proportion de Rouge, Vert et Bleu (de 0 à 63).
  La procédure Ecriture_Couleur effectue le même type de travail mais en ne
  modifiant qu'une couleur à la fois, et ce de manière directe (pas de
  tableau). Il est également possible de connaître les composantes d'une
  couleur donnée en inscrivant sur le port 3C7h le numéro de couleur puis en
  lisant successivement sur le port 3C9h chaque proportion de Rouge, Vert et
  Bleu (non implémenté dans l'unité). Cette méthode est extrêment plus rapide
  que d'utiliser les fonctions adéquates du BIOS (essayez donc de faire un
  fading propre d'une image de 256 couleurs via le BIOS!).

        La routine Ecriture_Pixel ne fait rien d'autre que de calculer
  l'offset équivalent à 320 * y + x afin d'afficher le pixel avec la couleur
  souhaitée. Pour tout ce qui est animation la rapidité est un facteur
  absolument indispensable. Ainsi quand on sait combien certaines
  instructions assembleur sont coûteuses en temps machine (un MUL équivaut
  environ à 80 cycles machines!) il faut autant que possible les éviter.
  Comme 320 = 256 + 64 on peut alors éviter l'opération de multiplication
  en faisant un XCHG de y (ce qui revient à le décaler de 8 bits à gauche et
  donc de le multiplier par 256 : 256 * y), en lui ajoutant ensuite ce
  résultat mais décalé de 2 bits à droite (256 * y + 64 * y), puis en
  ajoutant finalement x et le tour est joué!. On gagne apparamment quelques
  dizaines de cycles... Sur le même principe il sera très facile de
  concevoir une routine Lecture_Pixel qui donnera le code couleur d'un pixel
  donné (non implémenté dans l'unité).

        Dans le contrôleur CRT on dispose du registre Dh lequel
  permet de définir l'adresse d'offset qui servira d'adresse d'origine sur
  l'écran physique. Par défaut, dans ce mode on ne pourra effectuer un
  scrolling horizontal que par 4 points à la fois. Les données s'énoncent
  donc par 1/80ème d'unité à la fois (on remarquera qu'à raison de 80/80ème
  d'unité à la fois on transforme le scrolling horizontal en scrolling
  vertical puisque l'offset est alors décalé de 320 pixels à la fois et
  l'image semblera ainsi se déplacer vers le haut!). Il ne faut surtout pas
  oublier que l'adressage est linéaire, donc que le point qui suit
  immédiatement le dernier d'une ligne est en fait le premier de la ligne
  suivante; et quant à celui se trouvant juste après le dernier point de la
  dernière ligne de l'écran il s'agit du premier point de la première ligne
  de l'écran... Gare au phénomène de wrapping (enroulement). Quoiqu'il en soit
  la routine est extrêmement simple et est effectuée par la procédure
  Défilement_Octet.

        Pour entreprendre un dédoublement de l'écran il faut programmer
  plusieurs registres du contrôleur CRT. Il faut programmer le registre 18h
  (line compare) afin de préciser le numéro de ligne à partir duquel
  l'écran sera dédoublé. Mais le contrôleur considère ici la résolution dans
  son mode natif c-à-d en 320 X 400 (puisque chaque ligne est en fait
  dédoublée). Si par exemple on désire dupliquer les 100 premières lignes
  de 0 à 99 en 100 à 199, il ne faudra pas préciser la valeur 100 mais le
  double (200). De plus en faisant varier les valeurs de 399 à 0 on aura
  l'impression qu'une deuxième page (identique à la première) vient recouvrir
  la première de bas en haut! Donc pour superposer exactement les deux images
  il suffit de préciser la valeur 0. Mais le registre 18h n'a que 8 bits et
  pour représenter un nombre de 0 à 399 il faut utiliser le bit 4 du registre
  7 (le registre overflow = cuisine pour assurer les lignes supérieures à
  256!). De même un 10ème bit peut servir pour des résolutions supérieures,
  le bit 6 du registre 9 (Max scan Line = on bouche les trous comme on peut!).

        En ce qui concerne la routine Zoom_Vertical l'astuce consiste à
  changer la résolution verticale toujours à l'aide du registre 9. Seuls les
  bits 0 à 4 sont attribués à cette fonctionnalité.

        Viennent maintenant les deux procédures proprement dites concernant
  l'animation de sprites. La première (Copie_Bloc_Normal) effectue une copie
  d'une zone mémoire (centrale ou vidéo) vers une zone mémoire (centrale ou
  vidéo) en conservant le fond du sprite. La deuxième effectue le même
  travail mais sans copier le fond (c-à-d la couleur 0 par convention puisque
  par défaut elle est de couleur noire). Ces routines ne travaillent en fait
  qu'avec des pointeurs (une toute petite contrainte si l'on peut dire...).
  Il est vivement conseillé de travailler avec des pointeurs sur des zones de
  64000 octets linéaires (et non pas 320 X 200!) pour respecter une certaine
  cohérence avec la taille de l'écran physique (et donc pouvoir
  travailler sur des écrans virtuels). On part ainsi du principe que dans
  un ou plusieurs écrans virtuels se trouvent les différents sprites et/ou
  éléments du décor. Ces sprites sont donc mémorisés de la même façon qu'ils
  ont été conçus à l'aide d'un logiciel de dessin du type Deluxe Paint. Ainsi
  pour transférer un sprite de 20 pixels de large et de 40 pixels de haut qui
  se trouve aux coordonnées x1=0 et y1=32 de l'écran virtuel virt^ vers
  l'écran physique aux coordonées x2=100 et y=90 (sans masquage) il faudra
  écrire :

     Copie_Bloc_Normal(0,32,20,40,100,90,Seg(virt^)+Ofs(virt^),$A000);

        De même pour effectuer un traitement caché de mémoire centrale à
  mémoire centrale entre deux écrans virtuels appelés virt1^ et virt2^ on
  écrira (on a omis volontairement les 6 premières valeurs) :

     Copie_Bloc_Normal(,,,,,,Seg(virt1^)+Ofs(virt1^),Seg(virt2^)+Ofs(virt2^));

        Une dernière chose reste à préciser: La routine de copie avec masquage
  effectue un transfert octet par octet mais celle de copie normale
  effectue ce transfert mot par mot (toujours dans un souçi d'optimisation).
  Il faut dans ce cas toujours veiller à transférer une zone rectangulaire
  dont la largeur soit divisible par deux (paire).


  b) LE PROGRAMME ANIMDEMO

        Voici enfin la description du programme de démonstration utilisant
  l'unité ANIMAGE!!! (et pourtant je suis sûr d'avoir oublié de dire des tas
  de choses...).

        Que fait donc le programme ANIMDEMO?

     1) Apparition d'un titre (avec une police interne) en fading.
     2) Scrolling horizontal du titre en aller-retour.
     3) L'animation globale :
        - Quatre barres horizontales colorées se déplaçant verticalement et
          de manière sinusoïdale derrière le titre.
        - Trois balles colorées et rebondissantes passant sur les barres et
          le titre.
        - Un défilement continu de texte (chenillard) en haut de l'écran.
        - La même chose en bas de l'écran mais en zigzag.
      4) Un zoom momentané du texte situé en haut de l'écran.
      5) Disparition de celui-ci en fading.


        BAR_COULS contient les composantes couleur des quatre barres et
  PAL_COULS celles de la police et des trois balles. FONTE contient donc
  les codes couleur des caractères de A à Z, des 3 balles et du caractère
  Espace. Il est constitué de 1680 octets (240 points sur 7) c-à-d 30 petits
  sprites de 8 points sur 7. Cette police est d'ailleurs transférée ensuite
  dans image1^ (on a préféré utiliser une police personnelle plutôt que
  l'horrible police système!).

        A chaque commencement de caractère correspond une abscisse (dans ce
  cas les ordonnées sont inutiles puisque tous les sprites sont représentés
  à partir de la même ordonnée 0; de même pour la taille qui est de 8 X 7).
  TEXTE contient donc toutes les abscisses correspondant aux caractères du
  texte à faire défiler. La même chose est valable pour la première ligne du
  titre (TITRE1) et pour la deuxième (TITRE2).

        Dans ce programme le travail s'effectue avec deux écrans virtuels :
  image1^ et image2^ (ce qui est amplement suffisant). Le calcul des ordonnées
  des barres est précalculé dans TRACE_BARRE. Au début l'écran est rempli de
  160 lignes toutes de numéros de couleurs différents (en fonction de l'ordre
  dans la palette mais toutes de couleur noire!). Les barres sont en fait
  créées en changeant les 9 lignes consécutives correspondant à chaque
  nouvelle position de barre (Il ne s'agit pas d'animation mais de
  changements de couleurs!). Le titre qui apparaît au début est en fait
  masqué sur ces lignes d'où l'impression que les barres se déplacent en
  arrière plan.

        En ce qui concerne l'apparition en fading le principe est très
  simple : il suffit de créer une table de 768 éléments mis à zéro (les 256
  couleurs sont alors noires) et d'activer cette palette. Par la suite on
  affiche l'image (qui n'est donc pas visible) et on augmente incrémentalement
  l'intensité des 256 couleurs de cette table noire (en l'activant à chaque
  étape) tant qu'il existe une composante couleur qui ne soit pas parvenue à
  l'intensité réelle de la vraie palette de l'image. Le processus inverse
  s'applique pour la disparition en fading.

        Les composantes couleur de la police et des balles (PAL_COULS) sont
  mémorisées dans PALETTE à partir de la couleur 209 (Celles d'avant servent
  pour la pseudo-animation des barres). Mais pourquoi transfère t-on la
  police dans l'écran virtuel image1^? Tout simplement parce que FONTE n'est
  pas un pointeur et qu'il nous faut avoir les sprites dans une zone pointant
  sur 64000 octets! Ceci est dû au fait que normalement les images
  (compressées ou non) sont plutôt stockées dans des fichiers externes sur
  disque et lues alors directement dans les zones pointées. On a plutôt
  privilégié ici l'organisation d'un programme comportant toutes ses données
  en interne sous forme de tables (Il va de soit que les fichiers externes
  constituent une solution plus enviable!)...

        Pour effectuer un défilement de texte le plus simple est de décaler
  le bloc de manière soft de 2 pixels vers la gauche et d'ajouter le bon
  segment de deux pixels de large du caractère apparaîssant (dans un écran
  virtuel). Le bloc complet est ensuite transféré en RAM vidéo.

        Pour les balles on a d'abord effectué une copie de l'écran physique
  comprenant les lignes noires avec le titre vers image2^. Les balles font
  8 points sur 7; pour chaque nouvelle position de balle on transfère les
  zones rectangulaires de 12 sur 11 (entourant de deux pixels la taille
  d'une balle puisque les balles se déplacent par deux pixels à la fois)
  correspondantes de image2^ vers image1^. Ensuite on transfère les sprites
  des balles (qui sont situés en haut de l'écran virtuel image1^ et à
  droite de la police) vers image1^. On transfère finalement les zones de 12
  sur 11 où sont situées les balles de image1^ vers l'écran physique. Voilà!,
  le reste est suffisamment clair pour ne pas être détaillé.



5 AMELIORATIONS

        Peut-être est-il encore possible d'effectuer certaines optimisations?
  Il est également possible d'étendre les fonctionnalités de l'unité ANIMAGE
  en incorporant par exemple : zoom horizontal soft, copie de bloc en faisant
  l'addition des couleurs du sprite avec le décor de telle sorte à donner un
  effet de transparence (il faudra donc organiser les couleurs de la palette
  de façon appropriée), etc... Ou bien tout simplement se lancer dans la mise
  en oeuvre du mode X et pouvoir ainsi disposer selon les modes de une ou
  plusieurs pages graphiques.



6 CONCLUSION

        Dans cet article, on a présenté sommairement les constituant
  essentiels d'une carte graphique, les différentes techniques d'animation
  ainsi qu'une unité et un programme d'exemple permettant de s'initier à ce
  type de programmation assez particulier à travers le mode 13h.