Furry Blocks

Depuis quelques années, mes p'tits croquis pour la zone du désert/pyramide font intervenir des "boules de poil" supposées servir de blocs-à-casser dans le level design. Si ça marche assez bien dans les carnets de croquis, en revanche, je n'étais toujours pas parvenu à sortir quelque-chose de convainquant en pixel art.

Et la vue "en perspective" n'aide pas franchement. J'avais étudié la manière dont les graphistes de Fury of the Furries avaient réussi à rendre leurs bonshommes "poilus" malgré leur petite taille et leur palette limitée... Mais la transposition au style DS ne donnait pas grand-chose. Trop plat. Trop contrasté.

I've been drawing "Furry blocks" for the pyramid levels for nearly 5 years now, so it's about time I get something to render them on-screen in my upcoming desert zone. Unfortunately, it is unexpectedly tricky to come with something convincing. I studied Fury of the Furries and many other materials, but none of them was satisfying once converted to DS screen.

J'ai essayé quelque-chose sur base d'une reconversion de mes blocs verts

Mais voilà. Je n'étais pas satisfait du résultat. une espèce de "brique" avec des poils qui pendouillent par-dessous. ça colle du point de vue du style graphique, mais pas avec le genre de personnage recherché. Retour à la planche à dessin...

The best I had until last week looks a bit like a hairy brick, rather than like a furry block. Then I realised how fool I was to try and fit it into a 16x16 frame. After all, if some hair protrude either upwards or downwards, I could still use the art, and it would even be fun to animate them to react to player's motion.

J'essaie du coup un nouveau modèle, partant de l'idée que si les poils-qui-pendouillent traînent sur le bloc d'en-dessous, ce n'est pas vraiment un problème. Ce serait même rigolo de les animer pour réagir au passage de Bilou (p.ex. pendant la course). Ce n'est pas encore complètement à mon goût sur la photo ci-contre -- à la limite le tout-carré est mon préféré.

So I tried to apply some Infogramesque moto "go for the look you want, and we'll make the code accomodate for it afterwads". It looked nicely, although it's sttill a bit too high on the screenshot. Since then, I reduced the height to make it look more like the one on the right, and added some hair on its "forehead". I was pretty happy with it. Almost proud. Then my brother came and declared the brick-shaped one was its favourite ...

Mais à ma surprise, c'est le modèle "brique" qui a la préférence de mon frangin. On va veiller à ne pas l'effacer trop vite, du coup.

Amélioration Spongebop ...

Je me suis amusé l'autre jour à imaginer comment les SpongeBops pourraient être plus interactives dans le jeu. Les faire flotter sur l'encre, bien sûr, mais aussi les transporter comme les dumbladors. Et pourquoi pas s'en servir également comme d'un "parapluie" contre les jets d'encre ?

So far, we can grab spongebops while they're swinging, and use them to reach higher places ... but that requires significant learning of the game mechanics. Dumbladors can be used to detach them but so far, it doesn't bring much difference. I wanted to add "carrying" and floating, which is now ongoing. I'd also love to make carried sponge a protection against falling ink droplets...

• [done] pick up and throw spongebop
• [done] spongebop floats on ink
• [done] ink droplets stops on spongebop
• [done] pendat turns back when walking into a spongebop.
• [todo] floating makes spongebop move up and down
• [done] stands on floating spongebop. Don't bounce.
• [done] better physics when thrown
• [done] Bilou stays hung when Spongebop is jammed.
• [done] blador-like virtual walls to avoid Bilou holding the spongebop from far away.

Petit voyage dans le temps.

Petite image de ce que donnait la School Zone en QuickBasic en 1997... Que dis-je "image" ! presqu'une animation.
Côté Pixel Art, on regrettera évidemment les briques rouges rendant le crayon-soldat quasiment invisible. Côté animation, c'était impossible d'accélérer la démarche du crayon. Je ne suis pas mécontent du progrès réalisé ces dernières années.

Look! That's what the school zone looked like on its first implementation, in QuickBasic for MS-DOS in '97. I'm glad I took time to digest advise from Pixelation folks. 

I swear I'll never use plain red as a background colour in later games.

 

Stack'm'up!

totally totem !

Commencer par les choses simples. C'est ce qui m'a permis de progresser en fin un peu sur le systèmes des plate-formes dans mon moteur de jeu, malgré des semaines bien remplies. L'objectif: permettre d'empiler des dumbladors l'un sur l'autre pour que plus tard, Bilou puisse lui aussi grimper sur un dumblador puis sur des objets qui bougent.

C'est un bon premier pas, même si dans l'immédiat, le taille-crayon du dessus ne se rend pas compte du "démarrage" de celui d'en-dessous, ce qui m'a permis de l'envoyer à son tour par-dessus le premier.

that was too much for one chunk.

At last, I've got one more step performed on the game engine. Too many times, I picked up my laptop after the kids when to bed to end up watching things on youtube or hunting for a new car. Somehow, getting at once into "Bilou riding some platform" was intimidating and I couldn't get things in place. When picking up my notes again this morning, I wanted to come back to small steps that can be chunked with a single tea cup. How about having Bilou able to stand on a stunned blador and call it a milestone ? As I started converting blador.cmd into the new cpp-assisted format, it turned out that I could get something even simpler to check the bare mechanisms: having stunned blador stacked onto each others. Well, tonight it's done.

Oh, and I'm afraid you'll have to wait somewhat for my "Critical Link" series comparing the gameplay of 2D Zelda games: my scanner has apparently entered the dark world of non-functioning appliances.
PS: it's easy to explain the fact that the "stacked" blador stays in place: I was missing the "attach to path" statement. More annoying: the new GameObject::ride() method was built under the assumption that Gob's movement in (dx,dy) would be consumed, which is not the case with dumblador's stepped movement.

2D + 3D = ^_^

After some clean-up and tweaks, I got the 2D+3D setup properly initialised in my test level. Nothing useful rendered so far: just a NeHe tutorial triangle that rotates as you press the DPAD in various direction without interfering with the 2D game. I still have to re-arrange memory banks before I can get textures, though. And I'll have to move around the owl-school background which was currently mapped on the "BG0" layer, the only one capable of 3D.

Quelques règlages ici et là, et j'y suis: un premier polygone (non-texturé) affiché en symbiose avec le moteur de jeu 2D. Tout ça fonctionne évidemment mieux quand on essaie pas d'activer la 3D à 3 emplacements différents dans le code. Je vais devoir à nouveau ré-organiser quel-layer-est-utilisé-pour-quelle-fonction ... ça devient un brin lassant, je vais faire une couche d'abstraction, ce coup-ci.

That starts sounding like I should introduce an abstraction layer so that the following things manipulate a "logical background" rather than physical registers directly:

• setting up map/tile VRAM addresses in GameScript
• scrolling registres in InfiniMap
• setting priority in runme

There was activity about the controling log display this summer ... It should allow me to flip between BG and log quite transparently.

edit: huzzah! it works!

edit: game engine fix is done. Runme adaptation will have to follow (and will likely be a bit more tricky). Real bugger will be the "fade sequence" which used BG1 (now used as "farground") to hide the screen content while re-loading the level ... I'll have to use another technique like window registers.

20 ans!

Il y a 20 ans, Bilou voyait sa première aventure esquissée sous les crayons de mon frère d'après les programmes CPC de Pierrick. J'ai fait de mon mieux alors pour transformer les "idées papier" de mes ainés en lignes de code et en pixels, mais la School Zone m'avait tenu en échec: le niveau de complexité dépassait ce que mes outils pouvaient supporter, menant peu à peu à la mise au grenier du projet.

Gain speed to break through that pencil barrier.

Aujourd'hui, je prends ma revanche avec ce homebrew pour Nintendo DS qui vous emmène à travers le dernier niveau dessiné par mon frère avec les monstres de Pierrick. Plus vous ramasserez de bonus, plus on vous emmène loin dans le temps...

That's it: the anniversary level celebrating the 20 years of Bilou video game sketching, design and coding is ready to play. At last, Pierrick's ennemies and my brother's level come to life and challenge you to gather all the letters scattered through the chemestry classroom. The more you get, the further we take you back in time. Can you make it back to 1993 ?

A: sauter et rebondir / jump & bounce
B: attraper et lancer / grab & throw
Bilou can run faster if you do a sharp turn back (tap left and slide to the right to run to the right). You can bounce on monsters by tapping A just when stomping them.

Pour courir vers la droite, pressez d'abord la croix vers la gauche puis glissez le pouce vers la droite. Pour courir vers la gauche, faites l'inverse. La "barrière crayon" peut être traversée si Bilou tombe d'assez haut.

Playing on the Real Thing
You need a DS and a linker device that can play homebrew files. With most linkers sold after 2007 (that support DLDI), all you'll have to do is drop the .nds file somewhere on your media card and launch it as any game.

With older linkers, you need to patch the .nds file manually using the driver compatible with your hardware. If your hardware need patching and you haven't patched, you'll see the bottom screen displaying only purple background with the words "NODA!" written in the middle. (and other boot info around).

Playing on an emulator
You're suggested to use desmume and follow these instructions to set the "GBA slot image" as being the .nds file itself. Other emulators (notably iDeaS, patch as R4TF) will require manual DLDI patching (see above). You'll get a better experience with a SNES-like gamepad.

Known Bugs/limitations
Although it's an anniversary, it's also a first release. There are things that are not visually consistent and room for improvement. It was however decided to release early and that those features would be left for future levels/releases.

edit: fix anniversary-G88 released.

"J'vais chercher mon frère à la guerre"

Quelques blocs repris du niveau, les pieds et les mains de Bilou, les yeux de l'encrier et en 10 minutes me voilà avec une assez chouette animation du crayon qui marche au pas dans le bas de l'écran d'AnimEDS... prêt à aller rejoindre les gommes sauteuses et les éponges dingues dans un niveau-anniversaire pour Bilou ^_^

With multi-palette system and clean eyes/hands/feet sprites it only took me some 10 minutes to come up with a first animation of the pendat ... Just what I needed to build the "anniversary level" one step further. I pretty love how AnimEDS allow me to come up with dynamic animations... I'll have to reverse-tutor this one ...
(I shall not replace emulator screenshots with mobile phone real shots -- I shall not
replace emulator screenshots with mobile phone real shots --
replace emulator screenshots with mobile phone real shots -- I shall not ...)

AnimEDS updates

Holly Bells! I don't think I've been waiting so hard for holidays since I graduated 0_0.
And to celebrate that, here's the new "running" animation built in AnimEDS. I also animated Spongebop and added a few animations to inkjet, but there seems to be issues with AnimEDS itself, and which slot it decides to save your current work to, so those got overwritten ...

Aah! Des vacances! enfin! Voilà une petite animation de Bilou occupé à courir réalisée dans AnimEDS. Profitez-en bien parce que je risque justement d'être occupé un bon moment à corriger le code d'AnimEDS qui me fait un peu trop de farces à mon goût. Du style "tiens, et si j'écrasais la dernière animation vue avec la dernière animation éditée avant d'enregistrer le fichier sur la carte mémoire }:-D"

Let's recap the required upgrades so far:

• [1145] use some overlay to show which limb is currently pulled, and make sure pulls are properly reset when loading an animation.
• [1141] fix thumbs in the thumblist. set them to the content of the first frame everytime an animation is saved if needed.
• [1142] fix the multi-sprites thumb generation, and automatically set the scaling factor for the 16-32 pixel sizes used in Bilou when that would be enough (i.e. frame fits a 32x32 bounding box)
• [done] ensure setting "delay=1" in the animation editor means 60 frames/second. Otherwise, "split" time doesn't work properly.
• [done] ensure we can hide *all* the crosschairs so that frame editor isn't hiding things and can preview the animation nicely.
• [tryit] don't pause on the "animation terminated" pseudo-frame, and directly hop to first frame, for smoother looped animation edition.
• [dream] crosschair that gets its due alpha-blending. -- there's no support for Sprite/Sprite transparency.
• [1143] allow edition of color 0 and use that to tune the background colours. 
• [1146] ensure we don't overwrite data when we've just loaded a new .spr file
• [1141] don't overwrite data when saving animations.

Premier encrier.

Enfin! le premier encrier qui se promène dans le jeu de Bilou. Je n'étais jamais arrivé jusque là dans la version "BASIC". Voyez vous-même (.nds homebrew).
Maintenant, on va *vraiment* pouvoir commencer. L'encrier doit pousser Bilou, le repousser en cas de collision en l'air, mais aussi emporter Bilou.
Inkjet floats around, special blocks (not yet invisible, for debugging reasons) guide the path followed... I'm ready to start with the "new collision" mechanisms. And I'm curious to know how many times you manage to jump over the 48-pixel pencil in a row.

(Et si vous allez vous promener à la gauche de la map, vous pouvez essayer de sauter par-dessus le crayon de 48 pixels pour remplir le Quizz de la semaine.)

edit: bon, bin c'était pas franchement le poll qui ait attiré le plus de participation, mais avec la puissance du saut de Bilou revu légèrement à la hausse, les obstacles de 48 pixels de haut devraient maintenant offrir juste le bon dosage de difficulté.

XMAS School Demo.

Here's the new demo. I hope I'll be able to add some screenshots and stuff, but my Internet access is currently down. I've managed to fix the memory corruption problems that prevented to reload the level when Bilou "dies", so here you go.

Voilà enfin la démo promise. Bilou se promène dans les nouveaux graphismes de l'école, il saute (A), assomme les dumbladors, puis les ramasse, les transporte et les lance plus loin (bas). Une erreur de gestion de mémoire m'a obligé à rallonger la phase de debugging. Pour ne rien arranger, je me suis retrouvé sans connexion Internet pendant presque toute ma semaine de congés, du coup, c'est une release "en aveugle", goupillée à partir d'un .nds sur clé USB lors d'un passage-éclair pour reprendre du jus de fruits au bureau ^^".

Since it's a "blind release", I had no access to my todo list, so I couldn't remember I still had a bug with Dumblador recovering just on the left of walls. If you do that, it will remain stuck. (Fixed in SchoolTest-GoT.zip)

Press A to jump and stun bladors, then press "DOWN" to grab them and "DOWN" again to throw them in the direction you're facing.
START enters the pause/debug mode, which you leave by pressing L+START.

throwing bladors

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

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

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

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

10: GOTO 10

To be honest, I didn't expected it to be that complicated to fix, with a lot of trials and source reading (on my shinynew Cybook) to figure out why the code behaved differently than I expected. But at last, AnimEditor is now able to set "sticky limbs" on the first frame of an animation as well, which in turn enables me to craft a walking animation for Bilou in the editor.

I took the time to document the thing a bit more, too. The trick is that I have two representation for the animation: the tlist that is a sequence of TIFrame at specified time positions. This is just perfect for editing, as each frame fully encode the state without any reference to past/future state. The game engine needs just the opposite: a list of commands that instructs it to move that limb, change the sprite used by this one, then move the whole sprite by x,y pixels and wait for 3 vertical refreshes. All these commands are encode()d into flat 32-bit integers that are easy to read and write to files. When exporting them, frames are compared and updates are generated when required. When importing, the last generated frame is copied after every delay and altered to reflect the new state. So far so good.

Bien. Voilà un deuxième point règlé dans ma "roadmap de l'été": je peux créer une animation qui déplace le personnage à chaque "frame", y compris entre la dernière et la premère image, lors du "rebouclage". Je vais (enfin?) pouvoir améliorer la marche de Bilou grâce à AnimEDS :) Ça ne fut pas aussi simple que je l'avais pensé, celà dit ... croyez-moi (ou apprenez l'Anglais :)

It gets a little more complicated with the "sticky limbs" thing. The editor needs to know which limb sticks at the same place on-screen. You do that by selecting one of the limbs on the leftmost "limbtable" and then pressing the "time/move" button just between the frame editor and the animation preview (highlighted on screenshot), which initially just reads 'time'. If you decide to move dumblador's sticky foot further to the right, dumblador will move faster, and if you move the foot closer to dumblador's body, it will slow down its walk.

At the export, the offset of the sticky limb compared to the previous position of that limb is used to generate a "I_MOVETO" command. Devil was in the details, as always: when should the information be cleared when reading back, how to handle the commands when a TIControl item is selected, and whether the additional I_MOVETO has to be stored at the end of the serialised animation or before all the other update commands.

Well, I got it more or less sorted out now. All I'll need is improve the walk animation itself and patch bilou.cmd so that it makes good use of it.

AnimEDS: l'écran "fichier"

Le menu "fichier" a pas mal été révisé avec la version 0.3 d'AnimEDS. Ca vaut peut-être la peine de passer les nouvelles fonctionnalités en revue:
Pour enregistrer une animation et en commencer une autre

• pressez (START) pour passer en mode "fichier"
• utilisez le DPAD pour choisir un slot, puis pressez (Y) pour y sauver votre animation
• choisissez une autre animation et presssez (A) pour la prévisualiser
• pressez à nouveau (START) pour revenir au mode d'édition

N.B.: (A) sauve l'animation en cours d'édition dans son slot d'origine. Pour abandonner les dernières modification et charger une autre animation, pressez (B).

Pressez (R)-(R) en mode 'fichier' pour sauver de façon permanente votre fichier sur la carte-mémoire. Alternativement, (R)-(A), (R)-(B), (R)-(X) et (R)-(Y) permettent d'enregistrer sur un des fichiers de travail précis.

Define your own character
That's a major new feature added with AnimEDS 0.3: you're no longer tied to a pre-coded character structure. You can come with a fresh .spr file you've drawn with SEDS and proceed as follows:

• use '-' and '+' buttons to define how many component your character will have
• use '>>' and '<<' buttons to navigate to the proper sprite sheet, touch the picture you want to use as "thumbnail" for a component, and finally L-touch the limb in the limbs table on the left.
• repeat this process until all the limbs have a picture defined.
• click 'OK' to start a fresh animation with that skeletton, or L-click "OK" to resume edition of the current animation with the updated skeletton.

N.B.: the order in the limbs table also define priority among limb sprites.

modifier la structure du personnage:
L'éditeur prépare un personnage à 2 mains, 2 pieds, 1 corps et 1 tête. Chaque "composant" est associé à une palette de sprites (la "sprite sheet" sur la droite) et ne peut utiliser que des sprites appartenant à cette palette. En revanche, plusieurs composants peuvent utiliser la même palette.

• utilisez les boutons '-' et '+' pour définir le nombre de composants dans votre nouveau personnage.
• pour chaque composant, déplacez-vous vers la bonne palette à l'aide de '<<' et '>>', puis touchez du stylet le sprite qui servira de "représentant" pour ce composant et L-touchez le composant en question dans la table de gauche.
• répétez l'opération avec les composants suivants jusqu'à ce que le personnage soit entièrement défini
• cliquez sur 'OK' pour commencer une nouvelle animation avec cette structure, ou cliquez en maintenant 'L' enfoncé pour retourner à l'animation en cours en appliquant les modifications de structure.

N.B.: l'ordre d'apparition dans la table de gauche défini aussi la priorité relative des composants (p.ex. 1 main et 1 pied par-devant le corps, 1 main et 1 pied par-derrière, et les yeux par-dessus tout).
Truc: une fois la structure définie, positionnez les différents composants pour une image fixe que vous enregistrez immédiatement (START-Y) avant de commencer à animer. Enregistrer votre première animation sur un slot différent de façon à pouvoir facilement commencer une 2eme puis une 3eme animation en repartant d'une structure déjà dégrossie.

Manage your animations
Once in the "file" area, you can move the cursor on the top screen with your DPAD to select an animation slot. In v0.3, you're given 48 slots where you can record animations. By default, your "ongoing" work is nowhere yet in those slots, but the program remembers where it came from. So,

• (A) will save current work where it came from, and load the selected slot
• (B) will drop current work, and load the selected slot
• (Y) will overwrite the selected slot with your current work.
• (X) should clear the selected slot, and keep your current work untouched (experimental feature).

When saving your work to a file (with START-R-[ABYX]), the program will automatically write back your current work into the slot it came from.

Back in time ...

Well, I still have to work on a few aspects to make AnimEDS more comfortable to work with before I start using those new animation in the game engine. But at last, the "core modification" of how the timeline is managed is fixed. Pauses and loops can be visualised and manipulated. Do you like their "musical" style ?

vendredi soir} Bion, j'ai donc réussi à faire une version minimale de l'augmentation de délai. Encore un peu trop minimale, puisque je suis obligé de sauver l'animation puis de la recharger pour que le délai fasse effet ... bizarre, bizarre ...
samedi} Ou alors il suffirait de "valider" l'animation ? ...
dimanche} Allez, on re-génère la version compilée de l'animation lorsqu'on clique sur la preview, et on en parle plus. Mais pourquoi diable mes petits contrôles de boucle n'apparaissent-il pas ?
lundi midi} ça y est. Les contrôles apparaissent. La ligne du temps reste ordonnée quand j'y déplace un cellulos. On va pouvoir passer au prochain point sur la todo list ... la transparence ou les zones de collisions ?

update on BG colors.

So that's the tileset as you know it so far. Used in "greenwoods demo" and "Apple Assault". It took me a few more missed attempts while trying to blindly copy Eyecraft's colours but I finally got it working... And what made it work was to build up a mockup first (the small image nearby) with BG, FG and character tiles alltogether in such a way that contrast issues became obvious. Once in that setup, with a 32x32 area to focus on where all the important things were there, I could bring the BG colours down, almost to grey, although keeping the blues with a higher value (blues and purple = dark, cold shadows. That's how our bluesky world and cone-rod eyes work ^_^)
Ingrédients: un tileset pas bien coloré, un sprite de référence, un éditeur capable de cloner des couleurs et une pinte de bonne humeur

1. Créer une nouvelle Sprite Page et y copier l'intégralité des tiles à recolorer
2. Copier également les tiles qui doivent avoir un bon contraste et le sprite de référence (personnage principal du jeu).
3. Superposer l'arrière-plan et l'avant-plan en utilisant sur-chargeant avec (B) en mode curseur plutôt qu'avec (A). Construire un mini-mockup avec les tiles ainsi obtenus.
4. Sélectionner un des tiles d'arrière-plan, cliquer sur "SCAN"
   
5. Clicker sur une zone de la palette encore vierge pour définir la destination des couleurs clonées, puis L-cliquer sur le bouton [+] du sélecteur de couleur (QuickPal). Clicker sur "SYNC" pour valider les nouvelles couleurs.
   
6. Passer la grille en 32x32 et charger (R-déplacer le curseur-A) la zone entourant le personnage.
7. Basculer en mode "édition de palette" (SELECT)
8. Ramener les couleurs clonées vers du gris. Vérifier sur la zone de preview en gris que le contraste est suffisant.
9. Clicker sur "okay" pour prévisualiser les modifications sur l'ensemble de la page, puis validez en cliquant sur "sure". Retourner à la grille en pressant à nouveau SELECT
   
10. Si nécessaire, pressez "START" et utilisez les boutons "<<" et ">>" pour faire apparaître en vis-à-vis la page avant et après modification. Clicker sur un tile "d'avant" puis L-clicker sur un emplacement "d'après" pour effectuer le transport.
    

See that horizontal area between [+] and [-] under your spriting grid ? This is the QuickPal widget. when you click [SCAN], all the colours present on the grid are copied there. "cloning" the colors consist of copying those colours at an alternate location in the palette. You first pick that target location by touching the palette widget, then launch the cloning by clicking [+] while holding L shoulder button of your console. All the tiles on your working sheet (on screen) will then use the new colours. All the remaining tiles are unchanged, included the backup copy of your working sheet, meaning that you can reimport some old tiles if you need to do so.


PS: ce blog comprend maintenant exactement 600 posts (dont 55 brouillons :P)

Goro mode activated

There are still a few things that are unpolished, such as (sprite-based) widgets that remain sticky between the FileWindow and the AnimWindow ... or whose state isn't coherent among the two. But at least, the basic feature is there: you can expand your "character" and give him more limbs if needed. Look at this 4-handed Mr. Egg, for instance. Isn't he wonderfully promising of future fun ?

Bin ça n'aura pas été une semaine très causante, sur ce blog, hein ? Que voulez-vous, c'est qu'en-dehors des "grands travaux", il y a parfois une série de petites choses ingrates qui n'ont droit qu'à une ligne dans une todo-list et une autre ligne lors de leur commit SVN. Mais ce coup-ci, les epsilon se sont additionnés suffisamment pour devenir un delta: je peux (enfin) modifier la "structure" de mes personnages (le nombre de sprites utilisés, les pages parmi lesquelles choisir les images et l'image de référence) depuis l'application DS elle-même. Il reste encore pas mal de nettoyage à faire pour éliminer les incohérences de l'application, bien sûr ... mais on a fait un bon pas en avant.

On s'approche déjà de la release 0.3 ... bonne chose.

• [bugfix] : la "petite main" réapparaît quand je sélectionne qqch dans la spritetable de droite, AnimWindow
• [bugfix partiel] : si je réouvre une animation 2-mains, elle est "promue" animation 3-mains-3-pieds :P
• [now] : si je sauve par START+R+R, l'animation en cours n'est pas réécrite dans la feuille d'animations avant la sauvegarde (et donc pas sauvée).
  

Almost done ...

As soon as you realise that the DMA unit of the nintendo DS cannot manipulate whatever is on the stack because the stack (DTCM) is basically connected directly to the ARM9 cpu and therefore not accessible through the system bus, it gets easier to debug the rest of the code.
It required some cleanup and head-scratching, but at last I have thumbs for the frames rendered on the timeline and a similar thumb for each animation slot rendered on the upper screen. All I still need to get done for release 0.2 is now to allow multiple animations to be saved ... Oh, and I might also need to check that the sprite editor can manipulate the pixels of a .spr file without trashing the animations it contains.

errm. Wait ... I might need something to preview the animation as well ^^"

Yahoo!

Hey! Regardez: c'est Rayman ... reconstitué sur l'écran de la DS. Il y a encore un paquet de choses à régler, mais c'est la première compilation de mon éditeur d'animations qui permet de positionner les différents "membres" sur l'écran! Wouhouu!

Howdy! It works! It's still for sure full of bugs and needs a lot of polish and fixups, but for the very first time, it works: I can drag the different limbs of rayman to actually make it look ... like Rayman! No idea how long it will still take for release 0.1, but it's über-motivating, for sure ^_^

• [done]refernce position should be the *center* of the limb
• [fixed]moving a limb above the area will hide it definitively
• fix the "selection hit" area
• [done]double-sized frame editor
• [done]enable selection of an alternate sprite for the limb.
• [done]save frame and edit the next one.
• [done]visual confirmation of the selected limb
• [wish]preview animations by sweeping the timeline (?)
• [done]actual thumbs on the timeline
• [done]1x animation preview
• [done]buttons for flipping limbs
• [done]arrows to move to the previous/next frame
• [done]arrows to precisely set limbs
• ensure there's no collision between sprites for timeline and sprites for other widgets.
  

TimeLine : public Widget

Okay... l'éditeur d'animation prend forme, mais on est encore loin du compte. Disons plutôt que j'ai enfin une base sur laquelle travailler le comportement de la "ligne du temps". C'est terriblement "prototypal" ... arithmétique de pointeurs pour configurer les sprites, et tout le tintouin. Il y a sans doute moyen de faire plus propre, mais je vais le garder tel quel jusqu'à ce que les éléments soient tous en place et que j'y voie un peu plus clair.

Slowly, the animation editor is shaping up. It's still far away from the objective, but at least I have now a more solid base on which I can work on the "timeline" widget behaviour. It's still very sketchy : pointer arithmetic circumvent the lack of proper OO containers or patterns ... but at least I can make the thing exist, grow up, and have a clearer view of what I still need.

A running list of things to work on:

• [done] new frames added on the timeline can easily go out of the allowed width for the widget.
• [done] moving frames along doesn't affect the animated version.
• [done] we don't have any visual confirmation of the frame we selected.
• [past] animation always start with a delay and can't end with a delay.

Last Minute Panic...

Mouais. Pas si finale que ça, finalement, la version 1.4 d'Apple Assault. En tout cas, elle mériterait bien un bugfix. Un conseil si vous devez faire une pause, fermez la console un niveau, pas entre deux niveaux. Disons que le suivi d'un pattern pour déclencher des actions sur certaines lignes n'aime pas trop qu'on laisse le pattern tourner sur l'ARM7 pendant que l'ARM9 est mis en veille.

It looks like the final release of Apple Assault might need some more tweaking, finally. Anyway, if you need a break during the game, close the lid within a level and not between two levels... You've been warned. Well, let's say the TrackSequence that follows an XM pattern launching actions such as clearing the screen and loading a new level isn't that happy when you suddenly freeze the ARM9 that executes commands while the ARM7 keeps playing the music :-/

I tried a trivial workaround, that slightly improves the situation. But it's not improved enough : there is an interference remaining between fading-out and fading-in actions that may leave the screen partly obscured for the next level >_<

Je croyais contourner le problème facilement mais ce n'est pas si évident: la preuve, le jeu n'est plus bloqué, mais il y a eu interférence entre les opérations avant-veille et après-veille ... et du coup, l'écran reste à moitié noir :P

Par contre, j'ai pu faire une petite démo à Pierrick et Parmy ... et ça, c'était bien chouette ^_^

edit: corrigé