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. 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.