TP Projet en

architecture des
circuits
microprogrammés

Table des matières

Mohamed Bouhadid
Adel Amar Chaker 2018-2019
 2

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 Figure 2 Image du jeu sur DSPIC33.............................3
Figure 3 test affichage des textures........................................................................................................4
Figure 4 Excel du niveau 1 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 Année 2018-2019
 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 Année 2018-2019
 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.2. 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 Année 2018-2019
 5

2.3. 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 Année 2018-2019
 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.4. 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 Année 2018-2019
 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 Année 2018-2019
 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 carte, Sous-
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 Année 2018-2019
 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 Année 2018-2019
 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 Année 2018-2019
 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

12 Année 2018-2019
 13

sont 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 Année 2018-2019
 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.

14 Année 2018-2019
 15

Figure 15 Exemple de chute de plusieurs pierres

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

15 Année 2018-2019
 16

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).

16 Année 2018-2019
 17

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.

17 Année 2018-2019