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.

Bowels of the Memory Manager ...

With cases stacking up, I got used to ignore all those testimonies that pretend that "Malloc is the killer, I've seen him". I wouldn't trade Malloc's skin for my oldest pair of gloves, as he's always the first one people blame.
Bah. People. What do they know about crime, after all...

Hopefully, I have other noses for such cases, so I paid tracemem.pl a visit and showed him the shots Coroner GDB gave me from the victim.
At first, Tracemem pretended to know nothing about that laying frame... he always does, until I provide him hexadecimal evindence he can't deny, as the victim's and suspects addresses.
"Free(man) is cheating you", he finally dropped, panting. "Look at those figures: these are not even addresses. I have no idea what this is, but this is certainly not addresses".
"When you've got no idea, Tracemem, it usually means you've seen them last week. I don't need idea, I need info. Tell me what you know".
"Okay, okay" he added "take it easy... You shouldn't mess up with those guys, really. They're trading bare hex they compile themselves in a hideout they name "AnimEDS". They say they can make you move in ways you've never experienced before. I don't have anything to do with these guys, right ? I just serve drinks when people order. I don't want any trouble".

I'd lost almost half a week, and all I know is that the last address where Free had been seen is fake, and actually a room in a building owned by someone else in the AnimEDS gang. Not yet enough to get the cavalry moving. I had need for another vision of the problem. I went to Doc Xygen and showed him the remains of GameScript. "I want descriptions", I insisted, "don't puzzle me with line numbers". I didn't tell him that pictures in malloc.h were made up from archives, but that's the best way to make him sing. With his usual frenzy, Doc Xygen started to show all the connection he could find. Among the expected ones, however, there were surprising exchanges. "Wait, SpriteSet got some cans from Malloc and directly sell them back to Free ?" I asked.
"Elementary", the Doc said, "SpriteSet is low on stack. With only 16K brutto, he's got to rent space to Malloc&Free for his loading activities on the docks.
Nothing to worry about. But ... hmmm ... *this* is interesting", he said, drawing a red circle around a triangle of pictures among the boxes and arrow he had scribbled all over the desk. "Interresting?"
"Clearly", he said. "Look, GobAnim and GameScript both tried to sell back some cans to Free, a few cycles from each other! Both pretending that they had the exclusivity on products by A'n'Im Eds"
"So they would have a tussle next to Free's place just as Malloc was going out!?"
"Of course", added the Doc. "Malloc gets back the cans that Free buys to the dockers, optionnally clears them and sells them back to other dockers. Everyone blame them, but noone else has cans to provide ..."

I fixed my hat and thanked the doctor: Malloc & Free's dubious activities are none of my business. I had a name to give to my client, and he'd be able to deliver his new product in due time. Happy clients make larger checks.

Note to future self

Do *not* plug your DS' microSD card in your funky phone even if you're *desesperate* about shooting picutres/video. You did that on Dec. 6th and you've lost all your SEDS/AnimEDS backup history in crossed cluster chains.

And no, you don't seriously have time to port a journalised file system to the NDS to avoid that further on. Sync on a regular basis, and push to Git master.

GobAnim vs. GobAnim

Something went 'oops' when trying to upgrade the 'bouncing feet' behaviour for dumblador's behaviour. I edited new animations for the feet in AnimEDS (mostly to take advantage of the bounding box edition feature), but when I injected that into the ongoing test level, I simply didn't see any feet anymore.

Armé de mes nouvelles petites anim' pour les pieds baladeurs de Dumblador (et des zones de collisions associées), je venais tout juste de faire les ajustements à blador.cmd, mais en lançant le jeu dans l'émulateur, j'ai juste eu droit à une avalanche de "oops? endless looping" sur la console de débugging. Un p'tit breakpoint bien senti sur iprintf (oui, carrément) m'a permis de voir que je faisais fausse route: ce sont des GOBs "simples" (comme dans AppleAssault) qui sont créés pour les pieds et non pas des CompoundGobs comme Bilou et Dumbladors. Du coup, l'interprétation des données d'animation est erronnée. Je vais devoir passer plus de temps que prévu sur ce point-là.

I had to rely on some DDD to figure out that gob shooting currently systematically create a SimpleGob instance, but that attaching a AnimEDS animation to a SimpleGob just results in non-sense (and likely no display). I thus have to merge a bit more those two co-existing animation parsing (binary and textual) and rendering (compound or simple). The easy way out would be to claim "oh, I can also shoot compound gobs", but the reality is that 90% of shots (weapons, dustballs, feet) will be simple gobs. Only monster generators and Bosses may need something else.

• [done] GobAnim::parse() should use AnimUser encoding, rather than AnimCommand {} structs. Keep the API (GobScript syntax) unchanged.
• [done] SimpleGob::play() should align to that new encoding.
• [done] enable BBOX, origin and pageno's colours bits from anims.
• [ok] ensure a 1-limb AnimEDS encoding can be used to create SimpleGobs in GameScript::GobCommand() 
• [done] GameScript::setGobState() no longer blindly cast to SimpleGob to call setstate()
• [done] GobGun::shoot() no longer blindly generates SimpleGob()s

Games of Thrown

1MB. throwing in action ...

mises à jour du moteur de jeu terminées: on peut ramasser et lancer des Dumbladors ... puis les re-ramasser et les lancer de nouveau. Enfin, toujours dans la même direction, je le crains, mais lancer quand-même.
Je vais pouvoir passer à l'implémentation des inkjets, du coup ^_^b

PS: attendez-vous à un ralentissement brutal et imprévu du rythme des messages de ce blog dans le courant du mois: *deline attend son petit frère j.l.n mi-janvier.

The game engine now supports throwing of bladors. Pick it up, throw it, repeat. Many things could still be refined including

• [done] having feet really hidden during the stunned animation.
• [drawn] having the bouncing feet looking like feet
• [done]allow the engine to shoot compound gobs too (new feet anim)
• [done] allow runMe to launch the level as well.
• [done] avoid one-way platform to corrupt behaviour of bouncing feet
• [done] throw in both direction, and just drop if you feel so.
• [wish] blador can stun baddies (and Bilou ?) while falling
• [done] fix the map
• [done] use dynamic palette assignment and get rid of those "crosses" marking Bilou feets in jump animations
• [done] areas that can trigger only one other GOB (or a single foot can be consumed by 2 dumbladors simultaneously)
• [wish] climb on stunned bladors, but still walk through them. 
• [done] multi-color that works in runMe too.
• [done] make sure we restart the level if killed, with colours.
• [done] allow bladors to recover next to walls.
• [done] Blador recovers when 2 feet have touched it.

I'll do my best to get all that sorted out quickly so that I could offer the world a new playable demo for Christmas. Earlier arrival of lil'sson could force me to tolerate some imperfections in that release, though.

levez .. abaissez ... levez ... balancez!

Petite réflexion de week-end: comment s'assurer que Bilou ne puisse pas tenter de prendre un 2eme objet en main. Pour l'instant, c'est en tombant une 2eme fois sur Dumblador que celui-ci passe en mode "transporté", ce qui autorise un nombre arbitrairement grand de Dumbladors à suivre Bilou.

Il faudra donc impérativement que les zones de collision déclenchant le ramassage et le lancer soient liées à un état précis ("ramasse" ou "lance") plutôt qu'à une zone générique, vu qu'on a pas de zones conditionnelles. Il suffit alors d'une des variables d'état de Bilou pour se souvenir s'il y a ou pas un objet à lancer lorsque le bouton d'action est enfoncé.

Technically speaking, we can now carry dumbladors. But we're carrying too much of them: every bop on a stunned blador turn it into the "carried" state. I'd rather avoid having 3 bladors following Bilou: grabbing a new one only if none is being carried at the moment would be by far preferable.

Conceptually, there are two "meta-states" (free hands and carrying), and we're only switching from one to the other by picking up or throwing objects. Practically speaking, however, there no such "meta-states" in the state machines, but there are some per-gob variables that can complete those states, so sIdle-> sPickup and sIdle->sThrow transitions would be conditional (and use dedicated collision areas).

Reste le problème de l'apparence proprement dite (les mains en l'air). Au départ, j'avais envisagé un mécanisme de "costumes" (cf. Monkey Island) rudimentaire qui aurait consisté à "geler" la position des mains de Bilou en ignorant toutes les commandes d'animation les concernant. Le hic, c'est que d'une animation à l'autre, les mains ne sont pas forcément liée au même "membre" logique.

Pas évident non-plus de modifier le contenu d'une page de graphisme en guise de "costume" (comme on l'aurait fait pour Kirby), à moins d'effacer complètement les mains du sprite de Bilou et de les intégrer à l'objet transporté (Dumblador, donc). La seule alternative restante serait de donner une deuxième version de *chaque* animation... j'imagine que vous comprenez aisément pourquoi j'aime autant trouver autre chose :P

To ensure proper operation, it is required that some  active collision zone could force state change after the first collision has been triggered. Then, I still have the problem of "animating the pick-up", but I came up with a nice approach for that.
Last but not least, I'll have to ensure that Bilou's hands remain above his head while moving along with a blador ... which may involve an alternative for *every* animation. I'm still thinking about a more practical way to handle that.

où est mon crayon ?

I guess I should have kept Google+ and blogger accounts separated, but for some reasons, I wanted to open the circles of "readers" for this blog, and I thought enabling g+ would have been the good way.

But all of sudden the little "pencils" and "wrenches" icons that let me edit the content easily got lost.

Hopefully enough, I'm not tool-less to investigate such annoyances. First, Firefox 10 comes with the ability to inspect elements: with just a right-click, I can open the inspector mode (Q) and explore the content of the web page much more efficiently than source exploration would have offered. it's a span.item-control.blog-admin ... neat. It has display:none because of an obscure rule in 1937454905-widget_css_bundle.css ...

I guess I shouldn't have tried to enable "share post" buttons on a layout as custom as mine, but I did. Since the problem only occurs on one machine (and since it's not affecting anyone than myself), I can take local action: somewhere in $HOME/.mozilla/firefox/*/chrome/, there's a file dubbed userContent.css that allows overriding of CSS properties at will. I can then say that

.item-control { display: inline !important; }

And that will show the icons back. Well, it's a bit extreme: it shows icons on any blogs, including thoses where I have no edition rights. And it might do other things on other webpages as well. I could have used a @document domain(sylvainhb.blogspot.com) to work that around, but unfortunately, G has also decided not so long ago that the webpage I'd visit would depend on the country I'm in. When visiting torino, I'd end up on sylvainhb.blogspot.it in no time, with my rules (potentially) not applying anymore.

So I hope I can come back with a real explanation and a fix soon ... I'll have to live with that hack running in-between.

'nuf said. Back to dumblador throwing. I need to ensure we don't grab some when we're carrying some.

edit: all of sudden, I need to swap a bool in about:config to be able to use my userContent.css file ... oh well ...

En voiture!

Je continue de suivre ma petite carte de développement, une fonction à la fois. Après les panards baladeurs, après la correction des bugs d'animation, voici le transport de dumblador.

First occurence of a transported GOB tonight: stunned dumblador will not simply follow Bilou (as BerryBat): it sticks to a defined position relative to Bilou. A nice "proof of concept" before I try to make it look as professional as possible. [done]

Un nouveau "contrôleur" qui utilise directement les coordonnées de Bilou (après attachement) pour aligner le dumblador. Ça n'est pas encore aussi impeccable que je le souhaite, et on peut observer un léger décalage qui dépend de la vitesse de Bilou, comme avec les plate-formes de Zool. Il faut donc que j'aille jeter un oeil aux listes d'animation pour ajouter le support de ces bits "pending" pour arranger ça.

Puis j'irai chercher une technique de "costumes" à la Monkey Island pour que les mains de Bilou reste sous le Dumblador.

Landing bug, from the state machine

Since the introduction of 1st September release, I observed curious behaviours with Bilou landing. First, it could occur that Bilou looks "dislocated" just when landing, which would last for a few frames before he starts walking. That can be explained by the fact the OAMs the hardware uses have received new graphics, but still with the ordering (and layout) of the last frame. It "sticks" that way because the "walking" animation starts with a 'MOVE' command, which actually instructs the game engine to wait for the GOB to have accumulated sufficient amount of inertia to be able to "step" by 3 pixels to the right. This has been fixed just yesterday.

La dernière release a un bug bizarre: quand Bilou atterrit, on dirait qu'il se retrouvé désartibulé un moment (cf. capture), puis tout revient dans l'ordre au moment où il commence à marcher. la raison, c'est qu'au moment de changer d'animation, les sprites hardware ont déjà reçu leurs nouvelles images, mais leur coordonnées (et leur ordre d'affichage) reste inchangé. Si ça ne se voit pas la plupart du temps, c'est que la prochaine image n'est généralement pas bien loin, sauf dans le cas de l'animation de la marche qui commence par une commande MOVE indiquant au moteur d'attendre que le personnage ait accumulé assez de "crédit de déplacement" pour pouvoir faire le premier 'pas' (ici de 3 pixels).

But there's another, harder to catch, subtle bug that hides in the "state machine" that controls Bilou, more precisely between "fall", "idle" and "walk" states. In those rare cases, Bilou lands in "walking" state although you're no longer pressing the DPAD in any direction. He keeps walking forward at a very slow rate (~1px/second), unless some block prevents him from doing so or you press some button on your DS.

There sure are curious things in that state machine, such as clearing the DPAD memory before entering idle state so that you force dpadController to generate an event for "getting pressed". I have the feeling that none of this remains useful now that I have "impact speed" variables that can offer a direct fall->walk transition.

It looks like the bug was in the momentum controller code, however: it would fail to decrease any speed below 8/256th of pixel per frame, and would generate no event for "reaching speed zero".

Un autre effet bizarre lié à un bug dans la machine d'états de Bilou se déclenche quand l'atterrissage se fait alors qu'on vient de relâcher le DPAD. Bilou donne alors l'impression d'avancer trèèèèès leeennnteeeemmeeeennt avant de s'arrêter complètement. Il faudra sans doute que j'aille corriger dpadController pour qu'il perde la mémoire des dernière directions avant d'entrer dans l'état 'attente'. Je ne devrais plus en avoir besoin maintenant que je peux capturer la 'vitesse d'impact' quand on atterrit. Ah, et un p'tit bug dans le contrôleur d'inertie qui oubliait de me signaler l'arrivée à une vitesse nulle, restant bloqué à 8/256e de pixel par frame.

PS: the '90,000 views' bar has been hit this morning, according to Google, but I strongly doubt that it's true. Google is terribly sensitive to all those page-ranking cheaters that pretend they're referencing you just to attract your attention to their web domain.

Jongleries ...

Bon! Il reste encore du travail avant que ces choses rebondissantes puissent être associées aux pieds de DumbBlador qui tentent de retourner auprès de leur maître, mais au moins, elles se dirigent bel et bien vers l'objet qui les a lancées. Le mécanisme d'attachement fonctionne, et le contrôleur associé également. On va pouvoir poursuivre :)

Neat! Things are thrown when one bops a blador, and once they stop, they'll move back and track the GOB they come from. If there's a wall blocking them, they'll jump higher to pass it. It's far from looking like "feet that go back to their body", but at least the mechanic works.

gob->attach(that)

J'ai trouvé un cas de figure pour tester la fonction "attacher un GOB à un autre" qui doit me servir entre-autres pour transporter Dumblador ou pour faire de SpongeBob une plate-forme mobile.
Je veux dire, "un cas de figure qui ne dépende *que* de cette nouvelle fonction".

Starting to work on a set of new features such varied as "grab bladors and throw them onto other ennemies" usually raise the problem of "where do we start". Among all the features (aligning Gobs onto each other, tracking them, etc.), I need a first one that is simple enough and demonstrate the bare bones needed in the code logic: attaching objects at run-time. It seemed that bladors feet could be a candidate. When I draw Bilou bopping a dumblador, blador's feet are stretched away from its body. And when Bilou throws bladors at pendats, the feet are gone, leaving just a large chunk of steel ... a living weapon.

It would be easy to have feet "thrown away" when blador gets bopped on, but then, what should we do when the blador recovers? It magically rebuilds up wherever its feet are gone, like New Super Mario Bros' drybones ? I'd rather not.

Actually, I'd rather have feet attached to their blador although they have been thrown, and guided by a controller that pulls them back in place. The blador's body (the initial GOB) would then stay stunned until both feet have returned. Not only that sounds funny to do and play with, but it also means that the terrain surrounding the dumblador will affect how long it will stay stunned if you stomp it, and thus how tricky it is to grab it before it recovers. A nice interplay approach, imho.

Je m'étais amusé à imaginer Dumblador perdant ses pieds au moment où Bilou lui saute sur la tête ... eh bien, c'est exactement ce dont j'ai besoin. Les pieds deviennent des GOBs autonomes, mais restent "attachés" à leur Dumblador d'origine, ce qui permet de définir des contrôleurs qui les ramènent vers celui-ci. On verra par la suite si celà crée un gameplay intéressant, mais pour l'instant, ça semble un test prometteur.

• Le mécanisme "pending" qui garanti que l'objet auquel on fait référence a déjà été traité n'est pas encore complètement opérationnel.
• Lors de la génération des "tirs", ceux-ci sont assimilés aux objets passifs d'une collision alors que le "tireur" est l'objet actif.

C'est le tronc qui ment le moins.

J'avais pas mal tatonné au moment de faire le tronc de l'arbre pour la forêt de Bilou. Un des éléments qui m'avait été indiqué sur pixelation était le manque de "volume" retranscrit par mon graphisme. Et là, en faisant une petite promenade matinale dans les parcs de Torino, je constate avec stupeur que le tronc des arbres n'est absolument pas éclairé "principalement d'un côté, l'autre dans l'ombre.

Que se passe-t'il donc dans ce parc qui défie les lois de la physique ?

Eh bien, tout simplement, l'arbre a un feuillage suffisament large et dense pour faire de l'ombre à tout son tronc. Résultat, aucun éclairage direct pour lui. La lumière qui lui parvient est le résultat de la diffusion (tous azimuts) notamment par le sol. De plus, le tronc est rugueux, et pas lisse. Les rayons de lumières y sont eux aussi écartelés et n'auront donc pas de zones "highlights" comme le ferait une surface plus lisse.

Bien sûr, dans son jeu vidéo, on est libre de choisir les conditions d'éclairage de son arbre, tout en veillant à ce qu'elles soient cohérentes avec celles des objets alentours. Et si jamais on décide de faire un arbre au tronc assombri, il reste un élément qui peut lui donner du volume: la distortion des motifs. Ici, l'écorce de l'arbre s'est craquelée en une sorte d'entrelac de lianes sur un fond plus rougeâtre en vieillissant. Globalement, l'écart entre deux "lianes" est le même partout, mais on l'observe plus serré sur les bords qu'au centre.

Voilà. Dessinez bien, moi je vais tenter de rattraper mon retard de sommeil.

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.

tint'm'up!

Avec les nouvelles version de SEDS et AnimEDS, je n'aurai plus à rougir de la variété des Koopa Troopa. Me voilà également capable de créer des personnages animés en changeant la teinte des différents sprites utilisés. Voilà qui complète agréablement les modifications apportées à mon éditeur de niveau début septembre. Je vais peut-être bien pouvoir en profiter pour faire un premier essai de "pendat" en 2D, même si au départ, j'avais prévu d'utiliser des polygones pour ce perso (et pour BangBash, d'ailleurs).

Ain't 'fraid o' Kolorful Koopas. No more. With my latest updates on SEDS and AnimEDS, I can use up to 8 distinct palettes for the sprites I use to build character and monsters animation. The same "hands&feet" spritesheet can be used for Bilou, Dumblador and even Pendats, with two separate shades for foreground and background. That should be quite enough.

Now I've got to focus on the thing I've left behind for a while: make the game engine support all this as well. Right now, the 'schoolzone test' has a 'donkey kong return' look: only the owl-styled background has colours, and everything else is plain black ^^". But not right now. Right now is Ravioli time.

pick a slot

I'd say "good. things are progressing" if that progress hadn't been done while I can't get due sleep, coughing and sneezing. Anyway, I'm done with some basic steps to confirm that a multi-slot palette can be loaded in AnimEDS. Much remains, that will need more lunch-thinking.

• [done] ensure multi-slot palettes are read correctly.
• [done] buttons to pick slot on skeletton-setup page.
• [done] selected slots reflect in anim edition window.
• [done] move swap bits of AnimCommands to their hardware place, to make room for palette bits.
• [done] limbs table can reflect palette slots
• [done] palette slot preference stored in animations
• [todo] frame editor that obey colour preferences
• [done] preview using real colours
• [wish] timeline using real colours
• [done] size up to 8 palette slots for pendats to come in.
• [done] dumblador using multicols and bilou's feet.
• [done] Bilou using multicols for darker foot & hand. 
• [bugfix] saving something multipal with AnimEDS kills all the palettes
• [bug] sticky palettes selection when changing sprites?
• [SEDS, done] ensure palette reorganization works in multipalette .spr files.

Multipalette de-briefing

I do want to have multi-palette in AnimEDS as well, so that you can tint your monsters and reuse e.g. the same sprite for Bilou's front and rear foot, or for Bilou and Pendats feet and hands. Right now, each foot sprite is cloned 4 times and I only have 1 monster so far ... seriously.

Allons-y: multi-palettes aussi dans l'éditeur d'animation. C'est vrai, quoi: pouvoir repeindre les bouquins dans l'éditeur de niveau, c'est bien beau, mais ça ne change en rien le fait que je suis obligé de maintenir chaque sprite de pied en 3 coloris séparés et 4 coloris pour les pieds. Vous comprenez bien que dans un contexte pareil, tenter de faire un "pendat" avec les pieds et les mains blanches (couleur règlementaire dans l'armée de Sqrt) est totalement hors de question >_<.

So it's time I track the core changes made to Level Editor so that it can benefit from multi-palettes:

• Initialisation of the Engine object needs an  (EXTENDED_PALETTES) additional argument;
• every call that sets DISPLAY_BGx_ACTIVE now also need to set DISPLAY_BG_EXT_PALETTE;
• SpriteRam should no longer be initialised with e.g. SPRITE_PALETTE but with one of the slots returned by Engine::editpal($slot,false));
• when calling SpriteSet::setpalette() to copy from/to VRAM, make sure you call  Engine::editpal($slot,true); before copying and Engine::editpal($any,false); when you're done.
• before loading a SPR file, define SpriteSet::ncolors and wrap SpriteSet::Load() with Engine::editpal calls as needed.

Now, AnimEDS will mostly require extended palettes for sprites, not for simply for tiles. So ...

• [done] make AnimEDS compile in the noswap branch
• [done] get rid of logo display.
• [done] only MAIN screen is given multi-pal capabilities. Tell GuiEngine on which screen console should be ; Window provide palette[] and layers abstract registers ?
• [done] move AnimWindow on MAIN screen; fix sprite-based widgets.
• [done] make sure a palette is initialised

Courir ?

En testant la démo "Back to School", Facet regrettait l'absence d'un bouton "RUN" dans le comportement actuel de Bilou. D'un côté, un mini-jeu comme "nuts'n'bolts" ne devrait pas avoir besoin d'un tel bouton (pas de grand trou à franchir, et un gameplay plus basé sur le timing que sur les réflexes). D'autre part, je ne suis pas encore décidé sur le mode de fonctionnement de la course.

Il faut un bouton pour courir, ça c'est assez évident. Mais sur le DPAD ou comme bouton d'action ? Est-il vraiment indispensable de le garder enfoncé tant qu'on veut courir ? A la fin d'une partie de Mario, on finit par attraper des crampes... Pourtant j'aime bien la phase "gagner de la vitesse" que ce genre d'approche permet, par rapport au mode "un coup de bouton X et ça y est, on court à pleine vitesse" dans Rayman. Au point que Peach et Shantae ont carrément un bouton "ne pas courir".

Have you felt the lack of a RUN mechanics in the latest Bilou demo too ? Facet surely did.

I was really missing a run button and the little pauses and lack of inertia take away from the fluidity. I'd like to bounce and slide more.

After I spent some time thinking about it, it becomes clear that "Bilou's adventure" will have such a RUN mechanics, where speed progressively increases, but that this would be absent of "Nuts and Bolts" (and possibly other in-between arcade games featuring Bilou).

I would like, however, to be able to release the button, and not force the power-player to keep RUN button pressed for 30 minutes if he wants to speed-run the game. Fundamentally, what I'd love to try is a sort of "cruise control" behaviour, where you press a button only when you want the DPAD to make you "accelerate". Once you release that button, you keep moving at the reached speed until you release the DPAD as well.

Mon impression, c'est que le fait d'accélérer progressivement ou non peut être découplé du mécanisme de "lecture" du gamepad. En d'autre termes, on pourrait avoir un bouton qui n'est pas "courir", mais "accélerer". Si le joueur mêne Bilou dans une direction sans enfoncer ce bouton, Bilou ne change pas d'allure. Par contre, dès que le bouton "accélerer" est enfoncé, la vitesse de Bilou augmente (plus ou moins) progressivement jusqu'à la vitesse maximale. Que celle-ci ait été atteinte ou non, Bilou conservera la vitesse acquise si on relâche le bouton d'accélération.

The poll is now open: which sort of RUN do you actually prefer ?
Mario: 62%
Rayman (PSX): 12%
Shantae: 0%
Kirby: 0%
Bilou (new): 25%

One Last Apple Assault.

Well, granted, 2 years after its initial release, there's not much more novelty I can bring to Apple Assault. I got feedback from Pierrick and his son about the latest modifications, just took the time to bring the last polish, and here's Apple Assault v1.6. At last. In appearance, not much changes since 1.5, but it's quite a strong difference in terms of rhythm and gameplay, imho. 

Voici la version 1.6b d'Apple Assault, enfin finalisée, avec juste quelques micro-règlages par rapport à la 1.6a sera mon dernier mot. 4 mois pour passer de la pré-release à la release définitive ... je vieillis, moi.

Yellowl and Redowl

I tried again, with the updated SEDS and properly charged battery. I could save a first draft (just the shadow lines), and then when I tried to save my "finished" work, the editor crashed again. That's *really* getting on my nerves, now.

Hopefully enough, I had a real camera powered up and ready-to-shoot just one floor below, this time, so I've shot pictures of my screen and did some Gimp post-processing to try to enhance and restore the picture into something that could be shown or fixed afterwards. I started the owl again, from the 'shadow lines' that were saved, using the version of SEDS I submitted to NEOflash compo. Everything went fine, and I made tons of intermediate saves. Then I thought "oh, well, that should be it for now", and clapped the lid of the DSi. As usual, I then thought of a small last improvement I could do, so I opened the lid, applied the change and tried to save again ... stalled. So this is what goes wrong: I cannot read/write to the SD media card anymore after I put the device in "sleep mode" for a while. And that happens regardless of whether I use the "1.x" or "2.0" version of my GUI engine.

owl story ...

I took the time to print out Facet's edit on my school owl so that I could train myself and draw a new one on my DSi. It was starting to come out quite nicely, but unfortunately, I've lost it. For some reason, SEDS stalled when I tried to save my new piece of pixel "art" on a new file.

Voici hélas tout ce qu'il reste de ma scéance de dessin de hibou sur la DS ... l'idée de faire d'abord uniquement les zones les plus sombres dans une "couleur stencil" avant de doubler la taille n'était (à mon avis) pas mauvaise, mais au moment de sauver mon travail sur la carte mémoire, quelque-chose a coincé sans crier gare et je me suis retrouvé (une fois de plus) avec une DS qui ne répondait plus aux commandes au moment de définir quel fichier de sauvegarde devait être utilisé. La batterie de ma console était fort faible (je n'ai même pas su la relancer), j'espère que c'était juste ça... Ce n'était pas encore la dernière mise à jour de SEDS, non plus.

Was the linker no longer able to access the media card ? Was there a bug left in that r1056 version of SEDS ? was the battery's low level critical when power was needed again by the flash hardware ? I have no idea, but that's getting troublesome ...

N'empèche, ça m'ennuie ... il serait temps que mes outils de game-making sur DS redeviennent fiables.

So many palettes!

This time, I do it the correct way: I start mapping which (hardware) palette is used where so that I can later properly track copies that goes on all over the place and figure out why I can't properly load/store palettes in that "multipal" update.

Many of the operations you can do on the PaletteWindow actually involve copies from one of the palette into the others. Ideally, they are all synchronised...

•  as soon as you start editing your palette, it differs from those of the "upper screen" which are kept static
• "okay" button copy the edited palette into SPRITE_PALETTE_SUB, allowing a preview on the current sprite page
• if you're fine, "sure" button copies the edited palette on BG_PALETTE_SUB as well. It's now officially your working palette for the grid.
• At anytime, you can undo something by clicking "oops", which copies BG_PALETTE_SUB back as the edited palette. 

There's something the multipal approach changes, however: what is now stored in the .spr file is the offscreen set of (up to) 4 palettes, which is updated every time you flip to another slot. So "okay/sure" only affects how you will draw pixels in the close future, not what is actually stored when saving. The bare minimum I can do is to ensure that onscreen->offscreen update is performed when clicking "okay" as well. 

I *could* also enforce this synchronisation when going out of the PaletteWindow, but that would break the former user interface convention (where going out without having pressed "okay" at all means you won't save your palette edits). To overcome this, and avoid data loss, I introduce an additional offscreen undopal[] where I can automatically store data, and a "lost" button that can recall what was on screen the last time you left the palette edition "window".

branch/noswap

Le support du mode "multi-palettes" dans LEDS m'a obligé à revoir un point assez noirâtre de mon moteur d'interface graphiques: les widgets dynamiques. Bon, c'est un peu pompeux de les appeler comme ça, j'avoue: il ne s'agit ni plus ni moins que de pouvoir cacher certains éléments à l'écran ou d'en modifier l'ordre de priorité au fil de l'exécution du programme. La barre de boutons qui apparaît et disparaît dans l'éditeur de niveaux, par exemple ...

La plupart du temps, je m'en sors avec un tableau dont je modifie l'emplacement final. Un bouton "undo" à faire apparaître ? nbWidgets++ ... il doit disparaître ? nbWidgets--. C'est aussi simple que ça. Dans le cas des boutons d'édition, c'est un peu plus subtil, parce que la "zone sensible" qui permet de construire le niveau couvre tout l'écran et qu'il n'y a pas moyen de "cliquer à-travers" pour toucher les nouveaux boutons. Jusqu'ici, je me servais alors de Windows::swap() qui permuttait deux widgets dans la liste d'affichage, mais cette façon de faire rend rapidement le code lourdaud et peu lisible, avec pas mal de bugs qui jouent à cache-cache dès qu'on essaie de changer quoi que ce soit.

C'était donc l'occasion d'essayer autre chose: des instructions de saut dans la table des "widgets". En clair, je peux maintenant avoir quelque chose comme

normal: (grille) (boutons) (palette) STOP
copie: (curseur) GOTO normal
recolor: (bouton sync) (bouton undo) GOTO normal

Je n'ai donc "plus qu'à" choisir le point d'entrée dans ma liste de widgets pour avoir le rendu souhaité. Note qu'heureusement, ce type de pratique était resté rare puisque j'ai la possibilité "d'empiler" des "fenêtres" justement pour éviter ce genre de manipulations. S'il n'y avait pas eu en plus la grande tambouille du changement de linker, je n'y aurais d'ailleurs probablement même pas consacré un post.

Let's get cracking

Okay, hardware is restored, it's now time to merge summer experiments and converge towards a platform for more pixels, more animations, more levels and more monster design experiments ...

• [done] merge the 'z-order' branch back: it has proved it's a GoodThing
• [done] 4-palettes LEDS must be backward-compatible with one-palette spritesets
• [done] make sure we still see the background and monsters in 4-palettes LEDS
• [done] restore disappeared iprintf (known bug)
• [done] barebones to update colours on BG layer in LEDS
• [done] ensure that LEDS runs on real hardware (fix blue screens when loading a .cmd file and when switching to colors mode)
• [badbuild?] ensure it's still possible to L-pick tiles in draw mode
• [bug?] need to press select twice in SEDS to enable PaletteWindow ? 
• [done] something odd happens on SEDS when loading a spriteset while a non-zero palette is currently selected in PaletteWindow (palette #0 overwrites current slot)
• [workaround] entering sleep mode breaks iPlayer's access to the media card.
• [done] palette selection in AnimEDS as well
• [fork] find something better than Window::swap() to structure widgets.
• [bugfix] ensure that SEDS works in the noswap branch too (currently, it's all black!?)
• [badbuild?] some widget only display randomly on real hardware
• decide what to do with left-handed mode
• [done] ensure I've got all the material to edit/test levels on the DSi (currently, something displays "T.M.A.P" and random tiles on the console, and the level doesn't load). LEDS apparently saved a map file as autoexec.cmd. Needs investigation.
• [done] allow map2png.pl to work again
• [wish] make map2png.pl work with swapped (and coloured) tiles too.
• [done] complete the books tileset so that I can change books size (cf. CyanGmou's mockup).
• [postponed] fix the landing bug for Bilou
• [postponed] fix blador.cmd so that bladors can be stunned
• [now] revamp the School's owl
• [postponed] draw/animate some pendats

En clair, ça en fait du travail pour se remettre à avancer sur la School zone ... l'objectif, c'est bien sûr plus de souplesse pour construire les niveaux, plus de variétés dans les décors et de nouveaux monstres à développer.

Linker de Bisounours pour DaySi

Yes! ça y est! Grâce au matos gracieusement donné par ZeBlackOS -- à savoir un linker de bisounours iplayer -- je peux enfin faire tourner mes homebrews sur la DSi rachetée à Mr. Proper l'an dernier! Vu qu'elle avait même un chargeur de poche pour brancher sur port USB, ç'aurait vraiment été dommage de la cantoner à faire tourner Zuma Revenge pour ma fée :P

Il pourra se vanter de m'avoir fait suer, note, au point que j'ai fini par craindre de l'avoir mis hors-circuit au moment de lui faire son "upgrade kernel" ... mais non. C'était tout simplement un problème de formattage. Si les gars de SuperCard insistent sur le fait que la carte microSD soit formattée avec leur outil dédié sous Windows, ils ont en fait une bonne raison: la mémoire de la DS étant limitée, il faut que la table d'allocation puisse tenir dedans.

If you just found an iPlayer, but that it seems to stall after showing a blue logo screen but without going to the screen that says "DS Video Expert", chances are that you overlooked the vendors' recommendation for using their own formatting tool for your media microSD card. Granted, that sounds plain ridiculous. Every OS (decent or not) comes with a FAT formatting tool, and you shouldn't have to install third party to do that, and certainly not on a Microsoft OS!.

Still, as the DS has limited memory, and given that using their formatting tool *did* unleash the linker's full potential, I can imagine the following scenario: the FAT driver of the linker's firmware is so crude that it *needs* to fit the whole FAT within 1Mo of RAM. A conventional formatting tool will instead try to come with settings that minimizes cluster size, so that you're doing the most of your filesystem... and dismiss FAT size as a significant issue.

En l'occurence, ici, la carte de 8Go a été formattée avec des clusters de 32Ko (ce qui est modérément large, mais large quand-même), de sorte que la FAT soit juste un rien plus petite que 1Mo ...
(Bien sûr ça pourrait être un autre détail: taille du répertoire racine, le nombre de clusters réservés ...)

En toute logique, j'aurais pu obtenir l'effet souhaité sous Linux avec mkdosfs -s 64 -F 32 -f 2 -h 8192 ... Mais pour une autre taille de carte SD, il faut ajuster le paramètre -s en conséquence (#Go*8, je dirais).

Here's the result of a filesystem analysis after supercard's tool "correctly" formatted my 8GB media card for iPlayer:

SchoolTest> sudo dosfsck -n -v /dev/mmcblk0p1 Boot sector contents: System ID " " Media byte 0xf8 (hard disk) 512 bytes per logical sector 32768 bytes per cluster 4404 reserved sectors First FAT starts at byte 2254848 (sector 4404) 2 FATs, 32 bit entries 969728 bytes per FAT (= 1894 sectors) Root directory start at cluster 2 (arbitrary size) Data area starts at byte 4194304 (sector 8192) 242304 data clusters (7939817472 bytes) 8192 hidden sectors 15515648 sectors total

dosfsck /tmp/disk.img Boot sector contents: System ID "mkdosfs" Media byte 0xf8 (hard disk) 512 bytes per logical sector 4096 bytes per cluster 32 reserved sectors First FAT starts at byte 16384 (sector 32) 2 FATs, 32 bit entries 3992576 bytes per FAT (= 7798 sectors) Root directory start at cluster 2 (arbitrary size) Data area starts at byte 8001536 (sector 15628) 998046 data clusters (4087996416 bytes) 0 hidden sectors 8000000 sectors total

8GB formatted with special tool

4GB formatted with mkdosfs under Ubuntu

Pourquoi "de bisounours" ? Eh bien, parce que ce linker permet de faire tourner les jeux amateurs (dits "homebrew"), mais refusera de lancer les ROMs commerciales. Merci, tata Raymonde. Et merci à Pierrick de m'avoir filé un coup d'EEE main, sur ce coup-là. Et bien sûr Merci à ZeBlackOs pour le linker ^_^
My last fear is gone, btw: although the linker's documentation mention directories such as MUSIC, VIDEO and HOMEBREW where we're supposed to place our files, it can still launch files that are at the root (e.g. beta versions of my tools) and that have been downloaded by runME (currently in /moving/) Mais du coup, je m'interroge: les difficultés que j'ai à faire tourner de manière fiable mes outils avec ce matériel pourraient-elles être liées à une libfat pas vraiment calibrée pour des clusters de cette taille ?

Doxygen & Cybook : round 2

That's for sure: doxygen output on a cybook is a great thing to plan the next update on my tools. I can do that any time while commuting, take simple notes and then just commit the changes into code when I get to a keyboard-enabled computer :)

Still, that requires a bit of tweaking of my Doxyfile configuration:

COLS_IN_ALPHA_INDEX    = 3
ALPHABETICAL_INDEX     = YES
REFERENCES_LINK_SOURCE = NO
REFERENCED_BY_RELATION = YES
FULL_PATH_NAMES        = NO

Au fil des mois, mon cybook odyssey se révèle de plus en plus un puissant allié pour la programmation de projets-hobby. Toujours en poche (ou presque), il me permet de planifier les évolutions de mon projet à tête reposée, dans mon fauteuil, sans nécessiter de réimprimer à chaque fois la dernière version du code. Il a évidemment fallu un peu chipoter pour avoir des documents "pratiques" sur cet écran 600x800, en enlevant les numéros de ligne ici, changeant la structure du document là, etc. Mais le résultat est plutôt satisfaisant.

J'aimerais juste que l'Odyssey soit capable de détecter les "clics" sur les schémas en mode "image map" (cf. p. 1629, par exemple) et que doxgen propose un mode "epub" natif qui m'éviterait de faire tourner "calibre" pendant près de 10 minutes pour la conversion html->epub.

Once the doxygen files have been created, I need to post-process them to strip out line numbers in the code. There's unfortunately no configuration setting to do that *in doxygen* itself, and I lost the patch that forced doxygen to avoid generating them altogether.
fe class*.html "mv % /tmp/% ; sed /tmp/% -e 's:/a>0[0-9]*:/a>:g;' > % ; echo % stripped"

Last step is to get rid of <namespace>:: prefix in some classes name (in the class index) so that it actually fits 3 columns.
mv classes.html /tmp/ ; sed /tmp/classes.html -e "s/>[A-Z][a-zA-Z]*::/>/g;" > classes.html

Unfortunately, calibre is still über-slow processing this, and it looks like the Cybook Odyssey doesn't support clickable image maps. Anyway, if you want to give it a try (and have the hardware as well), here's the file.

new and improved

Cette fois-ci, plus possible de retarder le passage au nouveau-blogger-tout-moche bien longtemps. Le hic c'est que la balise HTML que j'utilise pour faire un blog bilingue est détruite systématiquement (remplacée par un simple texte italique)Voici un test de préservation de la balise <em>;Plus important le main() doit pouvoir apparaître comme du code.

En fait, la balise <en>, elle, reste préservée (mais elle n'est pas standard).  Si elle passe correctement sur les différents browsers, la solution consisterait alors à définir un nouveau .css pour que <en> soit affiché correctement dans l'éditeur ...This is a test for the future of this two-language blog. You should see this text in italic with a purple tint. If not, it means that your browser doesn't allow me to use <en> tag for english paragraphs. I used <em> so far, but the new compose mode turns those tag into <i> instead, killing my formatting at source level. I reported the bug to blogger with the "send feedback" several times, but it looks like they really don't care and keep pushing the "new and improved" version. I will survive, but that may mean that your RSS reader will no longer visually differenciate languages (chances are that it wasn't showing a different colour, already, but just slanted/regular text). I'm sorry. Blame google.

em:Emphasized text

strong:Strong text

dfn:Definition term

code:Computer code

samp:Sample output from computer program

kbd:Keyboard input

var:Variable

q:short quote

First multi-palette LEDS screenshot

Si le post précédent vous a laissé avec des yeux grands comme des soucoupes, voici une petite image qui résume ce que donne le "multi-palette" hardware une fois ajouté à mon éditeur de niveau. Eh oui: les livres peuvent enfin avoir des couleurs différentes. Bon, on est encore loin du compte, parce que pour l'instant, ce sont les propriétés des objets (solide, pentu, ...) qui modifient les couleurs, alors qu'au final, il me faudra un outil de sélection de couleur à part. En plus, seul l'arrière plan (juste derrière Bilou) pourra voir ses couleurs modifiées, l'avant plan utilisant obligatoirement les couleurs de la palette "de référence".

the multi-palette .spr file I crafted on my DS phat has been beamed and (thanks to Sverx's precious hints), I've got LEDS now working in extended palette mode, so that it can natively use the same tiles data for at least two different tints of books. I still have much to fix, but it's a nice first step.

2nd at NeoCompo !

That's rather a good suprise: AnimEDS was ranked 2nd (just behind Smealum's FPSMaker) at Neocompo 2012. That comes just in due time to cover homebrew hardware expenses and get me quickly back on track. Shopping time ^_^

Congratulations fly to Alekmaul for his 1st place in the GAME competition with a cute SNES puzzle game reminiscent of Sokoban (actually a port of an MSX game, afaik).

VRAM_E_LCD

I previously messed up with the sources of "Tetris Attack" to gain experience with DS development. Among the things Sten used, there was multi-palette display, using an extra bank of VRAM instead of the "regular" PALETTE_BG and PALETTE_SPRITE.

 videoSetMode(MODE_0_2D |
               DISPLAY_BG0_ACTIVE | /* the background */
               // ... more settings
               DISPLAY_BG_EXT_PALETTE);
  // 128K
  vramSetBankA(VRAM_A_MAIN_BG);
  // 128K
  vramSetBankD(VRAM_D_MAIN_BG_0x6020000);
  vramSetBankB(VRAM_B_MAIN_SPRITE);

The video mode initialisation we have here is fairly standard (note the old-time code with VRAM addresses still exposed to the homebrew coder :P), except for DISPLAY_BG_EXT_PALETTE flag. You can turn extended palettes on/off separately for sprites/backgrounds, or for top/bottom screens, but if you enable it for background, it's used for *all 256 colors backgrounds*. Period.

  // 64K, can hold palettes for all four BG layers
  // allocate for cpu access
  vramSetBankE(VRAM_E_LCD);
  
// background
  Decompress((void*)(0x6880000), background_pal_bin);
  
  // blocks
  Decompress((void*)(0x6880000 + 256*16*2), sprites_pal_bin);
  // an alternate palette with colors dimmed so that we can
  // easily dim the whole playfield when the game is over...
  CreateShadedPalette((u16*)(0x6880000 + 256*17*2),
                      (u16*)(0x6880000 + 256*16*2));

This magic 0x6880000 memory address sits within the 'LCD-mapped' region and is where VRAM bank 'E' appears. Right then, it's "offscreen", somehow, just ready for setup by the CPU. Each palette is 256x2 bytes long, and each background will have access to its 16 palettes at fixed offset. In this game, we had the backdrop on BG0 (thus palette at 0x6880000 to 0x6881E00 = 0x6880000 + 512*15), "blocks" (or apples) on BG1 that has its first palette at offset 512*16 (0x6882000) and its second palette at offset 512*17 (0x6882200). That makes lot of room unused (15 unused palettes for BG0 and 14 unused palettes for BG1), but if you want them to use different palettes (e.g. being converted independently from each other), you don't really have a choice.

  // text
  Decompress((void*)(0x6880000 + 256*16*2*2), font_pal_bin);
  // more background...
  Decompress((void*)(0x6880000 + 256*16*3*2), singlebackground_pal_bin);

Score and status are displayed with a tiled layer too, implying yet another palette is needed. He could have used a macro XPALETTE(bg,slot) defined as ((void*)(0x6880000 + 256*(16*bg+slot)*2), or (possibly), use bank F/G forcing BG 0 and 2 to share the same 16 slots, but ensuring that those slots in use by BG2 are never needed by BG0 and vice-versa.


// then allocate it for extended palette use
vramSetBankE(VRAM_E_BG_EXT_PALETTE);

Enough setup: we let the video hardware access those fancy colours ^_^

supercard and multi-palette

There is one last thing I can do with my failed homebrew equipment: dig out my old SuperCard (slot 2), update the makefile so that it automatically apply DLDI patch if $DLDI environment variable is set, and work on that multi-palette support that will ultimately allow me to tint books in up to 16 colors in the school zone (only 4 slots atm.)

Premiers tests concluants pour le système "mutli-palettes":voici un bouquin vert, mais qui peut redevenir rouge à n'importe quel moment. Et il ne s'agit plus d'un simple test grandeur nature dans SEDS: les palettes alternatives peuvent maintenant vraiment être sauvées dans des fichiers .spr et re-chargées plus tard.

Now, that's annoying...

Bon, DarkneSs, ma DS noire, est toujours en réparation ... Je viens de recevoir de ZeBlackOS un sympathique iplayer -- le linker de bisounours qui ne lance pas les ROMs commerciales -- mais j'ai encore du mal à le faire tourner convenablement... il "boote" sur la DSi, ça c'est déjà un progrès, mais reste bloqué au niveau des logos "loading": le message "DS Video Expert" n'apparaît jamais.

Apologises to those of you who expected an activity boost after the first "owl school zone" level: you'll have to wait for me to fix some issues... I have only one working linker left until I buy some new parts or got other back from repair.

Mes derniers développements se sont donc faits essentiellement sur la DS "phat" de ma fée, avec le 'faux' R4 SDHC que j'avais obtenu pour DarkneSs... Ce n'est pas génial pour les couleurs, mais pour éditer des animations et vérifier que tout passe bien sur hardware, c'est toujours ça... enfin "c'était". Les opérations de mise à jour de l'iplayer ont eu raison du système FAT de ma carte mémoire (oui, j'ai commis l'erreur d'essayer d'utiliser la même carte mémoire sur R4 et iplayer), bousillant au passage rungama.nds et sedsgama.nds, faisant disparaître ledsgama.nds, animeds.nds, spritea.spr (la school zone) et spritey.spr (la green zone). Rien de définitivement perdu normalement tant que les disques dur de mes machines PC tiennent bon, mais c'est tout de même très dérangeant.

One left, that should be enough ? well, except it's the linker that has no built-in support for DLDI, on the DS that has poor color contrast. No art can be seriously built on that, and software upgrades will be a pain at best... Hopefully, I don't think I've lost any data although both green zone and school zone .spr files were killed by the mess that resulted from running the iPlayer firmware.

Il me reste la possibilité de me rabattre sur mon bon vieux SuperCard slot 2 et son passcard associé ... le soucis, c'est qu'il ne supporte pas le DLDI. Je devrais donc veiller à ce que tous les fichiers transmis soient bien patchés pour super-card avant de les uploader ... plutôt pénible quand on se souvient qu'au départ le support supercard était d'office dans la libfat. Et non, m'sieur devkitpro, *je ne vais pas tenter la mise à jour système du dernier linker fonctionnel qui me reste*.

Smooth Slopes at last!

After so many tests where I had to jump slightly when approaching the bottom of a slope, having flawless, smooth moves in the school zone almost feel magic!

Funny enough, the doslopes() function that I crafted carefully was already flawless, but the defects were in the glu code (the walker controller) that interfaces that with the animation replay. As I expected from the start, the step-by-step movements system was the root of the problem. It essentially nailed down to 2 things, that occured when leaving a slope:

1. in that case, I need to check whether the character could fall. Bug #1 was that I wasn't completely taking care of the horizontal adjustment in that case, and it resulted in "no, you won't fall at coordinates (99,60). you can safely move and stand at (100,60)"
2. when falling down, the controller actually FAILs to keep walking, but that means (for the animation replay subsystem) that the defined speeds are cancelled. The problem is in the case of walking off a cliff, the horizontal move has been validated and it should *not* be cancelled. Only the absence of vertical move changes.
   

I updated the demo link accordingly in the "back to school" post ^_^