 |
Samedi 20 avril 2024 - 11:29 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
Donner vie aux graphiques sur Amiga
L'animation informatique consiste à afficher une série d'images sur un écran vidéo. Les images peuvent être affichées au même endroit sur l'écran pour une animation statique ou déplacées sur l'écran pour une animation dynamique. L'animation consomme en général une grande partie de la puissance de traitement et de l'espace mémoire disponibles d'un système. Cependant, il est généralement possible de trouver un compromis entre l'espace mémoire et la puissance de traitement requise.
L'Amiga de Commodore dispose d'un matériel spécifique qui permet à l'animation de consommer moins de puissance processeur. Les canaux DMA (accès direct à la mémoire) des sprites permettent de déplacer et de modifier une image relativement petite en changeant seulement quelques emplacements en mémoire. Le Blitter est un dispositif matériel à haute vitesse utilisé pour copier ou fusionner des données d'image et dessiner des lignes. Comme les couleurs de l'Amiga sont stockées dans des registres, une forme spéciale d'animation appelée "color animation" animation couleur est possible.
Dans cet article, nous aborderons brièvement les différents aspects de l'animation sur Amiga et les possibilités offertes par le noyau en ROM de l'Amiga pour générer des images graphiques. En conclusion, nous décrirons nos méthodes de programmation de l'animation sur Amiga.
L'affichage
La première chose à spécifier est le fond sur lequel l'animation va se dérouler. Pour ce faire, il faut définir une structure "View", qui décrit les caractéristiques de l'affichage (voir figure 1). La vue est constituée d'un ou plusieurs "ViewPorts" (ports d'affichage) chacun ayant une hauteur, une largeur, un mode d'affichage, des données d'image, des couleurs et une position sur l'écran spécifiques.
Figure 1 : la structure View, qui définit les caractéristiques d'affichage de l'Amiga, consiste
en un ou plusieurs ViewPorts, qui doivent être séparés par au moins une ligne blanche. Les valeurs RxOffset
et RyOffset déterminent quelle partie de la carte binaire de l'arrière-plan est affichée dans un ViewPort.
Figure 2 : la structure ViewPort contient des pointeurs vers le ColorMap, qui indique au système
les couleurs à utiliser dans le ViewPort, et vers RasInfo, qui indique au système où se trouve le BitMap.
La structure BitMap contient des pointeurs vers un à six plans de bits représentant respectivement de 2 à 64 couleurs.
Animation des sprites
Les sprites sont des "objets" matériels qui sont indépendants de l'affichage de fond. L'Amiga peut avoir huit sprites, chacun de 16 pixels de large et d'un nombre quelconque de lignes de haut (figure 3).
Figure 3 : les sprites matériels, des objets graphiques qui peuvent se
déplacer indépendamment de l'affichage d'arrière-plan, peuvent avoir
jusqu'à 16 bits de largeur, un nombre quelconque de bits de hauteur
et jusqu'à trois couleurs plus la transparence.
Un sprite est affiché à l'écran en spécifiant ses coordonnées X,Y et un pointeur vers la zone mémoire qui décrit l'image formée. Pour animer un sprite, il suffit de modifier les coordonnées ou le pointeur vers les données de l'image. Comme il suffit de modifier quelques octets pour déplacer ou modifier l'image, l'animation d'un sprite ne nécessite très que peu de puissance processeur.
Le noyau en ROM de l'Amiga fournit plusieurs routines pour manipuler les sprites matériels. "GetSprite" alloue un sprite matériel pour l'usage exclusif de la tâche qui le demande. "ChangeSprite" modifie le pointeur vers la carte binaire de l'image d'un sprite réservé. "MoveSprite" modifie les coordonnées X,Y du sprite. "FreeSprite" restitue un sprite réservé au système.
Pour utiliser les sprites matériels dans le système d'animation, le noyau en ROM de l'Amiga définit une structure appelée "VSprite" (pour "virtual sprite"). Les informations relatives au sprite, telles que les données de couleur, la détection de collision et le double tampon mémoire, sont contenues dans la structure VSprite.
Les sprites sont extrêmement faciles à animer, mais ils ont des limites dont vous devez tenir compte. Un nombre limité de sprites est disponible, et chaque sprite a une taille limitée. Par conséquent, si vous devez animer une grande zone, les sprites ne seront pas appropriés. Un sprite individuel ne peut avoir que trois couleurs et les sprites attachés peuvent avoir quinze couleurs, alors que l'affichage de fond peut avoir jusqu'à 32 couleurs. Le bit de mode "SPRITES" dans la structure ViewPort doit être activé si vous utilisez des VSprites ou des sprites matériels.
Animation d'arrière-plan
Le type le plus simple d'animation d'arrière-plan utilise l'astuce "XOR". Par exemple, si vous effectuez un XOR d'une zone de l'écran avec un motif, le motif apparaît à l'écran avec une couleur différente de celle du fond (figure 4).
Figure 4 : une forme d'animation d'arrière-plan sur l'Amiga implique l'utilisation d'un motif
pour XOR une zone de l'arrière-plan. Le motif apparaîtra à l'écran avec une couleur
différente de celle de l'arrière-plan.
La méthode la plus souvent utilisée pour animer des images d'arrière-plan complexes consiste à déplacer les blocs de données réels. Cette méthode prend le plus de temps processeur, mais l'Amiga aide avec le Blitter matériel. Le Blitter utilise jusqu'à quatre canaux DMA pour déplacer les données quatre à dix fois plus vite que le microprocesseur 68000.
Les routines "BltBitMap" et "ClipBlit" copient des zones rectangulaires d'une section de la mémoire à une autre. BltBitMap prend les plans de bits comme arguments et ne déplace ("blit") que les plans de bits spécifiés. ClipBlit fonctionne avec la structure RastPort et dans le cadre du système multitâche. Il ne détruira pas les données d'une fenêtre chevauchante d'une autre tâche. Les deux routines utilisent des minterms, des valeurs de 8 bits qui déterminent comment le rectangle source est déplacé dans la zone de destination. Si vous voulez que l'objet fasse plus que s'animer dans une position stationnaire, vous devez sauvegarder l'arrière-plan sous l'objet pour qu'il puisse être restauré. Si plusieurs objets se déplacent l'un sur l'autre, les déplacements de données doivent être traités dans l'ordre suivant : dernier entré, premier sorti. Deux objets mobiles qui se chevauchent seront traités dans cet ordre :
- Sauvegarder l'arrière-plan 1.
- Placer l'objet 1.
- Sauvegarder l'arrière-plan 2.
- Placer l'objet 2.
- Restaurer l'arrière-plan 2.
- Restaurer l'arrière-plan 1.
D = AB + AC |
où "A" est le masque de l'objet, "B" est l'objet, "C" est l'arrière-plan et "D" est la nouvelle image d'animation. Autrement dit, la nouvelle image est remplacée par l'objet lorsque le masque d'objet est vrai et par l'arrière-plan lorsque le masque d'objet n'est pas vrai.
Pour mettre en oeuvre cette opération "cookie-cutter", les adresses des données de l'objet et de l'arrière-plan sont chargées dans les registres de données source du Blitter BLTxDAT (où "x" est égal à A, B ou C, comme ci-dessus) et le minterm résultant de l'équation ci-dessus est placé dans le registre matériel BLTCON0. La même chose peut être accomplie en divisant l'opération en deux parties et en utilisant la fonction BltBitMap, qui prendra deux sources à la fois.
Lorsque l'Amiga modifie une image en mémoire, il le fait en modifiant un plan de bits à la fois. En raison de la période de temps finie qu'il faut pour modifier chaque plan de bits, un objet en mouvement aura tendance à avoir ses plans de bits séparés à travers l'écran. Un autre problème survient si le programme commence à dessiner de nouvelles informations là où le faisceau vidéo passe. Il en résulte un écran composé en partie d'anciens éléments et en partie de nouveaux. Si les deux images sont très différentes, l'aspect peut être assez mauvais. La solution à ces deux problèmes est de doubler la mémoire tampon de l'écran. C'est-à-dire que le système affiche un espace mémoire tout en dessinant dans un autre espace mémoire. Les pointeurs des deux zones sont permutés lorsque le dessin est totalement terminé et l'écran conserve son intégrité visuelle. Cette méthode utilise deux fois la quantité de mémoire de l'écran, ainsi le double tampon mémoire d'un écran avec des plans de quatre bits utilisera 32 ko supplémentaires de mémoire Chip. Une autre façon pour l'Amiga de faciliter l'animation est de gérer le défilement horizontal et vertical. Si vous changez simplement le RxOffset et le RyOffset de la structure ViewPort (voir figure 1), l'écran affichera une portion différente des données de fond. Aucune mémoire n'est déplacée, de sorte que le défilement est rapide et fluide. Une particularité du défilement, cependant, est qu'il désactive les sprites matériels 6 et 7.
Si vous réglez le ViewPort en mode "DualPlayfield" (double plan), vous disposerez de deux plans contrôlables indépendamment, l'un ayant une priorité plus élevée que l'autre. Chaque plan peut avoir jusqu'à sept couleurs, plus la transparence. Un arrière-plan mobile à l'extérieur d'une fenêtre d'avion est le type d'effet possible avec cette technique.
Animation en couleur
L'animation en couleur est une forme particulière d'animation dont les applications sont assez limitées. En changeant les registres de couleur de l'Amiga dans une séquence régulière, une image correctement formée semblera "couler" sur l'écran. Cet effet convient bien à l'animation d'une rivière qui coule ou d'un nuage de fumée. Comme l'animation couleur utilise très peu de temps processeur ou de mémoire, elle peut fournir des effets simples sans utiliser beaucoup de ressources.
Le système d'animation Amiga
Le système d'animation graphique du noyau Amiga classe les sprites (VSprites) et les objets (BOB) d'arrière-plan (ou Blitter) comme des éléments graphiques (GEL). Les routines d'animation graphique gèrent automatiquement certains des sujets que nous venons d'aborder. Si votre séquence d'animation nécessite à la fois des BOB et des VSprites, et si vous avez besoin d'utiliser la plupart des fonctionnalités de ce système, cela pourrait vous simplifier la tâche. Cependant, ce système ajoute beaucoup de surcharges et vous trouverez peut-être que vous avez plus de contrôle si vous écrivez vos propres routines spécifiques à l'application.
Un BOB est une extension des informations contenues dans la structure VSprite (hauteur, informations de gestion des collisions, position et pointeurs vers les données). La structure BOB gère les informations propres à l'arrière-plan, telles que la séquence de dessin, le masque d'image, la sauvegarde et la restauration des informations d'arrière-plan et la double mise en mémoire tampon. Vous pouvez déterminer l'ordre de dessin de chaque BOB ou autoriser le système à les dessiner dans l'ordre de position Y,X. Le système dessine d'abord le BOB dont la valeur Y est la plus faible. Si deux BOB ont la même valeur Y, le BOB dont la valeur X est la plus faible est dessiné en premier. Les objets dessinés ultérieurement recouvrent les objets dessinés antérieurement.
Pour que le système enregistre automatiquement l'arrière-plan à restaurer après avoir déplacé le BOB vers un nouvel emplacement, vous devez activer le bit "SAVEBACK" dans la variable "sprFlag" de la structure VSprite et définir la variable "SaveBuffer" à l'adresse d'un emplacement mémoire. Pour "découper" le BOB en arrière-plan, activez le bit "OVERLAY" et définissez le masque "ImageShadow". Pour faire un double tampon mémoire, un pointeur BOB est placé dans la structure BOB vers une structure appelée "DBufPacket". Cette structure contient des informations qui permettent de garder la trace de l'arrière-plan dans le tampon de dessin actuel pour une restauration correcte. Si l'une des BOB est à double tampon mémoire, tous les BOB doivent être à double tampon mémoire.
Quatre variables décrivent les limites d'un rectangle qui va délimiter le BOB. Si le GEL est passé complètement en dehors de la région délimitée, l'indicateur "GELGONE" sera activé. Si ce GEL n'est plus nécessaire, vous pouvez le supprimer de la liste des GEL pour accélérer le traitement global. Le bit "SAVEBOB" peut être activé pour indiquer au système de ne pas effacer l'ancienne image du BOB, ce qui donne un effet "pinceau" lorsque le BOB se déplace. Une fois que tous les GEL sont déplacés ou modifiés, ils doivent être triés avec la routine SortGList et finalement affichés avec la routine DrawGList. DrawGList constitue une liste d'instructions pour le Copper.
L'Amiga gère un ensemble de structures et de routines qui vont animer les BO. L'AnimOb (objet d'animation) est la structure de données de haut niveau qui organise les AnimComp (composants d'animation) et contient le point d'enregistrement dans l'affichage par rapport auquel les BOB de ses composants sont dessinés. L'AnimComp est un composant de l'animation qui contient l'imagerie réelle, comme un bras, une jambe ou une autre partie de l'objet complet. La structure AnimOb contient la position initiale de l'objet, sa vitesse et son accélération dans les directions X et Y, un pointeur vers le premier d'une liste liée d'AnimComp et un pointeur vers une routine d'animation spéciale. L'AnimComp contient un pointeur vers l'AnimComp suivant dans la séquence et une synchronisation pour indiquer au système quand il doit changer. Une fois les deux structures mises en place, l'appel de la fonction Animate permet de lancer l'animation.
Le système d'animation Amiga gère le dessin séquentiel et le contrôle des mouvements, qui peuvent être utilisés séparément ou ensemble. Dans le dessin séquentiel, chaque vue est une modification de la vue précédente. Ceci est particulièrement utile avec une animation de nature cyclique, comme la marche. Une étape dans une séquence de marche serait un dessin séquentiel. Pour donner l'impression que l'objet est en mouvement, chaque nouvelle vue est positionnée plus loin d'un point de référence commun. Une fois que l'animation a terminé un cycle, l'AnimOb doit être déplacée d'une certaine distance pour que le mouvement apparent reste fluide. Cette distance est contenue dans la structure AnimOb.
L'animation à contrôle de mouvement spécifie des objets dont la vitesse et l'accélération peuvent être contrôlées indépendamment. Les valeurs de vitesse et d'accélération sont traitées comme des fractions binaires à virgule fixe de 16 bits ayant la forme "vvvvvwvvv.ffffff". La vitesse la plus lente possible est d'un pixel toutes les 64 images. Chaque appel à Animate entraîne l'ajout des valeurs d'accélération aux vitesses.
La priorité de dessin des objets AnimObs est déterminée par la priorité des BOB qui les composent. Le système d'animation met automatiquement à jour la préséance dans les structures BOB pour chaque image afin de refléter l'ordre de la première séquence. Si plus d'une AnimOb est à l'écran, un objet complet peut avoir la préséance sur un autre en reliant le dernier BOB de la première AnimOb au premier BOB de la deuxième AnimOb. De cette façon, vous pouvez faire en sorte qu'un objet semble passer devant un autre.
Les structures AnimOb et AnimComp peuvent toutes deux contenir des pointeurs vers des routines fournies par l'utilisateur qui sont appelées chaque fois que Animate() est appelé et qui peuvent provoquer tout changement dans la séquence d'animation.
Synchronisation
Pour animer un objet sur Amiga sans scintillement, il faut comprendre comment l'image se forme sur l'écran. L'écran entier est réaffiché 60 fois par seconde. La période de temps entre le dessin de la dernière ligne de l'écran précédent et la première ligne de l'écran suivant est appelée le "Vertical Blank" (rafraîchissement verticale). Pendant la période de rafraîchissement vertical sur l'Amiga, les sprites, le Copper et les pointeurs de plan de bits sont initialisés pour l'écran d'affichage suivant. L'écran est alors généré de haut en bas, de gauche à droite.
Le scintillement est causé par la modification d'une zone d'affichage au moment même où la zone est écrite à l'écran. Pour éviter ce phénomène, vos routines d'animation doivent effectuer toutes les mises à jour avant que le faisceau n'atteigne la zone d'affichage ou après que le faisceau ait quitté la zone d'affichage. La position actuelle du faisceau peut être déterminée en appelant la routine "VBeamPos".
Dans le cadre du système multitâche de l'Amiga, chaque tâche dispose de 4/60e secondes pour s'exécuter avant d'être préemptée pour exécuter la tâche suivante de même priorité. Cela peut perturber toute tentative d'animation fluide, car vos routines d'animation peuvent ne pas être exécutées dans un laps de temps régulier. Une méthode pour contourner ce problème est d'augmenter la priorité de votre tâche d'animation à un niveau élevé ou d'utiliser la fonction "Forbid()" pour déjouer le système multitâche et permettre à l'animation de s'exécuter exclusivement dans l'Amiga.
Une autre méthode consiste à attacher une sous-routine à la chaîne d'interruption du rafraîchissement vertical. Cela incrémente un compteur, qui peut ensuite être vérifié pour déterminer le nombre d'images qui ont été affichées depuis la dernière mise à jour de l'animation. Les routines d'animation peuvent alors utiliser cette valeur pour positionner correctement les objets d'animation.
Utilisation de la mémoire
Dans l'une de nos applications, nous avons un arrière-plan défilant qui fait quatre écrans de large et cinq plans de bits de profondeur, ce qui nécessite un total de 160 000 octets. Nous utilisons six sprites pour former une image mobile. Chaque étape de l'animation utilise environ 1 ko. Si l'image animée comporte 40 étapes, l'image et les données d'arrière-plan consommeront à elles seules 200 000 octets de mémoire.
Comme vous pouvez le constater, il est pratiquement impératif d'ajouter l'extension de mémoire supplémentaire de 256 ko aux 256 ko internes de l'Amiga 1000 pour accueillir le système d'exploitation et tout morceau significatif d'animation. Actuellement, seuls les 512 ko inférieurs de mémoire sont disponibles pour le matériel des puces spécialisées. Si de la mémoire supplémentaire est ajoutée via le bus 68000, l'accès aux données d'image à partir de là sera plus lent que l'accès aux données stockées dans les 512 ko inférieurs car toutes les données d'image et de son doivent encore être transférées dans les 512 ko inférieurs pour être utilisées.
Matériel et méthodes
Nous souhaitons décrire brièvement la manière dont nous avons développé notre animation sur Amiga. Nous utilisons le compilateur croisé Lattice IBMPC-to-Amiga ainsi que l'assembleur et l'éditeur de liens de MetaComCo pour développer nos programmes. Nous avons écrit notre propre programme de transfert parallèle PC-Amiga car nous avons trouvé que celui fourni avec la trousse de développement Amiga était trop lent. Le développement de gros programmes sur Amiga lui-même sera difficile jusqu'à ce que de la mémoire supplémentaire et un bon disque dur soient disponibles. Des débogueurs adéquats pour l'Amiga commencent seulement à être disponibles dans le commerce.
Les dessins de notre animation ont été réalisés avec Deluxe Paint d'Electronic Arts. Une fois encore, nous avons écrit nos propres routines pour extraire les données du fichier IFF généré par Deluxe Paint et les convertir directement en fichier assembleur. Nous avons ensuite utilisé les structures et les fonctions décrites précédemment pour programmer les animations.
Conclusion
La mécanique de la création de graphismes animés peut être assez difficile et le résultat ne vaut que ce que vous voyez à la fin. Si la roue d'une voiture dans une séquence animée tourne trop vite par rapport à la vitesse de l'arrière-plan qui passe, l'animation ne reflétera pas ce que vous vouliez qu'elle reflète. Une bonne animation est créée par l'artiste et le programmeur qui poussent le système à ses limites pour produire des effets visuels. A cet égard, les possibilités d'animation sur Amiga sont très intéressantes.
Glossaire
AnimOb : structure de données qui rassemble plusieurs AnimComp dans un objet entier.
AnimComp : extension d'un BOB lui permettant de fonctionner comme une partie d'une AnimOb.
Bit Map : structure qui contient des pointeurs vers des plans de bits et définit la largeur et la profondeur des données du plan de bits.
Plan de bits : zone de mémoire qui définit la couleur des pixels affichés à l'écran. Chaque plan de bits multiplie par 2 le nombre de couleurs possibles de l'affichage. Si un plan de bits est utilisé pour un affichage, seules deux couleurs sont possibles. Si deux plans de bits sont utilisés, quatre couleurs sont possibles. Un maximum de cinq plans de bits peut être utilisé dans un affichage à basse résolution et quatre plans de bits dans un affichage à haute résolution.
Blitter : dispositif matériel spécialisé qui effectue la copie de données à grande vitesse et le dessin de lignes. Le Blitter peut effectuer jusqu'à 256 opérations logiques sur trois sources de données tout en réalisant une copie vers une destination.
BOB : objet Blitter qui est une version logicielle du sprite matériel. Les BOB ne sont pas limités par la taille ou les couleurs d'un sprite.
Mémoire Chip : les 512 ko inférieurs de mémoire sur l'Amiga, qui peuvent être accédés directement par les puces spécialisées.
Color Map : Carte des couleurs, une liste des valeurs rouges, vertes et bleues qui sont attachées à un ViewPort et chargées dans les registres de couleur de l'Amiga lorsque ce ViewPort est affiché.
Copper : l'une des puces coprocesseur spécialisées de l'Amiga, elle contrôle l'ensemble du système graphique. Le Copper peut modifier les registres, repositionner les sprites, changer la palette de couleurs, mettre à jour les canaux audio et contrôler le Blitter. Le Copper libère le 68000 pour exécuter la logique du programme plutôt que de mettre à jour l'affichage. Le Copper n'a que trois commandes : WAIT (attente jusqu'à ce que le faisceau atteigne une position d'écran spécifique), MOVE (déplace une valeur dans un registre) et SKIP (passe à l'instruction suivante si le faisceau a dépassé une position d'écran spécifique).
GEL : élément graphique qui peut être manipulé par les routines d'animation graphique du noyau de l'Amiga. Les VSprites, BOB, AnimComps et AnimObs sont tous des GEL.
IFF : Interchange Format File, le format standard pour les données écrites dans les fichiers sur Amiga. Cette norme permet d'échanger facilement des données entre les outils de développement et les produits.
Minterm : valeur de 8 bits qui détermine les opérations logiques à effectuer par le Blitter pendant une opération de transfert de données.
RastPort : structure de données qui contient des informations nécessaires pour manipuler l'affichage graphique avec les routines du noyau en ROM de l'Amiga. Les couleurs du stylo, le mode de dessin, le motif de remplissage de la zone, les attributs du texte, la police, la position du stylo et le motif de la ligne sont stockés dans le RastPort.
Sprite : objet graphique matériel qui est défini et manipulé indépendamment de l'affichage de fond. L'Amiga possède huit sprites de 16 pixels de large sur un nombre quelconque de lignes de haut. Chaque sprite peut avoir quatre couleurs, ou deux sprites peuvent être attachés pour un sprite de 16 couleurs. Faire défiler l'arrière-plan ou afficher plus de 320 pixels par ligne en basse résolution ou 640 pixels par ligne en haute résolution rend les deux derniers sprites inutilisables.
View : Vue, structure qui définit un affichage complet de l'écran. Une vue contient un pointeur vers une liste de ViewPorts et les décalages X et Y de cet écran.
Viewport : structure qui définit une section horizontale de l'écran. Plusieurs fenêtres peuvent être affichées sur un seul écran s'il y a au moins une ligne blanche entre les fenêtres. Chaque fenêtre contient une carte de couleurs, un mode d'affichage, une largeur, une hauteur, un décalage X et un décalage Y uniques pour sa partie de l'écran. Un arrière-plan défilant peut être créé en modifiant les décalages X et Y contenus dans la structure ViewPort.
VSprite : sprite virtuel, la méthode de description des sprites matériels réels à utiliser dans le système d'animation Amiga.
Les auteurs
Elaine A. Ditton et Richard A. Ditton (Free-Radical Software, 1323 South Yale Ave., Arlington Heights, IL 60005) sont président et vice-président de Free-Radical Software, une société spécialisée dans les logiciels grand public et le conseil en infographie.
|
