Tuesday, December 12, 2017

branches, reviews and cannelloni

The idea is hanging around. It has been for some times, now. Possibly since I re-started exporting code to e-book readers through Doxygen, or since I tried to use apple assault as a tutorial to libgeds. I'd like to go for some in-depth review of my engine code. I'd like to use powers of code versioning system to slice code into readable, purpose-supported chunks, which would help the reader which components bring what feature and how they interact together.

But now, I started it. I've got a "bare minimum" DS application with corresponding library code (mine or 3rd-party), and its build system.
[done] found the source of Noda's EFs tool again.
[todo] have it built as part of the dsgametools host-tools binaries, bui


Sunday, December 03, 2017

Far ground

Je tente d'intégrer mes bouquins-totems comme décor de fond du niveau vertical ... après quelques essais/erreurs pour faire le bon montage, qui ne consomme pas trop de mémoire vidéo, quelques corrections pour que le moteur de jeu puisse utiliser effectivement les 256KB dont il dispose plutôt que de s'auto-brider à 128K, je commence à avoir quelque chose...

Enfin presque. L'état du code pour la gestion du décor en parallaxe n'est franchement pas terrible
  • le code qui effectue le chargement de l'image ne supportait que la taille de 512x256 pixels alors que je veux maintenant utiliser le système en 256x512.
  • le code de scrolling utilise directement les coordonnées de la "caméra" en les divisant par deux, de sorte qu'il me décale le décor de 64 pixels sur la droite
  • on dirait que seul un des deux "écrans" est utilisé, en boucle, plutôt que d'avoir un décor deux fois plus haut que large ... à l'exception de certains endroits où le décors est sans dessus dessous.
Il va y avoir un peu de travail pour corriger tout ça.

edit: je devrais essayer de mettre un auto-scrolleur sur le plan de décor, tiens... ça simplifierait les tests.
  • en effet, ça simplifie. Et le coup des décors sans dessus-dessous vient probablement du fait que je ne chargeait que la moitié de ma map (eh oui, il faut 2 bytes par pavé, pas un seul)
  • par contre il y a clairement quelque-chose qui annule l'effet du réglage "32x64". 
  • Et pourquoi ai-je un VBL handler appelé deux fois, pour deux maps différentes, et qui modifient les registres des deux plans ? 

cando grow?

Not so easy to fix the state machine bug about Bilou entering ceiling And that is mostly because it is not in the state machine itself. It happens because Bilou has two sizes, and the "HIT" state is one where he is big. Since"HIT" is a state that you can reach from almost any other state, we can't really "fix" the problem by conditional transition.

So I took my code back and started looking around the call to CompoundGob::setbbox() for inspiration.
1. the "grow'shrink." mechanism can be nicely separated along axes. I shall try it on the vertical axis alone so far.

2. I should use cando() function to detect potential issues with virtual movements before I actually change the size. That should be much easier to have something where we check whether we could move up by dy (actually grow upwards) and align coordinates if we can't.

3 . That will work for small resizing, and .can be extended to duck/stand for.human-sized characters  with a simpe - iteration. I haven't tested that, because all shrink/grow changes in Bilou change size by a mere few pixels. And I presume it wouldn't be completely satisfying for something like granting mushrooms for Super Mario. For one thing, the code assume that it is possible to grow. It won't catch the situation where small Mario would get a mushroom in a narrow corridor of bricks.

It took quite some sketching to find the right adjustments and avoid ending up with tons of tests to find all corner cases, but instead do the right computations, taking advantage of the fact that some terms are just zero in some cases. I think I might even no longer need hints about which side we should align against, but I prefer keeping them at the moment, until I get the proof that they indeed turned useless.

Saturday, December 02, 2017

spriteram vs . Resource

Using InspectorWidget to understand buggy situations has become abnormally hard. Just look at the picture we got earlier this season. Compare that to what it used to look like. I've got the "boxes" area all messed up. Of course: in School Rush I now have two things trying to use the sprites of the bottom screen: Inspector Widget and the HUD.

I needed to change a bit the code for the HUD (which uses a SpriteRam to load hud.spr) so that it tells the GUI engine that it used some resources, which are thus no longer available to the InspectorWidget... and let the Engine give some other tiles to Inspector Widget.

One thing I had overlooked is that I devoted up to 256KB of VRAM to background tiles on the main screen, leaving only 16KB for HUD sprites. At 256 bytes per 16x16 block, that means I can have at most 64 different blocks at all. I have 20 different sprites used, 44 left.

Inspector Widget uses 1 such block for "box-borders" (with 4 different flips), and then it has 4 areas-reporting sprites (made of 64x64, 16-color sprites that get scaled up and down to match the effective area shape). That's 32 "tiles" count each for the engine, or 8 of the "blocks" I've used above. So with proper values, I can get it right.

Monday, November 27, 2017

MMU9 write32 to undefined register 04001058h

While working on a solution to get-into-walls bug, I had a ugly alignment bug to fix. I have many debugging tool, but none was really helpful (once again), partly due to my lovely HUD that now takes the bottom of the screen...

InspectorWidget est en vacances,
iprintf en arrêt maladie,
ddd fait la grève du code optimisé,
Qui reste-t'il pour sauver la journée ?
Qui, sinon 0xbadb07 !

Ouaip, y'a une adresse-mémoire qui provoque un message sur le terminal quand l'émulateur la rencontre, avec la valeur posant problème, et même l'emplacement dans le programme. Alors j'ai rajouté comme un malpropre des accès direct à cette adresse pour envoyer un diagnostic d'erreur à travers le subespace de l'émulateur.
Du coup, je peux corriger mon code. Ciao.

And then i've seen that error message from desmume while launching the system: something in the boot code tries to write at some place where NDS documentation doesn't claim any register. A non-fatal condition. But that means I have a way to export a series of values as the program is running. Crude debugging, non-portable and likely to be broken at the next desmume update, but debugging nonetheless.

The fix is thus made. I can commit and go to the bathroom ^_^

Saturday, November 18, 2017

power-button bug

On the game design axis, I am quite satisfied with the final level of school Rush and how it integrates with the earlier levels. It took A. (from the S-Team) Some 30 attempts to beat it, but she hasn't turned mad or bored, and even enjoyed being wrapped to level 1 afterwards.

On the technical side, my latest personal tests hit me with a bug I thought I fixed long time ago: getting stuck in a ceiling, There are few places where this can happen in the game, but if it happens, you will remain stuck, possibly forever unless you use the power button to trash all your progress and reboot. Would a player feel like starting the game again in such conditions? I don't think so.
The thing is, the basis pretty hard to track, a bit tedious to reproduce and all my attempts to fix it have failed ... so far.

What I truly need is a tool that will allow me to identify the sequence of state transitions that led to the offending state when I finally manage to reproduce it. Another debugging tool that would complement Inspector widget for cases that cannot be solved by single-stepping on setting breakpoints.

edit: let's stop rambling, let's start cracking ...

Bug is tedious to reproduce

Then let's make it easier to reproduce. Let's have e.g. a build of the game with much more lives, more hitpoints if needed, that drop you in a place where it is easy to try reproducing the bug. Let's go to that level with the DS, too, and try to get into the wall in as many ways as possible (runMe is neat for that because it let me launch any level), to get a better understanding of the conditions that make it happen.

Moreover, we're running on an emulator, here. And emulator typically have a free save-state mechanism. I'm unsure whether it works flawlessly with desmume, but it's worth giving it a try.

Bug is hard to track

Then let's make our best to get as much information as we can from a succesful run.

Granted, the ideal would be to have a curve plotted, annotated with state changes, in readable colors and where I could get any set of gob variable at any time by just pointing at a spot on the curve. But we don't have that. Granted, last time I had to use both ddd breakpoints and Inspector widget, but that doesn't mean I cannot do better this time.

So the ideal would be a time machine that let me replay things if I ever manage to produce the bug, and view what happened in slow motion, eh ? Wait ... that tool exists already. That tool is ... recording game + Inspector widget as an animation and replaying it!

Bug couldn't be fixed so far.

I thought I knew what happened by looking at the code that makes Verso bounce, because I know I had to fix the problem for Verso (the bouncing eraser). And the solution was to detect the impact's vertical speed to tell ceilings apart from floors, and prevent the 'fail [assuming on the ground]' from happening when what really happened was 'fail [on the ceiling]'.

So after I located something similar with the "HIT" state of Bilou, I thought I got rid of the problem. But since I don't have well-isolated test cases for the state machine (yet), seeing the bug again doesn't mean that the fix wasn't effective: simply that it might not be an isolated case.

To be continued ...

Friday, November 17, 2017

most vexing (gobscript) parse

My scripting language is far from perfect, but this one is really the most vexing issue I have encountered so far. I mean, it is hard to debug, counter-intuitive, and it feels more like a question block turned into a thWomp and smashed you. It gave no clue, no warning, you did nothing wrong, but still get smashed.

The core of the issue lies in how collisions are handled:

  • There is always an active "collider" and a passive "collided" object. 
  • collider area is allowed to expand to any size (within int size limits). 
  • collided area will only be checked if the object's boundary box intersected with the active area.

The third constraint comes from performances considerations. But unfortunately, it means if you create a passive area larger than the object's own size, nothing will complain, you will see boxes intersecting, bar no collision will ever occur.

I'll need to take some time to add warnings

Tuesday, November 14, 2017

Qui est volontaire ?

Je voudrais pouvoir faire une série "tutorielle" pour introduire progressivement les concepts de mon moteur de jeu et fournir une base de travail à d'éventuels game-makers amateurs qui voudraient s'essayer sur DS. Je voudrais aussi qu'ils puissent avoir quelques graphismes de référence, y compris les personnages.

ç'aurait pu être la bestiole de Pipemare (RSD), mais j'ai du mal à me l'approprier. ça ne peut pas être Jack Boost, Badman, Spector, parce qu'ils ne m'appartiennent pas en tant que personnage. Je n'ai pas envie que ce soit Bouli ou Biokid parce que j'y suis trop attaché, alors qui ?

For ten years now, I've been developing a game engine for the Nintendo DS. It isn't perfect but it already allows to do interesting things. And while most of the homebrew we've seen in the golden era of NDS development were using static screen, with GEDS, we have the full power of large maps and parallax scrolling.

Yet so far, I have failed to offer a workable starter kit for the libgeds and dsgametools. Apple Assault source code is mostly obsolete. Discovery packs for LEDS and AnimEDS weren't really helping to kick into game development. And my tilesets are too complicated for a 8-years-old to start sketching levels.

I'd like to take some time to craft something better. A small tileset inspired by Kenneth Fejer mockups. A generic-enough-but-yet-inspiring character that could be sent onto a Commander Keen / Nicky Boom-like adventure.

J'ai envisagé de commencer par un exemple basé sur Out'm'Up, SeaFox ou Crazy Brix, mais aucun n'est vraiment pratique pour montrer ce dont le moteur GEDS est capable (scrolling multi-niveaux, animation modulaire, etc). Non, il me faut une aventure à la Nicky Boom ou Commander Keen.

Reste les personnages secondaires que j'ai développés. Nono le gamin malchanceux (une version anonymisée de Badman, en sorte), Mo le sorcier maladroit, Mol la taupe punk ou Mike Boost, le talentueux mais ténébreux. Ou alors affubler spector d'une tête de souris ?

Rien de complètement convaincant. Reste la possibilité de faire des pixels sur mesure. Voici donc "power kid", qui a l'avantage d'être un perso rigolo.

Of course, given the amount of games I have contributed to together with other PPP Team members, it may sound weird that I'm on a quest for a character to drop to the public domain. The thing is, most of them were designed by other members (Badman, Jack Boost, Biokid) or collectively... or were pastiche of copyrighted characters (Calimero, Xeen, Frogger). My best candidate would be the punk mole I inserted in Badman II and who was playable in my brother's "4 to save Toon Land", althoug -- as you can see from the sketches -- it is definitely not the only option.

Wednesday, November 01, 2017

Rendez-vous avec la S-Team

Ah. Enfin l'occasion de faire tester mon niveau vertical à la S-Team au grand complet! Et de plus entouré de p'tits n'veux de 8-10 ans qui ont fini par venir s'agglutiner autour de L (la benjamine) tandis qu'elle s'entrainait à aller le plus haut possible dans le niveau final. Les ainés auront eu du mérite puisqu'ils se sont accrochés pour aller jusqu'à la dernière section (rouge) malgré un kolossal bug qui permettait aux pendats de laminer Bilou en un seul contact, faisant fi de ses 5 points de vie ...

A défaut de la photo de famille, donc, un petit aperçu des différentes sections du niveau en question. Mon frangin, hier, avait réussi à frôler le dernier écran et approuvé la difficulté avec la mention "vache, mais pas trop". (il avait atteint le haut de la zone jaune et je l'y ai ré-emmené pour qu'il voit la fin)

Un playtesting bien utile puisqu'il m'a permis d'identifier quelques coins piégeux de la map: images qui font penser qu'il y a une plate-forme alors qu'il n'y a rien, voie à suivre peu claire qui a conduit A (la cadette) à se lancer dans l'encre à plus d'une reprise, trop confiante de la distance que Bilou pourrait parcourir en un saut sans se douter que le bon chemin était en réalité derrière elle. Après 3 ou 4 essais, elle parvient au passage critique "des gommes" (zone jaune) où il faut enchaîner les rebonds avec très peu de "filet". Heureusement, en général, à ce stade-là, on a pris suffisamment d'avance sur l'encre pour pouvoir réessayer quelques fois. Et à mon grand soulagement, elle a passé ça en une seule vie. Ni elle ni L n'aura eu de difficulté avec le duo d'éponges de la section orange (re-ouf).

I got the opportunity to have the final level of School Rush heavily play-tested (at last) and got many small things (and other-not-so-small) fixed. It is always a pleasure to see kids and teenagers challenging each other on my game. I'm impressed they kept doing their best despite I had an awful bug that allowed pendats to one-shot the player almost everytime. Nonetheless, the best trained of the testers managed to climb almost to 3/4th of the final level, beating the "bouncing erasers climbing" part at her first attempt.

Thanks to those playtest, I had fixed some phantom platforms here and there, ensured idle inkjets (those that don't shoot by default, as on the title screen) always notice you when you jump into them, allowed to swim-up to escape the ink even when you don't end up in the final depth of the ink, got the "torchlight feature" rendering correctly ... And before you ask, yes, I took the week off ;-)

Même N. s'y sera réessayé, alors qu'il avait plutôt snobbé Bilou au profit de ses jeux sur smartphone ces dernières années (bah, il a genre 17 ans, l'ainé, maintenant). Un cycle de 3 vies lui aura été nécessaire pour reprendre un peu le jeu en main, mais après ça, il atteignait sans problème la zone verte avec 2 power-up mais n'aura pas poussé jusqu'au jaune, L. insistant pour faire un nouvel essai.

Par contre,

Monday, October 30, 2017

.fr ?

Bon, je ne vais pas y aller par quatre chemins: animer ce blog en bilingue devient trop lourd pour moi. Entre le boulot qui me tient beaucoup plus devant un écran, les trajets en tous ssens pour les activités extra-scolaires des loustics, et -- avouons-le -- un laptop moins convaincant dont l'écran n'a jamais la taille qu'il faudrait, je peine déjà à rédiger ce qui me passe en tête quand je gribouille une page de notes sur ma tablette-liseuse-scanneuse.

Alors le faire en deux langues, ça devient vraiment infernal. C'est aussi au détriment du projet lui-même. En théorie, la France arrive toujours en n°2 dans les statistiques. Ai-je encore des lecteurs francophones ? (ai-je encore des lecteurs tout court ?)

N'hésitez pas à vous faire entendre: le sondage "English /Français" court toujours.

Panic! GameInfo reading out of buffer!

Pretty weird error message. I don't know what triggers that. It doesn't interrupt the emulated program but kills the emulator itself, even when we're running in gdb-debugging mode. It happens while parsing some line of text in my "wave.cmd" script unless I invoke GobAnim::setWindowed() on an animation earlier on. The object parsed when the crash occurs has no relationship with the GobAnim that gets windowing-enabled.
  • Panic! GameInfo reading 302251 out of ROM (302254)
  • halting emu: ARM9 PC=020406A0/02000F0B, LR=0204069C 
  • ARM9 halted 
  • halting emu: ARM7 PC=037F9B84/037F9B7C 
  • ARM7 halte
The crashing address happens to be within memcpy.

  break *0x20406a0 if $r3 + $r0 > 0x300000 && $r0 < 0xb000000

could be working, except that GameInfo doesn't start at offset 0, but apparently rather at offset 0x08000000.

A bit more digging (setting the right breakpoint, using one more desmume patch to reveal registers R0 through R3) finally allowed me to get a stack trace....
And the offending memcpy was part of a buffer refill for waves.cmd file. For some reason, by incrementing the size, I hit a threshold where one more copy is needed, but then the very last bytes can't be read because the emulator believe they should always pick a 4 bytes from the current position (instead of an aligned 32-bit word holding the byte). Simply adding a zz.zz file that will come past the waves.cmd file make the code work again.

Tuesday, October 24, 2017

Finishing steps for School Rush

  • [true] ensure the music track for the last level is different
  • bring in the amazing books as the background for the final level
  • make a funny "true ending" sequence
  • [done] draw something for the missing loading screen(s?)
  • [done] inkjets start aggressive in hard mode
  • [wish?] page-swap bonuses as player progress into the levels to m4ke him b3liv3 th3 m4th 4r3 t4king 0v3r th3 w0r1d (originally mentioned here)
  • [done] resume the normal level order/spawn points.
And I still don't have vertical movement for floating spongebop.

Yup. No code tonight. Just took some time to crawl through the old "todo" posts and collect a list of things that are still pending. As I can allow less and less time at once on my hobby project these days, I need to organize myself more ...

To be honest, I'm starting to be attracted more and more by things that aren't related to School Rush and less and less by finishing School Rush itself. Possibly because we're approaching a big release at work ... possibly because the Internet seems not to care a lot about the idea of rushing School Rush.

I wanted to temporarily disable the "window" feature on the torch-light GOB (just to check it has the shape it should), but when I do so, I get a cryptic "Panic! GameInfo reading out of buffer!" message from desmume... I'll have to investigate that.

  • [done] With the window disabled, it looks like the OAM flipping isn't working for my torchlight-sprite. I'll have to understand why
  • [done] While hacking the get-ready-to-swim fix, it looks like I broke a rule in the Bilou-got-hurt rules, allowing pendats (which are both hurting and solid) to combo-kill you

Monday, October 23, 2017


The inscene'99 visit had been quite as success, especially regading the 100K game competition. My brother and I then tried to figure out what we would do on the next instance - obviously, our chance of making a good game were higher than making a big demo like the one envisioned for "samedi, tous in my home".

A comment by my peer "Gedeon" about how it was a shame that crazy brix was only using boxes for collisions pushed me towards the implementation of some pixel-perfect collision routines. I remember I wanted to do some pinball game, but after all, it was decided to go for a shoot-em-up. Our secret "games to do" folder had a long list aborted shmups, from the "Polycosmos" conversion of "space Mission", the failed "cosmowars" on RSD Game-Maker, and the aborted "Bilou sky quest" ... Nothing getting any close to our childhood golden award "Warhawk". So I picked the "Tyrian" palette and started to pixel some ships.

The assembly code for crazy Brix was quite horrible, and I remember taking care of increasing the quality of the organisation for out'm'up. Especially, frames-to-aminations, level layout, and to some extent the sprites behaviour were described in a "data-oriented" macros system that looked a bit like game script, but converted straight into binary pointers and values -- something that was apparently common in MegaDrive games development.

The second key development was to support a dynamic list of sprites, allowing fancy explosions, lots of shots and even powerups where crazybrix couldn't even accomodate for anything but a ball and a paddle. Two lists, in fact. This engine was the first time I decided to split objects in two separate casts to reduce the amount of collision checks required.

While the level design wasn't very inspired, the game received a brilliant soundtrack, a classic but good-looking starfield effect and Out'm'Up won the first place - although mostly due to the lack of significant competition.

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. 

Wednesday, September 06, 2017

Sketching on Boox

La première prise en main de l'application "prise de notes" de mon nouvel Onyx Boox n'avait pas franchement été convainquante... arrêter son traît au bon endroit, viser un emplacement avec le stylet ... tout ça est plus complexe que ça ne le devrait. La faute à mon avis à l'absence de compensation de l'inclinaison du stylet.

Starting to draw with my "Boox" was a bit disappointing. Whatever I could try with stylus calibration, there was still a significant offset between the contact point of the stylus tip and the actual drawing point. I bet better tilting support in the software (or hardware?) would have avoided that, but that's not something I can improve. Hard to stop at the right place on a rectangle's corner. Harder to make a circle (or whatever else) at a precise spot ... and almost impossible to make an arrow >_<

Du coup, quoi qu'on fasse avec la fonction "calibrage", le point de contact du stylet avec la surface et le point où l'encre change de couleur ne coïncide pas.

Difficile du coup de faire de beaux rectangles ou  (encore plus ennuyeux) des flèches. Difficile aussi de dessiner des p'tits Bilous dans le coin d'une explication. Ou de faire du dessin type "ligne claire".

I usually love to have small Bilou / Bouli talking and illustrating a technical chat... That will be difficult to do here. It usually requires to draw at small scale, a single line, Tintin-style. And that works terribly bad with the imprecisions of the Boox "Notes" application. 
But hopefully, lining up multiple lines and writing works naturally well. 

The good news, however, is that if I'm just sketching at a scale of 5-7 cm, striking over again and again to make the lines more defined gives some quite interesting results. Not really suitable for artwork either, but creating quite acceptable sketches.

Par contre, le style "repasser sur les lignes, plus nerveux, plus "esquisse" ne donne pas trop mal.

edit: for those who're curious about it, Onyx documents its scrible interface on github.

Friday, September 01, 2017

I got a Boox

J'ai reçu mon nouveau gadget à base d'encre électronique, donc. Même si au prix où il était, j'espère qu'il sera plus proche d'un ordi que d'un gadget, évidemment. Il s'agit d'un Onyx Boox 9.6" combinant un stylet magnétique et un écran capacitif.

I jumped completely out of my comfort zone and ordered online a device I never had in hands before at a price well over that of a Nintendo DS: the Onyx Boox N96, combining magnetic stylus (afaik), capacitive screen and e-ink display for roughly the size of a A5 sketchpad.

Malgré une boîte tout-en-chinois un peu intimidante, l'appareil a des menus en bon Anglais et la prise en main s'est faite assez facilement. Ma grande inquiétude, évidemment, c'était de savoir si je pourrai m'en servir pour mes documents "doxygen" si utile pour faire du développement intermittent.

The device feels right in hand, is quite a hybrid between an androïd tablet (unfortunately only 4.0, making applications for twitter, picasa and blogger unusable >_<), but what was really stressing me was to know whether I could use it for epub+doxygen code browsing I've been usiing sooo much for the last years to progress on my pet projects. And unfortunately, out of the 4 embedded readers, none of them got the layout right. No indentation, useless line numbers, incoherent spacing ... all of the issues I had fixed earlier this summer -- and some I never heard of before -- were back to haunt me.

Ce n'est pas gagné: sur les quatre lecteurs e-pubs embarqué, aucun n'a un système "styles de l'éditeur" comme mon regretté Cybook. Et sur chacun d'eux, le code produit a tous les défauts d'une mauvaise conversion: pas d'indentation, numéro de ligne inutiles, tailles incohérentes, etc.

J'avais compté sur l'installation de FBReader, testé avec succès sur la tablette de ma fée, mais c'était compter sans une dernière roublardise d'androïd: Il y a en réalité une version plus ancienne de FBReader dans le pack d'applications préinstallées, ce qui m'empèche d'installer une version plus récente pour cause d'erreur -104. (j'aurai peut-être plus de chances après une recompilation ?)

My plan was to use the open-source FBReader if such thing occured, but unfortunately, I couldn't install it from Google Play: interference between the pre-installed FBReader (older version) in the firmware makes it fail with error -104.

I was hesitating between sending it back and switching to some pure html-based doxygen crawling when a post in one of my blog-on-epub conversion caught my attention.

Bref, je m'apprétais à devoir me rabattre sur une utilisation de pages webs moins pratiques (pas d'annotations, pas de marqueur 'vous êtes ici' d'une lecture à l'autre, etc.) lorsqu'au détour d'un post de ce blog converti en fichier e-pub, je constate que l'un des lecteurs par défaut (je ne me souviens pas duquel il s'agit :P) que les styles sont tout à fais satisfaisants pour mes besoins:
  • le bloc de code est en police monospace alors que le texte du post est en police classique,
  • les indentations ont fonctionné correctement,
  • (bin y'a pas denuméro de ligne, forcément, vu que je n'en ai pas mis. Haha.)
Le jeu, ça va être maintenant de comprendre la différence entre ce bloc-là et ce que j'avais dans mon document doxygen pour faire des doxygens qui marchent mieux.

See ? It's all there. Indentation, font switching... The CSS reading is there. The rendering works. It's all a matter of making the doxygen stuff damn simple enough so that it couldn't possibly fail. That's something I can handle. The boox may stay here.

Wednesday, August 30, 2017

mayfreeze = false

Voilà: le niveau vertical est pour ainsi dire fini. Du moins pour ce qui est des décors. Maintenant, je vais devoir passer un peu de temps à faire les réglages pour l'encre-qui-monte. La bonne nouvelle, c'est que la technique qui évite que l'encre s'arrête de monter quand elle sort de l'écran est déjà opérationnelle depuis Juillet.

It's now time to make sure the vertical level get rising ink, too. And this time, I need to take extra care that the objects that control the ink level will never got "frozen" when going too far away from the camera. That was hopefully available since early July.

Un peu plus délicat: s'assurer que Bilou se "noie" toujours dans l'encre malgré le fait qu'il puisse parfois tomber de plusieurs écrans avant d'être arrêté (et la zone de collision de l'encre ne va pas jusque là).

Another thing that I'll have to take care of, is that Bilou don't go too deep into the ink. Without it, we can quite easily have Bilou fall down so low that he'll go out of the "hit player" box ... and player will have to find some other way to hurt himself (while seeing nothing but a black screen) to be granted another attempt.

Je vais devoir ajuster un peu les encriers -- et en particulier éviter que Bilou ne soit totalement à l'abri à l'intérieur d'un encrier -- faute de quoi il pourrait très bien y rester bloqué indéfiniment. Et enfin, il faudra trouver la bonne vitesse pour la montée de l'encre, parce que là, j'arrive en haut du niveau avec 6 bonnes minutes d'avance. De préférence sans trop "tricher".

One last thing: I cannot keep the rule that "being within an inkjet = being immune to ink" as with the 4 previous levels, because then you'll be stuck in your inkjet forever.

And then, I'll need some tuning on the ink speed itself. Right now (60*32/256px/sec), I can climb up the level and I'd have to wait for over 6 minutes before the ink can catch me back.

If I let the ink almost reach me when I'm about to go through the last "room", though, I'm only some 40 seconds ahead at the top -- which is still quite a lot.

Saturday, August 26, 2017

School Rush sur Press Start

Difficulté très bien rodée, dit Space-Cowboy de Press-start. La présentation est un peu plus formelle que celle de Pirez, mais tout à fait sympathique.On va un petit peu plus loin dans le jeu, aussi. Mon regret sera que notre cow-boy a fait sa vidéo sur la version de l'an dernier et ne nous montre donc pas les nouvelles animations sur lesquelles j'ai travaillé l'an dernier.

School Rush continue lentement sa progression parmi les internautes. J'espère un jour pouvoir atteindre la rédaction de Pix'n'Love, mais leur forum reste curieusement verouillé...

I'm still hoping to get in touch with some English-speaking youtuber who would love to play-test School Rush. I'll definitely have to try a bit harder with the next release

Monday, August 21, 2017

End of Cybook ?

After about 5 years of helpful operation, my e-ink device "cybook odyssey" seems to be definitely damaged. I cannot do more than a few minutes of reading before getting the system to reset. Sometimes even just clicking a link or trying to change the font size will jam the device. I tried a factory settings restore, but that only help for a few minutes.

And now the "gadget" class of the device really shows up. I have no logs that could point out the flaw, no way to access the critical components (namely the internal flash). The device as a whole will have to be recycled just because one component is weared out.

Mon Cybook me lache à nouveau. Trois ans après son passage en service-après-vente, mais sans espoir d'intervention de garantie, cette fois-ci. Me le réparerait-on de nouveau ? Peut-être. Est-ce que j'ai envie d'injecter encore de l'énergie dans un appareil que je ne peux empêcher de vieillir ? Pas franchement. Est-ce qu'il y a mieux à acheter ? Peut-être si je suis prêt à lâcher 300€ pour un modèle Androïd-à-encre-électronique.

So what ? Shall I replace it with another one, with slightly increased screen resolution, take advantage that I know the beast, including the annoying amount of time it takes to accurately select a phrase to highlight it (and risk having issues with memory again within a few years) ? Shall I pay up to 3 times the price for a device with stylus, android (including the ability to program my own tools on it), bluetooth, but unfortunately not the version of Android required to run the infamous "inkspace" application required for my bamboo spark ?

There is even 13" models, but they seem to be sold near 700$, not the 400$ I spot on alibaba. The same company makes 9" devices too, claimed to be half the price (which gets into the "expensive but affordable" category). Maybe I should wait for a few weeks and see whether that "ReMarkable" thing actually ships this august and at what price ?

None of these could be found in stores so far, but I had a look at a Kobo Aura One this afternoon, and it was quite sexy, with its all-flat front side. No stylus and no android (afaik), though.

Saturday, August 19, 2017

Les autres pentes

Du point de vue du moteur de jeu, un niveau est avant tout une grille dont chaque case reçoit des propriétés: solide, solide uniquement quand on tombe, pente, spécial, etc.

(note to English reader: the handwritten text on the pictures is part of the post's text this time).

... A grid, with tiles telling "solid" or "sloped", or "jump through, but don't fall". And sometimes just "special block".

Les "blocs spéciaux" ne sont pas compris par le moteur de jeu lui-même (d'où leur caractère "spécial") mais décrits dans les scripts qui définissent les règles du jeu.

Ainsi, quand Bilou touche par exemple un Bonus, le moteur de jeu récupère quelques bits d'information pour chaque pavé (8x8) de la grille constituant le bloc (16x16) et reconstruit un numéro de bloc spécial (de 0 à 255) qui permettra de retrouver les instructions à exécuter (faire un son, déclencher une animation, donner des points, etc.)

... each "special block" tile provide two bits that are combined to define the "block number" used to retrieve collision properties, hit box and script expression that makes a bonus play a sound and spikes hurt Bilou. The game engine itself, to some extent, doesn't know anything about the special blocks except how to delegate block/object collisions to the appropriate script sections.

Quand Bilou touche une pente, en revanche, le moteur de jeu sait qu'il doit aller regarder une petite table indiquant la hauteur de chaque pixel de la pente. A priori, la forme de cette pente pourrait être n'importe quoi. Mon éditeur de niveau connaît les pentes à 45° et à 22.5°

The height array tells how high is each pixel in the tile. The game engine knows very well what to do, this time. Some tuning could provide an alternate height array to support a different kind of slope, but I haven't used that so far in the game.

Mais voilà: j'aimerais pouvoir avoir plus de souplesse: des escaliers, des coudes, par exemple. Un petit schéma de rien du tout qui traîne depuis des années (2010?) sur un bloc de brouillon en atteste.
"Le mieux serait d'avoir deux boutons 'pente' [dans l'éditeur de sprites] qui forcent le remplissage d'une ligne de 64x16 pixels avec des pentes suivies (les modèles)"
 ajoute encore le calepin.

That "sprite editor / stripe of sloped tiles" approach hangs around in draft mode for years. Because each tile has a unique address in video memory, I had plan to use that address to extend "advanced slope-to-the-right" into "start-of-slope, 0° to 22°". The issue is that the Sprite Editor has no real control of which blocks goes where in memory. Just filling a row of the tile sheet with slope patterns doesn't guarantee that the corresponding tiles will all receive consecutive (and not even aligned either) numbers in the tile set. The solution was in realising that the Level Editor is the component that should solve the more-slope-types problem.

En effet, la technique que j'envisageais alors consistait à utiliser comme information supplémentaire la position du graphisme au sein d'une ligne de blocs dans l'éditeur de niveau (une "tranche" de 16 pavés de 8x8 successifs). On pourra alors convertir l'information de la grille "pente compliquée vers la droite" en "transition douce de 0° à 22°" parce qu'on est dans le 6eme pavé sur une tranche de 16.

Sur les dernières années, ça n'a jamais été mis en service et mes derniers tours d'horizon dans le code de l'éditeur de Sprites me confirme que travailler "par tranche de 16 pavés" serait un vrai casse-tête (le mode et le moment de l'allocation des pavés dans la mémoire vidéo n'étant absolument pas prévu pour ça).

Et cet été vient une idée qui jette un autre éclairage sur ce problème: "Les pentes douces, c'est un problème pour l'éditeur de niveaux. Ce n'est pas quelque-chose à régler dans l'éditeur graphique.

Et l'éditeur de niveau sait par contre traiter des groupes de chiffres pour montrer qu'un bloc spécial est soit un bonus, soit des pics, etc. En prenant donc un type de pavé qui dit "pente compliquée, regardez les chiffres en-dessous pour en savoir plus", je peux diriger le moteur de jeu vers une autre table de hauteurs qui définit la pente (parmi 16 pentes possibles), mais aussi éventuellement fixer le coefficient de friction (sol dur, glissant, boue-qui-ralentit, etc.)

"Special Slope" type merges the behaviour of "sloped tile" and "special block": it will have less bits available to encode the type of slope (e.g. "only" 16 possible slopes), it will require collaboration of multiple tiles, but instead of creating a BlockArea and trying to match collisions, it will just provide an alternate height arrays.

Il me tarde d'essayer ça ^_^