owlboy: monkey feedbacks

J'étais arrive au continent volant, convaincu qu'avoir pris conscience que je jouais à un shoot-em-up allait enfin rendre le jeu plus facile à aborder. Malheureusement, ça n'a pas suffi. Je me débats avec le tir explosif du personnage secondaire, je peine contre des mouches carnivores invisibles pendant des heures pour finalement découvrir dans un let's play (après avoir laborieusement passé la zone) qu'en réalité elles sont juste déclenchées par un timer quand on reste trop dans le noir, et qu'il faut trouver d'autres torches pour les tenir à l'écart, et non essayer de les vaincre.

Je ne peux pas m'empêcher de penser que quelque-chose lié au temps devrait clairement indiqué comme tel au joueur. Ok, l'idée des mouches carnivores est merveilleusement intégré à l'histoire, mais rien ne les lie au temps, au fait d'être dans l'ombre, ni même ne nous renseigne sur ce qu'elles sont réellement.

d'autant que juste après ce dialogue sur la peur des mouches, on tombe sur un buisson avec des insectes qui tournent autour et qui se mettent à nous tourner autour. On ne sait pas les toucher, mais si on brûle certaines lianes (le personnage au "briquet" vient de nous dire qu'il ferait de son mieux pour les tenir à l'écart, c'était assez gros comme tutoriel déguisé), elles quittent les lianes pour se réfugier dans le buisson voisin.

Mais non. Ce n'était pas ça.

Le mouches en question sont noires, et invisibles dans le noir. Et je ne suis pas le seul à m'être tout d'un coup dit "eh ? que se passe-t'il ? pourquoi je perds ma vie, tout à coup ?". On aurait pu être dans une impasse, et être forcé d'apprendre. Les mouches auraient pu être visibles si on est mis game-over. Mais en réalité, si on va suffisamment vite, et qu'on va de l'avant, on reste assez proche des lucioles innoffensive jusqu'à ce qu'on atteigne un 'fruit-lumière'. On a donc pu passer et les mouches vont passer au second plan. Le problème se reproduira plus tard dans le niveau, quand les fruits-lumière se feront plus rares. C'est là que j'ai dû faire appel à un wiki pour comprendre de quoi il retournait, à quoi ressemblaient ces "mouches", etc. personnellement.

Je suis tenté de raccrocher ça au fait qu'on est en face d'un jeu indé, avec une équipe trop restreinte pour qu'à un moment quelqu'un de suffisamment influent et avec assez de recul sur le développement ait dit "non, ça ne va pas. Les joueurs ne comprendront pas". Peut-être bien l'origine de ce que Kirby Kid appelait "that indie feel" ...

Tout ça me donne l'impression que la communication des objectifs et des avertissements n'est pas aussi claire qu'elle le pourrait. Et le deuxième boss dans la lave a tendance à me renforcer dans cette idée. Ici, on se fait régulièrement attraper par un des singes et plonger dans la lave, ce qui met fin au combat. 30 à 40 minutes de jeu plus tard, ça n'avait toujours pas changé. Je ne m'attend plus à passer un boss du premier coup dans le jeu: je sais qu'il faudra que je sacrifie d'abord quelques vies pour comprendre ce qu'on me veut.

Ici, il aura fallu une vidéo youtube pour que je réalise qu'il était possible de se libérer de ce genre de prise. Et non, je n'aurais jamais pensé utiliser le bouton "Saut" pour ça! Ni qu'un tel mécanisme puisse être introduit si tard dans le jeu sans un indice sur l'action attendue. D'autres évènements en cours de combat (comme le fait d'être enflammer) sont annotés avec l'action à faire pour se "soigner". Pourquoi pas ici ?

Iconoclasts perdait peut-être parfois un peu en immersion avec ses icônes, mais au moins les intentions des développeurs étaient claires. Ici, on dirait qu'il manque le message "RELOAD" d'un rail shooter.

Et ce genre de problème de communication va se généraliser jusqu'à ce que l'on trouve le troisième personnage et que le jeu s'écarte un peu du fait de tirer sur des cibles. Mais Alphonse et son arme dont on ne voit ni la portée ni la direction de tir va nous faire passer un désagréable milieu de partie...

https://www.spriters-resource.com/fullview/78065/ {alphonse}
https://www.spriters-resource.com/pc_computer/owlboy/sheet/84737/ {monkey}

Charly et le Poisson-Rêve des playmobils

Link's Awakening, c'est peut-être bien mon jeu préféré. C'est en tous cas mon "Zelda" préféré depuis 25 ans et j'y ai rejoué à de nombreuses occasions. Donc oui, évidemment que je me suis chopé une cartouche du jeu dès que possible. Bien entendu, que j'avais l'oeil sur sa date de sortie dès qu'elle a été annoncée. Naturellement, je bidouille nettement moins mes p'tits éditeurs DS le soir.

Ce mois-ci je joue à Link's Awakening dans son incarnation switch... "au pays des Playmobils", comme je dis avec J.L.N et *deline. En mode héroïque (pas de p'tits coeurs à part au village, pas d' petites fées à part dans les fontaines), vu que j'en étais arrivé sur GB à essayer de finir le jeu sans épée L2 et sans boomerang. Mais un Zelda, c'est quand-même plus intéressant quand on doit chercher plus que quand on doit chercher moins.

Et je me suis même fait un 'fork' de la partie où je ne m'autorise les sauvegardes que si j'ai réussi à débloquer un objectif sans perdre de vie.

I'm not 100% sure this is my favourite game ever, but it is clearly my favourite RPG ever. Next month will be #linktober for me. And I'm collecting some screenshots to improve my pyramid level if I can.

I realize with this re-play (and watching kids playing the game) that one of the key strengths of Link's Awakening is how the initial village -- your exploration headquarters for almost the first half of the game -- is a cozy place. There is no time pressure, you can recover health, items, and even money as long as you want. There are people to talk to, ways to help them even without having to leave the village. There are minigames that can dry your money as long as you have some, meaning you can put yourself in an endless loop of lawn-mown-for-money-to-play-games without ever facing any danger.

There is no such "safe spot" in Link to the Past (the screen where your home stands is crippled with shadow soldiers), Occarina of Time (you're almost told you'll never return to Kokiri Village by the time you're out for Hyrule) or Wind Waker (your island is at the edge of the map, and you don't really need to return there unless you need grandma soup). The closest would be Phantom Hourglass, but there the village is also the front door of the Temple of the Ocean King, which isn't quite cozy to think of.

Adventures in LVM

I had issues resizing the / partition of my system some time before creating the last VM I was using at work, so apparently I though "oh yeah, I'll enable Linear Volume Management (or whatever LVM stands for) this time".

Everything worked fine as long as I was running on that VM. And I don't remember having to grow the partition (I'm unsure the disk backing it would have allowed it to grow a lot, anyway).

But then I had to make the same virtual disk working on a new root filesystem, likely because the new VM has UEFI boot enabled by default and the previous disk image was for MBR-boot only... https://www.svennd.be/mount-unknown-filesystem-type-lvm2_member/ helped a lot to recover stuff.

Do you think that would make it.

No. Of course not. I managed to screw my enlightenment window manager configuration, and end up with nothing but black-on-black windows (with nice blue shadows when I switch focus, though). Since all the enlightenment configuration files are "encrypted" now, I unfortunately can't vim me out of this mess, so I thought "never mind: I'll mount a second instance of that hard disk and recover files from there ... haha. Nice try.

Of course, the two disks have the same LVM identifier, so none of lvscan and friends allow to use both at the same time >_<

some shutdowns later, I copied back my configuration and have a working window manager again. pfew.

Next time, I'll remember to archive contents of ~/.e/ before feeling adventurous... enlightenment nicely makes up to 10 backups of your files, but when one more is lost about everytime you start a new session, apparently. And one quickly makes lots of sessions while trying to fix such issues :-/

owlboy: drôles de contrôles.

Les graphismes d'Owlboy sont superbes, les musiques plantent une ambiance idéale et j'adore l'histoire. Pourtant, pendant tout le début de l'été, je n'ai pas ressenti cet effet d'appel à jouer que j'ai pu avoir avec hob ni meme flinthook. La progression est laborieuse, j'ai la sensation d'être brouillon et de ne pas bien comprendre ce que le jeu attend de moi.

J'ai commencé par penser qu'il s'agissait d'un problème d'interface: si seulement je pouvais
forcer le jeu à tirer quand je pousse sur Y plutôt que de réclammer un ZR, tout irait beaucoup mieux, non ? Ça me remettrait dans une configuration identique à celle d'Iconoclast et de Flinthook auxquels j'étais aussi en train de jouer. Les choses deviendraient enfin naturelles. D'autant qu'en y regardant de plus près, c'est aussi le mode de fonctionnement que j'ai utilisé sur Super Mario World et Donkey Kong Country.

Puis je me suis rendu compte que ce serait incompatible avec le système de visée du jeu et j'ai commencé à prendre conscience de tous les raccourcis prévus dans les actions du joueur. J'ai alors commencé à reconsidérer le jeu, non plus comme un jeu de plate-fomes où on sait voler, mais comme un shoot-em-up avec des phases au sol, et à laisser le jeu en mode "tir automatique" par moment pour me concentrer sur mes mouvements d'esquive.

Et des "raccourcis", il y en a des fameux. Voyez, en bleu la séquence d'actions que j'effectuais jusqu'à la fin du deuxième "donjon" pour pouvoir tirer: d'abord commencer à voler puis invoquer mon partenaire, et enfin, viser et tirer. Il y avait aussi une autre possibilité consistant à faire apparaître d'abord le partenaire, puis à le 'ramasser'.

Tout celà est rendu encore plus compliqué par le fait que certaines pressions de touches peuvent nous faire revenir en arrière, et que lorsqu'il est au sol, il faut être assez près de son partenaire pour pouvoir le ramasser. En clair, dès que le boss va venir vous mettre la pression, c'est fini. D'autant que la plupart des coups qu'on encaisse projettent notre personnage et son partenaire dans des directions différentes. Mais heureusement, si on se concentre sur le côté "shoot-em-up" du jeu, bin le réflexe quand on s'est fait toucher n'est plus de sauter mais bien de se remettre à tirer. Et là, bonne nouvelle: utiliser le bouton de tir nous "téléporte" instantanément dans l'état "en train de voler avec son partenaire accrocher qui se met à tirer dans la direction indiquée par le 2eme stick. On peut dès lors oublier toute la partie bleue dans les phases d'action et se concentrer sur l'essentiel: un stick pour bouger, un stick pour viser, une gâchette pour changer d'arme et une gâchette pour tirer.

Je pensais plus ou moins jusque là que les noms "plate-forme", "beat-em-all" et "shoot-em-up" n'avaient d'utilité que dans un catalogue ou un magasin, mais après plus de 20 ans de pratique du jeu vidéo, on dirait que ça va plus loin. Le fait de penser "c'est un shoot-em-up" semble activer un autre ensemble de réflexes, y compris un mode de vision plus global pour surveiller les trajectoires de plusieurs projectiles à la fois.

Et pourtant, pendant une bonne partie du jeu (et en particulier presque tout ce deuxième donjon), le fait de tirer est beacoup moins impliqué: on va essentiellement résoudre des énigmes en transportant et lançant des objets (ennemis-bombes, nuages ou cruches d'eau pour éteindre les monstres de feu, etc). De quoi endormir le peu de réflexes qu'on aurait pu se constituer dans les phases d'action du premier donjon.

Bref, Owlboy a fait le pari d'un jeu multi-facette, qui alterne des phases de shoot-em-up, des phases de puzzle "à la zelda" et des phases (rares) de réel platforming ("Attention: ces gnomes ont une ouïe super-fine. Ils t'entendraient battre des ailes à 100 mètres. Quoi qu'il arrive, ne t'envole surtout pas!"). Une richesse indéniable, mais pas toujours claire à appréhender pour le joueur. Et qui va vous demander -- tout comme le personnage doit le faire dans le jeu -- d'abandonner derrière vous vos a priori si vous voulez continuer à aller de l'Avent.

owlboy

I should have made a "game to watch" post about DPad Studio's "Owlboy" game since I saw the first screenshots in my Google Reader feeds (possibly as early as 2008?), and if I had made another "show me what you (wanna) play, I'll tell you who you are" post, I would have been featured just like Iconoclast and Ori. I haven't said much about them yet mostly because I had no hope to see those games coming to either Linux or NDS. It all changed with their announcement on the Nintendo Switch.

Owlboy fait partie de ces jeux que je surveille "en secret" depuis le début de leur développement. Rétrospectivement, j'aurais aimé en avoir un post déjà écrit depuis 2008 ou 2011 qui explique ce qui m'attire dans le jeu, comme ça j'aurais pu commencer à poster des "critical owls" dès que j'ai commencé à jouer ... Mais voilà. Je devais avoir la tête ailleurs et me dire qu'il était peu probable que j'arrive à le faire tourner sur mes machine jusqu'à ce que je passe en mode #sijavaisuneswitch.

Voilà donc un jeu au pixel art de Snake Pixel époustouflant, d'un niveau capable de se mesurer à celui de Henk Nieborg dans Shantae. Et évidemment, c'est le premier point qui m'avais conquis. En plus de ça, il était présenté au départ comme un jeu de plate-forme (je reviendrai là-dessus), mon style de prédilection, garanti 100% 2D. Et si côté blog je suis resté assez discret, en revanche, j'ai commencé à ajouter des images de Snake à ma collection "pixelstudy" depuis 2015.

Maybe you wonder then why I didn't start playing it straight as I got the Switch ? Well for the exact same reason I'm not playing Link's Awakening remake right now: I wanted to find a physical support for it. I don't want it to be in competition with other newer titles in a too-small, un-expandable storage.

J'ai finalement mis la main par pure chance sur une copie physique dans un magasin ayant pignon sur rue(lle) et même si j'ai eu beaucoup de mal avec son gameplay au début, j'ai continué à y jouer par-ci par-là tout l'été parce que moins éprouvant pour les pouces, et aussi parce que c'était devenu l'histoire-de-papa pour J.L.N, pendant que sa soeur lisait seule le 4eme tome de Harry Potter.

I've been using the 'shoot picture while playing" a **lot** with this game, and I barely started pixel-studying all the things I gathered. I've been into places I expected and into many more places I wasn't expecting at all.

And the story ... boys, the story is just gorgeous. It's not just a rescue-your-pals theme. From act 1, there is a strong artistic sense in how the game play make you feel how the character feels miserable and struggles to find his place in the society although he's not as actively rejected as in Secret of Mana. I love how DPAD studio speaks about the dormant sense of doom and lack of proper reaction from people in charge of our destinies, the underlying risks of pushing science to the limits. If there was a "Meaningful Theme" award for a video game, Owlboy (much like Iconoclasts) truly deserves to be nominated.

Et franchement, autant au départ c'est pour le côté léger de son graphisme que j'avais laissé voir mon fiston que je commençais à y jouer, autant je trouve le jeu riche en enseignements. Sentiment de solitude, déception d'avoir déçu, difficulté et importance de l'amitié, de la franchise. Responsabilité quand à l'emploi des avancées scientifiques. Et il ne s'agit pas ici de simples effets dans les dialogues. C'est vraiment l'intrigue principale, c'est renforcé par le gameplay.

A un moment j'ai été tenté de laisser la console de côté sur l'air de "bah, pourquoi est-ce que je me fatiguerais à essayer d'atteindre la 3eme relique avant les pirates ? de toutes façons le script va faire en sorte qu'ils arrivent les premiers quoi que je fasse: c'est perdu d'avance". Puis j'ai pris un pas de recul, et j'ai réalisé que c'était exactement le genre de réaction que le personnage était succeptible d'avoir, puisque quoi qu'il fasse, on trouve toujours qu'il a fait les choses de travers et que c'est de sa faute si tout va mal.

Sloppy Mouse vs. Windows 10

Huuuge thanks to winaero blog author! I can now have the desired mouse behaviour on my freshly-installed Windows 10!

Having the focus follow the mouse rather than having to click to focus windows is already hidden enough in Windows ('Make the mouse easier to use' in the 'old Control Panel), but not raising windows when you hover them while still giving them the focus is completely arcane wizardregistry: we'll have to locate UserPreferencesMask under  HKEY_CURRENT_USER\Control Panel\Desktop, and then clear bit 0x40 in the first bytes of that binary blob.

Miles away from the convenience and flexibility of enlightenment (see picture), but at least it exists now.

I cannot blame my colleagues for finding the resulting behaviour weird. But it's definitely more comfortable for me.

rongtudju! 'make the mouse easier' is under 'ease of use' only, and won't show up if you search 'mouse' over the whole control panel.
rongtudjuu! bit 0x40 is of course set only when you turn on ease-of-use. If you couldn't perform step 1, step 2 is pointless.
rongtudjuuu! the first part takes effect immediately. The second part will require a logoff/logon cycle at least.

 - - -

That was for the nice part. Unfortunately, despite they have had 20 years to improve their operating system, they still manage to suck. Sometimes for trivial things, sometimes for much more important things.
- How do I customize colors in Windows 10 ? You cannot. You may switch between white-on-black or black-or-white. And that's it. You're uncomfortable with large, white areas because you're an IT professional and would prefer black-on-lightgrey instead ? too bad. You could use some tints on the idle-window-bars because white title bars over white windows backgrounds just feels like hide-and-seek ? too bad.
- You would like to keep using your previous virtualization solution rather than going for an unknown Hyper-V service ? Good luck. If you remember trying to install another browser than Internet Explorer at the edge of the millenium, welcome back. In case you wonder why I'm unhappy with hyper-v,
  - it has no video card / audio card support : everything will go through the Remote Desktop Protocol
  - it sucks dealing with SHIFT+< or ALTGR+$ to produce symbols we use a lot in programming
  - it steals some key combos like CTRL+ALT+UP which I've been using for ages to control my window manager.

Even the 'windows menu' is trying to drive me mad. Hit the windows-key then type a word and you'll be allowed to search for that word in all the programs / configuration items / whatever. That part is good. Click the icon and there's a random (?) chance that typing will have no effect. I mean not at all. Even hitting the ESC key no longer closes the menu!

More substantially, that O.S. is still unable to write a new file when a process is using it, of course.

Edit: hopefully,  following https://ugetfix.com/ask/how-to-disable-hyper-v-in-windows-10/ + https://github.com/kubernetes/minikube/issues/4587 (now that my PC has a repaired .Net 3.5 framework) let me run a virtualbox VM again. Hope I'll get rid of those hyper-v horrors ASAP.

ImportsWindow::render()

Bion, la nouvelle garde-robe est installée ... j'ai eu un peu de temps pour regarder comment m'y prendre pour avoir les images des différents personnages du jeu sous le contrôle de la nouvelle "ImportsWindow" et en tracer les grandes lignes dans le code
[done] utiliser les ImportBlocks pour choisir quel état afficher où
[done] mettre en place une matrice de scaling pour les éléments secondaires d'une ligne 'import'
[don't] sauver les noms ? 

Je vous en raconterais bien plus, mais je suis à la recherche du truc électrique responsable des coupures de courant à répétition dans la maison ...

272 sprite pixels / line.

Si faire une image sur DS c'est un peu comme monter une bibliothèque-étagère contre un mur, alors faire une image sur Super Nintendo, c'est pareil. Sauf que le toit est en pente, qu'il y a un conduit de cheminée qui dépasse, des poutres de toiture apparentes et une tablette d'appui de fenêtre dans le chemin.

Bref, il y a des contraintes à gogo et il faut tenir compte de toutes ces contraintes-là en même temps. Une qui m'a particulièrement perturbé, c'est la limite à 34x8 pixels de sprites par ligne horizontale en plus de la contrainte d'un maximum de 32 sprites par ligne (sur un total de 128 sprites, quand-même. ouf.)

En clair, la console a beau être capable de faire le rendu d'un sprite de 16x16 ou 32x32 pixels d'un coup, ça ne lui donne pas plus la possibilité d'utiliser les sprites pour faire une ligne de vagues couvrant tout l'écran (256 pixels) avec 8 sprites de 32x32. Enfin, si, mais vous n'aurez plus droit qu'à deux personnages sur la même ligne, et pas 24 autres sprites.

Je me suis donc mis à essayer de comprendre comment la structure du chip graphique de la Super Nintendo pouvait bien expliquer ça. L'idée de base, c'est que la console n'a qu'une bande passante limitée à sa mémoire graphique, tout juste suffisante pour aller chercher assez d'informations pour construire une ligne d'image sur le temps qu'une ligne de graphisme est tracée à l'écran par le canon à électrons. J'avais déjà appris que c'était vrai pour les décors -- c'est ce qui explique qu'on doive descendre à 4 couleurs par plans si on veut ajouter plus de plans -- reste à comprendre ce que ça implique pour les sprites.

Nintendo DS and Super Nintendo graphic chips are quite similar in the way they build images. Multiple layers of tiled background plus independently-positioned sprites. But the SNES comes with way more constraints than the DS, and I don't mean resolution or colour count constraint. I mean the 'sprites per scan line' constraint and the 'sprite tiles per scan line' constraint. The NES had only one width for sprite: 8 pixels (one tile). SNES introduced the ability to use 16x16 and even 32x32 pixels sprites but there was still some part of the hardware that could only prefetch a fixed number of sprite tiles per line to do its job.

See, for every pixel on-screen, the graphic chip will have to decide whether one of the sprite's graphics should be shown, or whether background pixel should show through. But the graphics chip has limited bandwidth to the video memory, and most of the time, it uses it nearly to its maximum. That's why we have to drop colours per pixel if we want more background planes, for instance.

Pour chaque pixel que le contrôleur du signal d'écran produit, il va falloir tester les sprites actifs et pour certains (peut-être chacun) d'entre-eux, il faudra regarder si le pixel correspondant est transparent ou opaque. Le premier pixel opaque dans l'ordre de priorité défini par le hardware gagne le match et les autres ne seront pas pris en compte. Ce genre de chose peut être réalisée efficacement avec un bus à collecteur ouvert et un circuit de contrôle des sorties de chaque unité "pixel pour le sprite S" dépendant du résultat des circuits précédents. Mais ça suppose qu'on ait, pendant toute cette phase de génération d'image, accès à l'ensemble des pixels de tous les sprites pour la ligne en cours.

La bande passante de la mémoire n'est pas suffisante pour aller regarder chacune de ces valeurs à chaque pixel, il faut donc supposer qu'il y a à l'intérieur du chip graphique un cache de 8 pixels de large (d'où le x8) pour chaque comparateur et que ce cache est rempli une et une seule fois lors du traîtement de la ligne.

Il me restait à comprendre comment ce genre de préparation est compatible avec des sprites dont on peut modifier la position en cours d'image. Et là, surprise: selon Upsilandre,

[...] Tu peux pas modifier la [Sprite Attributes Table] pendant l'affichage, ça veut dire pas de multiplexage software possible contrairement à la megadrive.

Le principe des sprites au raster c'est que les 34 patterns sont chargé en amont pendant le Hblank dans des registres internes. Ensuite c'est un jeu de priorité cablé dans le hardware qui va fait que tel pixel de tel registre aura la priorité sur les autres.

En arcade c'est mieux, t'as un (double) line buffer donc ils peuvent charger les pattern pendant toute la durée de la scanline précédente (et pas juste pendant le Hblank) c'est ce qui leur donne ces performances bien supérieur

J'aurais cru que la technique de multiplexage -- classique sur C64 ou NES et possible sur NDS -- était omniprésente sur console, et sur la 16-bit de Nintendo aussi. Visiblement non.

The best re-design I can come from assumes that we have an 8-pixels-wide cache of sprite data for each comparator block we put in the chip. Video memory is still laid out as 'bitplanes' in the SNES and accessed 8-bit at the time from commodity RAM chips. Each unit we read gives us data for 8 pixels and reading more of them gives us more bit-per-pixel. What I couldn't come up with was how to make that work with on-the-fly modifiable sprites table. Chatting with Upsilandre killed that fantasy: unlike the NES, the Mega Drive, the NDS and even the Commodore 64, you cannot change the contents of the 'OAM table' describing sprites while the SuperNES is repainting the screen.

Et pour creuser un peu plus loin, les chiffres sont sur http://folk.uio.no/sigurdkn/snes/timing.txt. C'est un peu difficile d'en tirer un nombre d'instructions possibles par ligne retracée à l'écran, mais les chiffres annoncés me portent à croire que le 65xxx dont la Super NES est équipée garde une architecture interne très proche de celle du 6502, avec un bus unique entre les différentes unités internes et du "microcode" qui s'exécute à la fréquence de la master clock de la clock processeur mais qui peut nécessiter un nombre de cycles d'horloge variable (de 3 à 6) pour exécuter une instruction, ce qui donne entre 200 et 500 50 et 73 instructions par ligne retracée à l'écran.

On comprend mieux du coup les ruses de sioux du style "on ne va pas tester toutes les collisions à chaque images" qui régnaient en maître à l'époque..

Feedback in Iconoclasts

I've been playing a few shooting-based games lately. Iconoclasts, obviously, where you shoot, run, fight bosses, talk to NPCs and solve some puzzles. Flinthook, too, where you shoot, zoom through levels, shoot again, explore, die, repeat in another ship. And Owlboy, too. I'm ashamed I haven't posted anything about that one for so long, as I've been waiting for it since around 2015!

Bon, je ne suis pas grand consommateur de jeux-à-flingues en général, mais cet été, je viens de m'en faire quelques uns. Iconoclasts, bien sûr, qui mélange les traditions des run-and-gun avec ceux des castlevania pour donner une sorte de successeur de Cave Story avec une dimension RPG plus prononcée. Il y a eu ensuite FlintHook, mon premier roguelike qui m'aura bien tenu en haleine avec sa bande son sur-vitaminée. Puis Owlboy, plus zen sur le long terme et moins succeptible de m'envoyer à la pharmacie chercher de l'anti-inflamatoire que les deux autres grâce à son auto-fire. Owlboy aux graphismes superbes dont j'aurais dû parler depuis 2015, mais au gameplay améliorable.

And with the mix of all these, I start to better appreciate the way feedback information is conveyed in those games. I'll use Iconoclasts as an example of how it can be made right. Granted, they somewhat overdid it, but they allowed player to immediately know whether they picked the right action and to reduce the feeling of the game being unfair to them.


There are 3 main weapons in Iconoclasts plus a few alternate ways of attacking monsters. And frequently some monsters are vulnerable to some weapons and shielded against others. The feedback here is pretty simple: a small red skull moving away from the monster denotes a successful hit while a blueish cross indicates that the monster blocked our attack.

Ce mélange me permet de mieux apprécier les choix de certains jeux: parfois j'aimerais que l'un se comporte plus comme l'autre pour tel ou tel aspect. Et en particulier les choix de feeback visuel dans Iconoclasts qui me semblaient discutables montrent toute leur force de design tandis que je me casse les dents sur les ennemis de Owlboy.
Vous voyez, les explosions des armes de Iconoclasts sont assez impressionnantes. Peut-être à l'excès. Et elles pètent tout pareil que votre tir fasse mouche où qu'il ait été dévié par les défenses de votre cible. Heureusement, Konjak nous a prévu un petit symbole discret mais efficace qui évite qu'on ait l'impression que le jeu était vraiment trop injuste. Une petite croix bleue en cas d'échec, une petite tête de mort si on a "blessé" notre adversaire. On peut donc rapidement changer d'arme si on se rend compte que celle qu'on utilise n'est pas appropriée.

Cette convention est appliquée à l'ensemble du jeu, du plus petit blob aux boss les plus gros. D'une certaine façon, c'est une version plus rapide à traîter (parce que sans lecture) des chiffres et des statuts du genre "manqué" ou "blocage". Ça s'intègre mieux dans l'univers du jeu, aussi.

This convention is applied game-wide, from the smallest critter to final bosses, and they work even though most our shots create pretty huge explosions. To some extent, this work a bit the same way than the "blocked", "hit", "severe hit", "missed" etc. statuses and damage numbers  that got shown in action-RPG games, but more integrated into the game's universe by not requiring reading.

The last sort of such feedback is how some attacked are telegraphed to the player, namely those that must require a parry with the wrench. They are identified with a big green circle and small icons depicting rotating wrenches just before the shot. Again, it is applied game-wide, letting the player quickly react rather than requiring fail-and-retry learning with every new monster we encounter.

I'm not completely fan of that one, though. Although I agree with the idea, it is too obvious, and poorly integrated with the game's universe.

Par contre, il y a un type de signal qui ne me convainc pas. Ce style de cercle vert accompagné de petites icônes représentant une clé à molette qui tourne indique que l'ennemi correspondant est en train de préparer une attaque qui pourra être parée en faisant tourner notre clé à molette (normalement utilisée essentiellement pour activer des portes, etc.) ça m'a sauvé la vie dans plusieurs combats et c'est impossible à louper, mais on a un peu l'impression d'être dans un logiciel ludo-éducatif tellement c'est "Captain Obvious". C'est mieux que pas de feedback, mais tout juste.

Super Bilou ?

Because yeah, I can't help: the SuperNES draws me like a magnet. No matter how many times I refrain myself from looking deeper into it, I keep wondering how school rush would feel on the 16-bit queen.

But there is no easy answer. The SNES means only 128 colours for all 3 tiled layers. It means that either the ink or the owl must be patched to work with only 4 colours per tile. And it most likely mean that the twin playground layers of School Rush levels must be merged into a single one, with sprites automatically used where Bilou must enter objects like big binders.

Parce que oui, il n'y a rien à faire: la Super Nintendo exerce un magnétisme sur moi, et quelque soit le nombre de fois que j'aie décidé de ne pas m'attarder dessus, je ne peux pas m'empêcher de recommencer à me demander comment Bilou tournerait dessus. Après tout, le jeu a été conçu à une époque où les 16-bits régnaient en maîtres, et faire tourner le jeu sur une vraie machine 16-bit, ce serait la consécration. Et la Super Nintendo est à mon avis la seule machine grand-public qui serait capable de faire tourner un portage correct du jeu. La Mega-Drive et l'Amiga manquent tous les deux de couleurs ... puis je me vois assez mal demander à mon frangin de travailler sur une bande-son Mega Drive, même si l'assembleur 68000 est définitivement plus sexy que le 6502+ de la SNES.

Mais tourner sur SNES, ça veut dire tenir sur 128 couleurs pour l'ensemble des décors, retravailler l'encre ou le hibou du décor parallaxe pour qu'il ne prenne que 4 couleurs par tile, et autres contraintes de ce genre. Et ça veut dire aussi que je dois fusionner les deux couches de tiles en une seule, parce qu'il n'y aura pas assez de plans sans ça. J'ai bien tenté de faire l'encre avec des sprites ou une tranche de hibou en sprites pendant qu'on bascule un des décors du hibou vers l'encre, mais les ressources de la console en terme de sprites sont trop limitées pour ça. Ce n'est pas pour rien si les vagues des niveaux d'eau dans Sonic montrent un clignotement pair/impair ... mais je ne peux pas faire ça si je veux que l'encre ait l'air opaque.

But even with all those limitations, I feel like it would be the only mass-marketed 16-bit  that could host ports of the game. Both Mega-Drive and Amiga lack colours , and I don't feel like asking my bro to give Sega FM chip a try, even though 68000 assembly has more hex appeal than SNES 6502+ instruction set.

I tried other approaches, like using a row of sprites for the owl statue if the ink approaches enough, since there isn't enough sprite resources to implement ink waves as sprites as on the DS (more on that in a later post). But I had to come to the conclusion that merging the two layers into one is the only practical thing to do. So the next question is: how much overlap between layers is there in the levels of School Rush?

Voyons donc cette histoire de fusion. Ayant un niveau modeste en pixel art et un moteur de jeu basé sur un contenu quasi-statique de la mémoire vidéo, j'avais essayé au maximum d'éviter dans School Rush d'introduire des tiles qui seraient une combinaison de deux objets (un classeur à l'avant-plan et un morceau de bois à l'arrière plan). Au lieu de ça, j'utilisais deux plans verouillés ensembles tout en mettant les graphismes sur l'un ou l'autre plan selon les besoin. Avec le GPU sous stéroïdes de la DS (si, si), il me restait encore de quoi faire tout le reste. Ramener les deux plans sur un seul est possible parce que la SNES permet pour chaque tile dans la map de fixer sa priorité par rapport aux sprites. Reste à trouver des solutions pour afficher les superpositions. Du coup y en a-t-il beaucoup dans School Rush, et où sont-elles ?

I have fairly simple tilesets in School Rush, and used overlap to make object-bridging tiles. Merging means that these tiles now need new slots in the tileset. How many of these are there ? Can they fit the remaining space in the tileset or do I need to use virtual tilesets as I plan to implement in later versions of libgeds.

In most of the game, there is only a few tiles of overlap, in corners, often with green books or binders. These could either be done with overlay sprites or merged tiles. No problemo.

Les plus fréquentes proviennent des livres et des classeurs verts. Je dis 'fréquents', mais il n'y en a pas tant que ça par écran. Ce ne serait probablement pas pratique de construire une palette qui permette de combiner 'verts et mauves', une autre avec 'verts et bruns', etc. donc je m'orienterais probablement vers une implémentation avec des petits sprites 8x8 par-dessus le graphisme de la "couche" la plus distante de la version DS. Pas de soucis en vue ici.

Il y a ensuite une série de structures où la superposition n'est pas fondamentale pour le gameplay, voire parfois carrément accidentelle. C'est le cas avec la zone encadrée en bleu clair sur l'image ci-contre. Là une simple modification de la map suffira.

Viennent aussi les graphismes qui sont réalisés avec une combinaison de deux tiles plus simples pour des raisons de facilité, comme ce tube qui rentre dans le classeur, mais qui en réalité ne se coude pas et passe simplement par-derrière. Là, on pourra probablement se contenter d'un nouveau jeu de tiles parce que les version "simplifiées" ne sont pas utilisées telles qu'elles dans le niveau.

There are other locations where overlap allows to create sophisticated tiles with simpler ones -- like with the purple areas on the screenshot next. But in the level where I find these, the 'simpler' tiles aren't used anywhere else, so I could just have these in the SuperNES vram and that's it. Then there are locations where the level could be simplified to avoid overlap (like with the cyan area) without altering the layout of the play area.

Then there is the annoying areas. Those where we don't see parallax background layer with some wooden walls. They lead to a significant amount of additional tiles, especially given the complexity of that background (16 unique tiles). There isn't much else in these areas, hopefully. And not so many structure. Stacking sprites should work, but that makes more palettes needed. Alternatively, I would have to simplify the background texture locally and have a copy of those tiles with a simple, but opaque background.

Là où les choses se corsent réellement, c'est pour les "cachettes", ces passages du niveau où on est à l'intérieur d'un banc. Ici, n'importe quel objet qui n'est pas simplement rectangulaire introduit des nouveaux tiles. Et pour corser encore les choses, la texture de "fond de bois" prend facilement 16 tiles. On va avoir des combinaisons dans tous les sens si on n'y prend par garde. On risque de manquer de palettes si on essaie d'utiliser des sprites pour tout ça. Par contre, je pourrais essayer de faire une variante de ces tiles sur un fond opaque mais plus simple, et ajouter une variante des tiles de la texture "bois" qui permet la transition vers les objets. A condition que j'aie assez de place dans mon tileset pour caser tout ça.

Likely, the last, vertical level will be impossible to port to the SuperNES, and it is the reason why I started consuming the last 256 tiles of the 1024-tiles set.

So final move. Let's pick the latest tileset. Let's clear out all the tiles that feature only opaque pixels. Then let's clear those that are mirrors of each others (maybe not that wise, but there weren't so many of them). The result is about half the free room that not implementing the vertical level leaves. I can have two alternate (opaque) backgrounds of these. Or at least, I could if the SNES had 96 or 128KiB of video memory. But it only has 64.


Ce ne sera probablement pas le cas avec la version finale de School Rush et son niveau vertical qui introduisait justement plein de nouveaux tiles-de-raccord, mais si je m'en tiens aux 4 niveaux horizontaux d'origine, il me reste un bon quart (256 tiles) de mémoire disponible. Belote.

Maintenant, voyons un peu quelle quantité de mémoire représentent tous ces tiles qui possèdent des pixels transparents. On est dimanche soir, j'ai la flemme de scripter quelque-chose de pratique. J'y vais à la main comme un bourrin. Verdict: on pourrait faire tenir encore 2 à 3 copies de ces tiles-là dans un tileset de 1024 éléments. Rebelote.

Mais la Super Nintendo n'a que 64KiB de mémoire, à partager entre les graphismes des décors, des sprites et les "maps" (comptez 4KiB pour un écran qui scrolle horizontalement, 2KiB pour un arrière plan qui reboucle), et un tileset complet en 16 couleurs pèse 32KiB. Mon décor de hibou (534 tiles et 10 couleurs) est légèrement au-dessus des 16 KiB. Les techniques de "virtual tilesets" seront donc incontournables.

 NOTE: le côté "ouais, mais non, j'ai pas de SNES ni d'écran pour brancher une SNES dessus, de toutes façons, et les cartouches-linker coûtent bonbon" devrait pouvoir s'incliner devant un appareil comme le BittBoy. à cogiter.