Demo: Scorpeye, Apple, Water and Sand

A new demo appeared. At last, my checklist is complete (and sure, there are still many more things to write for a next list). The demo is still based on the "three rooms". Don't expect much more land to explore. I still have a few concepts to prove before I can do that.

Enfin direz vous, et je ne vous contredirai pas. Voici la nouvelle démo de mes travaux en cours sur Bilou's Dreamland. Toujours limitée à 3 salles à peine de 2x2 écrans qui servent pour expérimenter les nouvelles mécaniques sans passer trop de temps à courir jusqu'à la nouvelle fonction à tester. Mais pour la première fois, vous allez pouvoir nager, affronter les sables mouvants, lancer des carapaces. Et puis il y a toujours le rodéo d'éponge et le saut en encrier. Allez, quoi. Sortez votre linker et faites-vous plaisir :)

Compared to the previous demo, you can try

• the new appleman animations
• the collapsing platform (pyramid)
• the scorpeye shell (jump on the scorpeye, then grab it like you'd do with a blador)
• flowing sand, pushing you down the slopes
• improved swim mechanics, waterflow
  

tested on NDS Lite, desmume 0.9.11 and desmume 0.9.6

Feel like playing a real game ? Try my previous titles ;)

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 ;)

Dans le .zip

 

Pour faire ses propres personnages sur la Nintendo DS avec mes outils, il va falloir commencer par les images. Voilà l'écran d'accueil de l'éditeur d'image de dsgametools: SEDS. Dès ce moment, il est prêt à dessiner sur la grille de 32x32 pixels présentée au milieu de l'écran. Il y a pas mal de choses qui peuvent se gérer avec l'écran tactile, et pas mal d'autres qui marchent mieux avec les boutons de la DS. On en rediscute tout à l'heure.

C'est parfois plus facile de se faire la main en modifiant une image existante qu'en démarrant de rien, donc suivons ce qui est recommandé sur l'écran du haut: appuyons sur START pour passer sur l'écran de chargement et regardons un peu ce qu'il y a dans les fichiers du répertoire Démo du .zip

Nous voilà dans l'écran de chargement touche le mot "browse" au stylet pour explorer le contenu de la carte mémoire plus librement.	L'exploreur montre \moving\*.spr par défaut. pas de défilement ici, mais si nécessaire, on peut filtrer les fichiers et répertoires affichés avec l'alphabet dans le coin. Appuyer sur "I" par exemple montrera tous les fichiers commençant par I. Pour les lettres paires, il faut maintenir le bouton L enfoncé pendant qu'on touche la case.
bg.spr contient quelques blocs libres de droit pour faire des petits décors de niveau de jeu de plate-forme	hero.spr contient un petit père Noël, également libre de droit. Notez qu'en le chargeant après bg.spr, on a encore en mémoire un "fantôme" du fichier précédent. Pas terrible ici parce que les deux fichiers utilisent des palettes différentes, mais ça peut s'avérer utile dans certains cas.

Bien. Maintenant qu'on a choisi le fichier et la page qui nous intéresse, on peut appuyer sur START pour retourner dans l'écran d'édition (ou pointer le mot "Draw" en haut de l'écran tactile, en fait).

Les blocs dans ces fichiers sont en 16x16, la grille est un peu différente qu'à l'écran d'accueil, mais le principe reste le même:

• Toucher une case la remplit. 
• Toucher une case de la grille en maintenant L choisit cette couleur sans changer la case.
• Toucher une couleur dans la palette la sélectionne.
• Toucher un bloc dans la "table" à droite le copie dans la grille
• Toucher un bloc de la table en maintenant L y copie le contenu de la grille
• Presser la croix vers la gauche ou la droite nous promène dans la palette de couleur ("bien pratique pour les dégradés")

Une fois les modifications terminées et ramenées sur la table, on peut appuyer sur START pour retourner à l'écran de chargement. Là, presser sur les boutons R puis A va enregistrer les modifications dans le fichier de travail "spriteA.spr", R puis B dans "spriteB.spr", idem avec X et Y. Appuyer deux fois sur R réécrase le fichier qui avait été sélectionné au départ.

 

Sand "waves" completed.

Bien. Ce coup-ci, je pense qu'on y est enfin. Le sable tombe, il fait un petit tas, le tas croule le long de la pente, puis se "dissout" au moment d'arriver à la chute suivante. ça reste "mode démo", celà dit: le code pour la pente à contresens n'a pas été testé et la longueur de la pente est hard-codée dans la "l'animation" de la vague qui descend. Mais ça fera l'affaire.

At last. Sands falls down, piles up, flows down slope and then falls again. The illusion is complete. The code is partly production-grade, partly demoshow-grade. Just what I need for a new release of the 3-rooms demo ... if only there wasn't that just-popping-up bug in the School room >_<

Ciao, Lime ?

Depuis plus de 10 ans, c'est surtout ma DS colorée "Lime" que vous voyez. C'est elle qui sert à dessiner des nouveaux pixels avec Sprite Editor, c'est elle qui a l'éditeur de niveau à jour pour 3-rooms. C'est encore elle qui va m'aider à faire des animations pour les nouveaux personnages.

Mais là, pour les derniers ajouts pour avoir du sable fluide, Lime me lâche. Son trigger gauche ne répond plus qu'occasionnellement, or il est absolument critique pour tous mes outils. C'est lui qui fait la différence entre "CTRL+C" et "CTRL+V" dans l'éditeur, la différence entre "pipette" et "pinceau" dans SEDS. La différence entre "charge en mémoire" et "enregistre sur ma carte SD" dans runme. Le bouton "L", c'est mon clic droit.

Hold the L trigger in one of my homebrews, and you're swapping between "pull mode" and "push mode". You pull a colour out of the SpriteEditor grid. You push a sprite into a sprite page. You push a colour into the palette, etc. Hold the L trigger on that Lime DS I've been using as gamedev unit for about 10 years and ... nothing happens. I want to pull the colour of a pixel and I push the current colour to that pixel instead. I want to push something to the sheet and I pull the older contents instead. Same if I try to pull the current tile of some spot of a level: I end up pushing the last used block instead. No need to say that this made the last step of "fixing the sand falls" super exasparatingly tedious.

Ce n'est pas la seule, bien sûr. Il y a aussi DarkneSs, qui était numéro 1 pendant AppleAssault mais qui depuis sa chute a pris plus le rôle de distracteur d'enfants mais pouvait parfois ressortir quand un test un peu plus audacieux (nouveau devkit, p.ex.). Un petit swap de linkers, un changement d'adresse IP dans mes commandes de transfers par WiFi et la voici prête à prendre le relai et poursuivre le marathon.

Les réparateurs de DS sont plus rares que dans les années 201x, évidemment, mais mon frère a pris pas mal de galon dans ce genre d'entreprise. Je garde espoir qu'on puisse remettre cette console photogénique en selle d'une manière ou d'une autre. Ses écrans et sa batterie étaient encore parfaitement opérationnels. Ou a défaut lui trouver une remplaçante.

Hopefully, that does not kill all hopes of seeing more homebrew contents from me. I still have my DarkneSs unit and its triggers seem all fine. Just swapping the linker cards, changing an entry in my IP addresses list and it's ready to take over the tasks. I have hope that the faulty trigger of Lime can be fixed, and my brother even offered a third option just in case (I'll have to find a name for a grey device, if we pick that up. Mithrandir might do)... Wait and see.

(Et pour faire bonne mesure, voilà la coque de protection de ma liseuse boox qui tombe en morceaux :/ )

Sand falls

Il faut bien l'admettre, dans toutes ces animations de Bilou qui est repoussé par les chutes de sables et de décor en pseudo-3D réalisé à grand coup de HDMA, la chute de sable tout en pixels statiques, ça ne rendait pas particulièrement convainquant. C'est donc maintenant ma dernière étape avant une petite riliize de ma démo 3-écrans.

Anokolisa mock up, initial reference

Almost every time I posted a video about Bilou being pushed by sandy slopes or about the pyramid background 3D scrolling, I couldn't help being sorry for the flat, uninspired, unanimated sands fall that are present since the first release of the 'three rooms' demo. That's the last thing I want to fix before I release a new one.

ça fait un moment que j'avais ce mockup d'Anokolisa parmi mes images à étudier et j'avais même quelques gribouilles assez réussies de comment ils étaient construits ... mais vous en conviendrez, du miel et du sable, ça ne s'écoule pas granchement de la même manière.

J'ai fini par retourner regarder les graphismes de la Sandopolis Zone dans Sonic & Knuckles ... qui au final étaient assez simples de ce côté-là: un cycle de 4 couleurs dans la palette, un tramage par-ci, une rangée de pixels transparents par là ... j'ai essayé de m'en inspirer et ça rend assez correctement pour une première démo, je trouve. Il me reste encore à animer 'le sable qui descend le long de la pente'. Voyons si le week-end m'offre le temps de faire ça ;)

But it is a bit tricky to find good pixelart reference for such item. For quite some time, I thought I could use something inspired by Anokolisa's Hive tileset, until I realised that it would never flow like sand, no matter how close I could get from that brilliant design. Neither Souldiers nor Megaman could help, but I finally remembered about Sonic's Sandopolis Zone, burried in early reference hunts. A quick check on youtube convinced me that, once in motion, they are good looking. Their design is quite simple, though: wavy patterns of 4 colours that will be palette-cycled. When they have to become half-transparent, non-solid tiles, they are alternated with empty columns or dithered with transparent pixels. That's enough for a CRT screen, but I will likely require something a bit more subtle for the LCD screen of the Nintendo DS. Well, my pattern is more angled, but it seems to be good-looking enough, given mastodon reaction.

Now I have to aslo animate the slope itself, but checking Souldiers again, I believe I might better spawn waves periodically and let them roll down a static ground than trying to animate it all as I did for the sand falls (scoop: I'm not using palette cycling this time)

Appleman 2.0

Bon, je me suis enfin refait les animations de l'Appleman dans l'éditeur d'animation modulaire. C'est que déjà avant que je ne m'attaque à Apple Assault, j'avais dans l'idée que Bilou puisse ramasser le corps de l'Appleman pour s'en servir ensuite de projectile. Puis c'est plus cohérent avec le comportement de dumblador qui joue le même rôle dans la School Zone.

Sauf que, vous vous en doutez, ça ne s'est pas passé sans mal. D'abord quelques plantages de MEDS (oui, encore) qui m'ont obligé à tout refaire, puis le niveau qui ne voulait plus rien charger le temps que je lui réexplique où se trouvent les animations demandées et que je corrige celles qui étaient lues en boucle alors que la machine d'état prévoit une transition "à la fin de l'animation".

You could easily claim that this was a cursed sprite and I would almost believe you. See, I've had applemen pixels from over 15 years now, and yet I wanted to upgrade its motion into a compound sprite. The idea would be to make it more like the dumblador, losing its feet when stomped, staying stunned until feet are recovered etc. I expect that it would feel fun...

Then the curse started, with blue screens in the editor as I tried to "clean up" some animations, despite I fixed something similar in September. Then the level would no longer load because some of the newly defined animations were looping and AppleAssault assumed it could wait for them to be done for some transition. And when all that was fixed, with WiFi transfers over RunMe through the NUC, the appleman did not have feet but huge, purple fists instead.

Ensuite, voilà que les pieds de l'appleman sont remplacés par des gros poings mauve alors qu'il devrait réutiliser les pieds de Bilou relookés en brun. La faute à un code encore un peu trop jeune dans le chargement d'un 2eme fichier de graphismes. Les couleurs erronées, ça, ça m'aura pris plus de temps. Je me replonge dans le code d'il y a 2 ans, je vérifie qu'on a bien assez de mémoire vidéo pour charger tout ce petit monde (scoop: oui. On a 16KiB, assez pour 8192 couleurs alors que les 16 palettes accessibles par les sprites n'en consommeraient que 4096)

To get proper images, the first thing is to ensure SpritePages are properly remapped when loading the additional set. For the school zone, that was done with spr.more "school.spr" page8,82 meds+4. Yeah, I know. That's not the most self-documenting line of script in the world ^^". What's important here is page8,82. That is controlling the remapping.

• The first number (8) indicates that we expect Bilou.spr to feature 8 sprite pages, and that pages for "school.spr" are to be numbered 8, 9, 10, ...
• The second is not a number: it is a series of digits each identifying a page, and each telling where each page is starting with the 8th slot. Page 8 remains unchanged (since the series starts with an 8), but page 9 will use page 2 instead (where Bilou hands and feet are)

That was for the school zone, but the green zone spriteset did not have hand and feet. Instead, they had to be added as the 11th page within the set ... almost page 20 for the level. Code parsing that was a bit crude too and was never meant for things identifying page number higher than 10. Oh, you could do it, but you might have to identify page 11 in the whole set with ;. I tried to simplify that a bit so that we can actually use spr.more "green.spr" page8,-..---.----2 meds+4 instead. Here,

• every - in the sequence means "that page holds no sprites. It shouldn't be used by animations".
• . means "don't touch: that page is perfect as it is". Any sprite page in green.spr has such a dot.
• And you know about the final 2 already: it identifies one page within bilou.spr that must appear instead of a "draft" page of green.spr and be used by Appleman animations

Definitely, some colors from green.spr were loaded here. We wouldn't have the sprite-branch with colours that close to those of the trunk otherwise. But the yellow worm now has weird blueish outlines and the appleman feet are both light-Bilou-green rather than having one dark brown and the other darker brown. 

Et là, la raison était plus ... exotique, on va dire. Le code C++, rien à redire. C'est presque limpide: ça *doit* ajuster les commandes qui définissent les images et palettes utilisées par les personnages, à condition que le décalage soit correct. Et le décalage, je fournis à la main dans le script du niveau. Mais manque de bol: le compilateur (gcc 8.1.0 ajouté à devkitARM 49 en 2018) produit du code machine qui ne correspond pas à ce qu'il me faut (une fois encore). Vérification faite, le gcc 10.1.0 du devkitARM 54 ne fait pas mieux. Pour avoir enfin mes bonnes couleurs, il faudra que je réexprime mon code différemment pour contourner ce qui semble être un bug dans le générateur de code ou dans l'optimiseur ...

There's a line in the remapPages() function that should deal with that: find "change sprite" instructions in the animation code, isolate the current palette value and add the "adjust palette" computed by the caller. It should work, really, but single stepping through the code with all the optimized-away locals left me puzzled. So I dug deeper, taking notes of the machine code, tracking what register meant what and ... 0_0

and there was no add instruction to be found. Nowhere in the loop. The machine code generated by gcc 8.1.0 would just assign the same green_palette[0] to every sprite no matter what palette they were using. That seemed to happen with gcc 10.1.0 as well... it wasn't too hard to work around, but yet. Troublesome.