Un p'tit bug?

Dans l'éditeur d'animation, dernière mouture ? Je m'explique, je voulais prendre quelques captures d'écran pour expliquer comment se faire un petit personnage à partir de "composants" simple, puisque la "branche tutoriel" sur github est maintenant capable de gérer aussi bien les personnages simples que composés.

Malheureusement, un des widgets (normalement sur la gauche) n'affiche plus rien. Particulièrement ennuyeux puis qu'il s'agit en fait de la "palette de composants" qui permet de sélectionner un pied, la tête, le corps, etc.

J'ai du louper quelque-chose lors du refactoring.



Doing some bug-hunting on AnimEditor so I could do a 'setup your compound character' tutorial for the github tutorials series. Some flat facts:
- the thumbnails are on the "sub" screen, the timeline and sprite pages preview are on the main screen.
- the 'limb table' is actually rendered, but only on BG3, which appears to be hidden.
- clicking limbs properly switch sprite pages
- clicking the sprite page does weird things with the cursor on the top (sub) screen.
Oddly enough, if the layer with limbs table is hidden, how comes we see the sprite page ?

Somehow, it looks like the widget I'm using to show what is selected when clicking on the sprite page was hard-wired to the sub-screen, instead of letting the window creating it telling which resource to use. That's easy to fix.

It also looks like AnimEditor didn't get its dedicated LayersConfig, and still use the default layers setup combined with some custom register programming. That doesn't help. And we still see the SpritePage because, unlike the limbs table, this one is truly made of sprites.

Finally, it looks like the 'limbs table' is initially empty. It only fills when I drop new sprites there. It should be pre-loaded with the animation's skeletton when I load an animation.

So, some more flat fact:
- in the old approach, fill_anim_thumbs_16() is the code that copies pixels from the spriteset into a spritesheet used by the limbsTable. Exactly one 'block' of data per limb.
- only other calling site fill_anim_thumbs_16() is AnimWindow::restore().

Q: do we still call fill_anim_thumbs_16() on FileWindow::event() ?
A: yes.
Q: what is the target spritesheet then ?
A: one pointing to main-screen background tiles.

Q: did loading an anim changed the limbs table in medsgama.nds ? 
A: no. Only "opening" the animation on the AnimWindow did. And it still does. With a spritesheet using some main-screen BG memory.

Tuto branch update.

A few weeks ago, I found myself pressing the direction pad of my DS to keep
that little character onscreen. It had the most basic behaviour could think of because its sole purpose was to demonstrate how we control things in my game engine. Somehow, it felt a bit like an empty level in Space Taxi.
today, that same character moves around a place that comes from the level editor, with blocking tiles effectively blocking you. What it misses is a target. Snake-like pellets, if you want.

That requires me to revise:
- collisions between Gobs
- counters
- in-game level changes.