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. 

Gamebrew / platformers

Somebody on gbatemp surprised me back in 2016 claiming (about School Rush)

HOLY CRAP! I'm surprised to see an actual game here, because usually most DS Homebrew is just shitty abandoned tech demos. Nice job on this! I'll check it out soon.

I dug that one again not so lately after School Rush finally got its Gamebrew Wiki entry and it felt hard to believe given the 1394 other entries the wiki has just for NDS games. There had been some unfinished titles for sure that had just enough contents to rank fairly in seasonly "coding" competitions, but there had also been brilliant titles. It was just after I ran into some "7 best DS games" that would only mention a few FPS and then non-game homebrews... I can't review all 1394 games, but I sure could give the "platformers" category a spin

"Sonic, the game" defines quite well the first category: graphics ripped from various 2D titles in Mario and Sonic series, unfinished physics and uninspired level design and no sound whatsoever. At least it demonstrates scrolling in large levels with parallax effect for the background layer.

Monky. One-screen collect-and-progress game. You'll have to backtrack if you missed some letters on the way. You'll lose all the collected bananas if you get hit. 1 monster type, 4 levels (as far as I can tell). (Unrelated) background music featuring a mod player and a few sound effects.
A nice tech demo using PaLib and graphics ripped from DK Jungle climb GBA game, but not very inspired as far as game and level design goes.

I did not pass level 1 on first play. I missed a key gamedesign element: as you keep moving forward, you'll enter a sort of "run state" where you jump higher. There seems to be 4 worlds of 5 levels each ... that would be worth playing more before rating the quality of level design. You've got sound and music, but if you've played some pinball titles on the Amiga, you'll immediately recognize the style and honestly, it doesn't quite fit the coconut plains of the first levels. 

Temple Topple could have been featured in our "Biloutris" project, I guess. Block falls, they disappear if they line up, but you can't move them (at least, I don't think so). You do have to avoid getting crushed, though. Don't expect much variety as you play. None of the little things that can make such a "climbing" game really funny.

Starting a game has a significant chance of being unfair. Once you're one or 2 screens away from the bottom, there's little chance of getting crushed, and in between, there's a good chance you'll have to wait for the next jump option to show up. I gave up around 1300 pixels high, out of boredom. I would bet on looped WAV/MP3 sample for the background music. It might have been the author's hands-on title for DS Game Maker...

I tried Epic Caveman, too, and understood why the wiki entry only lists the title screen. The title is an endless runner, somehow akin to the "running zilla" game offered when a chrome browser cannot connect to the internet. But here obstacle are quite large, right form the start, requiring very precise timing to clear the jump over them. You can't jump "on" them either, which doesn't seem to make sense in this context. An there will be sudden speed up, requiring you to adjust the tediously learnt timing on the fly. Not even between series of blocks but *within* a series.

There's some sound but nothing really impressive. I'd put it in the category "mini-game of an afternoon, to check you've understood how to use assert import and can structure your project with different screens around the main game screen. Good for a programming tutorial if you had the source, but hardly interesting as a game, although - unlike "sonic the game" - there is coherency and care to detail here.

edit: okay, this is what "sonic the game looks like. and you don't see the fact that if you nearly land on a "platform", it will push you backwards so you can safely fall down instead of remaining balancing on a few pixels. That reminds me why the real sonic has *two* vertical sensors, and not just one. 

(yeah, I hesitated to dedicate 280KiB of blog storage to show that, and I certainly didn't want it to become the post's thumb picture)
 

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 ?

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.

StyleHax on DSi

For (too?) long, I've staid aside of DSi homebrew. Partly because there's little the camera could offer to my projects and I don't really need more than 4MiB of RAM, but mostly because until recently, running homebrew on that device felt like an arm race with Nintendo. You need to break into the machine through exploits the same way you'd take control of someone else's server on Internet and that has a taste of dark side I'm not fan of. Plus, once you've managed to get into things, you then have to install more permanent modification if you want to be sure to be able to do the same the next day, since Nintendo could ban the vulnerable software you've used to gain access (if you were lucky enough to have it on your device on first place).

But one post on hackaday might well change all this. Nathan Farlow has found a way to use the web browser shipped with the DSi firmware to execute arbitrary code.

 He just had to get his code into the right spot. For this he employed what’s known as a NOP sled; basically a long list of commands that do nothing, which if jumped into, will slide into his exploit code. In modern browsers a good way to allocate a chunk of memory and fill it would be a Float32Array, but since this is a 2008 browser, a smattering of RGBA canvases will do.

Ultimately, that will execute a boot.nds file from the SD card, such as a homebrew launcher.

Octobre dernier, j'avais jeté un oeil un peu plus attentif à "Comment on peut faire tourner des homebrews sur DSi". S'en était suivi un graphe compliqué dans mon calepin indiquant quel menu dépend de quel installateur qui dépend de quel firmware custom. Mais au final, on finissait toujours par dépendre d'un "hax" pour prendre le contrôle de la console. Un vrai piratage en règle, quoi, et qui dépend en général de la disponibilité d'un logiciel vulnérable sur sa console.

Pendant toute la durée de vie de la bête, Nintendo a mené une chasse farouche à ce genre de vulnérabilité, supprimant jeux et applications du service DSiWare au fur et à mesure qu'elles étaient identifiées, étendant sa liste de cartouches "nds" interdites (dont les clés avaient été cassées et utilisées pour des linkers) lors de mises à jour système indispensables pour faire tourner les nouveaux jeux ou refaire un téléchargement sur le DSiWare. J'étais resté à l'écart de tout ça. Mais j'ai commencé à réviser ma position: un nouvel "exploit" (comprenez "mécanisme permettant de faire tourner son code à soi en exploitant une vulnérabilité) à été trouvée, et pour le navigateur intégré, tout simplement!

It should be trivial to try: install your favourite DSi-capable software as boot.nds on an SD card, direct your DSi browser to nathan's web page and voilà. Except nothing guarantees the contents of Nathan's page will stay the same over time, so I'd rather download that locally and study the stylehax source code before I start using that on my own device. 

At the start of the chain is an html document with some NDS binary embedded as "shellcode" in the html <script> part, plus some javascript to exploit the use-after-free bug of the browser. The payload.c featured in the stylehax repository contains actually just a little loop to inject the 'true payload' at some dedicated location (held as a blob into payload.h). And that true payload comes from another repository (well, actually, that second repository contains many exploits, but the one we'll use is the 'minitw' one, according to payload.h)

As soon as the 'payload.c' part is running, we already have access to most resources of the DSi. The goal of minitwlpayload is to setup the proper context for the default bootloader of the devkitpro project embedded into the .nds (yes, that comes from a third repository :P) The bootloader will mostly run on the ARM7 core, which is the only one to have access to SD card registers on the DSi. There will be many passme-loop-synchronization-points until we're ready to execute the NDS or DSi code contained in boot.nds, one for each ARM9 function we want to execute between two ARM7 functions.

Pour celui qui veut tenter sa chance, rien de plus simple! L'auteur de l'exploit a mis en ligne une page HTML (une seule) intégrant le code nécessaire pour aller exécuter le fichier boot.nds qu'on trouverait sur la carte SD de la DSi et le javascript qu'il faut pour faire bugger le navigateur au point qu'il se mette à exécuter un morceau de page web canvas HTML5 comme si c'était du code machine. Et surprise, c'est du code machine, cette fois-ci! Enfoncé, HTML Quest ;-)

One question remains, though: how does ARM9 exploit trigger execution of custom code on the ARM7 ? It looks like the answer lies within the following snippet of exploit.c:

    memcpy16(VRAM_C, decrbegin, decrsize); // writing custom code into VRAM at 0x6000000
	VRAM_C_CR = VRAM_ENABLE | VRAM_C_ARM7_0x06000000;
    // now inserting a jump at the start of ARM7-dedicated memory area.
	*(vu32*)0x2380000 = 0xE51FF004; // ldr pc, =0x06000000
	*(vu32*)0x2380004 = 0x06000000; // (constant for above)
	debug_color(0,15,0); // dark green
	IPC_SendSync(1); // MAGIC!

For some reason, when we trigger an IPC IRQ on the ARM7 with code 1 (out of 16 possible codes), it executes code from the start of the ARM7 area again, where we have installed our trampoline to VRAM. Why does it behave so ? I guess the reason lies in some line of code for the ARM7 code in the TWL sdk, sealed in a vault at Kyoto ...  I presume I'll have to accept it without further understanding.

Seulement moi, j'ai envie de comprendre un minimum ce qui se passe. Histoire entre-autre d'éviter que la page ne télécharge un jetaibieneu.nds au lieu de démarrer hbmenu.nds rebaptisé boot.nds, par exemple ?Et aussi pour enfin comprendre cette histoire de .twl et donner une meilleure chance à l'exécution de mes homebrews sur DSi. Donc je parcours les pages github, ma liseuse dans une main, mon calepin dans l'autre...

exomizer/exodecrunch

One notable action of exploit.c from minitwlpayload is to "decrunch" the embedded bootloader into VRAM where it will execute, that is, to undo the compression performed by the exomizer tool invoked by dsi/exploits/minitwlpayload/Makefile.

• it packs the 'bootloader' from devkitpro github from 6KiB into a bit more than 4KiB. Unsure whether it was critical to use in this context :-P
• ndsload.bin is just an 'objcopy' binary-extraction of the ndsload.elf
• https://bitbucket.org/magli143/exomizer/src/master/src/Makefile could be the source for the exomizer tool, but I fail to get why it would need a 6502 emulator ... (I guess this is linked to the 'self-extracting for C64, Apple II and BBC micro' feature)

Possibly, such steps could make sense for larger payloads or for other exploits where the amount of data we can embed is limited (remember, there has even been exploits involving QR code readers)

NDS Dev in 202x

Back in february, 19-yo Violet! posted an animated version of the low-poly DS collected 167K likes and over 380 comments, most of which going towards "my childhood" nostalgia. Clearly, the NDS is now a retro console. That may not bring a wave of NDS development the same way we saw people starting to do SNES development a decade ago, but that's enough to push some 23-y-o 3D artist to convert their model into a .nds just to check what it'd look like and animate their hair with more code.

I've been surpised to hear the snes-lady Skwirl reporting that she had first wanted to write homebrew herself back in the days but dropped it because it was "too complicated". (she started some 3DS port of tilemap town, btw)

There are some ongoing NDS projects on github. I spotted one that pushes the 'reimplement X on NDS' to the extreme, bringing support for GBA pokemons, no less. Codestudy started. Probably tricky to get into it. And given how 'mature' the device is now, chances are that we find more ambitious projects like this (or a minecraft clone or cave story port) than the tiny one-screen flash/arcade-inspired titles of the neocompo years.

Curieusement, on dirait que ça ce ravive un peu, du côté du dévelopement amateur NDS, ces derniers temps. On est encore loin de l'age d'or, mais voir une Violet de 19 ans poster un modèle 3D de DS lite et récolter 380 commentaires parlant de "c'est toute mon enfance" et 167 mille likes, ça pourrait bien indiquer que la console est finalement devenue rétro, après tout. Un autre, de 23 ans, à carrément décider d'exporter le modèle 3D de son personnage fétiche en une ROM pour animer sa chevelure. Tout ça m'a remis en mémoire un commentaire plus ancien qui demandait "comment on fait un homebrew NDS, au fait". Et je dois reconnaître qu'une grande partie des tutos et ressources de l'époque ne sont plus à jour: les procédures ont évolué, les bibliothèques aussi ...

Resources
It reminded me of a series of tweet where someone was wondering how to get into NDS development. I have a tutorial git of my own, where each commit presents a part of what I use to build games on NDS, but that's teaching you to use libgeds, not libnds. There are devkitpro examples, too. I can't really recall whether their coverage is convincing for someone who wants to kick in. I myself have learnt with a mix of that and open-sourced projects from fellow homebrewers, but these are likely obsolete and wouldn't build against recent devkit versions.

The closest I've found is magusti tutorials. Most 'readmes' are in spanish, unfortunately and the directory structure is a bit confusing. It uses modern libraries, including maxmod. It uses 'all your data are belong to 4MB of RAM' approach, though.

Mais quelque petites recherches github ont quand même donné quelques résultats intéressants. Si la plupart des projets actifs utilisant libnds sont des portages plutôt ambitieux (et trop gros pour pouvoir servir de tutoriels), si la NFlib a le défaut de contenir encore pas mal de commentaires en Espagnol, on trouve quand-même deux ou trois choses directement exploitable, comme la balle-qui-rebondit de Magusti ou une adaptation de '2048'.

Maybe the best way would be to use NFLib ? Like in 2048-nds, a small puzzle game with a codestudy-firendly size ? It does restrict what you can do but usually in ways that won't hurt your project (like assume you don't want to use 16-colors layers), it has understandable wrapper functions and meaningful abstractions like auto-adjust position of sprites when scrolling background planes or delay OAM updates until vertical blanking happens. It let you chose between "my files are in fat:/SOME_DIR" or "my fat are in magical NitroFS (within the .nds, but requires compatible loader).

If that's fine for you, the projects Snake-DS seems like a nice thing to check first.

Getting Started

The windows installer 3.0.3 is still there, and it seemed to install things properly on a Windows 10 machine. Or so it seemed. Likely the Antivirus quarantining 'padbin.exe' during the installation process did no good, but all I actually get (apparently) is an msys2 install in C:\devkitpro\msys2 (which hasn't messed with the other msys2 pre-installed on that system. yahoo!) and that's it.

I did get a 'choose your packages' box, but it did not produce anything apparently. Well, pacman -Sl dkp-libs did indeed report what's available and pacman -S libfat-nds libnds nds-examples was all I needed to get the devkitarm (now r59) and the make rules as well. Some dependencies were still missing to build NDS examples though, namely ndstool (and I also missed dswifi because it's not named ndswifi ^^"). That's not yet enough. I'm still missing 'default.elf' from the default-arm7 pacakge :-/

So make your life simpler than mine: read the doc to the bottom and pacman -S nds-dev to install the pre-selection instead ^^"

Pour la forme, j'ai même voulu vérifier que tout ça compilait bien avec la version la plus récente des outils devkitpro. Eh bien, ça marche, et contrairement à ce que j'avais cru plus tôt dans l'année, il y a toujours bien un installateur pour windows (version 3.0.3). Bon, on ne s'emballe pas, il se contente essentiellement de nous filer un msys avec un gestionnaire de packages modifié. Je découvre d'ailleurs en fin de parcours la présence d'un méta-package 'nds-dev' qui pré-sélectionne tout ce que j'ai personnellement téléchargé à la main ^^"

Edit: looks like there's even someone who's busy designing a R4 substitute based on dual-core Raspberry Pico ...

2048 triangles

Cette histoire de Big Level Objects me turlupinait: est-ce que je ne fais pas le mauvais choix en laissant de côté le hardware 3D de la DS pour dessiner les niveaux ? Plusieurs autres homebrewers ont déjà indiqué qu'ils parvenaient sans trop de difficultés à gérer tout l'affichage d'un platformer 2D à coup de polygones sur la DS.

Bug! (1996) Saturn / PC

Given how natural "big level objects" are in 3D engines and how hackish they are in tiled-based engines, I wanted to give a second chance to the all-in-3D option. I know some homebrewers have succesfully walked to path opposite to that of New Super Mario Bros: sprite entities in 3D worlds that actually render 2.5D. Don't let yourself fooled: it's a tempting trip since the first screenshots of Bug! got printed in my favourite PC magazine.

A second tempting trait is that a 2.5D setup can make the "goal" of a level as clear as Journey's mountain. In a pure 2D platformer, you don't see where you're heading, hence the "walk to the right" stereotype.

Bon, je me suis laissé dire que les calculs pour que les graphismes tombent justes sont assez dégueulasses, ce qui a plutôt tendance à me refroidir.

Mais bon, en 1996, j'étais séduit par l'approche de la 3D par le jeu Bug! (en fin, au moins sur photo dans les magazines). Et depuis Journey, je dois reconnaître que voir dans l'arrière-plan l'objectif à atteindre, c'est une manière intéressante de travailler, tout en proposant un déplacement latéral pour les phases de plate-formes plus exigeantes. Sans doute que si j'avais vu la réalisation de Hercules, j'aurais poussé l'idée plus loin.

Donc, supposons que ... Qu'est-ce qu'elle a dans le ventre, la bête ? 2048 triangles. Ou 1024 quadrilatères (oui, on peut alimenter le chip 3D soit en triangles, soit en quads). Si on donnait un quad par tile à l'écran, il ne resterait plus que 256 polygones pour faire les personnages ou les particules. Pas énorme.

Fuzed by Relminator

One clear drawback is that the computations to get it right are ugly. Everybody who's been trying to do pixel art in Unity eventually says so, and I have no reason to believe it would be otherwise with NDS hardware. I don't mean the maths behind 3D projections here, but the setup to ensure that pixels got rendered as they are intended to, with one cell in memory exactly matching one cell on-screen.

But nonetheless, I looked up the "manuals". The NDS can render 2048 triangles or 1024 quads. That's 130% of  the number of 8x8 pixels tiles I've got on one _plane_ per screen. No doubt that if I go the 2.5D-with-GL path, I'll have to design levels with coarser objects (maybe not as coarse as Relminator's 32x32 pixels cubes), but thinking of some extra quads so that things are effectively 3D and not all flat might be necessary.

Now, to be honest, I don't really see Bilou fitting a cubical world like the one seen in Fuzed (or in Lemmings 3D), nor a origami-like world à la Mario 64. I gave that a try back in the Deluxe Paint days. Picking my best 'dirt' picture and soft-render it like if it was a Wolfenstein view. And to be honest, Badman 3 story that was rendered in a similar way look gorgeous in comparison.

Du coup, je m'attends à devoir travailler avec des objets plus larges, un peu comme ces cubes de 32x32 pixels comme on les voyaient dans le jeu "Fuzed" de Relminator. Là, avec un bon moteur on aurait 3 quads par bloc (5 avec un moteur minimaliste), et je compte un maximum de 62 cubes visibles à l'écran (donc 180 à 300 quads sur les 1024)

Bien sûr, si je veux aussi montrer une deuxième "couche", plus éloignées, les cubes seront plus petits, et donc plus nombreux.

3D made with Deluxe Paint for Badman.

Maintenant, il faut bien admettre un truc: ce genre d'esthétique toute cubique, ça n'a jamais vraiment été mon trip. J'avais fait un essai avec la fonction 'projeter une brush en 3D' de Deluxe Paint aux alentours de 1998 avec ma meilleure "texture" de terre pour refaire la cachette dans les racines de l'arbre creux de la green zone, et c'était pathétiquement catastrophique. Ça pourrait marcher un peu mieux avec la School Zone ou la pyramide, mais on devrait partir sur une esthétique plus proche de Phantom Hourglass (qui ne m'a jamais vraiment séduite non plus).

Bref, faute d'élément motivant, je reste gentiment avec mes p'tits tiles et mes p'tits sprites.

that would be 1024 quads. So we can fill the screen with 32x32 pseudo-tile and we'd have saturated the 3D pipeline of the NDS.

(cf. https://github.com/AntonioND/nitro-engine)

Intrepid Izzy

 Bon, je vais devoir présenter d'avance des excuses au Senile Team: Intrepid Izzy n'est pas franchement un jeu dont j'attends la sortie. Ne vous méprenez pas, hein: ça a l'air plutôt bien fait, en plus c'est prévu pour être un homebrew dreamcast et c'est un jeu de plate-forme. Ils font même des vidéo devlog et ils ont même un blog. Donc, en fait, je devrais être fan de leur travail. Mais voilà: je n'y arrive pas.

Il y a un quelque-chose dans l'animation du personnage que j'assimile à l'époque des jeux flash, qui trouve aussi des échos dans certains choix artistiques comme les contours noirs autour de l'herbe ou les fleurs à la tige raide comme une baguette. Le fait d'avoir choisi une caisse en bois comme objet à pousser dans le temple perdu ...

I guess I should have expected it. See, there are people doing homebrew on 32-bit Dreamcast console. Although we're at the border between homebrew and indie here, with Senile Team envisioning Steams sales in addition to a SEGA homebrew.

There's a good deal of qualities in that ongoing development platformer, that's un-deniable. Unfortunately, while checking the videos, I fail to get that excitement that Giana: twisted dreams or Ziggy triggered. I don't feel like detailing the why. They aren't really flaws, just mismatch of tastes, I presume. I could summarize by saying that the look reminds me of Flash animations, and I've never really been a fan of flash games. But they have nice art, including art in the desert. And All platformer references showing desert environment without going for super-cliché Egyptian Pyramid is welcome for my own Desert Zone ...

 Je sais, c'est peu de choses par rapport au travail fourni et indéniable (regardez-moi ces rochers et ces sapins!). C'est bien pour ça que j'ai passé le truc sous silence jusque-là: le projet mérite qu'on le soutienne, pas qu'on en critique les petits détails perfectibles.

Alors pourquoi en parler maintenant ? Eh bien à cause de leurs couleurs pour l'environnement "temple/pyramide", évidemment!

#300030 + #5c2744 pour le mauve sombre dans la partie "morte" du niveau,

#532041 + #6d3046 + #5b2a39 + #915c51 pour les blocs servant de décor de fond à l'intérieur du temple, 

#ffc463 + #ce9362 + #7b4251 pour les blocs "solides" dans le décor.

Je continue à caler sur la conception de la zone du désert pour mon prochain jeu Bilou et quelques couleurs à essayer ne feraient probablement pas de tort.

Early DS homebrew moments.

When I started considering doing homebrew on the Nintendo DS, the hardware used by hackers was pretty unconvenient to bring in a sofa. For years, I've kept those pictures around found on website such as http://natrium42.xyz/ or https://www.darkfader.net/ds/, two websites where people pushing the limits of homebrewing were exchanging information and achievements.

But I must admit, I was merely considering doing GBA homebrew on NDS, by then. I wanted to keep things simple. And to some extent, I still want, which is one of the reason why, in 2020, I still haven't started doing homebrew on any other system, unlike most former NDS homebrewers.

There's a much better coverage of the era in Modern Vintage Gamer's video (2019) (reached from Retro Reversing)

The hack on the first picture shows how to extend GBA device with mass storage through a IDE cable and a (portable, enclosed) hard disk. The first devices allowing to run DS homebrew software (not only GBA homebrew) was only half less chunky. To be able to do so, the PassMe device had to relay requests for signed headers to a genuine NDS cart plugged at the rear of the console while it was itself inserted in the slot 1 of the console. That sort of thing works fine on a 16-bit home console, like a game genie / Sonick & Knuckles like monster, but for a handheld, I'd have been constantly fearing to lose a part or break it.

The remaining alternative wasn't very appealing either, as it required you to flash the firmware of the console with one that would have a menu for browsing homebrews on GBA flash cart (iirc) and bypass copyprotection checks.

That involved bridging two testpoints (solder pads) together with a metallic device and keeping them in contact while you're flashing the ROM with new contents (don't remember how). Would you slip during the process, and you might end up with a bricked device that has incomplete firmware. 

Well, it turned out that I eventually started doing NDS homebrews running in emulators before I started doing GBA homebrews and that by the time I decided to purchase something doing GBA homebrew, 'passcard' were small enough to fit a slot 1.

Oh, and by the way, I just discovered someone made a top 5 best homebrew apps last month. When you see that they are youtube 4 DS, Yahoo messenger for DS, an MP3 player and a text editor disguised as WintenDoS, it shouldn't be a surprise why homebrew consumers turned to smartphones as soon as smartphones became cheap enough.

Happy new year, too.

Bonjour Stravingo

Je vous ai déjà un peu parlé de Stravingo, un développeur de homebrew avec qui j'avais eu quelques contacts du côté de 2007. Il a lancé un nouveau site web ces derniers temps, l'occasion de le retrouver et de lui poser quelques questions.

Voilà, donc. Est-ce que tu peux nous raconter comment tu as découvert la programmation homebrew ? Et à quelle époque de ta vie as-tu fait tes premiers pas sur DS ?

En fait, je suis tombé dans la programmation depuis tout petit, vers l'âge de 10 ans au début des années 80, grâce à un ZX81 gagné par mes parents à un concours organisé par un supermarché. C'était les débuts de la micro-informatique, rare étaient les gens qui avaient un ordinateur chez eux. Mais cette petite machine à l'affichage monochrome dotée de 1Ko de RAM a complètement orienté ma destinée et m'a permis de découvrir ce que je souhaitai faire plus tard. J'ai commencé à programmer très tôt, car à l'époque il était difficile de se procurer des cassettes de jeux pour cette machine.

J'ai en revanche eu des livres et des magazines expliquant la programmation en basic et donnant des listings d'exemples. J'ai donc dû pour jouer recopier ces exemples, parfois les relire pour trouver des erreurs de recopie occasionnant des bugs, appris peu à peu à les modifier puis à créer à partir de zéro mes premiers programmes. J'ai ainsi appris tout seul à programmer, en tâtonnant avec les ressources de l'époque. Mes premiers véritables cours en informatique, je ne les ai eu qu'à la fac 10 ans plus tard !

Entre temps j'ai eu d'autres ordinateurs, un ZX Spectrum donné par un oncle féru d'informatique qui m'a permis d'afficher mes premiers pixels en couleur (quelle émotion, encore maintenant), puis un Atari STE qui a redonné un coup de fouet à ma passion pour l'informatique. C'était pour moi une révolution, sonore et visuelle ! J'ai beaucoup joué dessus, mais aussi beaucoup codé. Toujours en Basic grâce à l'excellentissime GFA Basic, mais c'est aussi là que j'ai découvert l'assembleur et le langage C.

Le même GFA BASIC qui avait été utilisé par Eric Chahi pour développer les outils de son "Another World", si ma mémoire est bonne. Mais légèrement plus jeune qu'Eric ou Michel Ancel (qui avait aussi commencé sur ZX81?) si je calcule bien. Avais-tu déjà essayer de programmer sur une autre console (avant la DS) ou sur un autre appareil embarqué avant ? Avais-tu fais de la programmation PC ?

 C'était l'époque où le monde vidéoludique se partageait en 4 : l'arcade, les consoles, les Atari/Amiga, et les PC. Les Mac étaient dans une dimension un peu parallèle. Personne parmi mes connaissances n'avait de console ou de PC, mais j'en suivais l'actualité avec émerveillement dans les pages du regretté magazine TILT. Je voyais bien que les Super NES, Megadrive et autres PC Engine tenaient la dragée haute à l'Atari (je n'entrerai pas dans la polémique Atari/Amiga), mais le monde de la console ne m'interessait pas à l'époque, car une machine sans clavier qui ne permettait que de jouer ne me disait rien.

C'était la programmation qui m'attirait avant tout. Mais pas forcément pour développer des jeux. Ce que j'aime dans la programmation, c'est la possibilité de créer. Toutes sortes de choses. C'est un outil qui permet de créer et c'est ça en fait que j'aime avant tout, et pas forcément que dans le domaine de l'informatique.

Marrant... de mon côté, il y avait beaucoup de PC, quelques consoles 16-bit et quelques Amigas parmi les potes rencontrés après mes 15 ans. Pour jouer sur Amiga, il fallait une autorisation parentale et prendre deux bus. Et personne n'avait pris d'Atari.

Puis ça a été l'hégémonie du PC et les machines 16/32 bits ont laissé leur place. Un âge d'or à mon sens a disparu et j'en garde la nostalgie. Celle où deux potes peuvent faire un jeu dans leur garage. C'est ce qui est revenu avec l'esprit du homebrew et qui me plait. J'ai eu de nombreux PC, mais je crois que je ne me suis toujours pas remis de pouvoir afficher 256 couleurs simultanément avec une carte VGA. Merci Sylvain de me permettre de faire cette thérapie 😉 J'ai continuer à coder, sur PC et sur Mac, et j'en ai même fait mon métier 🙂

Mais pour ce qui est des consoles, c'est un monde dans lequel je n'ai mis les pieds que très tardivement ! J'ai acheté ma première Nintendo DS en 2007, mais très rapidement j'ai cherché un moyen de la programmer et c'est là que j'ai découvert de monde du homebrew et de ses kits de développement amateurs. 

Ca m'a tout de suite plu, car la petite bestiole aux deux écrans a bien des charmes et des possibilités techniques que j'ai cherché à expérimenter au travers de la réalisation de jeux (Ka-Boom, Setsuzoku no Puzzle) et d'utilitaires (DS Weather Report, Treasures of Gaia, Miniville DS Manager, Secret Hordes) et de quantité de projets plus ou moins esquissés. J'ai aussi découvert une communauté très active de développement amateur sur Nintendo DS, en particulier française sur un site web hélas maintenant disparu, dev-fr.org. C'est cet esprit de communauté que j'aime beaucoup dans le monde du homebrew, avec son esprit d'entraide, d'apport d'outils, de vision critique.

Une disparition que je regrette aussi, évidemment. On retrouve certains anciens sur twitter, de temps en temps, mais ce n'est plus la même chose.

L'autre console que j'ai acheté, c'est cette année, une gameboy FAT première génération de 1989. Avant tout pour le côté icônique, la nostalgie d'une époque, la beauté de son design. Mais on ne se refait pas, le côté programmeur a vite pris le dessus. J'ai acheté une cartouche avec mémoire flash, je me suis interessé aux possibilités de développement, et je viens de sortir mon premier essai de programme, Kalimboy, permettant d'utiliser la Gameboy comme kalimba, le "piano à pouces" africain 🙂

Intéressant. Je me demande si ça fonctionne aussi avec une cartouche programmable avec carte micro-SD ...

Sinon, en matière d'appareil embarqué, j'ai réalisé des applis sur smartphone et iPad, sur Arduino, sur Raspberry Pi et aussi sur une pédale d'effets pour guitare programmable ! En fait, ce que j'aime, c'est la diversité, explorer de nouveaux champs d'expression via la programmation, expérimenter de nouvelles plateformes, pas forcément récentes. D'ailleurs la programmation sur Super NES et sur Megadrive me tente bien 😉

Je te comprends ^_^

Yo Yo Shuriken par Dr. Ludos

Un p'tit coin de web bien sympa, où Dr. Ludos nous raconte l'aventure de son homebrew SuperNES: "Yo-yo Shuriken". On est dans un jeu de type 'arcade / clean-them-all' qui n'est pas sans rappeler les ambitions simples d'Apple Assault.

Le jeu est orienté autour d'un mécanisme qui titillait Dr. Ludos depuis un bon moment: un jeu de tir où on a droit qu'à un seul projectile. Après quelques essais où il faut aller récupérer son shuriken en bordure d'écran, Dr. lui ajoute un mode boomerang et le sort du cyber-ninja est scellé: il se fait voler la vedette par son shuriken. Le voilà condamné à une éternité d'anonymat.

Somehow, I ended up discovering Dr. Ludos's web page where the development of his SuperNES homebrew title was revealed. The game is an arcade-inspired clean-them-all title that may remind you of my own Apple Assault attempt.

The unexpected twist in the gameplay design is to make a shooter game where you have only one bullet, so you have to wait to get it back before you can shoot again. 

En plus de nous raconter la genèse et le développement de son jeu, Dr. Ludos nous parle aussi du développement pour SNES version 2020.

I used [PVSNESlib] to make Yo-Yo Shuriken, so I could code it in C language. For graphics, I drew BMP images that were converted to the SNES graphics format. For audio the framework accepted wav files for sound effects and .it files (Impulse Tacker format) for music. It was still quite a challenge to make a game running on the SNES, but PVSNESlib made it a "hard but fun challenge"!

PVSNESlib, c'est le travail de papy Alekmaul, un ancien de dev-fr qui a embrayé sur les consoles 16 bits une fois que la fièvre des DS est retombée. On lui doit des portages de jeux Amiga, un assez sympathique jeu de puzzle (qui avait fait parler de lui à une compo, si ma mémoire est bonne) et la partie technique de Sidney Hunter, un homebrew original dans la veine de Rick Dangerous.

In the end, even if you use a tool like PVSNESLib, you'll need to be familiar with how the SNES works in order to make actual games for it. Hopefully the wonderful homebrew community have consolidated some very extensive documentation. I'll recommend:

• The PVSNESLib wiki, that will guide you on how to set up the tools and how to make simple SNES programs: https://github.com/alekmaul/pvsneslib/wiki
• The NoCash SNES specs (technical, but thorough) https://problemkaputt.de/fullsnes.htm
• The SNESdev section of the NESdev forum: https://forums.nesdev.com/viewforum.php?f=12
  The community is very helpful and skilled. They saved my life more than once when I was making Yo-Yo Shuriken!

Pour ma part, je n'ai pas encore commencé le développement sur SNES, mais j'aimerais que mon prochain jeu ("Bilou's Dreamland") puisse envisager un portage sur la reine des 16-bits. Je vais donc garder bien au chaud les recommandations de Dr. Ludos. Mais ce ne sera pas simple partant avec 80 ennemis à l'écran (hors des 128 possibles pour le hardware) pour ses premiers tests, Dr. Ludos doit redescendre à 40 une fois les tests de collisions ajoutés (pour tenir les 60fps), puis de nouveau à 24 pour prendre en charge un deuxième joueur et la gestion de la musique. Soit un total de 38 sprites si on compte aussi les joueurs, leurs shurikens et les explosions.

I could be tempted to compare the game to the Berzerk! title of the vectrex era, but instead of adding walls and a labyrinth, Dr. went for more ennemy types and boss fights.

What's quite interesting is that Dr. Ludos also explain how, with 2020 tools, he developped a new SNES homebrew title, using libraries developped by former users of the dev-fr forum. I haven't started SNES development myself, but that's something I'd love to think possible, maybe with my next title, although it won't be easy.

 

Dr. Ludos started with 80 baddies on screen (out of 128 allowed hardware sprites per frame), but he had to get down to 40 as soon as collision tests were added, then down to 24 when adding a second player, and music, for a grand total of 38 sprites on-screen including shurikens and blasts. And yet, this was only made possible by moving baddies only every other frame, running collision checks on the odd frames.

Il va devoir malgré tout ruser un peu, comme convenu avec ce genre de machines: contrairement au joueur, les ennemis ne seront déplacés qu'une frame sur 2, ce qui permet d'étaler les tests de collisions sur 2 frames. (Curieux de voir ce que PVSnesLib a dans le ventre pour gérer ça, tiens ...) Il va falloir équilibrer ça avec le temps de mise à jour disponible pendant la période de VBlank, aussi -- seul moment où on peut faire une mise à jour de la mémoire graphique sur la SNES -- faute de quoi certains éléments graphiques seront tout simplement manquants à l'écran.

Mais Dr. Ludos ne s'est pas arrêté à faire une ROM de son jeu. Il nous fait la totale, avec une boîte, un manuel et une cartouche physique soudée à la main! Amis amateurs de tubes cathodiques, vous voilà avertis ...

Amy Zing

It only took Ant a few days to include my little "Amy Zing" sprites into his neat labyrinth crawler homebrew, actually. For some reason, I completely missed it by then (March '18) and only realised that the game was released thanks to some anonymous internet folk who followed a link from simian zombie web site to mine, leaving a mark into the logging system which I tracked backwards to hit the page with the release.

So I grabbed the game, enjoyed it, enjoyed again, tried the various resolutions (normal is my favourite one) and smiled: that was my first ever homebrew collab as a spriter ^_^. And then started to wonder... Could such simple labyrinths work for Bilou, under gravity ?

I traced some of them in a notebook and started to check where I would put collectibles or hazards and why. In a platformer, you shouldn't (imho) try to make your labyrinth with individual blocks, because the player will need some room to manoeuver. If I pick 4x3 Bilou-sized blocks as a "maze cell" (3 blocks being a standard jump height), the maze now scrolls over 4x3 screens. You can no longer plan your move easily with that limited visibility, so you'll end up more often in dead ends and will have to back-track. Hence the rewards and hazards.

And well, Imho, with properly tuned jump distances and some wall-kick mechanics, you might not even need fancy ladders or similar tricks to support those labyrinths.

That's not quite "infinite pyramid", but it could be a nice step towards it.

edit: good news: my 5-year-old J.L.N wasn't afraid of the half-dead monkey and accepted the maze game as something to do when he's bored.

Les Homebrew de 2015 -- driven to insanity

Je peux difficilement me plaindre que mon "School Rush" reste dans l'ombre si, tout équippé pour le homebrew comme je le suis, je ne jette pas un seul regard au travail des autres. J'avoue que d'emblée les titres parus en 2015 sur Nintendomax ne sont pas du genre à m'attirer. Ils ont aussi été presque tous réalisés en Lua-sur-DS ou avec DS game maker, donc peu d'intérêt de programmeur ... mais laissons ces préjugés au placard, sortons hbmenu.nds (ils nécessitent le nouveau protocole "argv" qui n'est pas supporté de base par mon linker de bisounours) et regardons ça de plus près.

I am not the only one to make homebrew content for the Nintendo DS, even in 2015. The DS Game Maker still receives new game now and then, relayed on NintendoMax. Not the kind of projects that appeal me, but if *I* don't pay attention to others' work, why would others' pay attention to mine ?

I started with "driven to insanity", a board game for 3 players developed by Mumpyboor when he was 12. I mostly complain that you cannot learn the goal of the game by running the game. Either you guess it (I guessed I must go to any "goal" and then back to the start) or you open readme.txt... There are health status to take care of, room for strategy, chance events... it could be worth somewhat better graphics but things remain readable. Yet, I don't think I'll run it ever again, not without english-speaking kids around to play it. I hope the more recent humour-driven game by Mumpyboor will please me more.

Je commence par "driven to insanity" (mumpyboor, janvier). Un jeu de plateau converti sur DS à jouer avec deux comparse. Il y a des cartes chances, il faut prendre soin de votre bus et de votre santé. On dirait qu'il faut passer à un des "goal" puis retourner au point de départ un nombre suffisant de fois pour remporter la partie, mais le jeu manque un peu d'explications sur ce point.

La réalisation est un peu élémentaire mais sans être désagréable pour autant. Une bonne entrée en matière pour un développeur qui avait 12 ans à l'époque. J'espère que "jihad au mont Olympe" du même auteur sera plus intéressant. Là, c'est vraiment pour l'article que j'ai continué à trainer mes 3 bus jusqu'à un marquer un point. Je dirais bien "ce sera pour amuser les enfants", mais en anglais, ça ne marchera pas sans moi.

See you, bloggers.

With dev-scene.com dropped, dev-fr crashed, google reader turned off and the DS celebrating its 10 years, my RSS feeds list has shrunk to the point it is no longer worth checking. I wished to thanks their author for the nice ideas shared between 2005 and 2012 (mostly).

J'ai beaucoup aimé les années blog, que je situeraient de 2005 à 2010. J'ai beaucoup aimé l'ambiance bon enfant de dev-fr jusqu'à ce que l'engouement pour les iPhones ne le dépeuple et qu'un Androïd ne lui donne le coup de grâce. Je suivais les développement des uns et des autres via Google Reader grâce à la magie des RSS. Je laissais des commentaires et j'en recevais quelques-uns en retour. Tout celà est loin maintenant. Les blogs sont au mieux alimentés d'un "je ne suis pas mort" annuel. Au pire, leur adresse a été vampirisée par un quelconque annonceur sans scrupule. Petit message de sympathie à mes correspondants de l'époque.

0xtob is the author of NTXM library and nitrotracker for Nintendo DS. I owe him a lot -- including a patch featuring my upgrades to his player. His work has now moved to code.google.com. His blog is gone, his homepage is still there.

Je commence par 0xtob, à qui je dois la base du son dans mes homebrew. Je lui dois d'ailleurs toujours un rétro-portage de mon code pour les effets (vibrato, etc) dans sa nouvelle architecture... Le blog est mort. La page d'accueil lui a survécu. Le code aussi. J'aurais dû regarder de plus près à son moteur physique, peut-être ?


Squidi had the Grand project of describing 300 game mechanics. One a day, iirc. He went quite far away, around 160 mechanics, and even started implementing examples in HTML5. I think the archive.org is the only way to consult content he wrote.

Il n'y avait pas que des homebrew dans mes flux RSS, mais aussi les nouvelles idées très chouette de règles de jeu. Il s'était fixé l'objectif de 300 règles, il est arrivé au résultat très honorable de 160. Bien mieux que le catalogue des Jeux Vidéos Obsolètes.

Sverx doesn't post much anymore, but he's still into homebrewing. Mostly moved to SEGA mastersystem tools/libraries and posting code on github.

Les petits jeux de Sverx étaient bien agréables. Ses conseils de baroudeur des consoles Nintendo Précieux. Il est maintenant passé à une bibliothèque pour la Master System de SEGA. Github semble être suffisant par rapport à un blog puisqu'il n'y met plus qu'un bonjour par an.

J'adorais les mini-jeux de Mia. Lui a continué à blogger de temps en temps, et son blog est toujours actif. Comme de nombreux homebrewers' Mia est passé au jeux Androïd, mais malheureusement avec de "simples" jeux de cartes. Peut-être celà représente-t'il un vieux challenge à vaincre pour lui ?

Last but not least, I'd like to greet Mia and thank him for his inspiring little games on Nintendo DS. He switched to Androïd, like many other french homebrewers. It's a bit of a pity that he decided to make only plain card games. I know he used to rip nintendo graphics because he had no own characters for his games. Maybe that's still missing for him ? Maybe he doesn't know about Open Game Art ?

And then, there are those who haven't gave up. I'm impressed at how Smealum (previously releasing Aperture Science for DS and the first DS minecraft clone) makes progress towards a full understanding of the 3DS, and it looks like there is now a growing community of 3DS software homebrewers, reaching the state where a clone-of-moonshell is being crafted. So far, what I want to do fits the NDS alone, I haven't found any way to push homebrew to my own DS (I'm often lacking the game to exploit) nor did I started investigating what others have done / found on that newer hardware,  but maybe that would be the best way to quit that feeling of being a lomesone cowboy lost in the deserts of NDS homebrew...

Oh ... et pendant ce temps-là, Zalo nous sort quelques tutoriels 3DS et une reprise de Jumping Jack sur son blog ^_^

Programmation GBA dans Login 92

 J'aimais vraiment bien le magazine Login:, bien plus riche que tous les Linux Mag' sur lesquels j'ai pu mettre la main. Romain Guy y signera une série d'articles, sur la programmation GBA début 2002. Un an trop tard pour moi, malheureusement: je suis à fond dans la construction de Clicker avec une demi-douzaine de collaborateurs potentiels, et en passe de devenir modérateur sur le forum Mega-Tokyo.

We never had a great collection of programming magazines in Belgium, unless you read German fluently and live in the eastern cities, I mean. But in the later years of my university studies, I had a stable dealer of "Login:" (and earlier Dream) magazine, covering a wide variety of open source, coding, and chip vendors news. I thought the blog would be a nice place to write a tribute post to Romain Guy's work, for instance his series about homebrew GBA programming. That arrived one year after I considered the option of re-creating Bilou's Adventure on that platform, and after we received a cold reply from Nintendo explaining their requirements for allowing a company to get an SDK.

Beside the relative complexity of the GBA platform -- where you had to manually decide whether to use Thumb instructions, and with very small RAM for code and data with the need to decide which part of your code would migrate from ROM to RAM to meet real-time constraints -- homebrew hardware was still quite repellent, with cartridges having internal flash, rather than using standard media cards, and requiring dedicated programming devices ... I dropped the idea and pursued my research on Operating Systems instead ...

Il y a aussi le côté "lourd" des équippements nécessaires pour programmer les cartes. La miniaturisation de la SuperCard n'a pas encore été atteinte ... ou peut-être les carte SD n'étaient elles pas encore assez répandues. Toujours est-il qu'on se retrouvera avec une cartouche unique, avec une certaine quantité de mémoire flash embarquée et une espèce de périphérique dédié à connecter sur PC pour réécrire le contenu de la mémoire embarquée. Mais tout ça est gros. Pas aussi lourd que la version "on sort un cable ATA pour se repiquer sur un micro disque dur clipsé sous la console", mais le côté "console portable" disparaît.