Projet: Architecture des circuits

microprogrammés

Master 1 : Electronique Embarqué

Groupe 1
2020-2021

Réalisé par : Encadré par :

Mohammed Abkari Mr.Claudel
 2

Table des matières

1. Introduction..................................................................................................................................... 3
2. Préparation ...................................................................................................................................... 4
2.1. Affichage des textures sur l’écran ........................................................................................... 4
2.2. Création des textures personnaliser ....................................................................................... 4
2.3. Création des niveaux ............................................................................................................... 5
2.4. Affichage du personnage......................................................................................................... 6
3. Structure globale ............................................................................................................................. 7
3.1. Initialisation ............................................................................................................................. 8
............................................................................................................................................................. 8
3.2. Programme Principal ............................................................................................................... 9
3.3. Sous-programme d’interruption ........................................................................................... 10
3.3.1. Déplacement ................................................................................................................. 12
3.3.2. La chute de pierre.......................................................................................................... 14
3.3.3. Le « GAME OVER » ........................................................................................................ 15
4. Conclusion ..................................................................................................................................... 16

Index des Figures :

Figure 1 Image du jeu Boolder Dash sur NES……………………………………. .................................................. 3

Figure 2 Image du jeu sur DSPIC33……………………………………................................................................... 3
Figure 3 test affichage des textures ........................................................................................................ 4
Figure 4 Excel du niveau 1……………………………………. ............................................................................... 5
Figure 5 Excel du niveau 2……………………………………................................................................................. 5
Figure 6 Excel du niveau 3 ....................................................................................................................... 5
Figure 7 Algorithme principal .................................................................................................................. 7
Figure 8 Algorithme d'initialisation ......................................................................................................... 8
Figure 9 Algorithme du programme principal ......................................................................................... 9
Figure 10 sous-programme d'interruption ............................................................................................ 10
Figure 11 organigramme de déplacement ............................................................................................ 12
Figure 12 Exemple pousser de pierre .................................................................................................... 13
Figure 13 Exemple GAME OVER par chute de pierre ............................................................................ 13
Figure 14 Exemple de chute de pierre .................................................................................................. 14
Figure 15 Exemple de chute de plusieurs pierres ................................................................................. 14
Figure 16 Exemple de "GAME OVER" par écoulement de temp ........................................................... 15

2 2020-2021
 3

1. Introduction :

Le but de notre TP est de réaliser un jeu, en Langage C et de l’implémenter sur notre Micro-
Controller. Afin d’utilisée au mieux les ressources de celui-ci. Vu que les ressource du micro-Controller
sont très limitée par rapport à celle d'un ordinateur, nous nous sommes naturellement orientés sur un
jeu en 2 dimensions (2D) avec un mode de déplacement de type case par case.

Notre choix s’est porté sur le jeu ‘’Boulder Dash’’. Dans le jeu que nous avons programmé, le
joueur doit ramasser tous les diamants sans se faire tuer ou piéger par les pierres, si le personnage se
fait tuer par une pierre, il est remplacé par une tête de mort et la partie est terminer, alors un écran
« GAMER OVER » apparait, avec le score actuel et le meilleur score obtenu, alors le joueur doit appuyer
sur le bouton RB0, pour relancer une partie. Dans le cas contraire, où le joueur récupéré tous les
diamants du stage, il passe au niveau suivant.

La carte du jeu se compose aussi d’élément indestructible, ces éléments ne peuvent pas être
déplacer, ou traverser. Alors que les pierres peuvent être déplacer, et tombent s’il y a aucun obstacle
en dessous de type terre ou autre. Afin de nous approcher le plus possible du jeu d’origine, nous avons
aussi ajouter une limite de temps par stage qui est de 100 sec par niveau, si le temps est écoulé alors
l’écran « GAME OVER » apparait.

Figure 1 Image du jeu Boolder Dash sur NES Figure 2 Image du jeu sur DSPIC33

3 2020-2021
 4

2. Préparation :
2.1 Affichage des textures sur l’écran :

Pour commencer, nous allons tester l’affichage des textures sur l’écran, pour cela nous chargeons
le programme suivant : (après avoir initialiser l’écran)

Ce qui nous donne sur l’écran :

Figure 3 test affichage des textures

2.1. Création des textures personnaliser :

En plus des textures par défaut fournis, dans les fichiers sources, nous allons générer quelques
autres textures, pour cela nous allons utiliser le logiciel Photoshop pour crée les images et du script
Matlab (Fournis dans les fichiers sources) pour les écrire sous forme de matrice de 768 (chaque
pixel a besoin de 3 valeurs pour le code RGB, et les texture sont de taille de 16x16, donc
3*16*16=768 valeurs).

Les textures ajouter sont les suivantes :

- : pour illustrer la mort du joueur.

- , , , , , et : pour afficher le « GAME OVER ». On peut noter ici que nous
avons besoin d’une seule matrice pour le « E », pour l’afficher deux fois.

4 2020-2021
 5

2.2. Création des niveaux :

Dans cette partie nous allons créer les trois niveaux qui compose notre jeu, pour cela nous allons
nous basé sur ce qui suit :

- La taille de notre écran est de 240x320 pixel. Et nos textures sont de taille 16x16. Ce qui nous
donne une matrice de 15x20 carreaux.

Pour crée les trois niveaux nous nous sommes aidés d’un fichier Excel, afin de visualiser les niveaux
avant l’implémentation :

Figure 4 Excel du niveau 1 Figure 5 Excel du niveau 2

Figure 6 Excel du niveau 3

5 2020-2021
 6

Dans les matrices précédentes, les valeurs correspondent à ce qui suit :

- La valeur 0 : c’est les obstacles.

- La valeur 1 : est la terre non creuser.
- La valeur 2 : les diamants.
- La valeur 3 : la pierre.
- La valeur 4 : la terre creuser.
- La valeur 5 : zone de non jeu (cette zone va nous permettre d’afficher score, temp …etc.
- La valeur P : correspond la position du joueur au début de la partie.

Enfin pour afficher, la carte après avoir déclarer les matrices avec les valeurs précédentes, nous
utilisons une double boucle « for » imbriqué et un « swtich case » :

On peut noter l’absence du « case 4 », car au début de chaque partie la terre n’est pas encore creusée,
mais aussi du « case 5 », qui est une zone de non jeu et donc il n’est pas nécessaire d’afficher quoique
ce soit, et enfin du « case P », car l’affichage du personnage est une action récurrente et donc nous
avons préfère utiliser une fonction externe et faire appel à cette dernière.

2.3. Affichage du personnage :

Pour afficher notre personnage nous avons déclarer une fonction de type « void » nommé
« perso », qui se présente comme ce qui suit :

« xp » et « yp » corresponde à la position de notre personnage sur l’écran. Et la variable « DG »

vaut « 0 » si notre personnage regarde à droite, et « 1 », si notre personnage regarde à gauche.

6 2020-2021
 7

3. Structure globale :
Notre programme peut être représenter selon le schéma suivant :

Début

Déclaration des variables/Fonction

Initialisation

Programme principal Sous-programme d’interruption

Fin

Figure 7 Algorithme principal

Ici nous pouvons distinguer ce qui suit :

 Bloc Déclaration des variables/Fonction : dans cette partie nous allons déclarer toute nos
variables, et fonctions récurrentes. Avant le « main » afin qu’elles soient disponibles sur tout
le programme.
 Bloc initialisation : dans cette partie nous allons initialiser, tous nos paramètres (Score, sens
du regard du personnage…etc.), les ports (Entrée/sortie), Timer, interruption…etc.
 Bloc Principal : le programme principal est généralement utilisé pour exécuter une tache de
fond (calcule…etc.), mais dans notre jeu, le corp de notre programme va être placer dans le
sous-programme d’interruption.

7 2020-2021
 8

 Bloc Sous-programme d’interruption : ici nous allons mettre tous nos tests, et faire appel au
fonction nécessaire au bon fonctionnement de notre jeu.

On peut noter que notre programme n’a pas vraiment une fin, et donc on réalité il va boucler entre
les deux blocs « programme principal » et « sous-programme d’interruption ».

3.1. Initialisation :

Début Initialisation

Configuration PortA et PortB, Écran

et joystick…

Configuration du temp
d’interruption

Validation des Interruption

Initialisation du Timer à « 0 »

Initialisation des variables

(Score…etc.), chargement de la Sous-
carte, positionnement joueur programme
d’interruption

Fin Initialisation

Figure 8 Algorithme d'initialisation

Dans cet organigramme, on peut noter qu’on commence par configurer nos ports utiliser en
entrée, ainsi que notre écran et joystick. On poursuit par la configuration de l’interruption et ont fini

8 2020-2021
 9

par l’initialisation, des variables et chargement de la carte. On peut noter aussi que le sous-programme
d’interruption peut faire appel à la dernière partie de l’initialisation qui va nous permettre de relancer
le jeu en cas de « Game Over », en appuyant sur le RB0 ou lors du chargement de la carte du niveau
suivent.

3.2. Programme Principal :

Début Programme Principal

Interruption
Sous-
Boucle While (infinie) programme
Fin d’interruption
Interruption

Fin Programme Principal

Figure 9 Algorithme du programme principal

Dans cette partie, nous avons déclaré dans notre programme principal une boucle de type
« while » avec une condition toujours vraie. Suite à chaque interruption le microcontrôleur exécute le
sous-programme d’interruption et à la fin de celui-ci, il revient à la boucle infinie.

9 2020-2021
 10

3.3. Sous-programme d’interruption :

Figure 10 sous-programme d'interruption

10 Année 2018-2019
 11

Sur l’organigramme de la figure 10, on peut voir comment fonctionne notre sous-programme
d’interruption, c’est un ensemble de test « if » imbriqué. On commence par vérifier si la partie est
terminer (GAME OVER) ou pas, si ce n’est pas le cas, nous vérifions alors si le joueur veut se déplacer,
ensuite si une seconde s’est écoulée, et on vérifier si le joueur a ramassé tous les diamants du niveau.
Enfin on termine par un test, sur le bit RB0, pour voir si le joueur veut relancer une partie depuis le
début (on note ici qu’il n’est pas nécessaire d’être en GAME OVER pour relancer une nouvelle partie.
Mais en revanche, si on a un GAME OVER, le joueur ne peut plus se déplacer, et donc il est nécessaire
de relancer une partie).

11 2020-2021
 12

3.3.1. Déplacement

Figure 11 organigramme de déplacement

Pour le déplacement nous avons utilisé des tests « if », où le « haut » est la plus prioritaire suivi
de « bas », « droite » et enfin « gauche ». Le joueur ne peut se déplacer que si les conditions sont

12 2020-2021
 13

favorables (pas d’obstacle). Dans le cas des déplacements à droite ou à gauche si le joueur rencontre
une pierre et que celle-ci est suivi par de la terre creusée, alors le joueur peut la pousser.

Figure 12 Exemple pousser de pierre

Pour le cas de la direction du « bas », si une pierre se trouve au-dessus du joueur et que celui-
ci fait un déplacement vers le bas, alors la pierre vas lui tomber dessus, et donc va provoquer un
« GAME OVER ».

Figure 13 Exemple GAME OVER par chute de pierre

Si un déplacement est réalisé, après avoir actualiser les information (matrice, et variable), nous
vérifions s’il y a un diamant au nouveau cordonné du joueur, si c’est le cas nous incrémentant le score.
Dans le cas ou le déplacement n’est pas possible, nous nous dirigeons vers la fin de déplacement.

13 2020-2021
 14

3.3.2. La chute de pierre :

Dans cette partie nous allons voir notre fonction de type void nommée chute_rocher, elle se
présente de la façon suivante :

Elle a besoin de deux paramètres pour fonctionner, qui sont les cordonner de la pierre à faire
tomber, ensuite elle vérifier jusqu’à quel niveau la pierre va tomber en incrémentant « i » jusqu’à
quel ne trouve plus de terre creuse.

Figure 14 Exemple de chute de pierre

On peut noter aussi que nous avons bouclé, toute la fonction avec une boucle « while », pour le cas où
nous avons plusieurs pierres les uns au-dessus des autres.

Figure 15 Exemple de chute de plusieurs pierres

14 2020-2021
 15

3.3.3. Le « GAME OVER » :

Dans cette partie nous allons voir notre fonction de type void nommée game_over, elle se
présente de la façon suivante :

Cette fonction est appelée dans les deux cas suivants :

- Dans le cas où, il y a une pierre au-dessus du joueur, et que le joueur fait un déplacement
vers le bas (Voir Figure 11 organigramme de déplacement).
- Dans le cas où, les 100 secondes par niveau sont terminées.

Figure 16 Exemple de "GAME OVER" par écoulement de temp.

On commence, par appeler la fonction chute_rocher, pour faire chuter le rocher, on note que dans le
deuxième cas où c’est un « GAME OVER » par le temps, la fonction chute_rocher, ne fait rien. Ensuite
la texture « mort » (la tête de mort) est mise à la place du personnage, suivit par le message GAME
OVER avec les textures précédemment déclarées (voir 2.2. Création des textures personnaliser :). Et
on fini par l’affichage du meilleur score.

On note aussi que nous avons mis la variable the_end = 1, cette variable va nous permettre de savoir
si, le jeu est on état de « GAME OVER » (Voir le premier test de la Figure 10 sous-programme
d'interruption).

15 2020-2021
 16

4. Conclusion :

Dans ce projet, nous avons pu mettre en pratique ce que nous avons appris dans les précèdent
TP, notamment les interruptions, la gestion des priorités, l’affichage sur l’écran et l’utilisation des
ports comme Entrée/Sorite. En combinons, nous avons pu réaliser notre jeu sur le DSPIC33, pour
obtenir un jeu complet.

Ce projet pourrait faire l’objet d’amélioration, comme l’ajout d’image transitoire pour le
déplacement ou la chute de pierre, afin de donner un effet plus fluide sur l’écran, ou le rajout de
quelque niveau supplémentaire. Ou un menu pour choisir directement le niveau de début.

16 2020-2021