Tuesday, April 26, 2011

UI revision for AnimEDS

Puisque mon petit éditeur d'animations marchait plutôt bien ce week-end, j'ai voulu le faire essayer à ma fée et à mon frère avant une petite "pre-release" destinées à nos charmantes têtes blondes en mal d'inspiration pour jouer aux playmobils. C'est là que je me suis rendu compte que le programme avait tout de l'instrument de torture:

  • il faut maintenir L enfoncé pendant qu'on déplace un des composant de l'animation. Ca devient fatiguant pour les poignets au bout de 10 minutes d'utilisation, et ça demande de sérieuses contorsions pour un utilisateur gaucher >_<
  • sans confirmation visuelle du composant sélectionné pour le déplacement, les choses deviennent franchement hasardeuses dès que l'on superpose certains éléments
  • pour passer au cellulos suivant ou précédent, il faut impérativement cliquer sur la ligne du temps, ce qui empêche de faire des corrections rapides sur une animation complète.
  • On déplace fréquemment un objet par erreur. Il serait préférable de pouvoir le renvoyer à sa dernière position.
Operating the animation editor turns out to be a pain. I mean physically: you feel strain in your wrist after some 10 minutes. I need to revise a few things, and I intend to do that revision while focusing on the primary function of the various widgets. For instance, moving limbs around -- not selecting them -- is the primary function of the FrameEditor, and therefore, this must be the action bound to GUI_TOUCHED. I also need to ensure that it will be possible to quickly revise the movement of one limb along a given animation, which isn't possible right now as you need to have the timeline selected for that purpose.

Bref, je vais devoir revoir ma copie: je n'ai pas prévu de faire de cet éditeur une arme paralysante.

Friday, April 22, 2011

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 ^^"

Tuesday, April 19, 2011

C++ doesn't help!

I really feel the lack of any "package" protection level in C++. Every significant new piece of software triggers some hide-and-seek problems that must be solved before the code can actually get written. Something like saving animations and re-loading them, for instance.

I struggled with "how I could share the animation data so that AnimWindow doesn't have to know the details of writing to files, but that FileWindow doesn't need to know the details of animations structures... Then came the ghosts of deep object copy and reference counting bats (they are quite frequent in the caves of poor design).

Curieux, non ? Dans la petite "todo list" basée sur les premiers essais sur DS, aucune mention de "sauver l'animation créée" ... C'est pourtant la fonctionnalité primaire qui manquait encore et qui devait recevoir la priorité. C'est qu'à nouveau, on touche à "qui peut manipuler quoi" dans le programme, et le C++ n'aide vraiment pas dans ce domaine-là. Par moment, j'en viens à regretter la "visibilité par package" du Java. C'est dire!

Hopefully, a light sparkled in the darkness: I needed animation data to be shared by the two windows, but that didn't mean the objects must be accessed by the two. The animation being edited can remain held in AnimWindow::tlist and AnimWindow::anim, as the other components won't edit frames or timeline. And that allowed me to apply the coding practice that works the best for me: interfaces. All I need is that AnimWindow offers a iAnimHolder to the rest of the software. That interface serialise the current animation into a vector of information with the only constraint that it must be easy to reconstruct the editable object. pfew.

From that point on, things went better: it was a mere matter of mimmicking the Scream Tracker's approach to pattern compression: if value is repeated, don't repeat it. Bare "unsigned" encoding command-class, command (e.g. move limb, delay, change sprite ...), object identifier (which limb, usually) and leaving 16 bits for the actual data (number of frames to wait, sprite reference or pair of coordinates relative to the "center" of the frame editor) was enough. And they could naturally be packed into an large DataBlock before being pushed to a .spr file.

Heureusement, à force d'accumuler les tentatives UML, j'ai fini par constater que les besoins de AnimWindow::tlist ne sont pas similaires à ceux de ThumbsWindow et FileWindow: seul l'AnimWindow doit manipuler les animations en tant qu'objet. Pour le reste, il me suffira de "stocker" les animations pour pouvoir les resservir plus tard. En somme, il suffit que l'AnimWindow offre une interface de sérialisation/désérialisation et rien de plus.

Comme la sauvegarde et le chargement de fichiers .spr prévoyait déjà la possibilité de manipuler des blocs "de données inconnues", le reste n'était que pure formalité: voilà donc AnimEds capable de sauver et recharger une animation. Encore quelques widgets et on pourra en manipuler autant qu'on veut et passer de l'une à l'autre comme s'il s'agissait de simples sprites.

Oh, btw, if you missed the post "animation editor 0.1", it has been translated earlier today.

Sunday, April 17, 2011

Animation editor ... 0.1

La bonne nouvelle, c'est que mon éditeur d'animations est plus ou moins au stade 0.1: on sait à présent définir une série "cellulos" en déplaçant les membres du personnage et les passer en revue avec le DPAD. Si ça manque encore un peu de finesse et d'intuitivité, la fonction primaire est là.

Good news first: AnimEDS has reached what we can hope for version 0.1: you can select limbs by touching them on the FrameEditor widget, move limbs around on a frame by holding L, press Y to save that frame and proceed to the next one, etc. Once you're done, just click any frame on the timeline and then use 'UP' and 'DOWN' on the DPAD to preview the animation. No way to save it, though.

Where things gets less funny, is that although I can provide you a download link for the app, I cannot ship the raymanim.spr file that turns it into a "raymanimator" -- not without the blessing of Michel Ancel or Ubisoft. And so far, some parameters of the animation (such as the number of limbs, and which one is on which SpritePage) are still hard-coded, so even if you had the time to draw the limbs for another character (I can't afford it right now), you would have hard time planning its use with AnimEDS :-/

La moins bonne nouvelle, c'est que même si je fais une release du programme, il restera inutilisable. La sélection des "membres" dans un fichier .spr est pour l'instant encodée en dur dans le programme pour coller avec mon fichier "rayman.spr", et sans l'accord d'Ubisoft ou de Michel Ancel, je ne peux pas distribuer ce fichier... Dommage, parce que je connais plus d'une tête blonde qui se serait bien amusé à faire faire quelque mouvements à ce personnage bien sympathique. Alors évidemment, je pourrais vous proposer un autre personnage de mon crû avec lequel jouer au marionnettes. N'étant pas graphiste, celà risquerait de me prendre un temps de dingue. Il faudrait peut-être que je lance une annonce sur Deviant Art ou Pixelation ...

Friday, April 15, 2011


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.

Wednesday, April 13, 2011

FrameEditor ...

Dilemme, dilemme ... Dois-je continuer à présenter mes avancées (par petit pas, temps de midi oblige) au risque de lasser avec des micro-news ou attendre d'avoir "quelque chose de plus significatif à dire" au risque que les infos se perdent dans des "edit+++" de mes posts précédents ? Je me lance: je suis prêt à attaquer la programmation "sérieuse" de l'éditeur de sprite modulaire -- à savoir la zone centrale dans laquelle on devra pouvoir manipuler les différents composants (ici de Rayman, plus tard de Bilou ou de ....) pour définir une des étapes d'animation. Enfin ... "je" suis prêt, mais au vu du message "FRAME SET TO null".

Should I stay or should I go ? If i stay (for more coding) there may be double (or triple) "edit: ..." and coding comment in some former posts ... but if I go (for some blogging), you might get bored by some micro-news. Well. Let's go anyway. I think the "preliminary checks and cleanups" for the multi-limbs animation is done. Widgets are present and responding. I can now focus on the actual coding of FrameEditor widget -- the central area where you'll move limbs along at the touch of your stylus to define the individual frames of the animation before you "store" them on the TimeLine.

The amount of "flesh to bring to the bones" might be more than just one "handle()" and one "event()", though, as it looks like there isn't any 'frame' object to edit (yet). I'll check that out later on: lunch time is over.

Monday, April 11, 2011


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 +

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.

Saturday, April 09, 2011

Sehr Gut.

Haa. Deux publications soumises (en co-auteur, mais c'est toujours ça). Je vais *enfin* à nouveau avoir un peu de temps à moi... enfin, si j'arrive à lâcher "Auf Wiedersehen, Monty" :P

Duty fulfilled. I can now (at last) have some hobbies again. I'll resume programming on AnimEDS, hopefully.

Monday, April 04, 2011

Deep Ink Pit: "Backstory"

Nous voilà en plein milieu de la School Zone ... Bilou va avoir besoin de l'aide d'un encrier vétéran et de sa plume volante ... mais celui-ci n'est pas dupe.
la lettre d'introduction de Maître Pad ne suffit pas: il veut une preuve tangible que Bilou est bien le héro légendaire qu'il prétend.

Well, this is not exactly "necro-posting", but yet, these pictures were waiting in the "draft" subjects since May 2010 ^^" ... and they were likely drawn from a long time ago by then, since the chose-your-game poll of January 2010 was already featuring the concept of Deep Ink Pit. And I know these small sketches, between design document and comic book, were drawn as the concept of the Deep ink Pit was forming in my mind.
I bet that's the best I can do tonight to make you forgive me for being so much overwhelmed with work that I can barely give you a blog update ...