Tuesday, November 30, 2010

atof("3.14") == 0

J'avais donné le code suivant à mes étudiants:


int i = atoi(argv[2]); printf("[2] = '%s'\n",argv[2]);
float f = atof(argv[4]); printf("[4] = '%s'\n",argv[4]);
char* s = argv[6];

printf("%i %s %f = %f\n",i,s,f,f+(float)i);

Et l'un d'entre eux vient me trouver en disant que, chez lui, le code affiche toujours "42 plus 0.00000 = 42.0000" quelque soit la valeur donnée à l'argument '-f'. Je récupère le fichier je compile ... ah flûte: pas de devkit SDL sur la machine qui sert à projeter les transparents pendant les répèts. Hop, je commente "#include output.h" je compile je teste ...

Et là, bardaf. pas moyen d'avoir une valeur correcte... Un p'tit coup de manpage Warf. atof renvoie un double là où j'ai utilisé un float ... et printf("%f") suppose aussi la présence d'un double -- un nombre réel à haute précision, et prenant donc 2 fois plus de place ... vu que ça risque de poser des soucis (utilise une valeur tronquée, tout ça), je s/float/double/g tout ça je recompile et ... bin non. Toujours pas.

Tout ça accroupis dans l'auditoire. Je ne me démonte pas, je démare ddd ... qui persiste et signe.
Il aura fallu que je sois de retour sur ma devstation dans mon bureau, à l'aise, pour mettre le doigt sur le bug ... grâce à gcc -Wall, soit-dit en passant. Je vous laisse cogiter, puis passez voir la réponse dans les commentaires: c'est bête comme chou.

Monday, November 29, 2010

7 of 9 -- personal Log

27/11 : quelque soit le code ARM7 que j'utilise (le mien modifié, celui de Tobias ou le code DefaultARm7), runme ne passe pas le cap "sync with 7" sur l'ARM9 ...
28/11 : avec le code ARM7 de Tobias et le code ARM9 de l'exemple httpget.c, je parviens à avoir une transmission WiFi fonctionnelle. C'est donc (contre toute attente) le code ARM9 qui foire.
29/11 : la présence d'IrqInit() dans le code de GuiEngine::prepare() était clairement une des causes d'erreur, mais je ne sais pas encore dire si c'était la seule. Je vais devoir continuer à importer petit à petit les fonctionnalités de runme sur cette nouvelle base pour mettre le doigt sur les éléments perturbateurs.

Seven's log, stardate 201011.27 -- I am trapped in my ARM7 cortical implants. Although I could potentially still communicate with the WiFi collective -- if any was at short range -- I have lost connection with the ARM9 behaviour controller that would allow me to communicate with the crew of the Voyager. I have analysed the defect starfleet fifosystem.c that the Doctor installed to replace my damaged borg implants that is the root cause of my malfunction. The only tool I have to operate is a standard DESMuMe tricorder from the federation filled with irrelevant features, and that reaches only 67.3% of the efficience of a corresponding Borg nanoprobe.

Seven's log, supplemental -- A double initialisation of my interrupt mask might be the cause of this FIFO dysfunction. Deeper inspection of the starfleet FIFO protocol revealed a rigid structure with 16 virtual channels and imperfect typing of messages into one-word addresses, one-word value and external larger dataquads. I will resume my investigation when my refresh cycle is complete.



PS: curieux qu'avec le couple de processeurs ARM7 et ARM9, personne (que je connaisse) n'ai fait le rapprochement entre la DS de nintendo et le borg converti "Seven of Nine" de Star Trek : Voyager, vous ne trouvez pas ?

Note: j'aimerais bien également en savoir plus sur le support des fonctions FIFO dans desmume ... je note par exemple dans la fonction _MMU_ARM9_write32

case REG_IPCFIFOSEND :

  IPC_FIFOsend(ARMCPU_ARM9, val);

  return;

Mais aussi (dans le même fichier FIFO.cpp) des fonctions GFX_FIFOsend, apparemment utilisées par l'implémentation des fonctions 3d -- et qui n'a donc probablement rien à voir dans le cas qui m'intéresse.

PS: to the devkitpro and desmume teams : no offense intended. That's Seven's "personality". Watch season 4 of Star Trek Voyager if you haven't yet: you'll know what I mean.

PPS: here's a patch against svn revision 3601 of desmume that enhance debugging of FIFO by
1) enabling per-direction logging of writes to FIFO registers through the DESMUME_FIFOLOG environment variable
2) uses location 0x04042000 as REG_DEBUG : everytime you write some 32-bit word there, it will be dumped -- together with processor no and PC value -- on STDERR.
I don't think I have "fixed" anything, so it looks like r3601 of desmume-cli already supported the full FIFO features (even though generation of interrupts are a bit obscured and could use some more documentation), but it could certainly help people understanding or validating the fifosystem.c of libnds, or other ARM7 initialisation code.

Friday, November 26, 2010

#undef DSMI

La bonne nouvelle avec le passage au DKP-r32, c'est que du coup, j'ai les bonnes bibliothèques et outils pour compiler le projet NitroTracker d'0xtob ... et donc, que je suis potentiellement un peu plus proche d'un portage de mon support des effets de la libNTXM vers son projet d'origine ... On verra ça ;)

Il se pourrait bien, par contre, que les sources d'0xt0b soient autrement précieuses, puisque mon code ARM7 custom a du mal à passer à la vitesse supérieure, alors que le code d'0xt0b, lui, est déjà prêt à l'emploi. Finalement, il me resterait "juste" à lui ajouter le support de l'exécution d'un autre .nds pour revenir sur les bases nécessaires pour mes outils...

the good thing with the switch to "release 32" of the devkitpro is that I'm now able to compile the Nitro Tracker project -- the one where theNTXM sound library I use originates from. That brings me one step closer to backporting of my own NTXM extension to its seminate project, but also, it means that recycling the ARM7 code of 0xt0b could be more efficient than trying to upgrade my own custom ARM7 code, since Tobias has included support for the WiFi as well.

Wednesday, November 24, 2010

source setup-r32

Bion, un package sources pour Apple Assault, c'est sympa, mais si le code pouvait être compilé avec les versions en date du devkitpro, ça ne serait pas plus mal, hein ? Il faut dire que j'étais resté à la version r21 qui doit dater d'octobre 2007 et sur laquelle j'ai pas mal bricolé entretemps.

I guess it'll make more sense to do a source release if you're able to compile Apple Assault from the source, right ? That's where you'll need devkitpro, the open-source cross-compiling and core-libraries project for homebrew console development ... as it was back in October 2007. Sticking to a working -- but obsolete -- development kit helped me during 3 years to stay focus and work on my tools rather than doing pointless bugfixes, but now it's time to move on. I fear it won't be an easy task, though, as I use a custom ARM7 and so on ... Hopefully, again, the ease of branching with subversion should help a lot.

  • gcc 4.5.1 râle sur char * x = "hello" et insiste pour qu'on ait const char* x = "hello", histoire que la chaîne (normalement considérée comme une constante) ne puisse pas être altérée par le programme. Dans l'absolu il a raison et c'est facile (mais chaint) à corriger... d'autant (C++ oblige) que le code de la bibliothèque doit lui aussi être recompilé pour bénéficier de l'update :P
  • IPC n'existe plus ou a été modifié. Je m'en servais pour gérer la mise en veille de la console ... 'faudra trouver autre chose. Plus gênant, mon code custom pour le côté ARM7 devra sans doute être mis à jour lui aussi, et de manière substancielle.
  • SUB_DISPLAY_CR a été renommé, de même que BGx_CR, BGx_X0 et leur variantes SUB_xxx (pour assurer la cohérence avec GBAtek, ce qui n'est pas plus mal, soit dit en passant). Pas vraiment gênant pour l'exécutable lui-même, mais ça va être pénible pour la mise à jour de mes bibliothèques
Bien sûr, mélanger les libgeds.a ou libpppnds.a de devkitpro r21 avec AppleAssault.o compilé pour devkitpro r32 (libnds 1.4.8, libfat 1.0.7, dswifi 0.3.13) serait voué à l'échec. C'est donc l'ensemble du projet qui a besoin d'être migré >_<

L'alternative, c'est de fourguer libnds, libfat et dswifi précompilé dans le "package sources", mais ça me tente tout de suite moins :P

PS: "source setup-r32" parce que j'ai pris l'habitude d'avoir un script shell nommé "setup" à la racine de chaque projet qui configure toutes les variables d'environnements (CLASSPATH, LD_LIBRARY_PATH, CFLAGS, voire même PATH pour utiliser des cross-compilers) ce qui me permet d'utiliser la commande shell source pour "activer le mode OMNet++" ou "activer le mode devkitpro". En l'occurence, pour devkitpro, j'ai un setup-rxx selon que je veux utiliser la release 19, 20, 21 ... ou maintenant 32.

Sunday, November 21, 2010

Last Minute Panic...

Mouais. Pas si finale que ça, finalement, la version 1.4 d'Apple Assault. En tout cas, elle mériterait bien un bugfix. Un conseil si vous devez faire une pause, fermez la console un niveau, pas entre deux niveaux. Disons que le suivi d'un pattern pour déclencher des actions sur certaines lignes n'aime pas trop qu'on laisse le pattern tourner sur l'ARM7 pendant que l'ARM9 est mis en veille.

It looks like the final release of Apple Assault might need some more tweaking, finally. Anyway, if you need a break during the game, close the lid within a level and not between two levels... You've been warned. Well, let's say the TrackSequence that follows an XM pattern launching actions such as clearing the screen and loading a new level isn't that happy when you suddenly freeze the ARM9 that executes commands while the ARM7 keeps playing the music :-/

I tried a trivial workaround, that slightly improves the situation. But it's not improved enough : there is an interference remaining between fading-out and fading-in actions that may leave the screen partly obscured for the next level >_<


Je croyais contourner le problème facilement mais ce n'est pas si évident: la preuve, le jeu n'est plus bloqué, mais il y a eu interférence entre les opérations avant-veille et après-veille ... et du coup, l'écran reste à moitié noir :P

Par contre, j'ai pu faire une petite démo à Pierrick et Parmy ... et ça, c'était bien chouette ^_^

edit: corrigé

Friday, November 19, 2010

The bald's guy game

Vous vous souvenez peut-être d'Arne, le pixel artist qui nous avait fait de sympathiques faux-écrans d'un remake inexistant de Miner Willy ?
On lui doit aussi plus récemment une réinterprétation des graphismes de Super Mario Bros 1 absolument adorable.

Arne a un sacrément bon coup de crayon, aussi, comme en témoigne son projet de HDification du jeu C64 "exile" ... et il est apparemment assez prolixe en concepts de jeu qui n'aboutissent pas. Si bien qu'en février 2007 -- en pleine cave-story-mania -- Derek Yu lance sur le forum TIG un projet de convertir un des design originaux d'Arne en un vrai jeu. Oui, oui, on parle bien du Derek Yu à qui on doit le très réussi Spelunky (un croisement entre Boulder Dash et Rick Dangerous où chaque partie se déroule dans un niveau unique et aléatoire), et plus récemment Aquaria à la bande-son envoûtante.

A l'heure actuelle, "Balding's Quest" est toujours en développement -- au point qu'il vous faudra taper le nom d'un fichier .bqMAP pour pouvoir le tester -- et, chose peu courante, le développement est communautaire, chacun apportant sa petite touche perso (un niveau, une animation, un tileset, etc.). Pour rendre tout ça possible, BmCC, le programmeur en chef, s'occuppe du moteur de jeu central qui est scripté en Lua... j'ai d'ailleurs l'intention de creuser un peu comment ils s'y sont pris.

Le résultat est des plus sympa, avec un côté résolument 8 bits 1/2 ... mais attendez vous à mourir. Beaucoup. Mais toujours avec le sourire.

"Another visitor ... stay well ... stay forever !"

Par contre, le code a beau avoir l'air relativement générique et très customisable, quand je vois des choses comme ce paquet de if (...or...or...) je me dis que j'ai bien fait de suivre l'approche "proriétés des tiles et fonction cando()" de Xargon, tiens.

liens en vrac:
original design : http://www.itchstudios.com/psg/platform/platform2.htm (archive.org'd)

making it a sketch :
Methodology : Engine + LUA scripts for objects, bonus, etc. + BQanim text files

Thursday, November 18, 2010

open-sourcing apple assault ...

The engine behind apple assault is open source from the start: this is my (modest) gift back to the world for having provided wonderful open tools such as Firefox, Linux, gcc and devkitpro. The problem so far is that pixel art, on its side, required a lot of work from myself, and I consider it as my own intellectual property that I want to keep under control. As a result, Apple Assault itself was closed source so far: publishing source without the art would not have run properly.

Le moteur d'Apple Assault -- tout comme l'ensemble des outils que j'ai développé pour DS -- est Open Source. C'est ma manière de récompenser tous ceux qui ont travaillé à d'autres produits open source que j'utilise tous les jours. Pourtant, jusqu'ici, il n'était pas possible d'avoir les sources complètes du jeu lui-même, notamment parce qu'il aurait de toutes façon été impossible d'obtenir une version fonctionnelle du jeu à partir de ces sources sans que je ne vous donne également les planches de sprites utilisées par le jeu. Et ça, je n'y tient pas: elles m'ont demandé des heures de travail créatif et acharné. Je souhaite qu'elles restent ma propriété intellectuelle.

Mais le petit script "8-bit-ify.pl" écrit ce midi devrait prochainement changer la donne: j'ai la possibilité de réduire la qualité des graphismes (leur donnant au passage un petit look 'C64' assez rigolo) tout en conservant l'entièreté de la fonctionnalité du jeu, et sans devoir passer par des phases de conversion de données fastidieuses. Avec le passage vers SVN comme outil de contrôle des version en prime, je devrais pouvoir vous proposer une version "commentée tutorielle" du jeu d'ici la fin du mois ^_^

Hopefully, I wrote a quick "8-bit-ify" script that convert the art (mostly killing details) such that it is still possible to compile and experiment, but not to fork a new project reusing the original sprites and tiles. Together with a switch to Subversion rather than CVS as the project revision control, you can expect a full open-source Apple Assault to come out soon as tutorial to the usage of my tools and libraries.

Somehow, it's fairly odd to play with those C64-feeling graphics at full framerate :P

source released on 24.12 MMX on Sourceforge.net

Tuesday, November 16, 2010

vsnes à la rescousse...


Bion, nous y voilà: à gauche la version SNES, à droite la version GBA. Même lieu (le boss du chaudron), Dixie sélectionnée et Diddy en mode "suiveur" dans les deux cas. Ambiance sombre et dantesque sur SNES, grosse bouillie rougeâtre à droite. Qu'il s'agisse du sol, du décor de fond ou de la lave, on a l'impression que la version GBA n'a eu droit qu'à un seul dégradé ... Je pourrais refaire la même analyse avec plein d'autres screenshots, je pense.

Face to face, the SNES and the GBA version of Diddy Kong's Quest (DKC2). I'd like to find out whether there was a technical subtle difference between the video hardware of the two that would explain why the GBA version is so ugly to my eyes... something like "DKC2 used an infamous 256-colour mode thanks to an on-cartridge bank switching device" or whatever... I used vSNES to analyse the use of video resources by DKC, but I couldn't find an evidence of such a techical explanation. So my only guess so far is that the colours have been changed *on purpose* to meet the rendition capabilities of the backlight-less screen of the GBA. Hover the screenshots below for english comments.

Avant de commencer à dire ce qui aurait été faisable ou non sur GBA, voyons un peu de quoi étaient faits les jeux de RARE sur la SNES.

J'ai trouvé un outil assez ultime pour ça: vSNES, un analyseur de cartouche et de savestate ... Comprenez : je démarre la ROM dans l'émulateur zSNES, je presse F2 pour sauver l'état, je quitte, et vSNES va interpréter l'état sauvé (contenu de la VRAM, notamment) et me permettre de visualiser les couleurs utilisées, le tileset (avec les différentes palettes disponibles), le rendu de l'écran dans les différents modes (DKC en mode 7 donne un résultat assez ... inattendu)

Première observation: 64K de mémoire vidéo pour la SNES, tileset et sprites partagés, les deux travaillant avec 16 couleurs par pavé de 8x8 pixels (les "tiles", vous vous souvenez). Chaque sprite et chaque pavé sur la map peut choisir la palette de 16 couleurs qu'il utilise, ce qui explique que j'ai des bananes oranges et un donkey correct à gauche, et des bananes correct avec un donkey psychédélique à droite.

Deuxième observation, les couleurs sont bien en R5G5B5 sur SNES, tout comme sur GBA. On aurait donc en principe pu reprendre les images de DKC (et de DKC2, vu que je n'ai pas de raison de penser que cette partie-là du moteur de jeu a été modifiée entre les deux épisodes) et les afficher telles quelles sur GBA. On a 3 plans dans le jeu SNES, la seule subtilité est que la priorité des tiles (devant ou derrière les sprites) peut être manipulé tile-par-tile sur SNES (comme sur la SEGA Genesis, donc) alors qu'il faudra obligatoirement passer par un layer supplémentaire sur DS ou GBA.

J'espère trouver un outil similaire pour GBA (no$gba sous Wine, peut-être) pour faire la même analyse sur la version portable du jeu. Ma seule hypothèse jusqu'ici est que l'écran de la petite portable (sans rétro-éclairage) aurait conduit à un jeu inutilisable si les graphismes avaient été conservés tels quels. Si je remets la main sur la DS Phat de ma fée, je pourrai peut-être me faire une meilleure idée...

Sunday, November 14, 2010

Bleeps and Bloops...

Je dois avoir découvert Donkey Kong Country II chez un gamin en '96 ou '97, qui m'avais demandé de lui passer un de ces niveaux au-dessus de la lave dans le Chaudron du Croco. Le jeu m'avait fait une forte impression et je sais l'avoir fini sur SNES avant de me lancer dans la chasse au 103% avec ZSNES. Mon frère l'ayant dégotté en GBA -- alors qu'il n'a jamais été très Donkey --, je lui chippe une petite semaine. Hélas, le portage n'est pas à la hauteur de l'original: son "rabotté" qui sonne "début des années 90 sur Amiga" et des graphismes curieusement pauvres en couleurs ... Le gameplay semble être resté assez bien le même, mais garder le bouton 'B' enfoncé pendant tout un niveau se révèle pénible sur DS lite avec mes paluches d'adulte. Déçu, donc, mais intrigué de savoir pourquoi Captain N a ainsi décidé de massacrer un chef-d'oeuvre d'immersion sensorielle pour le faire tenir sur une console près de 10 ans après sa sortie sur SNES ... Voilà ce que j'ai trouvé au niveau du son.

My brother dug two GBA cartridges that we tested last week-end : Donkey Kong Country 2 and Super Mario World -- two major SNES hits that were converted to "prime" the new console. Both turned out to be fairly disappointing, esp. DKC2 that sounds and look like a cheap clone. This post collects pointers to the audio specs of the original Game Boy, the Gameboy Advance and the Super NES in an attempt to explain why the "cool sound" of the SNES couldn't be retrieved and why the SNES tunes usually sound more like MIDI than like tracked music, although the hardware 'looks' tracking-compatible.

Game Boy :

2 square waves, 1 programmable 32-sample 4-bit PCM wave, 1 white noise, and one audio input from the cartridge.[25] The unit only has one speaker, but headphones provide stereo sound (for further information, see Game Boy music)


En clair, au niveau rhytmique, on est proche de ce que fait le beat-voxing: un son masque complètement le précédent. Et celui qui veut faire dire "Ghostbuster ... wha hahahaa !" a sa console doit reprogrammer à la volée le buffer de 16 bytes jusqu'à ce que l'ensemble du sample ait été joué. Oui, quand ils disent "32-sample", ils parlent bien de 32 bytes si le son avait été 8-bit, et de 16 bytes vu qu'on a que 4 bit par échantillon. Rien à voir donc avec le "sample" d'un soundtracker.
Autant dire que quand "Zelda: Link's awakening" nous chante une mouette qui passe, le "z80" ne doit pas être loin du 100% d'utilisation de ses 4MHz tout mouillés (en fait, non. La mouette est faite à coup de square waves, et pour le reste, c'est surtout la technique des wave tables qui est utilisée).

SNES et son SPC-700 -- une sorte de System-on-Chip intégrant un CPU de C64 (6502), des unités de conversion Analogique/Digital, de l'ADSR en hardware, lecture de samples à vitesse variable et mixage hardware pour 8 pistes. 64KB de RAM dédié au contrôle de tout ce petit monde (et aux samples, évidemment) grâce à un programme pour SPC qui aura été "uploadé" depuis le CPU principal de la console. Ca me rappelle un peu le tandem ARM7/ARM9 de la DS, mais en horriblement plus custom :P

GBA :
The GBA supplies four 'analogue' sound channels for Tone and Noise (mostly compatible to CGB sound), as well as two 'digital' sound channels (which can be used to replay 8bit DMA sample data).

La réalité me semble un peu plus tordue: deux canaux de "square wave à timbre programmable", avec enveloppe simplifiée (linéaire, quoi), et un de ces canaux est capable de "portamento" en hardware. On a un canal de bruit (canal#4) et un "chipsound programmable" similaire au canal 3 du bon vieux gameboy. A côté de ça, deux canaux jouent ce qui sort de la ROM (ou de la RAM si on veut faire un modplayer) à grand renfort de transfer DMA -- exactement comme une Sound Blaster 8 bit, donc. De quoi expliquer le "look" si particulier de la bande son de Zelda: Minish Cap qui mélange "sons gameboy" avec des strings orchestraux et des voix numérisées pour les personnages. Pour jouer un .MOD de 4 pistes sur cette console, il faudra faire le mixage et le traitement de la hauteur de la note entièrement en software sur le processeur ARM à 33MHz. Si c'est techniquement possible, on aura sans doute plus grand-chose comme puissance de calcul à dédier au jeu lui-même qui devient une sorte "d'annexe au modplayer" façon Crazy Brix. Il faut aussi rappeler que le GBA a relativement peu de RAM (32K, plus de la "EWRAM" à accès probablement plus lent, mais dont je n'ai pas saisi le rôle précis jusqu'ici), et que si le SPC de la SNES pouvait laisser la lecture des samples au hardware dédié, avec un mixage en software, ça passera forcément à travers le même bus que le reste des données...

I'm pretty sure you remember your good old 486 DX 33 and his soundblaster, right ? That computer had the guts to do software rendering of a multi-track sample-based tune, but still, 90% of the games you can find on any DOS museum site will use AdLib (or clone) for the background music. And for a good reason: doing software real-time mixing of the samples will consume a good deal of your CPU's power. Yet, that .MOD tune you're struggling to play was likely written on an Amiga 500 clocked at 8MHz -- but that had dedicated hardware for bending, shaping and mixing samples. The very same thing occured between GBA and SNES : the GBA inherited from the sound system of the original Game Boy and has a stereo DMA channel to stream something else -- including something that is mixed in real time -- where the SNES had a slower clock speed, but hardware sound mixing.

plein d'infos sur le son du GBC (sauf à quel point celà diffère du GB :P) On notera sur GB et GBC la présence d'une ligne "audio IN" de la cartouche vers la machine. Pas souvent utilisée commercialement, mais ça ouvre la possibilité de monter un soundchip ADlib sur une cartouche GBC pour se faire un remake ultime de Fury of the Furries ;)

Saturday, November 13, 2010

Download AppleAssault 1.4

-- Oh wait. You could download version 1.6 instead !
Voilà, ma petite puce m'a enfin laissé assez de temps pour passer le dernier coup de polish sur Apple Assault que je peux du coup vous proposer en version "1.4". On y retrouve le "super-poing", des transitions entre les niveaux, correction de quelques bugs d'affichage dans l'écran-menu, support de la musique multi-piste amélioré. Je crois que c'est tout. En principe, ce sera la dernière version: je prépare un package "sources" et je passe à la suite.

See this post for the latest update on Apple Assault featuring the berry bat and revised apple rate.

Here you go: Apple Assault in its final "1.4" version. You keep fighting against apples, using your punch, big-punch, shuriken and evasive moves. This release introduce transitions between levels, improves support for multi-part soundtrack, and fixes minor graphical bugs in the menu screen. I don't plan to evolve this game further on : it's time to move to other Bilou games as soon as I have a source package released.


Introduction
Bilou et Bouli viennent juste de se crasher sur une planète étrange. Pendant que Bouli répare l'écran protecteur de l'Astrocruiser, Bilou doit faire face à une horde d'applemen déchainés !
Le jeu se joue sur 4 secteurs (nord-sud-est-ouest) que vous devez nettoyer avant de passer au suivant. Sautez d'abord sur les applemen avec (A) pour accumuler de la force de frappe que vous utiliserez pour les expédier au loin avec (B). A chaque vague d'assaut, les applemen sont plus nombreux. Jusqu'où tiendrez-vous ?

Bilou and Bouli have crashed on a strange planet. While Bouli is repairing the Astrocruiser's repellor shield, Bilou (the blue ball) has to keep hordes of crazy applemen away ! The game feature the four fields surrounding the cruiser that you must clean up so that Bouli can finish his job and provide you a safe retreat for further exploration. Stun the applemen by stomping them (A). That will provide you more punch power to dispatch the assaulters further away (B).
In each assault wave, the applemen will come back with reinforcement. How long will you stand ?


trucs & astuces
  • pour faire progresser la barre de punch plus vite, rebondissez sur les pommes (en réappuyant sur A au moment du choc)
  • les petits vers ne peuvent pas être éliminés, mais vous pouvez aussi rebondir dessus pour augmenter votre punch sans pour autant approcher les pommes.
  • dès que votre barre de punch est remplie (elle vire au jaune et une musique spéciale se fait entendre) , Bilou peut lancer un shuriken dévastateur. Par contre, celà vous videra de tout votre punch de moitié.
  • plus vous enchaînez les rebonds sans toucher le sol, plus votre score grimpera vite !
  • choisissez votre niveau de difficulté en mangeant des pommes dans le menu.
  • Funky Funghi, le champignon du niveau 4 est invulnérable. A contourner soigneusement.
Bug connu: bloquage du jeu possible si vous fermez la console pendant un chargement de niveau. Investigations en cours ...(corrigé dans la version -ld)

gameplay tips
  • you can build up your punch power faster if you press (A) again when bouncing on applemen
  • yellow worms can't be dispatched, but they can "help" Bilou building punch power while staying at safe distance from apples
  • once you've gathered enough power (your punch bar turns gold and the music change), you'll shoot a devastating shuriken instead of merely punching.
  • the more bounces you chain without touching the ground, the more you'll score.
  • check out the gameplay teaser video if you still can't beat level 2.
  • grab apples on the menu screen to select harder game difficulty.
  • Funky Funghi, the mushroom of level 4, cannot be defeated. Focus on the apples and don't mess with him.

If you think the gameplay choices are odd or bizarre, think of Apple Assault as a game in the lineage of Mario Bros. -- the initial, non-super one or Bubble Bobble


Historique sur dev-fr.org
Le projet sur Sourceforge

reported to work succesfully on R4, SuperCard DSTWO (Cid) and Acekard2i (Cid).
Fixed Bug: closing the lid just while the game (re)loads a level no longer leads to a livelock.

Special Thanks:

Thursday, November 11, 2010

Stuck again >_<

A peine avais-je corrigé cette histoire de "blocage en tombant au sol" que je me rends compte que Bilou peut à nouveau se retrouver coincé dans un mur >_<.
J'ai un peu pataugé pour trouver le soucis (de nouveau lié au changement que j'ai introduis il y a une ou deux semaines), entre autres parce que je cherchais au mauvais endroit. La dernière fois qu'une telle chose s'était produite, c'est le "StopController" qui ne vérifiait pas que Bilou ne rentrait pas dans les murs. Mais cette fois-ci, rien.

Himmel! Just after I fixed the land-and-got-stuck case I mentioned last week, I got a phone call from GuiEngine, asking me to find out who smashed Bilou into a wall up to the point that he became definitely stuck! Once again, I suspected a side-effect of the new way events are managed, and investigated collision checks in StopperController who were involved in similar cases a while ago.

J'ai finalement repris les choses à la base, avec la fonction "pas à pas" de l'InspectorWidget -- maintenant totalement rétabli, pour me rendre compte tout d'abord que c'était bien pendant que Bilou marche qu'il heurtait les murs, mais aussi que le problème ne venait pas d'un signal FAIL mal traité, mais du fait que les contrôleurs (en l'occurence la gestion de l'inertie) générait des EVENT à tort et à travers, court-circuitant certains tests.

But the stopper was innocent this time. I was sneaking on the wrong guy. I was walking down dark, cobble streets, under pouring rain with hope that one of my contacts would sing me a clue... in vain.
I sat down and opted for another strategy, reviewed the facts and the pictures shot by Inspector Widget one after the other, and the truth at last appeared to me in a flash: Bilou was walking when he got embossed into the wall. It turned clear that DDD had lied to me and that he should be paid another visit. "You asked me about FAILures!", he said crawling on the ground, "I told you all I knew about them !..." - "You did", I replied, "and still you knew there was more to tell. Where can I find DPAD and Momentum ? They're hinding since the start of this case!". Panting and flickering, it didn't take long for DDD to sing after I pointed my breakpoint at him. Before the end of the hour, I had Momentum tied on the back seats of a car: he'd never forge fake speed limit reports again.

Wednesday, November 10, 2010

Apple Assault = ?€

If you're reading this with an RSS reader, chances are that you've missed the "You would buy Apple Assault for ..." poll that will close within 10 hours. The idea is simply to help me figuring out the new trends as I've never been that much into buying ringtones or logo myself, under the hypothesis that Apple Assault was available, polished in its ideal final version, e.g. on the DSi. So far, the poll suggests that 1€ would be a bit too high, and that ~40% of this blog's audience isn't ready for pay-download-and-play systems.

Voilà, si vous voulez participer à l'enquête "combien vaut Apple Assault", il vous reste encore 10 heures pour faire entendre votre voix. On parle ici d'un Apple Assault finalisé et hypothétique qui serait à la disposition des masses sur DSi Ware, par exemple, ou un "game store" similaire pour une autre console.
edit: poll closed, figures updated

Thursday, November 04, 2010

Got Stuck ?


Hover me
Dans un vrai développement, introduire quelque-chose comme les transitions en cas d'évènement liés aux contrôleurs alors qu'on est en phase pre-alpha n'est pas souhaitable. J'aurais été au boulot, j'aurais au moins fait un "svn copy trunk/ branch/..." avant de m'y attaquer. Mais voilà: c'est un projet-hobby et la liste des choses à faire entre une version et la suivante n'a plus grand-chose d'excitant...

This is something you'd never see occuring in a "real" project, but this one is a hobby project. I may know very well how to use SVN to create branches and avoid that an experimental feature triggers a bug in a pre-release, and I do it on regular basis for work. I just don't care too much about it when it comes to hobby project: I do what I wish yo do when I feel so. And so I may end up with Bilou curiously getting randomly "stuck" again when he hits the ground, not responding to DPAD anymore, etc. It doesn't even get hurt by Applemen, as you can see...


InspectorWidget, functional, but not fully restored yet
Bref, je me suis retrouvé à avoir Bilou bloqué de temps en temps au moment où il touchait le sol. Fort heureusement, InspectorWidget n'était pas bien loin, sans aller jusqu'à dire qu'il soit complètement opérationnel avec ce changement d'écrans ... Mais je ne suis pas mécontent d'avoir passé du temps sur ce petit débuggeur intégré l'été dernier: alors que j'avais sèché sur le script "bilou.cmd", il m'aura suffit de reproduire le problème et d'appuyer sur [START] pour découvrir que ce n'étaient pas la chute, mais bien les manoeuvres d'évasion qui étaient en cause.

This is where InspectorWidget turned handy again. I was cautious enough when I disabled it for AppleAssault, and it wasn't very far away. It's tempting to claim "all I had to do was to change bool InspectorWidget::FullyQuiet = truefalse; in main.cpp, but the recent swap of screens required a bit more tweaks and cleanup. And as shown below, it's not yet fully recovered :P
Yet it was sufficient to point me at those evasive moves for further investigation -- I was searching for bugs in the regular "falling" states until then -- and the fix should now be trivial.

/* fixed: la plupart de ces bugs d'affichagent étaient dûs à la redirection de la console (consoleInitDefault() vers l'écran du bas qui détruisait les caractères personnalisés par Engine::createChar() :P */