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

Crappy Debbie WiFi

Bad luck, I've got unreliable WiFi with the new distro: every now and then a web page will get stuck while loading. When they're not, they're taking age to complete. If I ping, I don't see "network unreachable", but I see the pings struggling, the resovled name changing, sometimes even switching from IPv6 to IPv4. So I went for a monitoring of dmesg -w and I spot events like

[13390.293505] wlp2s0: disconnect from AP e4:bf:xx:xx:xx:50 for new auth to e4:bf:xx:xx:xx:48
[13390.332410] wlp2s0: authenticate with e4:bf:xx:xx:xx:48
[13390.332455] wlp2s0: 80 MHz not supported, disabling VHT
[13390.379300] wlp2s0: send auth to e4:bf:xx:xx:xx:48 (try 1/3)
[13390.382294] wlp2s0: authenticated
[13390.385211] wlp2s0: associate with e4:bf:xx:xx:xx:48 (try 1/3)
[13390.396102] wlp2s0: RX ReassocResp from e4:bf:xx:xx:xx:48 (capab=0x1411 status=0 aid=3)
[13390.400601] wlp2s0: associated
[13390.414136] wlp2s0: Limiting TX power to 20 (20 - 0) dBm as advertised by e4:bf:xx:xx:xx:48
[13411.113702] wlp2s0: disconnect from AP e4:bf:xx:xx:xx:48 for new auth to e4:bf:xx:xx:xx:50

Every 20-30 seconds. They match the struggles of ping.

Now, there are posts about how to handle frequent disconnections, and I wish they weren't so often behind cookie walls, so I could scan through them more easily. The link mentioned would offer little to no help. "Have you tried switching to networkd+resolved instead of NetworkManager ?" ... eh ... I'd rather leave that untouched if I can. See, it's not a whole new system: a decade-old ubuntu was able to use that same WiFi chip reliably.

if I watch iwconfig, I can see Bit Rate ramping up after a disconnect, then reach a certain point (around 100Mb/s) and then we disconnect and are back to a few Mb/s again. Yet, sudo iw dev wlp2s0 set bitrates legacy-2.4 48 36 24 18 12 9 6 does not seem to help ... Of course: ramping up bit rate is not the cause of the issue, it's a consequence of network being disconnected: it has to slowly re-establish connection every 30 seconds.

I'd like to say that I've found a blog post that proposed me to check nm-connection-editor and change "band auto" into "band B/G (2.4GHz). I'd like to say I've got a colleague explaining that pointed out it would have no effect until I manually systemctl restart NetworkManager.service, no matter whether I clicked "save" button on that settings window. Truth is this has been suggested (among many other useless things) by the rubber duck, again.

Now that it's fixed and that I read those dmesg lines again, I spot how there were *2* MAC addresses competing, and my computer would hop from one to another. Likely I could have saved myself trouble by disabling either band on the access point settings, but that may have affected phones of my relatives.

NUC en maintenance...

Mon beau-frère a beau trouver que je le sous-exploite, ces 2 mois sans accès à mon NUC auront été douloureux. C'est qu'après le passage du technicien WiFi, il n'était plus sur le bon réseau (le gars m'ayant mis un SSID tout en MAJUSCULEs. Eh oui). Et avec d'autres paramètres de sécurité.

Et le truc, c'est que depuis son installation d'origine, le NUC était en mode "cube numérique dans son coin douillet à côté de la chaîne HiFi". soit je communiquais avec par SSH, soit par un p'tit service web perso pour trier les playlists au fur et à mesure qu'on les joue, que ce soit par tablette, laptop ou smartphone-de-ma-fée.

Pour une raison inconnue, les gars de chez Intel ont pensé qu'une prise HDMI n'aurait pas tenu sur la face multimédia de l'engin et donc j'avais un câble mini-HDMI <-> HDMI au chaud dans un tiroir et un adaptateur miniHDMI:M->HDMI:F qui m'avait servi lors du setup initial sur le setup Raspberry de mon filleul. J'avais d'ailleurs racheté le même adaptateur HDMI->VGA que lui (on le voit sur la droite de la photo).

Fort heureusement, j'ai aussi chez moi un apparail auquel j'ai programmé un mode "forward HDMI". Je peux donc y faire passer mon signal pour éviter de devoir brancher deux câbles HDMIs l'un avec l'autre.

sudo modprobe zd1201 ap=1 # /etc/modprobe.d/wlan did not seemed to have effect before reboot.
sudo iwconfig enx00cafe00babe essid "bilou"
sudo ifconfig enx00cafe00babe 192.168.7.1 netmask 255.255.255.0
sudo vim /etc/udhcpd.conf # fix 'interface', 'start' and 'end'.
sudo vim /etc/default/udhcpd # set DHCPD_ENABLED
sudo touch /var/lib/misc/udhcpd.leases
sudo service udhcpd reload
sudo service udhcpd restart

Et *enfin*, mes consoles DS ont pu recevoir une addresse IPv4 et transférer des fichiers vers/depuis le NUC avec server.pl et sink.pl... Par contre, pa encore moyen de faire les mises à jour automatique (de runMe, qui devrait recevoir son nouveau mécanisme de rapport de iScriptException) parce que ils ont été configurés pour contacter 192.168.0.11 et rien d'autre.

Donc on va commencer par ajuster EXTRAFLAGS et recompiler tout ça ...

• [done] /etc/modprobe.d/wlan.conf instead of /etc/modprobe.d/wlan allowed ap=1 to be auto-assigned
• [todo] trying to reload the module while stick is plugged in fails to upload firmware with ETIMEDOUT (-110) errcode
• [done] wireless_essid under iface enx00cafe00babe inet in /etc/network/interfaces allows to define SSID properly.
• [done] I had to manually ifup enx00cafe00babe until the interface was added to the auto list of /etc/network/interfaces
• [done] using Ubuntu HWE allowed the TPLink USB stick to be supported on my laptop
• [done] nmcli dev wifi connect "bilou" ifname wlx00deca00fbad let my laptop connect to the bilou wifi as well.
• [todo] looks like nmcli has to be re-done when I plug the TPLink stick again...
• [todo] uploading purposely buggy greent.cmd could trigger the PatchWindow, but J.L.N's level still produces a *** cannot parse line*** diagnose halt instead.

Il est où le wifi ?

Le portail Wifi qui nous connectait au monde de Bilou s'est effondré. Les forces de l'empire Télétravail ont fait intrusion, entendant stabiliser leur hyper-tunnel privé sécurisé contre les fluctuations de l'étoile 192.168.0.24. Résultat, tout le système stellaire a été basculé en WPA alors que l'astro-cruiser ne peut communiquer qu'en WEP.

J'avais envoyé sur place ma sonde ZD1201 qui m'avait déjà tiré d'affaire quelques fois, mais si la DS peut bien voir le nouveau réseau, par contre, je n'ai pas encore réussi à m'y connecter. Echec à la première tentative. Freeze de la DS à la seconde (dans runMe). Serait-ce lié au fait que je n'ai pas su définir de clé WEP pour le nouveau réseau ?

Je n'ai plus le concierge-Mario Kart, mais j'ai un menu de configuration wifi dans Phantom Hourglass ... qui ne fait guère mieux. Le pilote est maintenant maintenu par les gens du Noyau et son firmware est pré-distribué par la Fédération Ubuntu.

The WorkFromHome Empire has struck hard the WiFi portal that allowed me to communicate with Bilou and Bouli. I had to accept a new modem/router device so that their secured hyper-tunnel would get shielded against pulstar 192.168.0.24, but the result is that the whole stellar system now has to use WPA instead of WEP. And unfortunately, the DeepSpace cruiser of Bilou and Bouli only communicates over WEP.

I hopefully managed to recover my ZD1201 probe and dispatch it in the quadrant. It had proven effective to recover WiFi portals a couple of times already. The good news is that it is now part of Ubuntu Federation and their Kernel Teams' standard tools. It was quite trivial to confirm that the probe was accepted as an access point by the DeepSpace cruiser. Getting it in sync with that access point proved more complicated.

Wireshark restait muet. Ce n'est pas surprenant: si les paramètres de chiffrement sont incorrects, le stick wifi ne reconnaîtra pas les ondes comme étant un paquet pour lui et ne passera rien à la pile réseau Linux.

Mais ça c'était hier. Je viens de refaire un essai avec la tablette de ma fée d'abord, puis à nouveau avec Phantom Hourglass et je vois enfin des requêtes DHCP dans wireshark. Dont une avec une adresse MAC de chez Nintendo. Tout espoir n'est donc pas perdu.

Par contre, le logiciel que j'avais utilisé à l'époque pour le DHCP n'est plus distribué par Ubuntu qui lui a préféré UDHCPD, l'implémentation interne à BusyBox (dont il faudra que je vous reparle). Donc,

# The interface that udhcpd will use
interface enx00cafe00babe # default: eth0

devrait me permettre d'être serveur DHCP sur le stick wifi (à l'adresse MAC improbable 00:ca:fe:00:ba:be) tout en restant client sur les autres.

J'avais tenté d'utiliser une adresse statique hier, évidemment, mais sans succès. Au moindre test de connexion, le logiciel WFC sur la DS me lâchait juste un "paramètres incorrects". En réalité, si on désactive les requêtes DHCP sur la DS, il faut impérativement fournir *tous* les paramètres, y compris la passerelle à utiliser, le DNS, etc. j'ai probablement été un peu négligent là-dessus.

Running a similar test with my fairy's tablet proved it could be working, even without setting a WEP key (no clue how to define that with iwconfig properly, and not sure the ZD probe supports it). But if I try and use static IP address instead of configuring a DHCP server on the laptop attached to the probe, then I need to configure *all* the network parameter manually -- including Gateway and DNS -- else Phantom Hourglass' WFC manager would just shout "invalid parameters" and that's it.

So I finally got the MAC address of the Nintendo DS showing up in wireshark, proving that WEP handshaking worked. Now I'll have to find a way to mimmic the DHCP configuration I once used for udhcpd, the BusyBox-related tool Ubuntu Federation integrated to replace the legacy thing I knew. To be continued.

Affaire à suivre. Pourvu que nos héros tiennent bon.

Quand j'aurai pu vérifier que ça fonctionne, il me restera à créer une liste de règles iptables propres aux échanges avec les Nintendo DS (disons DSIN), y rediriger le traffic entrant venant d'une adresse MAC de NDS (/sbin/iptables -A INPUT -m mac --mac-source 00:0F:EA:91:04:08 -j DSIN) et jeter tout le reste qui vient de l'interface supplémentaire-et-non-protégée. (/sbin/iptables -A INPUT -i enx00cafe00babe -j DROP)

RunME needs a fix.

Mid-summer has been fairily hostile to game/tool development, unfortunately... I'm stuck on level editor progress because I can't easily ensure levels I edit are working properly, as RunME struggle to launch them. The best I could do while *deline was exploring the joy of the sea-side was some documentation of RunME so that the following fixes could be performed:

• [done] file/directory selection information should get its own space on top-screen
• [done] not only the FILE*, but also the extension name (file type) should be accesible from the L+A launcher button.
• [done] beam-in files in the last directory used for beam-out.  [todo] currently, only typing a new mask on the "alphanum keypad" will activate that directory.
• [todo] buttons (SEDS/edit) shouldn't overlap.
• [todo] ensure we can move back to SEDS/LEDS/download mode at all time.
• [done] don't try connecting when there's no sink on a given slot
• allow beam-out to be cancelled.
• [wish] global_connectAP and wfcWindow::autoconnect should belong to WiFi widget. 
• [done] IP address and [wish] SSID shown on the top screen once the connection is established.
• [wish] allow .spr files to become autoexec.spr even though they're too large to fit our 256K buffer.  
• [todo] spritesheet loaded with L+A in RAM should be able to display their colours, despite the "extra palettes" setup.
• [done] a way to try again the WFC connection settings from the "access point selection" list, as they may contain WEP keys, too.
• [wish] enter WEP key in AP selection list.  
• [wish] use Window.active flag if "clicking on other screen's button" is a bug rather than a feature.

^ UI/transfers -- level running v

• [done] fix the 'unregister XFER' loop bug.
• [done] proper cleanup when 'returning' to beaming activities from a test.
• [todo] avoid InspectorWidget/LoadingWindow interference (active areas not reacting anymore, beam-in offers cluttering the display)
• [done] report hero/ennemy/none class in InspectorWidget.
• [todo] control log display, clear and end-of-test from Inpector widget. 
• [think] special InspectorWidget display mode on (breakpoint collision), showing both colliding GOBs' state *before evaluation occurs*, with the ability to step to the next frame (after collision occurs)
• [done] double-check .spr and .xm loading support: no jamming allowed.
• [fix?] how could die() end up showing blank screens (when leaving the running game)?

That makes a NeoCompo entry very unlikely this year, unfortunately.
But at least, it gave me time to sit down and think about what mechanics could nicely complement JUMP in the full-blown adventure game.

post-trauma-edit: I just picked Surt's tileset I used for LEDS release 0.1 with the hope that I could use it to prepare a "tutorial map" and ship LEDS for NeoCompo ... result? I quite certainly screwed'up my school0.map (and will have to recover it from some git) with parts of the tuto map because I hadn't changed *that* filename in "tuto.cmd" ...
When I tried to save back the map under "tuto1.map", the map got all cleared ... Unfortunately, LEDS is not ready for shipping to the world and an extended 4-days week-end won't help even though I'd decide to invest all those free hours in a compo rush, I'm afraid.

runme is working with WEP ^_^

Bonne nouvelle: runme supporte maintenant le WEP, pourvu que le point d'accès ait été configuré avec un programme Nintendo officiel (Zelda: Phantom Hourglass, par exemple ;). C'était probablement déjà le cas depuis un moment, vu que je n'ai rien eu à changer dans le code pour que ce soit le cas, juste passer le nouveau modem de mon ISP en mode WEP (sauf erreur de ma part, la DS lite ne supporte pas WPA).

I bet it actually did support it for longer, but with my former WiFi router, I had no need to configure it. The newer one has only WPA or WEP mode, so I had no choice but giving it a try.

Welcome, libfat 1.0.9

While I was busy on a tons of things (including building up the first prototypes of AnimEDS) in february, Wintermute and his friends at devkitpro did a major revamp of the libfat, separating "what's good for the DS" from "what's good for the Wii". When it comes to mass storage performance, the two beasts are strongly different ... L1 cache, data transfer speeds, amount of L2 memory ... The release (1.0.7) I used in my "dkp-r32" setup tried (and failed) to provide a uniformised solution. I tried a few hacks that at some point looked to improve the performance, but didn't find the time to quantify the boost in a systemic way. I offered a patch, but ignoring the project's habbits made it doomed to /dev/null.

Hopefully, the new build seems to provide good performance again (PC->AP->DS transfer rates of 64-80KB/s at home).

Oh well, one annoying difference remain: i *have* to apply a DLDI patch manually for SCSD device (which used to have a built-in driver in former libfat). I also have an issue with directory scanning ... I hope it won't take too long to figure out what it is. it looks like I underestimated the MAX_FILENAME_LENGTH ... again ...

J'étais tellement à la bourre en février que j'ai complètement loupé la sortie de la version 1.0.9 de la libfat. Heureusement que je suis repassé jeter un oeil sur le forum de devkitpro après avoir tenté de refaire le point sur l'état du cache la semaine dernière, sinon j'aurais bêtement perdu plein de temps. Enfin, donc, une version qui traite la DS indépendamment de la Wii et de la gamecube, même si j'ai du ruser pour contourner les problèmes de __io_dsisd manquant et patchouiller mes programme pour m'ajuster à une augmentation de MAX_FILENAME_LENGTH visant à améliorer le support d'UTF8. Enfin, c'est réglé.

Une vitesse de transfer entre 64 et 80kB/s (@home en utilisant le wifi entre le PC et le routeur et entre le routeur et la DS), c'est tout ce que je demandais.

Bon, maintenant, 'faudra que je regarde comment faire en sorte que ma fonction die() marche à nouveau ...

(PS: oui, j'ai testé tout ça sur la PHAT de ma fée, histoire de limiter la casse et les pertes de données au cas où... honte à moi ^^" ... quoi que, avec le binaire de SEDS qui crèe systématiquement des fichiers de taille 0 datant de janvier 1979 ...)

Speed Limit: 32

Now, that's fairly annoying. It looks like the TCP WiFi transfers with the "devkitpro r32" is roughly 3 times slowlier than its r21 counterpart (in purple) for the same receiving code. That's especially annoying since it significantly increase the duration of a self-upgrade cycle during development.

The new performance (in black, as reported by wireshark) is impaired by regular "waits" of ~200ms before the PC retransmits some data. And I'm doing the test with a local server here. A larger RTT would likely reduce the performance even more. Retransmissions happen form the start, and that's fairly normal for a wireless transmission. I ran some early code comparison between the ARM9 TCP code of the two dswifi versions, but I couldn't spot any major change that could explain this behaviour.

J'ai finalement suffisament rafistolé runMe pour qu'il puisse de nouveau faire sa mise à jour automatique -- la clé de voûte de mon cycle de développement sur DS. Je pouvais déjà jouer à redémarrer sous Moonshell, puis passer dans le menu R4, utiliser le vieux runMe "21" pour télécharger le nouveau tryMe "32", retourner à Moonshell puis au menu R4 pour démarrer le programme tryMe. Pas extraordinaire. Problème: les transfers par WiFi sont devenus nettement plus lents. Jusqu'à 3x plus lents si j'en crois mes captures wireshark (ci dessus, runme-21 en mauve, runme-32 en noir).

Pourtant, à en croire le code de TCP dans libdswifi9, rien n'a changé ... ou presque. Rien en tout cas qui puisse expliquer ces pauses de 200ms récurrentes dans le deuxième scénario. J'investigue un peu plus grâce au zoom infini de WireShark pour découvrir que la DS annonce juste avant cette pause une fenêtre de réception de plus en plus petite, qui finit par atteindre une taille nulle. Et ça, en langage TCP, c'est le signe que le récepteur ne suit plus: les buffers saturent.

One intriguing thing is that, somewhat prior one of these long wait is that the receiver's window size is reduced from 1400 bytes to 1127, then 591 and finally 55 bytes ... It will then remain with a 0 receiver window for a few packets and then move back to 1400. In TCP language, this is an indication that the receiver struggles to process the received data on time. But the code that invokes "recv()" hasn't changed either ... that sounds like a problem coming from the "write-to-filesystem" side of the program ... from the libFAT.

It looks like libFAT has received more substantial changes, especially regarding the cache management. I used runMe's "receive to memory" mode, which is limitted in file size, but still operated at the usual peak speed. If a sequence number graph doesn't talk to you, the performance monitor just on the right should. The first "bridge" bar is the transfer to disk, the second "tower" bar is the transfer to memory. I haven't figured how to fix that yet, but at least I am in position to say that TCP is clear of charges.

Puisque le code qui transfère les données de dswifi à libfat n'a pas changé d'un iota, le problème est plus que probablement dans la libfat, qui a subi des modifications relativement importantes -- notamment au niveau de la gestion de son cache. Et vu que les données arrivent par le réseau à une taille qui n'est pas la taille "naturelle" pour écrire sur disque, un petit défaut dans la libFAT pourrait facilement avoir un effet conséquent sur les performances. Dernier petit test pour me convaincre de continuer dans cette direction : un transfer Wifi en mémoire (et non pas vers un fichier), fonctionalité un peu désuète de runMe mais qui tombe à pic ici. Résultat sans appel: on retrouve la vitesse à laquelle runMe m'avait habitué.

C'est donc un dswifi blanchi qui quitte la garde à vue tandis que je m'apprète à jouer une âpre partie de cache-cache avec le gros lard louche connu sous le nom de libFAT.

It works ! I can't believe it !! ...

Wo, dudes. It sure has been an odd week at work, but it was even weirder after office hours when I tried to figure out what prevented Apple Assault to work... I wish I had actually typed "svn copy trunk branch/dkp-r32" before I started "fixing" the code for the new release of devkitarm.

After spending hours contemplating fifosystem.c and other hours digging into the source of DesMuME, I found no heroïc bug to fix, gained more confidence in the new tools and finally figured out that some of the assumptions I was working with (e.g. "thou shall call irqInit() before you invoke swiWaitForVBlank") were no longer true in the latest release ... and actually weren't true anymore for a while.

Migrating to the new libnds requires you to switch to the new everything ... including the latest desmume where the way to support "emulated filesystem" had changed. After I inserted a fake register whose content is dumped immediately on both ARM processors (I'm pretty sure there is similar features already, but it's faster to redo it than to locate it :P), I got capable of tracking the execution of the program ... Another modification enabled register dump after haltemu was called, which "explained" that the emulator shutdown was due to a new policy for handling not only exit(), but also abort() -- and C++ exceptions, which I had used in a tweaked way with the "devkitarm-21-based" setup I used so far.

The good news is that I now have Apple Assault running -- in a degraded mode, but running. And I have plenty of developer-friendly stuff added to my emulator to help me fix (hopefully) quickly the remaining things... It was about time : I nearly got discouraged yesterday.

Vous avez vu ? j'ai réussi à réavoir de l'Apple Assault qui s'affiche. C'est pas encore complètement rétabli, mais ça remarche de nouveau. Tout le reste, vous l'avez déjà lu dans les posts précédents :P

edit: I even managed to get sound running, although TrackSequences aren't working yet (missing the get-current-position ? no : curpos() do not rely on FIFO : it's just shared memory ... Or maybe I should ensure the oops[] array is accessed through un-cached addresses it looks to work fine the way it is, but it constantly compares against "pos == 0" ... ) That means the "trunk" is now definitely for "devkitpro-r32" (whatever it means) and that the devkitpro-r21 old things are archived once for all in tags/apple-assault-release.

SYSTEM POWERED OFF VIA ARM7 SPI POWER DEVICE

sauf erreur de ma part, je parviens maintenant à avoir le code de runme qui tourne sur desmume (version 0.9.6-SVN) quand il est compilé avec en mode "dkp-r32". Par contre, si j'essaie d'utiliser les même outils pour AppleAssault, j'ai droit à un magnifique "SYSTEM POWERED OFF VIA ARM7 SPI POWER DEVICE". Je soupçonne desmume de couper froidement toute communication avec GDB quand ça se produit, ce qui, du coup, m'empêche d'en chercher la cause >_<

IPC9@201564a send FIFO < 0x480A725C -- size 000 (l 0x8505, tail 00) (r 0x8501, tail 05)
-- IRQ delivering.
IPC7@37ff16a recv FIFO > 0x480A725C -- size 000 (l 0x8401, tail 05) (r 0x8504, tail 01)
IPC9@201564a send FIFO < 0x04010040 -- size 000 (l 0x8505, tail 01) (r 0x8501, tail 08)
-- IRQ delivering.
IPC7@37ff16a recv FIFO > 0x04010040 -- size 000 (l 0x8401, tail 08) (r 0x8504, tail 02)

Evidemment, la version "standard" de desmume (0.9.5, livrée par Ubuntu), elle, coince à l'initialisation du Wifi, et ça ne vaut donc même pas la peine de continuer à chercher. Je vais donc devoir aller ajouter l'équivalent-émulateur d'un gurumediation dans le code de emu_halt(), voire y ajouter un DEBUG_dumpMemory() ...

I think I can now get runMe running under desmume when it is compiled with my 'dkp-r32' install. If do try to use the same tools for AppleAssault, I end up with an error message suggesting ARM7 powered off sometihng. I bet the emulator doesn't try to talk to GDB any further when that occurs. Let's see if I manage to get more information by adding something helping guru meditation in emu_halt() ... and later a 'magic' fake register that allows me to track evolution.

After exploration, it turns out that something is calling `abort()` before my exception catch-and-report code could kick in. And abort() may shut power down. All this occurs because I forgot command line argument --gbaslot-rom to let DLDI code access files.

Après modification, et si j'en crois mon nouvel outil, c'est au niveau de libnds_exit.c que le processeur ARM9 s'est arrèté, juste après un appel à powerOn, qui aurait été appelé quelque part à partir de fifosystem.c (dans la fonction waitBlock, ce qui me paraît on ne peut plus louche ...) Le processeur ARM7, lui, s'est bloqué au niveau de writePowerManagement appelé depuis powerValueHandler. Ca, au moins, c'est cohérent. Le dernier message transmis de l'ARM9 vers l'ARM7 est (poétiquement) un 0x04010040, ce que je peux décoder en:

• 0xxx.xxxx : Channel 0 : power management
• x4xx.xxxx : Immediate value (type=4)
• xxx1.xxxx : PM_REQ_ON
• xxxx.0040 : PM_SYSTEM_PWR (?...)

Ma foi, ça me semble être tout à fait la situation découlant d'un appel à systemShutdown, dernière opération de __libnds_exit() lorsque le "retour à hbmenu" a échoué :P Bref, heureusement, je m'étais donné un "faux registre" 0x04042000 pour envoyer des mots de 32 bits hors de l'émulateur ... ce qui m'amène à la conclusion que mon interception des exceptions C++ s'est fait court-circuiter par un appel "abort()" qui a ordonné la fin du programme ... grr. ... et derrière tout ça, l'oubli de --gbaslot-rom, désormais indispensable pour EFS sous desmume >_<.

sgIP_TCP: either buggy or awkward

L'implémentation de TCP sur DS me surprend un peu, et pourrait bien expliquer les "fuites de données" observées pendant les transfers DS->PC. Ou les "deadlocks" qui se produisent en cours de transmission". Sur la sellette, la gestion des ACK, ces signaux qui indiquent qu'un paquet a bien été reçu.
I've never seen a TCP implementation behaving like dswifi, and chances are that it might explain the "data losses" and deadlocks I'm experiencing with runme uploads recently. I've compared my version (2005-2006) against the latest version in devkitpro and did not noticed significant changes in the TCP protocol handling.
What looks odd is the management of ACKnowledgements, those little packets that just tell the sender that "okay, i've got your data, go ahead". First, the DS seems to acknowledge everything, including ACKs from the PC. Moreover, it doesn't look to take all ACKs into account when sending a packet, but only the oldest one ...

• d'abord, la DS émet un ACK même pour un paquet qui ne contenait aucune donnée (un ACK du PC, par exemple)
• ensuite, elle ne semble pas tenir compte du dernier ACK reçu au moment de renvoyer des données, si bien que la DS réémet des données que le PC a déjà acquittées.
  

Mon analyse est encore un peu imparfaite (la DS a-t-elle ou non reçu les ACK du PC ? difficile à dire)
En regardant les lignes 4060 et 4061 de la capture, il est évident que la DS a reçu un ack du PC, puisque le n° de séquence évolue pour la 1ere fois depuis la ligne 4050, mais alors que le PC vient de valider tous les bytes jusqu'à 101796 (compris), la DS retransmet tout de même à partir de 100633 (ç.a.d. seulement 256 bytes plus loin que le packet précédent).

Je travaille toujours avec la version 2005-2006 de la bibliothèque dswifi de Stephen Stair. Je devrais sans doute tenter une mise à jour.

edit: the third pass on my own code revealed a subtle error on how I handled "EWOULDBLOCK" when uploading from a file. sgIP_TCP thus did not lose any data and is just a bit awkward. Sgstair himself took the time to point me out that there are much more levels of queueing in the DS networking stack (including hardware buffers), which sheds another light on the problem ... I think I can live with small performance issues. But I'll keep on investigating the issue anyway.

FileWidgets

Let's welcome FileWidgets.cpp in libgeds and appropriate DirShow + TypeWord widgets on the beam-file-out-of-DS page of runme. Snapshot will come out later : it's past my bed time, already.

Bin voilà. Finalement j'ai pu transférer les FileWidgets depuis le LevelEditor dans libgeds, ce qui m'a permi du coup de les utiliser dans runme pour le choix du fichier à exporter. Mais là, je vais aller dormir :P

runme feature request

Le problème d'un petit outil bricolé à la demande, c'est justement que les fonctionnalités sont bricolées à la demande. Ainsi, runme est devenu assez fort pour recevoir des fichiers depuis le PC par wifi, à condition de préférer une connexion rapide à un nom de plus de 8 lettres ...
Pour ce qui est d'émettre des fichiers, par contre, je suis à la traine. C'était un ajout destiné à permettre le backup des fichiers créés par mon Sprite Editor, avec donc 4 boutons "A-B-X-Y" correspondant aux quatre fichiers de travail spriteA...spriteY eux-même liés au fait que pour sauver son travail dans SEDS, on fait START-R-[ABYX] pour choisir le fichier à écraser ou START-R-R pour "sauver le fichier en cours". Idem START-L-[ABYX] re-charge un fichier. Pas de boite de dialogue, donc. Du code assez simple pour une fonctionalité assez simple, parce que de toutes façons je n'avais pas besoin de plus (et je n'ai toujours pas eu besoin de plus jusqu'ici).

Runme's upload features (that is, DS-to-PC transfers) are still fairly limited, and become a boulder in the path of coding. All it offers is to pick one of the 4 spritesheets edited with SEDS, and that's all. How about the map i've just edited ? how about Bilou and foes state machines? how about any other file on my .nds i'd love to beam back on rotating magnets (that is, HDDs :P) ?
It's somehow getting a priority. I'm not hot about integrating those Directory-selection widget of LEDS into rumne, but I guess it's no longer an option. I hoped the PC-side could tell us the name of the file to pick, but it also look like the objects of my code are oriented in another direction. OOPs >_<.
Mais depuis, j'ai aussi un éditeur de map et si les fichiers .cmd qui définissent les niveaux sont toujours rédigés à la main sur PC, ils ne sont pas forcément sur ce PC. Bref, il me faut plus de souplesse dans le choix du fichier. Quelque-chose du genre du choix de fichier dans LEDS. J'avais pensé contourner le problème en sélectionnant le fichier à partir d'infos envoyées par le PC par Wifi, mais malheureusement, l'organisation POO du code s'y oppose.

Je pourrais aussi repécher les derniers fichiers ouverts lors du parsing des scripts, tiens.

Affaire à suivre, parce que du coup, le temps imparti est écoulé. Et je n'aurai pas pu aller bricoler Bilou pour qu'il saute moins haut quand on relâche le bouton...

contretemps

Mon routeur @home est en rade. Depuis la naissance de *deline, ou presque. J'ai passé presque toutes les vacances à faire du "card swapping" (heureusement plus rapide avec une R4 que mon ancienne SuperCard) pour transférer les fichiers et faire mes tests. Evidemment, avec l'éclatement du gros script de niveau en plusieurs petits scripts, ça complique encore un rien l'affaire.

J'ai ramené ma petite clé USB, celle-là même que j'avais utilisé en Suisse comme point d'accès autonome ... aujourd'hui. Evidemment, dans l'intervalle, j'ai cherché des solutions pour éditer rapidement les scripts déjà présents sur la DS.
Et je dois admettre que je suis assez étonné du peu de programmes proposant un éditeur texte -- même tout simple -- sur nintendo DS. J'ai testé un Blargh en mode pre-alpha (sans sauvegarde :P), le moonshell "en lecture seule" et la combox de Lilou n'est pas fiable sur ce coup-là : j'ai régulièrement des lignes qui disparaissent, qui fusionnent, etc.

The day *deline came back home, both my car and my WiFi router decided to go on strike. The car was quick to fix, but i'm still in need of a 5V/2.5A power adapter for the router, making data & code uploads via runme unfeasible at home during the whole summer. I just brought back the USB access point i set up for my laptop in Basel, so since yesterday, i'm no longer forced to swap the micro-SD card in and out of my R4 to progress on Bilou.

Meanwhile, i've been tempted to edit my files directly on the DS. All i have to do is change a few things here and there, not to write down complete source scripts. Moonshell already allowed me to view files, but not to edit them. I gave BLARGH a try, an editor using a "keyboard" specially designed for efficient stylus input, but it's still a beta release that cannot save edited files. Pretty useless. I have thus used the text editor present in Lilou's combox, but it proved to be unreliable, randomly dropping or merging lines on edits. Maybe i'll work on a TEDS text editor to accompany runme and friends later on, and it might be based on "tag clouds" derivated from the text's content.

Anyway, i'm not fully back, but the "maquis" weeks toying with SD card readers are hopefully over, and i've succesfully tested controller chaining feature. I can go on with appleman's behaviour.

Bref, quand j'aurai le temps, je me ferai mon propre petit "TEDS", probablement basé sur un "tag cloud" des mots les plus fréquents dans le texte existant, histoire de faciliter l'écriture dans des langages de programmations (au détriment du micro-blogging). Enfin, tout ça pour dire que j'ai enfin pu faire un test de l'enchaînement des contrôleurs: ça demande encore un brin de mise au point, mais ça prend bien forme.

Uh ? It looks like nothing about controllers have been translated in English this far. I'll need to fix that.

powersave

Jusqu'ici, mes petits programmes étaient plutôt dévoreurs de batterie sur la DS. J'avais beau dire à mes p'tits n'veux que "tu fermes ta DS et tu viens manger tes frites, le jeu sera toujours là quand tu auras fini", c'était loin d'être le cas pour Bilou ou mon sprite editor.

Et pourtant, le fonctionnement est plutôt simple: un registre (REG_POWERCNT dans libnds et POWCNT1 sur gbatek) permet d'activer ou de désactiver certaines puces de la DS pour réduire la consommation. Côté ARM7 (connu alors sous POWCNT2), il contrôle le son et le Wifi. Côté ARM9, il contrôle les processeurs graphiques, permettant d'activer ou de désactiver séparément la 2D, la 3D, etc. Tout ce qu'il y a à faire, c'est :

if (lid_closed()) {
  u16 power = REG_POWER;
  REG_POWER = 0;
  while (lid_closed()) swiWaitForVBlank();
  REG_POWER = power;
}

la position du capot étant donnée par le 7eme bit des "boutons" de la console. Le coeur du fonctionnement étant évidemment la boucle "while(lid_closed) waitForVBlank() qui va utiliser les fonctions du BIOS de la DS pour mettre le CPU en pause jusqu'à ce qu'une interruption se produise (en l'occurrence un retour d'écran), et ce en continu tant que le capot est fermé. Au lieu d'exécuter 66 millions d'instructions par secondes, le processeur se contentera alors d'environ 600 à 1200 d'entre-elles (à la grosse louche, hein) et le rendu graphique est désactivé.

Evidemment, pour faire "pro", il faudrait aussi signaler au co-processeur (l'ARM7) de mettre en berne le son (sauf si on programme un iPoDS) et le Wifi (sauf si un transfer de fichier est en cours). En clair, si l'ARM7 pourrait gérer sa puissance de manière autonome, il reste préférable de le reléguer dans un rôle d'esclave.

Ma première tentative pour appliquer ça n'a pas été franchement probante, mais quelques "printf" m'ont vite révélé mon erreur : je n'ai encore aucune routine d'interruption pour le 'retour d'écran' (VBLANK) et les interruptions VBLANK sont carrément masquées par mes programmes. Résultat, swiWaitForVBlank() attend indéfiniment :P Si j'y remédie et que je passe à du "waitForVBlank" dans ma boucle principale également, c'est toute l'application qui devrait devenir nettement moins gourmande.

while(REG_VCOUNT>192); // wait for vblank
while(REG_VCOUNT<192);

c'est indigne d'un vétéran. Quand mes étudiants codent comme ça, je les menace de leur imposer de coder sous DOS.

Et si je vous raconte tout ça au conditionnel, c'est que mon routeur WiFi à la maison m'a lâchement laché, rendant le développement DS aussi pratique qu'à Bâle, le temps libre en moins.

edit: après essai, curieusement, le son est mis en veille lui aussi, automatiquement et sans communication explicite de ma part entre ARM7 et ARM9 ... Ne loupez pas non plus le commentaire très intéressant de thoduv (lapinou jumps) pour passer de la théorie à la pratique "pro".

sendall

J'ai toujours été intrigué par cette fonction "sendall" du Beej Network Programming Guide. Selon Beej, un appel à send pour transmettre des données pourrait ne pas nécessairement envoyer autant de données que prévu. J'ai toujours trouvé ça un peu surprenant et je n'avais personnellement jamais été témoins d'une telle chose jusqu'à aujourd'hui.

Corrigeant les TP de programmation de BitTorrent, j'ai un strace ouvert aussi sur le client initial dans un "environnement de test contrôlé" et voilà que j'aperçois la séquence suivante:

send(10, "\0\0\200\t\7\0\0\0(\0\0\0\0\2619\r\222\265\315r\264a\363"..., 32781, 0) = 32781
send(10, "\0\0\200\t\7\0\0\0(\0\1\0\0\340\306\335\246\17\r\377\265"..., 32781, 0) = 32781
send(10, "\0\0\200\t\7\0\0\0(\0\2\0\0\233\257\314\25P\322\2363\316"..., 32781, 0) = 32781
send(10, "\0\0\200\t\7\0\0\0(\0\3\0\0002\235\311\36yyzt\322\363$"..., 32781, 0) = 28790
send(10, "UUUUUUUUUUUUUUUUUUUUUUUUUUUUUUUU"..., 3991, 0) = 3991

Le programme tente d'envoyer des données de 32K accompagnées de 13 bytes de contrôle. Le plus souvent, celà signifie qu'un buffer de 32781 bytes est passé à l'appel-système send (cf. le 3eme argument) et que 32781 bytes ont effectivement été envoyés (cf. la valeur de retour, après le '='). Sauf pour les deux derniers, où si on a bien 32K+7 soumis, seuls 28790 bytes ont pu effectivement être "envoyés" ... Je devrais plutôt dire "pris en charge par le protocole TCP". Effectivement, TCP a sa propre mémoire-tampon dans laquelle il conserve les données à envoyer, mais elle n'est pas infinie. Si a un moment donné elle "déborde", TCP prend le plus de données possibles mais signale à l'application qu'une partie n'a pas pu être traitée.

On aurait pu préférer une approche "l'appel va être bloquant jusqu'à ce que tous les bytes soumis soient traités". Bin ce n'est pas forcément le cas, et ce n'est pas plus mal: l'application a peut-être quelque-chose de plus utile à faire avant de ré-envoyer le reste.

Comme j'ai de temps en temps des fichiers qui "passent mal" avec les transfers wifi de runme, je regarderai à l'occasion si je ne ferais pas bien de rajouter un "sendall" ici ou là.

PS: au passage, Beej a finalement fait une version "bouquin" de son superbe tutoriel.

analysis paralysis ?

Près de 3 mois loin de chez moi, maintenant, et toujours pas de petit homebrew à vous mettre sous la dent. Okay, mon laptop est un char à boeufs comparé aux PC que j'ai à la maison. Okay, je n'ai pas de Wifi dans mon k0dek et le laptop n'est pas configuré pour faire base station pour la DS mais il y a autre chose.

Je sais qu'il y aura pas mal de choses à mettre en place pour parvenir à réaliser Bilou sur DS ... je veux dire par là, "le jeu de plate-formes tel qu'il avait été prévu dans les années '90 et prototypé sur BASIC", mais revu et corrigé pour la DS, bien sûr.

Par exemple:

• [just started] la gestion des bordures. Même si je garde au départ un système tile-based, les plate-formes mobiles et autres sables mouvant devront être capable d'altérer le comportement des sprites
• [ongoin] les pentes. Je veux que Bilou puisse se déplacer sur des plate-formes qui ne soient pas uniquement horizontales.
• [done] l'animation modulaire. ou "à la rayman", qui me demande un éditeur d'animations spécifique en plus des ajustements dans le moteur de jeu
• [done] les collisions perso-bloc qui soient plus maniable que juste le "petit bonus" que j'ai pour l'instant. Plate-formes qui disparaissent, échelles, etc.
• [done] des réactions aux collisions perso-monstre. Avec une question pertinente "et comment fait-on perdre une vie, au fait"

J'accumule les idées sympa sans vraiment avancer dans le développement. Je sautille d'un projet de shoot à une reprise de Seafox à un "bubble bobble - like" etc. Et bien sûr, comme j'aime le pixel art, j'ai tendance à explorer les aspects graphiques à tort et à travers avant de me lancer dans un jeu.

Je vais devoir me fixer une "roadmap" jallonée de petits projets intermédiaires, et attaquer les difficultés techniques une à une, sinon je vais finir par recommencer à programmer sur Clicker :P

Bonne résolution 2009 #1: on garde Bilou. Quelque soit le petit jeu envisagé
Bonne résolution 2009 #2: un nouveau thème graphique si et seulement si un jeu est produit.
Bonne résolution 2009 #3: s'il n'y a pas d'image de fond (ou si l'image est fixe, etc.) ce n'est pas un problème pour l'instant.
Bonne résolution 2009 #4: faire la vaisselle ce soir

edit: côté "base station", j'ai au moins pris la peine de recompiler le module de mon stick WiFi. M'en vais aller manger une soupe et tester ça @home, tiens.
edit++: toujours pas de connexion Internet au k0dek, mais au moins, j'ai su modifier runme pour qu'il puisse démarrer un programme 'runme-compatible' après l'avoir téléchargé.

3 monthes in Switzerland and still no updates. I'm not focused enough and therefore I'm missing the #1 golden rule of game development : *release*. Having no Internet access in my Swiss flat doesn't help, so I modified runme so that it can launch the last compatible .nds it received from a WiFi transfer. Using my laptop as an access point, it allows ad-hoc development.

Allez, je vais essayer de me faire un petit "ramasse toutes les pommes pour passer au niveau suivant". Ce sera déjà un bon début. Après tout, c'est fort le principe de base de Qwak, Bubble Bobble et même Still Alive DS :P

mon routeur à un DNS qui rame ...

Bon, avec ces routeurs Wifi qui deviennent de plus en plus fréquents, j'imagine ne pas être le seul à avoir le problème : ce genre de routeur se renseigne généralement comme "serveur" DNS local (en gros, c'est lui qui se chargera de savoir qui est "google.com" et tous les autres sur le réseau), supplantant le serveur de votre ISP ... Ce qui ne serait pas bien grave si ce brave petit routeur WiFi avait la puissance et la mémoire nécessaire pour faire ce boulot ...

Résultat: une navigation ralentie par de longues attentes sur des noms par rapport à une connexion directe avec le modem de l'ISP. Que faire ?
Première chose, apprendre l'adresse du fameux serveur DNS (serveur de nom) de votre ISP. Jetez un coup d'oeil au fichier /etc/resolv.conf ... s'il renseigne "nameserver 192.168..." ou "nameserver 10.0..." (qui sont des adresses IP "locales", utilisées uniquement derrière ce genre de routeur-pare-feu), c'est qu'effectivement le routeur sert de serveur de noms. Réessayez alors sans le routeur, et vous aurez peut-être droit à quelque-chose comme "nameserver 123.56.1.1", que vous vous empresserez de copier sur un post-it (c'est le serveur de nom de votre ISP ... le vrai). (PS: vous pouvez sans doute aussi apprendre ça en interrogeant l'interface Web de votre routeur ou en retrouvant dans votre fouilli le contrat de l'ISP ;)

Rebranchons notre routeur, maintenant, et une fois le réseau prêt à fonctionner, éditons comme un grand sauvage le fichier /etc/resolv.conf (à coup de sudo, bien sûr) pour remplacer "nameserver 192.168.1.1" par "123.56.1.1", par exemple ... Est-ce que la connexion a l'air de se faire mieux ? Si oui, c'est qu'il y avait bien un soucis de DNS ...

Evidemment, ce serait trop simple que cela suffise. /etc/resolv.conf est un de ces fichiers qui est écrasé à chaque démarrage par le client DHCP (celui qui demande au routeur gentillement de lui donner une adresse et de s'ajuster au réseau et qui vous permet du coup de vous ballader du bureau à la maison sans vous poser trop de questions). On va donc devoir aller éditer cette fameuse config DHCP (dans /etc/dhcp3/dhclient.conf sur mon ubuntu), le truc étant d'utiliser la commande "prepend" pour forcer une configuration statique à prendre le pas sur la config automatique.

send host-name "";
#send dhcp-client-identifier 1:0:a0:24:ab:fb:9c;
#send dhcp-lease-time 3600;
#supersede domain-name "fugue.com home.vix.com";
prepend domain-name-servers 123.56.78.1;
prepend domain-name-servers 123.56.1.1;

et voilà. Les "sudo /etc/init.d/networking restart" n'auront plus raison de notre beau resolv.conf ...

PS: c'est geek, hein ;) oui, je sais, c'est plus simple quand il y a des cases à cocher, mais à défaut, on a un peu appris comment ça marchait ;)
PPS: oui, j'ai finalement moins bricolé ma DS pendant ma première semaine en Suisse que je ne l'aurais cru ... et je n'ai pas senti le besoin de blogger les petits progrès qui avaient quand-même été réalisés ... d'où un blog un peu plus calme, ne vous en déplaise.

Bon anniversaire, Bilou

Eh oui, ça fait maintenant deux ans que je bricole sur ma DS. Et figurez-vous que en voulant retracer l'historique, ma mémoire m'a fait défaut. Elle n'a apparemment retenu que les évènement "vie réelle" (achat de maison, mariage, conférences, changement de voiture, etc) et éventuellement greffé les bouts de développement DS qui s'y rapportaient.

For some reason, /dev/brain only stored memories of real-life events since I started homebrew development. Let's recap.

juillet 2006 - octobre 2006 : Balbutiements

Les débuts de SEDS, qui commence sur émulateur uniquement, puis reçoit la libfat pour stocker les fichiers sur la carte SD. Et en deux ans, je n'ai toujours pas fait sauter la "limite" de 4 fichiers, même si la quantité de données autorisée sur un fichier, elle, a considérablement progressé.

July 2006: Baby steps. I get started with a sprite editor attempt just on emulator, then I got true hardware and add libfat support so I could save my work on the SD card. I take shortcuts such as '4 files will be enough for everybody' which is still true as of today. By October'06, I have a first snowy tileset and a santa character converted from a .PCX file. I'd like to bring in a pinguin baddie I had drawn in an unifinished PC game project and make a Rick Dangerous clone out of it.

Fin octobre, j'ai mon premier petit "tileset" hivernal et Mr Noël récupéré du PC, de sorte que je peux envisager un Rick Dangerous like avec mon papa noël de 2000. Faute d'avoir retrouvé le pingouin de Badman III, le projet n'ira jamais plus loin que ce petit "mockup".

Novembre 2006 - Mars 2007 : Rumbling

Entre la thèse et le déménagement, j'avais apparemment trouvé le temps pour coder un petit "whack a rat" nommé "apple rumble", partant des sources de Tetris Attack. C'est aussi pendant cette période que mon lecteur de carte SD m'a laché, et que je me suis rendu compte de l'ampleur des lacunes du Desmume (l'émulateur DS) de l'époque. D'où le démarrage du projet "runme" permettant des transfers "over wifi"

November'06 to March'07 was a busy time. Writing my PhD, moving to a new home and the like. But still a dug enough time to convert a Tetris Attack clone into a whack-a-mole: Apple Rumble. A definitive failure of my SD card reader will trigger development of runME, my custom WiFi transfer tool. I still rely on emulator snapshots to show my pixels to the world.

Et si les tiles de la "bibliothèque" de Bilou sortent dans leur première version, c'est toujours à coups de SEDS émulé que je les convertis en "mockup". En revanche, beaucoup de fêtes en famille, donc beaucoup de level design pendant cette période-là ^_^

Avril 2007 - Juillet 2007 : Rédaction

Calme plat ... il fallait s'y attendre :P

Aout 2007 - Octobre 2007 : L'odysée du Wifi

C'est la grande reprise de "runme", qui jusque-là pouvait télécharger des fichiers par wifi, voire en afficher certains (.pcx, .spr, .it ...) mais c'est tout. Deux petites lib' releasées au bon moment (l'attente de ma thèse relue) vont permettre la pierre d'angle de mon développement DS : l'auto-update par wifi, ou comment un programme va récupérer une nouvelle version de lui-même et la démarrer sans autre intervention qu'un clic de l'utilisateur.

August'07. The thesis is submitted. I push WiFi support further: all the dsgametools will now support hot-update over WiFi. runME becomes the 'hub' from which SEDS can be invoked, and to which it can return once user tries to 'quit' it.

Suivra une ré-écriture de SEDS pour qu'il puisse gérer plus de sprites (multi-page) et "sortir" vers runme (qui sera aussi en mesure de lancer SEDS), qui sera annoncé sur les forums (à partir de Player Advance) vers la mi-octobre.

Novembre 2007 - Février 2008 : Objectif LEDS

Quelques scripts bien placés et je m'attaque maintenant au débuts de mon moteur de jeux de plate-formes: le scrolling. Théorique d'abord, puis pratique via une petite modification de runme (qui me sert une fois encore d'homme à tout faire) Ensuite, je m'attaque a un éditeur de niveau "autonome", ce qui amène son lot de nouveaux "widgets" et à la création d'une bibliothèque de fonctions utilisées par les trois programmes, j'ai nommé "libgeds" (pour Game Edition on DS).

November'07: it is time I start with the core of my future platforming game engine: scrolling. Once again, runME will be the host (and the fits-all-purpose tool) for testing things. Then comes the time to scroll not only things converted by scripts on a PC, but maps drawn on the NDS itself. That's how libgeds appeared by collecting "widgets" and functions shared by the three programs I have so far.

Février 2008 - Mars 2008 : NTXM

libmikmod ne me convient plus. Trop lourd, trop buggué. Je m'attaque à une intégration du player XM que Oxtob vient de publier. J'attaque aussi la gestion des effets ... un des côtés les plus obscurs des modplayers qui avait fini par avoir raison de mes efforts sous DOS/Assembler en 2000.

February'08: I drop libmikmod. Too heavy. Too buggy. 0xtob has just released an XM tracker and player. Let's integrate that. It lacks effects support, but I can do that. Unlike back in 1997, I now have the power of Internet to explain those things to me

Avril 2008 - Juillet 2008 : GedsDemo

Après cette petite pause musicale, je reprends le développement de mon moteur de jeu. Collisions, animations, déplacements ... Tout ça prend peu à peu place. La première animation postée sur le forum pixelation va aussi être à la base d'une révision quasi-complète du look de Bilou et de sa forêt, ce qui ne se fera pas sans pas mal de bricolage autour de SEDS (de nouveau) notamment pour la gestion et l'import/export des palettes.

April'08. Enough for the musical break. Let's get back to game engine development. Hitboxes, animations, motions, scrolling. Things are getting in place slowly. First 'movie' is posted on pixelation and will trigger an almost complete relooking of Bilou and the green zone, which will require another iteration on SEDS to improve palettes management. And it's also time to extend compatibility to other (DLDI-capable) linkers...

Le tout sur fond de "R4volution", afin d'améliorer la compatibilité de mes programmes avec d'autres linkers que mon Super Card...

Bilou par Wifi ...

Hehe. Je vais me faire enflammer avec un titre pareil. Non, on ne joue pas encore à Bilou par Wifi, mais j'ai transféré les couleurs de mes tests sur Pixelization vers SEDS histoire de pouvoir essayer un p'tit Bilou (mais alors vraiment tout petit, là). Ce qui veut dire que les réorganisations de couleurs dans la palette, c'est fait aussi. Je me ferais bien un petit "publier le sprite courant par Wifi" avec conversion immédiate en .png à la réception sur le PC, tiens ;)

Oh, keep cool. You cannot play Bilou vs Bouli over wifi. Not yet. But i can beam my palettes to SEDS using Wifi and give a try on new looks for Bilou. I made quite a bunch of very funny animations with those colours, and i have to admit that it's working well. Unfortunately, i made *too much* animations, and i should rather have polished my code instead. When i tried to finally save my work and go to sleep, the display looked strange, and when i later tried to re-load the sprites, all i got was a guru meditation.

The most likely explanation is that the code for managing animation is very rusty -- one of the very last remains of the initial code for SEDS that has never been refactored, and it obviously contain bad practice memory management stuff that have last beyond initial expectations. I lost a couple of things in the process, but nothing i couldn't re-do. Hopefully enough, it happened on a testbed spritesheet, and not on my preciousss "greenzone" tileset. It's a good thing to see that my tools for handling .spr files can recover some corrupt data too ;)

Aaargh. sur ma lancée, j'ai essayé de faire un deuxième Bilou un peu plus grand. Puis je l'ai animé pour donner l'impression de "respirer" et j'ai refait des balles de formes diverses (plus applatie et plus ronde) sur la même base. Puis j'ai joué à faire marcher mon p'tit Bilou et donner quelques expressions au plus grand.

Ouais. Bin j'aurais mieux fait de finir le debugging de mon éditeur, pas encore capable de gérer correctement les longues animations qui s'en sont suivies. Au moment de sauver tout ça, il m'a montré des pages de sprites de plus en plus louche ... Pas dupe, j'ai voulu recharger : bardaf : Guru Meditation.

Comme vous pouvez le voir, la plupart des "tiles" seront récupérables (à la main dans Gimp, j'imagine), mais les infos qui disent quel bloc utilise quel tile, là, c'est irrémédiablement foutu >_<

edit: comme je m'y attendais, c'est plus que probablement dans la gestion des animations que se trouve le gros bug. C'est du vieux code d'avant que je ne me mette à la bibliothèque standard du C++ (vecteurs, maps, etc) qui est encore plein de malloc(sizeof(x)*n) et qui manque de if(i>n) return; si vous voyez ce que j'veux dire