symbol tables in GS3

J'ai bêtement égaré le carnet Atoma dans lequel je rassemblais les idées pour la révision de mon langage "Game EDitors Scripting" version 3 ...

C'est le genre de choses que j'y avais documentées. Souffrez que je ressorte quelques "brouillons" avec un minimum d'explications, du coup. (enfin, souffrez pas trop quand-même).

Heureusement, j'avais déjà un peu bloggé sur certaines de ces idées, notamment le choix des types de propriété pour les blocs et l'idée fondamentale de séparer l'encodage du type de sol et l'encodage de la pente, quitte à regarder un tile plus bas quand on veut savoir si le sol est glissant, collant, etc.  

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.

virtual tilesets

How should I handle tilesets larger than the 1024 tiles the NDS hardware is designed to use? Quick maths show that with 16K unique tiles, I'm already consuming 1MB of RAM. Full 16-bit tile identifiers would address the whole 4 MB of RAM the NDS has.

Unlike in Eric's games, I cannot assume here that the RAM is just a cache for the whole game data (ROM) because the game data may only be accessed through the SD card interface, abstracted through DLDI which -- afaik - - does not support asynchronous reads. And the score-table l implemented lately suffered noticeable lag while accessing the filesystem.

So there will be only main memory and video memory. Echoing what happens on x86 CPUs Virtual memory management, I'll use "logical" for the identifiers related to the full tileset and "physical" for the identifiers related to (temporary) video memory locations.The two functions that deal with translation between the two  sets of tiles are linked to the scrolling updates: since the level map is made of logical identifiers, we need logical-to-physical conversion there. The other(new) function kicks out trees that no longer need to be in VRAM.

I haven't really found a use for a physical-to- logical map. And all my plans for a smart combine-bitmaps system to decide which tile to evict fell flat when I realised it would be smaller to just keep an integer counter for every physical tile. So I will avoid over-complicating things and just go for the array of counters.

I know the logical-to-physical map could use a hash table implementation. It would have at most 1k items present, i'd say that means the main table should be at least 2k entries large. One important thing to consider is that we will have to remove items quite often, which means resolving collisions with chained list would work better than by using the next available entry in the table. Especially given that we will likely find consecutive tiles present, for instance when we have a large structure on screen. Good thing is that since there is an upper limit to the amount of items present, we know an extra 1 k entries for the chained list with always be enough.

Now, one entry in such a table is at least 16-bit logical id + 16-bit physical id + 16-bit next pointer. that takes us close to 18kB for the table, while a plain array of physical identifiers indexed by logical id would take at most 32 kB. Granted, the diffeence is critical for SNEs deving, and likely significant for GBA deving. But here? is it really worth the extra memory lookups ? Is it worth doing divisions to get a good hash function? We'll look into that if I ever need more than 8192 unique tiles in a level.

definition files in geds3

The refactoring keeps going. I'm about to show the "load a map" feature, and then I'll have to show "how characters interact with the ground through properties".

Meanwhile, I'm digging what sort of additional definitions a "Behaviour Editor on DS" should read, and how that would be translated into .h files that convert the "level 2" scripts into plain "level 0 scripts" that can be parsed by the runtime engine on the DS. I'd allow e.g. BEDS to do more lookups in symbol tables while all symbols should normally be translated into values or expressions in level 0 when loading levels in a game.

Maybe you wonder "but what is level 1?" ... well, level 1 is what I'm doing right now with Bilou School Rush, with the C pre-processor expanding symbols for us so that I can write "$RUNLEFT->$RUNRIGHT on eDpad [D_RIGHT]" instead of "statl12->statr13 on event0 [v2 $20 &]".

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.

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.

Behaviour Edition ... brainstorm

Prochain outil pour le projet "dsgametoosl" ? Je ne sais pas encore. Mais j'aimerais beaucoup construire quelque-chose qui permette de manipuler les machine d'état définissant le comportement des personnages dans les jeux qui tournent sur mon moteur "geds".

Quelque-chose à moitié graphique (je clique sur un bilou en train de sauter, on me montre tous les états qui sont accessibles depuis celui-là. J'en choisis un, je vois les conditions et les actions annexes pour la transition correspondante si elle existe), et à moitié texte (je peux en éditer une ou en créer une nouvelle, sans s'embêter, rien qu'en écrivant les expressions que je veux).

Quelque-chose de pratique (je clique sur une variable, je vois tous les états où elle est manipulée).

Pour permettre la réalisation de "School Rush", j'ai introduit pas mal de fonctions à coup de macros qui permettaient de "nommer" des tests du genre "est-ce que la direction choisie sur le DPAD va vers la droite ?" Pour que l'éditeur soit pratique, il faudrait qu'il permette de conserver ce genre de simplifications, et ne pas imposer à l'utilisateur de mettre dans chaque test "est-ce que le bit 5 de la variable numéro 3 est à 1?"

Du coup, l'éditeur doit à la fois savoir que l'expression utilise la variable 3 (l'état du dpad) pour qu'elle soit listée dans "toutes les expressions qui dépendent du DPAD), mais aussi qu'elle s'affiche avec un "DRIGHT". et pouvoir indiquer à l'utilisateur ce que fait DRIGHT au cas où ce ne serait pas suffisamment explicite.

ça demande d'une part de faire avec assez de précision le tour de tous les éléments de scripting qui ont besoin de pouvoir servir de "critère de tri", mais aussi de faire en sorte que le logiciel tournant sur DS puisse comprendre la version "évoluée" du script et puisse en tirer la version "interprétable par le moteur de jeu" pour essayer les modifications dans runME.

Un défi qui n'est pas à prendre à la légère, en fait. J'avais envisagé pendant mes congés de l'an dernier de refaire l'équivalent du préprocesseur de gcc, mais je me rends compte aujourd'hui que je suis parfaitement libre d'utiliser autre-chose que des macros C pourvu que je sois en mesure de produire le fichier voulu. Par exemple en produisant un fichier .h à partir de ce que le nouvel éditeur utilise pour connaître les variables, les compteurs, les types de collisions, etc.

Ce sous-projet m'intéresse pas mal, et commence à consommer de plus en plus de feuilles quadrillées dans mes petits carnets, même si je traîne un peu à blogger tout ça ces derniers temps. J'ai ma petite idée sur la saisie de texte (à mi-chemin entre pixel-art et reconnaissance d'écriture manuscripte), par exemple, ou  la possibilité de représenter sous une forme d'arbre les expressions mathématiques du style "v6 := min(v6 - 32 , -400)" qui s'écrit en GobScript "v6 32 - 400 ~ m :6" pour être plus facile à traiter par l'interpréteur.