Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/07103.jsonl.gz/311

Sprites et clavier
Gameboj – Étape 10
1 Introduction
Le but de cette étape est d'une part de terminer le composant simulant le contrôleur LCD, afin de lui ajouter la gestion des sprites, et d'autre part d'écrire le composant simulant le clavier du Game Boy.
Comme cela a déjà été dit à plusieurs reprises, un sprite — parfois appelé lutin en français — est une petite image qui peut être placée n'importe où à l'écran et qui est utilisée pour les éléments mobiles des jeux : personnages, projectiles, etc. Le contrôleur LCD du Game Boy peut gérer un total de 40 sprites de 8×8 ou 8×16 pixels, dont les caractéristiques sont stockées dans une mémoire dédiée, décrite ci-dessous.
1.1 Mémoire d'attributs d'objets
En plus de la mémoire vidéo présentée à l'étape précédente, le contrôleur LCD possède une seconde mémoire vive, nommée mémoire d'attributs d'objets (object attribute memory ou OAM). Le nom de cette mémoire provient du fait que la documentation officielle du Game Boy nomme les sprites des objets (objects). Autant que possible, nous utiliserons ici le terme de sprite, d'une part car il est plus standard, et d'autre part car il prête moins à confusion.
1.1.1 Contenu
La mémoire d'attributs d'objets contient 160 octets, visibles sur le bus entre les adresses FE0016 et FEA016 (exclu). Ces 160 octets permettent de stocker les attributs de 40 sprites, numérotés de 0 à 39. Les attributs d'un sprite sont donc constitués de 4 octets qui, dans l'ordre dans lequel ils apparaissent en mémoire, sont :
- la coordonnée y du sprite à l'écran,
- la coordonnée x du sprite à l'écran,
- l'index de la tuile à utiliser pour l'image du sprite,
- un octet contenant quatre caractéristiques binaires, décrites plus bas.
Les coordonnées du sprite sont stockées avec un décalage, de sorte que pour obtenir la coordonnée à l'écran du pixel haut-gauche du sprite, il faut soustraire 8 de la coordonnée x donnée, et 16 de la coordonnée y. Cette convention peut paraître étrange mais elle garantit que toutes les coordonnées sont positives, même lorsque les sprites ne sont que partiellement visibles à l'écran, ce qui évite d'avoir à se préoccuper de problèmes de signe.
L'index de la tuile désigne toujours une des 256 tuiles situées dans la plage comprise entre les adresses 800016 et 900016 (exclu). L'index 0 correspond à la tuile dont l'image commence à l'adresse 800016, l'index 1 à la tuile dont l'image commence à l'adresse 801016, et ainsi de suite. En d'autres termes, cet index est interprété exactement comme celui des tuiles composant l'image de fond et la fenêtre lorsque le bit
TILE_SOURCE du registre
LCDC vaut 1. Dès lors, les 128 tuiles dont l'image se trouve dans la plage comprise entre les adresses 900016 et 980016 (exclu) ne sont pas utilisables pour les sprites.
Le dernier octet des attributs ne contient que 4 bits utiles, qui décrivent différentes caractéristiques du sprite. Leur signification est résumée dans la table suivante :
|Bit||Nom||Signification|
|4||
||Palette à utiliser pour le sprite (

|5||
||Inversion horizontale de l'image du sprite|
|6||
||Inversion verticale de l'image du sprite|
|7||
||Plan auquel appartient le sprite (arrière ou avant)|
Les quatre bits de poids faible, d'index 0 à 3, sont inutilisés.
Le bit
PALETTE indique la palette à utiliser pour transformer les couleurs du sprite. S'il vaut 0, alors la palette contenue dans le registre
OBP0 du contrôleur LCD est utilisée, sinon c'est celle contenue dans le registre
OBP1 qui l'est.
Les bits
FLIP_H et
FLIP_V indiquent respectivement si l'image du sprite doit être inversée horizontalement ou verticalement. Si un de ces bits vaut 1, alors l'image est inversée dans la direction correspondante, sinon elle ne l'est pas.
Finalement, si le bit
BEHIND_BG vaut 1, le sprite est à l'arrière-plan, c-à-d que son image apparaît derrière celle de l'image de fond. Les autres sprites sont à l'avant-plan, et leur image apparaît devant celle de fond.
1.1.2 Copie rapide
Pour afficher des sprites à l'écran, il est nécessaire de remplir la mémoire d'attributs d'objets avec les données leur correspondant. Ce remplissage peut se faire de différentes manières, entre autres en copiant une zone de 160 octets depuis une mémoire quelconque — p.ex. la mémoire morte de la cartouche — vers la mémoire d'attributs d'objets.
Une telle copie peut bien entendu être faite par le programme exécuté par le processeur, au moyen d'une boucle copiant les octets les uns après les autres. Toutefois, une boucle de ce type nécessite plus de 10 cycles par octet copié, ce qui est coûteux.
Pour accélérer une telle copie, les concepteurs du Game Boy ont donc intégré au contrôleur LCD un mécanisme dédié à la copie rapide de 160 octets depuis une adresse (presque) quelconque vers la mémoire d'attributs d'objets. Ce mécanisme peut copier un octet par cycle et est donc plus de 10 fois plus rapide qu'une boucle équivalente exécutée par le processeur.
Afin obtenir ces excellentes performances, le contrôleur LCD accède directement à la mémoire — au bus, en réalité —, pour y lire les données à copier. Pour cette raison, on nomme ce mécanisme un accès direct à la mémoire (direct memory access ou DMA).
Pour demander au contrôleur LCD de démarrer une copie par accès direct à la mémoire, il suffit d'écrire une valeur dans son registre
DMA. Cette valeur donne les 8 bits de poids fort de l'adresse depuis laquelle les données doivent être copiées, les 8 bits de poids faible valant implicitement 0. Le contrôleur LCD copie alors 1 octet par cycle jusqu'à ce qu'il en ait copié 160 et rempli ainsi totalement la mémoire d'attributs d'objets.
Par exemple, si à un cycle donné, la valeur 4116 est écrite dans le registre
DMA, alors le contrôleur LCD va copier les 160 octets compris entre l'adresse 410016 et 41A016 (exclu) dans la mémoire d'attributs d'objets, c-à-d aux adresses FE0016 à FEA016.
Il faut noter que sur le Game Boy réel le bus est totalement monopolisé par le contrôleur LCD lorsqu'une telle copie est en cours, et le processeur n'y a plus accès. Il ne peut donc même plus lire les instructions qu'il doit exécuter, sauf si celles-ci proviennent de sa mémoire haute, car il peut accéder à cette dernière sans passer par le bus. Les programmes utilisant le DMA pour effectuer des copies exécutent donc durant ce temps un programme placé dans la mémoire haute et qui ne fait généralement rien d'autre qu'attendre durant 160 cycles.
Cette limitation de l'accès au bus n'a aucune influence sur notre simulation, et nous ne tenterons donc pas de la reproduire.
1.2 Dessin des sprites
Comme nous l'avons vu, le contrôleur LCD calcule l'image à afficher à l'écran ligne par ligne. Le contenu de chaque ligne est déterminé en composant l'image de fond, la fenêtre et les sprites. Chacune de ces composantes peut être activée ou non par un bit dans le registre
LCDC, qui dans le cas des sprites est le bit
OBJ (1).
Pour comprendre la manière dont les sprites sont dessinés puis combinés avec l'image de fond et la fenêtre, il est bon de considérer que chaque ligne affichée est le résultat de la superposition de trois lignes calculées indépendamment :
- la ligne des sprites d'arrière-plan,
- la ligne de l'image de fond et de la fenêtre,
- la ligne des sprites d'avant-plan.
La manière dont la ligne de l'image de fond et la fenêtre est calculée a été décrite à l'étape précédente ; la manière dont les lignes de sprites le sont est décrite ci-dessous.
Avant d'examiner le calcul des lignes de sprite, il faut toutefois noter qu'en raison d'une limitation matérielle, un maximum de 10 images de sprites peuvent être combinées pour une ligne donnée. Dès lors, s'il y a plus de 10 sprites dont l'image intersecte une ligne, seuls les 10 premiers — dans l'ordre de leur index, et indépendamment du fait qu'ils soient à l'arrière- ou à l'avant-plan — sont pris en compte.
1.2.1 Calcul des lignes de sprites
La ligne des sprites d'un plan donné — arrière- ou avant-plan — est calculée par superposition des images de tous les sprites de ce plan. Bien entendu, avant d'être superposées, les images des sprites sont placées horizontalement sur la ligne en fonction de leur coordonnée x, et la palette spécifique au sprite —
OBP0 ou
OBP1, en fonction du bit
PALETTE — est appliquée à leurs couleurs. Cela fait, elles sont empilées selon l'ordre donné par :
- la coordonnée x du sprite, puis, en cas d'égalité,
- l'index du sprite,
la première se trouvant au sommet de la pile, c-à-d devant les autres.
Par exemple, admettons que les images des sprites d'index 0 à 15 aient une intersection avec la ligne à dessiner. En raison de la limitation susmentionnée, seuls les 10 premiers sont pris en compte, c-à-d ceux ayant les index 0 à 9 (inclus). Admettons maintenant que ces 10 sprites aient les caractéristiques suivantes — où le type est soit B (background) pour les sprites d'arrière-plan, soit F (foreground) pour ceux d'avant-plan :
|index||0||1||2||3||4||5||6||7||8||9|
|coordonnée x||50||40||30||20||20||30||40||50||20||20|
|type||B||F||F||B||B||F||F||F||B||B|
En triant ces sprites selon l'ordre décrit ci-dessus — coordonnée x d'abord, index ensuite — on obtient les index : 3, 4, 8, 9, 2, 5, 1, 6, 0, 7. Une fois ordonnés, ces index peuvent être séparés en deux listes ordonnées contenant :
- les index de sprites d'arrière-plan : 3, 4, 8, 9, 0,
- les index de sprites d'avant-plan : 2, 5, 1, 6, 7.
Le sprite d'index 3 est donc celui qui est au sommet de la pile des sprites d'arrière-plan, c-à-d que son image se trouve devant celle des autres sprites de ce plan. Sous cette image se trouve celle du sprite d'index 4, et ainsi de suite. Pour les sprites d'avant-plan, celui d'index 2 est au sommet de la pile, donc devant les autres, et ainsi de suite.
La manière dont la ligne des sprites d'arrière plan est combinée avec celle de l'image de fond est subtile et mérite d'être détaillée.
Jusqu'à présent, nous avions (implicitement) supposé que tous les pixels de l'image de fond/fenêtre étaient opaques, car aucune autre image ne pouvait être affichée derrière elle. Or les sprites d'arrière-plan changent la donne, puisqu'ils sont justement derrière l'image de fond.
La question se pose donc de savoir comment composer l'image de fond et les sprites d'arrière-plan, en particulier dans le cas où les deux contiennent des pixels transparents superposés.
La règle utilisée sur le Game Boy est la suivante : les pixels opaques des sprites d'arrière-plan (et eux seuls) sont visibles à travers les pixels transparents de l'image de fond. En d'autres termes, les pixels transparents de l'image de fond ne le sont réellement que si au moins un pixel opaque d'un sprite d'arrière-plan se trouve derrière eux, sans quoi ils sont opaques.
Par exemple, admettons qu'un pixel de l'image de fond ait, avant application de la palette, la couleur 0. Comme nous l'avons vu à l'étape 8, ces pixels sont toujours ceux qui sont considérés transparents sur le Game Boy. Si derrière un tel pixel se trouve un pixel opaque d'un sprite d'arrière plan, disons de couleur 2, alors le pixel résultant de leur combinaison aura la couleur 2, qui sera celle visible à l'écran. Par contre, si derrière ce pixel transparent de l'image de fond ne se trouve aucun pixel opaque d'un sprite d'arrière-plan, alors le pixel résultant de leur combinaison sera celui de l'image de fond, considéré opaque ! Sa couleur finale sera donc celle résultant de la transformation de la couleur 0 par la palette de l'image de fond.
1.2.3 Hauteur des sprites
Les images des sprites du Game Boy font généralement 8×8 pixels, mais il est aussi possible de faire en sorte qu'elles aient une taille de 8×16 pixels, en mettant à 1 le bit
OBJ_SIZE du registre
LCDC.
Lorsque les sprites font 16 pixels de haut, leur image est constituée de deux tuiles superposées : celle du haut est celle dont l'index est donné dans les attributs du sprite, qui doit être pair, celle du bas est celle d'index suivant.
Par exemple, si le bit
OBJ_SIZE du registre
LCDC vaut 1 et qu'un sprite utilise la tuile d'index 20, alors la partie supérieure de son image est celle de la tuile 20, tandis que sa partie inférieure est celle de la tuile 21.
1.3 Clavier
Le clavier du Game Boy, nommé joypad en anglais, est très simple et composé de 8 boutons :
- quatre boutons de direction (haut, bas, gauche et droite), organisés en une croix directionnelle,
- deux boutons d'action nommés A et B,
- deux boutons nommés Select et Start.
Au niveau électronique, ces boutons sont organisés en une matrice de deux lignes de quatre boutons chacune, de la manière suivante :
|0||1||2||3|
|0||droite||gauche||haut||bas|
|1||A||B||Select||Start|
Cette organisation influence la manière dont l'état du clavier — c-à-d les boutons qui sont actuellement pressés — peut être lu par le programme s'exécutant sur le Game Boy, comme décrit ci-après.
L'état du clavier est encodé sous la forme d'un octet, stocké dans un registre nommé
P1 et visible sur le bus à l'adresse FF0016. Les différents bits de ce registre ont la signification suivante :
|Bit||Signification|
|0||État de la colonne 0|
|1||État de la colonne 1|
|2||État de la colonne 2|
|3||État de la colonne 3|
|4||Sélection de la ligne 0|
|5||Sélection de la ligne 1|
|6||aucune, vaut toujours 1|
|7||aucune, vaut toujours 1|
Notez que tous les bits de ce registre ont une signification inversée par rapport aux conventions habituelles, comme nous allons le voir ci-dessous. Cela signifie que ce qui est généralement représenté par un 1 l'est par un 0 dans ce registre, et inversément.
Les bits d'état (0 à 3) sont accessibles en lecture seule depuis le bus, c-à-d que leur valeur est préservée lors d'une écriture à l'adresse du registre
P1.
Les bits de sélection (4 et 5) sont accessibles en lecture et en écriture depuis le bus, et déterminent la ou les lignes dont les boutons influencent les bits d'état.
Lorsque le bit de sélection d'une ligne vaut 0, la ligne en question est sélectionnée et les 4 touches appartenant à cette ligne influencent chacune le bit d'état correspondant à sa colonne : celui-ci vaut 0 si la touche en question est pressée, 1 sinon.
Lorsque les deux bits de sélection valent 0, les deux lignes sont sélectionnées et deux touches influencent alors le même bit d'état. Si au moins l'une d'entre elles est pressée, alors ce bit vaut 0, sinon il vaut 1.
Finalement, si aucun bit de sélection ne vaut 0, alors aucune ligne n'est sélectionnée, et tous les bits d'état valent 1.
Par exemple, admettons qu'à un moment donné les touches A et haut sont pressées, et que le bit de sélection de la ligne 0 (bit 4) vaut 1 tandis que celui de la ligne 1 (bit 5) vaut 0. Comme seule la ligne 1 est sélectionnée, seule la touche A influence les bits d'état, qui valent alors
1110 (du poids fort au poids faible). Le contenu complet du registre est donc
11011110.
Lorsque, suite à la pression d'une touche, l'un des bits d'état (bits 0 à 3) passe de 1 à 0, alors le clavier lève l'interruption
JOYPAD (4) du processeur.
2 Mise en œuvre Java
La mise en œuvre Java de cette étape consiste à terminer la classe
LcdController, écrire la classe
Joypad représentant le clavier et finalement compléter la classe
GameBoy.
2.1 Classe
LcdController
Les ajouts à effectuer à la classe
LcdController sont en gros au nombre de quatre :
- La méthode
attachTodoit être redéfinie comme celle de la classe
Cpu, afin que le contrôleur LCD ait la possibilité d'effectuer des lectures depuis le bus, nécessaires lorsqu'une copie par accès direct à la mémoire (DMA) est en cours.
- Les méthodes
readet
writedoivent être augmentées afin de donner accès à la mémoire d'attributs d'objets. Comme toujours, l'interface
AddressMapcontient des constantes désignant l'adresse de début (
OAM_START), l'adresse de fin (exclue,
OAM_END) et la taille (
OAM_RAM_SIZE) de cette mémoire. Notez que
writedoit également démarrer le processus de copie si une écriture est faite dans le registre
DMA.
- La méthode
cycledoit être augmentée pour copier le prochain octet vers la mémoire d'attributs d'objets lorsqu'une copie par accès direct à la mémoire est en cours.
- La méthode
computeLine(ou équivalent) doit être augmentée afin de calculer les lignes de sprite d'arrière-plan et d'avant-plan, et de les combiner à la ligne de l'image de fond déjà calculée.
Les trois premiers ajouts ne devraient pas poser de problème particulier, le quatrième mérite quelques conseils, donnés ci-après.
2.1.1 Conseils de programmation
Avant de donner des conseils spécifiques, nous vous rendons attentifs au fait que le code — pas totalement trivial — permettant d'obtenir l'octet correspondant aux 8 bits de poids fort ou faible d'une ligne donnée d'une tuile donnée est quasi-identique pour l'image de fond, la fenêtre et les sprites. Il paraît donc raisonnable de l'extraire dans une méthode séparée.
- Calcul des sprites à afficher
Le calcul des sprites à afficher sur une ligne donnée pourra être confié à une méthode spécifique, nommée p.ex.
spritesIntersectingLineet retournant un tableau contenant les index des (au plus 10) sprites dont l'image intersecte la ligne donnée, triés selon l'ordre d'empilement.
Une manière relativement simple et rapide de calculer ce tableau consiste à construire un premier tableau de 10 éléments de type
int. Chacun de ces éléments contient deux informations empaquetées : dans les bits de poids fort, la coordonnée x du sprite, dans les bits de poids faible son index. Ce tableau est rempli avec les informations correspondant aux (au plus 10) premiers sprites ayant une intersection avec la ligne donnée. Ensuite, il est trié en ordre croissant ce qui, étant donné la technique d'empaquetage choisie, équivaut à le trier selon l'ordre d'empilement décrit plus haut. Finalement, un nouveau tableau contenant uniquement les index des sprites, dans l'ordre donné par le tri, est retourné.
Pour effectuer le tri, notez que la classe
Arraysoffre une méthode permettant de trier seulement une partie d'un tableau d'entiers.
- Calcul de la ligne d'un sprite individuel
Le calcul de la ligne correspondant à un sprite unique peut se faire très facilement en utilisant de manière judicieuse les méthodes de la classe
LcdImageLine. L'idée de base est la suivante :
- construire une ligne de 160 pixels de long ayant l'image du sprite dans son premier octet — c-à-d positionnée tout à gauche de la ligne —, tous les autres bits valant 0,
- décaler cette ligne pour placer correctement l'image du sprite dans la ligne, en pensant bien au sens dans lequel effectuer ce décalage (!),
- transformer les couleurs de la ligne au moyen de la palette appropriée.
Cette ligne correspondant à un sprite individuelle peut ensuite être superposée à celles des autres sprites appartenant au même plan, dans le bon ordre, afin d'obtenir la ligne correspondant à ce plan-là.
- Composition de la ligne des sprites d'arrière-plan
La manière dont la ligne des sprites d'arrière-plan est composée avec celle de l'image de fond a été décrite à la §1.2.2 et peut sembler complexe. En réalité, elle est très simple à mettre en œuvre si on se rappelle qu'un pixel de la ligne de l'image de fond n'est réellement transparent que si :
- il l'est « à l'origine » (c-à-d son opacité est fausse), et
- le pixel de la ligne des sprites d'arrière-plan correspondant est opaque.
Cette condition s'exprime très facilement au moyen d'opérations bit à bit sur les vecteurs de bits représentant l'opacité des deux lignes en question, qui permettent de calculer l'opacité à utiliser pour effectuer leur superposition. Une fois ce vecteur d'opacité calculé, il suffit de le passer à la variante de la méthode
belowde la classe
LcdImageLineprenant explictement une opacité en argument.
- Taille des sprites
La gestion des sprites de 16 pixels de haut peut sembler difficile à première vue, mais il n'en est rien. En effet, étant donné la manière dont les images des tuiles sont organisées en mémoire, la première ligne de l'image d'une tuile peut aussi être vue comme la neuvième ligne de la tuile précédente, la seconde comme la dixième de la tuile précédente, et ainsi de suite.
En conséquence, les deux seuls moments auxquels il est nécessaire de tenir compte de la hauteur des sprites dans le code sont :
- lors du calcul de l'ensemble des sprites dont l'image intersecte la ligne en cours de dessin,
- lors de la gestion du retournement vertical des sprites.
2.2 Classe
Joypad
La classe
Joypad (ou équivalent), du paquetage
ch.epfl.gameboj.component, représente le clavier. Etant donné que cette classe simule un composant attaché au bus, elle implémente l'interface
Component. Son constructeur prend en argument le processeur du Game Boy auquel le clavier appartient, dont elle a besoin pour lever des interruptions.
Les méthodes
read et
write ne font rien d'autre que donner accès au registre
P1 dont la valeur est déterminée de la manière décrite plus haut. Notez que l'adresse de ce registre est comme d'habitude définie par une constante de l'interface
AddressMap, dans ce cas
REG_P1.
En plus de ces méthodes
read et
write, la classe
Joypad offre deux méthodes publiques, nommées p.ex.
keyPressed et
keyReleased et permettant à ses utilisateurs de simuler la pression et le relâchement d'une touche. Chacune prend en argument la touche concernée, représentée par un élément d'une énumération publique imbriquée dans la classe
Joypad, nommée p.ex.
Key et contenant un élément par touche (
RIGHT,
LEFT,
UP,
DOWN,
A,
B,
SELECT et
START).
2.2.1 Conseils de programmation
Le fait que les bits du registre
P1 aient la signification inverse de la signification habituelle peut rendre le code difficile à comprendre. Une manière simple de résoudre ce problème consiste à l'ignorer dans la plupart du code, et à inverser (au moyen de
Bits.complement8) les bits de la valeur lue/écrite sur le bus.
D'autre part, il faut noter que, d'une manière ou d'une autre, il est nécessaire de stocker l'ensemble des touches pressées dans un ou plusieurs attributs de la classe
Joypad, car le contenu du registre
P1 ne suffit pas à lui tout seul pour savoir quelles touches sont pressées. Une manière simple de représenter cet ensemble consiste à avoir un entier de type
int pour chaque ligne de touches, dans lequel un bit est à 1 si et seulement si la touche dont la colonne correspondante est pressée. La valeur du registre
P1 peut très facilement en être déduite.
2.3 Classe
GameBoy
La classe
GameBoy doit être complétée pour ajouter un clavier (c-à-d une instance de
JoyPad) au système. Cela implique de :
- créer une instance de
Joypaddans le constructeur et l'attacher au bus,
- ajouter une méthode d'accès permettant d'obtenir cette instance de
Joypad.
De plus, afin de terminer totalement la classe
GameBoy, deux attributs publiques, statiques et finaux doivent y être ajoutés :
- le premier de type
longdonnant le nombre de cycles exécutés par seconde, qui pour mémoire vaut 220,
- le second de type
doubledonnant le nombre de cycles exécutés par nanoseconde.
Cela fait, la classe
GameBoy est enfin complète, et ne changera plus jusqu'à la fin du projet.
2.4 Tests
Pour tester votre code, vous pouvez utiliser une version modifiée du programme de test de l'étape précédente. Nous vous en proposons une ci-après, libre à vous de l'adapter à vos besoins.
Le programme ci-dessous attend un seul argument sur la ligne de commande, qui est le fichier ROM à utiliser. Il simule d'abord 30 millions de cycles, puis poursuit la simulation durant une seconde avec la touche A pressée, et une dernière seconde sans la touche A pressée. Ce petit scénario convient bien aux deux tests proposés plus bas.
public final class DebugMain3 { private static final int[] COLOR_MAP = new int[] { 0xFF_FF_FF, 0xD3_D3_D3, 0xA9_A9_A9, 0x00_00_00 }; public static void main(String[] args) throws IOException { File romFile = new File(args[0]); long cycles = 30_000_000; GameBoy gb = new GameBoy(Cartridge.ofFile(romFile)); gb.runUntil(cycles); gb.joypad().keyPressed(Key.A); gb.runUntil(cycles + (1L << 20)); gb.joypad().keyReleased(Key.A); gb.runUntil(cycles + 2 * (1L << 20)); LcdImage li = gb.lcdController().currentImage(); BufferedImage i = new BufferedImage(li.width(), li.height(), BufferedImage.TYPE_INT_RGB); for (int y = 0; y < li.height(); ++y) for (int x = 0; x < li.width(); ++x) i.setRGB(x, y, COLOR_MAP[li.get(x, y)]); ImageIO.write(i, "png", new File("gb.png")); } }
En exécutant ce programme de test en lui passant le fichier ROM de Flappy Boy, vous devriez voir l'image ci-dessous, sur laquelle plusieurs sprites sont utilisés pour représenter l'oiseau volant au milieu de l'image :
Figure 1 : Flappy Boy
En plus de cela, nous mettons à votre disposition une archive Zip contenant une ROM de test provenant du projet mooneye-gb de Joonas Javanainen. Le programme qu'elle contient, visible sur github, vérifie que les sprites sont dessinés dans le bon ordre. Avec le programme ci-dessus, vous devriez obtenir l'image suivante :
Figure 2 : Test de l'ordre de dessin des sprites
3 Résumé
Pour cette étape, vous devez :
- écrire la classe
Joypad(ou équivalent) et terminer les classes
LcdControlleret
GameBoyen fonction des indications données plus haut,
- tester votre code,
- documenter la totalité des entités publiques que vous avez définies.
Aucun rendu n'est à faire pour cette étape avant le rendu final. N'oubliez pas de faire régulièrement des copies de sauvegarde de votre travail en suivant nos indications à ce sujet.