Saturday, October 21, 2017

drop your weapons

One of the most vexing gameplay bug I can think of in School Rush is that you can't enter inkjets when carrying a dumblador. That can easily lead to moments of panic for most reactive players and frustrating death for others.

I now have it fixed, by dropping the requirement of NO_WEAPON when entering inkjets, adding a "THROW" test area when being in the inkjet and ensuring that we DROP_WEAPON if this area ever gets triggered.

What took me a bit too much time to figure out is that the impulse to drop an inkjet must be define as you enter the state with a F_THROW test area, and not on the found-matching-object transition expression (likely because the blador-side of the expression evaluation happens before the bilou-side expression).

Wednesday, October 04, 2017

OBJ-WINDOW: Look through the ink

The DS video is made of multiple layers -- this should be no news for you. One of the video registers define which of these layers should be shown on screen, but that register also enables and disable a more obscure feature of the NDS: the windows -- that is, the ability to define multiple regions on screen and give them different set of layers to be shown. When the ink raise in School Rush, I'm not simply painting black squares over the scenery: I actually reduce the window through which the scenery can be seen (with a setup where nothing at all can be seen out of that window).

Petit tour d'horizon dans le document "gbatek" pour voir comment fonctionnent les sprites/fenêtres, une petite particularité de la console DS qui permet de basculer entre deux réglages de visibilité des différentes couches graphiques du jeu. Jusque là, je l'utilisais d'une manière assez simpliste pour dessiner l'encre ou les "rideaux" qui ferment la scène à la fin d'un niveau.

Un simple rectangle dans ce cas-là, qui permet de voir toutes les couches à l'intérieur de la fenêtre et aucune à l'extérieur.

The use I have so far of the "window" feature is pretty basic, but a recent talk with Adrian (GBA developer) made me realise that it would be just perfect to allow the game to give us a hint on where Bilou is when he's swimming up the ink to safety. The trick is that some sprites can be used to create another kind of window. Rather than being rectangular, it can have any shape ... and will be much easier to use than reprogramming the size of the window as we get horizontal interrupts amiga-style.

Pour que l'on puisse voir Bilou nager dans l'encre, il me faudrait donc une deuxième configuration qui laisse voir une partie du niveau tout en gardant assez de noir. Il devrait suffire pour ça de changer un simple bit dans la configuration.

J'hésite un peu quand à la manière d'implémenter ça ... Plus précisément, sur la manière d'indiquer depuis les scripts du jeu que l'on souhaite passer un certain sprite dans le mode "fenêtre". L'idéal serait probablement que l'information soit retenue dans les animations elles-même, mais sans nécessiter de modification de AnimEDS.

En même temps, l'utilisation d'AnimEDS n'est nécessaire que si j'essaie de micro-optimiser et d'éviter un sprite 32x32.

There are a few implementation details I'd like to sort out before implementing that. I already figured out that it should be under the responsibility of *Gob + GobAnim classes, the *Gob being the only class that can manipulate OAM entries (including the OBJ_WINDOW_MODE bits) and GobAnim being a natural place to setup flags indicating that "this appearance of the sprite should be a window (or alpha-blended, or rotated)". I might give it a try with a single 32x32 sprite and dedicated "flags xxx" script entry before I go for something more integrated that could replace the Flicker command currently in use by e.g. inkjets... 

edit: got it working. (by Oct. 14th) Some pixels to edit, now.

Monday, October 02, 2017

Thanks, ::Twig

On y est presque. Un mois après l'arrivée du Boox comme remplaçant du Cybook, j'ai réussi à faire un petit script Perl convertissant la sortie de Doxygen pour que le e-pub reader le plus puissant de l'appareil (point de vue navigation) parvienne à afficher correctement les extraits de code. Et ce grâce à l'aide d'un petit module plutôt bien foutu -- XML::Twig -- permettant d'écrire dès règles du style "si tu rencontres
<div class="line">...</div>, remplace par <tt>...</tt>".

Yo! One month later, I finally have a nice Perl script for converting stylesheet-heavy doxygen output for the super-navigating (but style-agnostic) reader application embedded on my Boox device.
The XML::Twig package I used for the job seems pretty powerful -- and much easier to use than XmlStylesheetsTransformationLanguage, as far as I am concerned.

I can't help but dreaming about pushing it further and have blog excerpts integrated with code snippets on an enlightening document that would progressively turns the readers into code writers that would contribute to dsgametools ...


Il serait très tentant d'utiliser ça pour faire aussi un peu de fusion blog/doxygen, d'ailleurs. histoire de reprendre les schémas UML dans le code navigable.


Thursday, September 21, 2017

NExt (last?) steps on School Rush

No real "todo item" identified from last week-end' playtesting session, except one funny idea of using a special feature of the NDS' sprite hardware so that we can see Bilou while he's swimming up the ink.

I've got a few other things to do, though. Some editing on the map, some debugging on the inkjets, but mostly, a way to animate what the pipes when Bilou disable them.


Je me suis retrouvé un peu "tout bête" à ne pas avoir de véritable chose à corriger après la petite scéance de playtesting de du week-end dernier. Qu'à celà ne tienne: il y a quelques détails qui restent encore à améliorer sur le dernier niveau, et en particulier faire en sorte de pouvoir animer l'arrêt du flux d'encre quand on rebouche un bouchon. Je pense bien utiliser les polygones: ça fait parfaitement l'affaire. tout ce qu'il me manqu(ait), c'est un bout de code qui dessine un rectangle noir entre deux objets du jeu, et un peu de script pour lier le tout.

So let's go for a new "GobController" that renders some polygons between two objects and don't do anything else. Ideally, the "circular" controller used to swing spongebops could be cleaned of OpenGL instructions and once I'll have a 3D object editor, I'd be able to name which 3D object should be used as the link between any two attached objects. But we're not there yet.

Ce n'est pas franchement le genre de programmation qui fait plaisir: assez bien de copier-coller, pas franchement le bon rôle (c'est un contrôleur, et on fait de l'affichage >_<), etc. Je reviendrai là-dessus quand j'aurai bouclé le jeu et que j'aurai un peu avancé sur mon projet d'éditeur d'objets 3D sur la DS.

Ah oui. Il y a un autre élément qui serait sympa: faire en sorte qu'on puisse voir Bilou nager hors de l'encre. Point de vue technique, j'ai ma petite idée, mais ce n'est franchement pas prioritaire.

edit: good news, if you want an invisible sprite for some reason, you don't have to devote another blank tile for that. Just 'naming' an empty slot of any SpritePage will do. For some reason ... which I'll have to understand ^^"

Tuesday, September 19, 2017

Ink pit : play-tested

J'ai eu l'occasion de faire tester le niveau vertical de "school rush" à L., 11 ans maintenant et qui essaie maintenant occasionnellement les niveaux de Bilou depuis 2009 2013. La fonctionnalité-clé est validée: "j'aime bien qu'on puisse nager pour ressortir de l'encre", affirme-t'elle, alors qu'en pratique, elle n'aura réussi que quelques fois à se tirer du mauvais pas, et généralement si affaiblie (enfin, Bilou, hein. Pas ma testeuse) qu'elle n'ira guère qu'un ou deux écrans plus loin.

Mais l'effet psychologique prend. Elle s'accroche et s'améliore peu à peu, jusqu'à atteindre régulièrement 1/4 du niveau et occasionnellement 1/3. Au-delà, les choses se corsent et il faut régulièrement courir pour franchir les sauts, ce que L. ne maîtrise pas encore véritablement.

Celà dit, comparé au jeune premier, L. a immédiatement senti l'urgence de l'encre qui monte, remarqué qu'il fallait se méfier des encriers endormis et qu'en sautant un petit coup supplémentaire une fois arrivé dedans on les réveillait (oui, c'est un vrai bug que je dois corriger, pas un choix de gameplay douteux), repéré les horizontales dans les les livres et les utiliser comme plate-formes, etc.

Friday, September 15, 2017

Come back from the ink ?

Bon, entre les programmes d'activité des loupiots qui grandissent, les centrales vapeur qui tombent en panne et les interventions de réparation dans la maison, je me prends une petite paire d'heure pour essayer de corriger un couac avec le passage à un niveau vertical dans "School Rush": s'assurer que le jeu relance bien le niveau si l'encre nous rattrape.

Je dois  notamment éviter que Bilou ne puisse rester indéfiniment dans un encrier sous l'encre. Etre invulnérable dans l'encrier, ok, mais pas retomber immédiatement dedans quand il nous projette jusqu'à la fin de la batterie.

It is time to check what the vertical level looks like when we add rising ink in the mix. And the first tests show that there's quite some tuning required. The first mis-steps that my last playtester did led Bilou to be stuck in the ink, invulnerable, but also unable to keep on playing. One of them involved cycling between in-inkjet and hit.

I'm trying to make the state machine detect that we're in the ink and switch to a "swim up" state that would give the player a chance to get out. This is possible because ink has an additional flag that makes it possibly different from a regular hazard. All the engine requires is that the test on "hurts and is ink" precedes the test on just "hurts".


Se faire projeter par l'encrier, c'est "$HJUMP". L'encre, c'est à la fois F_HIT (blesse Bilou) et F_ISINK (fait flotter les éponges). Une réaction "normale" pour le personnage qui tombe dans l'encre serait d'essayer de nager pour en sortir. En particulier s'il atteint quelque-chose qui peut le propulser hors de l'encre. Ce sera "$SWIM", dans lequel on est insensible à l'encre mais qui repasse faire un test périodiquement et continue donc à consommer des points de vie tant qu'on est dans l'encre.

Il faudra aussi que je complète ce "swim" lorsque Bilou arrive hors de l'encre.

Thursday, September 07, 2017

Doxygen on Onyx

I don't exactly know what I have changed, but using the "Neo Reader" application on the Boox today, my doxygen-to-epub-through-calibre file now renders as expected. I thought that could be linked to the disabling of "cache reflow bitmap" cryptic option in the advanced settings (see the small icon pointed by the stylus on the picture), but re-enabling it doesn't change anything (or it only has an effect when restarting the application ?)

Qu'est-ce que j'ai changé ? Je n'en sais plus trop rien. J'ai "torturé" le morceau de code qui apparaissait dans la version e-pub de mon blog pour essayer de trouver ce qui faisait la différence entre un rendu correct (white-space: pre-wrap ? utilisation de
<pre>plutôt que <div>? de <tt> plutôt que <span>?


Rien n'a semblé avoir d'effet. Puis ce midi, en jetant un coup d'oeil à mon code converti par doxygen et calibre, surprise! tout est impecablement rendu.

Plus de numéro de lignes indésirables, changements de polices, traitement correct des espaces ... tout y est.

Est-ce que ça vient du réglage "cache reflow bitmap" que j'avais changé ? difficile à dire. Le désactiver ne semble pas avoir d'effet immédiat, mais ils auraient pu omettre de dire qu'il fallait redémarrer l'application ...

One major drawback, though: Neo Reader application is the only one for which I find no way to hop back to the place I was before following a link in the epub document. And that will make navigation extremely annoying, I'm afraid.
Neo Reader v2.0 had nice backtracking feature, and that one gets interesting behaviour on my test epub document.
  • When using <span> or <div> with the CSS classes associated with working 'code-style' elements, nothing happens
  • When using <pre> or <tt> with the same elements, code is rendered as it should (as printed on dot-matrix ;-)
  • The style applied to "English section" (using <en>) doesn't go italic, while emphasis directly using <i> in the French part goes italic.
  • skipping CSS classes altogether has no impact (given that you're using
    pre/tt tags)
  • embedding the whole stuff in "blockquote" doesn't seem to have much effect
  • trying to use tables with colspan and some cells containing only a few whitespaces failed miserably. I think all cells are just sitting in a vertical list, not laid out on a table at all.