La forêt de Castle of Illusion ?

C'est l'histoire d'un screenshot qui arrive juste pendant que je réfléchis à décorer un peu mieux ma "green zone". Il aurait mérité d'être avec d'autres dans la section "études pour dessiner des arbres dans mon jeu" ... ou pas. C'est un screenshot de Castle of Illusion sur MegaDrive, mais pas ce niveau qu'on a tous vu, non le suivant. Celui qu'on coupe au montage. Celui où il va falloir éviter de tomber dans le vide et éviter de se manger les araignées ... 

C'est Régis Monterrin qui avait attiré mon attention dessus avant que je ne note des bizarreries dans les tiles, un peu comme si l'artiste avait fait un chouette truc puis que l'outil pour exporter son travail avait buggé et que personne ne s'en était rendu compte.

Parce que bon, on a tellement de carrés répétés indépendamment de la texture, de transition brutale entre palettes de couleurs aux frontière de la grille-de-tiles que ça en devient presqu'un contre-exemple de pixel-art, où les spécialiste vous donneraient des astuces pour éviter qu'on ne remarque que tout n'est que carrelage aligné sur une grille.

En fait, au fil de l'évolution de ma "green zone", je suis passé par un état un peu de ce genre et j'ai noté que ça me faisait inévitablement penser à ce jeu C64: Forbidden Forest. (et sa suite, sur le screenshot)

Forbidden Forest, c'est le jeu qu'il vaut mieux ne pas regarder de trop près. Alors ok, pour un jeu de l'époque 8 bits, avec un maximum de 256 caractères à l'écran alors qu'il y a place pour plus de 1000 d'entre eux, c'est le truc le plus organique et le plus varié que vous puissiez faire. Là où l'état de l'art, ce sont les écrans interchangeables de "Pitfall" ou la répétitivité de Wonder Boy, ici, on est sur un scrolling continu d'arbres tous différents les uns des autres ... mais aussi sur une omni-présence de l'angle droit.

C'est là qu'est intervenu Aurélien Simon:

Tout ça disparaissait sur un bon vieil écran CRT évidemment. Juger du graphisme de cette époque sur un LCD n'a pas de sens, puisqu'ils étaient créés sur et pour le CRT 

J'avoue que j'avais un peu de mal à y croire. Que le côté "patterns bizarre" du tramage ne pose pas de soucis, oui. Mais ces gros pavés ? ces lignes horizontales et verticales quasi-continues se feraient adoucir rien que par le balayage ?

J'ai cherché un peu sur youtube, des fois que quelqu'un aurait effectivement joué à ce jeu sur tube cathodique ... c'est un des niveaux qu'on avait fait avec J.L.N lors d'un "ludifestival", mais à l'époque, manette en main, on faisait bien sûr beaucoup plus attention aux feuilles-plateformes-géantes qu'au décor. Pas de chance, la seule vidéo que j'aie trouvé, c'est celle ou le joueur a coupé cette séquence au montage.

Mais pendant ce temps-là, Aurélien, lui, avait ressorti son bon vieux Phillips et sa méga-drive et re-joué à Castle of Illusion jusqu'à ce niveau-là pour refaire un screenshot (non?) réaffiché l'image de Régis pour la prendre en photo.

Et là, il faut bien reconnaître qu'à part la ligne horrizontale à hauteur du pied de Mickey, sur la gauche, ça donne plutôt propre. Ni les joueurs ni les testeurs de l'époque n'ont dû y trouver à redire.

Bon, fondamentalement, ça ne change pas grand-chose en ce qui me concerne: puisque mes pixels à moi vont être sur la NintendoDS, je n'aurai pas de flou gaussien pour venir à ma rescousse :P 

Ripple Dot Zero

Whoa! Seems http://Ruffle.rs has been making a ton of progress since I checked it last. I can now start Ripple and play the first level in my browser Not quite ready for prime time yet (performance is very swingy), but what a great leap! -- Tommislav

That was a tweet of the author of Ripple Dot Zero, about a port of his own game, to wich I added That game is impressive. I definitely owe it a blog post. And he added

Thanks. Send me a ping if you want some "behind the scenes" anecdotes if you do

So, to someone who wasn't playing flash games in 2013, I could describe "Ripple.0" as a fast-paced shooting platformer. If you could extract the core DNA of Jazz Jackrabbit and inject it into a penguin with sleek shoes, you wouldn't be far away from Ripple.0. Now, chances are that the modified penguin would escape its pod and start putting a mess in your facility while attempting to rescue as many of its peers as possible.

Of course, because it's a flash game, I can't point you to a playable location, but there are youtube videos to get an idea of how it looked an played. I played the game back then and was baffled by how smoothly it worked and how large the levels were. Until then, flash game had mostly been 'small online arcade' titles, not something with 4-directional scrolling into Sonic-sized maps.

And the post came dormant again since September '25, where I "met" Tommislav again on bsky, with a collection of links to dig. I'll have to accept to post it as is, because real-life is quite demanding these days, and even dropping a few more lines to an ongoing post while things compile haven't occurred in ages ^^". So here they are, in their imperfect, wabi-sabi beauty:

• release in 2013 : blog.pixeltruss.com (from the archive.org)
• salomonsson.se, where a coauthor -- Simon Stålenhag -- is credited and we learn they worked together on the game for 5 years, and can have a peek at some later ludum dare entries
• a third-party recoveryof previous pixeltruss blog
• awesome soundtrack

I want to try your editors so much!

How could I resist to such a quote ?

Adeline Venture (hehe) in Shadow Of The Temple The puzzle platformer I really, really want to make some day.

I want to try your editors so much! But in order to finish, I will have to do it in an engine I already know well. Probably construct3 -- CastPixel

It made me want to pack a set of my dsgametools with contents of Castpixel's mockup pre-digested into a .spr file so that she could directly toy with the level editor ... perhaps also convert the tutogit scripts so that she'd get something playable!

So first thing to know is that SEDS works with 16x16 blocks. There is a perl script that can convert the mock-up into tiles but if used directly, it will be a complete mess as game assets.

1. 
   ensure things are aligned on the 16x16 grid as much as possible. That means the ladder half-way over pillar must be shifted. A few other things needs similar shifting on the mockup.
2. SEDS shows you 64-pixels slices at once. The scripts *can* handle wider pictures, but at the moment, they'll scan e.g. first row of 256x16 pixels and output 4 64x16 rows in the first page, then another 4x64x16 chunk etc. The result is barely usable, again, because many objects bigger than 16x16 will be de-aligned and will need to be re-aligned in the DS editor.
   
3. So instead, you may want to turn the mockup into a 64x* image where things are where you want. Todo: imlib2spr.pl should be able to scan the image in 64px-wide columns itself, so that this step becomes useless and the mockup remains readable.
   
4. The script may remove the background color, but when it does so, it also deletes fully background blocks from the output file. This is nice to avoid redundant data, but again, it screws up alignment on such a mockup. You can scribble something on those blocks or you may turn off the background color by giving another one with --bgcolor=ff00ff. Todo: have the imlib2spr.pl tool inject empty slots on the sprite page when it encounters such full-background blocks, to preserve alignment
5. B u t if I use --bgcolor=some-color, the tool will inject a fully-transparent block as block 0. This is required for proper operation of the game engine and the level editor, but this is useless on the sprite pages. And worse, having block 0 editable led to corrupted files in the past. todo: patch the tool so that the empty block is never used by the generated pages (and never allocated by the editor :P)

With all that taken into account, with a 64x* png file with the content of the mockup aligned on a 16x16 grid as often as possible, conversion is performed with 

SpriteEditor/bin/imlib2spr.pl cast-a-venture2.png venture.spr --nomap --nopack --blocksize=16

And the reverse operation to see how things went is

SpriteEditor/bin/spr2png.pl venture.spr /tmp/venture.png && display /tmp/venture.png

Once that looks fine, copy the venture.spr file on your SD card in the /moving/ directory, make sure you have SpriteEditor for DS at the root of your SD card and launch it.

• once launched, press START to enter the FILE screen
• click the |/_/ browse button to show the contents of /moving/
  
• if venture.spr doesn't show up, hold L trigger and touch the "UV" button on the alphapad to filter the list of files. (holding L lets you enter the second letter of each "button").
• touch the "venture.spr" name to load the file, then press START again to return to the edition grid.

 

back then ... geometry first.

Dumblador revisit post from October 2011 featured not-so-great book covers and "colour balance" post 20 days later featured them almost identical. Then 10 more days and they suddenly look like in School Rush. What happened in between ? pixel art Comment and Critique. "I think you're focusing way too much on using techniques right rather than the objects itself" said Elk, but I couldn't figure out what that meant. "The biggest problem with your art is bad texturing, at this point, I'll return with specific edit and critique." So Helm Returns is what happened. 

En triant un peu, je suis retombé sur un post du forum pixelation qui répond à une question que personne ne se posait. C'est qu'entre le relookage de Dumblador (Oct. 2011) et la recherche des couleurs idéales pour la School Zone (Nov. 2011), on est passé d'un livre pas très convaincant au design actuel utilisé dans School Rush (et qui restera certainement inchangé pour Dreamland). Dans ce post, Helm me donnait une série de conseils en retouchant lui-même le livre que j'avais dessiné.

1. is your book.
2. is the form broken down to its block shape.
3. is geometry, lit from above more or less. If a thing doesn't look good and identifiable on this stage, it won't look much better if you overrender it.
4. here I apply more detailed geometry, I still don't need more colors or fancy tricks, I don't need to fake texture, it's just stuff that the book can support. I also looked at reference here which you should always do, no matter how cartoony what you're trying to draw is. You can spot many differences from 3 to 4 that are related to the reference.
5.After the shapes are good, identifiable and the object has volume, you can go nuts with your new school colors and tints and whatever else, it's all embellishment from here and on.

Le jeu, dans ce cas-là, c'est d'essayer de réappliquer soi-même les conseils qu'on a reçu. A savoir ici "commence par la forme brute, puis fais en sorte que la géométrie soit compréhensible". Ne pas aller au-delà de l'étape 3 si quelque-chose va de travers. Ensuite, rafiner la géométrie mais ne pas texturer, ne pas partir dans des grands effets de couleur. Une excellente leçon, et je vais en avoir bien besoin pour m'attaquer au gros poing pour la pyramide ...

So I went on and try to apply the master's suggestions to get closer to what I wanted:

My attempt at having the right geometry with flat shading and minimal details, my step of putting more detailed geometry and shading before adding any texture, and the final take. The page lines have become too horizontal and dull, retrospectively, but the binding has been used almost as-is in the game.

It was a pleasure to read the master's comment:

Much, much better. Wouldn't surprise me to see this piece in any professional good looking mega drive game of the era.

Approach all real-life related items you render in a similar way, avoid 'noisy textures' for their own sakes and you will level up in your craft."

A lesson to remember as I'll have to work on more pixels for the upcoming game...

PicoDriller fait des vagues.

A côté de ses productions principales (lunark, castaway), Johan Vinet nous a aussi proposé un petit fangame sur pico8 d'un jeu où il faut creuser plus vite que son ombre, sorte de croisement entre Tetris et Boulder Dash.

Je dit "petit", mais la qualité du gameplay et de l'habillage est tout à fait remarquable. C'eut été un homebrew sur NintendoDS, vous pouvez être certains que je serais resté scotché dessus!

Mais ce qui m'a frappé au point de le reprendre dans ma récapitulation de 2023, c'est la vague géante de l'écran titre. Monochrome, avec au plus un creux à l'écran, elle est tout à fait dans les contraintes techniques de la SNES: on coderait alors les vagues en reprogrammant les "window" à grand coup de HDMA, et ça débloquerait le principal frein à une adaptation de SchoolRush sur la reine des 16 bit ... 

PicoDriller is a fun little Pico8 game, somehow a crossing over Tetris and Boulder Dash, and it would definitely deserve a complete review of its art and gameplay mechanics. And unfortunately, I'm not going to do that today. Sorry Johan (he's one of the Pico Driller author, and I've been playing some of his other games). No, today, I'll just discuss the title screen of PicoDriller and its very convincing big waves.  

Alors autant vous dire qu'à plusieurs reprises au cours de 2024, je me suis posé la question "mais comment savoir quelles valeurs donner, ligne par ligne, à Wstart et Wend pour qu'ils définissent la zone sous une sinusoïde ? et comment coder ça efficacement ? Et est-ce que ça tiendrait dans le budget CPU d'une frame SNES ?"

Et pour bien commencer 2025, je me suis dit "eh, mais si on partait du sommet de la vague et qu'on suivait la pente pour élargir la zone noire masquant l'image ?  Après tout, la dérivée de sinus, c'est le cosinus et le cosinus, c'est le sinus déphasé d'un quart de tour !

The core reason is School Rush, of course, and how the Super NES couldn't render enough sprites on a single scanline to depict the raising ink in the game. But if you use demomaker tricks with the 'window' feature of the 16-bit queen (using it as 2 horizontal lines whose position and size can be updated on every scanline), you might get a wave moving as smoothly as that in PicoDriller intro, and that might be stunning enough to excuse the lack of additional colors. 

The idea isn't new: it has been teasing me for the whole 2024 year. So with the winter holidays coming again I noted that "well, I could just start with the top-of-sine, at a given position, and widen it according to the slope of the sine at that point, right ?" and then taking my noteboox and starting to scribble trigonometric functions, taking into account that slope of sine is cos, that cos at some point is sine later on the curve and things alike until I thought I had enough to write down a little loop that *should* give all the items needed to render the sine with "just" a pre-computed look up table for cos values.

I had the surprise to see game developer Jayenkai (Blockman and countless other titles) objecting that it might still be too much maths for the SNES hardware, and pointing me towards an online BASIC interpreter with fair documentation of their graphics commands ... He proposed an alternative where quadratic curves are used to emulate sine, and to be honest, the difference isn't that strong unless you're interested by the slope of your sine when it crosses the "horizon line".

Jayenkai (platdude, blockman et tant d'autres) trouvait que ça faisait trop de calculs pour une snes et m'a aiguillé vers un basic-en-ligne pour m'illustrer une approximation quadratique très 6502 ... 

C'était juste ce qu'il me fallait pour tester rapidement le bidule, donc j'ai recodé la génération de la table de lookup (grandement simplifiée par la présence de cos() et arcsin() dans le basic) puis la 'simple' accélération/décélaration de la descente par accumulation, un accès à la lookup table par ligne

Bin je dois dire que ça donne plutôt bien ^_^

But that evaluator (gotojse) was a breath of fresh air, allowing me to toy around and eventually build up a way to render what *I* had in mind as well, proving the concept. Okay, I don't have it animated like in pico driller, but that might come later on ^_^ 

Bon, ce qui fait tout le sel de l'effet de pico driller, c'est avant tout la variation d'amplitude appliquée sur la sinusoïde, qui va jusqu'à en inverser la polarité. Le fait d'avoir doublé l'effet avec une "ombre" est très stylé, mais incompatible avec le hardware SNES que j'envisage de piloter. 

Il me semble aussi que le "niveau 0" monte et descend légèrement au fil du temps suivant une autre sinusoïde. Ce qui serait stylé, ce serait qu'il suive en réalité une sinusoïde de très basse fréquence (moins de 45° par écran), mais ça nécessiterait pas mal de calculs en plus ... pas sûr que je puisse me le permettre ici ...

 

Chasm pour Super NES ?

Si vous êtes attentifs, vous aurez peut-être remarqué depuis le temps le lien "Lint :: retrobrew" sur la colonne de droite de ce blog. Le site vers lequel il pointe est au point mort depuis une éternité 15 ans. Mais n'allez pas croire que son auteur se soit désintéressé du développement SNES pour autant ... il était juste actif ailleurs.

En fait, en Août dernier, il nous postait un entassement de scène de jeu vidéo, d'un bouquin sur la programmation du 65c816 (son très précieux "Programming the 65816" de Eyes & Litchy) et une version imprimée du document/tutoriel sur les techniques pour implémenter un platformer de Higher Order Fun de Rodrigo Monteiro qui m'avait également été bien utile dans un passé pas si lointain.

Le jeu en question, c'est Chasm, et si j'en ai suivi le développement depuis un moment, Lint_ n'est pas en reste: en avril 2018, il repostait le lien vers le kickstarter en ajoutant qu'il espérait une rétro-adaptation pour Super Nintendo ...

Chasm is coming. One of most wanted game I wanna play. Can't Wait ! I would love to see a #snes demake. -- Lint_

That was the reaction of a former blogger pal: Lint_ when he learnt that the Chasm game was finally out. Personnally, I was still hanging on tigsource and pixelation forums when slym started working on the game back in 2012. In launch interviews, game author James Petruzzi indicated that he wanted player to remember the SNES (or maybe PS1) metroïdvania games while playing Chasm, so I guess people like lint who were doing hobby SNES development by then were hoping to see the game retro-fitted to the old hardware.

 On dirait bien qu'il a fini d'attendre que le "demake" soit fait et qu'il a décidé de prendre les choses en main ;) Chasm étant en principe un jeu avec des niveaux générés à la demande et une navigation non-linéaire inspirée des metroïdvania, la tâche est des plus ambitieuse, mais Lint_ nous rassure: 

Not sure I would implement the procedural level generation if I was about to do a demake of that game. ;) -- Lint_

Parce que son projet de demake, il nous l'a bel et bien démarré. Pendant l'été, il nous a régulièrement posté des décors du jeu convertis pour Super Nintendo en mode "4 couleurs"... avec des changements de couleurs réguliers par ligne à grand coups de HDMA. Sacré coup de chapeau pour une performance qui n'aurait pas démérité sur la démoscène Amiga si on y avait accepté les productions Super NES !

Well, this year Lint had stopped waiting and start working on the demake himself. First we've had background sceneries rendered on SNES hardware, using horizontal retrace to change the 4-color palette on-the-fly and get that stunning colour count, while keeping the 16-color planes for the game proper. Actually, he had stopped waiting since 2022, re-creating key parts of the levels in Tiled, and importing converted tilesets on the SNES to make a running demo ... which seem to rather please the original authors.

A ceux qui seraient tenté d'en rire, je recommande de se replonger d'abord dans les Rétro Game Explained: réduire le nombre de couleurs pour l'arrière plan, ce sera déterminant pour pouvoir dégager assez de parallaxe pour le reste du jeu.

En fait, il avait déjà attaqué son projet en octobre 2022, recréant des morceaux de niveaux à la main (exit la génération aléatoire, donc) dans l'éditeur Tiled pour ensuite les convertir pour son projet Super NES. Je n'ai pas encore vu le personnage bouger par-devant tout ça, mais j'imagine que ça ne va pas tarder ;-) Et ça tourne déjà sacrément bien !

Quant à ses intentions pour la suite, quand on lui demande, Lint_ précise que c'est surtout pour travailler sur son moteur de jeu mais que "qui sait, un jour, peut-être", même si à l'heure actuelle, ce n'est pas réaliste d'envisager un portage complet du jeu. Le moteur n'est pas prévu pour un autre jeu, juste pour le défi de faire un moteur et que c'est Chasm qui l'a inspiré (et alimenté en graphismes somptueux :)

Does that mean there will soon be a SNES cartridge allowing to play a Chasm adventure in hand-drawn levels (as opposed to the procedurally generated original game) ? well, this is not in Lint's plans. When asked, he says that his primary goal is to make a game engine on SNES that would be able to run something like Chasm, and thus why not testing it with chasm contents and see what the demake would look like ... The repository for that project is private, but there's a sibling public repository with library and tools that benefits from the demake effort, from time to time.

Si le travail effectué reste actuellement dans un repo privé, l'une ou l'autre fonctionnalités percolent de temps à autre vers le repo public "cc65-sfclib" de notre antihero national ^_^

 

guest star: François Rimasson

C'est une histoire qui avait commencé mi-février 2021 avec un tweet ... une capture de vidéo pendant un lets-play de Fury of the Furries qui me fait prendre conscience que "#infinitepyramid hints from #furyofthefurries: make sures the spikes stand out." Et là, j'ai un François Rimasson qui répond

• I did all the graphics in 1993

J'enchaîne: You did a wonderful job, then. It has been my first good reference to get into pixelart. Huge thanks!

No kidding! I was already studying it in 2006 before I made my first NDS homebrew. And I was still using it last year.

Je dirais même que si "Badman II" a pu avoir des graphismes entièrement originaux (pour la 1ere fois), c'est grâce à l'étude des palettes de couleurs du désert et de la forêt de Fury. Donc Super-merci ^_^

Je le réaborde quelques semaines plus tard:

Tiens, à propos de Fury of the Furries, il y a ~10 ans, j'avais fait un petit test avec une de tes planches de décor pour illustrer mes outils (homebrew) de création de jeu sur Nintendo DS. Je n'étais pas allé plus loin vu que je n'avais pas les droits dessus.

Là (Mars 2021) mon gamin a l'air d'avoir bien accroché au "let's play" du jeu donc j'envisage de quand-même refaire une conversion aussi du personnage principal pour qu'il puisse s'entrainer le temps que papa ait terminé sa pyramide à lui.

est-ce que j'aurais ton autorisation de rediffuser ces graphismes au format NDS avec mes outils pour un tutoriel, ou est-ce que je garde ça dans le cercle familial ?

Et François de répondre:

• Oui, bien sûr, fais-en ce que tu veux, c'est tellement vieux, et si quelques personnes peuvent s'amuser avec ... je n'ai plus les planches de sprites originales.
• Je suis content que ça te plaise :)

J'ajoute : bin le côté facile avec Fury of the Furries, c'est qu'on a l'ensemble des fichiers .LBM directement dans le jeu. Evidemment, il y a peut-être des planches de pré-production que je n'ai jamais rencontrées.

Et donc on s'y met ... 

6 mars ... "oh birds! @F_Rimasson put so much pixels per spritesheet in Fury of the Furries that it used a buggy part of my conversion scripts that had never been used before ^^"

7 mars ... Hopefully, when you strip out the 'mask' sprites and re-align the sprites that were past the 'checkered' barrier, we're back to an acceptable amount. Actually, it would be perfect to illustrate UsingSprites::granularity.

8 mars ... I was about to suggest that 16-pixels and 4bpp sprites might be an Amiga sprites constraints, but it looks like Amiga sprites were actually 2bpp (https://stashofcode.fr/afficher-sprites-et-bobs-sur-amiga-1/), and likely did not need those mask pictures.

Bon, après ça, j'admets que les interactions ont été plus anecdotiques, avec quand même une phrase qui m'aura inspiré du monster design pour la castle zone:

• Il ne faut pas confondre un fantôme asperger et un spectre autistique

ok, c'est décidé: si je mets des fantômes dans ma zone des châteaux, ce seront des fantômes de légumes. des citrouilles, bien sûr, mais aussi des fantômes asperges qui te crachent de l'ectoplasme dessus.

libntxm by asiekierka or libmx7 by sverx

For years and years, I've been post-poning the time where I could back-port my changes of the sound player library NTXM into the upstream github... And then in December 2023, I note that the library has been revived by one homebrew developer I'm following since March.

I asked whether they would be interested in a pull request for my effects system and she replied

PRs are always welcome! However, someone has already made merged pull requests to support more XM effects, so you might need to review their changes against your own.

Later on mastodon, she added

 I honestly recommend maxmod or libxm7 for gamedev use...

I know that other package released by Sverx quite a while ago. Since the time I was looking for a module player to replace mikmod, Sverx has decided to open-source it. I still have to code-study it. So no code exchange occured and nothing changed in my own dsgametools repository.

Early this month, she announced an interesting news: 

nrio-usb-disk, a tool to use the DS Linker Writer card to connect your Slot-1 cartridges to a PC as USB mass storage. This acts as an open-source replacement for the DS Linker "uDisk" tool, but this one supports any flashcart.

So she can use it to quick-cycle-develop and rebooted Nitro Tracker over USB (instead of uploading over WiFi as I do with runME). The PC is the USB host and the DS is device (via USB controller chip in Slot-2).

Given how fragile NDS development over WiFi has become with WiFi security ever increasing and the NDS hardware remaining unchanged, I might have to consider getting one such device myself and understand how it works for a safer future.

edit: the linker used isn't exactly new.

trivia: did you know Goodboy Galaxy programmer gecko contributed a few fixes to nitroustracker 0.4.9 ?

furblock de montée

La dernière tentative d'améliorer la branche s'est plus ou moins soldée par un échec constructif. Puisque le week-end de montée m'offre un peu de répit, je vais partir sur une idée qui m'est venue en passant en revue les autres jeux avec des éléments de gameplay similaire: commencer par me faire un "bloc-note" à la SMB3, qui se concentre sur le mécanisme, pas sur l'animation. Et une fois que le mécanisme sera validé, je fait la même chose avec un objet invisible.

So trying to combine physical motion and animation for the bouncy branch proved to be a bad idea. Rolling back. I'll keep my satisfying animation and combine it with an invisible block behaving like the "note block" of Super Mario Bros 3 instead. And I'll prepare that with non-invisible block in an easier-to-test environment, that is the pyramid room.

• premier fix: je dois retirer les zik.import de mon script pyrat.cmd: ces commandes sont propres à la "trhee rooms demo" qui pré-charge un module de base (bilou.xm) et runMe ne connaît pas (encore) l'équivalent, même après recompilation du dernier modèle
• deuxième fix: runMe a besoin d'un "../spriteB.spr" explicite pour aller chercher le nouveau fichier (et pas un vieux fichier de SchoolRush dans efs:/moving/spriteB.spr ^^")
• 3eme fix: ma petite anim' faite à la main doit utiliser la SpritePage 8+2 (parce que le fichier bilou.spr préchargé contient 8 pages)

Bon on y est. J'ai un "furblock" dans le niveau-test de la pyramide. Je saute dessus et il s'enfonce bien puis ... il décole vers l'infini et au-delà (ç.à.d  -2147483648). Ah oui, et il n'a encore un tête de fury que sur DS, pas sur l'émulateur. 

J'ai utilisé pour le réaliser un nouveau contrôleur "grille" qui indique si on est repassé au "bloc" suivant, histoire de passer d'un état "repoussé vers le haut" à un état "repoussé vers le bas", et que le bloc finisse par se stabiliser à sa position d'origine. Mais manifestement, ça ne marche pas encore.

There have been a few "setup" issues, leading to a few TODO items to be processed later (this season?) in my notebook, like runMe not supporting the multi-music commands and the lack of "translate to that sprite page" macro for multi-spriteset that leads to annoying magic numbers. But I have to admit that even with that done, the behaviour was fairly surprising. Well, on the DS, the "furblock" did a downwards bump and then skyrocketed to negative numbers: I needed something to fire an event when the original position has been reached. And that thing could be the "grid" controller that was part of my "how to code bosses" arsenal.

But even with that, the resulting behaviour is emerging and perplexing. I guess I haven't found the proper set of rules yet.

Et nous voilà le week-end d'après encore plus au calme, ce qui m'a permis de décortiquer avec InspectorWidget le comportement émergeant (mauve) et de trouver les corrections (bleues) nécessaires pour que ça marche pour de vrai ;)

Special thanks fly to Wye for his SMW-remake-howto video and how it reminded me that the Springy note block exists in first place, and how they were perfect match for the feature I was looking after. ^_^

game design with Super Sunny World

There is a NES game in the making. Yes, a new one. A homebrew, of course. There are quite a few ongoing, actually, but this one features artwork from Kenneth Fejer ! and aims at cloning the gameplay of Super Mario Bros in a different setting. And I must admit I'm loving the simple charm it has, and I've been using Matt's posts on Super Sunny World as a sandbox to toy with game design ideas since March '23 the same way I did with Cyber Shadow a few years ago.

Matt proposes "grow up" power that sits still and "fire" power-up that slides away (like a SMB mushroom). Personally, I feel like both sliding and sitting idle do not fit the power-up personalities. I'd like the "grow-up" flower to have a little motion. To make it easier to grab than Mario's mushroom, it could be floating down towards the player. (post-thought: that might be luring a bit too much into Leilani's Island gameplay ^^")

Also, it feels odd that the pearl slides since it is in a shell but if it was a bare pearl, it would perfectly work to see it rolling away. I'm afraid it moves a bit too fast now and I'm unsure you could catch it unless you realized that you can run, which most young player won't. And even if it is only barely faster than yourself, 

Another follower, XPascalou, points out that In Super Mario Bros, players have to work to get their power-ups. It is not "free". Players have to master "run & jump" to catch the mushroom or the star. The star is even harder to catch because it gives much more power. That's true, but level designers put some surrounding elements so that early mushrooms are redirected towards you. (that would be interesting to study SMB1 maps to see how often that happens and when the games start making you take risks for a mushroom, then compare that with SMB3 and Giana Sisters)

Sometimes, it's just a tiny interaction, like when Matt announce he has adjusted the "hit range" for going down tree trunks, and now allows the player to trigger the transition when "duck sliding" across the top. But by all the hours spent on Super Princess Peach ... Thank you, Matt.

Sometimes, there's more meat, like when Matt wants to introduce a cousin to the snail (his default koopa-like creature). But as much as I love its look, with spikes-like on the shell, it looks more like it's deadly to jump on its head and seeing it shielded against shots was a surprise. (I guess I must unlearn to think of them as fireballs ^^"). It would be nice that the shots would slightly bounce them backwards (unless they entered the "stick to the ground" state after they bounced once, possibly).

Of course, for a programmer, it's always nice to get crusty details about what did not really went right, like how initially, shots would be "swallowed" by blocks 1 tile about the ground. Especially because that feels like something the Giana Sisters would have featured, and thus gives a new light on why there were such weird behaviours in that game.

It's nice to see other platformer authors come up with creative alternatives like waterfalls we can swim in ... rather than artificial ladders or elevator that would have felt out of place in the Sunny's world setting. +1 for using white clouds at the bottom of waterfall only when it is swimmable (it wasn't the case initially, and it will definitely help distinguish interactive and decorative waterfalls). I think mixing swimmable and non-swimmable waterfalls will be very demanding for non-expert players and should only be done if there's plain ground to catch us if we're confused. The way that waterfall is placed in the level perfectly introduce the mechanics in a no-tuto way, too ^_^

And then there are the cases where Matt's post make me think "uh. No. I wouldn't do that in my own game", like with the fishes:

fun twist on the "flying cheep cheeps" 🐡 for my NES game, Super Sunny World 🌞! Instead of just jumping and falling, they land and slide across solid surfaces. Maybe I should replace the fish sprite with a penguin sprite

Maybe they could either slow down and become immobile hazard on the ground or fall back through the ground once they are done bouncing ? I like them being fishes. Sliding penguins only work with slippery ground (and well, so could fishes, if ground is slippery) oh. Or they could slide to a stop, then miserably try to avoid you with ridiculously small jumps. Possibly jumping faster if you approach them.

I could try it, but my plan it to have 3 of those active at the same time, at all times, so my instinct is the keep the movement very linear and consistent, to allow the player to more easily track 3 moving enemies flying around the screen.

Okay, a last one, because that was on my blog-me list for such a long time:

Did you ever notice: In Mario 3, if you hit a block that bounces up, it pushes mario downward faster than if he hits a solid block?

I noticed that while playing "Croc World" demo which was lacking it. It felt cheap. I think Mario's Y speed is reverted while bouncing on an active block. On a solid block, the speed is simply set to 0 so it takes a little time to start falling down. Note on Matt's video how the same question block is active when flashing and just solid once empty. That surely contributes to how the game communicates what is interactive and what isn't.

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.

Tools update

It'd be fun to try your editors! I'd probably do any serious development on a computer, but it's still cool to have an opportunity to try something I would've loved to have as a kid.

(Nova Storm, 7 February 2024)

I told you about Nova's work on NES and SNES already. Earlier this year, she shown interest into NDS homebrew and linkers, so I proposed her to try the dsgametools, and she replied with the heartwarming sentence above. My last tools release dates back from 2021, and while there are not that many things that have changed since, some annoying bugs were fixed nonetheless. So I went for a new package with some README, example files and PERL tools in addition to the .nds files proper. 

Salut les neveux. Si vous voulez tenter de faire des jeux sur Nintendo DS avec mes outils, vous êtes arrivés sur la bonne page. Téléchargez le .zip en utilisant l'image-lien ci-dessus et copiez les fichiers *dlta.nds à la racine de la carte-mémoire de votre DS. Tant que vous y êtes, vous pouvez aussi créer un répertoire nommé "moving" à la racine de la carte mémoire et déposer les fichiers présents dans Demo/efsroot/ du zip. On fait bien attention à ne rien effacer, on éjecte en toute sécurité, on remet tout en place dans la DS et voilà.

Level Editor: 

• fixing bugs with meta buttons;
• add support for special tiles used in conveyer belts and flowing water
• cosmetics: buttons with shadow and show when they are pushed
  

AnimEditor: 

• fixing 'apply to all previous frames' and 'apply to all future frames' buttons.
• only store thumbnails when the animation is used. 

runME:

• cosmetics: buttons with shadow and show when they are pushed 

SEDSdlta est votre éditeur de graphismes. Il permet de définir des palettes de couleurs et des pages de blocs 16x16 ou 32x32 qui seront sauvées dans des fichiers .spr. Ces fichiers peuvent ensuite être ouverts dans l'éditeur d'animations MEDSdlta ou dans l'éditeur de niveau LEDSdlta. Les niveaux créés par LEDSdlta seront sauvés dans des fichiers .map

Deux points communs dans tous ces éditeurs: maintenir L enfoncé pendant qu'on touche un bouton/une grille/une image à l'écran permet de faire une opération différente. Et appuyer sur L+R donne un peu d'aide.

These tools seem like they're very compact and full of features, maybe to the point of feeling a little bit cramped or unintuitive, though it's tricky to do something about that with this sort of screen resolution. I do appreciate the manual that you can access whenever to find out how to do stuff, and I'd rather have all the features than have a simplified tool. I liked the "scan" button in the sprite editor; that's not something I've really seen in pixel art programs.

I can certainly agree with that. It isn't rare that I have to dig my own blog -- or worse, the source code -- of AnimEDS when I want to do something a bit less frequent like copy a frame to a given position, create a new skeletton or adjust hit boxes. I'll have to complete the "L+R to get hint on how to use things" but it's good news that someone noticed it and appreciated it. Maybe it could be completed by a "please explain that control" mode where you can touch something on screen and learn about it rather than use it ...

I feel like it would help a lot to have buttons that bring up menus (especially on the animation editor, which needs more explanation than sprite editors do), where you'd have more room to make it clear what each option does or avoid needing button combos so you can fit more options on-screen, but that has to be weighed against how much it would slow down a user who knows what they're doing. You *could* have quick shortcuts with small icons alongside a button that brings up a menu that's less compact, though.

I have started something along these lines for 'monsters edition' in LEDS... That will be motivating to push it further

As you may have guessed, that lovely avatar for Nova comes straight from her website ;)