Added:

validation/guests/guest_sprites_phys.bin
validation/guests/guest_sprites_pv.bin
Updated lab-virtual_game_machine.md with new guests for sprite validation

labs/lab-virtual_game_machine/lab-virtual_game_machine.md

@@ -62,7 +62,7 @@ Les sous-sections qui suivent décrivent le but et les fonctionnalités de chaqu
 
 **IMPORTANT**
 
-Le binaire du guest OS fourni est généré de sorte à ce qu'il soit chargé à l'adresse physique 0. Il est donc requis que celui-ci soit chargé à l'adresse 0 dans la machine virtuelle, sinon il ne fonctionnera pas correctement.
+Le binaire du guest OS fourni est généré de sorte à ce qu'il soit chargé à l'adresse physique 0. Il est donc requis que celui-ci soit chargé à l'adresse 0 dans la machine virtuelle, sinon il ne fonctionnera pas.
 
 ### Mécanisme d'hypercall
 
@@ -71,11 +71,11 @@ L'espace de mémoire partagée, faisant office de buffer pour les hypercalls, do
 
 ### (1) Console virtuelle
 
-Ce périphérique est uniquement exposé virtuellement (c'est à dire de manière paravirtualisée). Il permet au guest de demander au VMM d'afficher un message (une chaîne de caractères) sur une console virtuelle. Cette console virtuelle est simplement la sortie standard du VMM.
+Ce périphérique est uniquement exposé virtuellement (c'est à dire de manière paravirtualisée). Il permet au guest de demander au VMM d'afficher un message (une chaîne de caractères) sur une console virtuelle. Cette console virtuelle est simplement la sortie standard (`stdout`) du VMM.
 
 **Comportement du VMM**
 
-Le VMM affiche le texte spécifié par le guest sur la sortie standard. Attention, par défaut, la sortie standard (`stdout`) est bufferisée. Le texte écrit sur la sortie standard est *flushé* dans le terminal lorsque le caractère `\n` est rencontré ou lorsque le buffer interne lié à `stdout` est plein. La sortie standard peut être "débufférisée" avec le code suivant\ :
+Le VMM affiche le texte spécifié par le guest sur la sortie standard. Attention, par défaut, la sortie standard (`stdout`) est bufferisée. Le texte écrit sur la sortie standard est *flushé* dans le terminal lorsque le caractère `\n` est rencontré ou lorsque le buffer interne lié à `stdout` est plein. La sortie standard peut être "débufférisée" avec le code C suivant\ :
 
 \small
 ```{.c}
@@ -426,9 +426,9 @@ Le code lié au guest se trouve dans le répertoire `guest`. Voici la descriptio
 
 **Sprites**
 
-Le guest ne possède aucun moyen pour charger des données depuis un support physique. Comment donc charger les contenus utilisés pour les sprites\ ? Un moyen simple pour résoudre ce problème est de simplement intégrer les données des sprites dans le code source du guest.
+Le guest ne possède aucun moyen pour charger des données depuis un support physique. Comment donc charger les contenus utilisés pour les sprites\ ? Un moyen simple pour résoudre ce problème est d'intégrer les données des sprites dans le code source du guest, sous forme de tableaux de bytes.
 
-Le petit programme **`bin2array`**, dont le code source [se trouve ici](https://github.com/thxbb12/bin2array), permet de convertir tout fichier en un tableau de bytes en C. A vous donc de l'utiliser pour convertir des fichiers sprites (images png) en code source C.
+Le petit programme **`bin2array`**, dont le code source [se trouve ici](https://github.com/thxbb12/bin2array), permet de convertir tout fichier en un tableau de bytes en C. A vous donc de l'utiliser pour convertir des fichiers sprites (images au format `png`) en code source C.
 
 ## Consignes à propos de l'implémentation
 
@@ -556,6 +556,27 @@ Dans `disk_tests/disk_ref.raw` se trouve une image disque de 256\ KB contenant l
 ### `guest_disk_phys.bin`
 \vspace{-.3cm}
 
-Ce guest réalise le même test d'écriture de secteurs mais via un driver physique. Attention toutefois\ : le code du guest tente volontairement de réaliser des écritures sur disque, mais volontairement légèrement incorrectes. Ces tentatives d'écritures ne devraient jamais aboutir et seules les écritures implémentant un code correct doivent mener à un secteur écrit sur disque. Les secteurs écrits doivent donc être exactement les mêmes que dans le guest précédent, avec exactement les mêmes contenus\ !
+Ce guest réalise le même test d'écriture de secteurs que `guest_disk_pv.bin` mais via driver natif (physique). Attention toutefois\ : le code du guest tente de réaliser des écritures sur disque, mais volontairement légèrement incorrectes. Ces tentatives d'écritures ne doivent donc jamais aboutir. Seules les écritures implémentant un code 100% correct doivent mener à un secteur écrit sur disque. Les secteurs réellement écrits sont les mêmes que dans le guest précédent et leurs contenus identiques.
 
-L'affichage réalisé par le guest sur la console virtuelle est identique au guest précédent.
+Enfin, l'affichage réalisé par le guest sur la console virtuelle devrait être identique au guest précédent.
+
+### `guest_sprites_pv.bin`
+\vspace{-.3cm}
+
+Ce guest réalise les fonctionnalités suivantes à l'aide d'hypercalls\ :
+
+1. Initialise le mode graphique 600x400
+1. Défini le contenu de 3 sprites, aux dimensions respectives de 64x64, 64x64 et 128x128
+1. Rend les 3 sprites visibles
+1. Dans une boucle infinie\ :
+   - Déplace les 3 sprites aléatoirement
+   - Attends un délai de 10000 micro-secondes entre chaque tour de boucle
+
+L'affichage devrait ressembler à ceci\ :
+
+![Affichage de sprites](images/sprites.png){ width=80% }
+
+### `guest_sprites_phys.bin`
+\vspace{-.3cm}
+
+Ce guest réalise exactement les mêmes fonctionnalités que `guest_sprites_pv.bin`, mais en utilisant des drivers natifs (physiques).
\ No newline at end of file