Foreground for the underground ?

Something is annoying me with the underground section of the green zone levels: it's too repetitive. It shows in every screenshot I 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.
 

Better THROWN->ROLL transitions

 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 "thrown->roll" transition. If instead it was thrown into a solid wall, the bounce will be visible, but have no lasting effect

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"
 

NDS for DSi

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 a small local DNS resolver (dnsmasq or unbound) bound to the interface and configure only the few hosts to use it via per-interface/etc resolver settings or systemd-resolved split DNS. Since you want minimal config/deps on Ubuntu 18.04, dnsmasq is simplest.

• Edit /etc/dnsmasq.conf (or add /etc/dnsmasq.d/custom.conf) and add: 
• interface=eth1 # replace with your interface name 
• bind-interfaces # ensure dnsmasq binds only to listed interface 
• listen-address=192.0.2.10 # IP of that interface (optional, stronger) 
• no-resolv # avoid reading /etc/resolv.conf 
• add local hostnames: address=/host1.example/192.0.2.101 address=/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 ...  

Maybe I should pay a closer look to the updated nds_loader ? 

Maybe I should check the way GetDeviceOpTab is implemented and try to write something that reports all available devices ? (alt. repo from Patater)

Or maybe I should simply use another hack ? like the Memory Pit for the camera application ? 

A few fixes

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.

 

 

 

 

UDHCPD enfin automatisé

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.

J'avais essayé d'ajuster les scripts de NetworkManager/dispatch mais sans grand succès. Guère plus du côté du service systemd.

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

Fixing unimportant things

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 ^^". 

Dashosaurus and the gamedev afterwork

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.