le nouvel arbre

Avec les tests effectués pour les-racines-auxquelles-on-s'accroche, j'en ai profité pour faire une petite capture d'écran de l'arbre tel que je suis enfin en mesure de le faire apparaître dans le jeu ... Je pense que vous ne l'aviez pas encore vu. Pas parfait, mais honnête, je dirais. (et oui, j'ai vu: il reste des caractères foireux tout autour... C'est une map de récup, si vous vous souvenez ;)

edit: ces caractères (étoiles) sont invisibles dans l'éditeur de niveaux: il s'agit d'une portion de la mémoire utilisée pour les animations qui se retrouve visible parce que la map fait toujours référence à des numéro de tiles qui ne sont plus dans mes pages.

There are tests ongoing on my devstation with Bilou hanging to a root in the greenzone. They've been behaving rather weirdly lately, but they're taking place in that recovered-vertical-level once drew to test load-level-two feature.

And that means at some point, I was bored of seeing non-sense flashy tiles at the start of every attempt, especially since I've drawn some more leaves tiles last year. But you had never seen them, because I had never used them. Well, now it's done. they're not perfect, but here they are.

furblock de montée

La dernière tentative d'améliorer la branche s'est plus ou moins soldée par un échec constructif. Puisque le week-end de montée m'offre un peu de répit, je vais partir sur une idée qui m'est venue en passant en revue les autres jeux avec des éléments de gameplay similaire: commencer par me faire un "bloc-note" à la SMB3, qui se concentre sur le mécanisme, pas sur l'animation. Et une fois que le mécanisme sera validé, je fait la même chose avec un objet invisible.

So trying to combine physical motion and animation for the bouncy branch proved to be a bad idea. Rolling back. I'll keep my satisfying animation and combine it with an invisible block behaving like the "note block" of Super Mario Bros 3 instead. And I'll prepare that with non-invisible block in an easier-to-test environment, that is the pyramid room.

• premier fix: je dois retirer les zik.import de mon script pyrat.cmd: ces commandes sont propres à la "trhee rooms demo" qui pré-charge un module de base (bilou.xm) et runMe ne connaît pas (encore) l'équivalent, même après recompilation du dernier modèle
• deuxième fix: runMe a besoin d'un "../spriteB.spr" explicite pour aller chercher le nouveau fichier (et pas un vieux fichier de SchoolRush dans efs:/moving/spriteB.spr ^^")
• 3eme fix: ma petite anim' faite à la main doit utiliser la SpritePage 8+2 (parce que le fichier bilou.spr préchargé contient 8 pages)

Bon on y est. J'ai un "furblock" dans le niveau-test de la pyramide. Je saute dessus et il s'enfonce bien puis ... il décole vers l'infini et au-delà (ç.à.d  -2147483648). Ah oui, et il n'a encore un tête de fury que sur DS, pas sur l'émulateur. 

J'ai utilisé pour le réaliser un nouveau contrôleur "grille" qui indique si on est repassé au "bloc" suivant, histoire de passer d'un état "repoussé vers le haut" à un état "repoussé vers le bas", et que le bloc finisse par se stabiliser à sa position d'origine. Mais manifestement, ça ne marche pas encore.

There have been a few "setup" issues, leading to a few TODO items to be processed later (this season?) in my notebook, like runMe not supporting the multi-music commands and the lack of "translate to that sprite page" macro for multi-spriteset that leads to annoying magic numbers. But I have to admit that even with that done, the behaviour was fairly surprising. Well, on the DS, the "furblock" did a downwards bump and then skyrocketed to negative numbers: I needed something to fire an event when the original position has been reached. And that thing could be the "grid" controller that was part of my "how to code bosses" arsenal.

But even with that, the resulting behaviour is emerging and perplexing. I guess I haven't found the proper set of rules yet.

Et nous voilà le week-end d'après encore plus au calme, ce qui m'a permis de décortiquer avec InspectorWidget le comportement émergeant (mauve) et de trouver les corrections (bleues) nécessaires pour que ça marche pour de vrai ;)

Special thanks fly to Wye for his SMW-remake-howto video and how it reminded me that the Springy note block exists in first place, and how they were perfect match for the feature I was looking after. ^_^

Appleman 2.0

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

RES_BGTILE_SUB

Peut mieux faire. Une soirée de débugging et une heure de chipotage par essai/erreur pour parvenir à avoir la LimbsTable sur la gauche de l'image qui fonctionne correctement, il n'y a pas vraiment de quoi être fier. D'autant qu'il ne s'agissait pas cette fois-ci de coder un nouveau widget mais bien de réutiliser quelque-chose qui avait déjà été développé pour le LevelEditor!

Not really proud of how my SpriteTable widgets completely lack ease-of-use. It took me one evening debugging and one extra hour of trial/error coding to figure out how I should instanciate the "limbs table" for the animation editor. And that's not even some new widget: merely an attempt to reuse something that was built for the Level Editor a few years ago. And the resulting initialisation code is ridiculously complex:

La difficulté d'obtenir une petite partie des tiles pour un usage dédié est anormale. Voyez plutôt:

SpriteSheet limbsheet(BG_GFX_SUB + 0x4000 +
  Engine::allocate(Engine::RES_BGTILE_SUB,2*16)*32,
  BG_PALETTE_SUB,0x8000/64);

Alors qu'on aurait voulu pouvoir s'en sortir en écrivant limbsheet(Engine::RES_BGTILE_SUB,32). Et celà sans prendre en compte le besoin de reprogrammer le mode vidéo de l'écran "sub" (par défaut régler pour faire des zooms comme dans le SpriteEditor) et le "calque" sur lequel seront dessinés les différents membres (par défaut affichant des caractères ASCII en 16 couleurs).

Et il est temps que ça bouge, histoire que je puisse donner vies aux "petites marionnettes numériques" imaginées par mon frère pour divertir les loulous.

edit: okay. That seems to work, now. At least, I've got limbs displayed on the left and the according spritepage shown on the right when one limb is clicked. Ready to start working on the "Frame Editor" widget. But the code is still ugly.

edit++: it looks like making it "easier to use" will be required to turn the RightTable into a TileTable as well ... and that might be required to be able to display sprites on the FrameEditor.

raymanim.spr

Ma fée et ma loupiote sont chez Mamy Laine ... j'en profite pour bricoler mon éditeur d'animation. La version améliorée du script "imlib2spr.pl" (capable d'importer les images du RSD game-maker, souvenez-vous!) m'a permis de récupérer des têtes et des corps de Rayman, mais pour les mains et les pieds il me fallait de préférence du 16x16.

C'est l'occasion de rendre enfin fonctionnel le script sprtool.pl destiné à importer des spritepages d'un spriteset à l'autre. Me voilà donc armé d'un "raymanim.spr" pour tester le code de mon éditeur d'animation sans devoir (re-)passer par la case "pixel art". On devrait gagner du temps.

Using the scripts I developed in late October last year and some bug-fix on the sprtool.pl script that was longing for revival since 2008, I managed to build the perfect test-case for the in-progress animation editor: a rayman spritesheet with head and body as 32x32 sprites and a set of hands/feets as 16x16. This time with my beloved PSX sprites :P

(PS: Rayman est un personnage (C) Ubisoft, apparaissant ici à titre de "fair use" (pour ceux qui aurait passé les 100 dernières années dans un auto-cuiseur au fond de l'océean))

SpriteRam, SpriteSheet, SpritePage, SpriteSet

Ce week-end, c'était priorité au montage des étagères dans mon petit bureau de 7m³, mais j'ai quand-même pu me concentrer un peu sur les petits soucis de gestion de mémoire qui me ralentissaient dans l'écriture de mon éditeur d'animations.

Pas étonnant que 3 ans après, je m'y perde un peu ... SpriteSet est commun à tous mes projets DS: c'est en gros le support du format .spr généré par le sprite editor. Mais les données graphiques qu'il manipule se sont étoffées. Les SpritePages ont été introduites en 2007 pour permettre d'éditer plus que ce que l'écran de SEDS ne peut afficher d'un coup. Les SpriteRams, en 2008 pour compenser le fait que la mémoire vidéo de la DS est séparées en "caractères" et "sprites".

I *had* to set the priority on some furniture assembly this week-end, to make my "7m³-desktop" a place where I can actually focus on what I do. Yet, I found some time to meditate on the VRAM allocation issues that were preventing me from doing progress on the animation editor. We're talking here about a set of classes that was initially designed to manipulate a single VRAM bank directly and that started to be multi-purpose (game engine + editors), multi-sets (manipulates set of sets of sprites), and that embraces ram heterogeneity (VRAM + main RAM). No wonder I was baffled.

In the case of the animation editor, the various "limbs" may use different spritepage (at least, 16x16 limbs may not reside on the same page as the 32x32 limbs), and at least for building miniatures on the timeline widget, those pages must be accessed simulatenously although there might not be enough VRAM to hold them altogether. I added a few methods to SpriteSet to address this situation in an almost clean manner.

Pour le moteur de jeu, l'ensemble des sprites est chargé en VRAM et les SpritePages servent uniquement à la construction des animations. Pour les éditeur, par contre, le contenu graphique (et donc SpriteRam.target) est généralement présent en mémoire centrale, et la VRAM est plutôt affectée aux SpriteSheets.

Pour AnimEDS, il ne me suffit plus d'avoir une seule "page" présente et affichée: les différentes étapes d'animation vont utiliser des éléments issus de différentes pages, parfois pour les afficher séparément, parfois pour les combiner. Les cogitations du week-end ont donc suggéré d'ajouter une fonction unique SpriteSet::getdata qui partage une partie de la fonctionalité de SpriteSheet::getdata mais qui peut récupérer n'importe quelle image du fichier .spr en mémoire à partir du seul numéro de page et numéro d'image dans la page.

N.B.: ça fait beaucoup d'espace "gâché" sur la gauche. J'imagine que 16x16 serait suffisant pour choisir un composant...

SEDS Multipage

ah, y'a pas à dire: c'est agréable d'avoir un environnement de développement capable de mises à jour rapides ... En quelques coups de cuiller à pot, j'ai pu, hier soir, goupiller la première version de SEDS capable de gérer des fichiers .spr multipage. Enfin la possibilité de dépasser 48 sprites en un fichier (ça devenait vraiment problématique) et de réorganiser mes petits dessins par thèmes (un seul fichier pour toute la forêt, avec une page contenant les blocs de terre, une pour les arbres, une troisième pour les pommes, etc.)

Wow, needless to say, it's really a good thing to have software update to speed up application development. Just a couple of edit-compile-update loops were enough to brew the first version of SEDS that can manage multi-page .spr files (which had been tested in runme a couple of weeks ago). That means i can at last break the "48 sprites per file" limit and reorganize my own tiles theme-wise, e.g. grouping all the forest-related tiles with one page for dirt blocks, one for the tree trunk & roots, anoter one for in-progress tree tops, one for the apples, and so on.

C'est aussi un premier pas vers la possibilité de mélanger des blocs 16x16, 8x8 (pour les pieds et les mains de bilou, entre autre) et 32x32 (l'encrier).

Bon, ceci dit, pour l'instant, les réorganisations sont pénibles au possible, mais c'est juste parce qu'il me manque une interface pratique pour ce genre de tâche :P

Et il a fallu faire tout celà sans que les aventuriers qui avaient téléchargé la release d'hier ne se retrouve temporairement avec un programme inutilisable suite à un update malencontreux... ce qui n'a pas été sans mal :P

This is also the first step towards the ability of mixing 16x16, 8x8, 32x32 (and other sizes coming) resolutions in a single editor/spriteset, which will be crucial to go on working with Bilou's world. Well, right atm. "reorganization" is as tedious as moving files using MS word, but that's still better than no reorganization at all :P


Allez, ça mérite bien une "0.2"

sprtools (t.a.g.)

Wow. You've gone through all the posts about my own tools for my own SPR file format ! I'm impressed.
It may sound an odd idea to run your own file format when doing a video game. This is mostly motivated by the odd memory structure of the DS video chip, tiled to the bones. '.spr' file are mostly a VRAM dump with IFF-like headers, created by my SpriteEditor. "sprtools" are all the PC-side programs that manipulate those dumps, converting, extracting, recombining pixels and checking more complex data structures embedded within the file, such as the list of "free tiles" within a chunk of video memory.