旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � 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 늯re modifi�.� � Si vous en obtenez enti둹e satisfaction ou si vous l'utilisez � � souvent, effectuez donc votre contrat moral en envoyant un ch둸ue� � 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늤e que par le fait que de nombreux programmeurs pratiquant ce type de technique pr괽둹ent conserver leurs d괹ouvertes � l'abri des nombreux int굍ess굎. Cet article est tr둺 loin d'늯re exhaustif et n'a pour unique pr굏ention que d'expliquer le plus simplement du monde (du moins je l'esp둹e!) certaines techniques fondamentales d'animation graphique. 2 PRINCIPES a) LA CARTE VGA Tout d'abord, il faut savoir qu'une carte VGA est constitu괻 de plusieurs 굃굆ents: des registres g굈굍aux, le contr뱇eur CRT (Cathode Ray Tube), le s굌uenceur, le contr뱇eur d'attributs et le DAC (Digital/ Analogic Converter). Parmi les registres g굈굍aux on peut d'ailleurs trouver le registre 3DAh contenant des informations sur la VBL ou la HBL. Le contr뱇eur CRT (25 registres) a par contre la difficile t긟he de configurer convenablement l'괹ran selon les modes graphiques utilis굎. Le s굌uenceur (5 registres) permet de convertir les acc둺 � la RAM vid굊 en les dirigeant vers les bons plans de bits; le rafra똲sement de la RAM vid굊 fait 괾alement 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굊, et ce de 256Ko jusqu'� g굈굍alement 1 ou 2Mo, voire plus. b) LES ANIMATIONS : GENERALITES Le PC a souvent 굏� l'enfant pauvre en mati둹e d'animation (surtout face � des concurrents comme l'Amiga ou l'Atari). Cependant, ce handicap tend un petit peu moins � se remarquer gr긟e � l'av둵ement de cartes graphiques assez performantes et de PC puissants (malgr� certains goulots d'굏ranglement...). Imaginons par exemple le d굋lacement d'un petit bonhomme sur un 괹ran. Qu'est-ce qui cr괻 l'illusion de l'animation? Et bien, exactement le m늤e ph굈om둵e que l'on retrouve lors de la projection d'un film cin굆atographique. Diff굍entes 굏apes d'animation du petit bonhomme sont en fait affich괻s successivement (et suffisamment rapidement) afin de cr괻r l'illusion du mouvement. En informatique, chaque 굏ape d'animation d'un objet est d괽inie dans une zone rectangulaire que l'on appelle un Sprite. G굈굍alement cette zone est donc un peu plus grande que le dessin de l'objet (puisque les contours des dessins sont rarement rectangulaires!). N괶nmoins, il existe un cas de figure o� des dessins remplissent compl둻ement une zone rectangulaire; dans ce cas on les appelle plus commun굆ent des Tiles, c-�-d des entit굎 de base permettant par exemple de construire un d괹or entier en r괺uisant par la m늤e occasion son encombrement m굆oire � ces quelques Tiles servant � d괹rire le d괹or (comme dans Mario Bros...). Mais revenons plut뱓 � nos sprites. Supposons que nous ayons � notre disposition en m굆oire centrale un ensemble de donn괻s constituant un sprite. Pour l'afficher � l'괹ran il faut alors transf굍er cette zone rectangulaire compl둻e vers la m굆oire vid굊. Mais que se passe t-il si un d괹or quelconque se trouvait d굁� � cet emplacement? Et oui! on aura bel et bien un recouvrement rectangulaire du sprite sur le d괹or. Si la couleur de fond du sprite est le noir, alors toute la partie noire du sprite qui est inoccup괻 par le dessin appara똳ra � l'괹ran en cr괶nt un effet ind굎irable! Pour pallier � cet inconv굈ient il faut pouvoir tranf굍er les pixels d괹rivant uniquement le dessin et non ceux qui d괹rivent le fond. Dans ce cas on transf둹era 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굆os, jeux) utilisent g굈굍alement des modes vid굊 permettant de disposer de plusieurs pages graphiques au sein de la m굆oire vid굊. 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둹e � 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 굒idemment on y perd quelque part puisque du coup l'adressage ne sera plus lin괶ire; mais l'int굍늯 de pouvoir disposer de plusieurs pages rattrappe vite ce soit disant inconv굈ient. Quel int굍늯 a t-on de disposer de plusieurs pages en m굆oire vid굊? C'est tr둺 simple; Tout d'abord il s'agira d'autant de place en m굆oire centrale qui sera 괹onomis괻 puisqu'avec 4 pages on pourra all둮rement en attribuer une premi둹e pour les sprites et une deuxi둴e pour les d괹ors par exemple. Supposons que les 4 pages soient num굍ot괻s de 0 � 3; les sprites et les d괹ors seront respectivement attribu굎 aux pages 2 et 3; Les deux premi둹es 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 늯re qu'activ괻 � la fois � l'괹ran (par exemple la page 0), on effectuera la construction du d괹or et les positions des sprites sur la page cach괻 (la page 1). Ensuite, on bascule cette page � la place de l'autre pour la rendre visible � l'괹ran (en ayant soin d'attendre la VBL pour 굒iter tout probl둴e de parasitage tel que le flicking). Maintenant, on construit le d괹or et les 굏apes d'animation suivantes sur la page 0, etc... On construit donc alternativement une page pendant que l'autre est active � l'괹ran, puis on bascule. Il s'agit de loin la technique la plus usit괻! De plus les transferts de RAM vid굊 vers la RAM vid굊 sont assez rapides. Par contre dans un mode ne comportant par exemple que de 2 pages il faudra se r굎oudre � m굆oriser les d괹ors et les sprites en m굆oire centrale. Il est souvent plus rapide de reconstruire enti둹ement ou partiellement l'괹ran suivant que de sauvegarder les portions de d괹ors qui seront masqu굎 par des sprites. En effet, puisque l'on peut supposer pouvoir conserver par exemple un d괹or entier dans une autre page, il suffira d'괹raser les sprites de la page devenue inactive par les zones rectangulaires du d괹or � ces endroits pr괹is (il n'est donc pas n괹essaire dans ce cas de sauvegarder les zones rectangulaires des endroits o� seront affich굎 les sprites!). Evidemment, pour un d괹or qui se d굋lace cela se complique, mais en r괽l괹hissant 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 굈orme et le but est toujours de privil괾ier une m굏hode efficace et rapide m늤e au d굏riment de l'encombrement m굆oire (ce qui n'est plus r괻llement un probl둴e car actuellement on peut facilement disposer de 600Ko sous DOS). Une derni둹e petite chose � ajouter. Il est 괾alement possible de cr괻r des effets d'animation en faisant cycler des sous-ensembles de couleurs de la palette. Pour ce faire il suffit de d괹aler chaque couleur (donc les 3 composantes) � la place de la couleur suivante (ou pr괹괺ente selon le sens du cyclage), et la derni둹e du sous-ensemble prenant alors 굒idemment la place de la premi둹e (ou inversement selon le sens). 3 CHOIX TECHNIQUES Dans le cadre de cet article et par sou뇁 de simplicit� il a 굏� convenu d'utiliser le mode 13h du BIOS vid굊. Ce mode est en fait un sous-syst둴e du mode VGA appel� MCGA (Memory Controller Gate Array). Il a 굏� port� sur les petits mod둳es PS/2 d'IBM ne se contentant que de 64Ko de RAM vid굊. Les cartes graphiques dot괻s d'une m굆oire de capacit� sup굍ieure sont 굒idemment 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굊. Pourquoi? Et bien vraisemblablement pour garantir la compatibilit� avec les anciens mod둳es dot굎 uniquement de 64Ko (quel lourd boulet que cette sempiternelle compatibilit�!). Cela dit, comme nous l'avons 굒oqu� pr괹괺emment il est enti둹ement possible de disposer de plusieurs pages de 64000 octets ou plus � condition de programmer certains registres soi-m늤e, c-�-d sans passer par le BIOS (c'est le fameux mode X), mais ceci d굋asse le cadre de cet article. Mais revenons alors � ce mode MCGA. Que poss둪e t-il d'int굍essant? Outre une assez faible r굎olution de 320 * 200 pixels il permet n괶nmoins d'afficher 256 couleurs simultan굆ent � l'괹ran! Comme 256 굃굆ents sont codifiables sur 1 octet et que 320 * 200 font 64000 points, un 괹ran repr굎ente donc 64000 octets adressables depuis le segment A000h. La grande quantit� de couleurs compensera en quelque sorte la faible r굎olution de ce mode. Chacune des 256 couleurs est codifi괻 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굍essant! Les 64000 octets de l'괹ran sont de plus adressables de mani둹e compl둻ement lin괶ire (en fait il s'agit d'un leurre d� � l'activation du mode Chain4 et Odd/Even du registre 4 du s굌uenceur par le BIOS, de m늤e que chaque ligne de l'괹ran est en fait d괺oubl괻 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늤e simplicit� de l'adressage (괹rire un pixel aux coordonn괻s 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둴e de 256 couleurs est utilis괻 par d괽aut. En plus, comme dans ce mode on ne dispose que d'une page graphique (donc toujours active � l'괹ran!) il faudra donc prendre garde � toujours attendre la VBL avant d'actualiser les parties de l'괹ran qui le n괹essitent! Cependant on aura tout le loisir de travailler parall둳ement avec des 괹rans virtuels de 64000 octets (pour palier � la pr굎ence d'une page graphique unique) pour effectuer toutes sortes de m굆orisations (sprites et d괹ors) et de traitements cach굎. Rappellons aussi que selon le moniteur il peut y avoir en g굈굍al entre 50 et 70 VBL par seconde; Ainsi le couple constitu� du moniteur et de la carte graphique est-il d굏erminant pour la vitesse des animations (un moniteur avec un rafra똠hissement de 70hz et une carte vid굊 assez lente donneront d'assez mauvais r굎ultats). 4 LE PROGRAMME a) L'UNITE ANIMAGE Afin d'늯re 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굈ient r굎ide 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 굏� activ�. C'est cette solution qui a 굏� utilis괻 pour la fonction Activation_MCGA. Pour la proc괺ure Activation_Texte (qui permet de revenir au mode texte) seul le principe de la premi둹e 굏ape est suffisant puisque l'on dispose forc굆ent au minimum du mode texte! La procedure Attente_Synchro consiste � examiner le registre g굈굍al 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둺 la VBL, ce que fait donc la procedure Attente_Synchro. La proc괺ure Ecriture_Palette permet d'activer une palette de 256 couleurs ou partie de palette personnelle. Pour cela on consid둹e que chaque composante Rouge, Vert et Bleu doit 늯re cod괻 sur un octet. Comme 256 X 3 octets font 768 octets alors le tableau pass� en param둻re devra obligatoirement faire 768 octets de telle sorte � ce que les triplets de composantes couleur se suivent lin괶irement (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 굏ant m굆oris굎 dans le tableau PALET de 0 � 767) on 괹rira : 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 괹rit successivement chaque proportion de Rouge, Vert et Bleu (de 0 � 63). La proc괺ure Ecriture_Couleur effectue le m늤e type de travail mais en ne modifiant qu'une couleur � la fois, et ce de mani둹e directe (pas de tableau). Il est 괾alement possible de conna똳re les composantes d'une couleur donn괻 en inscrivant sur le port 3C7h le num굍o de couleur puis en lisant successivement sur le port 3C9h chaque proportion de Rouge, Vert et Bleu (non impl굆ent� dans l'unit�). Cette m굏hode est extr늤ent plus rapide que d'utiliser les fonctions ad굌uates 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 굌uivalent � 320 * y + x afin d'afficher le pixel avec la couleur souhait괻. Pour tout ce qui est animation la rapidit� est un facteur absolument indispensable. Ainsi quand on sait combien certaines instructions assembleur sont co뻯euses en temps machine (un MUL 굌uivaut environ � 80 cycles machines!) il faut autant que possible les 굒iter. Comme 320 = 256 + 64 on peut alors 굒iter l'op굍ation de multiplication en faisant un XCHG de y (ce qui revient � le d괹aler de 8 bits � gauche et donc de le multiplier par 256 : 256 * y), en lui ajoutant ensuite ce r굎ultat mais d괹al� 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늤e principe il sera tr둺 facile de concevoir une routine Lecture_Pixel qui donnera le code couleur d'un pixel donn� (non impl굆ent� dans l'unit�). Dans le contr뱇eur CRT on dispose du registre Dh lequel permet de d괽inir l'adresse d'offset qui servira d'adresse d'origine sur l'괹ran physique. Par d괽aut, dans ce mode on ne pourra effectuer un scrolling horizontal que par 4 points � la fois. Les donn괻s s'굈oncent donc par 1/80둴e d'unit� � la fois (on remarquera qu'� raison de 80/80둴e d'unit� � la fois on transforme le scrolling horizontal en scrolling vertical puisque l'offset est alors d괹al� de 320 pixels � la fois et l'image semblera ainsi se d굋lacer vers le haut!). Il ne faut surtout pas oublier que l'adressage est lin괶ire, donc que le point qui suit imm괺iatement le dernier d'une ligne est en fait le premier de la ligne suivante; et quant � celui se trouvant juste apr둺 le dernier point de la derni둹e ligne de l'괹ran il s'agit du premier point de la premi둹e ligne de l'괹ran... Gare au ph굈om둵e de wrapping (enroulement). Quoiqu'il en soit la routine est extr늤ement simple et est effectu괻 par la proc괺ure D괽ilement_Octet. Pour entreprendre un d괺oublement de l'괹ran il faut programmer plusieurs registres du contr뱇eur CRT. Il faut programmer le registre 18h (line compare) afin de pr괹iser le num굍o de ligne � partir duquel l'괹ran sera d괺oubl�. Mais le contr뱇eur consid둹e ici la r굎olution dans son mode natif c-�-d en 320 X 400 (puisque chaque ligne est en fait d괺oubl괻). Si par exemple on d굎ire dupliquer les 100 premi둹es lignes de 0 � 99 en 100 � 199, il ne faudra pas pr괹iser la valeur 100 mais le double (200). De plus en faisant varier les valeurs de 399 � 0 on aura l'impression qu'une deuxi둴e page (identique � la premi둹e) vient recouvrir la premi둹e de bas en haut! Donc pour superposer exactement les deux images il suffit de pr괹iser la valeur 0. Mais le registre 18h n'a que 8 bits et pour repr굎enter un nombre de 0 � 399 il faut utiliser le bit 4 du registre 7 (le registre overflow = cuisine pour assurer les lignes sup굍ieures � 256!). De m늤e un 10둴e bit peut servir pour des r굎olutions sup굍ieures, 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굎olution verticale toujours � l'aide du registre 9. Seuls les bits 0 � 4 sont attribu굎 � cette fonctionnalit�. Viennent maintenant les deux proc괺ures proprement dites concernant l'animation de sprites. La premi둹e (Copie_Bloc_Normal) effectue une copie d'une zone m굆oire (centrale ou vid굊) vers une zone m굆oire (centrale ou vid굊) en conservant le fond du sprite. La deuxi둴e effectue le m늤e travail mais sans copier le fond (c-�-d la couleur 0 par convention puisque par d괽aut 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괶ires (et non pas 320 X 200!) pour respecter une certaine coh굍ence avec la taille de l'괹ran physique (et donc pouvoir travailler sur des 괹rans virtuels). On part ainsi du principe que dans un ou plusieurs 괹rans virtuels se trouvent les diff굍ents sprites et/ou 굃굆ents du d괹or. Ces sprites sont donc m굆oris굎 de la m늤e fa뇇n qu'ils ont 굏� con뇎s � l'aide d'un logiciel de dessin du type Deluxe Paint. Ainsi pour transf굍er un sprite de 20 pixels de large et de 40 pixels de haut qui se trouve aux coordonn괻s x1=0 et y1=32 de l'괹ran virtuel virt^ vers l'괹ran physique aux coordon괻s x2=100 et y=90 (sans masquage) il faudra 괹rire : Copie_Bloc_Normal(0,32,20,40,100,90,Seg(virt^)+Ofs(virt^),$A000); De m늤e pour effectuer un traitement cach� de m굆oire centrale � m굆oire centrale entre deux 괹rans virtuels appel굎 virt1^ et virt2^ on 괹rira (on a omis volontairement les 6 premi둹es valeurs) : Copie_Bloc_Normal(,,,,,,Seg(virt1^)+Ofs(virt1^),Seg(virt2^)+Ofs(virt2^)); Une derni둹e chose reste � pr괹iser: 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뇁 d'optimisation). Il faut dans ce cas toujours veiller � transf굍er une zone rectangulaire dont la largeur soit divisible par deux (paire). b) LE PROGRAMME ANIMDEMO Voici enfin la description du programme de d굆onstration utilisant l'unit� ANIMAGE!!! (et pourtant je suis s뻭 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괻s se d굋la놹nt verticalement et de mani둹e sinuso땊ale derri둹e le titre. - Trois balles color괻s et rebondissantes passant sur les barres et le titre. - Un d괽ilement continu de texte (chenillard) en haut de l'괹ran. - La m늤e chose en bas de l'괹ran mais en zigzag. 4) Un zoom momentan� du texte situ� en haut de l'괹ran. 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둹es de A � Z, des 3 balles et du caract둹e 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굍괻 ensuite dans image1^ (on a pr괽굍� utiliser une police personnelle plut뱓 que l'horrible police syst둴e!). A chaque commencement de caract둹e correspond une abscisse (dans ce cas les ordonn괻s sont inutiles puisque tous les sprites sont repr굎ent굎 � partir de la m늤e ordonn괻 0; de m늤e pour la taille qui est de 8 X 7). TEXTE contient donc toutes les abscisses correspondant aux caract둹es du texte � faire d괽iler. La m늤e chose est valable pour la premi둹e ligne du titre (TITRE1) et pour la deuxi둴e (TITRE2). Dans ce programme le travail s'effectue avec deux 괹rans virtuels : image1^ et image2^ (ce qui est amplement suffisant). Le calcul des ordonn괻s des barres est pr괹alcul� dans TRACE_BARRE. Au d괷ut l'괹ran est rempli de 160 lignes toutes de num굍os de couleurs diff굍ents (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괹utives correspondant � chaque nouvelle position de barre (Il ne s'agit pas d'animation mais de changements de couleurs!). Le titre qui appara똳 au d괷ut est en fait masqu� sur ces lignes d'o� l'impression que les barres se d굋lacent en arri둹e plan. En ce qui concerne l'apparition en fading le principe est tr둺 simple : il suffit de cr괻r une table de 768 굃굆ents mis � z굍o (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굆entalement l'intensit� des 256 couleurs de cette table noire (en l'activant � chaque 굏ape) tant qu'il existe une composante couleur qui ne soit pas parvenue � l'intensit� r괻lle 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굆oris괻s dans PALETTE � partir de la couleur 209 (Celles d'avant servent pour la pseudo-animation des barres). Mais pourquoi transf둹e t-on la police dans l'괹ran 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괻s ou non) sont plut뱓 stock괻s dans des fichiers externes sur disque et lues alors directement dans les zones point괻s. On a plut뱓 privil괾i� ici l'organisation d'un programme comportant toutes ses donn괻s en interne sous forme de tables (Il va de soit que les fichiers externes constituent une solution plus enviable!)... Pour effectuer un d괽ilement de texte le plus simple est de d괹aler le bloc de mani둹e soft de 2 pixels vers la gauche et d'ajouter le bon segment de deux pixels de large du caract둹e appara똲sant (dans un 괹ran virtuel). Le bloc complet est ensuite transf굍� en RAM vid굊. Pour les balles on a d'abord effectu� une copie de l'괹ran 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둹e les zones rectangulaires de 12 sur 11 (entourant de deux pixels la taille d'une balle puisque les balles se d굋lacent par deux pixels � la fois) correspondantes de image2^ vers image1^. Ensuite on transf둹e les sprites des balles (qui sont situ굎 en haut de l'괹ran virtuel image1^ et � droite de la police) vers image1^. On transf둹e finalement les zones de 12 sur 11 o� sont situ괻s les balles de image1^ vers l'괹ran physique. Voil�!, le reste est suffisamment clair pour ne pas 늯re d굏aill�. 5 AMELIORATIONS Peut-늯re est-il encore possible d'effectuer certaines optimisations? Il est 괾alement possible d'굏endre les fonctionnalit굎 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괹or de telle sorte � donner un effet de transparence (il faudra donc organiser les couleurs de la palette de fa뇇n appropri괻), 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굎ent� sommairement les constituant essentiels d'une carte graphique, les diff굍entes 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.