Don't send namespace do an inline job

Okay, granted, I'm not a namespace master. I know they exist, I know they are helpful, but I'm not using them a lot myself, and I'm never too sure how I should write things like "namespace cp = Clicker::process;". I'm not completely sure whether going for "using namespace ietf::http" within HttpServer class is smart or silly.

Anyway. I had code in a .cpp I wanted to extract into a .h, for it contained assert helpers that should now be used in more than one test program. Unfortunately, when I started using it in my new program, I got the linker complaining that some assert_bool() function was defined in multiple .o files. That was the only one that was no template, unlike assert_equals() and its children. I then foolishly wrapped the whole thing into a "namespace /* anonymous */{", so that things couldn't be reused in multiple areas.

But one instance of gcc got it wrong. You see, I'm not using that assert_bool() in all my .o, and that version of gcc, with its parano flags settings, thought it shouldn't keep going with dead code: assert_bool() wasn't used internally in that translation unit, and it couldn't be used from outside, as it was anonymous for the rest of the world.

What I should actually have done was to define the function "inline". Simply.

Thème Mobile ?

Tout ça parce que j'avais décidé de ne pas prendre de carnet-geek pour la patrouille de St-Valentin, mais que ma fée avait besoin que je l'attende (sans avoir besoin de son smartphone). Du coup j'ai découvert que '?m=1' passait sur le "thème mobile" de blogger. Un thème à l'ergonomie acceptable, mais perfectible (en ce qui concerne les tags, notamment).

Par contre, pour ce qui est du look ... euh ... y'aura un peu de travail, là. 

If you want to customize your Mobile template styles, you need to set the Mobile Template to Custom.

By then any additions to your Theme "Edit HTML CSS" section will be rendered.

Using Blogger built in functionality use the .mobile classname to target the styles for mobile views. Example

.mobile .post-title {
  font-size: 21px;
}

Will change the post title size to 21px on mobile device but does not effect the post title web view style.

Et moi, il faut que je m'adapte à un truc comme

<div class="mobile-date-outer date-outer">
  <div class="date-header">
    <span>Monday, February 17, 2020</span>
  </div>
  <div class="mobile-post-outer">
    <a href="http://sylvainhb.blogspot.com/2020/02/theme-mobile.html?m=1">
    <h3 class="mobile-index-title entry-title" itemprop="name">
Thème Mobile ?
    </h3>
    <div class="mobile-index-arrow">›</div>
    <div class="mobile-index-contents">
      <div class="mobile-index-thumbnail">
        <div class="Image">
          <img src="https://1.bp.blogspot.com/-7w5i6XE-rQg/Xkp_FEWuuCI/AAAAAAAAI_E/b4RuPqzNa2U8w-glm-OsOIgAwT3b7XaowCLcBGAsYHQ/s72-c/Screenshot_2020-02-17%2BBlogger%2BBilou%2BHomeBrew%2527s%2BBlog%2B-%2BTheme.png">
        </div>
      </div>
      <div class="post-body">
Tout ça parce que j'avais décidé de ne pas prendre de carnet-geek pour la patrouille de St-Valentin, mais que ma fée avait besoin que je...
      </div>
    </div>
    <div style="clear: both;"></div>
    </a>
    <div class="mobile-index-comment">
    </div>
  </div>
</div>

• la partie "bannière" est bien trop haute. Il faudra changer la valeur height dans #header-wrapper (80px) et ajuster le padding du #header (top: 10px)
• le titre du blog doit arrêter de se faire compresser sauvagement (padding droit de #header).
  
• la petite "flèche" à droite de chaque entrée n'est plus à droite. Il faut lui rendre son thème.
• la ligne d'aide à la navigation doit se faire une place plus normale. (disons avec position: absolute, top: 100px, right:20px)
• il faut remettre une ligne entre les items
• il faut que les thumbs soient flottants (float et padding sur #mobile-index-thumbnail)
• il ajuster les pixels de bordure sur la gauche.
• il faut réparer la largeur de la page (widthde #content-wrapper, #header-wrapper)

Bon, ce qui tient lieu d'éditeur de thème pour blogger est assez peu ergonomique, et la technique du  .mobile ne marche pas pour tout. Donc, pardon mais il est possible que le look du site soit tout cassé pendant quelques jours parce que je ne vais quand-même pas prendre congé pour ça :-P

Plate-formes volantes ?

Si je veux faire quelque-chose de plus "aérien" pour la dernière zone, il va me falloir des plate-formes volantes. Mais voilà, je n'ai pas envie de leur coller des petites hélices (qui aurait fabriqué ça) ou d'invoquer du gravitium (pas partout, en tout cas). Pas envie de resservir le cliché du "bloc de pierre collé à un autre bloc de pierre qui vole grâce à des petites ailes de Parakoopa" ...

Pas convaincu non plus par des piafs qui auraient justement une forme de plate-forme. Il y a quelque-chose d'un peu ce genre-là dans DKC:TF, mais il s'agit de plus de bumpers volants -- rôle que les parakoopas avaient employé déjà bien avant. Ici, je veux bien parler de quelque-chose de suffisamment large pour qu'on puisse marcher dessus et de suffisamment coopératif pour qu'on puisse traverser un écran avant qu'il ne s'en aille.

You know, I'm trying to make Bilou's Adventure a somewhat consistent world. I won't say "believable" or anything like that, because we play as a ball with hands/feet floating around him anyway, but I'd like to avoid introducing too many alien elements like gravity-defying blocks or cartoon pockets or even human characters. If something exists in the game's world, at least Bilou and Bouli must find it believable. And that makes designing a mountain level with floating platforms ... a bit more challenging. I'd like to avoid the generic, Zool-like "floating rectangle -- just don't ask", and its Mario-like "floating rectangle with not-so-little wings".

Je m'oriente vers un croisement entre les zeppelins et les piafs. Les saucisses/zeppelins, c'est sympa. J'ai bien aimé l'idée dans Endymion, dans Titan et dans "L'incident Jésus". Dans Kirby, aussi ^_^. Avec un bec et des zyeux, on peut leur donner plus d'expressivité et les écarter d'une trop grande ressemblance avec Kirby, justement.

ils sont suffisamment dépendant des caprices du vent pour ne pas vraiment pouvoir éviter que Bilou ne les emprunte, pas vraiment mis en danger par ses atterrissages non plus.

I've postponed this post for a while as I was considering and then discarding ideas. I finally converged towards zeppelin-birdos. I loved zeppelin-like sentient creatures in Endymion, Titan and Frank Herbert science fiction books. They're close enough from a regular platform shape so that we can land and walk on them, not just bump on them. But in Bilou's world, it would be best if they had eyes and stuff that can suggest they feel something. And giving them little wings will make them more interesting to look at when you're not on them. But they're wings are too small to be able to do anything but follow the winds. And their body is soft enough to avoid taking damage from Bilou's lands.

Sure, I'm not the first one to try using second-class creatures as platforms. One of the most prominent example I can think of are the owls in Tropical Freeze. You'll note that these are more floating bumpers than floating platform, though: you cannot move freely just like on a parakoopa. And it make sense: if you had intruders landing on your head, chances are you wouldn't just wait for them to leave. Even the Parabeetles don't just keep moving unchanged if you land on them. Maybe SML2 owls ?

J'ai écarté juste avant ça des tapis volants (pourtant, des écharpes rouges volantes, ça aurait été un clin d'oeil sympa) et des plate-formes pendues à des poulies. Des cordes et des ponts suspendus, il y en aura sans aucun doute, mais je n'ai aucune raison pour justifier que Bilou ne puisse pas s'accrocher au "câble porteur", et donc c'est très différent d'une plate-forme volante.

A final word about dismissed designed. No flying carpet (flying scarf could have been fun). No walkable cloud. Since I plan to have ropes between peaks here and there, I must admit I've been tempted to go for platforms-on-pulleys. But no matter how I approached it, I couldn't explain why Bilou wouldn't just grab the carrying rope in case of emergency. Knowing my kids, they'd feel it unfair if they went for the rope and just fell through what is just decoration element.

Soldier Blade: can you be Mr. Perfect ?

Quelque part entre 2000 et 2001, mon frère me ramène un émulateur PC-Engine et une quantité impressionnante de ROM pour aller avec. N'étant pas un fan de Bonks, je lève un sourcil circonspect. Une machine de 1989 ? T'es sérieux, là ? Mais deux semaines plus tard, j'arrive au bout de Tyrian, donc je jette quand-même un coup d'oeil à ce que son CD a dans le ventre ...

Et je tombe sur Soldier Blade. J'ai toujours eu un faible pour les shoot-em-up (un reste de ma phase 'quand je serai grand, je serai astronaute' d'avoir lu les Yoko Tsuno, j'imagine), mais à part Warhawk sur C64, je dois bien reconnaître que j'ai finalement assez peu joué aux titres de shoot, largement dominés à l'époque par le style 'R-Type' où le vaisseau explose au moindre pet de moustique.

Tyrian était plus dans la veine de Warhawk, avec une barre de bouclier qui compense la majeure partie des tirs encaissés. Mourir, dans l'un comme dans l'autre, c'était recommencer le niveau du début, parfois en aillant perdu une partie de ses power-ups dont je dépends tant. D'où mon attachement à Tyrian où au moins on fait l'acquisition de certaines armes de manière définitive.

Soldier Blade avait un comportement différent et assez unique pour moi: on peut stocker des power-ups, les consommer comme super-bombes (généralement contre les boss), les combiner pour monter en puissance (si je ramasse 3 power-ups "laser" à la suite, sans ramasser de 'plasma' ou de tirs rouges, je passe au laser-niveau-3 en trident. Cerise sur le gateau, si j'ai le laser-3 et que je ramasse un 'plasma', je passe directement à plasma-3 (note bien ça, Space Invaders Extreme).

Si je me fais latter, mon vaisseau explose, éparpillant mes power-up autour de moi. Un autre vaisseau arrive alors assez rapidement à la rescousse pour reprendre le combat. Suffisamment rapidement pour que je puisse récupérer au moins 2/3 des power-ups perdus. La pénalité est beaucoup moins rude que dans un R-Type où on redémarrerait avec un vaisseau "tout nu".

Avec une bande-son tout en synthé qui donne la super-pèche, des graphismes certes aux coloris limités mais réalisés avec un brio, le jeu a beau tourner sur un processeur 8-bit, je suis scotché. Mais voilà: le jeu ne propose aucune sauvegardes et cet émulateur-ci, contrairement à z-snes et nesticle (que j'ai beaucoup utilisés sur mon AMD K6-II à l'époque) n'offre pas de save-states. Du coup, le seul moyen d'aller plus loin dans le jeu en cas de game over, c'est de recommencer et de s'améliorer. Recommencer de la mission 1.

Bref, après quelques semaines d'entrainement intensif (l'avantage d'avoir réussi en 1ere session à l'unif, c'est qu'on a deux mois de vacances ;-) arriver à la mission 6 était devenu une sorte de formalité. Un peu comme faire ses gammes. Y arriver avec suffisamment de vies pour pouvoir atteindre ce que je croyais être le boss final, c'était une autre histoire: on parle quand-même d'un niveau 2 fois plus long que les autres, avec des espèces de boss rush. Battre le boss final, je n'y suis jamais parvenu. Il aurait presque fallu faire un sans-faute jusqu'au boss pour pouvoir tenter le coup.

Si le jeu n'est pas à proprement parler un 'bullet hell', il y a quand-même énormément de projectiles à éviter, chacun susceptible de détruire notre vaisseau. Si bien que j'ai fini par prendre conscience que je jouais mieux quand je n'essayais plus de regarder en détail les différents objets du jeu. Je fixais mes yeux au centre de l'écran (non plus sur mon vaisseau) et je concentrais mon attention sur ma vision périphérique. Je pouvais alors bien mieux détecter les différent mouvements et guider mon vaisseau vers les zones dégagées.

Je ne suis pas devenu "Mr. Perfect". Je n'ai pas fini le jeu. Peut-être si j'avais pu me rendre compte que le vaisseau-compagnon peut faire office de bouclier contre à peu près tous les projectiles ?

Thèmes Elementaux

Faute d'un meilleur terme. Mais je suis retombé sur une cogitation de fin 2019 quand est apparu l'idée de faire un 'Bilou's Dream Land', mais avant que la décision ne tombe de prendre la montagne (Peaks Zone) comme 4eme et dernier niveau.

You know those many games where the levels are designed around "elemental" themes. Like fire - ice - forest - water - air - metal. It's almost everywhere. And it's not the most novel idea you can think of. But it brings in something interesting, as all the challenges / monsters can be designed around a unifying concept. And generic ideas can be declined according to levels, like fire-bats in the fire zone, freezing-bats in the ice zone, and so on.

I'd like to have diversity in 'Bilou Dream Lands', but not that kind of diversity. What I'd like to have is gameplay diversity. I've ruled out having keen-like keys and doors in the School Zone because it would make little sense, but I'd like to have them in a Bilou game anyway. At least in the pyramids. For the lack of a better term, I'll think of those as "elefundamental gameplay themes".

pour l'inspiration. Hoshi wo ou kodomo via Tohad

Quel environnement utiliser pour la 4eme zone de ce nouveau jeu? La logique voudrait que je réponde "le chateau" pour m'intégrer au mieux dans le design existant (monstre, tilesets, etc.) Mais ça nous donnerait avec la School Zone et la Pyramide un 3eme environnement "artificiel" qui risquerait d'être redondant.

Je suis très tenté de répondre "le temple englouti", mais je préfère le garder pour un jeu plus complet du point de vue scénario. Il faudrait que je trouve 4 "thèmes éléfondamentaux" au niveau du gameplay. La pyramide apporte le thème "labyrinthique". l'école quelque-chose de plus "militaire" avec des ennemis organisés et sous les ordres de Square Root.

La logique voudrait aussi que le 4eme monde soit le plus exigeant au niveau du "platforming". Potentiellement plus vertical et/ou avec plus de trous/lave/... (partant du principe que je ne recyclerai pas le niveau vertical de fin de School Rush pour ce jeu).

So, what are the 'gameplay themes' for the already-designed zones ? and what should the 4th zone offer to complete the experience in an interesting way ? Pyramid level at least is clear to me: it brings in the 'maze-like' theme. The School zone brings in the 'invasion army' theme with pendats following SquareRoot orders.

There wasn't much 'theme' for the green zone, but it could turn to cooperation with NPCs like the rabit and the frog. Now, what should be in the 4th zone. What is missing ? Possibly some tricky-platforming elements, with moving platforms and so. Think about mushroom levels in NSMB, if you want to picture what I'm talking about. The extra bonus with 'platforming' as the fundamental theme for level 4 is that it stems for open-space areas rather than enclosed areas and will better balance the game than, say, a "castle zone" or "lost temple" would do.

Je n'ai pas de meilleur nom pour ça, mais si vous voyez les niveaux-champignons de SMB et NSMB, vous avez une idée de ce que la 'peaks zone' pourrait apporter comme thème élémental. Bon, bin j'ai plus qu'à trouver quelque-chose qui convienne pour les plate-formes volantes, du coup...

Pourquoi ce trip "thème élémental" ? Disons qu'il est classique dans les jeux de baser les différents mondes autour d'un thème basé sur un élément (eau, feu, roche, air ...). Chacun de ces thèmes inspire à son tour des idées d'obstacles, de monstres, de boss... Mais si on prenait le contre-pied. Si on cherchait à avoir des thèmes de gameplay pour définir chaque "monde".

Nouveau Gimp

Je n'ai malheureusement pas réussi à ce que Gimp conserve ses anciens paramètres lors de l'installation de mon nouveau PC de bureau. J'ai même été franchement contrarié de les voir passer à une interface "tout intégrée en une seule fenêtre" comme le "nouveau" lecteur PDF d'adobe (eh non, plus moyen de continuer à utiliser Acrobat XI un peu plus longtemps). Mais au moins, chez gimp, on a une cochette [x] Single Window Mode pour si on veut utiliser une image de référence sur un écran pendant qu'on bidouille ses pixels-à-soi sur l'écran d'à côté.

Restons confiant, donc. Après tout, j'ai aussi pu remettre mon 'F12 = snapshot" en cherchant 'screen' dans Edit > Keyboard Shortcuts. (enfin, il fallait quand-même d'abord activer [x] Use dynamic keyboard shortcuts dans Edit > Preferences).

Je n'étais pas franchement convaincu par l'interface revisitée pour changer la taille du pinceau/crayon. 'faut dire que je suis plus souvent entre 1 et 4 pixels qu'entre 20 et 800, personnellement. La 'nouvelle' interface sépare chaque barre en deux zones, une qui permet un règlage absolu (sur le dessus de la barre. Le curseur souris devient une flèche verticale) ou relatif (sur le dessous de la barre. Le curseur ressemble à "changer la taille des colonne"). Mais ni l'un ni l'autre n'offre la vitesse de réaction que j'attends de mon outil.

Je sais que j'ai déjà changé ça: j'avais remappé CTRL+SHIFT+roulette, qui par défaut change la 'forme' du pinceau (ovale vertical -> cercle -> ovale horizontal). J'ai juste oublié comment j'avais fait.

5-10 minutes d'exploration des préférences. Toujours rien. Je cale. Je finis par refaire une recherche et tomber sur la vidéo-tuto où j'avais probablement trouvé le truc la première fois. Je n'étais pas loin: il faut bien aller dans 'input controllers' (logique), mais ce n'est pas un clic droit qui me proposera de configurer les choses. Un bon vieux double-clic-qu'on-avait-oublié-depuis-l'ipad.

J'ai pris tool-increase-size-relative, mais je ne suis pas 100% convaincu. J'aurais aimé pouvoir passer de 1x1-2x2-3x3-4x4-5x5 à 6x6, au lieu de quoi j'ai le choix entre 1x1-2x2-4x4-8x8-... et 1x1-3x3-3x3-3x3-5x5-5x5-5x5-7x7-...
Bah. ça fera l'affaire au bureau, j'imagine.

Au tour de meka-blador ...

Même si, j'avoue, mon analyse de "et qu'est-ce qu'on fait maintenant" m'avait conduit à définir MetaEdit dans l'éditeur de niveau comme la priorité suivante ... Mais la tentation a été trop grande: comment se comporterait un vrai personnage dans les tests automatiques de pentes que je viens de faire fonctionner avec un 'tic-tac-Bilou' complètement abstrait.

Je n'en suis pas au stade du Test.Read("blador.cmd"), mais j'ai au moins pu charger un vrai .spr et en extraire les animations (Merci, MedsAnim) puis constuire un nouveau cas de test basé sur un bout de texte extrait directement de blador.cmd.

Pour les bonnes nouvelles on s'arrête bientôt. Le meka-blador obtenu comme ça ne passe pas les tests. C'est qu'il est basé sur la vieille technique des testpoints qui sondent l'environnement autour de lui, et l'arrêtent avant qu'il n'approche trop du bord d'une plate-forme (là où le comportement de Bilou le laisserait avancer au-delà du bord). Mais blador ne saute pas.

Bref, mes collègues m'ont lancé dans la lecture de "Working Effectively with Legacy Code" où il est notamment question de "comment va-t-on s'y prendre pour que notre code écrit avant l'introduction des tests unitaires puisse subir des tests unitaires sans endommager sa fonctionalité". Je fais donc des p'tits exercices pratiques avec un iStateInspector que l'on peut définir au niveau de la classe GameObject et qui sera passé aux appels à GobState(::do_checks(), notamment) à la place de l'ancien flag "verbose_prints". Les vieux printf avec des coordonnées et des CON_GOTO peuvent donc quitter le code de GameObject.o: ils seront remplacé par des appels au StateInspector (s'il existe) qui peut être défini au niveau de MapTests.