Ori and the winning strategy

Immobilisé, incapable d'enregistrer des chapitres de HPMOR à cause de ma toux et ma fée en formation plusieurs soirs par semaine, tout ça après que j'aie redémarré une partie d'Ori and the Blind Forest, il n'en fallait pas beaucoup plus pour que je me refasse le jeu presqu'en entier. Mais suite à un bug casse-pied, j'y rejoue sur un nouveau compte de ma Switch, plutôt que "à côté" de la partie terminée. Pas question, donc, de retourner jeter un œil sur la carte d'une partie plus avancée pour renifler où sont les power-ups cachés et améliorer plus vite ses compétences.

Vous vous doutez bien que, depuis le temps, je n'ai pas non plus retenu leurs emplacements. Mais par
contre, je n'ai pas oublié que le jeu propose les compétences "voir les cellules de vie sur la carte" et autres annotations du genre. Ma stratégie sera donc la suivante :

• mettre tout sur la branche de compétences qui mène aux cartes complètes, dès le début du jeu, et ne regarder aux autres qu'en cas d'absolue nécessité.

Une autre chose que je n'ai pas oubliée : le terrier noirracine, avec son DASH (disponible dès le téléporteur avant la baignade interdite) et surtout sa petite lumière-à-lancer (disponible presqu'immédiatement après), vu que je sais qu'elle va permettre de déverrouiller l'accès à pas mal de points de compétence "gratuits".

Eh bien cette stratégie s'avère plutôt gagnante, puisqu'à l'arrivée à l'entrée du 2eme "donjon" du jeu, j'arrive à débloquer malgré tout le triple-saut, tout en pouvant échanger 1 point de Mana contre 2 points de vie lors d'une sauvegarde. J'ai aussi tellement de points de vie que les obstacles qui pourraient me one-shotter sont devenus rares, et tellement de points de Mana que je n'ai presque plus besoin de me retenir de faire des Sauvegardes. Bref, on est loin du feeling de "die and retry" injuste ressenti lors de ma toute première partie.

Finally doing some pthread stuff

For years and years, I've staid away from multi-threaded programming. Not that I dislike threads per se: I once made a multi-threaded micro-kernel myself after I spent countless hours studying IA32 Task State Segments. But who needs threads when you have two ARM cores, hardware interrupts for driving your sound DSPs and proper multi-layers video chip anyway ?

Even for network / system programming, I tend to prefer use pipes or socketpairs over threaded stuff. They strace better. You can actually see the flow of acknowledgements between entities. For most things, this is preferable over raw performance.

But a couple of years ago, I've been thrown in a pool where threads are already there and I need to swim with them. Parts of the pool use boost abstractions and are usually not too hard to work with because my colleagues did a great job at building robust RIAA things around those abstractions. But other parts of the pool use plain pthread + plain Windows thread/event/locks API. And as you can guess, upgrading corporate project to use C++11 threads is usually not easy (not that I know these any better, though).

One function that is used a lot in that code is pthread_cond_timedwait(). And there are a few things you must not do with that:

• do not call it if you're not holding the mutex argument
• a corresponding pthread_cond_signal is lost (not buffered) if no one is waiting on the condition at the moment of cond_signal

(more to come)