Sprite Editor for DS : la photo

Bien, j'ai tout un tag pour les photos - les vraies - et dedans quelques-unes avec des prises de vues sympathique de mon éditeur de niveaux ou de l'éditeur d'animations que j'utilise depuis School Rush, mais une photo de mon "Sprite Editor" ? eh ...

Je ne peux pas dire "rien", mais ce sont des photos tellement vieilles ou ne montrant que partiellement l'interface. Il était temps que j'y remédie, même si je n'ai pas de développement en cours sur SEDS pour l'instant.

Would you believe it ? Sprite Editor for Nintendo DS is my oldest homebrew, and yet there was no satisfying photo of it running on real hardware on this blog !? There were some, sure, but either showing uninteresting screens, or with a user interface so old that it barely looks like SEDS at all.

I had to got that fixed, be it only to have something for people following my #SpriteEditorForDS hashtag on mastodon or bsky ! 

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.

Oh, en passant, j'avais fait un petit sondage à l'époque ... Editer des jeux sur la NDS, vous trouvez ça

• épatant (56%)
• amusant, mais inutile (25%)
• de la folie (18.8%)
• et ce n'était le plus grand rêve de personne ... voilà voilà.
  

 

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.

Oops! I did it again!

Novembre 2020. J'ai voulu pouvoir ouvrir n'importe quel .spr dans mon Sprite Editor et j'ai rajouté un discret petit "dir" qui ouvre OtherFileWindow. Oui, parce que jusque là, c'était toujours A pour spriteA.spr, B pour spriteB.spr et ainsi de suite jusqu'Y. 

Sauf que quand j'ai voulu essayer de re-sauver ça n'avait pas marché. Pas de quoi fouetter un chat, mais j'ai moins ri quand je me suis rendu compte l'éditeur de niveau ne marchait plus. J'ai tenté un patch, j'ai voulu l'uploader dans runMe, mais runMe ne savait plus rien uploader non plus...

For over 15 years (!), Sprite Editor for DS has been satisfying to use with only 4 files directly accessible. It no longer is, with Furries experiments, demo projects and dreamland target that will use 4 different environment plus bilou.spr.

Hopefully, back in November, I added a new window in SEDS that let you pick a .spr when tapping the (poorly named) "dir." button.

There's unfortunately an unforeseen interference between SpriteSet::SaveBack() and OtherFileWindow::event(). One expects that the string you passed to SpriteSet::Load() megacycles ago is constant and hasn't changed. The other needs to drop the 'file' part of the path so that you can pick another file later on and not end up with fat:/moving/bilou.spr/desert.spr/green.spr ...

The unfortunate consequence of all this comes as SaveBack tries to make a .bakup of your .spriteset ... the name is now just the directory's name and thus the directory is renamed. None of my tools are ready to face that. Do you think future self-as-a-user will take notice of past-self-as-coder warnings written in the comments part of commit logs ?

Heureusement, je n'avais pas bousillé toute ma carte mémoire, mais par contre, au moment de faire la sauvegarde, mon "fat:/moving/oldies.spr" était redevenu "fat:/moving/", prêt à traiter un nouveau fichier et en faire un chemin d'accès. Et le code qui crée le fichier .bak à partir du .spr est ... disons ... vieux et innocent. Il à renommé fat:/moving/ en fat:/movibak qu'aucun de mes outils ne reconnait.

Et bien sûr, ça m'est re-arrivé hier en voulant changer quelque-chose dans mon bilouchk.spr ... Donc cette fois j'ai sorti mon callepin et le code-sur-boox

• [done] fix SpriteSet so that it uses a std::string rather than const char* to remember the filename to save
• [done] make sure SpriteSet::SaveBack() checks there is a .spr at the end of the file name
• [done] add a check window in runMe that triggers when there is no /moving/ folder and offers to create one or to restore /movibak as /moving (if exists)
• [done] also browse for files in AnimEDS
  

Une histoire de police

 C'est la série de p'tits fanart pixelisés de Rephil qui m'a mis la puce à l'oreille: une police en pixels, c'est quand même bien plus lisible avec un ombrage. Surtout quand on est pas déjà en noir-sur-blanc. (ou blanc sur noir). Et vous savez quoi, il arrive à le faire même en 5x5!

I guess it is the checkerboard pattern of Rephil's  (pixel|fan)art that lead me to realise is so much more readable when you drop a shadow. (yeah, that took me 15 years). So maybe it would be worth it to do the same on the DS for my game tools, right ? And maybe I could even push it further and use 'drop shadow' to indicate that some specific text is interactive! Someday ... maybe... Clearly not a high-priority thing to do.

Alors bin avec mes caractères 8x8, sur DS, il n'y a pas de raison que je m'en prive, si ? Dans presque chaque caractère, il y a une ligne vide en bas et une colonne vide à droite pour éviter qu'ils ne se 'collent' l'un à l'autre. Et ça n'est absolument pas gênant si les pixels d'ombre se colle aux pixels blanc des caractères suivant.

Petit mockup de ce que ça donnerait... On peut même raffiner en utilisant ce truc que pour les caractères "interactifs" des widgets. On peut même utiliser une couleur supplémentaire "highlight" qui disparaîtrait quand on active le widget alors que l'ombre passerait à la couleur de texte pour donner ce petit effet interactif "le bouton s'enfonce quand je pousse dessus" qui fait toujours du bien.

Maintenant que je suis passé à du multi-palettes dans tous mes outils, pourquoi s'en priver ?

edit: oh bin justement, quelqu'un a mis en ligne une belle collection de polices bitmap issues de la demoscene...

From iColorUsed to ScanTiles

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

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

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

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

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

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

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

sprck || fail.

Good news: I managed to reproduce in a controlled environment the corruption of a spriteset. Bad news: because I had no idea what was the possible cause of such corruption, I just went through a random set of deletions and then a random set of recycling of the released blocks. And repeating the process from a sane initial spriteset until the "checker" tool reports something abnormal

One interesting thing, though: what's abnormal is abnormal twice: not only I shouldn't have "cross clusters" in my sprite pages (two slots on two pages actually referring to the same tiles), but I possibly shouldn't have "0" at all (it is reserved on most spriterams) and I definitely shouldn't have some odd tile number since the smallest allocation unit so far is 4 tiles.

edit: Another curious thing, on the "animations" subset: one page makes reference to tiles that are not in the spriteset! possibly unused things that were inserted when the page was first created and then deleted before first saved into the spriteRAM. I guess I'll need to make sure I have some automated test that do something like that, too.

edit++: I think I got most issues fixed now. I'll have to give it a run on a real device and see whether I accidently broke something with all the "refactoring"  ...

book stack ...

A few days after releasing the playable version of Bilou : School Rush, I started encountering ideas for one ultimate level, one where you climb up to the top, rather than running horizontally. Something much more along the lines of the "original" deep-ink-pit although not expecting any specific game physics.
What was nice with that was that it turned the otherwise purpose-less "school rush" into something backed by a story (simple, I admit, but a story nonetheless). It opened nice opportunities to have hand-drawn pictures as support for a "game ending / credit" moment, too... and last but not least I found a nice way to ensure that this last level is available only in "amiga" or "arcade" mode, but not in "casual" (which is meant for training and teasing, as you remember).

A sketching pause was more than welcome, and now I have some concept art and some tiki-books for the background to change the atmosphere of the ultimate level. I'm under the process of converting that to pixel art. With a size of over 800 individual tiles, it is clearly the biggest piece i've addressed with my sprite editor. I had to chunk it into 64-pixels slices, resisting the temptation to redesign the UI of the editor, but I'll allow myself to add a "live mockup construction mode" before I'm done.
I first opted for 32-indexed colours in Gimp, thinking that I'd paint over the lines, but the shapes are too far from pixel-friendly angles, and "cleaning up", adding highlihgts could turn out to be my best approach. Yet, I'm already raging against my own self:

• clicking '+' on the quick palette widget insert the selected colors, shifting existing colors to make some room, collapsing places they come from ... but I couldn't find that documented anywhere;
• '!' (replace current color by its closest match) acting only on the grid is too restrictive for such pieces
• '!' and '?' (search for color closest match and occurence of the color in the tileset) are disabled after we load something on the grid. I have to shift the pixels around before the buttons work again.
• losing the content of the 32x32 grid when entering palette screen or touching one 16x16 block on the tilesheet should never occur again.

PS: please excuse french/english hopping again: it's another i'm-sick-and-blogging week.

Les vieux tout doux

Eh bien, il y en a, des choses marquées "à faire" depuis les années. Plus de 20 pages si je veux les imprimer sur papier. Ce sont principalement des améliorations pour les éditeurs, comme la possibilité de définir les zones de collision et les points-tests dans un éditeur graphique, aujourd'hui (enfin) très actuel.

La plus ancienne des fonctions manquantes du Level Editor -- les propriétés des blocs -- serait plutôt revu en "appliquer la combinaison graphisme/propriété à l'ensemble du niveau", et il faudrait aussi que je permette aux descriptions de blocs d'être partagées entre plusieurs scripts de niveaux.

Enfin, il y aura la liste des projets devenus hors-propos ou qui ne sont plus à l'ordre du jour pour mon projet actuel, rebaptisés "wish", comme l'éditeur 3D de bangbash ou l'intégration de RunME dans la PAlib :P

Mais la palme du PlusVieuxToutDouxDuMonde, c'est sans doute la possibilité de partager des tiles d'un bloc à l'autre (les blocs faisant 2x2 tiles), qui apparaît dès les premières réflexions sur l'animation des blocs en 2005 et marqué "need" en 2008 (traduisez: fonctionnalité jugée indispensable pour l'avancement du projet, qui permettrait de redescendre à 66% du nombre de tiles actuels). La possibilité de poser des quarts de blocs dans LEDS aidant, évidemment... Dans l'immédiat, j'aimerais plutôt pouvoir enregistrer des morceaux de niveau pour capturer des objets complets (qui apparaissait 6 mois plus tard, puis revient à la charge).


Voilà. J'ai fait un peu le ménage dans ce qui datait d'avant 2013 ... je ne suis pas sûr que ça m'ait vraiment fait progresser pour améliorer le niveau des expériences en cours, par contre. A suivre. Comme toujours :P
codes couleur: [done], [todo nécessaire pour school rush], [todo dans l'absolu], [wish]

That's what gets out of the 20+ pages of 'todo'-tagged posts already available on this blog. When you condense them on a sheet of paper, with focus on releasing the 'School Rush' game. There's one big point missing, though.

Write a documentation page for AnimEDS

Start+R+A

Reprise du boulot oblige, la progression de cette semaine est moins impressionnante, mais peut être tout aussi importante. Si DaySi a brillamment repris le flambeau depuis la chute de DarkneSs, elle se fait de plus en plus capricieuse avec son bouton R. Oh, il fonctionne, pas de soucis de ce côté ... mais il n'est plus très fiable. Il peut être nécessaire de pas mal le titiller pour déclencher quelque-chose, et quand il se décide, il n'est pas rare d'obtenir des "rebonds" du genre "on/off/on/off" en une seule pression du doigt.

Pressing Start+R+A or Start+R+R in SEDS lets you chose between "Save" or "Save As", changing the way a back-up copy of your file is created. When your 'R' button may automatically read as "R+R+R" for a single press, it quickly becomes unmanageable to have coherent file history. So I finally took the time to add some LOAD and SAVE clickable buttons (plus a tool option to invoke cursor mode in SEDS from the stylus) to compensate hardware deficiences of the DS.

Dans la mesure où ce bouton contrôle la "sauvegarde" dans SEDS et AnimEDS, c'est plutôt génant. A plusieurs reprises, j'ai du re-transférer d'anciennes versions de mes livres pendant que j'en faisais la mise à jour pour corriger une réécriture intempestive alors que je cherchais juste à activer le mode curseur (lui aussi déclenché par R). Mais voici donc une mise à jour de mes outils qui offrent des boutons cliquables (au stylet, donc) pour compenser ce genre de problème. A noter que le bon fonctionnement du bouton L, lui, reste incorrigiblement critique.

Release Checklist Time

Tomorrow is the yearly release day. I had hopes to come with a fully functional revamp of the "school zone, level 1" as initially drawn by Pierrick and Piet (aka Cyborg Jeff), but that's not yet possible. You still have the latest gameplay demo to try (3rd evolution since Christmas), I you really want to. That's still significant progress achieved since last year's first appearance of a compound Gob in the game engine.

I toyed with the idea of doing a quick-shot of SeaFox on DS, using the sprites I drew 4 years ago (whoaw. that old 0_0), which would now be somehow a piece of cake with the directional tiles I used for Inkjet and the objects generators that I used for berrybats. But I lacked time for that as well.

On the other hand, all the tools have been upgraded since the Neocompo, with the addition of multiple palettes, and so was the game engine. That's not as impressive as introducing the animation editor, but that's still a significant step.
In SEDS, you have a set of radio buttons telling "cmap slot" just above the raster tool. touching one letter picks that palette for edition, and L-touching it will copy the current data onto another slot. Clicking "okay/sure" activate one slot for the sprite editor. That's pretty much all you can say.

• [todo] enable some sort of "sheet preview" for all the sheets on top screen, and identify the currently selected sheet(s)
• [done] L+touch on the '>>' and '<<' buttons navigate to the "next page in the same set as the right (edit) page".
• [wish] 16x32 and 32x16 edition (even with 32x32 grid)
• [done] provide a button on screen for launching "cursor" mode, just in case R trigger is not as reliable as it should.
• [done] provide a "Load" and "Save" button on the file screen that do not depend on L/R triggers.
• [done] auto-compaction of the tileset as you move pages across types of ram
• [done] two-way navigation in ram types with L+touch. 

In the animation editor, there's two places where you can use alternate palette. When you describe a "limb" for an animation, you can use the "cmap slot" radio buttons on the "FILE" screen to define its default colour (before L-touching the limb table on the left).


Alternatively, you may need to change the palette slot of a "limb" during the animation, for instance to introduce some progressive shading effect. This is achieved by touching one of the "cmapslot" in the bottom-right corner of the EDIT screen.

See this post for identified bugs and things that needs improvement.

• [done] provide a "Load" and "Save" button on the file screen that do not depend on L/R triggers. 
• [done] allow more than 48 animations.
• [todo] dim the sprite when enabling "box" mode (as suggested here), report the current size
• [todo] allow the box to be moved without getting resized.
• [wish] more convenient way to encode limbs default priorities (i.e. grid vs. list)
• [todo] show both *load slot* and *save slot*.
• [done] export animations into .gif files 

Changing the color of tiles in LEDS is likely the most hack-ish of the three. You will need to ensure that your tiles are on the background layer, then press L+SELECT to switch to properties edition. From there, press the dpad to the LEFT direction once to hide the tile properties, and then press it again so that it says "colors on" on the top screen. you may then use (A) and (B) button to change the current cmap slot and paint objects with the stylus in the currently selected slot.

[done] make sure monsters are properly rendered on screen
[done] allow cloning of .cmd files and update of which map they use.
[done] feedback on file selection.
[todo] feedback on color selection; e.g. change palette for the upper screen and fade foreground objects.
[todo] make tile flipping simpler in draw mode (e.g. reaffect X or Y button).
[think] enable 'book' of sketched objects to be read/written to (may require A/Y for DRAW/COPY mode to be re-thought too).
[done] display non-functional (missing state) GOBs and allow selection.
[todo] report GOBs' cast
[todo] clear/set GOB init expression, set cast.
[need] in 8x8 mode, move the cursor by 8 pixels, not 16.
[done] allow monsters linking.

Hope you'll enjoy it.

throwing bladors

I can be glad I'm done with the "bottom things" of my summer todo list. Now the winter is starting, and what is left is what is more linked to the game logic and the revised collision engine which is waiting to prove its superior capabilities with some dumblador stunning and throwing.
De temps en temps, ça fait du bien de retourner à une "liste de choses à faire" pour s'assurer que le projet avance effectivment. Bon, des "todo lists", vous devez tout doucement commencer à en avoir une indigestion, mais je parle ici de quelque-chose qui s'approche plus d'un "planning" que des micros-tâches à effectuer sur un temps de midi. Mon dernier planning datait de mi-juin ... voyons où on en est... tous les éléments "du bas" ont été satisfaits, à grand renfort de mises à jour de SEDS et AnimEDS. Je vais donc pouvoir cet hiver attaquer sérieusement les nouveaux types d'interactions entre personnages: assomer, attraper, balancer.

On dirait que les mois à venir vont être durs, chez les Dumbladors.

At those "milestones", I can close many former todo lists, by collecting in a new one the items that remains pending but that weren't really linked to the then-going activities. And yes, this is truly a milestone, since I now have fully operational CompoundGobs, including the definition of palettes for individual limbs (altering the palette while playing the animation will be for a next milestone :P)

• [done] looping move should only be generated for looping animations
• [done] initial Mx,y statement should be ignored by the game engine (actually, everything that delays the rendering of the first frame of the animation should be skipped). That will partly solve the "landing bug".
• [todo] most of blador's debugging could have been avoided if we had the state-initialisation expression feature implemented.
• [done] not detaching an attached GOB when "throwing" it may have weird effects, but I would have liked the display list to be re-ordered so that such side-effects wouldn't have systematically occured.

Yellowl and Redowl

I tried again, with the updated SEDS and properly charged battery. I could save a first draft (just the shadow lines), and then when I tried to save my "finished" work, the editor crashed again. That's *really* getting on my nerves, now.

Hopefully enough, I had a real camera powered up and ready-to-shoot just one floor below, this time, so I've shot pictures of my screen and did some Gimp post-processing to try to enhance and restore the picture into something that could be shown or fixed afterwards. I started the owl again, from the 'shadow lines' that were saved, using the version of SEDS I submitted to NEOflash compo. Everything went fine, and I made tons of intermediate saves. Then I thought "oh, well, that should be it for now", and clapped the lid of the DSi. As usual, I then thought of a small last improvement I could do, so I opened the lid, applied the change and tried to save again ... stalled. So this is what goes wrong: I cannot read/write to the SD media card anymore after I put the device in "sleep mode" for a while. And that happens regardless of whether I use the "1.x" or "2.0" version of my GUI engine.

owl story ...

I took the time to print out Facet's edit on my school owl so that I could train myself and draw a new one on my DSi. It was starting to come out quite nicely, but unfortunately, I've lost it. For some reason, SEDS stalled when I tried to save my new piece of pixel "art" on a new file.

Voici hélas tout ce qu'il reste de ma scéance de dessin de hibou sur la DS ... l'idée de faire d'abord uniquement les zones les plus sombres dans une "couleur stencil" avant de doubler la taille n'était (à mon avis) pas mauvaise, mais au moment de sauver mon travail sur la carte mémoire, quelque-chose a coincé sans crier gare et je me suis retrouvé (une fois de plus) avec une DS qui ne répondait plus aux commandes au moment de définir quel fichier de sauvegarde devait être utilisé. La batterie de ma console était fort faible (je n'ai même pas su la relancer), j'espère que c'était juste ça... Ce n'était pas encore la dernière mise à jour de SEDS, non plus.

Was the linker no longer able to access the media card ? Was there a bug left in that r1056 version of SEDS ? was the battery's low level critical when power was needed again by the flash hardware ? I have no idea, but that's getting troublesome ...

N'empèche, ça m'ennuie ... il serait temps que mes outils de game-making sur DS redeviennent fiables.

So many palettes!

This time, I do it the correct way: I start mapping which (hardware) palette is used where so that I can later properly track copies that goes on all over the place and figure out why I can't properly load/store palettes in that "multipal" update.

Many of the operations you can do on the PaletteWindow actually involve copies from one of the palette into the others. Ideally, they are all synchronised...

•  as soon as you start editing your palette, it differs from those of the "upper screen" which are kept static
• "okay" button copy the edited palette into SPRITE_PALETTE_SUB, allowing a preview on the current sprite page
• if you're fine, "sure" button copies the edited palette on BG_PALETTE_SUB as well. It's now officially your working palette for the grid.
• At anytime, you can undo something by clicking "oops", which copies BG_PALETTE_SUB back as the edited palette. 

There's something the multipal approach changes, however: what is now stored in the .spr file is the offscreen set of (up to) 4 palettes, which is updated every time you flip to another slot. So "okay/sure" only affects how you will draw pixels in the close future, not what is actually stored when saving. The bare minimum I can do is to ensure that onscreen->offscreen update is performed when clicking "okay" as well. 

I *could* also enforce this synchronisation when going out of the PaletteWindow, but that would break the former user interface convention (where going out without having pressed "okay" at all means you won't save your palette edits). To overcome this, and avoid data loss, I introduce an additional offscreen undopal[] where I can automatically store data, and a "lost" button that can recall what was on screen the last time you left the palette edition "window".

supercard and multi-palette

There is one last thing I can do with my failed homebrew equipment: dig out my old SuperCard (slot 2), update the makefile so that it automatically apply DLDI patch if $DLDI environment variable is set, and work on that multi-palette support that will ultimately allow me to tint books in up to 16 colors in the school zone (only 4 slots atm.)

Premiers tests concluants pour le système "mutli-palettes":voici un bouquin vert, mais qui peut redevenir rouge à n'importe quel moment. Et il ne s'agit plus d'un simple test grandeur nature dans SEDS: les palettes alternatives peuvent maintenant vraiment être sauvées dans des fichiers .spr et re-chargées plus tard.

Roses are Red, Violets are Blue ...

And my books should be allowed to have whatever color I think fit. Or at least let me put it in a different way: that would be a waste of tiles if I could only have *red* books in the school zone, right ? (and only green binders). It's much more interesting if I can select an alternate palette when I want a blue-tinted book or a darker wood block.

The DS hardware allows all this (I mean, even the NES had it :P), extending the '256 colors' mode of the GBA to some fancy '16x256' colors. Granted, I *could* very likely work in 16x16 colors mode for the school zone, but I'm not yet a sufficiently good pixel artist to handle that.

I've took a first step yesterday by allowing some 4 palette slot selection in SEDS' palette editor. Before I give you a rainbow bookself, I still have to:

• [done] store all this in the SPR file (SpriteSet classes)
• [done] make sure SEDS has a palette large enough advertised to SpriteSet.
• [done] adjust the game engine so that it works in extended palette mode
• [done] provide palette set toggling in LEDS (only for the BG layer: the FG uses it to encode tile properties). That would be better to have it on the bottom screen, and not part of the "tileset" screen as depicted on the mock-up
• [done] provide palette setting in AnimEDS as well (so that dumblador and Bilou (and pendats) can share feet tiles. Being able to define it when the sprite' skeletton is created should be a good first step

Oh, and don't worry: there will be an polish on the transanims and a schooldemo.nds by the end of august. I just need to recover a DS lite for that, so I'm messing up with other parts of the summer-todo-list.

AnimEDS at Neoflash Compo

For the second time, I'm entering the "Neo Coding compo", with latest versions of AnimEDS and SEDS, with in-app help for almost all the operations. I had first some hope, as there weren't that much "good" (imho) applications submitted until Smealum (arsenal) nuked me with his FPSMaker ...

Un badge, des messages d'aide, un personnage moustachu en salopette dans un .spr (à la place de Badman), et voilà AnimEDS (et SEDS) prêts pour la compétition de "rétro-coding" de Neoflash. Cette année, c'est "toutes machines confondues", avec un sérieux regain d'intérêt pour les participants, même si je n'ai pas vu côté DS de production à la hauteur des jeux qui avaient brisé les espoirs de Apple Assault en 2010. Si je devais donner un pronostic, je parierais sur la victoire du FPSMaker dans la catégorie "Applications" (également sur DS).

Anyway, although I made the effort of having the compo badge shown in my entry this year, winning some prize is not my main motivation: I want to take the opportunity of many people blowing dust away from their handheld console and downloading homebrews to get more feedback about the user interface and how to make things more "user friendly". 10/15 blog readers have voted for that in the app/game poll that ends by friday ... but for that I'll need to know what people think and expect from my apps.

Gauchers

Utiliser SEDS n'était déjà pas très facile pour un gaucher ... LEDS et AnimEDS, c'est encore pire. Or, mon frangin et mon filieul sont gauchers et clairement intéressés à faire leur propres petites maps...

si ça, c'est pas un tout-doux-il-t'aime, alors il n'y en a aucun sur ce blog :P

How sort of a godfather would I have been if I couldn't hear the crying voice of a little left-handed boy who's willing to draw maps with LEDS but struggle to use the current controls ...

So let's do a first try and allow swapping of L and R trigger buttons that should already help a lot. I'll need to meet a left-handed again to check whether keeping map navigation with R+DPAD sounds like a good idea or whether I should also swap DPAD and ABXY...