Oneliner to convert them all

fe -nx *.spr "perl ~/DS/SpriteEditor/bin/spr2png.pl 
        %.spr ~/hobby/dspr/demo-%.blk.png
        --maxheight=256"

fe -nx *.spr "perl ~/DS/SpriteEditor/bin/spr2png.pl 
        %.spr ~/hobby/dspr/demo-%.spr.png
        --extra --maxheight=256"

Another oneliner to gather them all, and in HTML bind them...

(echo '<html><body>' ; 
   fe *.png "echo '<div style=@display: inline-block;
     background: grey; text-align: center;@>
     <img src=@%@ title=@%@ style=@display: block;@>
     <small>%</small></div>'" ;
   echo '</body></html>') 
   |  sed -e "s/@/'/g" > test.html

Why ? Because I need to know which are okay, which need to be recovered and which need post-processing.

And then I realize that I cannot 'compact' the alternate spritesets (draft and animations), and one possible explanation for that is that the 'free tiles' information for that pool is incoherent. Maybe my `sprck` tool could fix that, but to be honest, its output is so cryptic that I might need to run it in DDD to figure out. 

• horizontal vertical tripes mean there's no pages using the block
• vertical horizontal stripes mean there's a FREE entry for the block.
  
• why is there so many FREE slots indicating that tile#0 is free ? (there's sprck_cleanup() to address that).
• even after it 'repaired' the file, I seem to still have the same 
• [done] fix spr2png --cleanup so that it works properly with --extra=1 and --extra=2.
  
• [dont] ensure sprck is capable of dropping FREE entries when a block is used on a page. instead, we have to mark them free
  
• [okay] ensure sprck can add FREE entries when no page is using a block - that's automatic in -repair mode.
  
• [done] have fe and color.pl and whereami hosted in DS/bin (or DS/tools/ or wherever it fits) on Codeberg
  

spr.more et sprdo

J'avais prévu de commencer par "Bon, ça commence à prendre forme", mais le temps que me mette à blogger, j'ai presque fini. L'idée est donc de montrer qu'il est possible de charger les sprites d'un jeu GEDS en deux fois, avec un morceau pour le personnage principal et un morceau pour les monstres, par exemple, histoire de pouvoir avoir des monstres liés à l'environnement traversé par notre personnage (comme dans quasiment tous les jeux assez longs).

Si je dis "les monstres" et pas "les blocs", c'est que dans leur cas, le fichier .spr contient aussi les animations, et que ces animations font directement référence à des numéros de page. Charger en deux fois, ça voudra donc aussi dire modifier à la volée les animations pour s'adapter aux nouveaux numéros de pages. C'est codé, mais pour le tester, il me faut des fichiers à fusionner. Or jusqu'ici, je n'ai pas énormément de fichiers .spr avec des animations. J'ai l'école, le personnage-easter-egg de la présentation de AnimEDS, peut-être un 'papa Noël' quelque part (mais où?) et peut-être un badman (mais où??).

Bref, j'ai fini par me dire que le plus direct, c'était sans doute de couper bilou+école.spr en deux fichiers bilou.spr et école.spr pour montrer qu'on pouvait les recombiner ensuite. Pour ça, ça m'a semblé utile de revenir sur un de mes outils de hacking de fichiers .spr: sprdo. Il s'agit d'un programme linux tournant en ligne de commande et qui utilise le même modèle de manipulation des .spr que le Sprite Editor lui-même. (mon collègue parlerait-il de code métier?). 

Un argument Lfilename.spr, et voici un fichier chargé. Un deuxième argument pk6, et on fait comme si on effaçait la page n°6. un p? et on voit des informations sur chaque page présente dans le fichier en mémoire. C'est un peu primitif, mais ça fait l'affaire.

Il fallait donc y ajouter une commande "montrer l'animation unetelle" puis faire en sorte que "supprimer la page unetelle" supprime aussi automatiquement les animations qui y font référence.

ça n'a pas été sans mal, mais j'y suis presque (reste à "nettoyer" les fichiers .spr de tous ces sprites qui n'ont plus de raison d'être, histoire de ne pas dépasser les 64K au moment de fusionner les deux. (normalement, j'ai déjà du code pour ça)

edit: on y était presque. Inkjet et les power-ups se sont chargés correctement. une partie de Bilou.cmd ausi, puis on arrive à une animation située sur la "deuxième page" d'animations avec Bilou (0311) et là bardaf: il n'y a plus personne. En compactant le spriteset les doigts dans le nez, sprdo m'a visiblement perdu certaines animations (la plus haute étant la n° 107 alors qu'il faudrait que j'aille jusqu'à la 129)

• [done] use the right anim (the one using the right page) for the waves
• [done] apply waves animation from the proper page (that also fix blinking of Bilou's limbs)
  
• [done] pendat and blador use proper shared limbs page
• [done] understand why the heal pick-up is gone
  
• [done] proper animation when we pick up a bonus
• [done] proper animation when we bounce on an eraser.
  

Engine Refactory

The Big Refactory has started (I could pretend it is a new-year resolution). And it even went pretty far, like abstracting away the animated objects list so that only the code for animated objects need to know details of the animation scheduler.

I was about to try changing the VRAM allocation system so that only classes deriving from using Resources could request items, and I got stuck in the animation editor.

Unlike SEDs and -to some extent- LEDs, AniMEDs still use a lot of global variables. Things like the sprite set or the animation being editted are used almost directly in many places, instead of being captured as "structural singletons". And at some places, it also means that we were calling Ressource Manager directly at top-level code, and that contradicts what a common base class can do.

There is one other peculiar thing about the animation editor: the set of pixels used in the game isn't uploaded to the video memory. Instead, we keep it in main memory, and only some bits of it go tothe VRAM through a Sprite sheet that map some sprite memory.  These sprite sheets are linked to a specific widget, such as the timeline or the frame preview. I must not try to make them part of a "model": they truly belong to the implementation of the widgets.

And yeah, although I have a digital sketchpad and an e-boox, I still enjoy some good paper and fine (erasable) pens for such things.

Tout vient d'la cache

Quand Eric parlait de faire des mises à jour à la volée de la mémoire au fil de l'animation des sprites, je pensais spontanément à un système semblable à celui de Donkey Kong Country: chaque personnage se voit attribué un emplacement en VRAM et les mises à jours pour ce personnage-là viennent systématiquement à l'emplacement alloué à l'apparition du personnage. Du coup, s'il y a deux "kritters" en même temps à l'écran, il n'y aura aucun partage entre eux: le nombre d'objets à l'écran devient fortement contraint, même s'il y a peu d'images indépendantes, comme dans le cas d'Apple Assault.

In my first attempt to understand Eric Zmiro's animation engine I thought the video memory would be managed somehow similarly to what happens in DKC on SNES: every new object on screen would receive a chunk of video memory large enough for the most complex frame it has to render and it would update its content during the vertical synchronization timeslice (or at some other time slice when the GPU isn't busy looking up those pixels). To some extent, the DKC engine would be an auwfully bad choice to implement a game such as Apple Assault, where there are a large number of similar ennemies on screen and high probability that a single block of VRAM is in use by multiple ennemies at the same time. That was failing to include the key ingredient in Zmiro's engine.

J'avais oublié un élément essentiel des moteurs de jeu à la sauce Zmiro:

Chez moi, tout est en cache : Fichier, sprites, palettes, bloc... tu n'allais tout de même pas dupliquer les blocs autant de fois qu'il y a d'instance ? si ? [...] avec ce systeme (développé sur GBA en 2000), on fait actuellement l'affichage de fonte (du texte!) avec caractères proportionnel sur XBOX one et PS4, codé en utf-8 et disposant de toutes les langues y compris chinoix, japonais et coréen ! Tu vois, c'est souple.

Like for tileset used by a gigantic and varied map, Eric introduced cache management algorithm deep into the animation rendering. Animation data refer to logical blocks and the mapping to VRAM location happens dynamically, reusing blocks when possible, importing new ones only when they are not yet in VRAM somewhere else and dropping unused one only when room is needed, keeping them available for the next animation cycle when you have few sprites on screen.

With this approach, no need for pre-defined locations, no need to do spritesheet optimizations such as "let's keep only one VRAM slot for the stunned dumblador and update it from main RAM to get the desired animation on screen". For every block in the SpriteSet, all we need is an additional short integer indicating whether the block is currently missing in VRAM or stored at some location between 0 and 1023. Everytime an OAM need to be patched to reference one logical sprite block (like "page 4, block 21), you can check the corresponding VRAM slot in the spriteset and copy to a free VRAM slot if none is currently assigned.

Fini donc les emplacements pré-établis. Finies les acrobaties du genre "je vais garder une seule image pour 'dumblador assomé' sur la spritesheet et j'aurai un SprAnim qui change son contenu depuis la banque d'image restée en RAM (je fais pareil avec les vagues d'encre actuellement): pour chaque bloc de données contenues dans le spriteset, il nous faut un nombre supplémentaire, entre -1 (absent) et 1023 qui indique l'endroit en VRAM où on peut trouver cette image-là.

A chaque fois que l'on veut reprogrammer un OAM pour qu'il fasse référence au bloc "page 4, image 21", on regarde l'emplacement VRAM associé, et on en alloue un en réutilisant un emplacement libre si le bloc correspondant n'est pas encore en VRAM. Avec 1024 blocs de 16x16, on peut avoir assez de pixels différents dans les sprites pour couvrir 5 fois l'écran de la DS. Le risque d'un objet invisible par faute de mémoire vidéo est virtuellement nul. Dans mon organisation actuelle, j'ai 128Ko pour les sprites, soit moitié moins, mais ça reste tout à fait viable.

Le côté génial du truc, c'est que tant qu'on alloue sur des blocs qui ne sont pas actuellement présents à l'écran (marqués comme libres), on peut faire la mise à jour de la mémoire vidéo pendant la phase longue où le GPU retrace les pixels à l'écran. Seules les substitutions où on est obligé d'éjecter un bloc utilisé lors de l'image actuellement dessinée devront se faire pendant la phase courte émulant un "retour de balayage".

Now, how would that work with Bilou's spritesheet ? I'm currently using about 1/4th of the video memory for Bilou's heads while only one is shown at every single frame. Streaming Bilou's head into a double-buffer as the animation needs it was one of my top improvements for AnimEDS. With a Zmiro-cache, I no longer need to allocate VRAM slots to GOBs. I no longer need AnimEDS updates. And potentially, I could have the whole set of heads used by the current animation in video memory, having only gradual updates of the VRAM as I switch between actions.

Alors, est-ce que ça marcherait avec Bilou ? Un bon quart de la VRAM est utilisé actuellement pour toutes ses "têtes" et une seule est affichée à la fois. J'avais bien l'intention de faire une sorte de "streaming par double-buffer de la RAM vers la VRAM" dans une révision de AnimEDS. Le Zmiro-cache permet de passer souplement d'un double-buffer à "seules les têtes utilisées dans l'action en cours restent en mémoire vidéo". Je gagne de la place et je peux (enfin) me permettre d'autres petites animations avec des grimaces, etc.

Les mains et pieds partagés par les crayons, les taille-crayons et Bilou ? Ils n'occupent pas beaucoup de place et ont de bonnes chances de rester présents en permanence.

Shared hands and feet (used by Bilou, pendats and dumbladors) only use a small area of the whole spritesheet. It's likely a 'least-recently-used' policy would keep them permanently in video memory. Bonuses, ink drops, dust clouds would likely come and go as needed, giving more room for ennemies frames.

How many ennemies could we host ? Well the critical point is more "how much VRAM slots will be off-screen at every frame?". If you have a free (off-screen) slot for every block you need to bring in for the next frame, then you don't need time-critical copies during the blanking interval. You have 128KB of sprites memory, which means 512 different 16x16 blocks. enough to cover 2.5 times the 256x192 screen of the NDS. The gameplay will become cluttered well before you hit the cache limits. 

Les bonus, gouttes d'encre et autres nuages-de-poussière-encore-à-dessiner ferait probablement des apparitions éphémères, forçant des objets dont l'animation tient plus déjà du "streaming" (p.ex. inkjet) à faire revenir une image de la mémoire centrale vers la VRAM.

Bref, vu le nombre de fois où je me suis "cogné la tête au plafond" de la quantité de VRAM disponible juste sur le projet "School Rush", introduire cette technique de cache pour gérer la mémoire vidéo serait sans doute la bienvenue avant d'envisager un jeu plus ambitieux ... disons de la taille d'un Commander Keen ?

Si j'étais graphiste ...

Si j'étais graphiste, mes sprites auraient plutôt cette trogne-là. Je saurais qu'une bonne animation, c'est une animation où on a pas peur de casser les cadres et j'arriverais à l'appliquer. Du coup, le meilleur environnement pour faire du bon travail, ce serait quelque-chose qui soit le plus souple possible. avoir suffisamment d'images disponibles simultanément pour les copier-coller et les comparaison. Bref, un outil comme SEDS ne me semblerait probablement jamais franchement pratique.

Let's be honest: I'm far from getting any close to what a real pixel artist produces. If I was, my spritesheets would look like those featured in Titus's Prehistorik II: I would not let canvas restrict myself and I would apply squash/stretch so that animations work fine. There would be significant pixels variation between frames, too. In a word, the SEDS+AnimEDS would be very unlikely to suit me. I'd need something more flexible, and in return, my game engine would need something to easily convert such flat sheets into usable assets.

Mais pour mettre des graphismes dans un jeu, faire des graphismes ne suffit pas: il faut aussi qu'ils puissent être intégré au jeu. Il faut que l'artiste puisse le plus librement possible retoucher son animation, y compris faire grandir ou rétrécir certaines images.

L'idéal pour ça, comme l'expliquait hier Eric Zmiro -- concepteur avec plus de 20 ans de métier -- c'est d'avoir le système le plus automatisé possible. Voici donc ce que j'ai compris du système qu'il décrit.

 I had the opportunity to compare the tools used in my own "School Rush" with the kind of tools and techniques that Eric Zmiro (now at Magic Pocket, and formerly developer of Prehistorik II at Titus). The core idea is to make the spritesheet-to-game data conversion as automated as possible. There cannot be any "great hotspot positioning tool" because there shouldn't be any human doing such task in first place.

From his explanations, I started to think about such automated framing tool, which is mostly a matter of separating lines that contain pixels from lines that contain none -- and having some conventions such as "an animation is bottom-aligned horizontally". Of course, there is still need to identify a reference position for each frame, so that e.g. the character's nose stays at the same position on screen while scrolling at constant speed, but a mere line of lone pixels could do the trick.

Sur base de la première planche de sprites, le premier algorithme à faire tourner est un système qui identifie les zones dans lesquelles il y a des images des zones vides. Une ou plusieurs lignes horizontale ne contenant aucun pixel (gris foncé): c'est une nouvelle animation. Une ou plusieurs lignes verticales ne contenant aucun pixels (gris clair) à l'intérieur d'une tranche d'animation: c'est une séparation entre deux étapes d'animation. On peut ensuite raffiner pour rétrécir verticalement la zone active d'un sprite.

1) on découpe les animations par planche (1 planche = 1 animation)
2) on a un outil qui capture les sprites, les convertie en bloc
3) quand un bloc existe déjà dans la banque des bloc, il ne le rajoute pas.
4) pour chaque sprite indique : [x, y, flipXY, color_index, bloc_number, size] (j'espère n'avoir rien oublié)

Si deux sprites sont identiques, ils seront partagés. Mieux, certains blocs peuvent être partagé même si ils appartiennent a des sprites différents
Encore mieux, des blocs peuvent être identique apres flip, ou être identique a une transposition de palette prêt..

Si elle me semble contre-productive, la décision "une animation par fichier" trouve tout son sens dans une équipe soumise à une date de sortie: sur une planche "prehistorik-man.png", on peut effectivement laisser le logiciel découper les bandes d'animations et faire référence à prun = pman[0][*]; pcrawl = pman[1][*]; pswim = pman[2][*]; pjump=pman[3][*]; etc. Mais imaginons qu'au terme de la production on décide finalement de laisser tomber le niveau aquatique. L'animation de nage tombe aussi et pjump devient maintenant pman[2][*]. Tous les autres animations doivent également être re-numérotée. On s'en passerait bien vu qu'il faut livrer la ROM fin de semaine pour que le jeu soit prêt début décembre...

But my understanding was yet one productivity-step below the Zmiro approach: by enforcing only one animation per sprites file, we now have a strong filename-to-game asset relationship. If the file is named pcrawl.png, then we can gather all the corresponding sprites as pcrawl[*]. When instead the 'crawl' animation is simply refered as the 5th one on pman.png, then we become vulnerable to the removal of e.g. 4th or 3rd animation, for instance because "well, the water level doesn't work, we drop the swim animation".

Yet, having the art split into multiple bitmaps doesn't mean that the tool importing them all cannot identify shared frames (or blocks) across the whole dataset. The final touch, for every frame the auto-cropper found, will be to isolate solid pixels into a minimum set of hardware-compatible blocks and pack the pixels of those blocks into tiles. The DS video chip, for instance, will only work with 8*W x 8*H blocks with W/H ratios of 0.5, 1 or 2 and a maximum size of 64*64 pixels. Even with a simple greedy algorithm, we can easily shrunk the amount of video memory required for a sprite to 1/3rd of the brute-force 64x64 sprite approach. Each batch of tiles has a companion set of OAM data that can configure hardware sprites' size, ratio position and indexes so that your 7 sprites actually look like a single, seamless cro-magnon protagonist to the player.

Reste à faire manger ça par le hardware d'une console comme la DS, qui ne fonctionne qu'avec des sprites hardware de 8x8, 16x8, 8x16, 16x16, 16x32, 32x16, 32x32, etc. jusqu'à 64x64. Sa mémoire est limitée, aussi donc avec un seul bloc de 64x64, le nombre de sprites affichables simultanément est sérieusement réduit. Ici, p.ex., on a un cro-magnon de 37x49 pixels qui prendrait 64x64. Avec un simpe algorithme de découpe "glouton", on peut le couvrir avec 4 blocs de 16x16 et 3 blocs de 8x16. Soit 6/16 de la mémoire nécessaire pour l'afficher d'un seul bloc.

AnimEDS travaille par petites éditions successives. Mais AnimEDS suppose que le contenu de la mémoire vidéo est constant. Ici, il n'y a aucun intérêt à garder un morceau de cro-magnon en mémoire si cette image-là n'est pas à l'écran. Du coup, tout ce qu'il faut c'est allouer un bloc de N tiles de sprites -- avec N assez grand pour la plus grosse étape d'animation -- et assez de blocs 'OAM' pour les contrôler. Pendant la synchronisation vidéo, c'est un nouvel ensemble "VRAM+OAM" qui est transféré simultanément pour changer les pixels que la console peut afficher et l'information sur quoi afficher où (les OAMs).

Then you need to have a game engine that can make the best use of these list of OAM datas. A real animator like those who work with Eric will easily saturate the 128K of sprite memory the DS has, so every new frame is likely to see new sprites tiles updated in VRAM together with the OAM updates. More on that in a future post.

Mais je ne suis pas graphiste. Il y aura encore pas mal d'eau coulant sous des ponts avant que je n'accouche d'un personnage pareil ... donc je vais garder SEDS et AnimEDS encore un petit moment. Par contre, si mon moteur de jeu évolue dans le bon sens, on pourrait envisager un outil d'importation des .png en .spr qui ferait ce genre de travail pour faciliter l'importation de graphismes non-SEDS dans un jeu tournant grâce à libgeds.

What's wrong with my spritesheet ?

Ok, this time, let's try to get that .spr file fixed. That's the right timing to get some framework that read and write .spr files on my host platform with the engine's C++ code.

You may remember this spritesheet captured some times ago, where 'striped'  tiles were suspected to be declared free although containing pixels ... It's a bit more complicated apparently: the tool building those spritesheets wasn't processing 32x16 blocks properly. The real "trouble map" (generated by the C++ tool) looks more like below: everything seems correctly aligned between the two versions. Well, everything except the last tile which is mapped on two different pages ...

Ouf. Longue semaine d'inspection du fichier de graphismes, avec un nouvel outil qui profite de mon système de test pour pouvoir utiliser directement le code du SpriteEditor pour faire l'équivalent d'un "chkdsk" pour les fichiers de sprites. J'en ai profité pour ajuster l'outil en PERL qui m'avait servi pour avoir cette "cartographie des problèmes" (ci-dessus) qui montre plus de problèmes qu'il n'y en a réellement (ci-dessous). En cause, les sprites de 16x32 (ou 32x16) qui n'étaient pas reconnus. Encore une petite étape de reconstruction, plutôt facile dans l'environnement PC, et me voilà prêt à attaquer les animations supplémentaires pour la récupération des power-ups.

It would be tempting to believe that with that double-mapped tile fixed, everything would work fine. For small blocks (16x16 pixels), the "blue-ish" free blocks would be used first, then the "red-ish" blobs (16x32 or 32x16 pixels) would be split by try_harder_alloc(). Except that splitting isn't allowed in normal allocations. In fact, if I can rely on cscope's output, splitting is *never* allowed.
Adding some more 16x16 sprites thus grows the file closer to its limit.

edit: Well, i finally decided to fix that by rebuilding the contents of the SpriteRam according to their appearance in the SpritePage, possibly duplicating whatever has more than one link. Since all animation definitions use : rather than a direct offset-in-SpriteRam, no additional work is needed. Good news.

School Rush "Fish16"

 

Here we go: the long awaited update on Bilou: School Rush game. Still only 4 levels, polished gameplay, improved menus for easier difficulty selection, and last but not least, improved software stability. I also fixed a couple of issues with level maps, esp. in level 2 that still featured a few excessively difficult things. More about that later on.

• A : use your feet (jump, stomp, float)
• B : use your hands (grab, throw, pick up, punch -- double-B)
• R : run (or kirby-like tap-press the DPAD) 

Don't hesitate to have a look at the instruction in the former release if you need additional help to run the game.

Enfin! Une version stable avec gameplay, niveaux et menu amélioré. Cette fois, tout le monde devrait être capable de sélectionner la difficulté (c.à.d. la vitesse de montée de l'encre) qui lui convient. Alors faites-vous plaisir, et essayez cette nouvelle version de School Rush!

• A pour les pieds (sauter, rebondir, planer)
• B pour les mains (attrapper, ramasser, lancer), double-B pour le coup de poing (si on l'a).
• R pour courir (ou alors, à la Kirby, avec un double-coup de DPAD).

The next BigThing (tm) is to complete HUD (or should I rather stay the status screen ?) and give better feedback to the player about available abilities like floating or punching. I thought about dust clouds, sparkles, palette blinks and many others, but given how tight I am currently with the spritesheet, something simple could be preferred. 

Pour la suite, il faut que je complète l'écran du bas, qu'il donne une idée claire de la vie restante, des power-ups, etc. Ce serait bien aussi que le joueur puisse "sentir" s'il a tel ou tel power-up sans quitter le jeu des yeux. J'ai déjà listé quelques possibilités, mais je crois que c'est à travers l'animation de Bilou que je peux faire passer ça au mieux... d'autant que ma planche de sprites -- en plus d'avoir à nouveau des clusters-croisés -- est méchamment remplie.

C'est vrai quoi: ça ne fait pas très sérieux, Bilou qui reste tout souriant à nous regarder alors que le crayon lui fonce dessus. Quelque-chose d'un peu plus street-fight-esque pourrait faire passer l'idée que oui, on a bien le punch-power là maintenant.

Watching the animations of last month, I figured out that something was missing with the ready-to-punch one: Bilou is waiting for pendat to approach and is ready to punch. Yet, he's looking at us, smiling and stancing rather than "feeling the tension of the imminent release of his super-power". I thought it would work better if the idle stance was adapted to this situation, and it could convey to the player the information that "yeah, you've got the power to punch, right here, right now" much better than any random sparkles could do.

Oh, and before you wonder, that's "Fish" because French-speaking people say "poisson d'avril" instead of "April fool".

Je brûle d'envie de faire essayer ça à Kirby Kid, Philippe Dessoly et Eric Zmiro, mais il manque encore ces quelques petites choses qui produiront une meilleure prise en main. A bientôt.

selective WiFi transfers.

My .spr files are becoming large. That's especially annoying when you remember that issue with DS-to-PC bandwidth issue, which I still haven't investigated more. Look at all that grey and all that purple: these are not used by the game engine. I started an evolution of RunMe where you could selectively transfer "tiles" or "sprites" or "animations" of one .spr file, and then reconstruct the whole file on the PC side, but it's dormant, waiting (yep, that one too) for the game to be properly polished.

Economiser des pixels

Imaginons un instant que je tente de faire l'animation du crayon-soldat qui court derrière Bilou juste en pixel art ... Il me faudrait avant tout gagner assez de place sur mes planches de sprites. Heureusement, les "1002/1024 tiles used" sont un peu surfaits. Si je visualise le contenu de la VRAM, les sprites colorés en rouge sont ceux dont je n'ai en fait aucun besoin. Ceux en vert sont ceux qui pourraient bénéficier du système d'animation par copie qui est à la base de l'encre-qui-monte.

This is the current content of the 64K of sprite sheet in the School Rush game. Sprites in red are unused and could be dismissed. Sprites in green are those who could benefit from the streaming technique (updating VRAM content as the frames advance. Given that I used only 6 16x16 blocks for the pendat so far, I could have the room for a pixel art running pendat, after all ...

School level delivered!

Enfin nous y voilà. 3 ans après 'Apple Assault', un nouveau jeu Bilou est sorti. Enfin, "jeu" est excessif: c'est une démo jouable comme vous auriez pu en trouver avec votre magazine PC-Fun préféré dans le milieu des années nonantes. Avec un seul niveau, il n'y a par exemple aucun moyen de reprendre de la vie ni de regagner des vies. J'ai pourtant d'excellents souvenirs de la démo de Prehistorik 2 avec son compteur de pourcentage d'exploration. Nous nous étions donc mis en chasse des dernières plate-formes invisibles et bonus cachés jusqu'à parvenir à un 100%. C'est ce genre d'ambiance que j'ai tenté de reproduire dans le niveau-anniversaire mis en ligne hier.

Looking back at the former releases and the completed todo lists initially left me with some bitter taste: since March, it looks like nothing significant has been achieved and that almost all the features were present in the "usability test demos". Reality is somewhat different. Even the month spent exploring SMW and incentives for "alternate path" was the key to level re-design. There *was* some significant progress on the reliability of my SEDS/LEDS/AnimEDS tools. when monsters are randomly altered after every save, when you have some animation that may disappear under some circumnstances, when the map may be erased by a misplaced click, the odds that you manage to craft a level featuring 20 monsters are weak. Shaping up to 54 unique animations is only possible with some convenient numbering scheme.

Hopefully, those 6 monthes made the tools reliable and the additional month made the level appear. Let's celebrate ^_^.

Et dire que depuis Mars dernier, il me semblait de n'être nulle part, puisque presque toutes les modifications apportées au moteur de jeu dataient de 2012. Et pourtant, du changement il y en a eu: tout ce "rush" sur le niveau-anniversaire n'aurait jamais été possible avec des outils aussi peu fiables que ceux dont je disposaient en début d'année, succeptibles de perdre ou d'écraser le travail accompli à la moindre fausse manoeuvre.

I was concerned about the lack of variety in my tileset. One book here, one binder there ... wooden structure, metallic items, spiky pencils. At the end of the level, I started feeling repeating myself. If a level 2 was required, I'd need more variety, shadows, and such similar things. That's especially blatant in those confined areas where the scrolling background is not visible. Hopefully, I'm not near 80% of tile space as I initially thought. I merely used 50% of the space, because many object got dismissed as "drafts" as I progressed (greyed/translucent areas).

Le niveau dans lequel on se promène tente de respecter le plus fidèlement possible le design d'origine (1994) créé par mon frère, mais remplace régulièrement les "clés" et les "interrupteurs" abstraits par des interactions entre personnages. Par contre, au niveau graphismes, je dois admettre que sur la fin du niveau, je tournais un peu en rond. Pour continuer à construire la School Zone, il me faudra d'autres objets. Et là, soulagement de dernière minute; je ne suis en fait qu'à ~50% de l'espace disponible. Du côté des sprites je devrais pouvoir compter sur le doublement de l'espace disponible (j'utilise 64K sur 128), mais il faudra "expliquer" ça à l'éditeur de niveau.

I will have to do similar cleanup in the "sprites" memory or upgrade to full 128K of sprites (the hardware allows it, LEDS won't like it :P) if I want to have the full set of animations of pendats with pixel art (initially, 3D was planned) or if I want to have spinning sponges once on the ground.

Quite amusingly, many aspects of the monsters behaviour where "hacked" during the release-rush through creative use of the current game engine and level editor -- such as undermining some platforms so that monsters see them as holes while Bilou can indeed walk them -- where I'd have in normal hobby development extended the game engine with dedicated features to support the desired behaviour (such as a monsters-wall that Bilou can move through).

Si je suis parvenu à boucler ce "niveau jouable" en 2 mois alors que je travaille sur la school zone depuis Septembre 2011, c'est entre-autres que je suis passé sur une autre approche: chaque fois que c'était possible, j'ai rusé (par exemple en trouant le sol sous les pieds des Pendats pour leur faire faire demi-tour à l'emplacement souhaité) plutôt que de chercher à étendre le moteur de jeu (p.ex. avec un mur invisible pour les monstres). à retenir.

Et maintenant ? Quand tous les confettis de l'anniversaire auront été balayés? Bien sûr il y aura un peu d'emballage nécessaire pour permettre à mes p'tits n'veux de faire leur propres niveaux: manuel d'utilisation, blocs supplémentaires pour les vies et les soins, par exemple. Sur une autre branche, proposer une réalisation de "Deep ink pit" malgré tout pourrait s'avérer sympa, encore que le concept du jeu n'était pas aussi riche que celui d'Apple Assault. Enfin, il serait temps de s'attaquer à la 3D, histoire de permettre aux crayons de poursuivre Bilou et d'introduire le fameux Bang Bash qui, en février 2006, introduisait le jeu vidéo Bilou dans la blogosphère...

Oh ... et il me faudra un écran "sound test" pour comprendre les effets curieux qui se produisent sur les musiques ces temps-ci.

ghost busting with spr2png.pl

No matter how much I improved SEDS, I still can't "optimize" my spriteset below 1024 tiles without messing up something. So I had to admit a disturbing possibility: maybe my tileset is *really* corrupted, and has been so unnoticed for some times ... maybe I'm suffering the equivalent of infamous cross clusters.

Let's recap: in .spr files, you find BLCK section that provides you the tile number for each block (logical entity) on that page. Then, you'll find one FREE section per "ram type" (block, sprite, streamed animations and drafts) telling you which tiles could be reused because you deleted its content. Good so far... except when they disagree.

Corriger ce spriteset de la school zone s'avère décidément plus complexe que prévu. Après une nouvelle série de corrections apportées à SEDS, toujours pas moyen d'avoir les bonnes images. En tentant de "rétrécir" les images, je me retrouve avec plusieurs sprites qui partagent les même données. Un vrai méli-mélo (in)digne du système de fichier FAT sur lequel tout celà est sauvé.

Permettez que je vous passe les détails techniques: il y a deux marquages des tiles occupés dans un fichier .spr (disons "vertical" et "horizontal"), et là, ils ne sont plus d'accord. Une stupide erreur au moment de sauver les sections 'FREE' des différents types de graphismes.

I already had modified spr2png.pl tool with a --cleanup mode that renders horizontal stripes accross tiles that weren't listed in any BLCK section earlier in the week, and now I've just added vertical stripes on tiles that are listed in the FREE section. We should thus see only solid sprites or 'dotted' tiles. But that's not exactly what happens: instead, I've got quite a lot of sprites with vertical stripes, that are thus supposed to be kept, but that could be erased as soon as I'll start editing new stuff.

My first mission, should I choose to accept it, will be to fix the .spr file so that all tiles stay safe. Then will come the hard stuff. Where in the code is the ghost maker... Have I forgot to adjust free lists when copying things around between spritesets?

Hopefully, not. It seems to be simpler than this: I have 3 FREE sections for the 'sprite' tileset. My bet is that I failed to set the proper spriteram identifier and have all "sprite, draft and streamanims free tiles" applied on the sprite tileset ^^"

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.

avant Bilou ...

Avant même Calimero, se basant sur Rick Dangerous, mon frère me sort un niveau pour un jeu de plate-forme mono-écran qu'il baptise "Logic Labyrinth", rempli d'interrupteurs et de pièges en tout genres. Le concept me plait et je relancerai l'idée plusieurs fois (chaque fois que je découvre un nouvel environnement de programmation, en fait). Logic labyrinth manquait d'un personnage, par contre. Il devait s'agir d'un "char de l'espace", ce qui ne passait pas trop mal du temps de LOCO 64, mais plus difficilement après avoir découvert Giana Sisters. Je vous laisse donc découvrir cette petite illustration millimétrée de deux protagonistes destinés à s'attaquer au fameux labyrinthe, qui doit précéder la rencontre avec Piek de deux ans au moins.
Une balle aux cheveux hirsutes et une asperge à casquette ... Eh oui. On reconnait déjà le tandem "Bilou et Bouli" même si le style n'a encore rien à voir. A noter que Bouli étant arrivé sur le tard, son 'look' a souvent changé au fil du temps. Il était de bon ton, à l'époque, de prévoir un deuxième perso pour le joueur qui prendrait la manette 2 (ah, époque bénie ou une manette de console ne coûtait rien ;)

The image above is the Level 1 for a never-realised game of mine : Logic Labyrinth. With a strong influence from Rick Dangerous, my brother imaged one vicious puzzle screen where a hover-tank would avoid traps and cleverly activate switches to reach its goal. Since I wasn't too happy with the "hover tank" idea as a character, i started investigating a funnier team: a blue ball and a tall guy with a cap. This all took place years before we met Piek and it could be viewed as the very first step towards Bilou and Bouli the way we know them today.
Over the years (I was roughly 10 at the initial attempt on Logic Labyrinth), I reviewed the concept several times, being somehow a fan of puzzle platformers. Drawing inspiration from Misadventure of Flink or Pushover, the game has been renamed "Mo, the sorcerer apprentice" or "Nono in the Maya Zone", but it never grew bigger than a dozen of lines of code.
première tentative, Bouli en "négatif couleur" de Bilou, mais tout aussi rond que lui, qui apparaît parmi les ennemis d'une "technical zone" très largement inspirée de la "Chemical Zone" de Sonic 2 (découvert début '93).
C'est peut-être un peu trop "cheap". C'était bon du temps de Mario Bros. ou de Chip & Dales sur la NES, mais plus à l'époque de Sonic & Tails où même Mario et Luigi commencent à ressembler à Laurel & Hardie.

Second essai à peine plus ancien: Bouli en tant que "Superlapin", sans doute inspiré de Mr. Nutz. Mon frère n'aime pas. On oublie. A noter qu'à l'époque, Bilou porte des gants et a encore des bras.

C'est à Sparenduin, notre "pépinière de jeux vidéos" que naîtront les habitants de la "Pipe Zone". Il ne manque plus qu'un sourire au Pipe Meccano pour se transformer en Bouli tel que nous le connaissons.

Et pour revenir au jeu Logic Labyrinth, il aura été "revu" à plusieurs passages successifs à Sparenduin, une fois en "Nono in the Maya Zone" (en avril '96, influence probable de Push Over) puis en "Mo, l'apprenti sorcier" (influencé par Misadventure of Flink"), mais je n'en ai encore jamais commencé une tentative de programmation "sérieuse".

Still on the 'historical' side, can show you the very first spritesheet of Bilou (still named 'Boudy the Bubble' when drawn, though the name 'Bilou' appeared that very day) that Piek brought us on September the 25th, while i was working on a "maze race" game. Just above, you can see a collection of "alternative designs" for Bouli, first as "color opposite" of Bilou (plus hat), then as "über bunny". None of them were kept (hopefully ^_^) and i'd be tempted to say that de "pipemans" designed to be baddies in the 'Pipe Zone' might be announciating the current design.

Quant au nom "Bilou", c'est au moment de sauver les premiers essais de course dans les labyrinthes (précurseurs de "Bilou RPG") sur diskette qu'il apparaît. Piek m'avait affublé de ce sobriquet tout au long de l'après-midi, il deviendra officiellement le nom du personnage quelques heures plus tard.

Dernière pièce de musée, donc, cette "planche de sprites" dessinée et apportée ce jour-là par Piek, où Bilou s'appelle encore "Boudy" ou "Bubule".

PS: Oui, désolé, je suis dans un trip nostalgico-historique cette semaine-ci. Je promets le retour du développement sur DS prochainement ...

edit Découvrez M.G.T, la source d'inspiration de Logic Labyrinth, dans Pix'n'Love #13.

BBL to .png converter

J'avais pris l'habitude de faire un p'tit cadeau sur Internet pour mon anniversaire, et là, pour mes 30 ans, schnol. Avec les travaux dans la maison et le retour de Suisse, je n'avais rien à montrer. Quelle idée saugrenue m'a pris ce midi? Aucune idée. Mais je vous offre un petit script de conversion des fichiers graphiques du Recreational Game Maker (.BBL, .CBL et .MBL) vers des .png, plus pratiques à manipuler. download bbl2png.pl exemple d'utilisation :

perl ~/DS/SEDS/runme/bbl2png.pl /tmp/TOYZONE2.PAL /tmp/%.MBL m%.png --sprites

Here comes some pixels dump of sprites i've been working on in '97, at the peak of my RSD Game-Maker years. Each level had its very own tileset and spriteset (though there might be much shared things between two levels in the same "zone"). Behold Badman III, most likely the more complex (and unfinished) project with the RSD-GM ever. I finally managed to write a small ".BBL->.png" conversion script, meaning that i can retrieve *all* the graphics from all our previous games. 

Ca veut donc dire que je peux récupérer tous les graphismes de Badman et autres pour vous les montrer... Je doute qu'il y ait grand-chose à en tirer à part de la nostalgie ... j'ai tant appris en matière de pixel art, que même mes "plus jolis" boss sont tartes "by today's standards" :P En vrac, donc voici quelques sprites tels qu'ils sont présents dans la démo jouable Badman 3 (Badboyz are Back!). On y découvre "Ratman", d'après un T-shirt de T-Bob, qui ne sera finalement pas repris comme boss de la Cheese Zone. Juste après, Burner "relooké" qui laisse derrière lui une trainée de feu quand il court, avec un shading un peu douteux. Enfin, le gris aux oreilles rondes, c'est le "ratman" tel que vous pouvez l'affronter, avec son astro-flasheur "kirsch" et ces attaques de roues de gruyère.  

In "Badman III: Badboyz are Back", you can play either with Badman or Rubishbin (who you saved in "Badman II: Out of This World") in three insane environments: the Cheese zone, the Toy zone and the Ice zone. Each character had unique abilities giving them access to hidden areas. Rubishbinn, for instance, can do a spin-jump that destroy some blocks below him while Badman can dash under low roofs. I also reused the technique developed in Badman II for creating shooting bosses. The result was near to an unmanageable nightmare that turned short as I entered university: with only 5 playable levels, Badman III games already lists 44 'levels' in the game editor. 

Ce serait à refaire, je prendrais le "ratman" initial comme PNJ genre "Je suis le seul maître légitime de la Lune Fromagère, et je délivrerai mon monde de la tyrannie des BadBoyz ... Enfin, si tu veux m'acheter des grenades Petit-Suisses ou des Camemberts lacrymogène, ... " Et oui, le volet 3 de Badman était franchement inspiré de la mécanique de jeu de Megaman ... Suit l'Ice Zone, dont les monstres sont pas mal inspirés du niveau des glaces de Prehistorik II (auquel je rejouais cet été-là -- juillet '97 selon le .zip -- en version complète). 

On y retrouve donc un le fameux pingouin et un eskimo dont je n'étais pas peu fier à l'époque et un "lemmings xmas" qui était là juste pour le fun. Ce genre d'apparition était d'ailleurs assez habituel dans la série des Badman : le bonhomme-promo de Belgacom, Moktar sur son tapis volant, une bestiole rampante "façon Commander Keen", des p'tits robots tout ronds "façon twinbee land", une souris bleue mécanique "à la sauce Alfred Chicken", etc. Vous remarquerez aussi "Rex", le chat (private joke) utilisé dans des "cut-scenes" façon "Kirby's dreamland". Le mamhout vous paraît bizarre ? logique. 

Le game maker de Recreational Software ne supporte qu'une seule taille pour les monstres: 20x20. Un monstre plus gros est indestructible par nature et construit à l'aide de plusieurs monstres que vous tentez de déplacer de manière synchronisée ... ce qui se traduisait généralement par un désastre complet. Allez, je vous mets aussi Badman "himself" et son compagnon d'aventures "Rubish bin" ... On est plus très loin d'un extracteur de niveaux complets, avec les autres infos dont je dispose déjà 

PS : mon frère possède aussi une mine de petits "trivias" sur le développement des épisodes de Badman, qu'il reconstitue a partir des commentaires de ses .S3M ... Si vous êtes fan, bonne lecture.

.spr

Okay. Let's say you've downloaded the latest SEDS version and gave it a try. You loved the pixel art you've drawn and hopefully pressed START + R + A to save them on your media card. Then you either transferred them with runme or simply used a media card reader to retrieve them.

SpriteA.spr at the card's root. Most likely to be your drawings. As a matter, it is.

But what are you going to do now with that .spr file that your file explorer doesn't know and that do not open in Graphics Gale, Photoshop or whatever other spriting program you could think of.

If you are a "power user", you may already have perl installed or find it not that complicated to install. In that case, you're suggested to install the Image::Imlib2 package as well so that you can run spr2png.pl conversion script directly on your machine and have your sprites converted in a more user-friendly format.

If you're just a regular user, or if you haven't used SEDS often enough to find it is worth that much installation trouble, you still have an escape route: the brand new online conversion tool that can convert your art into a regular .png file with just the help of a regular web browser. Just select the picture with the "browse ..." button, click "post" and wait a couple of seconds to have the script doing the conversion and replying with the picture.

Have Fun ... i also submitted a "job offer" on sourceforge to find someone willing to write a batch conversion tool for Windows ... wait'n'see.

Costz dit : Mais on peu récup les sprites dans un autre format que le tien ?
Je veux dire y a un convertisseur pour que l'on puisse avoir au final une .png ou .gif ?

Oui, tout à fait. Il y a tout d'abord le script spr2png.pl qui, moyennant installation de perl et du module Image::Imlib2, permet de convertir tout ça localement sans soucis.

Et pour ceux qui auraient du mal à installer tout ça sur un Windows (sous linux, c'est juste apt-get install libimage-imlib2-perl), ou qui voudraient tout simplement essayer le sprite editor sans se prendre la tête, j'ai bricolé un convertisseur en ligne: tu uploades ton .spr et tu reçois le .png en échange.

PS: j'ai les sources en Perl du convertisseur et une esquisse du format de données avec le convertisseur en ligne. Je cherche quelqu'un qui connaisse la programmation windows (C, C++, VB, C# : tout est bon) pour écrire un convertisseur "user friendly" pour les wutilisateurs.

Si vous êtes partant, contactez-moi : pype_1999.geo@yahoo.com.

Petits Pas

vouaip. Petit progrès sur SEDS, qui sait (enfin) effacer ce qui ne vous plaît plus. C'est pas ultra-ergonomique (pressez R pour activer le curseur, déplacez le curseur sur le bloc qui vous déplaît puis pressez X pour l'effacer), mais ça marche.

Il faut dire que pour l'instant, j'essaie au maximum de me concentrer sur un fichu article reprenant mes travaux de thèse pour un journal, et qu'en plus, j'ai du faire une "pause sans écran" pendant une ou deux semaines, mes petits yeux ayant dit "stop, on en peut plus" :-/

Bref, je vais vous laisser vous rendre compte que j'ai pratiquement triplé la taille de mon post précédent (sur l'appleman), uploadé plein d'images et tout, et aller porter le dernier Maliki à ma fée avant que Morpheus ne l'emporte. Moi j'attaque les robots d'Asimov ;)

Enfin, avec tout ça, j'ai enfin réussi à "réparer" mon tileset de forêt et j'en ai profité pour faire un peu le ménage (virer les vieilles pommes et les souches qui ne servaient plus à rien ;) Restera à pouvoir "extraire" les anims et autres sprites, mais ça, ce sera une autre histoire, parce que là, je suis impatient d'essayer d'implémenter les tiles pentus.

*edit*: oh, et j'ai réussi à faire de "spr2png" un convertisseur reconnu par Image Magick. prochaine étape, en faire un vrai type mime reconnu par gnome et les autres ^_^

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)

Woods In Progress

Thanks to some awesome guys at pixelation, my little woods are progressing rather nicely. It's not always very easy as i cannot manage to come with decent pixels with PC tools only, so i need PC-to-DS and DS-to-PC conversions quite often.

After Zeid and tehWexxlorz convinced me (and helped me) to re-think the look of Bilou himself, after Zeid (again) bringing me to give those trunks another try with a "more interesting palette", after Ichigo pointed out how to get a coherent contrast/lightness/saturation over the whole forest, i'm now trying to follow Lackey's advices (and a bit of AdamAtomic's too) to get a fresh new look for my treetops. The picture above, for instance, was a print out of Lackey's edit (bottom) and my first attempt to re-produce it with a simple "bunch of leaves" shape (top).

Les conseils glanés sur Pixelation commencent à devenir porteurs ... Après la révision du look et des couleurs de Bilou (grâce à Zeid et theWexxl0rz), les nouveaux troncs d'abres et l'ajustement du contraste du décor (grâce à Ichigo), c'est au tour des feuilles d'en prendre pour leur grade. Je me suis d'ailleurs imprimé les commentaires de Lackey (image d'en-bas sur la photo d'en haut ;) et ma première tentative avant de ré-importer mon gros feuillage tout plat pour le remanier avec SEDS.

This is a definite departure from the "minishcap style" that i wished to follow initially, and imho, it's not really a bad thing. Unfortunately, i don't have anything like a "level map exporter" so far, so all i can offer you is a screenshot of the level editor showing you a new tree i've been working on yesterday.

Comme vous le voyez, on est bien loin du style "minish cap" imaginé au début ... Ceci a un look ... plus commodoresque, je dirais. Et je vous prie de me croire que j'utilise à 200% mes deux plans de décor sur ce coup-là! Il me faudra d'ailleurs un "copier/coller" sur des zones entières dans l'éditeur de niveau si je veux pouvoir continuer dans ce sens-là.

Pretty nice, but pretty hard to do, and fully using my two layers of background tiles. I will really need an "area cut&paste" tool in the editor if i'm to live with trees like that.

I don't know how you like it. Personally, i think it has some kind of C64 look, and that i still lack some alternate tiles to avoid getting something that shows collection of leaf balls next to each other ;)
Oh, et côté code, j'ai une autre bonne nouvelle à annoncer, mais vous attendrez que ma petite illustration soit faite ... na.