Scorpeye... Enfin!

 Oui, je l'avoue, j'ai été lent. J'ai été distrait (au sens attention détournée). J'ai été démoralisé par cette "carapace" qui ne voulait pas faire demi-tour à chaque fois ou qui faisait des demi-tours intempestifs. J'ai douté, de cet empilement de couches qui devait me permettre de laisser des personnes non éduquées au C++ de bricoler aussi leur propres personnages. Sauf que tout ça, c'est bien joli mais que quand vous avez un dysfonctionnement quelque-part, le débugger vous balance des instructions machines alors que le problème est dans le bytecode qu'elles interprètent. Et mon "inspector widget" (pas encore fonctionnel dans le projet 3 rooms) est loin de valoir ddd.

It's been a long time, I have to admit. I've been slow to get things running; I've had lost the hope that I could get that scorpio-shell turning back when it hits a wall... and only when it hits a wall. It felt like I had built a Jenga stack of complexity in order to have a 'simple' interpreter for state machines. But a language is never less complex than the tools you provide to debug it. And Inspector Widget fell short when trying to explain the issue (partly because it is surprisingly not yet working on Dreams.nds)

Une intuition pendant mes vacances ... j'ai retracé la machine d'état de mon scorpion-cyclope. J'ai bien identifié deux ou trois incohérences, mais rien qui ne conduise au bon comportement une fois corrigé.

Oui, je sais aussi, par rapport à ce que je bricolais sur le côté pendant mes semaines de vacances, c'est maigre. C'était des vacances un peu ... particulières.

Puis hier, j'ai repris la machine d'état de pendat. Lui aussi, il réagit quand il fait demi-tour en se prenant un mur. Et il n'est peut-être pas parfait, mais il marche en général bien mieux que cette satanée carapace.

Alors que scorpeye tentait de reconnaître l'absence de sol à l'aide d'un testpoint, pendat se contentait de "dire" "ah bin si la vitesse horizontale est tombée à zéro, c'est qu'on s'est pris un mur. Sinon, c'est qu'on a plus de sol. C'est forcé."

I found only a small evening of ndsdev during my summer holiday this year, and I used it to map the state machine of Scorpeye. It helped me finding a few weird stuff, but it would not make things run properly enough, unfortunately. Then I realised past Inktober that I already had a 'working' monster that bounced off walls. That was the running pendat. And I started mapping its state machine too (granted, after all these years of dsgametools, I should have given myself a tool to make that automatically). To my surprise, it almost never used the same tricks to perform the same task.

For instance, I used a TestPoint below scorpeye to tell me whether there was ground underneath when it claims it failed to slide on the ground. But this is unreliable because it checks only one point to decide for ground while the WalkController checks the whole surface. Instead, the pendat would test whether it came to a halt horizontally. If it did, that means there has been a wall. Otherwise, it bets there's no ground left.

Same with fall/slide transition: the scorpeye tried to use a testpoint to know whether it FAILed because of a ground. Pendat code author (past self) knew the only thing that can make GobGravityController FAIL was a ground. Being stopped by a wall triggers an event. That means no testpoint validation is required.

Finally, I gave myself an extra variable (there are still plenty available for scorpeye) to remember the sliding speed so that we can bounce walls without having to rely on an ImpactController to save the last speed, because so far I don't think GobWalkerController is an ImpactController. It requires to double some states (like left-thrown vs. right-thrown), but that should not be a big deal.

Still, there's one thing that I'll need to fix with unit testing: from times to times, being stopped by a wall while 'walking' doesn't make the move FAIL, but it does clears the speed. Pendat doesn't suffer for that because it has an "increase horizontal speed" statement in its running states that prevents the speed to stay null. I had to add the same statement to the shell, but it shouldn't be required. that's a todo item for XMAS, I guess.

Il me fallait un double-état pour la carapace lancée, une variable supplémentaire pour retenir la vitesse à la place de la 'variable d'impact'... ce genre de choses. Mais il y a un élément suspect. Pour qu'il n'y ait aucun soucis, je suis obligé de mettre une instruction forçant la carapace à accélérer. Sans ça, il reste des situations dans lesquelles je retrouve ma carapace toujours dans l'état "on glisse vers la droite" mais avec une vitesse nulle est un mur juste à ça droite.

Comme si GobWalkerController avait un bug qui l'empèchait parfois de signaler l'échec (FAIL) même si la vitesse tombe à zéro. ça, ce sera une tâche pour un test unitaire.

Behaviour edition on DS. ?

I'd like to be able to edit state machines (for Bilou and monsters) on the Nintendo DS itself. That'd be the pinnacle of on-the-road game making. There's a significant drawback to address before I can do that, though: usable state machine scripts currently heavily rely on GCC pre-processor to turn into engine-compatible text. Most of it is just providing nicknames for things that the engine solely knows as numerical identifiers.

So I'd need at least a sort of token-parser that can handle some of the substitutions on the DS itself. Both for potential Behavour Editor on DS and for runMe. Only the compiled .nds that embed the game would still use PC-pre-processed scripts (and see only numbers).

I've been toying with that idea summers ago, digitized and kept-as-draft the best part of it for seasons. It's not yet time I start implementing it (I don't think so, at least. It's irrelevant to the 'dreamland' effort), but it may be time I stop being silent about it...

Land on Slope

There are many things that got fixed over my holidays, and many things that remain to be done before I can claim the 3 rooms "done". I had to pick one for the last week-end ... it seemed wise to pick something that I'd likely not have enough focus to work on during the evenings of a regular week. "Land on slopes" seemed the right one to pick.

So far, only the "walk" (behaviour) controller is aware of slopes. For the rest of the code, the world is all made of square tiles, and the properties of a tiles are homogeneous over that square. The result is that if you try to land from a jump on sloped ground, you're very likely to end up floating over the ground until you start walking.

I gave it a first try yesterday, opening the debugger, seeing what happens when I'm entering such a tile, designing a patch, compiling it, trying it, discover that it wouldn't work, refine it, and repeating the cycle. Over and over.

It wouldn't work. First because the slope tiles couldn't be fallen through. There's no need to try working around it: they *must* be made fall-through. Second because slopes are currently complemented by walk-through-but-don't-fall-through blocks that ensure smooth walk, but interfere with falling. I had that discussed with the Undisbeliever in the past, as it was a difference between our implementations, and the solution will be to replace them with a 'sloped' ground that actually is square.

But the ultimate reason of my failure is that I was trying to provide a solution for 'fall on the sloped ground' as if we'd have the last row of tiles all made of F_SLOPE tiles. The reality is much more diverse: there are so many 'corner' cases that we can hardly call them 'corners' at all.

I have a replacement design sketched, which I'll give a try in the afternoon. Amusingly, it looks a lot like what (I've understood) happens in Sonic the Hedgehog engine: consider the whole column of tiles on top of the desired 'new hot spot position' and figure out the 'ground height' in that column. Then make sure the move planned so far doesn't work past the ground.

Do that every time. If done right, it doesn't matter how many sloped tiles were encountered when checking that we cando() the move.

Well, that was the plan, but for some reason, it is not yet quite working. And for some (possibly other) reason, it managed to break walk-on-slopes despite my care to avoid so.

edit: fixed

Le tout premier ?

 

Je viens de retomber sur une pièce d'anthologie. Une reproduction colorisée de ce qui pourrait bien être le tout premier synopsis de Bilou's Adventure! On y voit d'ailleurs dans le bas un 'bubule' dessiné par mon frère.

Premier élément remarquable, la 'school zone' est loin dans le jeu alors qu'elle passera assez rapidement comme deuxième zone. La zone aquatique est visible dès le départ, mais nécessitera des palmes (juste avant la School Zone) pour qu'on puisse y entrer ... Comme dans Commander Keen.

My brother had a fascination for maps back in '93, so I should not have been surprised if one of the first documents he brought me after we decided to rename the 'buble' character 'Bilou' was a world map of the games' big adventure. 

And on the back of that world map, there was a set of sketches for the games' introduction sequence ("magic" stones get scattered during a space shuttle crash), the main menu screen, and so on. Unlike in previous documents, the character is already identified as 'Bilou', and we are 'PPP Studio'.

Cerise sur le gateau, au dos de cette feuille, les croquis de mon frère pour l'intro, les menus, etc. Qui nous confirme que même si on dans du tout vieux, le nom "Bilou" avait déjà été arrêté.

There are a few interesting similarities between that map and the ones from the original Commander Keen trilogy. Notably the abundance of world map teleporters and an early-visible area that requires a swimming upgrade to be visited.

Compared to other maps of the game, the school zone appears quite late in this proposal, and the final boss is "catvador", the evil ruler of the Black (sic. we meant dark) Empire recycled from Calimero.
 

PatchedReader

 ça fait un moment que le projet me trotte en tête. Des années en fait: faire un éditeur de texte pratique pour Nintendo DS. Pas pour écrire une 2eme thèse avec, mais simplement pour pouvoir corriger facilement les scripts quand RunME me râle dessus. Il y a quelques jours, j'ai pris conscience que je n'avais pas nécessairement besoin d'un éditeur de texte complet: un patcheur de ligne pourrait déjà être bien utile. 

Que je m'explique: le ScriptParser lit notre texte ligne par ligne et lance une exception quand la ligne ne lui plaît pas. Actuellement, je dois alors sortir mon laptop, avoir le même fichier .cmd, trouver la ligne défectueuse, écrire une version corrigée et la ré-uploader sur la DS pour faire un deuxième test.

I had the idea of making a convenient text editor for Nintendo DS trying to find its way out of my head for some years. Not something you'd use to write a novel, but at least to patch game scripts when RunME spots something wrong instead of having to do WiFi transfers back and forth until things are fixed. But a few days ago, I realised maybe a full editor wasn't needed : what I actually need (since my parser processes things line-by-line) is a way to *patch* those lines if they're wrong.

Bon, pendant mes tests, je me suis mis en place un runME-autorun.nds qui permet de répéter les choses sur ordi à moindres frais, mais pour peu que ce soit les nouvelles animations ou qqch comme ça qui coince, je suis bon pour re-télécharger des .maps et autres .sprs avant de commencer à étudier le problème.

Donc, et si au lieu d'interrompre violemment l'évaluation du script, on basculait de la CmdWindow (qui exécute le script) à la PatchWindow, qui nous remontre la ligne ayant posé problème, nous permet de l'éditer et éventuellement de retourner dans CmdWindow ?

I gave myself a 'runme-autorun.nds' derivative of the real 'runme' that can start tests faster, but as soon as issues are with poorly defined animations or specific to the data files hosted on the NDS, the need will be back.

The idea would be to switch to the edition window as soon as the parser fails (instead of killing the whole level). With help from a new sub-class of InputReader, I should be able to serve the patched line of text instead of the original one.

Rather than trying to insert new lines into a single-block of memory, PatchedReader would maintain a patches lists, each replacement lines associated with their position in the file and either serves lines from the original source or from one patch line, depending on where we are.

Pour permettre ça, on introduirait une classe dérivant de InputReader qui suivrait la ligne en cours et la remplacerait par une chaîne présente dans sa liste de patch si on a effectué une édition. On aurait la fonction nécessaire sans devoir s'embarasser à scroller dans un fichier potentiellement longuet, avec un besoin réduit de fonctions de recherches, et une gestion de la mémoire simplifiée par le fait qu'on a jamais besoin d'insérer des caractères au milieu d'un bloc-mémoire existant...

C'est plus ou moins là que j'ai laissé le développement NDS avant de me faire ré-avaler par le royaume d'Hyrule.

Evidemment, si je veux que ça donne un jour quelque-chose, il faudra que j'accepte de ne pas utiliser tout de suite le système de reconnaissance d'écrite manuscrite, mais plutôt de partir vers un clavier virtuel un peu dans la veine de celui envisagé pour l'éditeur d'expressions à l'intérieur de LEDS.

edit July '21 ... get a first draft with better error reporting including word wrapping ... that almost works.

From iColorUsed to ScanTiles

 Bion. Vous vous souvenez peut-être qu'au moment d'attaquer l'ère post-desktop, je vous avais fait une photo de mon carnet de Bilouterie (entretemps aussi devenu mon agenda) dans lequel je mettais à plat un autre algorithme pour identifier les couleurs utiles et les couleurs inutiles dans mon Sprite Editor. Peut-être ... 

Oui, parce que par la suite, je n'en ai pas vraiment fait grand-chose: ça ne permettait d'atteindre aucun objectif. ça ne contribuait pas à cocher des cases dans la todo list. Mais si 2020 m'a appris quelque chose au niveau des bilouteries c'est que je dois arrêter de faire comme si elles étaient un entrainement à la gestion de projet.

Ne pas travailler sur certains aspects d'un projet parce que le management trouve que ce sont d'autres aspects qui doivent recevoir la priorité, c'est plus ou moins mon lot quotidien au bureau. J'ai besoin de casser avec ça et de faire (faire faire) c'qui me plaire (plaire plaire). Pas de prétendre que je suis dans le management en plus d'être un bon exécutant. Alors, la semaine dernière, j'ai remis ça en route.

Bon, il est vrai que j'ai aussi essayé une fois de plus d'utiliser la fonction 'tiens, qui utilise cette couleur' pendant que je gribouillais des essais de décor inspiré du graphisme de Nerkin, et qu'une fois encore, j'ai perdu tout le travail en cours parce que le programme s'est gelé.

Au final, j'ai maintenant des boutons plus clairs, mieux séparés les uns des autres pour éviter les maladresses, et un tout nouvel algorithme basé sur une sorte d'énumération générique du tileset. Il faudra d'ailleurs que je réécrive aussi la fonction "Zap!" pour en bénéficier.

Et tant qu'on y est, je pense qu'avec une petite modification supplémentaire, je pourrais aussi m'en servir pour préparer (enfin) une prévisualisation des pages de graphisme quand on choisit quel doit être la prochaine page à éditer. Une idée vieille comme l'éditeur de niveau, mais qui ne s'était jamais retrouvé "en tête" de la liste des priorités...

Mais là, c'est les vacances qui s'annoncent, alors au diable les priorités. Faisons du hobby-coding. C'est pas Monsieur-je-suis-un-dev qui va me contredire.

Reality check

 J'ai atteint un stade dans le développement de mon nouveau LEDS ou je peux envisager de faire un essai sur du vrai hardware. (En fait, il y a plusieurs choses que j'aurais dû essayer depuis longtemps, mais il semble y avoir une sorte de flemme à ressortir la DS et démarrer server.pl, ces derniers temps). ça fait une jolie photo, mais j'ai facilement passé la soirée à faire l'inventaire des choses qui ne vont pas :P

One bit at a time, a new build of LEDS has appeared, that combine enough patches from the 'newmap' branch so that I can consider giving it a spin on real hardware. Well, or so will I pretend. The crude reality is that the "Check List for RealThing" is only a few page past "April 2020" in my notebook.

I got no significant crash, but many of the features are incomplete. The evening was gone when I finally had the list compiled. Next evening, I'll update the e-book doxy-code and will start investigating why I have "bugWindow" inserted between MapeditWindow and MonsterWindow ...

La conversion des niveaux, par exemple, est incomplète. Ni les tiles "jump-through" ni les pentes n'ont été récupérées. Sur un vieux niveau où il n'y a pas de déclaration des blocs spéciaux, ils sont tout simplement invisibles (voire peut-être ignorés).

Les copier/collers de blocs spéciaux sont un peu bizarres aussi, en particulier pour les tiles "voir ci-contre". Je sais pourtant en créer de nouveaux en utilisant directement les Meta-Boutons.

Enfin, il se passe quelque-chose d'étrange avec la gestion des "fenêtres", comme si il y avait un mode "buggué" entre le mode "dessin" et le mode "édition de monstres".

Je sens qu'il va y avoir un nouveau .epub avec le code le plus récent à télécharger sur boox ...

Le retour des Meta-Boutons

Bon, la bonne nouvelle, c'est que j'ai repris le travail sur l'éditeur de niveau: il faut bien qu'on puisse profiter des nouvelles possibilités offertes par le moteur "newmap", vu qu'il a passé le premier round de tests automatiques.

J'ai attaqué avec la révision des "méta-boutons", cette palette d'outil qu'on peut faire apparaître sur la droite de l'écran pour définir si le sol est solide, pentu, préciser si les graphismes sont des bonus, etc. Il est encore trop tôt pour balancer un "ça avance plutôt bien", disons juste que je n'ai pas encore été immobilisé.

There's some good news: I resumed working on my level editor. Having a brand new game engine supporting more slopes and more physics won't be very sweet if I can't make level for it, right?

Well, I started with fixing 'meta-buttons', that widgets palette on the right of the map edition that let you define blocks properties. It is still too early to claim "good progress has been made". At this point, the best I can say is that I haven't been stopped yet.

There's some bad news too, unfortunately. If there is progress, it is even slower than Wintergatan's marble music machine. I'm happy if I managed to work 3 or 4 hours a week on the topic. I started my todo list in my notebook so that I can plan the things to happen even though I might not be ready for more screen time by the end of the day.

La mauvaise nouvelle, c'est que ça avance encore plus lentement que la machine musicale à boules de Wintergatan. Si je "travaille" dessus 3 ou 4 heures par semaine, c'est beaucoup. Heureusement, donc j'ai mon calepin pour y cogiter quand j'ai un peu de temps libre, pas d'épisode de Castle en retard, mais que je ne suis plus trop d'attaque pour me coller devant un écran.

Pour situer, j'ai même carrément commencé un thread twitter avec des p'tits bouts d'avancée parce que je sais parfaitement bien que quand je serai finalement devant le bon PC (plantage de desmume pendant que j'essaie de faire tourner l'éditeur sur le PC plus souvent disponible), j'aurai probablement oublié le calepin à côté de mon téléphone dans mon "cubicle" au premier qui me sert de bureau depuis que je suis en mode télétravail.

I had initially thought that once planned, I could crunch the thing in a couple of evenings, but no. This has turned so much into micro-development that I even started a twitter thread to post my screenshots and track "what's to do next". Left foot (one fix). Right foot (another bug discovered). Left foot(another fix). Right foot (yet another bug).

Not that ugly code got written, but the dependencies of what I had foreseen to need changes was of course imperfect. Sometimes more buttons means I start trashing the VRAM with my "back-up memory". Another time, I notice that the 'autorun.nds' used for tests doesn't know how to clear the screen (and turns it all red). Every step takes only an hour or so, but since that's all I can afford per sprint evening, it starts remembering me of how it felt to write code when I was 12 and my parents told me "that's it. 55minutes. Now save your work and wash your hands: the dinner is ready". (except that I'm one of the parents and that I'll have to make the dinner ready ;)

"Tiens c'est quoi, cette barre verte" ... une petite heure d'investigation. un commit qui corrige le mauvais positionnement de l'espace de backup dans la mémoire (oouhhh). Je déclenche accidentellement un "mur rouge" en voulant vérifier que tout va bien mais il est trop tard: ce sera pour un autre jour.

Et cet autre jour, je constate qu'un peu de refactoring serait le bienvenu avant de chercher l'erreur. Paf, une fois le refactoring terminé, il est déjà temps de refermer le laptop. Jour suivant, je fais les recherches avec gdb. Mais une fois le problème identifié, bardaf, il est temps d'arrêter.

Bref, je crois que vous voyez le tableau. ça rappelle un peu les conditions de programmation BASIC de quand j'avais 12 ans, tiens.

Well, let's not get disappointed, shall we ? I finally got translation-on-loading repaired yesterday. I refreshed how-autorun-checks-VRAM in my brain. Maybe I'll be able to fix one more bug tonight? Or I'll watch some more of Castle, S5 with my Fairy.

The Dreamland Map

I'm reaching the last pages of my plan-your-things notebook. It helped a lot completing both real-world and hobby projects. I've got more books available to take over, but I also need to make sure I won't miss contents of the 2019 book when I'll be hanging around with the 2020 book. That's why the 'todo maps' are on flying sheets rather than on proper pages.

Maybe there are things I should blog for remembering. Clearly there are things I should doxygen...

There are things I still need to blog in there. Notes I've taken about SNES hardware, for instance, and similar hardware features from the NDS which I haven't used yet.

And then, there are game analysis things, which are totally unrelated to tools & engine development, but which I'd like to bring into the 'design class'. Those, hopefully, will not be missing if I don't have them around in the new book.

You see, having the dsgametools code around in a e-boox is nice, but I need some additional place to "think out loud", and with my eyes not liking using screen more than 10 hours/day, it cannot only be this blog anymore. That's what the notebooks are for ;)

DoSlopes

Ok. Ajouter des pentes dans un jeu de plate-forme, ça devrait ne pas être compliqué, mais dès qu'on modélise son niveau à l'aide de dalles pré-définies (toujours les bons vieux tiles), ça cesse d'être simple. J'en ai déjà beaucoup parlé (cf. le tag) mais sans jamais vraiment (reality check: si) présenter la solution que j'utilise depuis Apple Assault: la fonction doslopes.

L'algorithme derrière doslopes travaille uniquement avec le 'hotspot' des sprites, et veille à garder ce point en contact avec le sol tout en appliquant un déplacement horizontal donné (qui peut s'étendre sur plusieurs tiles). Il utilise aussi une fonction annexe -- groundheight(x,y) -- qui donne la hauteur du sol pour un tile du niveau à partir de la base de ce tile. On y reviendra.

L'algorithme est constitué d'une boucle optionnelle (en jaune) pour atteindre le tile de destination puis une phase d'affinage (en vert) qui calcule la position du sol pour la position horizontale voulue.
En sortie, on obtiendra un  déplacement vertical correspondant au déplacement horizontal donné. A chaque déplacement intermédiaire, doslopes s'assure que l'on est pas en train de s'envoyer dans un mur à l'aide de la fonction cando -- la base de la gestion des interactions sprites/niveau.


Le principe de base, c'est de regarder la hauteur du dernier pixel d'un tile pentu juste avant de le quitter. Il peut avoir une 'hauteur = -8' ce qui fait positionne le joueur juste au-dessus du tile (comme on le fait normalement pour du sol) et permet du coup de regarder le bon tile pour la suite de la pente au tour suivant.

Rush to Flatworld

It took me some time to get all the special block types working again with the new collision engine for GEDS. Partly because there were places in the scripts that referred to some block identifiers which I had to squeeze from 8-bit to 6-bit. I managed to make it a lossless squeeze, but some bits had special meaning. 

Like all the blocks identified 1xxx or 3xxx triggering actions even when collided by a monster while 0xxx and 2xxx would require a HERO cast. Or like the second character of the id xXxx indicating whether the block would act as sky (x0xx), water, block (x2xx) or floor when not interacting.

Avec le recul, ça me fait un peu penser à un donjon Zelda où on viendrait de trouver l'objet-clé. J'ai un nouveau mécanisme pour gérer les types de blocs sur DS, conquis après une lutte opiniâtre contre les vilains bugs (pensez aux wall masters) et les émulateurs récalcitrants (grosses statues à déplacer vers une dalle-interrupteur au hasard dans la pièce).

Et du coup, je dois retrouver les différents endroits où je peux à présent reprendre le développement. Editeur de niveau amélioré ? Programme de conversion vers un nouveau format de map ? Plus de types de pentes ? chacune de ces "petites clés" supplémentaires seront nécessaires au final pour pouvoir faire une version jouable de la maquette "desert zone" que j'ai en tête, et un bon nombre est aussi utile pour débloquer une conversion correcte de la "green zone". Mais là, je suis dans la salle avec trois portes et je dois choisir la bonne.

But well, it finally works fine for level 1 of school rush, and adapting other levels should now become easy as I patched the "rules.gam" shared file instead of patching directly the level commands.

And while working on it, I also mapped the whole set of "tile properties" that were in use in School Rush. That will help for introducing the new tile types. In addition to the 'special' blocks, some will have direct flags for the 'cando' operations and some will have indirect flags (i.e. you have to lookup a table to know their properties). The idea is to reduce the comparison stress for the 'normal', 'empty' tiles. We may keep the 'monster cage' tiles, but they would be seldom tiles compared to plain 'air' tiles and allow an extra table lookup.

Well, that last part is not yet done. And to be honest, I feel so tired that I'll need to go back to my little "remember you had no blog" notebook to see what has unlocked with the newest achievement and which target should be my next goal. I can't even dare to do that on screen :-/

Toolset and MonsterPropWindow

I've got less free-reading time during my vacation this time, and likely, I should be not blogging right now, but cleaning up all the mess that going to vulcan(eifel) and back brought to the house. When I did get some time, I spent it clarifying some obscure parts of my Level Editor which puzzled me when I initially tried to add some additional monster edition features, like being able to decide within LEDs whether a given game object belongs to the 'hero' cast, the 'evil' cast or none of them.


I refactored a few things to make that possible already and I hope I'll get some time to continue working on it within the upcoming days.

I also took some time documenting one of the more elaborate (but arcane) widget that I might have to use to do that: the 'ToolSet' meta-widget, which is truly a bunch of buttons hacked to behave like the typical radiobuttons of point-and-click GUIs.

L'ère post-desktop

Bon, soyons clairs: être sur un PC - un vrai, avec une souris, un clavier, une connexion réseau et un écran - ça ne m'arrive plus qu'au bureau. La bricole homebrew, ce sera de temps en temps sur le laptop ... avec tout ce que je peux préparer hors-PC hors PC. Le "engine design" dans un cahier atoma -- pour pouvoir mettre en vis-à-vis les idées et leur conséquences -- la documentation UML dans un cahier A4 quadrillé à spirale, etc. J'ai même tenté une sorte de 'bullet journal' pour suivre ce qui devait aller sur le blog, les posts en standby etc, qui est tombé plus ou moins dans l'abandon depuis que je me suis installé Wordpress sur mon Boox.

Let's be honest: being on a true PC -- with a mouse, a keyboard, a screen and an Internet connection, that only happens at the office. Homebrew devin' nowadays, that's on a laptop, and everything that can be prepared off-screen is welcome. So game engine design happens in an Atoma notebook (so I could put an idea side-by-side with its outcome), UML documentation goes in friendly A4 notebook, and I even started a 'bullet journal' to track what blog posts should be updated, those waiting for sketches to be scanned, and those who are waiting for translation (although installing Wordpress on my boox helped with this)

I level'd up these offscreen tools this year, with a dotted-paper notebook where I scribbled "proudly powered by CreaCorner" that somehow became my true (offline) blog until I shoot a picture and share it on twitter. 

 This is where I collect my todo lists, things to be reviewed, things that should be done when I spent an hour on the laptop, and so on. And I'd rather keep going, since I'm in half-zombie state when I'm finally done with dish-washing these days. Without dotted paper help, I'd be browsing from one abandonned forum to the next one and not even having enough energy to start reading what people have posted.

Et depuis cette année, je me suis trouvé un super petit cahier pointillé à la fin duquel j'ai écrit "proudly powered by CreaCorner (en fait, c'est un Bullet Journal Toga) ... c'est plus ou moins devenu mon vrai blog, sauf qu'il n'est pas en ligne... allez, quelques photos de temps en temps sur Twitter.

Je me fais aussi mes petites "todo listes" dedans. Les choses à relire dans du code converti en e-book. Pourtant, une bonne partie des 'todo items' auront besoin de repasser sur PC. Parce que vu l'heure à laquelle j'en ai fini avec la vaisselle ces jours-ci, quand j'ouvre mon portable, je suis en mode demi-zombie ... je passe de forum vide en forum vide sans vraiment avoir l'énergie de lire ce que les gens y ont mis.

Donc, bin je vais me les ré-encoder ici, histoire d'avoir cette liste sous la main dans les rares cas où je suis sur PC :-P

• Q: où est-ce qu'on en est avec LevelModel, pourquoi ::SaveCommands() est vide ?
• Q: pourquoi avais-je introduit "MonsterGeneration"
• A: cette classe apparaît en même temps que le système de tri des 'blocs' de texte pendant les liens entre objets ... sans doute une tentative avortée qui sera restée au moment du commit faute de reviewing correct du code.
• Q: pourquoi est-ce que je n'ai aucune doc sur EditorLevel::scanSubFile() ?
• [todo] Refaire un coup de -WeffC++ sur le code, et trouver les #pragma push qu'il faut pour que le code incapable de supporter 'effective C++' se taise une fois pour toute et que ça devienne le mode par défaut pour la compilation.
• [done?, merged] transférer des captures d'écran des outils dsgametools à l'intérieur de la doc doxygen
• [todo] faire en sorte que SpriteRam apparaisse dans la doc du SpriteEditor

edit: voilà. je viens de terminer d'écrire ça et mon GSM me rappelle à l'ordre façon Monkey Island: "maintenant éteignez votre ordinateur et allez vous coucher".

Tile Engine Revision

Bon, j'ai une grosse révision de mon moteur de jeu en cours. Jusqu'ici, les propriétés du niveau étaient conservées dans les bits "palette" du niveau, soit 4 bits par mini-bloc de 8x8 pixels (les tiles, pour les intimes. Prononcez avec de l'aï comme dans light). Pour "School Rush" et ses niveaux de 16 écrans de large pour 1 écran de haut, on parle de 8KiB de données. Un niveau de Commander Keen (mettons la machine infernale des Shikadis) avec ses 1200x1200 pixels nécessite 22500 de ces tiles.

Much of my hobby time has been spent in tileset engine investigation since SchoolRush release. The current one has a few shortcomings which proved annoying during the " finish him " phase. Among other things, I want to stop using the palette bits for metadata, but it is still unclear how many bits per tile I can afford.
Most levels in schoolRush need a mere 16 screens, and consume only 8KiB with the current 4-bit-per-tile implementation. A Commander Keen level in comparison is 1200x1200 pixels, which would require about 22K tiles.

Pourquoi tous ces chiffres ? parce qu'au coeur de la révision, il y a le besoin de faire sortir ça des bits de palette pour pouvoir utiliser librement les changements de couleurs si utiles dans School Rush tout en permettant de nouvelles mécaniques de jeu. Jusqu'ici, j'ai pu m'en sortir avec des blocs spéciaux (bonus, pics) qui utilisaient les "codes couleurs" des 4 tiles qu'ils couvraient pour encoder un numéro suffisamment large. Mais quand on commence à réfléchir à faire de l'eau, des ventilateurs ou des tapis roulant, ce système devient bancal.

Of course, one of the goals for the revised engine is to enable multi-palette edition on both tile layers, but I would also like to increase the number of unique materials in the game. My attempts at having ice blocks, conveyor belts and flowing water highlighted that special blocks are not enough for all purposes.
One reason that makes it misfit is that special blocks only work for 16x16 blocks, not for arbitrary layout of 8x8 tiles or for transparent areas.

En particulier, il était basé sur le fait qu'un groupe de 4 tiles sont liées par les numéros de tile (en mémoire vidéo) utilisé parce que l'éditeur de sprites fonctionne comme ça. Impossible donc de définir un bloc-bumper sur un graphisme qui serait fait d'une moitié de gomme et d'une moitié de lettre. ça, c'est plutôt un avantage. Impossible aussi de rendre une pointe de crayon blessante si elle est sur 'l'arrière-plan'.

So from those figures, and given that the NDS has 4MiB of RAM, upgrading to 8-bit per tile should be possible. Granted, it could be nice to include some decompression techniques or some 16-bit era fancy techniques, but none of this seems to be mandatory right now. That's one of the strengths of the DS, imbo, that you can already make interesting games while keeping the engine simple.
And yet I know that at some point I'll wonder how such function could be achieved on a much simpler system - let's say a GBA, a SNES or a Mega-Drive... And should I have need for e.g. virtual tilesets, splitting away physics (meta) information from remappable graphics information would help.

Faut-il donc que je continue avec ce système (données 4-bit) sachant que je travaillerai maintenant sur un tableau séparé ? Puis-je me permettre une extension à 8-bit par tile ? et si oui, comment organiser au mieux les données ? Est-ce que ça m'impose d'intégrer de la compression ?

A mon avis, avec 22Ko pour une map type "Commander Keen" et sur une bécane qui dispose de 4Mo de mémoire principale, ça reste parfaitement jouable. Oui, c'est loin des techniques de trapéziste de l'époque des consoles 16-bit, mais c'est justement une des raison de choisir la DS à mes yeux: elle permet de se concentrer sur le jeu lui-même, avec des contraintes, certes, mais des contraintes simples à apprivoiser.

Todo list update

La "todo map" pour le projet "School Rush" a pas mal progressé depuis sa mise en ligne en 2015. Heureusement, me direz vous, et sans doute aurez-vous raison.

Maintenant que l'objectif "School Rush" est atteint, il va falloir que je reprenne ça, et que j'y ajoute les révisions souhaitées pour le moteur de jeu (gestion des coordonnées relatives pour pouvoir se promener à dos de 'blador correctement).

Back in 2015, I drew a 'todo map' for my School Rush game, trying to capture the 'todo' items scattered over this blog, prioritizing them according to the 'finish the School Rush game' objective and show how they relate to that objective altogether. Now that the game is complete, I've found myself wondering what I should do next ... so let's proceed with a new and fresh list. 

There are a few engine revisions I'd like to do, there are tool updates to be done and tool updates to be validated (esp. regarding the level editor). There is the level map format that needs to evolve in order to allow more flexible multi-palette updates. I also would like to find time to review the scripting language so that we can (at last) edit characters behaviours directly on the NDS.

Il y a aussi des mises à jours d'outil (le fameux "rules.gam" et la supression des ennemis hors-cadre lorsqu'on redimensionne une map) qui n'ont pas encore été suffisamment testés à mon goût sur DS, et un ou deux remaniements du format des niveaux (pour permettre l'utilisation de 16 palettes sur tous les blocs du niveau) qui affectent aussi bien le moteur de jeu que l'éditeur de niveau.

Après, j'aimerais bien pouvoir m'attaquer à une adaptation du langage de script pour qu'on puisse les éditer directement depuis la DS. nom de code: beds / geds3.