Sprite Editor for DS : la photo

Bien, j'ai tout un tag pour les photos - les vraies - et dedans quelques-unes avec des prises de vues sympathique de mon éditeur de niveaux ou de l'éditeur d'animations que j'utilise depuis School Rush, mais une photo de mon "Sprite Editor" ? eh ...

Je ne peux pas dire "rien", mais ce sont des photos tellement vieilles ou ne montrant que partiellement l'interface. Il était temps que j'y remédie, même si je n'ai pas de développement en cours sur SEDS pour l'instant.

Would you believe it ? Sprite Editor for Nintendo DS is my oldest homebrew, and yet there was no satisfying photo of it running on real hardware on this blog !? There were some, sure, but either showing uninteresting screens, or with a user interface so old that it barely looks like SEDS at all.

I had to got that fixed, be it only to have something for people following my #SpriteEditorForDS hashtag on mastodon or bsky ! 

Jackpot!

Trouvaille tandis que j'accompagnais ma fée dans le magasin-dont-on-ne-sait -pas-prononcer-le-nom ... Bonne reliure, motif à points imprimés pas trop forts, couverture robuste ... un prix assez proche de ce que je trouvais chez Toga au début. Papier 100gr/m² qui ne laisse pas trop voir mes marqueurs habituels à travers la feuille ... je valide. Même si la tranche dorée me donne un peu l'impression de l'avoir chipé à quelqu'un d'autre ^^"

Pour comparaison, j'ai mis aussi le bujo GDMLUP téléchargé de Chine, 1€ plus cher (sans compter les frais de livraison et le CO2 ^^"), avec un papier 140gr/m² (un peu trop raide à mon goût, mais intraitable contre la transparence) mais malheureusement un motif imprimé avec une encre trop sombre et qui gène la lecture ... mais que j'utilise pour l'instant comme cahier/journal/agenda parce que ... bah, j'avais encore rien trouvé de mieux :P

appleman 2.0.1

A little bit of work on the Appleman last week-end (at last, you could add and I wouldn't blame you). I've got the "shocked" animation revised, added "carried" animations and gathered infos about where these are in green.spr.

I'll still need to see why there is no "bounce" when it is shocked (reason: it's just using stopper and the animation is supposed to do the job) and patch the greent.cmd level script on the SD card of DarkneSs, because it still show the appleman with big purple punches instead of feet. (appleman.cmd must be correct, since level 2 doesn't seem to have any similar issue).

Voilà donc enfin le moment que je prends pour compléter les animations et le comportement de l'Appleman pour le projet Dreamland. J'ai corrigé l'animation "étonné", j'ai ajouté les animations "transporté", tout ça attend dans un petit fichier green.spr le prochain passage du WiFi. Je note au passage que le fichier "greent.cmd" qui décrit le premier niveau des "3 salles" a besoin d'un petit rectificatif pour ne plus me montrer un appleman aux poings mauves ^^".

La prochaine étape sera d'ajouter les animations des "pieds perdus". J'ai aussi retiré la commande de boucle pour l'animation "assommé", mais j'arrive trop tard: c'était bon pour compléter le comportement "Apple Assault" où les applemen se réveillent seuls, mais c'est inutile pour le comportement construit à partir du fichier "blador.cmd". Car oui, le nouvel appleman est plus ou moins la fusion des deux.

So let's add tonight "undead feet" animations, check a "do not loop stunned animation" that must be over 1 year old in my notebook. I've got another notebook where I've written down blador's behaviour ... let's merge that into appleman's script and we'll cleanup the resulting code mess once the home mess is tidied up.

edit: adding the wandering feet turned out extremely annoying. They're one-sprite objects, unlike most of the things I animate with AnimEDS, and it seems the software still handle that in a very different manner: touching an sprite in the side panel adds a frame with that item, rather than changing the current frame. It also breaks relationship between timeline, frame editor and buttons in general. I'll have to get that fixed: it really breaks the user experience...

edit': pick up works, stun works, wandering feet work. Apple/water interaction is a catastrophy, throwing only work from times to times, and there's something odd when you stomp on a stunned apple (blador acted as a platform there, appleman won't). That feels like it should roll instead ... A good thing animation 2.0 freed some frames ;)
 

Goodboy('s geyser) was here

J'ai quand-même commencé à tenter de dessiner un jet d'eau. J'avais lancé un appel sur twitter, pour essayer de trouver des références. Il faut dire que les cascades de l'époque 16-bit étaient encore plus convainquantes que les jets d'eau de la même période.

J'ai eu une réponse en or, du genre de celles que j'ai eues pour les arbres l'an dernier. Le temps de faire le point, et je vous raconte tout ça ;)

"I can't draw convincing water jet from below" did not sound like a very convincing reason for not using a water jet if it is the proper game mechanic to use. I finally have a good one to pixel study and started doing my own, as you can see on the photo, but allow me to rewind and start where it started.

Un pas en arrière pour revenir à l'époque 16-bit. On préférait souvent éviter d'avoir de trop grosses animations à gérer sur ce genre de machine, et animer de l'eau se faisait généralement avec un dégradé et une modification cyclique sur la palette de couleur (palette cycling). Le foncé devient blanc pendant que le clair devient foncé, le très clair devient clair et le blanc devient très clair...

Back in the 16-bit era, it was frequent to do color cycling to animate a waterfall. Sometimes it worked nicely, sometimes it was so-so. It works best if the raster is long enough and if the animation speed remains movie-quality. At cartoon-12fps, you start seeing as flashing more than falling down water.

But you'll note the bottom of the waterfall is often missing in those scenes. And when you look at the few game art that tried having upwards water jet, you understand why: it no longer works. We expect water to become darker with density increase. In a waterfall, vertical density variation are interpreted as downwards waves, but when water eventually widens up in a fountain-like mushroom cap, it is always more dense at the center and less dense on the "edges". If you do palette-cycling here, you break that.

ça donne une illusion potable de cascade, pourvu qu'elle ne soit pas trop grande et que la vitesse d'animation soit réglée au millipoil. Et si possible, utilisez plus que 4 couleurs pour le cycle, parce que sinon on se retrouve avec quelque-chose comme le décor de Yoshi's Island qui tient plus du clignotement que de l'écoulement d'eau. 

Et malheureusement, la même stratégie est appliquée dans les (nettement plus) rares jets d'eau de l'époque. Je dis "malheureusement" parce que pour un jet d'eau, on va forcément devoir aussi animer le "chapeau de champignon" qui va avec, pour lequel la surface animée est encore plus grande. Et l'effet clignotement encore amplifié. On l'a déjà dans Bubsy, où les pixels isolés clignotants ne parviendront pas à faire oublier le fait qu'ils sont statiques. On l'a dans le final de Link's Awakening et dans le jet d'eau d'un jeu obscur avec la mascotte du Mac Do.

In Bubsy, for instance, the artist sprayed out the water pixels as the water starts falling down. This is coherent with the style, but animating them will just give you blinking static pixels of water. And the stylized 'mushroom cap' used in Link's Awakening and Mac Do game flashes even more aggressively.

Là où ça coince tout particulièrement avec le "champignon", même quand on évite les pixels statiques, c'est qu'avec ce type d'image, le clair et le foncé ne sont plus interchangeables. On voudrait que le bord soit plus clair parce que l'eau y est plus éparpillée. Faites-y du palette-cycling et vous aurez des images qui donnent l'impression d'être en négatif.

J'avoue que je trouve un peu dommage qu'avec les resources graphiques de la SNES, on en soit réduit à ça pour animer l'eau. Mais il faut reconnaître qu'en misant tout sur de la RAM vidéo, la console n'a plus la possibilité de reprogrammer les plages d'adresses (bank switching) pour faire des "animations gratuites" comme la génération 8-bit. Toute animation va impliquer un transfert DMA vers cette VRAM et le budget pour ces transferts est limité (comme toujours).

Truly, the "cap" of the fountain/geyser needs dedicated animated tiles, but we're unlikely to see that on 16-bit engines. 8-bit machines could have done that with more ROM and evolved mapper chip, but 16-bit consoles no longer try to pull pixels directly from the ROM. They put them in dedicated video RAM, and rely on DMA channels to bring animation frames in due time. But the amount of pixels you can transfer per frame is limited. Animating Bubsy's geyser that way at 60fps would consume 25% of your animation power:

On NTSC with overscan mode turned off, there are 262 - 224 = 38 scanlines in vblank. Subtract one scanline for prerender time, and you may end up with 165.5 * 37 = a smidge under 6 KiB per vblank.

6K, sur SNES, c'est 46 blocs-question de Super Mario World. Animer quelque-chose de la taille de la fontaine de Bubsy à 60fps, ça demanderait donc 1/4 de la puissance dans la partie critique du moteur de jeu.

Bon, et après l'époque 16-bit, alors ? Du côté de Super Princess Peach, par exemple, qui est plutôt réussi côté pixel art ? Un jeu ou pleurer est une mécanique de jeu, il doit bien y avoir des jets d'eau dedans non ? 

So, well, my game is not for a 16-bit system anyway, so could there be any water jet pixel art for 32+ game that I could study instead ? Say, in Super Princess Peach ? A game where you cry waterjets sure should also have some geyser-like elements, right ?

Well, it does indeed, in Wavy Beach 2. It uses a "cone" of water that might be animated through color cycling plus a "flower" top that follows the rule "keep the center dark and the edges light". But even then, I don't find it appealing, and I don't see how I could make it match anything but the super-stylized environment of SPP.

Eh bien oui, en effet. Dans le niveau 2 de la plage. Mais je dois bien avouer que je ne suis que moyennement emballé par le style. On a un premier élément (le cône) qui utilise un effet de palette qui ne fonctionne pas trop mal, les traîts latéraux restant sombres en permanence. Puis on a cette "fleur" qui grandit et rétrécit, gardant toujours le sombre au centre et se permettant des éclaboussures au bord des "pétales" sur la dernière frame.

Mais ... bof. Même en corrigeant le truc pour que la princesse apparaisse par-devant la fleur, ça ne me convainc pas. Oh, ça marche plutôt bien avec le reste de l'esthétique stylisée de SPP, mais ce type d'animation dans Bilou ? Pas convaincu.

Et depuis ? Parce que bon, le modèle pour la cascade de Bilou, il ne date pas de 2005. Mais le truc, c'est que j'ai surveillé les cascades en pixel art pendant pas mal d'année, sachant que j'en aurais besoin tôt ou tard. Alors que des geysers, c'est plutôt un truc de dernière minute.

Et c'est là que hot_pengu, l'auteur de Goodboy Galaxy, m'a pointé vers la vidéo de son jeu sur GBA

And so I finally asked hints to people on twitter who might have seen something I could use as a reference, or ever proper keywords to search for one, and to my surprise, I received an answer from indie game developer hot_pengu:

We call it a 'geyser' internally for goodboy, and this (timestamped vid) is how we represent it.

Je jette un oeil, je prends un petit screenshot pas fou mais qui pourrait donner un point de départ, et là,

Here's a better look, if it's useful! (there's two versions, one comes out of a monster)

He added as I posted a quick snapshot for future pixel study, handing the Goodboy Galaxy spritesheet with 2 sizes of exactly-what-I-needed material that you see printed on the top photo. 6-frame stunning animations, with tileable base and stylish top. Even the style isn't that different from the one I have for my waterfall!

Une animation pixel-art moderne, tout en fluidité et utilisant bien les 6 frames, qui peut être étirée en hauteur comme on veut ! C'est celle que vous avez vu tout en haut de cet article, imprimée et que je suis occupé à étudier. Parce que là, j'ai bien mieux qu'une référence pour donner une seconde chance au cas du bouchon: j'ai une idée.

Voyez, ce geyser, je peux le placer au fond du trou, directement, sans avoir besoin de bouchon. Il bouge, il attire l'attention. Pas moyen que le joueur ignore sa présence. Il a un look quelque-part entre la plate-forme et le bumper ... on pourrait toujours sauter dessus, on ne sait jamais. 

I like how it simply requires the player to hop into the proper spot to trigger. Much cleaner gameplay than the "pull the cover" I had thought about, but it remains interactive. Plus, by being already flowing before we interact, there's no more questions about "where does this water comes from, where does it goes afterwards", etc.

Deuxième bon point, une fois que Bilou a sauté dessus, je peux réutiliser le type de comportement que le joueur rencontrera plus tard avec Inkjet: Bilou reste "coincé", la pression s'accumule et wouf! on est projeté vers le haut.

And that would match the way 'inkjet' monsters will lately be used as delayed bumpers in the School Zone ... Since this game will no longer feature a welcome screen with the inkjet, it's a good thing the player can be shown early what happens after the "caught in a boiling pot" animation.

Et si il a raté son premier saut, il peut retomber sur le "chapeau" du geyser et re-sauter de là.

Mieux encore: si le joueur n'est pas resté dans le geyser jusqu'à être projeté, on peut le pousser vers le haut s'il entre en contact avec le "pied" du geyser. Et si rien de tout ça ne se produit, on peut directement réessayer la même manipulation. Pas de risque d'aller se coincer en nageant, de faire redescendre l'eau trop tôt ou quoi que ce soit de ce genre.

Bref, j'avais pensé vous redessiner *mon* geyser sur DS pendant la petite semaine de vacances, mais au final, j'ai juste eu le temps de faire une petite feuille de notes pour illustrer ce que j'imagine comme mécanique avec mon geyser ... parce que les vacances d'une famille 11 + 15, ça ne ressemble pas vraiment à la dynamique 8 + 12 et ses plaines de jeu à surveiller :-P

I expect that the platform-look of the geyser top will invite even the younger players to jump on. I expect that its animation will catch their attention much more than a purple block or handle. Should they fail to use the bump effect to reach the key, they can be caught by the platform-top and jump again. If they jumped out before the geyser happened, they can jump into the flowing geyser and be pushed up to the platform-top. It's flawless ^_^

Now I just need to find enough time in the upcoming evenings to complete it ^^"

PS: if you want to animate something like that, consider animating it without the vertical motion first: just the wobbles and the sparkles, and only then apply the vertical shift to each frame. Unsure I will follow that advice myself this time.

Ciao, Lime ?

Depuis plus de 10 ans, c'est surtout ma DS colorée "Lime" que vous voyez. C'est elle qui sert à dessiner des nouveaux pixels avec Sprite Editor, c'est elle qui a l'éditeur de niveau à jour pour 3-rooms. C'est encore elle qui va m'aider à faire des animations pour les nouveaux personnages.

Mais là, pour les derniers ajouts pour avoir du sable fluide, Lime me lâche. Son trigger gauche ne répond plus qu'occasionnellement, or il est absolument critique pour tous mes outils. C'est lui qui fait la différence entre "CTRL+C" et "CTRL+V" dans l'éditeur, la différence entre "pipette" et "pinceau" dans SEDS. La différence entre "charge en mémoire" et "enregistre sur ma carte SD" dans runme. Le bouton "L", c'est mon clic droit.

Hold the L trigger in one of my homebrews, and you're swapping between "pull mode" and "push mode". You pull a colour out of the SpriteEditor grid. You push a sprite into a sprite page. You push a colour into the palette, etc. Hold the L trigger on that Lime DS I've been using as gamedev unit for about 10 years and ... nothing happens. I want to pull the colour of a pixel and I push the current colour to that pixel instead. I want to push something to the sheet and I pull the older contents instead. Same if I try to pull the current tile of some spot of a level: I end up pushing the last used block instead. No need to say that this made the last step of "fixing the sand falls" super exasparatingly tedious.

Ce n'est pas la seule, bien sûr. Il y a aussi DarkneSs, qui était numéro 1 pendant AppleAssault mais qui depuis sa chute a pris plus le rôle de distracteur d'enfants mais pouvait parfois ressortir quand un test un peu plus audacieux (nouveau devkit, p.ex.). Un petit swap de linkers, un changement d'adresse IP dans mes commandes de transfers par WiFi et la voici prête à prendre le relai et poursuivre le marathon.

Les réparateurs de DS sont plus rares que dans les années 201x, évidemment, mais mon frère a pris pas mal de galon dans ce genre d'entreprise. Je garde espoir qu'on puisse remettre cette console photogénique en selle d'une manière ou d'une autre. Ses écrans et sa batterie étaient encore parfaitement opérationnels. Ou a défaut lui trouver une remplaçante.

Hopefully, that does not kill all hopes of seeing more homebrew contents from me. I still have my DarkneSs unit and its triggers seem all fine. Just swapping the linker cards, changing an entry in my IP addresses list and it's ready to take over the tasks. I have hope that the faulty trigger of Lime can be fixed, and my brother even offered a third option just in case (I'll have to find a name for a grey device, if we pick that up. Mithrandir might do)... Wait and see.

(Et pour faire bonne mesure, voilà la coque de protection de ma liseuse boox qui tombe en morceaux :/ )

Un p'tit coup de marteau ...

Mes dernières sessions avec AnimEDS s'étaient toutes soldées par des "guru meditation". Peu de travail perdu, heureusement, le problème se produisant généralement soit juste au début, soit juste après une sauvegarde. L'impact sur ma motivation à continuer à animer mes p'tits persos en prenait quand-même chaque fois un coup: j'aurais pu effectivement perdre un travail précieux.

Alors j'ai noté de faire du debugging de tout ça. Il y a un bail. D'abord refaire une version précise de l'animateur (rH2021) et garder le .nds et son .elf à côté des fichiers re-générés à tout bout de champ quand je bricole du homebrew, histoire que quand le problème se présente console en main, je puisse effectivement utiliser la valeur du registre PC pour retrouver un numéro de ligne dans le code. C'est le cas depuis Juin.

I can't help wondering whether this is worth translating. It's another epic (?) showdown between me and my code to see who's got the StrongARM. But well, it has been bugging me since January, crashing the animation editor almost every time I used it. I'm just lucky I never lost anything important but motivation to work on some cute things over the evening. The "guru meditation" screens I got during the first half of the year were almost useless: the AnimEDS build on my 'lime' DS was so old I did not have the matching .ELF file for my debugger anymore. Believe it or not, the RealLife (tm) has turned so intense that I even had to write down an agenda check list with "rebuild ; keep .elf apart ; upload .nds to lime" to actually get it done.

Pas de chance: c'est un de ces bugs où l'adresse ne dit pas grand-chose parce qu'on est a suivi des pointeurs de fonctions qui ne voulaient rien dire. Mais! Bonne nouvelle, avec les nouvelles animations pour l'Appleman, le bug est plus facile à reproduire: il suffit d'essayer de copier une frame d'animation juste après avoir chargé la première animation du fichier dans l'éditeur.

Alors j'ai ressorti mon émulateur et mon débuggeur et là, bonne nouvelle, ça foire aussi dans l'émulateur. Différemment, mais ça foire, donc c'est débuggable. Et là, j'ai galéré pendant des heures ... Des structures qui ne veulent rien dire, des vptr complètement à l'ouest ... Il faut dire que pour encoder la ligne du temps utilisée par l'éditeur, j'ai pris une std::list de std::pair de classe dérivées. Bref, on se perd sous les couches de templates, de membres dépendant de l'implémentation et d'optimisation du compilateur qui prend un malin plaisir à rendre inaccessible les variables dont on aurait besoin.

With that done, I wasn't much more lucky. It's one of those bugs where you try doing a virtual function call on something that isn't truly an object and thus end up in the middle of nowhere, especially where memory contents doesn't match any valid opcode. Hopefully, while trying to get the crash to write down registers values, I realised that the bug was actually easy to reproduce (just open one animation and try to copy the frame before selecting any frame) and a bit later, that it also happened with the same file in my emulator. At least I could save the evening where I navigate DS memory to reconstruct objects on paper this time.

J'allais jeter le gant puis un soir j'ai noté dans mon calepin "fait du débugging indirect en surveillant les constructeurs". Bah oui: la variable aura beau avoir été optimisée, il faut bien qu'il soit construit à un moment où à un autre, le TIFrame qui explique pourquoi j'ai du n'importe quoi dans les registres au moment de copier cette première frame.

Sauf que ... non. Les "TIFrames" sont construites vides, puis au fur et à mesure que l'AnimationParser traite la liste de commandes destinées à GEDS -- le moteur de jeu -- il complète les coordonnées, les numéros d'images, etc. J'étais sur le point de laisser tomber (traduire: réécrire tout avec ma propre classe 'liste' plus propice au debugging) quand je réalise que je peux "figer" l'afficher d'une ou de TIFrame dont je capture l'adresse à la construction, et suivre leur évolution jusqu'au bug (l'animation en question ne contient en réalité qu'une frame et une commande de contrôle). Et là, surprise, tout va très bien (Mme la Marquise :)

 It did not save navigating memory altogether though. The way gdb handles std::list and std::pair combined to the amount of variables that were actually "optimized away" when they would be critical to have around still turned that debugging session into some guru meditation. I first thought that it was because of some incoherent animation instructions into the animation itself, but inspecting how the animationParser processed them shown everything should be fine. Yet, if I tried to see what frame was triggering the bug, all I'd get was garbage non-sense. I was about to replace all that std::* by some pype::* when I realised that I could just break on constructors of the contained TimeItems to see what the list contained.

That did not work either, unfortunately, because when TimeItems are added to the list, they are "blank" items that will be modified by the yet-to-come UPDATE animation commands. What did help, was creating some static watches at addresses discovered in a constructor-breakpoints so that I could look at the state of my list just before the offending call. That and realising that the list was just fine, thanks, but that I was using an iterator that might not have been updated since the previous list had been trashed and replaced by the new one :P

Une seule explication restante: c'est l'itérateur qui devient invalide au bout d'un moment. Je sors mon cahier A4 histoire de me faire une map UML de tous les bouts de code impliqués et c'est bien ça: quand on choisit une animation à éditer, la liste est vidée, mais l'itérateur reste inchangé, ce qui est invalide.

Ah oui. Vous vous demandez "pourquoi le marteau" ... et vous n'avez pas Thor. C'est à cause de cette blague d'ingénieur où un consultant rentre une facture de $100000 pour une intervention et ça rouspète chez le client parce que "vous avez juste donné un coup de marteau!". Et le consultant de reconnaître qu'il a fait une erreur et de préparer la facture suivante

• 1 hammer hit: $10
• knowing where to hit $99990

(bon, c'était vraiment une grosse machine très chère qu'il fallait dépanner). Bin c'est un peu la sensation que ça me fait sur ce bug-ci. Sauf que je ne vais pas recevoir des cents et des mille et que je ne devrai pas les débourser non plus :P

 

greent.map

Se pourrait-il que j'arrive malgré tout à avoir une démo "3 rooms" pour la fin de l'année. Enfin un premier jet. Le hic n° 1, jusque là, c'était la quasi-impossibilité de faire une nouvelle map propre. Depuis l'introduction de la branche newmap, l'éditeur de niveau ne savait plus le faire, mais j'ai fini par trouver ce qui n'allait pas

Maybe I'll have a 3-rooms demo by the end of the year ? Not with all the features working, of course. Expect static waterfalls and incomplete water physics, but at least a .nds where you could travel freely between the 3 environments I have so far. Until yesterday, that was hindered by a bug in the level editor that prevented me from creating new maps: I could only update existing ones. But that bug is now solved, so I started tiling 'greent.map' and 'schoolt.map' as I intended them to look like in my notepad.

Du coup j'en ai profité pour redessiner en 512x256 les niveaux-démos prévus, rajouter les palettes de couleurs que j'avais essayées pour les cascades. Il n'y a pas encore d'animations ni de physique de l'eau ... ce qui donne un résultat un peu perturbant (mais pratique pour aller voir ce qu'il y a d'autre sur le 2eme écran). Ouaip. c'est l'avantage de la Saint-Nicolas en quarantaine quand les enfants ont assez grandi. J'ai eu l'occasion de m'asseoir avec ma DS à côté d'un Gimp.

Then I went ahead, taking advantage of the 'woot-we-have-new-toys' while we're all locked-home by quarantine to open my earlier waterfall mock up and redraw that into SEDS.

I hope I'll be able to do the same with pyrat.map soon.

Loading more, in LEDS

Bon, les soucis avec le moteur de jeu semblaient réglés, donc j'ai voulu vérifier que l'éditeur, dans sa version 1919 (une petite révision en-dessous du code sur mon laptop) présente sur Lime savait bien modifier des choses sans perdre d'information.

Je me rends compte que tenter de re-charger un deuxième niveau dans l'éditeur conduit au mieux à un iScriptException, au pire à un crash à une adresse venant du void*. Entre les deux, un "bon vieux" crash comme sur cette photo, qui pointe du doigt la boucle interne à Block::getnext()

Le 'pire crash' contenait quand-même quelques adresses vers du code dans la pile et suggère de regarder du côté de l'appel à Block::append() dans Level::ScanSubFile().

L'affichage des miniatures dans l'écran d'accueil, c'était pas terrible non plus. Plusieurs fichiers avaient juste des têtes de Bilou partout. Une résurgence d'un problème que je croyais cru réglé ? (ça se produit essentiellement avec greent.cmd et ses SimpleGobs, on dirait)

On dirait bien que ce n'est pas trop difficile de reproduire le problème avec 'cmdck' pour peu qu'on lui ajoute un moyen pour charger un 2eme fichier de commandes. Un peu plus de mettre le doigt sur le problème, puisqu'au moment du SEGV, on est envoyé à une adresse invalide.

Un cran plus tôt, on voit une liste de blocs dont le dernier a une table de méthode virtuelle totalement farfelue. Et ça, pour le premier bloc à traiter dans 'ink.gam'. Mais il y a eu un autre fichier .gam passé en revue avant, et le bloc farfelu est de type 'END'.

Je refais un 3eme tour de programme, je surveille tous les ajouts de blocs spéciaux. Et en réalité, le bloc "end" s'auto-ajoute dans la liste. Du coup, faire un 'delete' dessus parce qu'il n'est pas du type 'spécial', ça casse forcément tout.

edit: un petit 'ledsdbug.nds' qui reprenait les modifications utilisées en Avril pour corriger les miniatures, je remarque du coup que les miniatures sur NDS essaient toutes d'utiliser le sprite #0 ... louche ... la modif 'Anykey()' ramenée aussi et je constate que la ligne 'spr.more' n'a pas été correctement traitée. La faute à une valeur incorrecte pour la correction des numéros de pages d'animations (ouais. C'est technique hein ? j'aurais peut-être juste dû parler de 'pageshift', comme dans le code ^^). Rien de ce genre sur mon PC et pour cause: le code de LEDS a inversé le pageshift lors de la dernière sauvegarde ...

Par contre, du coup, l'outil de test cmdck -s greent.cmd > /tmp/green2.cmd me montre que toute la première moitié du script n'est pas ré-écrite après le traîtement. 'va falloir que je ressorte encore ddd. Euh non. ça c'était juste une interférence entre fprintf(stdout) et fopen("/dev/stdout"). 'faudra que je sois plus prudent avec ça.

re-edit: une fois ce pageshift corrigé, ça ne marche guère beaucoup mieux. Les miniatures ne sont toujours pas chargées parce qu'il y a des valeurs complètement incohérentes à la place des numéros d'animations dans le fichier. En fait, le fichier tout entier est sans-dessus-dessous dès qu'on atteint la section des animations et des miniatures.

Et ce n'est pas la première fois que j'ai des ennuis avec ces sections. Je ne peux pas exclure que c'est parce que j'ai utilisé une ancienne version de SEDS ou MEDS sur Lime. Mais je ne peux pas non plus exclure qu'il reste quelque-chose à corriger dans les éditeurs. (les éditeurs en version finale sont clean. Mieux: AnimEDS est capable de corriger un fichier foireux rien qu'en l'ouvrant et le re-sauvant).

re-re-edit: avec un fichier .spr valide, il me restait deux soucis à résoudre dans LEDS:

• éviter les crash si on pointe dans le vide pendant l'édition des monstres (MonsterPropertiesWindow n'était pas prêt pour ça). Un 'simple' pointeur NULL, mais qui attire mon attention sur le fait que le hardware de la DS autorise qu'on lise à l'adresse 0 (en fait, tout une page de 32K).
  
• avoir un affichage correct des miniatures produites par AnimEDS, et pas cet espèce de potée aux pixels que l'on voit pour Bilou. un simple '+2' qui manquait dans la version qui tournait sur DS.
  

Mais c'est compris et réglé pour attaquer le dernier week-end de congé. 'faudra que je note de comprendre pourquoi mon curseur de monstre a re-disparu, par contre.

DJLN.cmd

Faire des niveaux sur papier, ce n'est définitivement pas une activité à proposer à mon fiston. Au mieux, je peux lui proposer de me dicter un niveau que je ferais moi sur papier.

Par contre, prendre la Nintendo DS de papa et ajouter des blocs ici et là, ça ça lui plaît bien. Mais pas de chance, la branche "newmap/newmeta" n'est pas encore stabilisée au point qu'on puisse tenter de jouer au niveau ainsi construit.

Assez surprenemment, mon nouvel écran de patching m'indique que l'erreur se trouve sur la première ligne de pyram.spr, CMAP n'étant pas une commande valide pour les scripts. Enfin, ça c'est sur émulateur après avoir récupéré les fichiers présents sur DS avec le wifi remis en service.

En fait, ce serait la commande spr.more "pyram.spr" qui n'a pas été comprise par l'éditeur de niveau. Du coup, au moment de sauver, il en fait un input "pyram.spr" Si j'en crois les numéros de version, le bug a déjà été patché, c'est juste que la DS n'avait pas pu profiter de la nouvelle version. C'est J.L.N qui va être content...

• invoking autoexec.cmd with the [run] button does not seem to allow PatchWindow to be invoked.

Twitter Trap Status: story is featured in "All tweets from blogger". No videos around. 

pyramt.map

Files transferred. Last week, I had just complete mess of tiles, some even not part of the file, but things remaining from the previous level. Hopefully, each of these level worked fine in the level editor on the NDS.

With a bit of tweaking, I could also get the shown in runMe. After I remembered I had a button to show the loading log in case of failure, I realised I had a few files missing (mostly .gam files) and I could get school title screen working with sprites as well.

But as far as pyramids and green zone maps are concerned, I'm still trying to get them working. Dreams.nds itself triggers a blue screen somewhere in GobAnim::translatecommands.

Avec un peu d'astuce, je peux maintenant avoir un niveau "pyramidesque" dans l'éditeur comme dans runMe. Pour runMe, il aura fallu que je me souvienne d'activer l'affichage du log (parce que oui, il est toujours là, juste caché), histoire de réaliser que la DS n'a pas le fichier .gam demandé. L'éditeur de niveau peut passer par-dessus un problème de ce genre, mais pas le moteur de jeu. 

One thing, though. It's nice to have a memory crawler embedded into my exception handler, but I should make sure it doesn't trash the precious registers I had on-screen when I'm exploring invalid addresses (first, because it is impossible to hop from 0x0b00xxxx stack addresses to 0x020xxxxx heap/code without entering some invalid addresses, and second because moving down to higher addresses makes the DPAD to enter addresses confusing at best)

SchoolRush, Armitage et 42

Si vous avez envie d'en prendre plein les yeux, passez donc faire un tour sur le site web d'Armitage, le dévelopeur belge de Métagolf... et qui me signalait sur twitter qu'en restaurant sa Nintendo DS, il a retrouvé une version de SchoolRush sur son linker AceKard ^_^

Alors en attendant que Outcast II sorte, je vous reposte sa photo. (ah oui, à l'époque, je n'avais pas eu l'occasion d'essayer Outcast mais j'étais tout à fait fan de l'idée d'utiliser des techniques de démoscèneur pour faire le rendu de la planète plutôt que de tout miser sur des gros polygones tout moches comme dans Tomb Raider ... Et j'avais la ferme intention de postuler chez eux une fois mes études d'informatique terminées si personne ne voulait me financer le développement de Clicker)

spr.load+

The next big step for my game engine to be capable of running project “Bilou  Dreamland” is overlay loading. In all my previous games, there was one main tileset and sprite set that contained all we needed. Monster, hero, Pick-ups. Anything that had to be animated sat together in that file…

Bon, prochaine étape significative pour le développement sur DS: faire en sorte que le game engine puisse charger les graphismes "en deux temps", en particulier pour les sprites. J'aimerais bien éviter de devoir répliquer le graphisme de Bilou sur plusieurs spritesets, tout simplement.

Et ouaip, j'étais prêt à lancer ça en début de congé de Noël, puis je suis laissé distraire par un 'to branch or not to branch', *deline m'a chipé la tablette pour lire du Ewilan, et moi je me suis mis à faire du déterrage de brouillons :-/

C'est ça, la quarantaine: ou bien tu code, ou bien tu blogges. Les deux, c'est niet.

In order to come up with a “world 2” that features new creatures, this has to change. Especially, I want to have a single “Bilou.spr” containing character animations for all moves. The engine will then complete this with world-specific monsters and NPC data. When you think about it, the very reason why there’s never been a level 2-1 in my BASIC games was because  I couldn’t find the proper solution to this design challenge.

Mais, allons. Ne soyons pas défaitistes: c'est pas que je n'aie rien fait sur DS pendant les vacances. Juste que je n'ai pas fait ce que j'avais prévu, et que j'ai complètement perdu de vue depuis ce que j'ai fait depuis ce moment.

Plutôt que de me lancer dans une nouvelle branche, j'ai stabilisé et consolidé les différents outils.

edit: j'ai déjà quelques p'tites modifications qui donnent pas mal.

Par contre, il faudra que je réfléchisse à un moyen de valider que tout ça fonctionne bien comme prévu.

Well, I was about to start this at the start of xmas holidays, and then *deline picked up my boox to do some e-book reading while I was wondering whether a new branch would be required or not and then I ended up spending the holidays posting some very old drafts. Welcome to being 40: blog xor code.

well, nor the whole holidays, actually . I’ve still been able to do some ndsdev, just not the kind of things I expected. Tools are now stronger and more reliable. I’ve finally started to code something for it, but I need to figure out how I am going to test that.

edit 30/1: j'attaque...
edit 2/2: sprdo could help testing it.

Bilan sur DreamLand : première année

2020 s'ouvrait sur un constat: il y a quelque chose de bien vu dans la formule de Kirby's Dreamland, un équilibre entre sophistication et simplicité, qui pourrait être un bon intermédiaire entre les petits jeux comme SchoolRush et la grande aventure.

Avoir un objectif m'a motivé à me sortir des tests unitaires à répétition qui auront pourtant continué quasiment jusqu'en juin. La deuxième moitié de l'année aura permis de remettre à jour mes outils (et LEDS en particulier) pour utiliser les nouvelles fonctionnalités du moteur de jeu en terme de propriétés du terrain

Flashback to early MMXX: there’s some successful alchemy in Kirby’s Dreamland, a balance between feature-rich yet kept-simple gameplay, and it could be the intermediate step l need between small games I’ve made so far and the Grand Adventure we once ambitioned.

Having such a goal clearly boosted my motivation and helped me to pull me out of this unit test swamps where I was. Starting with June, tools got upgraded – esp. the level editor- to enable the ‘new map’ in the engine

Entretemps, J.L.N a parfaitement adhéré au projet. Ça ne le fait pas plus prendre les crayons mais il m'innonde littéralement les oreilles de ce que les boss pourraient faire et comme LEDS est réparé, il peut même commencer à dessiner des niveaux selon ses préférences. Ce n'est pas aussi directement exploitable que le niveau gribouillé de Rémi, mais ça lui fait passer le temps.

Il faut dire que s'il y a bien un truc sur lequel je coince, c'est le fait de dessiner des bouts de pyramide ou des bouts de parcours dans la montagne pour compléter la 2eme moitié des 4 mondes prévus pour DreamLand. Le confinement ne m'a pas autant aidé que je n'aurais voulu, de ce côté-là.

Meanwhile, J.L.N. joined the project. Not that he would pick up any pencil, but I’m litterally flooded with proposals about what bosses could do. And since LEDS is repaired, he can even draw some levels when he feels so. It might not be as ready-to-use as Remi’s level was, but at least, it keeps him busy and focussed.

Par contre, je prends ici-même une résolution: je prends le risque d'avoir un mélange entre perspective 5:6 et vue frontale dans le jeu (idéalement pas au sein du même niveau quand-même), et d'en subir les conséquences plutôt que de continuer à me griller les neurones à savoir quelle serait la meilleure approche. L'expérience nous dictera comment faire pour la suite. Sans ça, je vais de nouveau faire un 'analysis paralysis' là-dessus. Les graphismes déjà dessinés resteront dessinés tels quels et ceux qui devront venir compléter un niveau s'adapteront au style du niveau en question.

You deserve honesty, here: I struggle with level design for the pyramid world. And the mountains level isn’t any easier. Even being confined did not help in that regard. Yet I still want to have these zones featured in Dreamland. 

So let me at least take a new year decision: I accept the risk of mixing 5:6 perspective in some level and frontal view in other levels of the same game. There might be some consequences but I prefer facing them rather than boiling my brain to find a hypothetical perfect solution. The game will test that, and will teach us what to do in a future game. The alternative is more months of analysis Paralysis. But whatever has been drawn already will stay as they are.

Reality check

 J'ai atteint un stade dans le développement de mon nouveau LEDS ou je peux envisager de faire un essai sur du vrai hardware. (En fait, il y a plusieurs choses que j'aurais dû essayer depuis longtemps, mais il semble y avoir une sorte de flemme à ressortir la DS et démarrer server.pl, ces derniers temps). ça fait une jolie photo, mais j'ai facilement passé la soirée à faire l'inventaire des choses qui ne vont pas :P

One bit at a time, a new build of LEDS has appeared, that combine enough patches from the 'newmap' branch so that I can consider giving it a spin on real hardware. Well, or so will I pretend. The crude reality is that the "Check List for RealThing" is only a few page past "April 2020" in my notebook.

I got no significant crash, but many of the features are incomplete. The evening was gone when I finally had the list compiled. Next evening, I'll update the e-book doxy-code and will start investigating why I have "bugWindow" inserted between MapeditWindow and MonsterWindow ...

La conversion des niveaux, par exemple, est incomplète. Ni les tiles "jump-through" ni les pentes n'ont été récupérées. Sur un vieux niveau où il n'y a pas de déclaration des blocs spéciaux, ils sont tout simplement invisibles (voire peut-être ignorés).

Les copier/collers de blocs spéciaux sont un peu bizarres aussi, en particulier pour les tiles "voir ci-contre". Je sais pourtant en créer de nouveaux en utilisant directement les Meta-Boutons.

Enfin, il se passe quelque-chose d'étrange avec la gestion des "fenêtres", comme si il y avait un mode "buggué" entre le mode "dessin" et le mode "édition de monstres".

Je sens qu'il va y avoir un nouveau .epub avec le code le plus récent à télécharger sur boox ...

L'ère post-desktop

Bon, soyons clairs: être sur un PC - un vrai, avec une souris, un clavier, une connexion réseau et un écran - ça ne m'arrive plus qu'au bureau. La bricole homebrew, ce sera de temps en temps sur le laptop ... avec tout ce que je peux préparer hors-PC hors PC. Le "engine design" dans un cahier atoma -- pour pouvoir mettre en vis-à-vis les idées et leur conséquences -- la documentation UML dans un cahier A4 quadrillé à spirale, etc. J'ai même tenté une sorte de 'bullet journal' pour suivre ce qui devait aller sur le blog, les posts en standby etc, qui est tombé plus ou moins dans l'abandon depuis que je me suis installé Wordpress sur mon Boox.

Let's be honest: being on a true PC -- with a mouse, a keyboard, a screen and an Internet connection, that only happens at the office. Homebrew devin' nowadays, that's on a laptop, and everything that can be prepared off-screen is welcome. So game engine design happens in an Atoma notebook (so I could put an idea side-by-side with its outcome), UML documentation goes in friendly A4 notebook, and I even started a 'bullet journal' to track what blog posts should be updated, those waiting for sketches to be scanned, and those who are waiting for translation (although installing Wordpress on my boox helped with this)

I level'd up these offscreen tools this year, with a dotted-paper notebook where I scribbled "proudly powered by CreaCorner" that somehow became my true (offline) blog until I shoot a picture and share it on twitter. 

 This is where I collect my todo lists, things to be reviewed, things that should be done when I spent an hour on the laptop, and so on. And I'd rather keep going, since I'm in half-zombie state when I'm finally done with dish-washing these days. Without dotted paper help, I'd be browsing from one abandonned forum to the next one and not even having enough energy to start reading what people have posted.

Et depuis cette année, je me suis trouvé un super petit cahier pointillé à la fin duquel j'ai écrit "proudly powered by CreaCorner (en fait, c'est un Bullet Journal Toga) ... c'est plus ou moins devenu mon vrai blog, sauf qu'il n'est pas en ligne... allez, quelques photos de temps en temps sur Twitter.

Je me fais aussi mes petites "todo listes" dedans. Les choses à relire dans du code converti en e-book. Pourtant, une bonne partie des 'todo items' auront besoin de repasser sur PC. Parce que vu l'heure à laquelle j'en ai fini avec la vaisselle ces jours-ci, quand j'ouvre mon portable, je suis en mode demi-zombie ... je passe de forum vide en forum vide sans vraiment avoir l'énergie de lire ce que les gens y ont mis.

Donc, bin je vais me les ré-encoder ici, histoire d'avoir cette liste sous la main dans les rares cas où je suis sur PC :-P

• Q: où est-ce qu'on en est avec LevelModel, pourquoi ::SaveCommands() est vide ?
• Q: pourquoi avais-je introduit "MonsterGeneration"
• A: cette classe apparaît en même temps que le système de tri des 'blocs' de texte pendant les liens entre objets ... sans doute une tentative avortée qui sera restée au moment du commit faute de reviewing correct du code.
• Q: pourquoi est-ce que je n'ai aucune doc sur EditorLevel::scanSubFile() ?
• [todo] Refaire un coup de -WeffC++ sur le code, et trouver les #pragma push qu'il faut pour que le code incapable de supporter 'effective C++' se taise une fois pour toute et que ça devienne le mode par défaut pour la compilation.
• [done?, merged] transférer des captures d'écran des outils dsgametools à l'intérieur de la doc doxygen
• [todo] faire en sorte que SpriteRam apparaisse dans la doc du SpriteEditor

edit: voilà. je viens de terminer d'écrire ça et mon GSM me rappelle à l'ordre façon Monkey Island: "maintenant éteignez votre ordinateur et allez vous coucher".

deep blue InfiniMap

CommonMap revision changed the lookAt/scrollTo interface of background layers to take unsigned positions. After all, it shouldn't be possible to set the center of the screen into negative coordinates when the top-most corner is (0,0).

But I will need to keep internal computation of signed integers anyway. else I get blue meditation screens...

The core of the problem is that processors have two main way to understand numbers: one where the top bit of the number has no special meaning (we call them 'unsigned' numbers and they're all positive), and one where it tells whether the number is positive or negative (with some tweaks, and we call them 'signed' numbers). And among the operations the CPU can perform on number one behaves very differently on signed and unsigned numbers: division. Divide an unsigned number by two, and you'll always have to insert a zero in the top bit. Divide a signed number by two and the top bit remains sticky.

If you mess with the numbers signedness (issue unsigned operations when you should have used signed operations) and you may easily turn a small, negative number into a big, positive number during a division. That's what I did with my update ... this is what I have to fix now... hmm... tomorrow. It's time I give my eyes and brain some rest.

Doxygen on Onyx

I don't exactly know what I have changed, but using the "Neo Reader" application on the Boox today, my doxygen-to-epub-through-calibre file now renders as expected. I thought that could be linked to the disabling of "cache reflow bitmap" cryptic option in the advanced settings (see the small icon pointed by the stylus on the picture), but re-enabling it doesn't change anything (or it only has an effect when restarting the application ?)

Qu'est-ce que j'ai changé ? Je n'en sais plus trop rien. J'ai "torturé" le morceau de code qui apparaissait dans la version e-pub de mon blog pour essayer de trouver ce qui faisait la différence entre un rendu correct (white-space: pre-wrap ? utilisation de
<pre>plutôt que <div>? de <tt> plutôt que <span>?

Rien n'a semblé avoir d'effet. Puis ce midi, en jetant un coup d'oeil à mon code converti par doxygen et calibre, surprise! tout est impecablement rendu.

Plus de numéro de lignes indésirables, changements de polices, traitement correct des espaces ... tout y est.

Est-ce que ça vient du réglage "cache reflow bitmap" que j'avais changé ? difficile à dire. Le désactiver ne semble pas avoir d'effet immédiat, mais ils auraient pu omettre de dire qu'il fallait redémarrer l'application ...

One major drawback, though: Neo Reader application is the only one for which I find no way to hop back to the place I was before following a link in the epub document. And that will make navigation extremely annoying, I'm afraid.
Neo Reader v2.0 had nice backtracking feature, and that one gets interesting behaviour on my test epub document.

• When using <span> or <div> with the CSS classes associated with working 'code-style' elements, nothing happens
• When using <pre> or <tt> with the same elements, code is rendered as it should (as printed on dot-matrix ;-)
• The style applied to "English section" (using <en>) doesn't go italic, while emphasis directly using <i> in the French part goes italic.
• skipping CSS classes altogether has no impact (given that you're using
  
  pre/tt tags)
• embedding the whole stuff in "blockquote" doesn't seem to have much effect
• trying to use tables with colspan and some cells containing only a few whitespaces failed miserably. I think all cells are just sitting in a vertical list, not laid out on a table at all. 

runMe is coming back

I got the most annoying bugs fixed, and in the "restructuring" branch, I'll also be able to use the same controllers/shooters state machine plug-ins for both runMe (the interactive playtest tool) and the final SchoolTest ROM.

I can choose between regular background and debug console output too. InspectorWidget, on the other hand, is messed up with some text. I'll be able to resume level design...

Avoir mon programme de chargement à nouveau opérationnel, c'est plutôt une bonne chose. Il est peu utile de faire progresser l'éditeur de niveaux -- ou de dessiner un nouveau niveau à la verticale -- si je dois à chaque fois transférer le niveau hors de la DS, recompiler tout et récupérer à nouveau le .nds sur la console pour faire le test... et c'est bien à ça que runMe me sert le plus: tenter un morceau de niveau avant de retourner dans l'éditeur, faute d'un mode "modification de la map en cours de jeu" qui serait indispensable pour un projet plus sérieux.

well as soon as I figure out why the level editor is stripping out all the dynamic objects. (not that it's so surprising, as the last thing I tried was to remove dynamic objects that were out of the level's boundaries).

There are other oddities linked to incomplete port to the latest devkitpro/devkitarm/libnds, imho, such as

• [fixed] no sound playing in new builds of runMe
• [fixed] no EFS found for SchoolTest
• [workaround] everytime a level is loaded, 3D effect is zoomed out a bit more
• [fixed] dying on the title screen leads to the game to stall on a blue screen.
• [fixed] none of the runME control widget seems to be working once the game is running...

Le Rush des p'tits n'veux

Petite après-midi de test de gameplay chez mes neveux, testeurs de Bilou depuis les premières heures. L'occasion de voir comment ils réagissent au nouveau niveau et au réglage de la difficulté. Ils sont maintenant des vrais fans de Bilou: la question n'est plus de savoir s'ils vont ou pas me demander un autre jeu ou après combien de temps.

Premier point positif: le système de jump-bounce. A aucun moment aucun des enfants n'a trouvé anormal ou gênant que Bilou rebondisse dans certaines conditions. Ils ont utilisé le "double-jump" sans avoir besoin d'explications pour se sortir de situations difficiles, mais sans hurler à l'injustice ni demander pourquoi on ne pouvait pas s'en servir à n'importe quel moment.

Autre chose intéressante: pour la plupart des joueurs, s'accrocher à une éponge est délicat. Ils sentent bien qu'il y a des bonus ou un intérêt non-formulé à être en hauteur, mais le timing n'y est pas. Pour la plus jeune de mes testeuses (8 ans cette année) qui n'aura testé que le "mode facile avec l'encre immobile", c'est pourtant la technique qu'elle utilise le plus et elle y excelle, même si les sauts qui suivent ne sont pas toujours réussis. En fait, on dirait qu'elle ne peut se passer de grimper sur une éponge même si ça ne mène à rien. Ensuite, elle se mettra à chercher la suivante. En clair, elle se définit elle même ses objectifs et le jeu n'est qu'un terrain d'expérience, pas un défi précis.

Start+R+A

Reprise du boulot oblige, la progression de cette semaine est moins impressionnante, mais peut être tout aussi importante. Si DaySi a brillamment repris le flambeau depuis la chute de DarkneSs, elle se fait de plus en plus capricieuse avec son bouton R. Oh, il fonctionne, pas de soucis de ce côté ... mais il n'est plus très fiable. Il peut être nécessaire de pas mal le titiller pour déclencher quelque-chose, et quand il se décide, il n'est pas rare d'obtenir des "rebonds" du genre "on/off/on/off" en une seule pression du doigt.

Pressing Start+R+A or Start+R+R in SEDS lets you chose between "Save" or "Save As", changing the way a back-up copy of your file is created. When your 'R' button may automatically read as "R+R+R" for a single press, it quickly becomes unmanageable to have coherent file history. So I finally took the time to add some LOAD and SAVE clickable buttons (plus a tool option to invoke cursor mode in SEDS from the stylus) to compensate hardware deficiences of the DS.

Dans la mesure où ce bouton contrôle la "sauvegarde" dans SEDS et AnimEDS, c'est plutôt génant. A plusieurs reprises, j'ai du re-transférer d'anciennes versions de mes livres pendant que j'en faisais la mise à jour pour corriger une réécriture intempestive alors que je cherchais juste à activer le mode curseur (lui aussi déclenché par R). Mais voici donc une mise à jour de mes outils qui offrent des boutons cliquables (au stylet, donc) pour compenser ce genre de problème. A noter que le bon fonctionnement du bouton L, lui, reste incorrigiblement critique.