A few fixes

It should have been a calendar, and somehow I'm using it that way on the "recto" side. But it's a week-by-week calendar, which means it's also a near-A3 rigid laptop with good quality paper that I can use nearly anywhere to write notes about nearly anything. 

But I wouldn't be studying Turing processors this week-end, nor how the 1st Pokemon game stored its maps. Instead I was trying to tackle two old bugs in my editors that affect loading new files in AnimEditorDS and leaving "monsters edition mode" in LEDS. It's not very impressive, but it's releaseversary day, so here it is anyway.

And, well, it seems like it's been nearly one year since I made a release of the Dreamland demo itself. Now that the "WIP" level in the greenzone -- the one I intend to keep and that has been historically the first Bilou level ever -- has an exit door, I can make some release for that as well. Enjoy

• water slides
• revised appleman mechanics, including the funny rolling throw
• connected doors
• smashing big punches

I'm sure there are plenty of bugs and glitches here and there. This is not a polished demo, more a presumably playable snapshot of the ongoing work.

 

 

 

 

Make it exist first,

You can make it good later. It's an ongoing meme in the gamedev community, and it's perfectly capturing what I intend to do with the "Green Zone" levels.  The map is very crude, most of the areas use repetitive patterns of the same block, it feels dull to "play" and I don't even have graphics for the key or the closed door ... but at least, I can check whether we can reach branches, cliffs, leap over holes and the like.

Il y a un meme qui est occupé à faire le tour des groupes "gamedev": un trait qui reboucle plus ou moins sur lui-même entourant un pâté de couleur accompagné de la légende "commence par faire en sorte que ça existe". En vis-à-vis, l'image d'un cercle aussi propre sur lui que s'il sortait d'inkscape ... avec la légende "tu pourras l'améliorer plus tard". Et c'est vrai que c'est assez pertinent: combien de projets ont tourné à rien parce que leur dévelopeur à cherché à atteindre l'inaccessible étoile trop tôt ? En plus ça colle assez bien avec le planning que je me suis fixé pour l'été: faire une version minimaliste de chacun des niveaux qui hantent le cahier-bleu-du-redesign pour voir si Bilou sait atteindre les différents objectifs ou si je dois envisager des mécanisme "d'aide à la conduite" du genre de ceux utilisés dans MainFrames. Et tant mieux si le niveau me sert aussi de bac à sable pour valider le fonctionnement des portes.

Files are being swapped back and forth between the computers and the DS, as I bring together the fixed bouncing branches, geysers and updated applemen. Unfortunately, the level editor is currently unable to show us invisible gobs (workaround: done), and with doors and branches, I start to have a higher number of them ... It also has restrictions on how to link items that I'll like to get rid of later on.

There's something though, that I don't really like about the current state. It's crude. There's no beauty in the way it looks. There's not much fun in the way it plays. Monsters feel placed randomly on uninteresting surfaces. The forever-in-progress "level two" -- with its geyser and huge trees -- makes me feel prouder than this.

Je transfère donc un script dans un sens, un spriteset dans l'autre, je passe du temps dans l'éditeur de niveau pour que ce "Green Zone 1: L'Arbre Creux prenne forme... Forme, mais pas vie. J'avoue que c'est un peu décevant cette austérité, cette absence d'objectif et de gameplay... et je me suis surpris à apprécier de retomber sur le niveau-en-chantier ou la salle de test qui me paraissent tellement plus accueillants bien que totalement inachevés.

Tools update

It'd be fun to try your editors! I'd probably do any serious development on a computer, but it's still cool to have an opportunity to try something I would've loved to have as a kid.

(Nova Storm, 7 February 2024)

I told you about Nova's work on NES and SNES already. Earlier this year, she shown interest into NDS homebrew and linkers, so I proposed her to try the dsgametools, and she replied with the heartwarming sentence above. My last tools release dates back from 2021, and while there are not that many things that have changed since, some annoying bugs were fixed nonetheless. So I went for a new package with some README, example files and PERL tools in addition to the .nds files proper. 

Salut les neveux. Si vous voulez tenter de faire des jeux sur Nintendo DS avec mes outils, vous êtes arrivés sur la bonne page. Téléchargez le .zip en utilisant l'image-lien ci-dessus et copiez les fichiers *dlta.nds à la racine de la carte-mémoire de votre DS. Tant que vous y êtes, vous pouvez aussi créer un répertoire nommé "moving" à la racine de la carte mémoire et déposer les fichiers présents dans Demo/efsroot/ du zip. On fait bien attention à ne rien effacer, on éjecte en toute sécurité, on remet tout en place dans la DS et voilà.

Level Editor: 

• fixing bugs with meta buttons;
• add support for special tiles used in conveyer belts and flowing water
• cosmetics: buttons with shadow and show when they are pushed
  

AnimEditor: 

• fixing 'apply to all previous frames' and 'apply to all future frames' buttons.
• only store thumbnails when the animation is used. 

runME:

• cosmetics: buttons with shadow and show when they are pushed 

SEDSdlta est votre éditeur de graphismes. Il permet de définir des palettes de couleurs et des pages de blocs 16x16 ou 32x32 qui seront sauvées dans des fichiers .spr. Ces fichiers peuvent ensuite être ouverts dans l'éditeur d'animations MEDSdlta ou dans l'éditeur de niveau LEDSdlta. Les niveaux créés par LEDSdlta seront sauvés dans des fichiers .map

Deux points communs dans tous ces éditeurs: maintenir L enfoncé pendant qu'on touche un bouton/une grille/une image à l'écran permet de faire une opération différente. Et appuyer sur L+R donne un peu d'aide.

These tools seem like they're very compact and full of features, maybe to the point of feeling a little bit cramped or unintuitive, though it's tricky to do something about that with this sort of screen resolution. I do appreciate the manual that you can access whenever to find out how to do stuff, and I'd rather have all the features than have a simplified tool. I liked the "scan" button in the sprite editor; that's not something I've really seen in pixel art programs.

I can certainly agree with that. It isn't rare that I have to dig my own blog -- or worse, the source code -- of AnimEDS when I want to do something a bit less frequent like copy a frame to a given position, create a new skeletton or adjust hit boxes. I'll have to complete the "L+R to get hint on how to use things" but it's good news that someone noticed it and appreciated it. Maybe it could be completed by a "please explain that control" mode where you can touch something on screen and learn about it rather than use it ...

I feel like it would help a lot to have buttons that bring up menus (especially on the animation editor, which needs more explanation than sprite editors do), where you'd have more room to make it clear what each option does or avoid needing button combos so you can fit more options on-screen, but that has to be weighed against how much it would slow down a user who knows what they're doing. You *could* have quick shortcuts with small icons alongside a button that brings up a menu that's less compact, though.

I have started something along these lines for 'monsters edition' in LEDS... That will be motivating to push it further

As you may have guessed, that lovely avatar for Nova comes straight from her website ;)

xmas21.zip

I finally posted something more on my sourceforge project: the set of editors (plus runme) as I've got them by this Christmas, invoking oven-hot slopes support.

I wish I could provide you with a meaningful 'change log' for this 'release' of my tools, but let's be

honest: there are over 20000 lines changed between then and now (assuming that you're only interested in what changed since last AnimEDS release in 2020). It won't be exhaustive, but I'll try to give you an idea of what's in anyway.

Sprite Editor

• allows you to work on any file you've got on your memory card (including automatic backups put in /DATA/SEDS/*)
• better 'colors zapping' implementation.
• 'where is that color used?' now cleanly implemented in the PaletteWindow
• (improved host tools sprdo and sprck are missing from this pack)

Animation Editor

• allows you to work on any file you've got on your memory card. 
  

Level Editor

• uses new map layout with dedicated PHYS layer (accidentally named 'SYHP' in the file >_>)
• show the 8 color palettes when selecting a block in DRAW mode (A). Color paint mode now available on both foreground and background layers (trigger with L+A on the desired layer)
• supports new any-sized special blocks with 'lookup arrows', features revised 'meta buttons' widget to select tile properties.
• reads new 'slopes %d = "%x"' hint in .cmd or .gam files and populates the slope tiles graphics accordingly. Different maps can use different slopes or share them by importing the same .gam file.
• supports spritesets and tilesets overlay commands

runMe (gameplay preview & WiFi transport)

• Allows live-skipping of buggy script lines
• allows auto-repair of the /moving/ directory
• features new level map engine
• supports script-driven song swapping with zik.file = "%s"
  
• Improved modplayer playback speed stability
• supports spriteset overlays (spr.more "%s" ...) and tileset overlays (bg0.more "%s" ...)

All these .nds files will work from anywhere in your flash card, but if you install them with their original *dlta.nds filenames at the root, you'll be allowed to hope from one tool to another with the embedded buttons (quit, LEDS, SEDS, MEDS) in the application welcome windows.

greent.map

Se pourrait-il que j'arrive malgré tout à avoir une démo "3 rooms" pour la fin de l'année. Enfin un premier jet. Le hic n° 1, jusque là, c'était la quasi-impossibilité de faire une nouvelle map propre. Depuis l'introduction de la branche newmap, l'éditeur de niveau ne savait plus le faire, mais j'ai fini par trouver ce qui n'allait pas

Maybe I'll have a 3-rooms demo by the end of the year ? Not with all the features working, of course. Expect static waterfalls and incomplete water physics, but at least a .nds where you could travel freely between the 3 environments I have so far. Until yesterday, that was hindered by a bug in the level editor that prevented me from creating new maps: I could only update existing ones. But that bug is now solved, so I started tiling 'greent.map' and 'schoolt.map' as I intended them to look like in my notepad.

Du coup j'en ai profité pour redessiner en 512x256 les niveaux-démos prévus, rajouter les palettes de couleurs que j'avais essayées pour les cascades. Il n'y a pas encore d'animations ni de physique de l'eau ... ce qui donne un résultat un peu perturbant (mais pratique pour aller voir ce qu'il y a d'autre sur le 2eme écran). Ouaip. c'est l'avantage de la Saint-Nicolas en quarantaine quand les enfants ont assez grandi. J'ai eu l'occasion de m'asseoir avec ma DS à côté d'un Gimp.

Then I went ahead, taking advantage of the 'woot-we-have-new-toys' while we're all locked-home by quarantine to open my earlier waterfall mock up and redraw that into SEDS.

I hope I'll be able to do the same with pyrat.map soon.

Loading more, in LEDS

Bon, les soucis avec le moteur de jeu semblaient réglés, donc j'ai voulu vérifier que l'éditeur, dans sa version 1919 (une petite révision en-dessous du code sur mon laptop) présente sur Lime savait bien modifier des choses sans perdre d'information.

Je me rends compte que tenter de re-charger un deuxième niveau dans l'éditeur conduit au mieux à un iScriptException, au pire à un crash à une adresse venant du void*. Entre les deux, un "bon vieux" crash comme sur cette photo, qui pointe du doigt la boucle interne à Block::getnext()

Le 'pire crash' contenait quand-même quelques adresses vers du code dans la pile et suggère de regarder du côté de l'appel à Block::append() dans Level::ScanSubFile().

L'affichage des miniatures dans l'écran d'accueil, c'était pas terrible non plus. Plusieurs fichiers avaient juste des têtes de Bilou partout. Une résurgence d'un problème que je croyais cru réglé ? (ça se produit essentiellement avec greent.cmd et ses SimpleGobs, on dirait)

On dirait bien que ce n'est pas trop difficile de reproduire le problème avec 'cmdck' pour peu qu'on lui ajoute un moyen pour charger un 2eme fichier de commandes. Un peu plus de mettre le doigt sur le problème, puisqu'au moment du SEGV, on est envoyé à une adresse invalide.

Un cran plus tôt, on voit une liste de blocs dont le dernier a une table de méthode virtuelle totalement farfelue. Et ça, pour le premier bloc à traiter dans 'ink.gam'. Mais il y a eu un autre fichier .gam passé en revue avant, et le bloc farfelu est de type 'END'.

Je refais un 3eme tour de programme, je surveille tous les ajouts de blocs spéciaux. Et en réalité, le bloc "end" s'auto-ajoute dans la liste. Du coup, faire un 'delete' dessus parce qu'il n'est pas du type 'spécial', ça casse forcément tout.

edit: un petit 'ledsdbug.nds' qui reprenait les modifications utilisées en Avril pour corriger les miniatures, je remarque du coup que les miniatures sur NDS essaient toutes d'utiliser le sprite #0 ... louche ... la modif 'Anykey()' ramenée aussi et je constate que la ligne 'spr.more' n'a pas été correctement traitée. La faute à une valeur incorrecte pour la correction des numéros de pages d'animations (ouais. C'est technique hein ? j'aurais peut-être juste dû parler de 'pageshift', comme dans le code ^^). Rien de ce genre sur mon PC et pour cause: le code de LEDS a inversé le pageshift lors de la dernière sauvegarde ...

Par contre, du coup, l'outil de test cmdck -s greent.cmd > /tmp/green2.cmd me montre que toute la première moitié du script n'est pas ré-écrite après le traîtement. 'va falloir que je ressorte encore ddd. Euh non. ça c'était juste une interférence entre fprintf(stdout) et fopen("/dev/stdout"). 'faudra que je sois plus prudent avec ça.

re-edit: une fois ce pageshift corrigé, ça ne marche guère beaucoup mieux. Les miniatures ne sont toujours pas chargées parce qu'il y a des valeurs complètement incohérentes à la place des numéros d'animations dans le fichier. En fait, le fichier tout entier est sans-dessus-dessous dès qu'on atteint la section des animations et des miniatures.

Et ce n'est pas la première fois que j'ai des ennuis avec ces sections. Je ne peux pas exclure que c'est parce que j'ai utilisé une ancienne version de SEDS ou MEDS sur Lime. Mais je ne peux pas non plus exclure qu'il reste quelque-chose à corriger dans les éditeurs. (les éditeurs en version finale sont clean. Mieux: AnimEDS est capable de corriger un fichier foireux rien qu'en l'ouvrant et le re-sauvant).

re-re-edit: avec un fichier .spr valide, il me restait deux soucis à résoudre dans LEDS:

• éviter les crash si on pointe dans le vide pendant l'édition des monstres (MonsterPropertiesWindow n'était pas prêt pour ça). Un 'simple' pointeur NULL, mais qui attire mon attention sur le fait que le hardware de la DS autorise qu'on lise à l'adresse 0 (en fait, tout une page de 32K).
  
• avoir un affichage correct des miniatures produites par AnimEDS, et pas cet espèce de potée aux pixels que l'on voit pour Bilou. un simple '+2' qui manquait dans la version qui tournait sur DS.
  

Mais c'est compris et réglé pour attaquer le dernier week-end de congé. 'faudra que je note de comprendre pourquoi mon curseur de monstre a re-disparu, par contre.

DJLN.cmd

Faire des niveaux sur papier, ce n'est définitivement pas une activité à proposer à mon fiston. Au mieux, je peux lui proposer de me dicter un niveau que je ferais moi sur papier.

Par contre, prendre la Nintendo DS de papa et ajouter des blocs ici et là, ça ça lui plaît bien. Mais pas de chance, la branche "newmap/newmeta" n'est pas encore stabilisée au point qu'on puisse tenter de jouer au niveau ainsi construit.

Assez surprenemment, mon nouvel écran de patching m'indique que l'erreur se trouve sur la première ligne de pyram.spr, CMAP n'étant pas une commande valide pour les scripts. Enfin, ça c'est sur émulateur après avoir récupéré les fichiers présents sur DS avec le wifi remis en service.

En fait, ce serait la commande spr.more "pyram.spr" qui n'a pas été comprise par l'éditeur de niveau. Du coup, au moment de sauver, il en fait un input "pyram.spr" Si j'en crois les numéros de version, le bug a déjà été patché, c'est juste que la DS n'avait pas pu profiter de la nouvelle version. C'est J.L.N qui va être content...

• invoking autoexec.cmd with the [run] button does not seem to allow PatchWindow to be invoked.

spr.more in Level Editor

 

ça n'aura pas été simple de recommencer à avoir des représentations des monstres correctes dans le Level Editor. J'aurais probablement dû utiliser mon "autoexec.nds" pour le coup, mais j'ai procrastiné ça en insistant que 'nan, mais j'y suis presque, là'. J'aurais aussi eu plus simple si j'avais eu un affichage de la VRAM 'brute' dans mon émulateur, mais je n'ai pas encore ça non plus. Ou éventuellement un 'print' qui se mette à jour d'office.

Là, j'ai pu corriger pour que spr.more ne perturbe plus le chargement du 1er spriteset, mais je dois encore chipoter pour le 2eme. Je pensais que c'était lié aux arguments de la commande, mais en réalité, ils n'ont pas d'impact si on ne joue pas les animations.

Mais les dernières ruses que j'ai dû déployer pour que ça fonctionne (notamment un champ additionnel 'meds+%d') me mettent un peu mal à l'aise. J'ai l'impression que c'est le signe que le mécanisme spr.more n'est pas au point et demande de trop connaître son comportement pour pouvoir s'en servir.

edit: près d'une semaine plus tard, je finis par mettre le doigt sur le dernier problème. Une commande destinée à introduire une animation pour 'SimpleGob' dont j'ai changé la syntaxe dernièrement sans penser à changer la syntaxe aussi dans le parseur de l'éditeur de niveaux.

Donc, l'éditeur de niveau est prêt (mais pas encore uploadé), l'éditeur d'animations est prêt aussi (allez, je les uploade tous les deux sur le cube), les fichiers .spr sont corrigés (sur la DS aussi, je crois) ... On dirait que je vais depouvoir commencer à faire des maps pour Dreamland ?_?

La bonne nouvelle c'est qu'au passage, j'ai doté cmdck de nouvelles fonctions pour me montrer le contenu des tables régissant ces vignettes sans devoir faire appel à l'émulateur (?thumbs, ?page, ?states)

Direct Flags

Signing in for a 7-days trial of the Nintendo Online sure affected how I used my hobby time these last days. But nevertheless, I could do some homebrew coding, and it was for the level editor.

You may recall that I'd like to introduce 'direct flags tiles' in the engine. The idea is to enable any combination of some very basic properties like "can be swum through", "can be climbed on" or "can be fallen through" within the level by dedicating 64 tile types where the 'type identifier' part is used as a direct set of flags for those properties.

Une des idées avec la révision du monde de Bilou, c'est de pouvoir permettre à certains tiles de définir directement les propriétés physiques à appliquer. Dans Apple Assault et School Rush, chaque numéro de tile fait appel à un lookup dans une table de correspondance pour connaître les 'flags' à utiliser dans cando(): ça, c'est l'encodage indirect. (ça vous rappelle vos cours d'assembleur ? c'est normal). Un quart des types de tiles seront maintenant dédiés à ce fameux encodage direct, qui permet notamment d'exprimer n'importe quelle combinaison de 6 propriétés fondamentales comme "permet de tomber", "permet de nager", "peut être escaladé", etc.

Yet, that's only efficient if you don't have to come with 64 custom editor art for them. And that was only possible with a few changes to my MetaFlags widget and the surrounding code:

• paint color for 'environment type' tiles 
• on/off switches for those tiles in MetaFlags
• auto-generate combined tiles for combined environment (e.g. CAN_SWIM + CAN_CLIMB)

"auto-generation" works by painting the the 'pure' tile with the highest bit, then painting over the lower-priority bits. So if you swap the order of  all-blue CAN_SWIM and some-green CAN_CLIMB, you won't see that you can do both anymore.

Jusque là, c'est bien beau sur papier, mais dans l'éditeur, comment représente-t-on que le bit 4 est utilisé pour l'eau et le bit 3 pour l'escalade ? Eh bien à travers le fichier .gam, bien-sûr. Celui qui contient déjà des commandes "block {}" pour tous les blocs spéciaux (bonus, clés, portes, etc.). Comme leur nombre a été réduit à 64, je peux utiliser une partie des numéros pour décrire 6 graphismes de base (un par propriété fondamentale). La chaine hexa sert toujours à définir l'image à afficher, le nombre qui est derrière la couleur à utiliser (le noir pouvant servir à 'effacer'). A partir de ces images de bases, l'éditeur générera les combinaisons possibles.

It's far from perfect, especially because I still have to override that for the tile that says "plain air here, sir". But I realised it was merely an optimization over the 'indirect' tiles, and premature optimization is the cause of so much bad things ...

*but* I can manage to get some clean output if I define 'flags' in the .gam file. Especially, knowing that meta-tiles are alpha-rendered, meaning that any black color turns transparent, whatever their palette indices. 

*edit* And the reason why so many levels I edited lately would have buggy 'empty' tiles rendering is that this "rush.gam" file I modified for the snapshots is only used in two levels so far.

makechar(BG_GFX, digit[i])

Bon, j'avais des affichages curieux dans LEDS. "où sont passé les pentes et les blocs jump-through" disait mon calepin. Eh bien ils étaient toujours bien là. Simplement pour les voir, il faut qu'il y ait quelque-chose au bon endroit dans la mémoire vidéo de la DS. Et jusque là, le code d'initialisation n'avait pas suivi l'évolution de la branche "newmap". Le niveau était donc bien converti mais les codes 0x81 pour "est une pente, type 1" n'avaient droit à aucun dessin.

Mais je n'ai pas sucé ça de mon pouce. Pour y voir clair, j'ai bricolé une p'tite table de caractères hexa en 3x7 pixels qui sont ensuite combinés pour faire 256 tiles dont le dessin indique le numéro.

I started getting weird effects in LEDS on the 'newmap/newmeta' branch. Special blocks and plain blocks seemed to work fine, but everything in-between (shadows, slopes, jump-through) was missing. Or so it seemed. They were actually still present, but invisible because the pixels to render them was still on the 'old codes' rather than on the new ones. I got it confirmed once I introduced a small loop that primes all the tiles used by the meta-layer with two-digit hex codes stating explicitly who's who.
 Unlike the legacy 0-3 codes, these are not meant to be shown to the level designer. As soon as we load the level, effective tiles will be filled, for instance using the 'symbol' statements.

Contrairement aux anciens codes, il n'est pas prévu ici de les conserver à l'écran: pendant le chargement du niveau, tous les codes utilisés seront remplacés par les symboles définis dans "rules.gam". Seuls restent affichés à coup de codes hexa les types de tiles "inconnus" -- ici les 00 qui servaient à "pousser" les personnages par-devant tous les plans de tiles et la pointe de crayon inversée.

Par contre, du coup, les "méta-boutons" deviennent beaucoup plus vides ^^"

Et comme maintenant je suis en mode multi-palettes pour tous les rendus de graphisme du jeu dans l'éditeur de niveau, j'ai les coudées franches pour redéfinir la palette principale, toujours utilisée par les plans "16x15 couleurs". C'est fondamental vu l'affichage du meta-layer en alpha-blending: utilisez une couleur non-définie (donc noire) et le truc est invisible. Prenez du blanc, et l'alpha blending sature.

Ok, c'est à peu près aussi passionnant que l'avancée des négotiations fédérales belges. Mais si je ne me remets pas ce genre de chose au frais en tête, je n'ai aucune chance d'avancer sur du homebrew. Et si je le fais, il est 23:37 quand j'ai fini ^^". 

C'est pas terrible pour la lisibilité des méta-boutons, par contre. Je vais leur donner une palette rien qu'à eux avec des couleurs bien EGA pour qu'on ne les loupe pas, du coup.  Puis j'irai jeter un oeil à la page du projet "Méta-Boutons" aussi, pour voir ce que j'avais envisagé pour passer les valeurs "inutilisées", parce que là, ça serait assez désagréable à utiliser (1 à 2 tiles utiles par "page" de boutons ... bof)

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

En couleurs

 Un dernier p'tit bout d'code pour finir les vacances ... J'ajoute à LEDS la possibilité de peindre aussi bien le décor d'avant plan que le décor d'arrière plan.

En dehors des détails d'organisation (on passe tout par le "Meta Tile" qui indique les informations à remplir quand on touche le niveau quelque-part), je me suis retrouvé à plusieurs reprise "coincé" de par le fait que seul un plan de tiles était prévu pour fonctionner en mode 16 palettes jusqu'ici.

There has been more wall-painting than tile-painting these holidays, but walls are now white enough and I can pick up my notebook and start applying those changes.

On a 'software architecture' point of view, selecting the colors will be the responsibility of upper-screen's "TilesetWindow" (that's where I have room for it). Which color is selected isn't explicitly delivered to MapWidget (that paints tiles on the bottom screen). Instead, it is directly encoded into the palette bits of the recently refactored MetaTile structure that captures what blocks we want to write while drawing.

Then I realised how much the code base was unprepared for my plan. Only one layer on the bottom screen effectively had 16 palettes to use: the 'front' layer of tiles replicated the palette #0 on all slots (so that it could pretend to ignore physics info in palette bits). Things were hardly better on the upper screen, where the GUI engine itself had no idea of how to enable multi-palettes.

Il aura fallu faire sauter certaines limites (style une copie de 16 fois la première palette dans la mémoire de l'avant-plan) et ajouter le support multi-palettes sur l'écran secondaire, chose que GuiEngine ne supportait pas encore jusqu'ici. Et comme vous pouvez voir, j'ai du chipoter pour ne pas perdre le "fond à carreaux" qui permet de savoir dans quel mode d'édition (dessin, copie ou recolorisation) on se trouve.

Il y aura aussi un peu de refactoring à faire du côté du widget "cursor": je ne suis pas convaincu par la manière dont on doit re-manipuler ses coordonnées et forcer des setxy() pour implémenter des actions spéciales en cas de débordement d'une zone donnée. 

 Y'a des trucs pas encore très nets avec le mode "édition de monstres", par contre...

Well, there we are now. I still have to give it a spin on real hardware, and fix the switch to grey checker when editing monsters, (done) but we should be close to a usable editor for the newmap branch.

Look at them colored replicas of the selected tile, on the right of your tileset. Ain't them sweet ?

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.

Détection automatique des pentes ?

Bon, j'ai réglé les problèmes de corruption de niveau dans la nouvelle mouture de l'éditeur (grâce à FakeMetaWindow) et on va pouvoir passer à la suite. Par exemple commencer à ajuster les "méta-boutons" pour qu'ils permettent d'utiliser directement les nouveaux types de tiles.

Parmi tous ceux-là, il y aura les nouveaux types de pentes, et si on doit commencer à jongler avec 64 types à la main, on ne risque pas de tenter beaucoup de fantaisie là-dedans. Du coup, je me disais: comme j'envisage déjà de juste copier-coller des tiles dans une 'sprite page' spéciale pour définir les types de pentes, est-ce qu'on essaierait pas de faire un système qui reconnaisse automatiquement la pente la plus proche quand on passe le stylet sur un tile ?

Une répétition pour le scribble widget, en somme.

edit: si l'idée est sympa pour un peu cogiter le soir, en revanche il est clair qu'un système de ce type ne pourra pas atteindre 100% d'exactitude, et qu'il me faudra de toutes façon un widget pour corriger les p'tits défauts de l'auto-slopeur... donc l'approche pragmatique sera de commencer par ce widget et d'ajouter l'auto-slopeur uniquement par après.

fakeMetaWindows

Bon, après un week-end assez "rock and roll", j'ai fini par pouvoir essayer un peu mon nouvel atout: un exécutable NDS alternatif pour la mise au point de l'interface graphique de LEDS. Parce que débugger SEDS c'est déjà pas rigolo mais il n'y a que "START + L + A" à taper pour charger un fichier. Dans LEDS, ça se fait avec les p'tits widgets d'exploration de répertoires. On clique par-ci, puis par-là, puis enfin l'émulateur charge le script principal, les spritesheets, le niveau. Et là tu peux faire A, réactiver tes breakpoints et commencer à débugger.

Mais ce sera bientôt du passé. J'ai pu extraire en tous cas les dépendances de la "MapeditWindow", la "fenêtre" principale à travers laquelle on voit et modifie le niveau dans une structure qui lui prépare un niveau rien que pour le test qu'on pourra faire défiler, modifier et pour lequel on pourra aller regarder le contenu de la VRAM pour s'assurer qu'on a bien affiché ce qu'il fallait à chaque étape.

Et ce sera bien utile, parce que là, tout de suite, je me suis attaqué à "permettre de masquer/afficher les boutons qui définissent les propriétés des tiles sans corrompre le niveau, mais du coup, je casse le niveau dès le départ >_< Vous le voyez, ce gros pavé jaune dans la zone "radar"? et toutes ces petites flèches noires sur l'écran du bas (par-dessous le texte de debug blanc, c'est difficile, je vous le concède) ? Bin c't'un bug.

un p'tit pas de plus pour LEDS

 Bien. J'ai donc un éditeur de niveau capable de faire l'affichage des niveaux même quand j'utilise le "nouveau" format. Y compris pour les blocs spéciaux. J'ai encore un peu de travail à faire dessus (notamment faire en sorte que les boutons à droite de l'éditeur ne s'incrustent pas dans le niveau chaque fois qu'on les invoque), mais c'est plutôt bien parti.

Avec tout ça, et l'introduction de nouveaux types de pente, je me dis qu'il deviendra bien utile de pouvoir faire des cas de tests sur des micros-niveaux, avec un système capable de détecter qu'on arrive bien à passer les "obstacles" quelques soient les variations de conditions initiales (légèrement plus à l'ouest, vitesse qui n'est pas un multiple entier de pixels, etc.) sans pour autant entrer en contact avec les blocs supposés en dehors du trajet.

If I want to be effective with introducing more complexity in the sloped-ground engine code, I think I'll have to add some more unit-testing. I've learnt the hard way that sub-pixel initial position, interaction with step-motion and animation quirks can lead to broken slopes code, and that debugging that takes lots of time because it needs parts in-engine breakpoints and parts in-debugger breakpoints.

A micro-level with a few simple slope scenarios, easy control on the initial state that can be automated should help a lot. And help is welcome. Plus, it makes support for those slopes independent from Level editor updates, which is welcome as well.

Si ça peut sembler une perte de temps, vu que je n'ai encore aucun moyen d'ajouter des nouveaux types de pentes dans LEDS, ça ne serait peut-être pas si mal. En plus, dans un niveau comme celui de *deline, il est assez inconfortable de vouloir vérifier si la logique du code de gestion des pentes fonctionne bien comme prévu, parce qu'on est en permanence interrompu par ce que les autres "personnages" du jeu font.

Ça pourrait aussi être l'occasion d'introduire un truc qui me titille depuis un moment: une série alternatives de constructeurs pour les objets principaux du moteur de jeux (déclarateurs de blocs spéciaux, états du comportement des personnages, zones de collisions, etc) qui ne passent pas forcément par une analyse de bloc de texte ... et seraient donc un premier pas vers la possibilité de "compiler" du gobscript en code C++ (ou assembleur 68000 ?)

tempting to use that as an excuse to introduce an alternate set of constructors that could build objects without necessarily having to rely on text parsing. Like state.Using<GobWalkerController>("") rather than relying on "using walker;" processed by GobState::parse(). That would be handy for GBA or 16-bits ports of the engine, but it isn't easy to achieve with the current codebase, unfortunately. The core reason being that classes for the controllers are encap~insulated into a separate .o that was meant for 'dynamic linking' with the engine 'happily ignoring they even exist', except through a std::map of factories that can be invoked by controller names.

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 ?

[done] remove import statement

Bion. Voilà une chose de presque faite. On pourra donc faire le nettoyage des commandes "import" (définissant les ennemis, etc) directement à partir de LEDS. De quoi permettre un peu plus facilement de passer d'un type de niveau à un autre en mode 'gamedev nomade'.

Je suis encore loin d'un outil qui soit "game-jam friendly": c'est pas avec SEDS+LEDS que vous allez remporter la Ludum Dare (mais si vous y arrivez, postez-moi le lien vers votre jeu, hein ^_^), même comme ça. Et avant de mettre ça sur ma DS, je devrai au minimum prévoir un message du type "êtes-vous sûr" ([done]), parce qu'en revanche, je n'ai encore rien pour permettre de rajouter des blocs définissant les machines d'états (ou autres) dans LEDS ^^"

---

Ah. Vous êtes toujours là ... je vous dois peut-être bien des excuses, du coup. C'est vraiment du micro-posting, je le reconnais. Le fait que j'aie commencé à parler de la feature il y a deux mois ne rends pas ceci beaucoup plus intéressant. C'était du micro-coding, aussi. Je dois m'y faire. Euh, bon, c'est vrai: je joue beaucoup à la switch ces derniers temps. Et j'ai repris une série de bouquins (Hyperion / Endymion) que j'adore depuis près de 20 ans, vu que ma collègue-et-les-méthodes-de-la-rationalité ne les avaient pas encore lus...

ImportsWindow::render()

Bion, la nouvelle garde-robe est installée ... j'ai eu un peu de temps pour regarder comment m'y prendre pour avoir les images des différents personnages du jeu sous le contrôle de la nouvelle "ImportsWindow" et en tracer les grandes lignes dans le code
[done] utiliser les ImportBlocks pour choisir quel état afficher où
[done] mettre en place une matrice de scaling pour les éléments secondaires d'une ligne 'import'
[don't] sauver les noms ? 

Je vous en raconterais bien plus, mais je suis à la recherche du truc électrique responsable des coupures de courant à répétition dans la maison ...

MonsterPropertiesWindow

At last, I've got a first working sketch of the 'monster properties window'. It turned out quite tricky to get it working. It can report whether gobs have links and initialization expressions in addition to tehir class. There still is plenty of work, like being able to actually update state when you use the widgets, and write an expression by using the customized 'TypeWord' widget featuring the full gobscript characters set.

Trickiness came from window-to-window communication, so that the right widgets got displayed at the right time (having to hide the whole "tileset" widgets)