Stacking Troubles

Fix a bug, another appear. Does that sound any familiar ? I had to reorganise the "window" that constitute my animation editor, so that I would no longer miss some data while saving my work. Those "windows" are widgets container that you can stack over each other. When the GUI engine needs to deliver an event, it starts trying to give it to the top-level window and digs deeper until one of the window has one widget that can process e.g. the click.

The reorganisation consisted of introducing the ThumbWindow (see snapshot) below the FileWindow, so that one can control the slot where an animation should be saved while he's building new skelettons and making "save animation to slot" a natural operation when you're on the road to save to a file.

at first, it seemed to work fine, unless I realised that a single click on any of the limbs or sprite tables disabled all the actions on the "bottom screen" widget. I had overlooked the fact that two of my widgets on the bottom screen (the tables) were actually not part of the "FileWindow", but something laying on the main (application-wide) MetaWindow (in red), so that they could be shared by both file storage and animation edition activities.
Unfortunately, because MetaWindow is the lowest layer of the software, it were obscured by the screen-wide "SpriteTable" that contains all the thumbs. No way to go through. Of course, this is ridiculous: those thumbs are not on the touch screen so they shouldn't be receiving any stylus-based event ... but well, they are. For some odd (historical?-) reason, the GuiEngine ignores facts as trivial as "the top window is a DownWindow, so any UpWindow in the stack shouldn't receive GUI_CLICKED". Hopefully, it features an "active" flag that windows can set and clear to indicate their will to receive/ignore such events. It's to the application author (me ^^") to ensure Window::release() and Window::restore() update this flag accordingly to the desired effect. ... which is now done.

Now, if you don't mind, I have a staircase to polish.

(-1)/8 = guru meditation error.

Et chroot! J'avais donc commencé à dessiner la tête et le corps d'un Badman avec la version "gamma" de mon sprite editor. J'en étais à une animation (plutôt réussie, à mon sens) de sa cape, l'idée étant d'en faire un perso annimable avec AnimEDS. Plutôt sympa pour commencer mes 2 semaines de congés pendant que ma fée est toujours dans le tome 1 de la Trilogie des Périls (Eddings). Je veux ajuster un poil la vitesse de mon animation et là, bardaf!

GURU MEDITATION ERROR

quelque part, un widget n'a pas été prévu pour recevoir des coordonnées négatives... Il ne devrait en toute logique pas y avoir de coordonnées négatives sur la DS, d'ailleurs. Nulle part. Mais là, pas de chance, ça m'a tout planté avant que je n'aie eu le temps de sauver mes p'tits dessins.
Enfin, j'ai trouvé la cause de l'erreur. Je vais patcher ça fissa. Patché.

Hey there. If you happen to be using the 'latest beta' of my Sprite Editor (that is, SEDSGAMA.nds since I've switched to dkp-r32), be warned: there's a nasty bug in the "animation preview" part that may make you lose your work. I figured out what the problem is and will update that version soon.

Edit: fixed: if you are using sedsgama, launch it near your favourite WiFi access point and press [START] then [SELECT] to download and use the latest version (N.B.: the updated sedsgama.nds will always be downloaded at the root of your media card.

now to the horizontal scrolling ...

Hello, there. If you missed the english translation on my former post, Sonic Camera Management, it's now done. The new scrolling is implemented and works fairly well for the vertical direction. Unfortunately, it doesn't work as well for horizontal scrolling.

The reason is that Bilou is not moving at the speed of 1px/frame but rather 2px every 2 frames, to match the animation speed. Former platformers would typically have running characters instead, since they are more flexible. When running, it's easier to make it so that (animation) frames where a feet is in contact with the ground only last for 1 (screen) frame. Well. Anyway. The result is that right now, the horizontal scrolling is not smooth anymore, but rather "pushed a bit" at every step, then it sits back, then pushed again. Ugly. I need a mixture of the two techniques, which means a bit more code hacking.

Youpie. J'ai donc un chouette scrolling vertical bien plus professionnel. Hélas, trois fois hélas, le scrolling horizontal en a pris pour son grade. Que je m'explique. Bilou se déplace de 2 pixels tous les 1/30eme de secondes alors que le jeu tourne à 60Hz. Il reste donc 2 "coups" de jeu au même endroit bien qu'ayant une vitesse moyenne de 60px/seconde. Le hic, c'est que si j'applique la politique "le personnage pousse l'écran en quittant la zone neutre du scrolling", eh bien, mon scrolling ne bouge plus qu'à 30Hz, 2 pixels à la fois. Et ça, c'est assez moche et nauzéeux. Bref, il faut que je passe à une approche hybride qui combine le nouveau scrolling vertical et l'ancien scrolling horizontal ... soit encore un peu plus de bricolage sur iCamera :P

... and well ... I will need to build a place where I can test things with the full-quality pixel art ... not restricted to that "open-source 8-bit" color reduction thingy :P

Sonic Camera Management

Le suivi de Sonic par la caméra fonctionne donc sur le principe d'une "zone" de focus dans laquelle le centre de Sonic est confiné. Selon qu'il est au sol ou non, la taille de la zone change, mais surtout, dès qu'il en sort, la caméra se déplace d'autant qu'il faut pour y ramener Sonic (avec tout de même une vitesse limite qui permet parfois à Sonic de "larguer" la caméra... et le joueur).

La grande différence avec le code dans Bilou, c'est que jusqu'ici, quand Bilou sortait de la zone de la caméra, j'accélérais le déplacement de la camera, pour ne le décélérer que si Bilou débordait à nouveau de l'autre côté, ce qui amenait des "oscillations" particulièrement gènantes en cas de saut, car l'écran allait continuer à monter de plus en plus vite alors que Bilou commençait déjà à redescendre.

Voyons un peu si ça colle avec mes "désidératas".

A state-dependent "allowed onscreen window" and a speed limit. That's all you need to get sonic-perfect scrolling. That is, the area of the screen where your character is allowed to appear vary depends on whether you're on the ground or on-airborn. I cross-checked with my requirement list for an ideal scrolling, and everything is there (further translation to come soon).

Centré au sol et sur la chute
Presqu'automatique si la zone de tracking est "applatie" à une seule coordonnée lorsque le personnage est au sol. La caméra enchaînera "presqu'immédiatement" pour suivre la chute si le bas de la zone autorisée pendant une chute est très proche de cette position de référence au sol.
My first requirement is that the camera tracks precisely Bilou (vertically) when he's walking so that climbing slopes happens smoothly, but that it starts scrolling down quickly when a fall starts. This achieved by a very narrow Y windown for "on-ground" state, and keeping bottom limits close to each other when falling.

garder un oeil sur ce que l'on évite en sautant
Ce sera le moyen n° 1 de se sortir d'une situation délicate dans un "platformer": sauter par-dessus. Ce mouvement doit pouvoir se faire sans déconcentrer le joueur. On doit pouvoir passer de plate-forme en plate-forme (alignées horizontalement) au-dessus d'une mare de lave sans attraper le tournis. Simple aussi : il faut qu'un saut tienne en entier dans la hauteur de la "zone de non-scrolling" à partir de la position de repos (au sol). Ce n'est qu'en enchaînant les sauts que l'on parvient en haut de l'écran (et donc que l'on active le scrolling), mais dès qu'on retombe d'un de ces sauts, le scrolling cesse de monter jusqu'au saut suivant (objectif #5).
Jumping is the #1 action in a platformer like Bilou (that is, where the hero has no weapon). It must be possible to hop from one platform to the next one without having the scrolling "bounce over and over" as well (which would give the player nausea). That's achieved with a fairly high "top limit" when the player is "on air". Yet if the player is "climbing up", he'll be kept on-screen. always.


Recentrer sans à-coups
De nouveau, ça tient au fait que le scrolling va ajuster la position de la caméra à la position du héros mais avec une vitesse limitée. Quand Bilou arrive au sol, on "rétrécit" à une ligne la zone de tolérance verticale de la caméra. Celle-ci va donc recentrer Bilou, mais en donnant une vitesse verticale maximale relativement basse (de 6px/fr pour Sonic alors que la limite horizontale est de 16px/fr), ce recentrage semble plus naturel.
Now, that's okay to have the scrolling "keeping an eye on the danger from below", but when the action "moves on" on the new platform, it's annoying to press UP or DOWN just to move yourself back in the center of the screen. This can be safely achieved by a narrow "on-ground" Y window, but a slow speed limit on the camera (in my case, "slow" will be 1px/frame).

Chouette. Tout y est. Plus qu'à coder tout ça. GravityController ou WalkingController auront donc la responsabilité de définir la "fenêtre autorisée" et la vitesse maximale, la caméra s'occupe du reste. Andiamo!

DSertyuiop

Parce que je vais re-travailler AnimEDS pour éviter les pertes de données, et que pour ça, je dois utiliser plus largement ABXY et un peu moins L et R, voilà un petit pense-bête de leur emplacement sur desmume-cli... quand on a un clavier AZERTY.

I'd really be happy if people using QWERTY keyboard around the world and developing e.g. games or emulators could take note that other keyboards also exists. Playing Doukutsu, Frogatto or Iconoclasts with W and Z swapped or Q and A swapped is a pain. It's obvious desmume-cli was also targetted at QWERTY given that if I swap things, I fall back to a "logical" layout with A nexto B, X nexto Y and L nexto R. But I have an AZERTY keyboard, hence the cheat sheet.

Sonic Physics Guide

ça faisait un moment que je n'étais plus tombé sur de la lecture chouette comme celle-là. "pentes & blocs à pousser", "collisions", "gestion de la camera", etc. Ca va me faire de la lecture ... Attendez-vous à ce que je vous en dise d'avantage dans les prochains jours.

A neat pick: the Sonic physics Guide starring handling of slopes, curves, camera movement ... knowledge likely generated from years of hacking the good'old Sonic 1 and Sonic 2 roms (for SEGA Genesis). Expect some more detailed posts when I'll be done with my readings. 

TODO: make a small executive summary of it. You may use https://twitter.com/bigevilboss/status/1164309035270754306 as a starting point.

Entering the Shadowlands ...

Episode 4 of Commander Keen is not far from fascinating me. That's likely the game I played the most (excluding beta-tests of PPP Team productions), and likely the game I'd love the most to replay once again. Of course, I'd love that some people would once say that about Bilou adventures as well, and somehow I hope I can learn something from CK4 that would help me reaching that goal.

Si je reprends la carte de Commander Keen 4 et que j'y reporte les différents éléments, on se rend finalement compte qu'il n'y a que 2 niveaux "gratuits" (c.à.d. qui n'apportent rien au niveau de la quête). Autre élément intéressant, dès les 2 premiers niveaux passés, la quasi-totalité du reste du jeu devient immédiatement accessible. Et ces deux premiers niveaux peuvent être franchis d'une traite par le joueur habitué tout en servant d'introduction à la majorité des mécanismes du jeu pour les autres. Une chouette manière d'éviter les "tutoriels".

I think one interesting aspect of CK4 is its overworld. It's mostly a select-your-level menu, and your goal should be to focus on those levels where a Guardian of Wisdom is being held captive. Of course, you don't initially know where they are, so there's some exploration dimension. The overworld is large enough so that you'll rarely see more than 3 levels on screen, but small enough so that you can travel it end-to-end in something a dozen of seconds.
During some spare time, I lost some time plotting which levels contain what "quest items". Guardians to be saved (red wizzrobes), hints from Floating Princess Lindsey that ultimately guide you to the Mighty Foot of Travel which can take you to the Pyramid of the Forbidden -- the otherwise unaccessible level. The major item is the swimming suit, hidden in Miragia, the disappearing desert city, which unlocks access to the three islands. Only the Isle of Tar and Sand Yego are "free fun levels" where you've nothing to earn (quest-speaking), not even a lot of lives or ammunition. They're rather an extra challenge, with fun-but-dangerous elements.

Beside this "swim lock", there's two gate levels (villages) at the start of the game, that can imho be seen as the frontier between basic skill acquisition and real danger. Both can be zoomed-through by the experienced player (just move to the left, hop over some monsters or spikes and you're done). It's interesting to see how the novice player is even -guided- through the sandbox area either by a friendly slope or an open door vs. a set of spikes.

For the novice players, they're a great introduction to the basic mechanics of the games, in a free-exploration fashion. Poles, doors, shots, switches ... everything is there, except key gems. It's interesting to see that a sandbox works as well as a tutorial to that regard. Of course, Commander Keen does not learn new moves during the game (vs. Rayman) and his move set is nuanced (ultra-pogo jump or rope-hop-while-blasting-downwards being examples) rather than complex (vs. Yoshi's Island or Super Princess Peach -- complexity arising from the number of possible actions and negative rewards from doing the wrong action at the wrong time).

Tout qui a joué à un Keen sait qu'un niveau ne peut être visité qu'une seule fois par partie. Sortir d'un niveau sans avoir trouvé le secret qu'il contient, c'est perdre définitivement ce secret jusqu'à ce qu'on recommence le jeu. Evidemment, pour éviter de bloquer le joueur, les mages seront le seul moyen de sortir d'un niveau quand ils s'y trouvent. Ce ne sont donc que les indices de Lindsey et le méga-pied-transporteur de la pyramide de la lune qui pourraient être loupés. Mais le résultat, c'est qu'on aura d'avantage tendance à explorer les moindres recoins du jeu, là où, dans Super Mario 3-*, j'ai davantage tendance à filer vers la sortie dès que les choses se compliquent, entre-autres parce que je sais que je pourrait refaire ce niveau-là plus tard (avec un meilleur power-up ou un peu plus de vies ...). Pourtant c'est bien Keen 4 le "platformer" auquel j'ai le plus joué et celui auquel je serais le plus succeptible de refaire une partie prochainement ^_^

Through the Commander Keen series, levels can be completed only once in a game: you never re-enter a completed level. That means if you complete a level holding a secret without finding it, you won't have the chance to get that secret before you replay the whole game. Imho, this is a key component that puts the player in an explorative mood, while you'll rather play a SuperMario game trying to zoom to the exit as soon as you don't feel easy in the level. The overworld reinforce that explorative mood by being itself open (once you've complete the two gates level at the start, 11/14 remaining levels become immediately accessible).

The overworld of the next opus -- the armaggedon machine -- is much stricter, with virtually every level being a gate to something else. There's very little room for exploration, just sufficient alternate ordering between the tunnels/balls pair to allow the player who faces a challenge beyond his skills at one place to try something else somewhere else. I spot that the two "mission-less" levels of Commander Keen 2 are also the ones where important plot/gameplay hints are unveiled. I'll investigate that further on another time.