Les graphismes des murs
J'ai téléchargé les graphismes originaux sur ce site (j'ai pris ceux de la version 3.6 Amiga).
Vous pouvez voir les graphismes du sol, du plafond et des murs dans "game\data\gfx\3DView".
Je les ai enregistrés en PNG parce que c'est un format sans pertes, donc il ne modifie pas les images comme le JPEG, et il a de la transparence.
Les images d'origine n'avaient pas vraiment de transparence, mais elles étaient pallétisées, et une des couleurs de la palette était considérée comme transparente.
Ces murs ont l'air un peu étranges. Il y en a des courts et des longs, certains sont de face, de coté ou il y a des blocs qui contiennent à la fois un mur de face et de coté.
Pour comprendre comment ça marche, on doit les placer à l'endroit où ils doivent apparaitre à l'écran.
Ouvrez le fichier "wall_pos.xcf" dans Gimp pour voir où ils devraient être. Vous pouvez zoomer l'image de 200% ou 400% pour mieux voir.
Maintenant regardez la fenêtre des calques.
En bas vous pouvez voir des captures d'écran du jeu que j'ai trouvées sur internet. Je les ai utilisées comme référence pour trouver où placer les murs.
Vous pouvez en rendre une visible pour servir d'image de fond si vous voulez, mais on n'en a pas vraiment besoin.
Juste au-dessus des captures d'écran, vous pouvez voir les calques du sol et du plafond.
Tous les calques au-dessus sont ceux des murs.
Maintenant, cachez tous les calques des murs en cliquant sur les petites icones "oeil" à coté d'eux.
Vous devriez maintenant voir seulement le sol et le plafond:
Maintenant, on va faire réapparaitre les murs un par un en partant de celui du bas jusqu'à celui du haut.
Donc on commence avec "Wall3_FarLeft", et on va voir successivement:
Une ligne de murs apparait devant nous depuis les cotés de l'écran. Et a la fin on obtient un seul gros mur de face.
Mais pourquoi pendant le processus des murs de cotés sont affichés en même temps que ceux de face ?
En fait ça nous montre que contrairement à la représentation qu'on a choisi pour la map, le jeu d'origine utilisait une représentation basée sur les cases.
Imaginez que chaque case de la map peut être soit "vide" (sans murs), soit "pleine" (entourée de murs).
Ce qu'on voit ci-dessus, c'est qu'on démarre avec une map "vide" et à chaque étape on dessine une case "pleine".
Pour être précis, on voit les faces "extérieures" des murs qui entourent chaque case "pleine".
Souvenez-vous qu'on a choisi une représentation basée sur les murs, et qu'on stocke les faces "intérieures" des murs de chaque case...
Mais on verra dans une prochaine partie que ça ne sera pas très difficile d'adapter les graphs à notre représentation.
L'ordre est important
En effet, quand vous regardez ci-dessus, chaque nouveau mur cache un mur de coté qui a été dessiné précédemment.
Si vous ne suivez pas cet ordre vous aurez des murs de coté qui apparaitront devant des murs de face. Vous pouvez simuler ça en changeant l'ordre des calques,
et vous obtiendrez quelque chose comme ça:
Si vous continuez de faire apparaitre les autres calques de bas en haut, vous verrez des murs apparaitre de plus en plus proches.
C'est le 2ième ordre qui est important: dessiner d'abord les murs les plus loins, et finir avec les plus proches.
Evidemment, c'est facile de comprendre que les murs lointains seront cachés si on en dessine des plus proches.
En graphisme sur ordinateur, c'est ce qu'on appelle l'algorithme du peintre, parce que l'on travaille comme un peintre qui peint d'abord le paysage dans le fond,
et ensuite les sujets au premier plan.
Le projet du jeu
Après toutes ces explications, je vais décrire rapidement le projet Qt pour le jeu.
J'ai choisi de faire tourner le jeu avec Qt par commodité, même si ce n'est pas vraiment le meilleur moteur pour les jeux.
Si on était en train de créer un jeu moderne avec des animations fluides qui doivent tourner au moins à 60 images par seconde, j'aurais probablement créé un projet
OpenGL ou DirectX. Mais ça aurait rajouté plus d'outils et de librairies.
Les animations du Dungeon Master original sont très basiques, et loin d'être à 60 FPS (elles sont plutôt entre 10 et 15 FPS).
Alors, même si la synchronisation de base de Qt, avec de QTimers n'est pas très précise, ça sera suffisant (et en guise d'exercice, vous pouvez toujours essayer de faire
tourner le jeu dans un widget OpenGL de Qt...).
De plus, c'est aussi plus pratique de pouvoir ouvrir le projet de l'éditeur et celui du jeu côte à côte dans QtCreator.
Donc pour le jeu, j'ai créé un répertoire "game" avec une structure très similaire à l'éditeur:
- Un dossier "sources" avec les fichiers ".cpp" et ".h".
- Un dossier "qml" avec les fichiers qml.
- Et un dossier "data" avec les données chargées pendant l'exécution.
Je vous laisse explorer les fichiers sources car ils sont très simples (pour le moment, le projet affiche juste les images du sol et du plafond).