such a mess ...

One file has the new (shrunk) inkjet ... the other has the survived ink swamp animation ... one has dumblador MEDS animation, the other lost them ...

This time, I could use runME to transfer the files (for some reason, I need to switch to "beam out" window, then back to "beam in" so that the "edit" spriteset button appears ?), but I wonder whether it could have dropped the animation information, somehow. Or is it something with the reading of autoexec.spr in SEDS that behaves differently from the typical START+L+* ?

Quelle histoire! Voilà la School Zone à peu près aussi sinistrée dans mes fichiers .spr que dans le monde de Bilou ... ici l'encre à disparu, là les encriers ont enfin retrouvé leur taille normale, mais dumblador ne marche plus... A force d'utiliser mes outils en cours de réparation pour tenter de réparer une bourde, les choses deviennent de plus en plus hasardeuses. Heureusement, j'ai les originaux de chaque fichier bien au chaud, sur mon disque dur (enfin, pas trop quand-même, hein ...)
Après avoir corrigé la copie de pages et la supression de blocs 32x32, je m'attaque à un dernier point mystérieux: la disparition des animations lorsque je transfère mes fichiers via runME (donc, avec un fichier 'autoexec.spr' présent au lancement de SEDS). Avec un peu de chance, j'arriverai (enfin) à récupérer tout le monde dans un seul .spr ...

Erhmm.. looks like it is. I'm missing an "&extdata" argument to keep track of "whatever the Sprite Editor doesn't natively understand"... such as animations. And all this happens with my brother's white DS, since DarkneSs is under repair after its "big fall"...

Ahaa ... got the autoexec.spr thingy fixed (yeah, there was the bug, as you may have guessed from checking the svn snippets). Some more beams and I also have the "smaller inkjet" copied into its proper place, the "minilevel" archived in the "draft" dataset ... Will I dare to run the engine on that ?

YES! pfew. I got it fixed, apparently. I will now be able to resume the attempts to bring ink swamp, inkjet and spongebop some life. howdy.

Oh, just not to forget it, the left-table on SEDS is still unable to offer 32x32 blocks properly, and it may still be required to switch back to the GridWindow before the right-table do it. That's a nuisance, and I think it took some 3 lines of code in AnimEDS to get it sorted out. Time for a merge-and-fix, dude-self. Done, thanks to doxygen-on-cybook ;)

fixing SEDS ...

(Flickr photo by amaky)

A blog is suppose to bring in updates, and yet after 6 years, I keep updating some posts again and again as the situation evolves. It happened again, I'm afraid.

So to keep you updated, I managed to fix the school spriteset using an upgraded version of SEDS. Spongebop now moves along and chase Bilou like a berrybat because I merely renamed "berrybat.cmd" into "spons.cmd" and then adjusted the animation statements :P

It turned out that most of the things I initially planned as "regression tests" for the editor trivially worked because they didn't care which SpriteRam they were working with... Yet many other things have been identified as broken/misbehaving, and will be fixed in the near future, but only after the revised SEDS is merged back on the trunk... and that will be after I'm back from my next conference. I'll allow myself the right to make SpongeBop behave as it should first, build up a proper animation for Bilou's walk and even to revise the pixel art for inkjet so that it indeed deserves the word "art" :P

Oh, mais oui, chers lecteurs francophones, merci à vous de rester là malgré mon emploi du temps surchargé qui me pousse à faire des posts monolingue pour l'instant.

sponge-hands-and-ink-and-mockup

Here I stand, guilty of doing low-level debugging where the situation wasn't calling it. Now that I have a "test level" for the school zone, it's very tempting to start writing more monster code. I thought I could easily hack a Sponge Bop test while *deline was asleep this afternoon, but for some reason, only the first frame of the animation did show up. The rest was just rubbish: Bilou feets and similar stuff.

Was my data corrupt ? Was there some nasty bug related to 32x32 sprites in the revised game engine (there shouldn't have been?) I scanned virtually everything, but the data I was (painfully) reading in DDD made little sense.

I finally decided to hack some debugging output in my .spr to .png converter to see what "pages" were containing, and I turned suspicious over the following entry:

4x4=1020,1036,1052,1068,1116,1132,1148,1164,1180,1196

1036 ? 1052 ? that's a bit surprising for a sprite number ... when I looked at the shape of the spritesheet, the obvious (finally) hit me: the DS can only enumerate 1024 tiles for sprites. No more, no less. Everything on the fifth column of the spritesheet can be nicely viewed in the SpriteEditor, but cannot be used in games. It's not even the first time I encounter the problem >_<. I think I'll need something in the Sprite Editor that warns the user about this when saving a tileset. And I'll have to figure out how I solved the problem last time...

Oh, and it's been over one year that I'm longing for a "draft" tileset and a "animation" tileset in .spr files ... I think it's now time to add this to Sprite Editor ...

developments:

• [done] enable up to 4 SpriteRam;
• [wish] show how much tiles are used in each SpriteRam (other than pressing L+START to enable debugging, I mean), and which spritepage should be moved to compress the tileset.
  
• [done] shrink spritea.spr so that it can be fully used by the engine;
• [next] enable 16x16 <-> 32x32 sheet conversion;
  
• [next] find a way to use the ink animation in the level;
• [done] produce a warning when saving a file where sprites or blocks set has too much tiles;
  
• [done] allow hint on which tile is used when producing tilesets with spr2png.pl

regression tests after the edit:

• [ok] change the spriteram used for a page
• [ok] save and load file with more than 2 spriterams
• [---] use the "scan colors" and "color remap function" (actually, nevermind: it operates on the working sheet, not on the SpriteRam itself).
• [ok] use the "compact tileset" feature (doesn't it just reduce the 'watermark' when last tiles are no longer used ? couldn't that be automated with load/save ?)
• [fair] use the "color zap" (dirty bit and warning message "file your sheet first" ?)
• [fixed] copying page only works for "blocks" pages.
• [fixed] cursor-assisted deletion of objects doesn't behave as expected with 32x32 sheets.

I'm a bit surprised to see the "SpriteRam*" pointer so scattered all over the code... I might have to change them into "spriteram_no" here and there so that only some core component deal with sprdata[i] directly.

ramno^1

En août 2008, poussé par un manque de mémoire vidéo,j'avais modifié SEDS pour qu'il puisse stocker les blocs séparément des sprites tout en gardant un seul fichier ".spr". Il aura fallu attendre février 2009 pour que cette modification soit pleinement supportée par le game engine et plus encore pour que l'éditeur de niveau en tienne compte.

The code snippet above is the handler for the "!extra!" button you can see below the Bilou sprites on the picture below. So far, it allows me to place whatever is drawn with SEDS either in the "blocks" tileset or in the "sprites" sheet. Since the Nintendo DS has separate VRAM banks for both, it's clearly worth the effort (the tale of this feature is now collected under the tag "ramno"). Last year, as I was sketching vines for the "nuts&bolts" project, I started using the "sprite" ram both for sprites and sketches. Soon or later, that's gonna catch me in the back. Since I'll have to update the sprite editor for r32, I'd like to add a separate "blockanim" and "draft" set. That could be helpful for the (yet to come) animation editor as well.

L'an dernier, alors que je fais un tour d'horizon des modifications à apporter pour Nuts&Bolts/AppleAssault, je dessine un paquet de lianes dans l'espace réservé au sprites (le tileset pour les blocs étant proche de la saturation), ne copiant que les blocs qui sont satisfaisants dans la zone de mémoire "blocs" utilisée par l'éditeur de niveau. Le texte "!extra!" sous les Bilous est donc le bouton permettant d'indiquer si la page fait partie du tileset par défaut (blocs) ou supplémentaire (sprites). Clairement, si j'avais eu plus de sprites, je me serais de nouveau retrouvé bloqué. Il faudra donc prochainement que je passe à un mécanisme à 4 positions: "blocs, sprites, blocanim, draft", la dernière position étant de fait réservée à des scribouillages internes au Sprite Editor. Je dis "prochainement", parce que l'éditeur d'animations, lui, n'aura que faire de ces scribouillage :P

Il y aura donc du rt^1 qui va devenir du (rt+1)%4 dans l'air prochainement.

Bug ou Feature ?

Bin finalement, ça n'aura pas été trop compliqué de bidouiller SEDS pour qu'il me permette de copier mon "fameux tile perdu" d'un fichier à l'autre. Enfin, dès que j'ai pensé à bêtement retirer la carte microSD pour placer le backup dessus en tant que SPRITEX.SPR plutôt que de m'entêter à utiliser runme pour un transfer par Wifi ^^".

Un fichier .spr est organisé en "feuilles" (les spritesheets), c'est à dire la zone de 64x176 pixels sur la droite de l'écran d'édition, et au début de la version 0.3, j'avais ajouté un mode "copie feuille-à-feuille" avec un second "viewer" indépendant. Tellement indépendant, qu'en fait, si je commente une ligne dans mon code, il devient capable de conserver les données (en lecture seule) malgré les chargements de fichier. Juste ce qu'il me fallait pour sauver le week-end.

Et pourtant, je ne pense pas qu'il serait judicieux de garder ça comme une "feature" dans la prochaine version de SEDS. C'est totalement contre-intuitif, et 9 fois sur 10, la spritesheet du fichier précédent est de toutes façon inutilisable parce que travaillant avec une autre palette. J'ai beau penser que "Si on ne sait pas le désactiver (à la demande de l'utilisateur), ce n'est pas une "feature" : c'est un bug!", cette bidouille serait perçue comme un bug puisqu'il faut "ruser" avec le programme pour le faire fonctionner normalement rien que pour bénéficier d'une option en plus.

The Lost Tile has finally been recovered with a fairly simple hack on SEDS. Funny enough: the "hardest" part was to transfer the backup .SPR file on the media card ... which turned out to be trivial as soon as I stopped trying to use runme for that purpose ^^".

The solution is based on the "sheet-to-sheet" copy feature that I introduced a while ago, and that allows to view two sprite sheets (those 64x176 pixels area SEDS edits) face-to-face once you press the "START" button. The second sheet is "so independent" from the file we actually edit that -- when commenting out one line -- it can preserve its contents accross "load file" operations.

Now, unfortunately, this is not a "feature" I can keep. For the end-user, it will definitely look like a bug! Just like you wouldn't call a "feature" of a word processor the ability of copy-pasting from two different files if that implies you only have meaningful text pasted when the two files use exactly the same set of fonts. I have a rule to distinguish a(n unwanted) feature from a bug: if you can't disable it, then its a bug. I can disable this one, so I'll do.

Click the picture and discover more of the "spriteset management screen" of SEDS on flickr.

Todo ... later

Time to compile a list of "pending issues" that I'd like to see resolved to progress in my projects. Only then I can actually start adding support for vines, moving platforms, conveyers or whatever else fancy stuff "Bilou Mining" could use.

• [testing ...] stand and land on slopes
• [done] fix vertical scrolling issues (cf. Morukutsu comment)
• [done] a "pause" action that dumps GOB state and stops the game engine so that I can proceed with collision debugging.
• [done] properly stomp applemen (woodworms seems ok in gedsdemo)
• [thinking ...] load any background music from the gamescript
• [done] require a press on a button to trigger a jump.
• improve berrybat's behaviour
• [wish] animXX mirror animYY to ease coding of .cmd files.
• [done] explicitly export states from monsterxxx.cmd into levelxxx.cmd
• [done] (refactory) give monsterxxx.cmd its own namespace for animations.
• [done](refactory) 'on event ...' transitions bound to micro-controllers and 'on fail' transitions to testpoints, the same way 'on hit/found' are bound to test/area statements.
• [done] (refactory) stateXX..YY->stateZZ on event [...] (...) to allow a transition from multiple input states.
• (wish) a "media manager" to avoid redundant loading of maps, spritesheets, modules, ...
• [done] (bugfix) make sure all OAMs are disabled when a new level starts.
• [done, afaik] (leds, bugfix) newly cloned monsters should be playable too.
• [done] (gfx) draw collectible nuts&bolts
• [done] (gfx) a separate frame when Bilou gets hit.
• [done] (leds) "play" button that saves the current .cmd file as "autoexec.cmd"
• [done] (blog) widen the view, update heading banner
• [thinking ...] blocks that fall/disappear after Bilou walked them (incl. gfx).
• (leds, bugfix) You might have several times the same gobno allocated ??
• (leds, bugfix) Cursor for block-picking doesn't work properly ??
• (seds) more "storage areas" : tileset, sprites, anims, sketches
• get the garbage out of the kitchen tonight

Bon, bin y'a du boulot! Entre les bugs dans les la maturation des fonctions expérimentales de LEDS, les graphismes à rajouter, les commentaires de Morukutsu sur la jouabilité, les difficultés pour le debugging des collisions Bilou-Appleman (les applemen étant invulnérables de temps en temps sans que ça ne soit prévu) et le "refactoring" nécessaire pour pouvoir continuer à gérer plus de monstres correctement ... Alors seulement on pourra commencer à penser à des plate-formes mobiles ou des tapis roulants.

Revamping the green zone

moui ... voilà donc un aperçu de cette fameuse "nouvelle map" que je bricole pour l'instant histoire de tester mes nouveaux graphismes de forêt (encore loin d'être parfaits, hein), avec, marqué en rouge, les endroits où il me manque des blocs de transition pour les coins, etc.

Notez aussi qu'il va falloir que j'aille un peu corriger mon éditeur de niveau qui m'a laissé éditer une cave profonde alors que je sortais en réalité des limites de la map, d'où ces étranges blocs flottants dans l'arbre de droite.

Il me manque des branches, un décor de feuillage "valable" par-dessus lequel je pourrais venir rajouter mes plates-formes feuillues, etc.

A quick sample of the current tileset for the green zone, which is used for testing new collision/behaviours atm. i'm still missing many transition tiles (hunt for red circles) and

TODO:

• [leds-done] ignore extra sheets in the level editor (rather than just showing empty sheets)
• [leds-done] a 'swap layer' tool that moves existing tiles to the other (bg/fg) layer
• [seds-done] RGB shown as 00..FF rather than 00..31
• [seds-done] S and V shown as 0..100 and not 0..255
• [seds-done] capture all the colors used on a page and clone them (to allow palette manipulations), updating tiles of that page to the new colors.
• [leds-wish] copy/paste/clear whole areas
• [leds-done] don't let me edit out of the valid map area

ramno 1/2

Aah. Eh bien finalement, ça n'aura pas été aussi difficile que je ne l'avais cru. Je parle de la possibilité d'avoir plusieurs "zones de stockage" dans un seul fichier .spr, bien sûr. En fait, une seule classe dans tout mon imbroglio était sensible à l'emplacement réel des tiles en mémoire. Il a suffit de l'éditer pour que tout se mette en place. A part ça, il y a juste SpritePage qui a chopé une nouvelle variable "ramno" pour indiquer le numéro du SpriteRam utilisé ...

"Mais par l'espace, pourquoi tient-il absolument à regrouper dans son fichier des choses qui n'ont aucun rapport entre-elles ?" vous demandez-vous (si, si, sondez le fond de votre coeur, vous verrez)

Eh bien, la première raison, c'est évidemment le hardware de la DS. Si on dispose de 640K de mémoire vidéo, en revanche, les différents plans, les sprites, etc. utilisent généralement des zones mémoire séparées. Or, si je pourrais me satisfaire d'avoir Bilou complètement séparé de mon décor de forêt, l'appleman, le petit ver et d'autres éléments font un tout avec cette forêt. Supposez que je veuille faire un monstre comme "mimerock" dans Keen4: le même graphisme est utilisé à la fois comme élément du décor et comme sprite mobile. Idem avec le "bloc-question" de Super Mario (dans la version ou il 'sursaute' une fois coud-boulisé). Il serait vraiment pénible de devoir gérer un tel bloc dans deux fichiers séparés (croyez-moi: c'est ce que j'ai du faire avec mes Badman sous Game Maker :P)

La seconde raison, ce sont les blocs animés. Reprenons le bloc-question de Super Mario. Il va apparaître comme un seul bloc sur notre map, mais son contenu sera remplacé régulièrement par les étapes suivantes de l'animation. Evidemment, cela signifie que l'animation complète doit bien être stockée quelque-part, et si le nombre d'animations devient un peu important, ce serait ridicule de stocker tout ça en mémoire vidéo (alors qu'on a 4Mo de RAM à côté).

Voilà. Je n'ai peut-être pas convaincu grand-monde mais je me sens mieux. Plus léger d'avoir pu vous confier tout ça. A la semaine prochaine, docteur ?

1036 tiles is far too much.

J'ai foiré. Vendredi soir, j'ai voulu pour rire animer une petite touffe d'herbe en plus de mes pommes et après avoir sauvé, vlan, plus rien. Je ne panique pas et je démarre le moteur de jeu qui refuse de charger le niveau avec le message "1036 tiles is far too much". Argh! J'avais oublié ... A force de dupliquer des pages de sprites pour faire des essais, etc. J'étais arrivé *tout juste* à 64K de graphismes, ce qui correspond à la limite que j'avais imposée pour rester dans une gestion toute simple de la mémoire.

Bon, le problème sera vite résolu dans l'éditeur de niveau (qui était de toute façons prêt à gérer 256K de graphismes, c'est juste un oubli), mais pas en ce qui concerne le moteur de jeu. Il va donc falloir que je fasse le ménage mais pour l'instant, SEDS est complètement dépourvu de toute fonction "effacer". On peut dupliquer, ajouter, remplacer par un bloc complètement transparent, mais effacer, ça, non.

Oops. Trying to animate the grass in Bilou's woods turned out in no fun at all when the game engine refused to launch the game with "1036 tiles is far too much" error message. It seems like i forgot that i just reached the 64K of pixels the day before (well, out of which only roughly 1/4th of the tiles need to be kept :P) ... Patching the Sprite Editor to let it edit the spritesheet again was trivially easy, but it won't help as there is so far nothing that *deletes* data in my sprite editor ...

Du coup, je me suis fait un nouveau petit "plan de bataille" pour y remédier:

• [done] remise en route des "fichiers backup" en cas de sauvegarde
• [done] construction d'un "fichier archive" lorsqu'on remplace un des fichiers de travail par un nouveau tileset (p.ex. importé par WiFi)
• [done] une petite mémoire "undo" et un bouton pour rappeler sur la grille d'édition le dernier bloc "écrasé" lors d'un enregistrement dans la "SpriteTable"
• [done] ajouter la possibilité d'avoir un "bloc manquant" dans la SpriteTable, pour effacer des blocs tout en conservant l'alignement général -- et réorganisation des tiles contenus en conséquence.
• [done] effacer toute une page

Ceci fait, je devrais pouvoir 'réparer' ma p'tite forêt. Ensuite, eh bien, il sera temps de penser à la possibilité de séparer les tiles à charger directement en VRAM de ceux qui restent "dormants" en mémoire centrale (p.ex. pour les animations)