Bon, oui, le GB studio, c'est rigolo comme concept. Et ça fait pas mal de titres tout à fait sympa comme ce dinosaure de luxe. Mais y convertir du Bilou, je vois mal le truc ... même Badman aurait du mal. .. mais, petit délire de Mars ... j'ai déjà un jeu qui avait été pensé pour le monochrome dès le début: Caliméro!
On ne va pas se mentir, par contre, ça n'avait pas vraiment été pensé pour les 160 pixels de large du DMG. Le personnage ne ferait pas loin de la moitié de l'écran!
I've spent a good amount of hours on GameBoy, back in the 90's, playing Super Mario Lands, Kirby and of course, Link's Awakening. So when I hear fellow developers enjoying to work with environment like GameBoy Studio and reaching a significant audience, I can't help thinking "shouldn't I try gameboy dev as well ?"
But what game would I make there that wouldn't be over-ambitious for the platform ? That can't be Bilou and while there has been a pseudo-gameboy level in Badman III, it's unclear it would be working with the rest of the game. But ... how about "my" monochrome hero in his monochrome adventures because it was originally designed on a monochrome 8086 back in 1990 ?
Une fois remis à une une échelle un peu plus raisonnable, avec un perso en 24x24, ou quelque-chose comme ça, on commencerait à pouvoir jouer. Pas que le jeu deviendrait automatiquement un hit, hein, mais voilà.
So I looked up for a GB screen template, dug my old Calimero screenshots and started to tweak colors to see how it would look like... and spoiler alert: it looked huge. Calimero was designed for 720x348 screen resolution and then ported to VGA 640x480 keeping its original sprite data, of 54x50 pixels or so. that's nearly 1/3rd of the GB screen in each direction. I know Calimero "gameplay" has always been about die-and-retry and you-should-have-known, but it would be pushing the thing too far. Scaling the sprite to some 24x24 would allow something much more playable.
Oh, bin puisqu'on en parle, je pourrais aussi vous mettre le lien vers une série de scans de l'été dernier. La Pipe Zone, bien sûr, inspirée de SMB3 et qui sera un thème récurrent dans les niveaux de mon frère, la pyramide dont le design ne m'a jamais convaincu et la "water zone" qui a un petit côté Alex Kidd.
Même quelques boss ;)
And what better post could I find to put a link towards the set of scanned level designs I did last summer ? Scans, I mean. Level designs are from 1989-1991 and from my brother. Let me tease you with this "pipe world" (obviously influence by the pipe world of SMB3). I'll let you explore the link and find the pyramid levels as well as Alex-Kidd-inspired bosses.
Been reading this far ? well, that deserves a link to that other mastodon thread where I tried to convert some of Bilou screenshots into 4-shades-of-grey mockups, after somebody posted a music disk of Mickey Magical Quest for Game Boy in January '25...
Et on pourrait essayer de finir en beauté avec une petite image de Bilou en 4 niveaux de gris, avant et après retouche par votre serviteur de janvier 2025... qui ne tient absolument pas compte des contraintes du genre "3 couleurs + transparence par pavé de 8x8", ni du nombre max de sprites par lignes, ni du nombre max de tiles de la GB ni rien. Un pur délire de Gimp, quoi.
Toujours en mode "post-desktop". Toujours avec mes carnets qui me servent entre-autres à suivre la progression (lente mais présente) du projet "dreamland". Tout le jeu, avec ce genre de carnet, c'est d'arriver à conserver facilement accessible les choses qui sont encore pertinentes. Souvent, ça passe par un coin de feuille sur lequel je vais me faire une espèce de petit index illustré des pages sur lesquelles j'ai encore des cases de "todo" à cocher ... régulièrement quand la dernière page de ce genre a perdu son statut de "priorité absolue".
Working without a desktop ... without a central unit where your project has its home and grows ... it has slowed me down for years until I opted for making the new home for my project to be made of paper instead. But that means I need to dig older contents into newer pages on a regular basis. And part of the solution for me was that this notebook hosts everything I need to keep track of.
A trick I've started using lately was to make visual/graphical table-of-contents towards past pages, in this case, all the pages where I have "TODO" items still pending, like a small mushroom getting hit by an apple to remind of the todo-state-machine that guided me throughlatest screenshot saturdays
C'est évidemment la page 61 qui a ramassé le plus de cochettes ces temps-ci, avec les interactions autour de Funghi et les Applemen, au point qu'il a même eu droit à sa petite barre de progression.
D'autres points avaient été relevés lors du feuilletage et vont se retrouver grisés: ils ne sont pas utiles pour proposer une "première démo" de Dreamland. C'est le cas pour les ajouts juteux autour du poing-écrabouilleur de la pyramide. Oui, ce serait plus sympa qu'il fasse de la poussière, qu'il fasse trembler l'écran etc. mais on peut très bien tester le jeu sans rien de tout ça.
There are a good number of the other todo items that are linked to water interactions and swimming but that's no big surprise: water and swimming have been added over the previous year to an engine that was unable to handle that before, so there are plenty of little things left to tune or fix.
Once I was done with that first sweep, I tried to rationalize: I'd like to be able to let people play the game as early as I manage, and many of the todo items, while valid, aren't needed before people play. Sure, big smashing punch looks better if it triggers clouds of dust and shakes the screen as it smashes into the ground, but none of this is a blocking point if it's missing ... that's why the punch "icon" is greyed out.
Si la page d'index visuel correspond à un moment-détente, comme certain(e)s feraient des mandalas, il y a aussi des petites notes beaucoup plus gribouillée sur des choses à corriger saisies au vol pendant que l'un ou l'autre essaye le jeu. Mon frère est particulièrement redoutable à ce numéro-là. Mettez lui un de mes programmes entre les mains et il va vous le soft-locker ou pire en moins de 2. Il aura fallu pas loin de 3 reboots pour qu'il puisse lancer une pomme sur Funghi le week-end dernier ^^".
Et comme vous pouvez le voir, c'est beaucoup autour de l'eau que j'ai pris du retard.
And yeah, many of the items in those sub-page are less eye-candy than the index. Many of them are on-the-fly sketches of something my brother or my son or someone encountered while testing the latest version on my NintendoDS. Sometimes they are summaries of other TODO items grouped according to the tools/energy I'll need to tackle them. I can't really setup WiFi transfers through my NUC-cube while the dinner is cooking. I won't have my blog at hand to remember me what I wanted to draw on the NDS once I'll be in a no-WiFi zone with my DS around. I'd better focus on editing code once I'll be in the good setup to edit some code, etc.
Il m'arrive aussi de temps en temps de faire une version structurée différemment de ces todo-index, où je re-trie les check-box en fonction de ce qu'il va me falloir comme matériel pour avancer: la DS elle-même, le laptop, le "cube", un moment WiFi ...
L'idée est d'essayer de mieux grappiller les moments disponibles et ne pas retomber sur "ah oui, il faudrait faire ça ... ah mais non, il faudrait d'abord que je mette à jour Bilou.cmd et je n'ai que la DS" quand j'ai une petite demie-heure qui se dégage.
Et forcément, c'est dans ces moments-là qu'arrive une idée du genre "mais oui! faire des ricochets sur l'eau avec les pommes!" ou "les chauve-souris cessent de vous pourchasser si elles rencontrent de l'eau (façon essaim d'abeilles Disney ;-)
And of course, I have to accommodate for the fact that ideas pop up when they feel it, not when I'm in front of a nice blank page on which a big title has just been polished :P
edit: for the next week-end, analysis and preparation happened thanks to the cube serving the repository over WiFi to the boox sketchpad and then coding happened early in the morning, outdoor in the Virtual Machine of That Other Laptop (better battery, awful keyboard) through sshfs as the files and compiler were hosted on the cube too but the emulator ran within the laptop. At least, the 1st half-hour session was outdoor then the rest was coded on the "dining" table next to the coolness dispenser. That allowed me to have 3 items done (that's completing the page 61) and 2 screenshot saturday released :P
Funky Funghi, un des plus anciens personnages de la Green Zone sur DS, vient de se ramasser une pomme. Jusqu'il y a peu, la pomme serait juste passée à travers, mais alors que ce blog va sur ses 20 ans d'existence, j'ai rajouté les quelques lignes de code script qui manquaient pour que l'interaction proposée début 2022 devienne une réalité: on va pouvoir dégager les champignons du chemin à coup de jets de pommes.
Throwing apples around is a bit more fun since they've started rolling when hitting the ground, but one thing has felt odd so far: seeing the appleman crossing the path of a bouncing Funghi without triggering any effect. Since early 2022, I had the idea that we could have Bilou *bouncing* when hitting the hat of Funghi rather than being hurt, and that implied of course that a thrown apple should bounce as well. It was now time to implement that.
Ah, and yeah, I've played a good deal of the original Rayman, including throwing fist at bouncy plums and yin-yan balls to make them reach the place I wanted them to be. With all this new bounciness, Funghi is no longer just a hazard and you might actually want him to be *somewhere* rather than just wanting him away. Some of the initial ideas -- such as having the hat deflecting apples and only the foot being the target to hit if you want him moving -- quickly proved unpractical, and uselessly tricky to do, especially for a World-1 interaction.
Bon, j'avoue que comparé aux "prunes rebondissantes" de Rayman, on est sur quelque-chose de nettement plus détendu: Funghi ne risque pas d'aller rebondir contre un mur et de revenir vous écrabouiller. Il ne reçoit que la moitié de la vitesse de la pomme et ralentit de moitié à chaque rebond. Juste ce qu'il faut pour passer d'une souche à "entre les deux souches" en une pomme. Mais ça devrait être marrant quand-même vu qu'il y a moyen de ramasser à nouveau la pomme et de la lancer une fois de plus. D'autant plus que maintenant, il va aussi être possible de rebondir sur le chapeau de Funky Funghi! (c'est peut-être encore un peu fort, d'ailleurs).
La solution à laquelle je suis arrivé à coup de débuggeur d'expression est un rien intimidante ... entre autres parce qu'elle dérive de la collision destinée à faire rebondir Bilou, et que pour Bilou, je voulais que l'angle change selon qu'on arrivait plutôt sur le bord ou sur le centre de Funghi, comme s'il était vraiment un bumper de flipper. Pour ça, on va préparer deux valeurs et les combiner avec | dans le byte haut et le byte bas d'un entier 16-bit avant d'écrire le tout dans la 10e variable de Funghi avec :a. C'était rigolo avec l'appleman, mais ça devenait compliqué d'y ajouter le transfer d'énergie ... donc au final, pour l'appleman, Funghi agira toujours comme un mur qui absorbe 50% de sa vitesse horizontale et n'a aucun n'effet à la verticale. Et sur l'énergie absorbée, la vitesse acquise par Funghi est moitié moins importante que celle qu'avait l'appleman ce qui nous permet de calculer qu'un Funghi pèse à peu près 2 Applemen ;P
I ended up with something simple for Funghi/Apple interaction: half of the speed of the appleman (w0) is transferred to Funghi, and the other half is bounced back. But since Funghi is bigger, the half it takes only result in 1/4th of the speed. Not pushing him very far, I'm afraid. And well, that's only the part w0 4 / v0 + :0. All the things that happen before are reusing the "protocol" defined for throwing things where the thrower decides of the direction of the thrown object I already used for dumblador. The X speed and the Y speed will be set in the 10th register of funghi with :a and later used by the appleman with
$RTHROWN->$LTHROWN on hit0 [C_THROW wa 0 < &] (wa $ff00 & :0 wa 256 * :1)
Mais dans le code de l'appleman, j'ai quand-même gardé un code générique qui se contente d'appliquer le vecteur-vitesse qu'il trouve dans la 10eme variable de ce qu'il a heurté. ça pourra me permettre par la suite de faire en sorte que les branches rebondissantes puissent elles aussi renvoyer les applemen ^_^. Petite subtilité: la transition hit de l'appleman est testée avant la transition found de Funghi mais c'est found qui fournit le vecteur vitesse que hit va utiliser. c'est pour ça qu'il y a un test qui s'assure que wa < 0, pour que lors de la première frame de collision, l'appleman conserve sa trajectoire pendant que Funghi calcule l'impact. A la 2eme frame, wa est défini et la trajectoire de l'appleman pourra changer.
Et pour la collision Bilou/Funghi, c'est la distance entre le centre des hitbox (we) qui va déterminer l'angle de l'impulsion que Funghi va nous imposer, entre (-3,0), (-2,-1), (-1, -2), (0, -3)
The idea inintially was to use the same behaviour as the one I coded for Bilou, where the angle you're bounced depends on the position you hit Funghi on. That's decided in Funghi's script with
state0->state0 on found$bilou [C_THROW we 0 >= &] (we 4/ 256* we 4/ 3 - $ff & | :a)
where we is one of the collision-specific parameter (rather than an internal variable of the collided object) containing the center-to-center distance between Bilou and Funghi, ranging from -24 to +24. At the very edge of Funghi, you'll get bounce horizontally by (+-3, 0), and at the center of his hat, you'll be bounced by (0, -3). In between, you could get (+-2, -1) near the edge and (+-1, -2) near the hat. And yup, it's got the overall expr_1 256* expr_2 $ff & | shape again to put both together in a single variable.
I still had to do something for how static Funghi looks when hit by something. My first attempt failed because transanims with characters that are made of a single sprite, and so far, Funghi was still like that. But behold, Funky Funghi 2.0, remade in AnimEDS after I separated hats and feet, so that I can animate it more freely, at in-between frames of some sort, etc.
It doubles the amount of memory it takes, but I think it's worth it.
Il me restait un truc à régler: Funghi donne l'impression d'être en béton et que rien ne peut lui arriver même quand on rebondit dessus ou qu'on lui lance une pomme. J'aurais bien essayé de réutiliser l'animation "rebondit au sol" dans un sens ou dans l'autre, mais Funghi est toujours un "SimpleGob" premère génération, et je ne leur ai manifestement jamais ajouté le support des transanims.
Je profite donc de la p'tite canicule du week-end pour redécouper un peu Funghi dans le Sprite Editor, refaire ses animations dans AnimEDS et rajouter un "fait rebondir un truc qui arrive du haut" ainsi qu'un "fait rebondir un truc qui arrive sur le côté". Ce n'est pas spectaculaire, mais ça donne plutôt bien quand-même.
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.
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
I have a git folder that is accessed both by a windows host and a linux guest from a VM (as a shared folder). Everything was fine until some git package upgrade started warning about "in the working copy of 'project.txt', LF will be replaced by CRLF the next time Git touches it" (or the equivalent from the Linux guest).
I'd like to avoid cloning the repository twice and I already have something that makes these file LF-only on the master repository. I set autocrlf = false in .git/config, but that does not seem to help.
The manpages of git are heavy, freaky and intimidating to say the least. But I guess if I had rtfm'd them, I'd have eventually encountered the git config --show-origin --get-all core.autocrlf command, which conveniently reports all the files where the given configuration item. I'd have figured out that while I had my local configuration file requiring "do not do auto-CRLF conversions", the system-global configuration actually had the precedence. ... ridiculus, but that's the way it is now.
git check-attr -a project.txt and git ls-file --eol project.txt could be useful to check the current state as well.
With autocrlf=false in Git/etc/gitconfig, I don't have the warnings anymore, but I still have the file that is switching between CRLF and LF depending on whether Windows host or Linux guest is checking it out. It looks like the only way to get the desired behaviour is to edit * text=auto eof=lf in .gitattributes, at the root of the repository. I want that to remain a local decision, and hopefully, my colleagues haven't committed that file yet, so that'll work.
J'avais jusque là la 3.0.6 sur la machine windows du bureau ... qui m'a déplu sur plusieurs aspects. Petit tour d'horizon avant de passer à 3.2.4
sauf que tout à coup, c'est la 3.2.2 qui s'ouvre !?
les niveaux de zoom sont devenus beaucoup plus étalés, notamment quand on zoome avec CTRL+roulette ... au point que avoir un 200% ou un 300% "propre" pour une capture d'écran de pixelstudy devenait impossible sans aller entrer la valeur à la main. 3.2.2 corrige ça en permettant de monter à 33, 50, 66.6, 100, 150, 200 avec les raccourci clavier "+" et "-"
changer de couche avec PG up et PG down ne permettait que de sélectionner la couche, pas de l'activer pour les opérations de dessin et de copier/coller. c'est corrigé avec 3.2.2
Est-ce que je deviens chèvre ? Non. C'est le nouvel outil de sécurité du boulot qui fait les mises à jour dans notre dos. Sans avertissement, sans résumé d'opérations. Rien.
Restait le panneau d'impression qui indique maintenant "pas de prévisualisation possible". Un comble pour un programme de dessin ! Un petit tour dans la base des registres pour ajouter PreferLegacyPrintDialog=(DWORD)1 sous Computer\HKEY_CURRENT_USER\Software\Microsoft\Print\UnifiedPrintDialog et on revient à quelque-chose de moche, mais utilisable.
Quelques semaines avant de partir me reposer un peu, j'ai voulu faire un test de "3 rooms" sur ma DS. Pas de chance, il manquait une ligne - une seule - au fichier script sur la DS, de sorte que le fichier en question ne se lançait pas. Du coup, quand je me suis retrouvé assis tranquilou à une terrasse, je suis revenu sur cette idée d'éditeur de texte pour la DS.
I really could use a text editor running on the DS, to patch those script files without having to 1) turn the cube on; 2) stick the WiFi in; 3) setup upstream/downstream channels; 4) beam file out; 5) patch it in vim; 6) beam it in again; 7) try and most likely repeat from 4. And I did have a couple of hours by the swimming pool, sitting at a table to think how to approach it.
Et après quelques notes sur comment l'éditeur pourrait fonctionner, je retombe sur cette idée de "mode scribouille" qui me hante depuis 8 ans ... pour finir par me rendre compte que le meilleur programme pour tester le système, c'est celui qui permettrait d'encoder les patterns de chaque lettre.
Et donc, après quelques petites opérations de maintenance, je lance une nouvelle branchepour prototyper ça , un peu patraque dans mon fauteuil et pas franchement d'attaque pour grand chose d'autre.
Of course, it wouldn't take long before I tried to inject the "handwriting for DS" technique into it, and I realised something interesting: the "minimal viable product" to see whether I can truly write stuff with that technique is 80% of what we need to populate the recognition data. So after more ndsdev in a row that I've been doing over the last few months, I made a first version of "teds", working enough to decide that, yeah, it's kinda-working.
Je pourrais baptiser ça "un marathon ndsdev", avec son lot d'essai-erreur, de petites étapes prudentes et de passage par DDD pour me rendre compte que j'ai utilisé la mauvaise variable dans l'itération d'une boucle ^^".
J'ai maintenant une sorte de "minimal viable product" qui permet de tracer des lettres et d'effacer l'une ou l'autre lettre d'un L+LEFT. Assez pour constater que
des cellules de 4x4 pixels, ce n'est pas convaincant, vu les imprécisions du tandem stylet/DS
une "zone morte" en bordure de cellule permet effectivement de faire des "diagonales" de façon plus fiable
il reste souvent nécessaire de faire des "retouches" pixel par pixel
tracer les lettres d'un traît ou tracer les lettres "tranches de pixel par tranche de pixel" donne grosso-modo la même vitesse d'écriture: 30-32 secondes pour "there is no spoon" (16 caractères avec les espaces)
Next step will be storage and loading of the "recognition database" and selection of a "bank" of 8 characters to "train" from the ASCII set shown on the left of the screenshot.
Something is annoying me with the underground section of the green zone levels: it's too repetitive. It shows in everyscreenshotI try to make. I have variation tiles that could make it less uniform, but they don't really work if we repeat them. I have plans for a background, parallax layer underground, but it only really works in open environments, not in tunnels, and underground areas are mostly made of tunnels. in the Green Zone.
But those funny pillars might work as foreground layer as well! Maybe even better because they're bigger than the pebbles repeating tile of ground I have. They would focus the gameplay in a smaller part of the level just like a circle-of-light would, but with something pleasant to look at. The question is, how can I make it indeed focusrather than obscure. I don't want to make Infogramish game where you don't see where you're heading to because of the foreground.
Let's ask Bouli to make a bit of math, here: if my foreground layer advances by e.g 3 pixels everytime my regular layer advances by e.g. 2 pixels, then I just have to make a map that is 3:2 bigger than the playfield if I want to follow things properly.
I mean, my "foreground" map would be drawn over a 150% zoom up of the main map, and that should be it. At least, that's the intuition. How to confirm it quickly ? Well, how about cutting some paper to make a live overlay and make it move around. Of course, you have to consider that only a part of the result will be shown to the player, too.
Does that mean I need a special mode or a variant of the Level Editor ? ... maybe not. At least, not more than "use the "physical" layer of gac.map (move by 2:3) and let me edit gacfg.map on top of that.
The fun trivia here, is that the initial motivation was to find a way to have VRAM for textures now that I know it does not require palette slots. But while comparing the options, I came to the conclusion that I had no real use of 3D in the green zone anyway, except maybe to render more trees in the background... but checking Case Portman's Lost in Fuzz video, I realised that proper amiga-style parallax would work better than any 3D and would be easier to make here. And yes, I'm only using 2 tilesets out of the 256K allocated to the background tiles in Dreamland, so I could fit a 3rd one and another "infinimap" in the unused space ...
Does it means textured 3D becomes out of reach ? No, but that Bilou's Dreamland will sometimes use 3D, sometimes not (plain 3D does not require more VRAM, but it consumes one layer).
Does it means Yoshi-Island-Style dual screen action should be forgotten ? No, but it would only work in levels where we have no 3D objects and no fancy lush background/foreground maps.
Does it mean having Bouli or another character "telling the story" on one screen while Bilou is "living the action" on the other impossible ? No, but Bouli may have to survive within 16K of sprite VRAM, using DKC-like live-update techniques for his animations.
edit: sidequest finding: shifting extended palettes from 64K to 16K VRAM isn't that trivial to do. (but not required unless we want to texture 3D stuff)
Since the introduction of the appleman ROLL mechanics, there was something I couldn't completely fix: if you managed to throw the appleman straight into a "jump thru" platform, it would stop as if it was a wall, while you'd expect it to roll over the platform or fall through it instead.
I envisioned a number of solution to this problem until I realised there was one quite obvious one: just bounce the appleman upwards a little bit when that happens. It will then be able to advance sufficiently into the platform so that it is then in the normal "thrownroll" transition. If instead it was thrown into a solid wall, the bounce will be visible, but have no lasting effect
Au début, ça ressemblait à un petit détail: au moment de se mettre à rouler, un appleman pouvait se retrouver bloqué bêtement par un sol qui trainerait en l'air. Mais si, vous savez: ces plates-formes qu'on ne peut franchir que de bas en haut, mais qui vous retiennent quand vous allez de haut en bas.
Eh bien pour vous retenir, il faut qu'elle soient solides au moins pendant que vous tombez. Et à ce moment-là, elles ne font pas dans la dentelle: pas question de venir avec un "oui, mais non, mais regarde: en vrai je ne peut pas atterir, là: c'est juste le côté de mon haut qui passe de quelques pixels dans le bord de ton bas ... j'fais qu'passer, quoi!". Nada. Je me retrouve avec une pomme qui était lancée à vive allure et qui s'arrête nette sur un plan d'herbe à travers lequel elle passait sans problème quand vous la portiez sur la tê♪te, la pomme ♫ i' faut pas'l'nier.
And let's be honest: it would have been a nightmare to debug without the recently introduced GobExpression debugger. You can quite easily end up in a situation where you expect some speeds to have been non-null in some condition and realise that, well, no they're null here.
The alternatives I had envisioned were globally more complicated, like holding the speed for some time and then restoring it. More complicated in the sense that they required introducing new states in the behaviour or even new controllers. Here, it's just one extra transition that says "stay in THROWN state if {conditions}, but update velocities as follows"
C'était devenu un sujet de cogitation dans mon carnet, et un assez bon exemple de ce qu'on pourrait vouloir faire avec un contrôleur "around" pour contourner les obstacles. Au final, ça se passe de ce genre de complication: il suffit de redonner une petite impulsion verticale, juste assez pour que la pomme monte d'un demi-bloc et puisse atterir sur la plate-forme plutôt que de passer à travers.
Tout ça grâce au nouveau débuggueur d'expressions que vous voyez dans le bas de l'animation, qui représente chaque opcode par un caractère qu'on fait avancer petit-à-petit avec la touche L et qui complémente agréablement ce bon vieil Inspector Widget :P
I had announced on some discord channels that I had a new NDS demo of my ongoing work. One of these channels is the one where I'm in touch with Fei, who already tried a copy of the 3-rooms demo back in 2021 and 2023.
Back then, we finally managed to have something running at his place, but it doesn't seem it has been preserved. After locating a register that could tell me whether we're running on DSi (and then skipping the InitGBA function that would blue screen the demo -- as there are no GBA memory around), the best I could get is a "EFS search failed" message, but also a mention that 1) DLDI is around but 2) the demo is installed on Fei's SD card rather than in the filesystem.
Bad news is that I don't see anything in libfat or in libnds that would enable DSi' SD card access, which goes through completely separate hardware and isn't covered by DLDI at all (to my best knowledge). I'm not the only one to have such problems, but there was no answers to be found.
So I guess my best move to make progress there is finally to get homebrew software running on my own DSi thanks to StyleHax... for that, the next step was to enable a DNS server on the cube. That sounded like a task the rubber duck could take care of and it suggested the following:
Use asmalllocalDNSresolver(dnsmasqorunbound)boundtotheinterfaceandconfigureonlythefewhoststouseitviaper-interface/etcresolversettingsorsystemd-resolvedsplitDNS.Sinceyouwantminimalconfig/depsonUbuntu18.04,dnsmasqissimplest.
add local hostnames: address=/host1.example/192.0.2.101address=/host2.example/192.0.2.102
ok, fine. That allowed me to fake some website with some other DNS name, and eventually get stylehax page shown on the DSi, even once making a green screen (exploit worked, but boot.nds was missing) and once loaded the dumptool.nds, but it complained the SD card was too small (it's a 128MiB one) and refused to do anything. Each attempt takes 1-2 minutes, and I'd say the success rate is at best 1:10.
One of my ideas was to use e.g. runME as boot.nds and work directly from there, but from this experience, it doesn't seem to be a viable plan ...
Or maybe I should simply use another hack ? like the Memory Pit for the camera application ?
edit (25/5): Got lucky with stylehax this morning: every boot.nds made it through in 1 or 2 attempts. So I managed to get DLDI scanning of Dreams-inspector.twl.nds and figured out I had to fix my Makefile to apply efstool processing over that new .twl.nds as well ^^. And eventually, I got Dreamlands 3-room demo running on my own DSi !_!
It should have been a calendar, and somehow I'm using it that way on the "recto" side. But it's a week-by-week calendar, which means it's also a near-A3 rigid laptop with good quality paper that I can use nearly anywhere to write notes about nearly anything.
But I wouldn't be studying Turing processors this week-end, nor how the 1st Pokemon game stored its maps. Instead I was trying to tackle two old bugs in my editors that affect loading new files in AnimEditorDS and leaving "monsters edition mode" in LEDS. It's not very impressive, but it's releaseversary day, so here it is anyway.
And, well, it seems like it's been nearly one year since I made a release of the Dreamland demo itself. Now that the "WIP" level in the greenzone -- the one I intend to keep and that has been historically the first Bilou level ever -- has an exit door, I can make some release for that as well. Enjoy
water slides
revised appleman mechanics, including the funny rolling throw
connected doors
smashing big punches
I'm sure there are plenty of bugs and glitches here and there. This is not a polished demo, more a presumably playable snapshot of the ongoing work.
C'était une étape casse-pied du dévelopement DS ici: à chaque fois que je voulais échanger des fichiers par WiFi, il ne me suffisait pas de brancher mon stick wifi, je devais aussi redémarrer le service DHCP sur mon cube. sudo service udpchd restart ... j'ai tapé (ou cherché dans l'historique) un nombre incalculabe de fois. Sans ça, la DS ne recevra pas d'adresse IP.
Au final, c'est dans /etc/network/if-up.d que j'ai ajouté un lien qui a fini par fonctionner.
#!/bin/bash
interface=$IFACE
event=up
log() {
echo $* | systemd-cat -p info -t if-up
}
log "$0 (interface=$interface, event=$event)"
if [[ "$interface" == "enx000272436672" ]] ; then
log "this is your USB WiFi stick ..."
if [[ "$event" == "up" ]] ; then
service udhcpd restart
fi
fi
Ok, ce n'est pas terriblement convaincant pour les transferts via runME, puisque là je dois toujours déterminer quel fichier envoyer/recevoir dans la ligne de commande, mais au moins ça me permet de faire les mise à jour des outils sans avoir besoin d'ouvrir le laptop... dans le cas où le fix avait déjà été mis sur le cube la veille :P
You know you're on a hobby project when you start fixing things that are on the bottom of your priority list first because you feel ashame of their current state and there's no one pushing you to do top-priority fixes instead.
Improving the graphics of the water slide was certainly no high priority except for my eyes. Having a special "patch sprite" to allow the desired shape that needed 3 layers despite I only have 2 map layers was inevitable after that, as much as patching the color cycler to avoid half-water half-rainbow effects.
Les graphismes des pentes-à-eau présentés fin 2025 (eh oui ... déjà) avaient un truc qui ne me plaisait vraiment pas : une jonction très "carrée" entre la cascade et la pente. Un problème qui est la conséquence d'un choix dans la construction de cette cascade:
elle est constituée de deux couches de graphisme superposés. ça offre des avantages, mais ça veut dire aussi qu'à part des sprites, je ne peux rien mettre en même temps. Un problème que j'avais déjà rencontré dans le dernier niveau de SchoolRush. Problème que j'ai retourné dans tous les sens pendant les mois de janvier et février (provoqué par le même genre de problème "quelle couche ?" autour du poing écrabouilleur) avant que l'évidence ne me frappe comme un boomerang revenant de l'ère 8-bit:
rajoute un sprite.
Well, adding a sprite overlay on top of the tiles layer is hardly any innovative. In fact, it was super-common in 8-bit and 16-bit games as soon as you aimed at something visually more sophisticated than Super Mario. But no. It took me almost two months to realise that was the solution I needed here.
And took me almost as long to realise that very dark greyish stone wouldn't work in the bright-and-colorful environment of Bilou undergrounds, and that since I'd like the peaks zone to feature purple rocks, I could start introducing purple rocks as soon as the first level.
Then in a single evening, I reconstructed a draft mockup of what I wanted to see: background dirt tiles and a waterfall, then the big rock and the wavy effect (that is still to be integrated), and in a couple of hours, I repainted the rocks in a quite satisfying way.
And when I saved things, I realised I was close to 90% of tile space consumption, while there are still a good deal of things I'd like to add to the green zone. So I wrote down a note to hunt for duplicatas later and a few other higher-priority things like drawing a background screen for the underground parts... and of course, the day after, I was marking duplicate tiles and then patching them in the level maps and noting where I had alternate dirt / rock tiles that I could use to break the grid, etc. Priorities will have to wait :P
J'ai donc profité d'une soirée où ma fée était au club-créatif du coin pour aller de fil en aiguille, dessiner quelque-chose qui ne me déplaît plus, faire le montage, ajuster les scripts et rajouter le code qu'il faut pour avoir une pente qui présente bien, avant de me rendre compte que oups, je commence à avoir trop rempli ma mémoire de graphismes pour la greenzone, marquer les duplicatas, les nettoyer, etc. au point que j'ai dû retransférer presque l'intégralité du contenu graphique de la green zone (y compris les maps des niveaux) de la DS au PC alors que je vais aussi devoir faire le transfert inverse pour les scripts de comportement ^^".
It's a small game, where you drive a triceratops-like dinosaur, collecting eggs and completing levels while avoiding falling lava bombs. But that was the game Antoine from Sleeping Panda presented last wednesday at the local gamedev afterwork event.
He made the game with Gameboy Studio, one of these recent desktop applications that bring together all the things you need to create software on 8-bit machines -- although here you're largely able to draw stuff in Gimp and lay out maps with Tiled. And you're also able to export your work as HTML5 game in addition to GB and GBC roms, which is clearly a plus to distribute your creations.
Antoine did talk a bit about GB Studio itself, and how that tool let him do things he wouldn't have done otherwise as well as how it would frequently make impossible some things that I'd have thought trivial, like the ability to destroy some of the ground with the lava bombs.
While he was talking, I couldn't help noting that graphics would have easily allowed to make parallax scrolling, but I doubt the events scripting system would have supported such low-level techniques, although -- according to Antoine -- the tool allow to "eject the engine", rewriting some parts to compensate e.g. the lack of Dash support in the platformer character while his game was all centered about dashing.
But the most interesting part of the talk for me was about the reception of the game by gamers. How it caught speedrunners interest while the author of the game did not know of speedrun beforehand. How people started to send him their best time. How people started to make him cover art, contact him to see whether he'd approve patches for retro achievement. And honestly, when I see how many people hype about gameboy and gb studio in general over the networks, I'm not so surprised about it. It was more complicated to explain how NDS is different. Because the nostalgy around the device is still very young. Because technically and legally, producing DS cartridges for homebrew is much more complicated. There are 8-bit catridge manufacturing online now, likely some 16-bit as well. But for DS cartridges I don't expect any such things before again some years.
But nonetheless ... Maybe I should take the extra step that I've never made so far: writing an itch.io page for School Rush because this is where gamers will look for games, not on github or sourceforge.
Je suis passé hier sur conseil de ma fée à l'Apéro Jeux Vidéo du coin, pile à temps pour le transparent 2 ou 3 d'Antoine sur son jeu GameBoy "Dashosaurus DX". Promis, je vous parle dès que possible de son homebrew et de son message, mais j'étais aussi venu accompagné de Lime et DarknesS pour la partie "apéro" et j'ai filé l'URL de mon blog à deux ou trois personnes qui vont probablement débarquer au milieu de mes causettes et se demander où ils sont tombés...
Donc, quelques pointeurs.
J'ai présenté hier la démo "three rooms", qui me sert de salle de tests pour mon projet "Bilou Dreamland"
Les plus patients auront aussi vu une version encore très WIP du niveau de l'arbre creux, ou une version aléatoire de mon jeu précédent "School Rush" mais pas la toute dernière, parce qu'elle m'a fait des misères sur Darkness ... Et bien sûr un tour d'horizon des outils: l'éditeur de sprites, de niveaux et d'animations.
Voilà, voilà. Bonne journée au passage à ceux qui auront vu ce message, n'hésitez pas à me laisser un message ici, sur bsky ou mastodon selon vos habitudes ^_^
Ah, just in case you're not speaking French, there has been a gamedev-cafe event in the town nearby last night, that I've been invited after an incredible sequence of events that all started with my Fairy and involved using dungeons and dragons to dismiss a bunch of flipping pirates. Anyway, I had a good time watching the quite long presentation of Dashosaurus DX developer and used the 'cafe' part of it to show those who wanted to see it my tools and games on Nintendo DS. Since Dashosaurus is a Gameboy title, that seemed pretty fitting ^_^
Entre deux chapitre du gros volume sur les jeux Harry Potter, j'ai aussi réemprunté à mon frère les premiers Pix'n'Love, avec l'intention de repérer les titres qui pourraient intéresser Mlle L de la S-Team qui nous fait un cursus lié au jeu vidéo.
Dans ma liste de "pix'n'gems", le 4eme mook était renseigné pour Lode Runner, mais avant d'en arriver la je me suis retrouvé scotché par la présentation du développement du shoot'm'up Xevious. Un titre dont je n'avais jamais entendu parler avant la sortie du magazine et qui n'est pas franchement attrayant à mes yeux de padawan de pixelation.
Mais voilà. S'il n'y a pas des masses d'éléments visuels pour nous raconter la genèse de Xevious dans le dossier, c'est parce que le développement s'est fait à contre-courant d'à peu près tout ce qu'on a eu l'habitude de présenter, avec un gars qui bosse en solo mais dans une grande boîte, qui fait tout "au feeling" directement dans le code au point qu'il faudra une équipe de reverse-designers pour faire les documents que le management voudra signer avant que la borne ne soit lancée. Et qui écrit un roman pour raconter l'histoire de l'univers de son jeu là où "pas besoin d'une histoire quand on a un bon gameplay" règne en maître.
Est-ce qu'il y a des enseignements à en tirer pour développer des jeux au XXIeme siècle ? .... j'hésite. Est-ce que c'est intéressant de découvrir le travail du futur développeur de Tower of Druaga, ce titre étrange et iconique des salles d'arcades japonaises des années '80. Absolument!
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:
somewhere, on planet Earth, there's a weird guy named Sylvain (aka. PypeBros) who loves to write programs and draw comics with a blue ball named "bilou". That's me.
If you have a blog that talks about similar stuff, just leave me a comment.
Bon, oui, le GB studio, c'est rigolo comme concept. Et ça fait pas mal de titres tout à fait sympa comme ce dinosaure de luxe. Mais y convertir du Bilou, je vois mal le truc ... même Badman aurait du mal. .. mais, petit délire de Mars ... j'ai déjà un jeu qui avait été pensé pour le monochrome dès le début: Caliméro!
%20%C2%B7%20RetroAchievements.png)
- + 
Vote for your favourite post
