L'un des objectifs d'un moteur est de simplifier le travail du programmer qui l'utilise.
Le CDevice va dans ce sens puisqu'il va gérer tous les différents modules du moteur (managers de ressources, bibliothèques tierces...)
Ainsi le programmeur n'aura qu'à lancer le CDevice au début du programme et l'éteindre à la fin pour avoir accès à l'intégralitée des fonctionnalitées du moteur. :)
Le constructeur de notre classe device va être un peu particulier... Il sera vide, et ne servira à rien. oO
La véritable fonction qui va initialiser notre classe et donc le moteur s'appellera init. (un nom original en effet ^^ )
Si on ne passe pas par le constructeur classique, c'est parce que notre classe est un singleton.
Eh oui rappelez vous, elle va gérer tout le moteur, il est donc essentiel qu'il n'en existe qu'une. On aurais l'air frais si les bibliothèques étaient lancées 2 fois par exemple...
Voilà donc comment les choses vont se passer : la première chose à faire dans le code de l'application sera d'appeler la méthode init en passant par la méthode getInstance de la classe CDevice.
Ce qui donne :
kgg::CDevice::getInstance()->init();
C'est un peu lourd comme notation mais bon, on ne l'utilise qu'une fois.
Au cas où le device ne serait pas initialisé, le reste du moteur serait inutilisable; et au cas où il serait initialisé 2 fois, et bien pas de problème particulier, c'est juste inutile. ^^
Voyons maintenant un peu les paramètres que va prendre init qui nous ont valus autant d'efforts :
Si le constructeur nous a posé problème, ce n'est pas le cas du destructeur qui remplira son rôle sans broncher, à savoir fermer proprement toutes les bibliothèques.
La 3eme méthode importante qui est propre à CDevice est template : addItem.
Nous avons vu dans le tout premier chapitre que pour gérer les éléments de notre jeu, on utiliserais une liste chaînée.
Et bien évidement, qui est mieux placé que le CDevice pour la gérer ? ^^
Cette méthode va précisement servir à ajouter un élément (item) à la liste.
Voyons maintenant les attributs de notre classe :
On peut éventuellement ajouter un itérateur pour éviter d'avoir à le recréer à chaque fois qu'on veut parcourir la liste. :)
Bon autant vous prévenir maintenant, il n'y a pas grand chose de palpitant au niveau de l'implémentation. ^^
Commençons par le plus court, la méthode render :
/* 01 */ //On parcourt toute la liste et on appel la méthode paint de chaque élément.
/* 02 */ for(m_iterListe = m_liste.begin(); m_iterListe != m_liste.end();
/* 03 */ m_iterListe++)
/* 04 */ {
/* 05 */ (*m_iterListe)->paint(m_ecran);
/* 06 */ }
/* 07 */ //Mise à jour de l'écran
/* 08 */ SDL_Flip(m_ecran);
Les commentaires parlent d'eux mêmes; à noter qu'on a ici un itérateur en attribut, ce qui évite d'avoir à en (re)créer un autre.
Cette méthode est en fait l'aboutissement de l'architecture polymorphique du moteur.
Tout ce qui sera affiché à l'écran est contenu dans cette liste, et cette méthode fait appel à la fonction de mise à jour de chaque élément.
Ce qui implique que la disposition des éléments dans cette liste détermine aussi leur ordre d'apparition à l'écran.
Si vous voulez qu'une surface soit au premier plan, il faut se débrouiller pour qu'elle soit la dernière de la liste. ;)
Voyons maintenant rapidement ce qu'il y a dans la méthode init. (nous rappelons que le constructeur est vide)
On commence par initialiser le générateur de nombres pseudo-aléatoires de la bibliothèque standard. (Qu'il ne faut initialiser qu'une fois durant tout le programme nous rappelons ;) )
Puis on démarre chacune des bibliothèques utilisées par le moteur en se servant des paramètres de la fonction au besoin et en testant les valeurs de retour à chaque fois.
Si une initialisation de bibliothèque échoue, inutile d'aller plus loin, c'est pourquoi tout ceci est inclue dans un bloc try, et au moindre problème, une exception est levée contenant le message décrivant ledit problème.
Elle est capturée desuite et le message est loggé dans le logger interne du moteur. (CInternalLogger)
De cette manière on est sur que l'initialisation du moteur s'est bien passée, ou si ce n'est pas le cas, on sait au moins pourquoi. :)
Le CDevice remplace en quelque sorte le code de la fonction main d'une application "classique" utilisant ces bibliothèques.
Regrouper toute cette gestion dans une classe est la meilleurs solution d'un point de vue objet, cela permet d'encapsuler les bibliothèques et décharge l'utilisateur de la "corvée d'initialisation". ^^
