Houba!

Le Marsupilami en jeu vidéo!

Okay, since you don't speak French, I guess I need to introduce the Marsupilami first. It's a fictional animal starring in some of the most popular Belgian comics of the 70s-90s. It is mostly yellow with a very long tail (about 8m for an adult) and the comics show him doing all sort of tricks with it, like lasso foes, punch nasty guys, use it as a spring to bounce higher ... I guess you've got the idea. There are 2 main marsupilamis character, one who has been brought back with heroes and act as a super-smart pet, and a wild one, who staid in the jungle in a fictional South-American country. Both like to play jokes (but aren't complete clowns), both are strong and smart and protect their loved ones. 

Distribué par Microïds, ceux qui avaient publié Nicky Boom (et plein d'autres titres auxquels je n'ai pas joué). Moi, je suis grand fan (exigeant, mais fan quand-même) du Marsu de Franquin et j'ai donc craqué pour ce titre qui pourrait presqu'être catégorisé "Donkey Kong Country Honoris Causa" tant il en reprend les codes: jusqu'aux "tonneaux-propulseurs-volants" (ici incarnés par des toucans), aux fruits piquants géants, les cavernes-défi-cachées et le dash-roulade-qui-permet-donne-un-double-saut. 

Since the 90s, there have been cartoons and video games about the Marsupilami, but usually they made a fool out of him and couldn't capture the essence of the comic character. And since I'm a huge fan of the original design and character, it was a showstopper. But hey! some French publisher added a Marsupilami title from some French studio to the Nintendo Switch store and from the teaser videos, it seems to play like a Donkey Kong Tropical Freeze DLC level. So I've lets-go-purchased it to see what it looked like.

Bref, au niveau gameplay, c'est validé. Pas aussi original que le travail de Apache Software sur Mega-Drive, mais ce n'est pas forcément une mauvaise chose: manette en main, le jeu de 1995 était grandement confus, comme si on avait voulu transposer un Sokoban en jeu de plate-forme en empruntant les morceaux manquants dans Lemmings. Pas top.

Côté esthétique, c'est du grand art! Le must de ce qu'on peut attendre d'un jeu de plate-formes 2D à l'heure actuelle. On a le choix entre trois personnages mais ils se jouent tous de la même façon. Aucun ne ressemble vraiment au Marsu phare de Franquin ni même aux bébés-marsu du tome "Le pollen du Monte Urticando". Il m'a fallu un moment pour m'y faire, mais je crois que le truc, c'est que qu'on joue avec les bébés devenus marsu-ado. Comme Franquin n'en a jamais dessinés (afaik), ça donnait la liberté aux artistes d'Ocellus Studio pour avoir un graphisme moderne, un niveau de détail adapté à la technologie utilisée et une personnalité qui convient à la narration. Bingo.

On a visual standpoint, it is a success. The environments are well-defined, characters are well-animated and their are quite matching the original creation although not looking exactly like the beloved comics. And the developers used a clever trick to get some distance with the comic: you're not playing any of the iconic grown-up marsus, nor any of the cute marsu babies starred in the 4th book. Well, actually, you're playing any of them three, but they're no babies anymore ... yet they aren't grown up yet.  They're at the marsupilami equivalent of "Son, you're getting close to be a man now" age where farmboys usually see their origin and destiny revealed and set up on a quest to save the world.

On a gameplay standpoint, this is close to DKC:TF the same way Shovel Knight is close to Megaman. The core mechanics are identical, there are a few twists here and there to make it feel fresh, although you wouldn't call it "a novel experience". And considering how the previous game from '95 failed at being fun or even entertaining by being so obscure, it is rather a good thing.

Premier élément sur lequel j'aimerais m'attarder: les "champignons" rebondissants, puisque je suis moi-même occupé à faire rebondir une branche. Restez par-dessus ces "champis", et vous rebondissez automatiquement, encore et encore, à la hauteur d'un saut ordinaire (qui n'est pas bien grande pour un marsu, celà dit). Si votre bouton de saut est enfoncé au moment du contact, vous partez pour un maxi-rebond. Le timing n'a pas d'importance. Maintenez le bouton enfoncé pendant 2 minutes et vous ferez des maxi-rebonds pendant 2 minutes.

C'est simple, c'est direct, c'est prévisible. C'est exactement ce qu'il me faut pour un niveau 1. Et c'est un des choix qui font que ce Marsu est plutôt bien adapté aux plus novices qui n'auraient pas réussi à aller plus loin que le monde 2 de Tropical Freeze (je ne parle même pas de Returns). Pas que le jeu soit enfantin (toutes les recettes de Rayman Origins pour adapter la difficulté au joueur sont reprises) mais il ne cherche pas à faire dans la Grande Quête. 3 mondes + 1 monde caché, et voilà.

From a game design perspective, there are two items I want to keep track of. The first is how easy and intuitive the bouncing elements are in the game (compared to that tricky-to-use bouncing branch in my own demo). Just stay on the thing and you'll make small bounces (about the height of a regular jump). Have the jump button held down and you'll make huge bounces. That simple. No need to press it again everytime you touch the bouncy thing (mushrooms ?). No need to time your button presses against the position of your character on the screen. Just. Hold. It. Down.

Autre élément de gameplay qui mérite qu'on s'y arrête, ce sont les anneaux-pour-s'accrocher. Aucune tentative pour habiller l'objet ici: ils sont à peu près aussi discrets que des blocs-question dans le royaume champignon. Ils s'éclairent en vert quand votre marsu est à la bonne distance et une simple pression sur le bouton d'attaque nous y accroche alors quasi-instantanément. On est ensuite tiré jusqu'à l'anneau ou on restera accroché, statiquement jusqu'à l'appui sur le bouton de saut.

Une séparation des rôles (Y=accrocher, B=quitter-et-sauter) qui est vraiment la bienvenue et qui évite les fausses manoeuvres même quand on s'embrouille dans ses boutons: appuyer sur Y à nouveau quand on est déjà accroché n'a ici aucun effet.

The game also provides an interesting answer to "how to HOOK to things". Here, hooks are plainly identifiable as such ... almost as artificial as Super Mario Bros question blocks. It gets a green glow if you're in range to trigger the HOOK mechanics. If you press the attack button, it will almost immediately (less than 50ms) reach for the hook with its tail and will then start zooming towards it along the straight line drawn by the tail. You won't leave the hook by pressing the attack button again: you'll have to use the JUMP button for that. A nice protection against accidentally leaving the hook when there's no ground to catch you.

Should there be multiple hooks in the range, the direction you indicate with the left stick will select which hook is targeted. Only that hook gets the green glow. That works most of the time, but may trap you in some of the latest levels where the hook you're leaving is falling down or about to move into spikes. Because yeah, those flying hooks will come into a good number of variations that I'll have to study later and the same mechanics are also used for the shooting birds that replace DKC barrels.

Dernière petite touche sympa: appuyer sur le bouton d'attaque pendant qu'on marche va déclencher une attaque-roulade (comme dans Donkey) alors que l'utiliser quand on est à l'arrêt déclenche un "coup de poing" avec la queue du marsu terminée par un gros noeud (sa signature dans la BD). pas de risque donc de se mettre à partir en avant avec un dash involontaire, résultat trop fréquent dans la série DKC. Ultime subtilité, mitrailler le bouton d'attaque pendant qu'on marche permet de rester dans un dash infini, qui pourrait se finir mal quand on arrive au bout d'une longue plate-forme avant un passage où il faudra plutôt s'accrocher. Et la subtilité la voilà: dans cette situation, les concepteurs ont presque systématiquement placé une ou deux caisses en bout de course. Le marsu ne peut pas rouler à travers les caisses: il se retrouve stoppé net. Et si le joueur continue son mitraillage malgré tout, marsu -- maintenant à l'arrêt -- donne un bon coup de queue dans les caisses, récupérant leur contenu, mais reste immobile malgré tout.

Final gameplay sweetness: in many places, you're invited to make a long roll by mashing the attack button. since the roll is actually a dash, you might end up doing one press too much and end up past the edge of the current platform. Hopefully, the level designers thought it wouldn't feel fair and typically end such platforms with a crate. The crate might just contain one fruit but most of all the crate cannot be rolled through. And if you happen to hit the attack button again while stopped by the crate, you'll trigger the Marsu's signature move: punch with a tail-knot, crashing the crate and opening the way.

Input Buffering.

Tout est parti d'un tweet de Case Portman, auteur du jeu "Flynn, Son of Crismon" dont je suivais le développement dans lequel il nous expliquait en quoi le "jump buffering" est fondamental dans tout jeu de plate-forme. Un nom un peu barbare pour les francophones qui consiste plus ou moins à faire du voyage temporel avec votre manette de jeu.

Quand le joueur est au sol et qu'il fait sauter son personnage, on s'attend à ce que le saut soit pris en compte à la frame exacte où le bouton est enfoncé. Pas trop difficile. Supposons que le joueur veuille rebondir sur le sol en finissant un saut. Il sera assez fréquent qu'il appuie sur le bouton de saut légèrement avant de toucher véritablement le sol. Son intention est de rebondir. Le code peut faire deux choses: soit ignorer la demande de saut vu qu'on est en l'air, soit effectuer un saut dès que l'on atteint le sol. Et clairement, les jeux qui suivent la première approche sont désagréables pour les joueurs.

In my notebook for 2022-2023, I had a small page about Case Portman's post on Jump Buffering (link recovered, thanks, search Engine :P), where the author of "Flynn, Son of Crismon" explains:

It's a nifty little feature that will add *a lot* more flow to your game. This can also be applied to almost any action! Shooting, melee attacks, dodge rolls, even menu selection.

Don't let the name frighten you: what it truly means is that you're time-traveling with your  DPAD, pretending than your jump button presses did not happen when they did. If time was a photoshop/gimp layer, then jump buffering would be something like "snap to guide". He went on with a detailed and beautiful gif animation showing how to achieve that and make the game more tolerant on the case where player is about to land on ground and press the jump button in one of the last few frames mid-air. Many 8-bit games failed to do so and feel unfair when played.

Dans mon moteur de jeu, tout celà est pris en compte par le contrôleur "dpad". Pour chacun des boutons, ce contrôleur retient si le bouton était déjà enfoncé lors de la frame précédente, et pendant combien de temps encore il doit être considéré enfoncé. La fenêtre de temps autorisée (6 frames, soit 1/10eme de seconde) sera la même pour tous les boutons. Je me suis refait un petit schéma de la manière dont c'était géré parce que je l'avais complètement perdu de vue. "to[i]" sur ce schéma, c'est le timeout associé à un bouton donné.

I realised then that how my engine does this slipped out of my brain: it was about time to document it and blog it. It all happens in the DPAD controller, where a counter will be started if a "new press" is detected and reset if the button is released. The counter is decremented every frame while you're holding the button. But earlier tests in SchoolRush shown that this is not enough. In some part of the character behaviour, we actually *must* indicate directly whether the button is still pressed. Without that, there's no such thing as "keep jumping higher as long as player holds JUMP button" or "keep floating as long as player holds JUMP button". My engine handles that with a bitmask that indicates which button should report "pressed" instead of "held".

Par contre, on peut définir état par état quels sont les boutons pour lesquels on veut un mécanisme du type "enfoncé il y a au plus 1/10eme de seconde" et ceux pour lesquels on veut "maintenu enfoncé depuis aussi longtemps  qu'on veut. 

Quand on définit "MOVE + FOOT" pour l'état "flotter" (dans les airs, façon super-cape de SMW), ça signifie que le DPAD et les boutons de sauts ne passeront jamais par "decrease timeout". l'état "chevauchée d'éponge" évitera quand à lui de faire expirer "MOVE + HANDS". Et pour tous les états où on a rien précisé, c'est le DPAD et la gâchette droite (qui sert de déclencheur pour la course) qui seront maintenus.

But watch the catch: while the controller code defaults to 'held', the script instead indicates which inputs are expected to be "held", and defautls to "press" ... that's why you see 'using dpad(MOVE|FOOT)' for the FLOAT state, where it prevents the press to expire while floating.

Dans le code de Celeste ...

Je m'étais fait une conversion epub du code de Celeste, peu après avoir reçu mon boox, pour étudier un peu tout ça pendant que *deline était à son cours de sport. Il faut bien dire que ce n'était pas simple à suivre, entre les hyper-jump et compagnie. Mais ici, un des développeurs vient de tweeter une série de mini-vidéos pour montrer toutes les ruses de gameplay qui ont été mises en place pour que le gameplay soit satisfaisant.

A few time after I got my first boox, I found the code for the game Celeste by Matt/Maddy Thorson. It seemed appropriate to study it while *deline was having sports in the evening, and it did give me some difficulties with all those hyper-jumps and similar advanced techniques. Especially since I barely started a game of Celeste on my switch and I'm nowhere in mastering those advanced moves. But the developer did tweet a list of 10 tricks they used to make the gameplay more satisfying.

Oh, j'ai une partie en cours sur Switch, aussi ... mais M. Oshiro en furie me mène la vie dure.

• De 1 à 4: on a des techniques équivalentes dans Bilou
• 5 - contourner les coins au lieu de se cogner la tête dessus. Pas encore.
• 6 - s'aligner sur une plate-forme à sens unique quand on passe à travers
• De 7 à 10: différentes manières d'étendre les zones de collisions avec les murs / plate-formes pour compenser des pressions de touches un peu tardives de la part du joueur (un peu comme le vile-coyote-time, mais dans d'autres circonstances - notamment pendant un wall-jump).

edit: ça y est! j'ai passé M. Oshiro!

Tiens, pour la comparaison, on atteint quand-même les 5000 lignes de code pour Player.cs (qui pourrait contenir plus que le code de Madeline, hein)

The tricks are the following (if twitter dies, they are hosted on "Celeste & Forgiveness" with their original animated gifs)

1	coyotte time	You can still jump for a short time after leaving a ledge.	done
2	jump buffering	If you press and hold the jump button a short time before landing, you will jump on the exact frame that you land.	done
3	Halved gravity jump peak	If you hold the jump button, the top of your jump has half gravity applied (gives more time to adjust for landing)	done
4	Jump corner correction	If you bonk your head on a corner, the game tries to wiggle you to the side around it.	todo
5	Dash corner correction	if you dash sideways and clip a corner, it'll pop you up onto the ledge.	todo
6	Dash corner 2	also pop you up if it is a semi-solid platform	todo
7	Lift momentum storage.	Add momentum of upwards-moving platform to regular jump impulse, but allow to use it even a few frames after platform stopped moving upwards.	done
8	coyotte wall-jump	you can wall-jump 0.25*playerwidth away from the actual wall	d.n.a.
9	8 for super-wall-jump		d.n.a.

(the 'done/todo' status indicates whether I have a corresponding solution in Bilou's game engine/state machine)

Ideas for a handwriting recognition on DS

Il y a un moment que je retourne l'idée dans ma tête : un système permettant d'écrire librement (du code, pour l'éditeur de comportements) sur DS. Le système serait basé sur une grille 3x5 visible par l'utilisateur. Parce que les claviers virtuels, c'est pénible et qu'un système qui autorise l'utilisateur à écrire n'importe où et n'importe comment, ça n'aura aucune chance de marcher avec 66MHz


That is another idea that has been laying on paper for a while. I lack text and script editors at the NDS.  I don't want to go for a virtual keyboard, because they are really too slow to work with. I can't afford a complex recognition system, and even Google's handwriting system would suck on code expressions.

But I feel like it would be easy to recognize letters when they have been written on a grid. A bit like if we were painting a low-resolution font.

Every letter drawn corresponds to a 15-bit map that can be quickly tested against a small database of features and suggest letters to pick when the decision is fuzzy.

 Additional features could be the starting and terminating coordinates, as well as the number of strokes.

Cette petite grille fait que chaque lettre tracée correspond à un code sur 16 bits unique. A partir de ce code, on pourrait rapidement identifier un groupe d'entrées dans une petite base de données qui traduit les traîts en lettre (p.ex. à partir de la position du point d'origine et du nombre de traits). Je ne veux pas me limiter aux lettres, évidemment. L'idée est de reconnaître l'ensemble des caractères ASCII pour pouvoir éditer du code n'importe où le plus facilement possible. 

I hope the result will be an interesting compromise between
- early PDA "one-weird-stroke-to-write-them- all" (Palm's Graffiti system)
- sharp Zaurus "Free-letters-one-by-one"
- OCR from scanned text.

I know segmenting is a complex task in letters recognition. With pre-drawn grids, the user is guided to start a new segment or stay in the current one. We can also tell apart uppercase and lowercase Eg. "p", punctuations, etc. locally rather having to rely on some line-level calibration. And we can naturally move to the next space for the next letter.


Avec cette grille, je m'affranchis d'un des problèmes les plus costauds de la reconnaissance de caractères (la segmentation) tout en permettant d'utiliser le plus naturellement possible l'espace disponible (sur Zaurus, on devait presque toujours revenir au même endroit pour tracer la lettre suivante ou le mot suivant). Et c'est toujours plus pratique à apprendre (encore qu'on pourrait essayer d'apprendre de nouvelles écritures à la DS) d'écrire "comme Pype/Zaurus" plutôt que "comme en Grafiti", même si grafiti avait le bon goût de ne demander qu'un trait par caractère.

Granted, the hand script writing I use when I want maximum readability already separates letters a lot and uses only one stroke for most lowercase. Because I reformatted my writing for the Zaurus already. But it's not like I had a huge user base to take into account ^^".

The granularity of the grid should help making tricky characters like braces-versus-digits-versus-C easier to deal with.

School Touch?

My brother comes back again with the idea of School Rush on Android platform. Porting issues set aside, I guess he means "on the bare device", and not assuming one bluetooth dpad and buttons attached, Nintendo-switch-like. That implies converting touch and taps and gestures into valid SNES inputs.

Mon frangin n'en démord pas: la plate-forme qu'il faudrait attaquer pour un portage de School Rush, c'est les smartphones & tablettes. Androïd, donc. Au-delà de l'aspect purement "portage", ce qui va manquer le plus sur Androïd, ce sont bien sûr les boutons et le D-PAD. Je doute qu'il avait en tête qu'on se bricole quelque-chose avec des contrôleurs bluetooth en plus du téléphone lui-même. Bon, la bonne nouvelle c'est que la DS elle-même a un écran tactile. On pourrait donc imaginer faire une version "School Touch" pour essayer le potentiel du jeu avec cette interface-là avant de se lancer dans des longues soirée de méditation sur les interfaces Androïd.

Good news: the DS also has a touchscreen. So as a preliminary test, I could just try to use the touchscreen to see how the game feels. Imho, a specific area to emulate the d-pad on having to hold a finger on the screen as we do for the (A) button would be terrible. No one could complete the game in those conditions. I've tried that with e.g. Sonic 2 back then and it was really degrading the gameplay.

Ce qui est déjà clair, c'est que je ne ferai pas une espèce de pad virtuel à travers l'écran tactile. C'est généralement une catastrophe. Il faudra plutôt que j'aille vers une sorte de mélange entre "platform panic" de Nitrome (glisser à gauche ou à droite pour changer le sens de la course avec Bilou qui continue à courir tout seul) et Phantom Hourglass (tapper un monstre pour utiliser les mains de Bilou)

Ideally, we should be constantly running when playing School Rush. That means in the School Touch game, Bilou should start running forward as soon as we trigger RUN, keep running until we give a contradictory input. Similarly, just tapping Jump should do a max-height jump. modulating dump height on distance would be additional inputs rather than timing on the initial input.

No idea when I would do that,... though.

Là où je sèche plus, c'est pour le saut. Dommage, pour un jeu de plate-forme, j'en conviens. Dans School Rush, on dose son saut par la durée de la pression sur le bouton. Faire pareil sur un écran, c'est risquer d'avoir toujours les doigts dans le chemin quand on veut regarder la suite du niveau. Je partirais plutôt vers un système où on fait de base le saut maximum, que l'on "interrompt" si Bilou arrive plus haut que l'endroit où on a tappé  / l'endroit où est le doigt. Enfin, il faudra trouver quelque-chose pour pouvoir atterrir avec assez de précision sur des plate-formes parfois assez étroites.

I liked the idea of "tap another GOB to trigger the "punch" button: it works for picking up bladors, throwing them on baddies, grabbing spons and punching things.

Sonic 2 for free ?_?

J'avais eu l'occasion de télécharger Sonic 2 pour Androïd, temporairement gratuit, sur la recommandation de mon frère. Une valeur sûre, de 1992. Emerald Hill et ses ponts spiralés ... La Chemical Zone et ses blocs lambinants qu'il faut escalader après avoir dévalé des pipe-line de liquide bleu-louche.
J'essaierais bien d'aller jusqu'à la Mystic Cave voire Oil Ocean, mais pour tout dire, les contrôles sur tablettes sont une catastrophe! Le bouton de saut ne réagit pas systématiquement, ce qui est un comble pour un jeu de plate-forme où les réflexes sont si importants. Ça fonctionne un peu mieux quand on appuie vers la mi-hauteur, mais ça veut dire que presque tout ce qui se trouve devant Sonic devient masqué par ma main >_<

What good is a free copy of Sonic 2 if you can't play it ? And how could play a reflex-based platformer when your hands are hiding half of the play screen ? How could you have proper timing when you can't have your hero reliably jumping on "button" press ? And if trying to move backwards may be ignored because you suddenly move out of the active detection region ?

does it really deserve the 'sonic' tag ?

DpadController::timeout

Back in 2010, I had introduced a tweak to the DPAD reading so that you wouldn't bounce again and again by just holding the JUMP button down. That seemed efficient enough. Whenever a button (DPAD excluded) was pressed, a timer was started, running for 30 frames, and as long as this timer hadn't reached zero, the transitions of your state machine would read the button as "pressed". That allowed players to do special bounces when bopping on applemen wihtout requiring 1/60sec. precision. That's called "input buffering" anywhere else in gamedev documents.

Comparé à un clavier ou à un joystick de PC, la saisie des mouvement du joueur sur le DPAD de la DS est une vraie partie de plaisir. Pensez un peu: un emplacement mémoire qui contient directement l'état de chaque bouton de votre console !
Celà dit, s'en servir pour alimenter la logique d'un jeu de plate-formes comme Bilou demande un tout petit peu de subtilité quand-même. Selon les situations, la question n'est pas uniquement "est-ce que le bouton de saut est enfoncé" mais plutôt "depuis combien de temps le bouton de saut a-t'il été enfoncé ?"

Shortening the "time window" (::delay) to 10 frames actually reduced the maximum height for jumps! After rising for 10 frames, the game logic is indeed notified that the key was released, and switch to "end-of-jump". Annoying. I already had the feeling that the "action" button may need to be held and thus be "timemask-free", but the issue is actually deeper. It means whether you use the timer mechanism or not depends on the state you're currently in.

Eh, c'est que rebondir sur la tête d'une tortue pour aller plus haut, c'est bien rigolo, mais s'il faut enfoncer le bouton précisément dans le 60ème de seconde où la collision a lieu, ça devient franchement trop exigeant. En revanche, voir son personnage faire un deuxième saut spontanément en arrivant au sol, c'est perturbant. J'ai donc depuis un moment déjà un mécanisme qui décompte les "images de jeu" depuis que le bouton (croix directionelle exclue) a été enfoncé, de sorte que la logique du jeu regarde surtout si ce décompte est arrivé ou non à zéro. Mais pour que Bilou puisse s'accrocher aussi longtemps qu'on le veut aux éponges, il faut en plus que je puisse définir, état par état, quel(s) bouton(s) ont le droit à un "décompte infini".

While moving up in a jump, you want to check simply whether the button is held or not, and keep pushing up as long as the button is pressed. When going down, however, the timer mechanism is applied so that you only get your special bounce if you hadn't pressed the button too much in advance. Similarly, the "action" button uses the timer when you're falling down, but as soon as you switch to the "grabbing spongebop" state, it just checks whether you're still holding it down. Same would go for mario-like running, for instance.

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.

no jumping allowed

just a small post to put credit where it is due. A few month ago, we had a post of PadrinatoR on gbadev.org, offering a new way of reading stylus input that would avoid "stylus jumping" (e.g. you draw a continuous line, and what you read has some random stylus presses miles away from the real location).

I wasn't able to completely make use of Padrinator's code (among other things, my way of using stylus input wasn't compatible with his new way of reporting stylus movements), but all together, it worked pretty fine as soon as i disabled a few "extra checks". The basic idea is still that any stylus input that is below a given pressure threshold is ignored.

So thanks for your work, Padri. Without it, i couldn't have half of my pixels half as cute as they deserve to be :P
Petit message de remerciements ... il y a quelques mois, un message de PadrinatoR sur forum.gbadev.org offrait une nouvelle technique pour lire les mouvement du stylet et éviter les "sauts intempestifs" (en gros, si vous traciez une ligne continue, la console 'sentait' des petites pressions un peu partout, même à des kilomètres de la vraie ligne).

Même si je n'ai pas complètement réussi à exploiter toute la puissance du code de Padrinator (entre-autres, il faut changer la manière dont on lit les informations, ce qui n'est pas compatible avec mon programme), l'un dans l'autre, j'ai un résultat tout à fait correct dès que je désactives quelques "tests supplémentaires", l'idée de base étant d'ignorer les pressions trop faibles sur le touchpad.

Merci donc pour ton travail, Padri. Sans lui, je n'aurais pas la moitié de mes pixels à moitié aussi beaux qu'ils ne le méritent :P