TileMap

I had a remark in my notebook, wrote a few months ago, where I felt it weird that some parts of the game engine would require a SpriteSet where they actually needed information about the level map, and that the SpriteSet class was actually the only object capturing the map pointer, as well as its dimensions.

I then realised there was several places in the code where you'd load a map from a file, and it was tricky to use only one of them because one is within SpriteSet and the other (in the level editor) has no use of such a SpriteSet. It was time to introduce a new class with informations about a loaded map. Refactoring things went pretty fine and I could even repair a few things thanks to the 'unit-testing' tools (and thanks to the 'watchpoint' feature of ddd).

Well, I realise that doesn't mean a lot. That's all I could craft since I'm on holiday, I'm afraid. Happy new year.

edit: now, with only one class doing .map - to - memory conversions, I can make a new unit-testing tool that operates on level maps. I stuck to the idea of having some 'generic' tool invoked in scripts to define test cases based on reference data, but I pushed it on step further than 'cmdck' I wrote in early 2019: 'mapdo' handles a stack of level maps in the way a RPN arithmetic evaluator handles a stack of numbers. And you can quite easily define new 'operators' that act on that stack. It will help for things like cropping, splitting, patching etc. and can also help for tests such as "load level1.map save test1.map load test1.map eq" to check the level hasn't changed after being saved-and-reloaded (e.g. on-the-fly newmeta conversion produces the same contents as PHYS chunk loading).

• by just passing "show" as the constructor argument to CommandHandler, this handler will be invoked whenever we see "show" on the command line
• CommandContext.maps is the stack of level maps,
• CommandContext.next() provides one token from the command line, for both commands-to-handlers lookup or for command arguments.
• it could be further simplified into a void run(cc) since we no longer need to communicate the amount of command line tokens we consumed.

I love how both the core loop and the handlers are elegant, although I'd have loved a more in-line syntax like case "show": or show=>sub { ... } as well, but they wouldn't have worked in C++, would they ?

Refactoring "QuickGo" widget

I'm trying to make that "mini-map" widget better following good practice software engineering, so that I could maintain the rest of the tool more easily. I've done that refactoring one small touch at a time, in usually one-hour session while it was damn hot outside and while kids were sleeping in the living room.

It looks like I've introduced a few bugs with the refactoring, though. It's been a while since I didn't get something that messy !

edit: oh, btw, that got fixed through early August.

And yeah, I know, it's a bit odd to keep blogging such things. Likely something that is both a public version control and a social website would do the job, and 'github' would immediately come to mind. Unfortunately, A) I hardly trust Microsoft to keep running github nicely and B) github doesn't work with my boox device >_<

Madness? this is refactory !

Maybe you remember this picture, the first one I scanned with my iris mouse. Maybe you remember the times where I mentioned some more things in the collision engine needed a revision. At last, I'm at it.

When two objects collide, they need to have access to each other for some times until all the rules of their state machine have been evaluated. To do this, I used a "GobCollision" object, linking to the related objects, script variables and hit boxes (GobAreas). That was a nice first step towards clean design, but it still has some drawbacks, like using weird arrays of so-called "GobCollision" that each captured only one side of the collision, and copies into the array to somehow "swap" orders when the collision initiator finally runs the 'found' rule with the collided object as "other" (while it just was 'other' for the 'hit' rule on the collided object).

But I had a small extra "Swap()" call dangling around. With some odd effects on the game, as you can see. But hopefully, I just got it sorted out. Now I'll be ready to be gone with the "collision-specific variables" telling how much hitboxes overlap each other, which is currently stored as a game-wide static array, while it should really belong to the new, real collision state object.

Guru Meditation again

Bon, je me suis retrouvé après avoir fait quelques essais du nouveau système de gestion des évènements de mon moteur de jeu avec un bel écran bleu. Sur DS uniquement, évidemment. Après quelques tentatives infructueuses de régler ça en une demie-heure, j'ai fini par profiter du fait que ma fée était en réunion pour me faire une soirée "guru méditation" à l'ancienne.

Papier quadrillé, désassemblage des fonctions impliquées (au moins, la position dans le programme était correcte), déduction de quel registre contient quelle variable (pour pouvoir exploiter le contenu de l'écran bleu) et structure physique des différents objets impliqués à grand coup de ddd en comparant le contenu "brut" de la mémoire et des affichages haut-niveau.

Vu que le crash se produit à cause d'un accès à la mémoire via quelque-chose qui n'a rien à voir avec un pointeur, j'étais prêt à rajouter des "nombres magiques" ça et là pour pouvoir reconnaître une transition, un état, une expression, etc. Mais en réalité, je n'ai besoin de rien de tout cela. Tous mes objets critiques ont au moins une méthode virtuelle, ce qui signifie que je peux utiliser la référence vers la vtable pour déterminer directement si une zone de mémoire donnée contient toujours un objet d'un type donné ou si elle a été écrasée.

A partir de là, c'est de la navigation dans la mémoire de la DS en suivant les pointeurs retrouvés sur l'écran bleu pour reconstruire l'état des objets impliqués dans le crash. Et au terme de tout ce sudoku-géant je finis par trouver deux indices troublant:
- l'adresse d'une des transitions à tester en cas d'évènement est un anagramme de l'adresse qui a causé le crash
- l'adresse de la liste de transitions correspondante n'est pas multiple de 4 alors que toutes les adresses ont une taille de 4 (bytes, mon cher Wattson).

L'émulateur voyant cet accès étrange aura "redresser" l'adresse, ignorant les bits les plus faibles. Parce que, oui, la machine sait que je veux prendre 32 bits quand-même. Le CPU de la DS, lui ... eh bien, il m'a sorti une variante mélangée des 32-bits se trouvant à l'adresse utilisée par l'émulateur. Les 8 bits "les plus à droite" de la valeur en mémoire se sont retrouvés à gauche pendant que tous les autres étaient décalés vers la droite.

simplifying events engine

I want to get rid of some static pointers in the management of events. The idea turned cleaner as I was flying over Denmark. But the result isn't convincing yet.
- you can't jump out of inkjets anymore (event from dpad controller is ignored - apparently because TrackAttached produced an event too -- although it has no corresponding transitions)
- you might get pushed away from spongebops when you try to grab them -- weird things still occur here with my best solution for inkjets.
- if Bilou starts swimming up, he'll keep swimming up forever -- that's fixed with swapped-priorities
- the little stars shining around you when you pick a health bonus keep shining forever. -- seems fixed with swapped-priorities too.

The thing is, when I want to combine the "thoughts" of two controllers, only one events list can survive. And of course, things don't get fixed if I swap the order in which they are produced (unless I swap them properly, that is). Weird things remains with that swapped-priorities, though. Like why don't we play the 'roll-in-the-air' animation anymore when Bilou's direction is changed while jumping ? I'll have to re-activate InspectorWidget and use the combined powers of InspectorWidgets and DDD to find out.

By the way, did you know that we could have methods, operators overloading and constructors for unions ?

GameObject::useEvent() should go away.

That shouldn't happen. The way controllers fire an event is not satisfying. A static pointer set by class X so that it is used by class Y with no restriction on who does what and that merely works because we know X calling ::useEvent() and Y checking *::doevents happens to take place with the right timing ? No.

I mean, look at the documentation: "assumes no re-entrance until gobRunController". That has turned false the minute I introduced 'attach-to-other-game-object' feature where you might have to run the object you're attached to before you can run yourself.

I'd like to convert {NONE, FAIL, EVENT}  enum into something else that allow "EVENT" to carry the list of transitions to check by itself.

Tuto branch update.

A few weeks ago, I found myself pressing the direction pad of my DS to keep
that little character onscreen. It had the most basic behaviour could think of because its sole purpose was to demonstrate how we control things in my game engine. Somehow, it felt a bit like an empty level in Space Taxi.
today, that same character moves around a place that comes from the level editor, with blocking tiles effectively blocking you. What it misses is a target. Snake-like pellets, if you want.

That requires me to revise:
- collisions between Gobs
- counters
- in-game level changes.

Tutorial revision goes on.

I reached the point where you can write very simple scripts and have them processed on the "tutorial" branch. Of course there isn't much follow-up at the moment despite the 3 forums on which I comment stuff. That doesn't really matter, although I'd love to get feedback on whether it reads well.

What is really interesting here is that it forces me to get rid of many odd things. Hopefully, that will lead to a code base that will be easier to extend. Things like "rules.gam", for instance.

Being busy reviewing the expressions system, for instance, make it obvious that some static array could be gone now that I have the gob collision structure. the "game counter al so cry for a refactoring out of the GameScript class. And making the 'guns/controllers' system easier to understand (esp. by automating the registration system) made it obvious that I need to re-think the way classes access the Camera object.

Biggest Refactory Ever

For me, at least. I wanted to make the scripts occur as soon as possible in my tutorial series, since the GEDS engine is meant to allow game-making even for those who don't know about C++ programming. But I also want to be able to introduce a behaviour editor, which suggests that the same script-parsing logic should be able to drive either the game engine or the state machine model in the editor.

So this last week, I've been busy splitting the big singleton "GameScript" that had both the parsing logic and the engine intimacy into two classes, the ScriptParser that knows the language rules and the Game* objects well enough to create them but has no knowledge about the Nintendo DS resources or the game engine per se, and the GameScript, that knows about the engine's runtime, last as long as the level does, hold resources and the like.

ça bosse ferme ... restructuration du lecteur de scripts pour pouvoir introduire un éditeur de machines d'état ...

I've finally reached a point where all my automated tests work again. Of course, School Rush isn't running fine in this branch ... yet.

edit: Okay, SchoolRush runs fine again in the emulator. Just some un-initialized arrays. -Weffc++ should have caught that, though.

gource and reDS

C'est un outil super: gource. Transformer les fichiers logs d'un gestionnaire de versions en une animation interactive où les développeurs deviennent des jardiniers taillant, soignant, élagant, greffant...

Et facile à utiliser, en plus! Bon évidemment, ici c'est assez moyennement intéressant puisque je suis tout seul sur le projet depuis le début ...

Mais au moins, ça met bien en valeur les efforts pour restructurer le code et permettre à d'autres (au cas où) de faire des projets à base du moteur de jeu GEDS plus facilement.

Au passage, j'ai franchi un cap avec le code d'AnimEDS. Les "modèles" sont maintenant activés. Je regrette un peu d'avoir quand même dû passer par l'émulateur et une exécution pas à pas pour corriger les bugs introduits lors du refactoring alors que j'avais des programmes de tests pour l'architecture native juste à côté... mais bon, les erreurs étaient dans le setup des objets, pas dans leur logique.

Maintenant, il reste à sortir la gestion des "callback" hors de la classe "Engine" (je les verrais bien en gestion autonome, avec un objet complètement interne qui assure la gestion et qui est caché derrière les méthodes "register" et "unregister" de la classe-maîtresse). edit: c'est fait.

AnimationModel

Donc, j'ai fini Fez (enfin, j'ai 64 cubes) mais ça, je vous en parlerai plus tard. J'ai aussi fini de réorganiser le code de mon éditeur d'animation de sorte que les manipulations effectuées sur la liste d'images puisse être extraites du code de l'interface graphique correspondante. Je ne vais pas qualifier ça de Model/View/Controller, mais c'est un pas dans la bonne direction, à mon avis.

At last, am done with one big chunk of nefactoring on the DS Animation Editor. Frames list can now be manipulared from any piece of code. It no longer requires emulation of the whole widgets/windows engine. 

It is probably not scleanly separated as MVC code, but it is definitely one step in the right direction. Now I can get rid of the ugly coupling between thumbs display and thumbs-bitmap filling when saving the file. I can get rid of global objects. I can introduce my new Resources class.

Tout ça parce qu'il était impossible dans l'état actuel de débarasser AnimEDS de ses objets globaux vu le couplage tordu et foireux entre la fenêtre qui fait le rendu des miniatures et le système de sauvegarde. Pensez un peu: pour sauver les miniatures (utilisées par l'éditeur de niveau), on allait devoir faire croire à cette "fenêtre" que l'utilisateur passe d'une page à l'autre pour la forcer à re-générer des prévisualisations en mémoire vidéo que l'on capture pour les placer dans le fichier.

Prévisualisations qui - au passage -- demandaient qu'on fasse croire à la fenêtre d'édition des animations qu'il y a une nouvelle animation à éditer pour qu'elle la décode, construise la liste de frames correspondante et qu'on puisse demander un rendu de la première frame à chaque coup.

C'est presque un miracle qu'on ait pu continuer à éditer des animations après une sauvegarde, à ce tarif-là.

Tout ça parce que si AnimEDS garde ses objets globaux, il est impossible de réorganiser la gestion des resources dans le Game/GuiEngine.

Engine Refactory

The Big Refactory has started (I could pretend it is a new-year resolution). And it even went pretty far, like abstracting away the animated objects list so that only the code for animated objects need to know details of the animation scheduler.

I was about to try changing the VRAM allocation system so that only classes deriving from using Resources could request items, and I got stuck in the animation editor.

Unlike SEDs and -to some extent- LEDs, AniMEDs still use a lot of global variables. Things like the sprite set or the animation being editted are used almost directly in many places, instead of being captured as "structural singletons". And at some places, it also means that we were calling Ressource Manager directly at top-level code, and that contradicts what a common base class can do.

There is one other peculiar thing about the animation editor: the set of pixels used in the game isn't uploaded to the video memory. Instead, we keep it in main memory, and only some bits of it go tothe VRAM through a Sprite sheet that map some sprite memory.  These sprite sheets are linked to a specific widget, such as the timeline or the frame preview. I must not try to make them part of a "model": they truly belong to the implementation of the widgets.

And yeah, although I have a digital sketchpad and an e-boox, I still enjoy some good paper and fine (erasable) pens for such things.

Refactoring de dingue!

J'hallucine. J'ai pris une de mes plus vieille classes -- InfiniMap, responsable à la fois du scrolling et des collisions sprites/map. J'ai renommé ça en "CommonMap", appliqué les changements partout sauf aux sites de construction. J'ai ensuite déplacé le code utile dans un nouvel InfiniMap, déclaré l'une ou l'autre méthode comme purement virtuelle dans CommonMap ... et recompilé.

I can hardly believe it. I picked of my oldest classes -- InfiniMap, that controls  scrolling and  -sprite-vs-world collisions -- and renamed it common map, everywhere but on lines of code building some instances. I then moved the "real" code into a new InfiniMap, mentioned a few ."pure virtual" markers in common Map, and rebuilt...

Et ça marche ! C'est du délire à l'état pur. Ok, j'avais une classe iWorld mais je ne m'attendais pas à ce que le truc ne réclamme aucune autre intervention. Nada.
Allez, demain, je déplace le maximum de variables membre.

And it works! I can't beleive it! (dott). I knew I had some interface class already, but I wasn't expecting it to work that easily, not requiring any fix or whatever !

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.


Plus les choses avancent, et plus j'ai envie de pouvoir proposer quelque-chose de plus didactique pour encourager d'autres amateurs de développement de jeu à s'essayer à la plate-forme NintendoDS. Pour ça, il me faudrait pas mal de réorganisation du code, et (idéalement) une branche mercurial qui approcherait les techniques nécessaires une par une, mieux documentées et testables. Et là, maintenant, c'est parti.

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.
[done] have it built as part of the dsgametools host-tools binaries, buildroot-style.

GobAnim vs. GobAnim

Something went 'oops' when trying to upgrade the 'bouncing feet' behaviour for dumblador's behaviour. I edited new animations for the feet in AnimEDS (mostly to take advantage of the bounding box edition feature), but when I injected that into the ongoing test level, I simply didn't see any feet anymore.

Armé de mes nouvelles petites anim' pour les pieds baladeurs de Dumblador (et des zones de collisions associées), je venais tout juste de faire les ajustements à blador.cmd, mais en lançant le jeu dans l'émulateur, j'ai juste eu droit à une avalanche de "oops? endless looping" sur la console de débugging. Un p'tit breakpoint bien senti sur iprintf (oui, carrément) m'a permis de voir que je faisais fausse route: ce sont des GOBs "simples" (comme dans AppleAssault) qui sont créés pour les pieds et non pas des CompoundGobs comme Bilou et Dumbladors. Du coup, l'interprétation des données d'animation est erronnée. Je vais devoir passer plus de temps que prévu sur ce point-là.

I had to rely on some DDD to figure out that gob shooting currently systematically create a SimpleGob instance, but that attaching a AnimEDS animation to a SimpleGob just results in non-sense (and likely no display). I thus have to merge a bit more those two co-existing animation parsing (binary and textual) and rendering (compound or simple). The easy way out would be to claim "oh, I can also shoot compound gobs", but the reality is that 90% of shots (weapons, dustballs, feet) will be simple gobs. Only monster generators and Bosses may need something else.

• [done] GobAnim::parse() should use AnimUser encoding, rather than AnimCommand {} structs. Keep the API (GobScript syntax) unchanged.
• [done] SimpleGob::play() should align to that new encoding.
• [done] enable BBOX, origin and pageno's colours bits from anims.
• [ok] ensure a 1-limb AnimEDS encoding can be used to create SimpleGobs in GameScript::GobCommand() 
• [done] GameScript::setGobState() no longer blindly cast to SimpleGob to call setstate()
• [done] GobGun::shoot() no longer blindly generates SimpleGob()s

ordinogramme

Some boxes, some arrows, and proper abstraction level ... That remain imho the best analysis tool to apply (now from code shown on e-Ink :) before I start messing up with some refactoring. This time, it turns out that I _can_ use virtual method to encode TIFrame and TIControl differently given that I revise what arguments these functions receive and pack the dependencies into an 'encoder' state structure.

Mon patron appelle ça "des boi-boîtes et des flè-flèches", avec un léger dédain dans la voix. Moi, j'applique ça depuis le Simon's BASIC sur C64, et je trouve que ça continue à me rendre de fiers services. Trouver le juste niveau d'abstraction pour l'encodage des animations par AnimEDS, par exemple...

Once that has been done, I can easily fix the I_DELAY / I_MOVETO redundancy issue that slows down Bilou's new walk animation.

Oh, and I will still have to figure out the difference between 'move 2 0' and 'move 2 *' in the implementation if I want to restore rulers climbing.

branch/companim

Rien de tel qu'un peu d'UML pour commencer la nouvelle branche du SVN "animation composée" (imho). Ah, mais peut-être voulez-vous un mot d'explication sur les "branches"? C'est l'équivalent pour un programmeur de "Dis, on va commencer par dupliquer la maison dans un univers parallèle avant d'attaquer les travaux pour la véranda. Comme ça, si on doit chercher les clés à un moment donné, on a qu'à le faire dans la copie de base. Et puis on peut laisser les enfants dormir dans celle-là, aussi: inutile de les envoyer dans la copie où on a abattu le mur du salon et où l'eau ne va plus jusqu'aux WC, hein ?"

Convaincus ?

I was quite confuse on where to start working on the compound anim support, so I just started by depicting the current situation into an UML blueprint, trying to precise which are the different phases of SimpleGob::play, which member variables where involved when, and where in the class hierarchy they stand. Part of my indecision came from the fact that the abstract class GameObject is designed to capture what controllers use, so I wasn't quite tempted to push up the state management there.

And to my suprise, that alone suffice to show me the right path to take: introduce a CommonGob class that capture what's not-in-GameObject but should be in all the technical variation of the animated objects.

Bon, première tâche dans cette branche, donc, c'est de refaire un peu l'état des lieux. Une animation composée, ça change essentiellement l'animation des GOBs, mais l'état, les contrôleurs, les collisions, tout ça reste identique. Ouais, sauf que jusqu'ici, tout ça est uniquement dans SimpleGob.

Une fois tout à plat sur ce joli "bluescreen" (excusez ma nostalgie d'ex-codeur en QuickBasic), la solution devient évidente: introduire une classe "CommonGob" qui regroupe tout ce dont SimpleGob et CompoundGob auront besoin dans leur fonctions "play" sans toucher au GameObject héréditaire endogène ... ce qui fera sans doute plaisir à BlockArea, accessoirement.

If you don't get a word of UML then ... well ... I guess the sketched-up version of a former, similar reflexion might help you to figure out what is this CompoundGob stuff all about.