Voici une petite animation d'une boule rencontrant un mur de briques
L'animation a été générée en construisant le mur et la boule dans le "Game Engine", puis en ajoutant une force à la boule dans la bonne direction. L'animation est ensuite enregistrée, et la scène peut alors être retravaillée dans le mode rendu.
Cela m'ouvre des horizons quant à la manière de gérer ses animations, en comptant beaucoup plus sur le "Game Engine" et ses scripts visuels plutôt que d'enregistrer des keyframes.
Nouvelle vidéo de notre bonne vieille planète. Cette fois-ci, j'ai rendu 1 minute de rotations en haute définition. Ma machine a trimé une bonne partie de la nuit, avec environ 6 heures à maximiser mes 4 CPUs.
Je suis tombé sur l'excellent tutoriel d'Andrew Price sur comment modéliser la planète Terre dans Blender, à partir des images de la NASA. Du tutoriel, je retiendrait la puissance des nœuds de matériaux, qui permet notamment de sélectionner la texture "jour" ou la texture "nuit" via la couleur de rendu d'un matériau postiche, et la puissance des nœuds du mode de composition qui permettent notamment des effets de halos qui rendent particulièrement bien.
Également, le raccourci du jour: Ctrl-Alt-Num0 déplace la caméra de manière à rendre ce que vous voyez dans la vue courante. Beaucoup plus pratique que de se battre à déplacer manuellement la caméra au bon endroit!
Voici d'abord l'image:
Et voici également la vidéo:
Quittons un instant le monde des ordinateurs dits "de bureau", et arrêtons nous du côté de la Sega Megadrive, pour jeter un coup d’œil à Landstalker. Landstalker est un RPG en vue isométrique, où vous incarnez un elfe chasseur de trésor rencontrant une petite fée qui dit savoir où se trouvent les trésors du roi Nole. Il n'en faut pas plus pour se lancer!
Ce qui frappe quand on commence à jouer à Landstalker, c'est bien évidemment cette 3D isométrique. Parce qu'elle permet également de se déplacer en hauteur via marches, escaliers, ponts, tunnels, étagères, corniches, ce sont des mondes beaucoup plus complexes qui sont disponibles, avec les énigmes qui vont avec. Le monde en lui même est riche et cohérent, composé de villages et de villes reliés par des chemins mal fréquentés, menant parfois à des ruines ou des cavernes contenant un élément essentiel pour faire avancer l'histoire. Dans les villes, l'on pourra entrer chez les gens qui auront souvent des choses intéressantes à dire, se réapprovisionner auprès des commerçants, ou jouer à des mini-jeux. La quête pour les trésors du Roi est entrecoupée de sous-quêtes où l'on pourra aider un villageois enlevé par des brigands ou déjouer un complot à la cour du roi local. Une équipe de chasseurs de trésors concurrente nous met régulièrement des bâtons dans les roues.
C'est souvent l'impression de liberté qui me permet de rentrer dans le jeu, et de ce côté là, Landstalker fait très fort. L'histoire est linéaire, mais reste suffisamment vague sur les détails pour nécessiter de l'exploration. Le monde est rempli de passages secrets et autre caches permettant d'amasser des sous ou de l'équipement, et il est possible de parler à tout le monde (et même aux animaux). L'humour est omniprésent, ainsi qu'une petite dose de grivoiserie, le héros étant tout à fait intéressé par les jeunes filles, et la petite fée jalouse comme une tigresse.
Les musiques sont très entraînantes, mais parfois un peu répétitives, puisqu'il s'agit du même morceau d'environ 1 minute mis en boucle pour chaque atmosphère (donjon, village, campagne...). De fait, c'est quasiment hypnotique, et je peux encore les chanter pratiquement toutes par cœur plus de 15 ans après y avoir joué.
Le jeu est terriblement difficile (j'étais loin de l'avoir fini à l'époque) et les boss sont redoutables. Il est parfois trop facile de se retrouver à tourner en rond, et du temps où Internet n'existait pas, l'on pouvait se prendre la tête pendant des heures sans trouver l'astuce pour continuer.
Landstalker est sorti sur la console virtuelle sur WII. C'est tentant, non?
Parlons un peu des routines de la libc que sont localtime_r, gmtime_r, mktime, et timegm. Ces fonctions sont utilisées pour convertir l'heure Unix (le nombre de secondes depuis le premier Janvier 1970) en une structure tm qui contient année, mois, jour, heure, minute et seconde, et inversement, en utilisant l'heure locale ou l'UTC.
Il est donc raisonable pour localtime_r et pour mktime d'accéder à la variable d'environnement TZ pour obtenir le fuseau horaire nécessaire aux conversions en temps local. Il est également raisonnable de protéger ladite variable d'environnement par un beau mutex global. Les performances s'écroulent lorsque trop de threads cherchent à faire des conversions de dates (imaginons par exemple un système de log multithreadé).
Ce qui est moins raisonnable, c'est que beaucoup d'implémentations de gmtime_r et timegm (notamment dans la glibc de RHEL5) utilisent les mêmes routines que localtime_r et mktime, et donc tentent d'acquérir le mutex global quand bien même elles n'en ont aucunement besoin, puisqu'il n'y a pas d'ajustement de fuseau horaire à effectuer. Les performances sont meilleures (6x plus rapide sur mon benchmark) car les calculs sont plus simples, mais il y a encore ce mutex qui s'obstine à nous pourrir la vie.
En allant regarder du côté de FreeBSD, on trouve en revanche des implémentations directes, sans mutex, des fonctions sus-citées. Collons ça dans le code, et c'est un facteur 3 qui est gagné.
La conclusion, c'est que pour faire quoi que ce soit d'avancé avec les dates, il n'y a pas trop le choix: il faut écrire sa propre classe DateTime, extraire les données brutes des fuseaux horaires depuis la tz database, faire soi-même les ajustements, et importer du code lock-free pour ses conversions.