A-Xion Projet Xion

Projet Xion — Rapport de soutenance 1

Mickael Mogmi Bidon (bidon m)Pierre-Marie PMdomine de Rodat (de-rod p)

Adrien Cookieslover Conrath (conrat a)Julien Sn00ze92 Lehuen (lehuen j)

1 Rapport de soutenance 1

A-Xion Projet Xion

Table des matieres

1 Preliminaires : Xionnet 31.1 Qu’est-ce-que c’est ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Resultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3 Un bonus imprevu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Presentation 52.1 Le Projet Xion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.2 Le moral des troupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3 Revisions du cahier des charges . . . . . . . . . . . . . . . . . . . . . . . 5

3 Bilan 63.1 Avancement global . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2 Le moteur physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2.1 Gestion des forces . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2.2 Gestion des collisions . . . . . . . . . . . . . . . . . . . . . . . . . 83.2.3 Deplacement sur la carte . . . . . . . . . . . . . . . . . . . . . . 103.2.4 Calcul de la tangeante a la carte . . . . . . . . . . . . . . . . . . 103.2.5 Difficultes rencontrees . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 Le moteur graphique — Interface globale . . . . . . . . . . . . . . . . . 113.4 Le moteur graphique — Gameplay . . . . . . . . . . . . . . . . . . . . . 133.5 Le moteur son . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153.6 Site web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4 Nouveau planning 174.1 Previsions pour la soutenance no 2 . . . . . . . . . . . . . . . . . . . . . 174.2 Previsions pour la soutenance no 3 . . . . . . . . . . . . . . . . . . . . . 174.3 Previsions pour la soutenance finale . . . . . . . . . . . . . . . . . . . . 17

5 Conclusion 185.1 Ce qui a ete fait . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185.2 Ce qui reste a faire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2 Rapport de soutenance 1

A-Xion Projet Xion

1 Preliminaires : Xionnet

1.1 Qu’est-ce-que c’est ?

Une fois que notre groupe de projet s’est forme, il est apparu tres clairement queles niveaux en programmation etait tres disparates. Nous avons ainsi decide de nousreunir dans une salle machine de l’EPITA une soiree et de realiser une sorte de TP :un mini jeu video du style tank. Voila ce que nous comptions atteindre :

Nous avons code en Delphi et utilise la bibliotheque SDL, le tout en programmationorientee objet, comme nous avions prevu de le faire dans le vrai projet. Au final, ce quise presentait comme une soiree d’apprentissage s’est transforme en une nuit blanchede code.

1.2 Resultats

Si nous parlons ici de ce micro-projet, c’est parce qu’il a eu de nombreuses consequencespositives, tant au niveau du groupe qu’au niveau individuel. Nous avons effectivementobtenu un mini-jeu complet exactement tel que nous l’imaginions. Plus encore que ca,nous avions un moteur de son fonctionnel ainsi qu’une intelligence artificielle a difficultevariable. Nous avons meme realise plusieurs themes graphiques differents. Nous avonsacquis un grand nombre de connaissances en un temps relativement court. De plus, auniveau du groupe, nous avons appris a coder a plusieurs, a nous connaıtre et surtouta passer un grand moment ensemble : la satisfaction de voir notre jeu fonctionner, ets’ameliorer encore et encore.

Le jeu genere une carte de dimensions donneees et dispose aleatoirement des blocssur celle-ci. Un certain nombre de tank apparaissent sur le terrain, dont le joueur enrouge. Les tanks peuvent alors se deplacer, tirer, detruire un bloc situe immediatementdevant eux ou encore creer un bloc derriere le tank. La partie se termine lorsque lejoueur meure (perdu) ou qu’il soit le dernier vivant (gagne).

3 Rapport de soutenance 1

A-Xion Projet Xion

1.3 Un bonus imprevu

Au final, nous nous sommes attaches a ce qui devait n’etre qu’un micro-TP. C’estpourquoi nous avons decide de le proposer en meme temps que notre jeu principalDestruXion. Il sera ainsi disponible a la fois sur notre site internet et sur notre CDfinal d’installation. Il sera disponible avec les quelques styles graphiques que nous avonsrealise.

Figure 1 – Avec graphismes Sans graphismes

N’hesitez surtout pas a y jouer ! Si nous avons le temps, l’envie et les idees necessaires,nous ajouterons peut etre quelques fonctionnalites de plus, comme un mode multijoueursur le meme clavier ou un mode � seul contre l’ordinateur �.

4 Rapport de soutenance 1

A-Xion Projet Xion

2 Presentation

2.1 Le Projet Xion

Notre projet de premiere annee est de realiser un jeu : DestruXion. C’est un jeuque nous allons realiser en 2D et dont le principe reprend celui du celebre Worms,c’est-a-dire que le joueur controle une equipe d’unites qu’il deplace a tour de role avecses adversaires et a l’aide de laquelle il doit annihiler les unites des equipes ennemiesau moyen d’armes et d’objets divers.

Pour cela, nous avons decide d’utiliser le langage Delphi ainsi que la bibliothequeSDL, amplement suffisante pour travailler en 2D.

2.2 Le moral des troupes

L’ambiance est toujours tres bonne et aucun conflit n’a eclate au cours des semainesprecedentes (si ce n’est sur notre serveur Subversion), et c’est avec plaisir que nousnous retrouvons des journees entieres ensemble pour faire avancer notre projet qui nousmotive tous beaucoup.

2.3 Revisions du cahier des charges

Le seul changement signifiatif du cahier des charges est le planning, et plus precisementles etapes d’avancement des differents moteurs. En effet, nous pensons qu’il est plusimportant d’avancer dans un premier temps au maximum graphismes, physique etson avant de nous lancer dans l’intelligence artificielle et reseau. Ainsi, des tableauxcorrigeants nos plannings sont proposes en fin de rapport.

5 Rapport de soutenance 1

A-Xion Projet Xion

3 Bilan

Figure 2 – Plannification de l’organisation des moteurs

6 Rapport de soutenance 1

A-Xion Projet Xion

3.1 Avancement global

Des que nous avons commence a programmer, nous nous sommes apercu que notreplanning ne correspondait pas tout a fait avec ce que nous avions en tete. Nous avonsainsi decide qu’il etait plus important de commencer par avoir les moteurs physiqueet graphique assez avances plutot que de vouloir tout avancer en meme temps. Ainsiceux-ci sont plus elabores qu’il ne l’etait prevu et nous disposons deja d’une ebauchede jeu fonctionelle :

– affichage de differents menus ;– affichage de cartes et des differents objets ;– gestion de la gravite, des deplacements et gestion partielle des collisions ;– deux armes sont disponibles : un bazooka et un arc, tous deux capables de tirer ;– gestion du son et des musiques de fond.

Nous avons donc etablit un nouveau planning que nous exposons a la fin de ce rapportde soutenance.

Notre jeu est base sur deux moteurs principaux : un moteur graphique qui s’occupede toutes les images que nous souhaitons afficher et un moteur physique qui permet aujoueur d’interagir avec le decor de maniere coherente (collisions, gravite, etc.). Nousnous sommes aussi concentres sur la creation du site web, juge important pour lacommunication.

3.2 Le moteur physique

3.2.1 Gestion des forces

Ce moteur traite l’interaction des objets avec le terrain par deux moyens. Lapremiere est la gestion des forces (gravite et vent) qui permet d’estimer la dynamiquedes objets dans l’espace. Deux integrations successives calculent la vitesse et la positionen fonction de l’acceleration. En effet, nos cours de physique nous apprennent d’unepart que force et acceleration sont identiques a une constante pres (la masse) et d’autrepar que :

~v(t) =d ~OM(t)

dtet que ~a(t) =

d~v(t)dt

ainsi ~a(t) =d2 ~OM(t)

dt2et ~OM(t) =

∫∫~a · dt

Par approximation affine (methode d’Euler), on peut ainsi integrer :

x(t + dt) = x(t) +dx

dt· dt

D’ou :

~v(t + dt) = ~v(t) + ~a(t + dt) · dt et ~OM(t + dt) = ~OM(t) + ~v(t + dt) · dt

Cette approximation est d’autant plus precise que le pas dt est petit.

7 Rapport de soutenance 1

A-Xion Projet Xion

3.2.2 Gestion des collisions

La carte de notre jeu est une image au format PNG. Elle est donc composee depixels, ce qui rend la gestion des collisions, des rebonds plus complexes que celle desjeux pour lequels la carte est composees de plateformes rectangulaires. Chaque pixela une valeur dite � alpha � correspondant a sa transparence. Cette value varie de0 (completement transparent) a 255 (completement opaque). Notre moteur physiqueconsidere qu’un pixel est � rempli � (et qui constitue donc un obstacle) si sa valeuralpha est inferieure a 127. Cette methode nous permet de nous dispenser de creer unediteur de cartes, puisque n’importe quel editeur d’image capable de gerer la trans-parence permet de creer en quelque clics des cartes de n’importe quelles dimensions.Ainsi, les debutants pourront creer des cartes tres simples, et les plus doues pourrontpousser la personnalisation tres loin.

Figure 3 – Classification des pixels en fonction de leur transparence

Pour detecter la collision des personnages avec cette carte, nous utilisons une boun-ding box : nous ne prenons en compte que le rectangle entourant le personnage afind’accelerer et de simplifier les calculs. Pour detecter si ce rectangle est en collisionavec la carte, on parcourt chaque pixel sur les bords de ce rectangle et on teste si lepixel correspondant sur la carte est rempli. Si on en trouve un, il y a alors collision. Enfonction du besoin de precision, on peut decider de ne tester qu’un certain pourcentagede pixels.

Lors de la detection d’une collision, nous avons au debut procede en annulant ledernier deplacement, c’est-a-dire en soustrayant le vecteur vitesse au vecteur position,mais cela avait pour consequence de voir le personnage s’arreter avant meme d’avoir

8 Rapport de soutenance 1

A-Xion Projet Xion

atteint l’obstacle. Pour resoudre le probleme, nous calculons la position limite dansle mouvement du personnage pour laquelle celui-ci se retrouve colle a la paroie. Oncalcule donc le vecteur unitaire colineaire au vecteur vitesse, puis on le soustrait auvecteur position autant de fois necessaires pour qu’il n’y ait plus de collision. C’est unesorte de retour en arriere progressif.

Figure 4 – Collisions : bouding box et comportement

Une difficulte cependant avec cette derniere methode : le personnage se retrouveparfois a un autre bout de la carte, et il est difficile d’en trouver la cause tant lesconditions de ce bug sont particulieres. Dans le futur, il reste a implementer la gestiondes equipes dans la partie des regles du jeu, mais aussi des actions des armes (tant surle terrain qu’aux autres unites) et du vent du cote du moteur physique lui-meme.

Figure 5 – Collisions : autres types de detection

Du cote de la collision des autres objets (projectiles) avec la carte, nous utilisonspour l’instant le meme procede pour detecter la collision entre un projectile et la carte,mais avec une bounding box de 1 pixel, car il y aurait une trop grosse marge d’erreursi on utilisait par exemple le rectangle entourant une fleche en position oblique. Maisle test d’un seul pixel n’est pas assez precis etant donne que le projectile est bien plus

9 Rapport de soutenance 1

A-Xion Projet Xion

grand ! C’est pour cela que nous allons nous orienter vers une suite de pixel dependantdu projectile pour faire le test.

3.2.3 Deplacement sur la carte

Pour gerer le deplacement du personnage sur la carte, il nous faut calculer la tan-gente au point de collision entre ce personnage et la carte. Si on veut deplacer lepersonnage a gauche, on calcule la tangente a gauche, respectivement a droite. Uneroutine, dont le detail du fonctionnement sera decrit par la suite, calcule un vecteurunitaire dirigeant cette tangente. Une fois multiplie par une constante definissant lavitesse de deplacement de nos personnages, on peut ajouter ce vecteur unitaire auvecteur position du personnage.

Figure 6 – Deplacement le long d’une pente

Le saut ne fut quant a lui pas complique a implementer. Il suffit d’incrementerla composante verticale du vecteur vitesse, et la composante horizontale d’une valeurpositive ou negative en fonction de la direction.

3.2.4 Calcul de la tangeante a la carte

Pour calculer la tangente a droite en un point A de coordonnees (x, y) sur la carte,on regarde l’etat (rempli ou non) du pixel au point B de coordonnees (x + k, y), puison cherche le premier point au-dessus ou en dessous de B tel que son etat different.

Dans cet exemple (figure 7), l’etat change au point C en (x + k, y− c). La tangentea donc pour coordonnees (k,−c). On procede de meme pour calculer la tangente agauche.

10 Rapport de soutenance 1

A-Xion Projet Xion

Figure 7 – Methode de calcul de la tangente ~AC a droite au point A

3.2.5 Difficultes rencontrees

Du fait de la complexite du traitement d’une carte pixellisee, il est tres difficilede prevoir toutes les situations. Nous avons a faire a de nombreux bugs tres longs acorriger. Ceux pour lesquels nous avons attache le plus d’importance sont ceux en-gendrant une boucle infinie. Nous nous sommes retrouves dans cette situation lors ducalcul d’une tangente en un point proche du bord de la fenetre par exemple. D’autresbugs nous donnent du fil a retordre, certains comportements imprevus surgissant parexemple lorsque le personnage marche sur la carte et entre en collision avec une penteoblique. . .

3.3 Le moteur graphique — Interface globale

L’interface globale se base autour du concept d’ecran : chaque partie du logiciel(comme le menu principal, le menu des options, le jeu lui-meme) est gere de manieregraphique par un ecran, une surface qui prend toute la fenetre et qui capte toutes lesinterractions de l’utilisateur.

Le fonctionnement des successions de ces ecrans est alors facilite avec l’utilisationd’une pile. En effet, considerons une pile d’ecrans dans laquelle seul l’ecran au sommetest affiche. Au lancement du programme, cette pile est vide. On empile alors le menuprincipal qui donne ensuite l’ordre, selon le choix de l’utilisateur d’empiler un autreecran (celui de jeu ou des options) ou de depiler, ce qui terminerait alors l’execution.

En ce qui concerne la construction des interfaces, un systeme uniforme de com-posants a ete mis au point, a l’image des interfaces utilisateur traditionelles grace al’heritage et au polymorphisme. Ces composants (les equivalents des boutons, des casesa cocher, des barres de progression, des conteneurs de composants) sont capables dereagir aux actions de l’utilisateur comme la frappe au clavier et les clics de souris.Il suffit aux conteneurs de definir la position des composants qu’ils contiennent parrapport a leur propre surface. La position de chaque composant est donc definie demaniere relative. Enfin, comme un seul composant doit etre actif, tous les composants

11 Rapport de soutenance 1

A-Xion Projet Xion

Figure 8 – Exemple de l’evolution de la pile d’ecrans au cours du temps

(sauf le composant active) sont dessines en laissant l’arriere plan a moitie transparent.

Figure 9 – Exemple : un conteneur gere plusieurs cases a cocher

Ces composants sont surtout utilises dans l’ecran des options. Celui-ci est directe-ment relie a un gestionnaire de preferences capable d’appliquer les modifications desoptions, et bientot de rendre celles-ci persistantes en les sauvant puis en les restaurantdans un fichier de configuration.

Le plus difficile dans la conception de l’interface graphique globale a ete la cohesion

12 Rapport de soutenance 1

A-Xion Projet Xion

des differents composants : l’interface de jeu, le moteur de son, etc. Pour faire face acette difficulte, il a suffit de normaliser les interfaces de ces composants et de codifierleurs interactions. La seconde difficulte est ensuite de creer une interface graphique ala fois simple et intuitive, tant pour l’utilisateur que le developpeur !

La prochaine etape de cette partie est donc centree sur la creation de composantsgraphiques pour permettre a l’interface de proposer un maximum d’interactivite al’utilisateur tout en restant a l’ecart de � l’usine a gaz �. Nous comptons pour celanous inspirer de l’arborescence des composants graphiques traditionnelle. Il faudraainsi prendre a maximum en charge la souris et le clavier pour rendre l’ensembleergonomique, agreable a utiliser.

3.4 Le moteur graphique — Gameplay

Comme promis, nous nous sommes attardes a realiser des graphismes soignes.

L’affichage du terrain de jeu tout d’abord. Cet affichage se fait grace a deux imagesrepresentant respectivement le fond de l’ecran et le terrain lui-meme. Le moteur gra-phique s’occupe de charger ces deux images, et d’afficher le fond et le terrain. Lors desdeplacements de camera, les deux images se deplacent, mais pas a la meme vitesse. Lesdeux images s’arretent sur leurs bords respectifs en meme temps.

Figure 10 – Modele de composition du terrain

Nous avons code plusieurs manieres de deplacer l’affichage :– le deplacement � suivi � qui suit le Xion actif lorsqu’il s’approche des bords de

l’ecran ;– le deplacement � centrage � qui permet au joueur de centrer l’ecran sur son Xion

actif ;– le deplacement � relatif � qui permet au joueur de se deplacer sur la carte a

l’aide de la combinaision Ctrl + Fleche.

13 Rapport de soutenance 1

A-Xion Projet Xion

Nous nous sommes egalement occupes de l’animation des jambes lors de la marchedu Xion. Pour cela, nous avons realise une grande image contenant les jambes danschaque etape de la marche, vers la gauche et vers la droite. Ainsi, on ne charge qu’unegrande image, en n’en copiant qu’une partie a chaque fois. Nous avons utilise la memeastuce pour l’affichage du reste du corps, vers la gauche ou vers la droite.

Figure 11 – Explication de l’animation des jambes

Pour terminer l’affichage du Xion, il nous a aussi fallu gerer l’affichage de l’arme,et que celle ci pivote lors de l’appui sur les touches haut et bas. Afin de preserver laqualite de l’image lors de la rotation, nous avons choisi de garder l’image de base, etde creer a chaque fois la nouvelle surface a partir de l’originale.

L’affichage des projectiles n’a pas ete tres difficile. En effet, il suffit de chargerl’image du projectile, puis de l’orienter (effectuer une rotation de l’image) selon sonvecteur vitesse.

Un autre usage d’une pile s’est avere necessaire pour un moteur : la gestion desetats du jeu, comme l’etat � normal � (StateNormal), � preparation du lancement d’unprojectile � (StateMotion), ou encore � jeu en pause � (StateEscMenu). Concretement,lorsque le jeu est en pause, il est necessaire pour reprendre de savoir si un projectileetait lance, ou si on le lancait : a la base de la pile se trouve l’etat StateNormal, puis siun projectile est lance l’etat StateMotion se trouve au-dessus, enfin si le jeu est aussien pause l’etat StateEscMenu est au sommet de la pile.

Nous avons en revanche butte sur une faiblesse de la SDL concernant la gestion descanaux alpha (le niveau de transparence des pixels d’une image) lors des operationsde blit (� collage � d’une surface sur une autre). Le probleme vient du fait que lorsd’un blit, le canal alpha de l’image source n’est pas pris en compte, et le canal alphade l’image de destination reste inchange. Par exemple, apres avoir effectue un blit

14 Rapport de soutenance 1

A-Xion Projet Xion

d’une surface remplie de noir opaque sur une surface remplie de noir completementtransparent, l’image resultante est transparente.

Ce probleme a ete resolu en codant notre propre fonction de blit : elle superposedeux surfaces comme le ferait un logiciel de traitement d’image. En revanche, commeelle est plus lente que celle proposee par SDL, nous ne l’utilisons que lorsque c’estvraiment necessaire.

3.5 Le moteur son

N’etant pas une partie tres difficile du projet et etant pourtant un element impor-tant pour l’ambiance du jeu, nous avons decide de terminer des la premiere soutenancele moteur de son. Pour cela nous avons utilise la bibliotheque SDL directement, quipourvoit largement a nos besoins, et nous n’avons pas senti le besoin de nous tournervers vers d’autres bibliotheques telles que FMod.

Grace a cela, nous pouvons desormais charger en memoire et jouer des sons enfonctions de leur utilite ou de leur taille : les fichiers courts et peu lourds, les effetssonores, sont tous charges en debut de partie et liberes a la fin, tandis que les musiquesde fond sont lues une par une selon une methode differente.

Profitant du grand nombre de fonctionnalites disponibles dans cette bibliotheque,nous avons egalement cree quelques fonctionnalites optionelles, comme un menu d’op-tions permettant de couper le son ou la musique dans le jeu. Nous gerons egalementplusieurs canaux de lecture qui nous permettent de jouer plusieurs sons en meme temps(voix, effets sonores, etc.).

Maintenant que le moteur de son est fonctionnel, il reste a creer les fichiers desons qui donneront au jeu son ambiance et son identite. Nous proposerons ainsi unlarge panel d’effets sonores pour chaque arme ou objet, ainsi que la possibilite auxunites Xion d’intervenir via diverses repliques au cours de la partie, et ce en fonctiondes evenements (exemple : en cas de grenade proche, le Xion crie � FIRE IN THEHOLE ! �). Il serait egalement agreable d’ajouter des sons legers lors des deplacementsdans les menus.

3.6 Site web

Nous avons choisi de realiser notre site web avec de simples pages xHTML auquellesnous avons applique un design grace aux CSS. Le design est inspire de la premiere carteque nous avons cree pour notre jeu et l’interface est tres simple grace a 5 pages :

– l’accueil qui presente globalement le projet et les dernieres nouvelles ;– une page de presentation de l’equipe ;

15 Rapport de soutenance 1

A-Xion Projet Xion

– une page de presentation plus precise du jeu, avec des images et quelques expli-cations ;

– une page de telechargements, avec le cahier des charges, des executables et lesrapports de soutenance ;

– une page de goodies, pour la communication.Vous pouvez le visiter a l’adresse http://www.destruxion.net/.

16 Rapport de soutenance 1

A-Xion Projet Xion

4 Nouveau planning

4.1 Previsions pour la soutenance no 2

Mogmi PMdomine Cookieslover Sn00ze92Site web 100 % 100 %Moteur physique 40 % 40 %Moteur reseau 40 % 40 %Moteur graphique 70 % 70 %Sons 100 %IA 30 % 30 %

4.2 Previsions pour la soutenance no 3

Mogmi PMdomine Cookieslover Sn00ze92Site web 100 % 100 %Moteur physique 90 % 90 %Moteur reseau 70 % 70 %Moteur graphique 90 % 90 %Sons 100 %IA 70 % 70 %

4.3 Previsions pour la soutenance finale

Mogmi PMdomine Cookieslover Sn00ze92Site web 100 % 100 %Moteur physique 100 % 100 %Moteur reseau 100 % 100 %Moteur graphique 100 % 100 %Sons 100 %IA 100 % 100 %

17 Rapport de soutenance 1

A-Xion Projet Xion

5 Conclusion

5.1 Ce qui a ete fait

Dans l’ensemble, nous sommes parvenus a tenir le nouveau planning que nous noussommes fixes. Nous avons donc un site web complet en ligne, des moteurs physique etgraphique deja bien avances, un moteur de son quasiment termine ainsi qu’un menud’accueil. Nous pouvons afficher une unite sur une carte, la deplacer, sauter, entrer encollision avec le decor et tirer. Au niveau du contenu, nous proposons d’ores et dejadeux armes differentes (un bazooka et un arc), differents sons ainsi que plusieurs cartesdifferents. Le menu des options nous permet de couper et d’activer les musiques et sonsainsi que de basculer du mode fenetre au mode plein ecran.

5.2 Ce qui reste a faire

Bien evidemment, nous prevoyons d’avoir des moteurs physique et graphique encoreplus performants lors de la deuxieme soutenance (notamment l’apparition du vent quiinfluencera la trajectoire des projectiles, la gestion des degats et des equipes), maisegalement un moteur de son pleinement fonctionnel. Ensuite nous devons nous penchersur nos deux parties restantes du projet, a savoir les gestions du reseau et de l’IA. Auniveau du contenu, nous augmenterons le nombre d’armes et de cartes disponibles,ainsi que la possiblite de choisir la carte via le menu de jeu. Le nombre de sons seraegalement revu a la hausse.

18 Rapport de soutenance 1

A-Xion Projet Xion

Figure 12 – L’equipe est en plein travail : ne pas deranger !

19 Rapport de soutenance 1