Sujet 13, Quak e

Julien Mairal
Sujet 13, Quake
Stéphane Lescuyer
21 juin 2004
1
Table des matières
1. Méthodes de travail
2. XBsp
3. Xquake
4. Le début d’une extension réseau.
2
1
Méthodes de travail
Différentes phases
étude des algorithmes et des structures
Programmation en parallèle de Xbsp et de Xquake
Deboguage commun
Programmation an parallèle des extensions
Deboguage commun
Rédaction du rapport, de la notice, et des transparents.
1.1
–
–
–
–
–
–
3
1.2
Les outils utilisés
– Une CVS
– Java et la librairie AWT
– LATEXet Dia pour le rapport et les transparents.
4
2
XBsp
5
2.1.1
2.1
L’édition des murs
Les arbres BSP
class Mur
Liste des murs
existants
Construction
Dessin
Dessin
class ListeMurs
– Quatre classes Mur, ListeMurs, Dessin, GestionSouris
class Dessin
Affichage Murs
Creation Mur
Edition Mur Courant
class GestionSouris
Clics souris
Mouvement Curseur
6
2.1.2
Insertion dans l’arbre
class XBsp
Arbre BSP courant
class XSegment
Intersection
Decoupage
Positionnement
class ArbreException
Insertion
class Bsp
– Six classes Dessin, XBsp, Mur, XSegment, Bsp, ArbreException
class Dessin
Creation Mur
class Mur
Liste des murs
existants
Intersection
7
2
3b
2
3f
1
Exemple d’insertion : le mur 3 dans le monde formé des murs 1 et 2
1
3
8
APRES
XSegment 3f
XSegment 3b
XSegment 2
XSegment 1
1.0f
0.66f
Mur 3
0.66f
0.0f
Mur 3
1.0f
0.0f
Mur 2
1.0f
0.0f
Mur 1
Les murs et les segments en mémoire après cette insertion
AVANT
Mur 3
Mur 2
Mur 2
Mur 1
Mur 1
9
2.1.3
L’optimisation
class ArbreException
Separation
Choix XSegment
Optimisation
class BspCompiler
class ListeSegs
Conversion ListeSegs
class ListeMurs
– Six classes : XBsp, Mur, BspCompiler, XSegment, ListeSegs,
ArbreException
class XBsp
ListeMurs courante
Decoupage
Intersection
class XSegment
Arbre BSP courant
class Mur
Liste des murs
existants
Intersection
Positionnement
– Optimisation en O(n2 )
10
2.1.4
L’affichage de l’arbre
Affichage Arbre
class DessinArbre
class Bsp
Dessin
Calcul du placement
et dessin des deux
sous-arbres
Dessin
class XSegment
– Cinq classes : XBsp, DessinArbre, GestionSourisArbre, Bsp,
XSegment,
class XBsp
Arbre BSP courant
Deplacement dans
le Canvas
class GestionSourisArbre
Glisser-Deplacer
– Algorithme de Reingold-Tilford en O(n)
11
2.2
–
–
–
–
Problèmes rencontrés
Problème d’affichage : flickering dans les Canvas
Problème de la pertinence des optimisations optimistes
La seule vraie méthode consisterait à tester tous les ordres
d’insertion possible et serait donc en O(n!), ce qui n’est pas
acceptable dès que n dépasse quelques unités.
Problème d’arrondis dans les calculs de produit scalaire pour
positionner les segments les uns par rapport aux autres
Problème des murs qui sont concourants et qui donnent lieu à des
segments minuscules voire nuls
Pour régler ces problèmes, introduction de l’exception
ArbreException
12
1
3b
2
3f
On teste donc avec l’autre extremite
Ici on ne peut rien dire, le produit scalaire est
trop proche de 0.0
Pas de probleme, on voit que ce segment
est du cote de la normale
13
1
3b
2
4
3f
ArbreException est levee :
le mur n’est pas insere
14
Cas problematique typique
3
Xquake
15
3.1.1
3.1
L’affichage d’un mur
L’affichage
mur
droite d’horizon
Calcul de la hauteur sur l’écran d’un "piquet" visible :
ouverture visuelle verticale : 30 degrés
écran
distance focale
16
zone 1
mur
zone 0
ouverture visuelle horizontale : 40 degrés
Calcul des coordonnées horizontales
zone 2
zone 3
écran
B
17
A
projeté de A sur l’écran
projeté de B sur l’écran
projeté de B sur le cône visible
3.2
2
2f
2b
L’algorithme du peintre
1
3
18
4
3
3
2b
J
2
1
2f
1
3.3
La gestion des collisions
Joueur
B
vectjb
(futurX, futurY)
La traversée d’un mur.
vectmur
3.3.1
A
vectja
19
3.3.2
2
2f
2b
3
O(log(n)) murs en moyenne à tester
1
3
20
2b
J
1
2f
3.4.1
3.4
Les classes principales
Structure du programme
– 20 classes
– Xquake : (Frame) choix des paramètres
– Visumonde : (Frame) accueil de l’application principale
– Monde : (Canvas) accueil des graphismes.
– BSPmurmonde et Murmonde : Les murs et les arbres BSP créés
par XBsp doivent être convertis pour être utilisables.
– Joueur : gestion des paramètres du joueur.
21
3.4.2
Les classes I/O
– Des classes "Listener" : GestionSourisMonde,
GestionKlavierMonde, GestionFocus
– Des threads qui gèrent les événements : GestionKlavierThread,
GestionSourisThread
– Un thread d’affichage Threadaffichage : le monde continue
d’évoluer entre deux affichages.
22
3.5
L’aspect ludique, les sprites
Fig. 1 – Les différents sprites du jeu
23
3.6
Le but du jeu : manger tous les pingouins
24
3.7
2b
La structure idéale
Joueur
J
3
BSPTREE
1
25
2f
S2
listesprites
S1
S3
3.8
Les problèmes rencontrés
– La gestion du clavier.
– Des problèmes de scheduling : Selon les machines la vitesse du
joueur peut parfois être inférieure à celle des sprites. Peut-être
faudrait-il calibrer les temps de latence des threads à chaque
lancement de l’applicaton ?
– Pas de problème de flottants cependant, comme nous aurions pu
nous y attendre.
26
4
4.1
Le début d’une extension réseau.
XquakeClient, XquakeServer, XquakeClientUI
– Cinq classes : XQuakeServer, ThreadedClientManager,
XQuakeClient, ThreadedClientListener, XQuakeClientUI
27
class XQuakeServer
TCM
TCM
TCM
TCM
Nouveau TCM
Message de connexion au serveur
28
class XQuakeClient
TSL
TSL
TSL
TSL
class XQuakeClientUI
4.2
L’adaptation de Xquake
– La classe SpriteJoueur : un tout début d’implémentation.
– Le client doit gérer les collisions de son propre joueur uniquement
et donner le chemin du joueur dans l’arbre BSP au serveur.
– le client doit demander au serveur les positions des sprites ainsi
que leurs "chemins" dans l’arbre BSP.
– le serveur gère les collisions des pingouins, leurs déplacements ainsi
que leurs "chemins" dans l’arbre.
– le serveur gère le "gobage des pingouins".
29
Conclusion
30