Open Source 3D Shoot'em up
Bonjour à tous,
Les votes sont clos depuis vendredi soir et c’est le thème de notre nouvel adhérent Kick (une fois encore) qui a été retenu : « Old School ». Vous avez donc jusqu’à dimanche prochain (8 mars 2012) pour rendre votre jeu vidéo (réalisé seul ou en binôme). Pour plus de précisions, je vous invite à lire l’interview sur gamesphere accordée par Tof & moi-même qui résume assez bien les enjeux de ce concours de création de jeu vidéo.
Une fois n’est pas coutume, un article un peu technique qui vise à faciliter – pour peu que l’on ne l’utilise souvent – l’emploi du container std::forward_list du nouveau standard C++11. Ce container comble une lacune de la librairie standard, à savoir la mise à disposition d’une liste simplement chaînée limitant l’overhead et favorisant la rapidité d’exécution. On remarque ainsi que le container ne dispose pas de membres size()1.
Je ne vais présenter plus avant pourquoi utiliser ce type de container mais il peut être utile pour gérer beaucoup de munitions par exemple.
Une autre difficulté à l’utilisation est que pour supprimer un élément via sa position (et non sa valeur => linéaire) , il faut connaîre l’itérateur précédent celui qu’on veut supprimer. Outre ceci, il faut récupérer l’itérateur retourné par la fonction membre erase_after pour garder des itérateurs valides. Bref réécrire le même code à la longue devient rébarbatif d’où ce court exemple qui propose un exemple qui prend en paramètre une instance du container, une classe et une fonction membre qui retourne vrai si elle veut supprimer l’élément traité de la liste:
template<class T,class PARAM>
void loopThroughBatteries( std::forward_list<PARAM>& container, T* instance, bool (T::*fn)(PARAM) )
{
FUS_ASSERT( (instance != nullptr) && (fn != nullptr) && "You should pass a function and an instance");
auto beginBattery( container.begin() );
auto beforeCurrentBatteryIt( container.before_begin());
auto lastBattery( container.end() );
auto currentBatteryIt = beginBattery;
while( currentBatteryIt != lastBattery )
{
//! quand retourne vraie on supprime
if( (instance->*fn)( *currentBatteryIt ) ){
currentBatteryIt = container.erase_after( beforeCurrentBatteryIt );
}
else {
beforeCurrentBatteryIt = currentBatteryIt;
currentBatteryIt++;
}
}
}
Exemple d’utilisation:
loopThroughBatteries( _activeBatteries, this, &IFleetForwardListBased:: periodicBatteryCheck );
avec
bool
IFleetForwardListBased::periodicBatteryCheck( IStaticBattery* battery )
{
bool stillOffscreen = getPlayState()->isEntityOufOfScreen(battery);
battery->stillOutOfScreen( stillOffscreen );
if( battery->getOffscreenCounter() > 3 )
{
battery->onTimeoutDisparition();
_INFO << "time out death";
return true;
}
return false;
}
Bon maintenant les bons diront qu’on peut faire exactement la même chose via :
_activeBatteries.remove_if( std::bind1st( std::mem_fun(&IFleetForwardListBased::periodicBatteryCheck),this) );
Malgré tout j’espère que cela vous aidera dans votre utilisation de std::forward_list.
Nous allons commencer par la configuration minimum avant de voir quelques astuces. Une fois connecté sur votre routeur, vous pouvez voir les associations en cours en tapant
# show ip dhcp binding
Parmi les commandes qui peuvent vous être Le serveur DHCP fonctionne avec un système de pool. Vous allez donc devoir créer différentes « pools » selon vos besoins. Avant de commencer, il faut passer en mode configuration (via #conf t) puis entrer la commande
(config)# ip dhcp pool <nomDeMaPool>
. Si la pool n’existe pas alors le routeur en créera une nouvelle. Il faut ensuite remplir les données que le serveur DHCP va distribuer:
(dhcp-config)# default-router <IP_de_la_passerelle>
(dhcp-config)# dns-server <IP_ServeurDNS1> { <ip_des_autres_serveurs_dns> ...}
(dhcp-config)# network <IP_du_réseau> <masque>
Je crois que les commandes sont suffisamment explicites. Si vous voulez tester les nouveaux paramètres, vous pouvez supprimer les associations en cours:
# clear ip dhcp binding {<IP> }
Il est temps d’aborder quelques notions qui peuvent vous faciliter la vie.
Si vous avez par exemple besoin d’indiquer un serveur tftp (pour faire des démarrages PXE ou parce que vos téléphones IP ont besoin d’un serveur tftp pour télécharger leur configurations) : il suffit d’ajouter de configurer l’option DHCP correspondante dans la pool:
(dhcp-config)# option 150 ip <IP_du_serveur_tftp>
Si vous voulez exclure une plage d’adresses IP ou même une simple adresse parce que certains de vos serveurs sont adressés statiquement, vous pouvez également le faire:
(config)# ip dhcp excluded-address <IP_basse> {<IP_Haute>}
Une astuce sympathique est également celle de pouvoir toujours attribuer la même adresse IP à un même ordinateur. Si vous êtes nomade (cad que vous vous connectez régulièrement à des réseaux différents), alors vous préférez sans doute rester en DHCP pour ne pas avoir à reconfigurer votre carte à chaque fois. Le revers de la médaille étant que vous devez vérifier via un ipconfig (ou ifconfig sous linux) quelle est votre IP à chaque fois que vous vous connecter sur le réseau. Avec l’astuce suivante, le DHCP vous attribuera toujours la même adresse. Comment fait-on ?
Vous devez créer une autre pool et ensuite associer votre MAC à une IP:
(config)# ip dhcp pool <nomDeMaNouvellePool> (dhcp-config)# host <IPqueJeVeuxDonner> (dhcp-config)# client-identifier <identifiant>
L’identifiant doit être donné sous la forme 01<mac> (le préfixe 01 indiquant que l’association se fait avec une MAC ethernet) avec des « . » tous les 4 caractères. Par exemple:
(dhcp-config)# client-identifier 0100.0000.0000.01
Maintenant imaginons que l’on change de carte réseau : l’association devient invalide ! Pour y remédier, on peut choisir une « locally administered MAC » comme identifiant. Pour ce faire, il suffit d’allers dans les propriétés avancées de votre carte réseau et d’entrer la MAC que vous voulez. Idéalement le bit de « locally administered MAC » doit être mis à 1.
Quelques liens en vrac pour ceux qui aimeraient comprendre la différence entre Universally/Locally Administered MAC (tous en anglais):
Note: A noter que la plupart des <IP> peuvent être remplacés par les noms d’hôte.
Me voici de retour pour une astuce rapide qui vous évitera comment upgrader l’OS sur les switchs/routeurs Cisco via la CLI. J’utilise dès que je peux le Cisco Network Assistant(aka CNA, petit logiciel gratuit utile pour configurer les paramètres de base, regarder la topologie depuis une GUI, supprimer des fichiers sur la flash etc…) qui vous permet d’upgrader l’IOS via un glisser/déposer. Malheureusement l’outil peut rencontrer des problèmes. Exemple:
command /overwrite /http not available <– message approximatif
Du coup il reste la bonne vieille méthode, on lance un serveur Tftp (celui de windows ou le très bon tftpd32) qu’on configure sur la bonne interface. On met le package de mise à jour (*.tar ou *.bin) dans le dossier partagé du serveur tftp.
On se connecte sur le switch (via telnet/ssh/console par exemple) et ensuite, au lieu de télécharger la nouvelle image, via tftp (copy tftp: flash: ) puis changer la valeur de BOOT (en mode config, boot system <chemin_vers_bin>), on va utiliser la commande archive qui va lancer des vérifications supplémentaires et éviter de se retrouver avec un switch sans ios (ha les joies de Xmodem !):
archive download-sw /allow-feature-upgrade /reload tftp://10.4.1.16/c3560-ipbasek9-tar.150-1.SE1.tar
Le /allow-feature-upgrade permet d’outrepasser le message suivant qui survient si l’on passe d’une image IP-BASED à IP-ADVANCED par exemple:
Error: The image in the archive which would be used to upgrade
Error: system number 1 does not support the same feature set.
/reload permet de redémarrer automatiquement l’équipement si le nouvel ios a bien été installé.
Si jamais la flash est trop petite…
Error: There is insufficient space in flash: to install the required
Error: image. Clean up some old images, and try again.
On peut ajouter le paramètre /imageonly pour extraire du tar le .bin uniquement (ou bien faire du ménage sur la flash avec delete). On peut également utiliser /overwrite pour supprimer l’ancienne image, l’option /safe permet de s’assurer que le switch redémarre correctement avec le nouvel ios avant de supprimer l’ancienne version.
A noter que l’on peut détarer un .tar directement depuis le switch avec la commande:
archive tar /xtract <source> <destination>
Des fois, malheureusement, on n’a pas le choix et il nous faut travailler avec svn au lieu d’utiliser un système de gestion de source moderne tels que Git ou Mercurial. Des fois même, il faut travailler et en plus sous windows ! On a les malheurs qu’on mérite. La plus grosse erreur que vous pourriez faire à mon sens est d’installer TortoiseSVN. Ca pourrit le menu contextuel, les icônes ne sont parfois pas mises à jour, on ne sait pas trop quel bouton exécute quelle commande, bref du grand n’importe quoi. Le mieux est donc d’installer le client svn windows classique depuis le site officiel, quitte à ajouter le dossier des binaires svn à votre path
Je vais prendre l’exemple d’Irrlicht car c’est pour contribuer à ce projet que j’ai du m’intéresser a problème.
Depuis la ligne de commande:
mkdir irrlicht1.8
svn checkout https://irrlicht.svn.sourceforge.net/svnroot/irrlicht/trunk .
(Attention au point, sinon svn crée un sous-dossier « trunk »)
Après on modifie les sources etc… Si on a créé de nouveaux fichiers alors on les ajoute via « svn add » (on peut utiliser des wildcards, l’option -R pour la récursivité). On vérifie que tout est à jour avec un « svn status » puis on crée notre patch via la commande:
svn diff > monPatchDuTonnerreDeZeus.patch (peu importe l’extension, il s’agit d’un fichier texte)
Jusque là rien de nouveau, c’est la procédure classique. Pour patcher sous windows, c’est déjà un peu plus sport car le programme « patch » de linux n’est pas présent par défaut. Il faut donc d’abord installer le programme patch.exe, l’ajouter à votre variable PATH (WIN+Pause -> Advanced Settings -> Environment Variables). Pour tester votre patch, placez-vous dans le même répertoire (au même niveau dans l’arborescence) et faîtes:
patch –dry-run -p0 < monPatchDuTonnerreDeZeus.patch
L’option –dry-run permet de ne pas appliquer les modifications du patch mais permet d’afficher les messages (erreurs comprises) que vous auriez eu si vous aviez réellement appliqué le patch. S’il n’y a pas d’erreur alors vous pouvez appliquer le patch pour de bon avec patch -p0 < monPatchDuTonnerreDeZeus.patch . Si jamais néanmoins vous avez des erreurs vous pouveez revenir en arrière en faisant un svn revert -R * . L’option « -pX » permet d’appliquer le patch depuis un répertoire différent de celui où il a été fait (remplacer « X » par le nombre de repértoires à enlever du chemin relatif). En l’état vous risquez fort d’avoir des problèmes et patch.exe va planter car les sauts de ligne ne sont pas ceux qu’il attend. svn diff crée des sauts de ligne Unix tandis que patch.exe attends des sauts de ligne windows (CR+LF). Vous devez donc effectuer la transformation vous-même. Par exemple avec Notepad++, on ouvre le patch puis dans les menus « Edition »-> »Convertir les sauts de ligne », on choist les fins de ligne windows, on sauvegarde et c’est tout bon.
Quelques liens en vrac:
http://www.journaldunet.com/developpeur/tutoriel/out/060906-subversion-svn-diff-patch.shtml
http://wiki.habariproject.org/en/Creating_and_Applying_Patches_for_Subversion
