Saturday, September 29, 2012

Yellowl and Redowl

I tried again, with the updated SEDS and properly charged battery. I could save a first draft (just the shadow lines), and then when I tried to save my "finished" work, the editor crashed again. That's *really* getting on my nerves, now.
Hopefully enough, I had a real camera powered up and ready-to-shoot just one floor below, this time, so I've shot pictures of my screen and did some Gimp post-processing to try to enhance and restore the picture into something that could be shown or fixed afterwards. I started the owl again, from the 'shadow lines' that were saved, using the version of SEDS I submitted to NEOflash compo. Everything went fine, and I made tons of intermediate saves. Then I thought "oh, well, that should be it for now", and clapped the lid of the DSi. As usual, I then thought of a small last improvement I could do, so I opened the lid, applied the change and tried to save again ... stalled. So this is what goes wrong: I cannot read/write to the SD media card anymore after I put the device in "sleep mode" for a while. And that happens regardless of whether I use the "1.x" or "2.0" version of my GUI engine.

Thursday, September 27, 2012

owl story ...

I took the time to print out Facet's edit on my school owl so that I could train myself and draw a new one on my DSi. It was starting to come out quite nicely, but unfortunately, I've lost it. For some reason, SEDS stalled when I tried to save my new piece of pixel "art" on a new file.

Voici hélas tout ce qu'il reste de ma scéance de dessin de hibou sur la DS ... l'idée de faire d'abord uniquement les zones les plus sombres dans une "couleur stencil" avant de doubler la taille n'était (à mon avis) pas mauvaise, mais au moment de sauver mon travail sur la carte mémoire, quelque-chose a coincé sans crier gare et je me suis retrouvé (une fois de plus) avec une DS qui ne répondait plus aux commandes au moment de définir quel fichier de sauvegarde devait être utilisé. La batterie de ma console était fort faible (je n'ai même pas su la relancer), j'espère que c'était juste ça... Ce n'était pas encore la dernière mise à jour de SEDS, non plus.

Was the linker no longer able to access the media card ? Was there a bug left in that r1056 version of SEDS ? was the battery's low level critical when power was needed again by the flash hardware ? I have no idea, but that's getting troublesome ...

N'empèche, ça m'ennuie ... il serait temps que mes outils de game-making sur DS redeviennent fiables.

Tuesday, September 25, 2012

So many palettes!

This time, I do it the correct way: I start mapping which (hardware) palette is used where so that I can later properly track copies that goes on all over the place and figure out why I can't properly load/store palettes in that "multipal" update.

Many of the operations you can do on the PaletteWindow actually involve copies from one of the palette into the others. Ideally, they are all synchronised...
  •  as soon as you start editing your palette, it differs from those of the "upper screen" which are kept static
  • "okay" button copy the edited palette into SPRITE_PALETTE_SUB, allowing a preview on the current sprite page
  • if you're fine, "sure" button copies the edited palette on BG_PALETTE_SUB as well. It's now officially your working palette for the grid.
  • At anytime, you can undo something by clicking "oops", which copies BG_PALETTE_SUB back as the edited palette. 
There's something the multipal approach changes, however: what is now stored in the .spr file is the offscreen set of (up to) 4 palettes, which is updated every time you flip to another slot. So "okay/sure" only affects how you will draw pixels in the close future, not what is actually stored when saving. The bare minimum I can do is to ensure that onscreen->offscreen update is performed when clicking "okay" as well. 

I *could* also enforce this synchronisation when going out of the PaletteWindow, but that would break the former user interface convention (where going out without having pressed "okay" at all means you won't save your palette edits). To overcome this, and avoid data loss, I introduce an additional offscreen undopal[] where I can automatically store data, and a "lost" button that can recall what was on screen the last time you left the palette edition "window".

Monday, September 24, 2012

branch/noswap

Le support du mode "multi-palettes" dans LEDS m'a obligé à revoir un point assez noirâtre de mon moteur d'interface graphiques: les widgets dynamiques. Bon, c'est un peu pompeux de les appeler comme ça, j'avoue: il ne s'agit ni plus ni moins que de pouvoir cacher certains éléments à l'écran ou d'en modifier l'ordre de priorité au fil de l'exécution du programme. La barre de boutons qui apparaît et disparaît dans l'éditeur de niveaux, par exemple ...

La plupart du temps, je m'en sors avec un tableau dont je modifie l'emplacement final. Un bouton "undo" à faire apparaître ? nbWidgets++ ... il doit disparaître ? nbWidgets--. C'est aussi simple que ça. Dans le cas des boutons d'édition, c'est un peu plus subtil, parce que la "zone sensible" qui permet de construire le niveau couvre tout l'écran et qu'il n'y a pas moyen de "cliquer à-travers" pour toucher les nouveaux boutons. Jusqu'ici, je me servais alors de Windows::swap() qui permuttait deux widgets dans la liste d'affichage, mais cette façon de faire rend rapidement le code lourdaud et peu lisible, avec pas mal de bugs qui jouent à cache-cache dès qu'on essaie de changer quoi que ce soit.

C'était donc l'occasion d'essayer autre chose: des instructions de saut dans la table des "widgets". En clair, je peux maintenant avoir quelque chose comme


normal: (grille) (boutons) (palette) STOP
copie: (curseur) GOTO normal
recolor: (bouton sync) (bouton undo) GOTO normal
Je n'ai donc "plus qu'à" choisir le point d'entrée dans ma liste de widgets pour avoir le rendu souhaité. Note qu'heureusement, ce type de pratique était resté rare puisque j'ai la possibilité "d'empiler" des "fenêtres" justement pour éviter ce genre de manipulations. S'il n'y avait pas eu en plus la grande tambouille du changement de linker, je n'y aurais d'ailleurs probablement même pas consacré un post.

Monday, September 17, 2012

Let's get cracking

Okay, hardware is restored, it's now time to merge summer experiments and converge towards a platform for more pixels, more animations, more levels and more monster design experiments ...

  • [done] merge the 'z-order' branch back: it has proved it's a GoodThing
  • [done] 4-palettes LEDS must be backward-compatible with one-palette spritesets
  • [done] make sure we still see the background and monsters in 4-palettes LEDS
  • [done] restore disappeared iprintf (known bug)
  • [done] barebones to update colours on BG layer in LEDS
  • [done] ensure that LEDS runs on real hardware (fix blue screens when loading a .cmd file and when switching to colors mode)
  • [badbuild?] ensure it's still possible to L-pick tiles in draw mode
  • [bug?] need to press select twice in SEDS to enable PaletteWindow ? 
  • [done] something odd happens on SEDS when loading a spriteset while a non-zero palette is currently selected in PaletteWindow (palette #0 overwrites current slot)
  • [workaround] entering sleep mode breaks iPlayer's access to the media card.
  • [done] palette selection in AnimEDS as well
  • [fork] find something better than Window::swap() to structure widgets.
  • [bugfix] ensure that SEDS works in the noswap branch too (currently, it's all black!?)
  • [badbuild?] some widget only display randomly on real hardware
  • decide what to do with left-handed mode
  • [done] ensure I've got all the material to edit/test levels on the DSi (currently, something displays "T.M.A.P" and random tiles on the console, and the level doesn't load). LEDS apparently saved a map file as autoexec.cmd. Needs investigation.
  • [done] allow map2png.pl to work again
  • [wish] make map2png.pl work with swapped (and coloured) tiles too.
  • [done] complete the books tileset so that I can change books size (cf. CyanGmou's mockup).
  • [postponed] fix the landing bug for Bilou
  • [postponed] fix blador.cmd so that bladors can be stunned
  • [now] revamp the School's owl
  • [postponed] draw/animate some pendats
En clair, ça en fait du travail pour se remettre à avancer sur la School zone ... l'objectif, c'est bien sûr plus de souplesse pour construire les niveaux, plus de variétés dans les décors et de nouveaux monstres à développer.

    Sunday, September 16, 2012

    Linker de Bisounours pour DaySi

    Yes! ça y est! Grâce au matos gracieusement donné par ZeBlackOS -- à savoir un linker de bisounours iplayer -- je peux enfin faire tourner mes homebrews sur la DSi rachetée à Mr. Proper l'an dernier! Vu qu'elle avait même un chargeur de poche pour brancher sur port USB, ç'aurait vraiment été dommage de la cantoner à faire tourner Zuma Revenge pour ma fée :P

    Il pourra se vanter de m'avoir fait suer, note, au point que j'ai fini par craindre de l'avoir mis hors-circuit au moment de lui faire son "upgrade kernel" ... mais non. C'était tout simplement un problème de formattage. Si les gars de SuperCard insistent sur le fait que la carte microSD soit formattée avec leur outil dédié sous Windows, ils ont en fait une bonne raison: la mémoire de la DS étant limitée, il faut que la table d'allocation puisse tenir dedans.

    If you just found an iPlayer, but that it seems to stall after showing a blue logo screen but without going to the screen that says "DS Video Expert", chances are that you overlooked the vendors' recommendation for using their own formatting tool for your media microSD card. Granted, that sounds plain ridiculous. Every OS (decent or not) comes with a FAT formatting tool, and you shouldn't have to install third party to do that, and certainly not on a Microsoft OS!.

    Still, as the DS has limited memory, and given that using their formatting tool *did* unleash the linker's full potential, I can imagine the following scenario: the FAT driver of the linker's firmware is so crude that it *needs* to fit the whole FAT within 1Mo of RAM. A conventional formatting tool will instead try to come with settings that minimizes cluster size, so that you're doing the most of your filesystem... and dismiss FAT size as a significant issue.


    En l'occurence, ici, la carte de 8Go a été formattée avec des clusters de 32Ko (ce qui est modérément large, mais large quand-même), de sorte que la FAT soit juste un rien plus petite que 1Mo ...
    (Bien sûr ça pourrait être un autre détail: taille du répertoire racine, le nombre de clusters réservés ...)

    En toute logique, j'aurais pu obtenir l'effet souhaité sous Linux avec mkdosfs -s 64 -F 32 -f 2 -h 8192 ... Mais pour une autre taille de carte SD, il faut ajuster le paramètre -s en conséquence (#Go*8, je dirais).

    Here's the result of a filesystem analysis after supercard's tool "correctly" formatted my 8GB media card for iPlayer:

    SchoolTest> sudo dosfsck -n -v /dev/mmcblk0p1
    Boot sector contents:
    System ID "        "
    Media byte 0xf8 (hard disk)
       512 bytes per logical sector
     32768 bytes per cluster
      4404 reserved sectors
    First FAT starts at byte 2254848 (sector 4404)
         2 FATs, 32 bit entries
    969728 bytes per FAT (= 1894 sectors)
    Root directory start at cluster 2 (arbitrary size)
    Data area starts at byte 4194304 (sector 8192)
    242304 data clusters (7939817472 bytes)
      8192 hidden sectors
    15515648 sectors total
    dosfsck /tmp/disk.img
    Boot sector contents:
    System ID "mkdosfs"
    Media byte 0xf8 (hard disk)
         512 bytes per logical sector
        4096 bytes per cluster
          32 reserved sectors
    First FAT starts at byte 16384 (sector 32)
           2 FATs, 32 bit entries
     3992576 bytes per FAT (= 7798 sectors)
    Root directory start at cluster 2 (arbitrary size)
    Data area starts at byte 8001536 (sector 15628)
      998046 data clusters (4087996416 bytes)
           0 hidden sectors
     8000000 sectors total
    
    8GB formatted with special tool4GB formatted with mkdosfs under Ubuntu

    Pourquoi "de bisounours" ? Eh bien, parce que ce linker permet de faire tourner les jeux amateurs (dits "homebrew"), mais refusera de lancer les ROMs commerciales. Merci, tata Raymonde. Et merci à Pierrick de m'avoir filé un coup d'EEE main, sur ce coup-là. Et bien sûr Merci à ZeBlackOs pour le linker ^_^
    My last fear is gone, btw: although the linker's documentation mention directories such as MUSIC, VIDEO and HOMEBREW where we're supposed to place our files, it can still launch files that are at the root (e.g. beta versions of my tools) and that have been downloaded by runME (currently in /moving/) Mais du coup, je m'interroge: les difficultés que j'ai à faire tourner de manière fiable mes outils avec ce matériel pourraient-elles être liées à une libfat pas vraiment calibrée pour des clusters de cette taille ?

    Saturday, September 15, 2012

    Doxygen & Cybook : round 2

    That's for sure: doxygen output on a cybook is a great thing to plan the next update on my tools. I can do that any time while commuting, take simple notes and then just commit the changes into code when I get to a keyboard-enabled computer :)

    Still, that requires a bit of tweaking of my Doxyfile configuration:

    COLS_IN_ALPHA_INDEX    = 3
    ALPHABETICAL_INDEX     = YES
    REFERENCES_LINK_SOURCE = NO
    REFERENCED_BY_RELATION = YES
    FULL_PATH_NAMES        = NO
    Au fil des mois, mon cybook odyssey se révèle de plus en plus un puissant allié pour la programmation de projets-hobby. Toujours en poche (ou presque), il me permet de planifier les évolutions de mon projet à tête reposée, dans mon fauteuil, sans nécessiter de réimprimer à chaque fois la dernière version du code. Il a évidemment fallu un peu chipoter pour avoir des documents "pratiques" sur cet écran 600x800, en enlevant les numéros de ligne ici, changeant la structure du document là, etc. Mais le résultat est plutôt satisfaisant.

    J'aimerais juste que l'Odyssey soit capable de détecter les "clics" sur les schémas en mode "image map" (cf. p. 1629, par exemple) et que doxgen propose un mode "epub" natif qui m'éviterait de faire tourner "calibre" pendant près de 10 minutes pour la conversion html->epub.

    Once the doxygen files have been created, I need to post-process them to strip out line numbers in the code. There's unfortunately no configuration setting to do that *in doxygen* itself, and I lost the patch that forced doxygen to avoid generating them altogether.
    fe class*.html "mv % /tmp/% ; sed /tmp/% -e 's:/a>0[0-9]*:/a>:g;' > % ; echo % stripped"

    Last step is to get rid of <namespace>:: prefix in some classes name (in the class index) so that it actually fits 3 columns.
    mv classes.html /tmp/ ; sed /tmp/classes.html -e "s/>[A-Z][a-zA-Z]*::/>/g;" > classes.html

    Unfortunately, calibre is still über-slow processing this, and it looks like the Cybook Odyssey doesn't support clickable image maps. Anyway, if you want to give it a try (and have the hardware as well), here's the file.

    Wednesday, September 12, 2012

    new and improved

    Cette fois-ci, plus possible de retarder le passage au nouveau-blogger-tout-moche bien longtemps. Le hic c'est que la balise HTML que j'utilise pour faire un blog bilingue est détruite systématiquement (remplacée par un simple texte italique)Voici un test de préservation de la balise <em>;Plus important le main() doit pouvoir apparaître comme du code.

    En fait, la balise <en>, elle, reste préservée (mais elle n'est pas standard).  Si elle passe correctement sur les différents browsers, la solution consisterait alors à définir un nouveau .css pour que <en> soit affiché correctement dans l'éditeur ...This is a test for the future of this two-language blog. You should see this text in italic with a purple tint. If not, it means that your browser doesn't allow me to use <en> tag for english paragraphs. I used <em> so far, but the new compose mode turns those tag into <i> instead, killing my formatting at source level. I reported the bug to blogger with the "send feedback" several times, but it looks like they really don't care and keep pushing the "new and improved" version. I will survive, but that may mean that your RSS reader will no longer visually differenciate languages (chances are that it wasn't showing a different colour, already, but just slanted/regular text). I'm sorry. Blame google.

    em:Emphasized text

    strong:Strong text

    dfn:Definition term

    code:Computer code

    samp:Sample output from computer program

    kbd:Keyboard input

    var:Variable

    q:short quote

    Monday, September 10, 2012

    First multi-palette LEDS screenshot

    Si le post précédent vous a laissé avec des yeux grands comme des soucoupes, voici une petite image qui résume ce que donne le "multi-palette" hardware une fois ajouté à mon éditeur de niveau. Eh oui: les livres peuvent enfin avoir des couleurs différentes. Bon, on est encore loin du compte, parce que pour l'instant, ce sont les propriétés des objets (solide, pentu, ...) qui modifient les couleurs, alors qu'au final, il me faudra un outil de sélection de couleur à part. En plus, seul l'arrière plan (juste derrière Bilou) pourra voir ses couleurs modifiées, l'avant plan utilisant obligatoirement les couleurs de la palette "de référence".

    the multi-palette .spr file I crafted on my DS phat has been beamed and (thanks to Sverx's precious hints), I've got LEDS now working in extended palette mode, so that it can natively use the same tiles data for at least two different tints of books. I still have much to fix, but it's a nice first step.

    2nd at NeoCompo !

    That's rather a good suprise: AnimEDS was ranked 2nd (just behind Smealum's FPSMaker) at Neocompo 2012. That comes just in due time to cover homebrew hardware expenses and get me quickly back on track. Shopping time ^_^

    Congratulations fly to Alekmaul for his 1st place in the GAME competition with a cute SNES puzzle game reminiscent of Sokoban (actually a port of an MSX game, afaik).

    Saturday, September 08, 2012

    VRAM_E_LCD

    I previously messed up with the sources of "Tetris Attack" to gain experience with DS development. Among the things Sten used, there was multi-palette display, using an extra bank of VRAM instead of the "regular" PALETTE_BG and PALETTE_SPRITE.

     videoSetMode(MODE_0_2D |
    DISPLAY_BG0_ACTIVE | /* the background */
    // ... more settings
    DISPLAY_BG_EXT_PALETTE);
    // 128K
    vramSetBankA(VRAM_A_MAIN_BG);
    // 128K
    vramSetBankD(VRAM_D_MAIN_BG_0x6020000);
    vramSetBankB(VRAM_B_MAIN_SPRITE);

    The video mode initialisation we have here is fairly standard (note the old-time code with VRAM addresses still exposed to the homebrew coder :P), except for DISPLAY_BG_EXT_PALETTE flag. You can turn extended palettes on/off separately for sprites/backgrounds, or for top/bottom screens, but if you enable it for background, it's used for *all 256 colors backgrounds*. Period.

      // 64K, can hold palettes for all four BG layers
    // allocate for cpu access
    vramSetBankE(VRAM_E_LCD);

    // background
    Decompress((void*)(0x6880000), background_pal_bin);

    // blocks
    Decompress((void*)(0x6880000 + 256*16*2), sprites_pal_bin);
    // an alternate palette with colors dimmed so that we can
    // easily dim the whole playfield when the game is over...
    CreateShadedPalette((u16*)(0x6880000 + 256*17*2),
    (u16*)(0x6880000 + 256*16*2));

    This magic 0x6880000 memory address sits within the 'LCD-mapped' region and is where VRAM bank 'E' appears. Right then, it's "offscreen", somehow, just ready for setup by the CPU. Each palette is 256x2 bytes long, and each background will have access to its 16 palettes at fixed offset. In this game, we had the backdrop on BG0 (thus palette at 0x6880000 to 0x6881E00 = 0x6880000 + 512*15), "blocks" (or apples) on BG1 that has its first palette at offset 512*16 (0x6882000) and its second palette at offset 512*17 (0x6882200). That makes lot of room unused (15 unused palettes for BG0 and 14 unused palettes for BG1), but if you want them to use different palettes (e.g. being converted independently from each other), you don't really have a choice.

      // text
    Decompress((void*)(0x6880000 + 256*16*2*2), font_pal_bin);
    // more background...
    Decompress((void*)(0x6880000 + 256*16*3*2), singlebackground_pal_bin);

    Score and status are displayed with a tiled layer too, implying yet another palette is needed. He could have used a macro XPALETTE(bg,slot) defined as ((void*)(0x6880000 + 256*(16*bg+slot)*2), or (possibly), use bank F/G forcing BG 0 and 2 to share the same 16 slots, but ensuring that those slots in use by BG2 are never needed by BG0 and vice-versa.


    // then allocate it for extended palette use
    vramSetBankE(VRAM_E_BG_EXT_PALETTE);

    Enough setup: we let the video hardware access those fancy colours ^_^

    supercard and multi-palette

    There is one last thing I can do with my failed homebrew equipment: dig out my old SuperCard (slot 2), update the makefile so that it automatically apply DLDI patch if $DLDI environment variable is set, and work on that multi-palette support that will ultimately allow me to tint books in up to 16 colors in the school zone (only 4 slots atm.)

    Premiers tests concluants pour le système "mutli-palettes":voici un bouquin vert, mais qui peut redevenir rouge à n'importe quel moment. Et il ne s'agit plus d'un simple test grandeur nature dans SEDS: les palettes alternatives peuvent maintenant vraiment être sauvées dans des fichiers .spr et re-chargées plus tard.

    Thursday, September 06, 2012

    Now, that's annoying...

    Bon, DarkneSs, ma DS noire, est toujours en réparation ... Je viens de recevoir de ZeBlackOS un sympathique iplayer -- le linker de bisounours qui ne lance pas les ROMs commerciales -- mais j'ai encore du mal à le faire tourner convenablement... il "boote" sur la DSi, ça c'est déjà un progrès, mais reste bloqué au niveau des logos "loading": le message "DS Video Expert" n'apparaît jamais.

    Apologises to those of you who expected an activity boost after the first "owl school zone" level: you'll have to wait for me to fix some issues... I have only one working linker left until I buy some new parts or got other back from repair.

    Mes derniers développements se sont donc faits essentiellement sur la DS "phat" de ma fée, avec le 'faux' R4 SDHC que j'avais obtenu pour DarkneSs... Ce n'est pas génial pour les couleurs, mais pour éditer des animations et vérifier que tout passe bien sur hardware, c'est toujours ça... enfin "c'était". Les opérations de mise à jour de l'iplayer ont eu raison du système FAT de ma carte mémoire (oui, j'ai commis l'erreur d'essayer d'utiliser la même carte mémoire sur R4 et iplayer), bousillant au passage rungama.nds et sedsgama.nds, faisant disparaître ledsgama.nds, animeds.nds, spritea.spr (la school zone) et spritey.spr (la green zone). Rien de définitivement perdu normalement tant que les disques dur de mes machines PC tiennent bon, mais c'est tout de même très dérangeant.

    One left, that should be enough ? well, except it's the linker that has no built-in support for DLDI, on the DS that has poor color contrast. No art can be seriously built on that, and software upgrades will be a pain at best... Hopefully, I don't think I've lost any data although both green zone and school zone .spr files were killed by the mess that resulted from running the iPlayer firmware.

    Il me reste la possibilité de me rabattre sur mon bon vieux SuperCard slot 2 et son passcard associé ... le soucis, c'est qu'il ne supporte pas le DLDI. Je devrais donc veiller à ce que tous les fichiers transmis soient bien patchés pour super-card avant de les uploader ... plutôt pénible quand on se souvient qu'au départ le support supercard était d'office dans la libfat. Et non, m'sieur devkitpro, *je ne vais pas tenter la mise à jour système du dernier linker fonctionnel qui me reste*.

    Tuesday, September 04, 2012

    Smooth Slopes at last!

    After so many tests where I had to jump slightly when approaching the bottom of a slope, having flawless, smooth moves in the school zone almost feel magic!

    Funny enough, the doslopes() function that I crafted carefully was already flawless, but the defects were in the glu code (the walker controller) that interfaces that with the animation replay. As I expected from the start, the step-by-step movements system was the root of the problem. It essentially nailed down to 2 things, that occured when leaving a slope:

    1. in that case, I need to check whether the character could fall. Bug #1 was that I wasn't completely taking care of the horizontal adjustment in that case, and it resulted in "no, you won't fall at coordinates (99,60). you can safely move and stand at (100,60)"
    2. when falling down, the controller actually FAILs to keep walking, but that means (for the animation replay subsystem) that the defined speeds are cancelled. The problem is in the case of walking off a cliff, the horizontal move has been validated and it should *not* be cancelled. Only the absence of vertical move changes.


    I updated the demo link accordingly in the "back to school" post ^_^

    Saturday, September 01, 2012

    Back to School!

    Here's at last the demonstration of game engine improvement and new graphics for the School Zone, on a temporary soundtrack by Cyborg Jeff.
    There's no "gameplay" or "mission" yet: you can navigate through a single map, bop sponges and dumbladors and track bugs (there sure are some). The ink doesn't hurt yet, but the baddies do. How many roll-jump can you chain ?

    New features:

    • better animations with AnimEDS
    • transition animation (in jumps, mostly)
    • improved parallax scrolling
    Known bugs:
    • Bilou may pause at the end of a downward slope. Just release the DPAD and move forward again.
    • Bilou may get stuck in corners. I need to figure how and why.
    • Dumbladors can be trapped mid air.
    • If the bottom screen turns pink, you've entered debug mode -- known as InspectorWidget. Press 'L' trigger for frame-by-frame game or hold 'L' and press 'START' again to resume "normal" gaming.
    • if all you can see is "efs:/strtrk.xm not found" on black background, you're using an incompatible linker or emulator. If you're using desmume, you need to add "--gbaslot-rom=self" on the command line.
    Download SchoolTest.nds and have fun.

    Oh, this is the 700th post, by the way ^_^
    vu sur dev-fr.org, et - chose amusante - c'est aussi mon 700eme post sur dev-fr (et ça, je jure que c'est pas fait exprès :P)

    edit: just understood and fixed the slope issues.

    . . .

    This is the moment where everything packs up, where final touches are made so that animations, graphics and code must fit together well into a "SchoolTest.nds" ...
    That's the moment where I have to make choice and dismiss some potential improvement so that a release can occur.

    Nothing you create is perfect ... improvement could always happen ... Maybe it's a good day to die release