.fr ?

Bon, je ne vais pas y aller par quatre chemins: animer ce blog en bilingue devient trop lourd pour moi. Entre le boulot qui me tient beaucoup plus devant un écran, les trajets en tous ssens pour les activités extra-scolaires des loustics, et -- avouons-le -- un laptop moins convaincant dont l'écran n'a jamais la taille qu'il faudrait, je peine déjà à rédiger ce qui me passe en tête quand je gribouille une page de notes sur ma tablette-liseuse-scanneuse.

Alors le faire en deux langues, ça devient vraiment infernal. C'est aussi au détriment du projet lui-même. En théorie, la France arrive toujours en n°2 dans les statistiques. Ai-je encore des lecteurs francophones ? (ai-je encore des lecteurs tout court ?)

N'hésitez pas à vous faire entendre: le sondage "English /Français" court toujours.

Panic! GameInfo reading out of buffer!

Pretty weird error message. I don't know what triggers that. It doesn't interrupt the emulated program but kills the emulator itself, even when we're running in gdb-debugging mode. It happens while parsing some line of text in my "wave.cmd" script unless I invoke GobAnim::setWindowed() on an animation earlier on. The object parsed when the crash occurs has no relationship with the GobAnim that gets windowing-enabled.

• Panic! GameInfo reading 302251 out of ROM (302254)! 
• halting emu: ARM9 PC=020406A0/02000F0B, LR=0204069C 
• ARM9 halted 
• halting emu: ARM7 PC=037F9B84/037F9B7C 
• ARM7 halte

The crashing address happens to be within memcpy.

  break *0x20406a0 if $r3 + $r0 > 0x300000 && $r0 < 0xb000000

could be working, except that GameInfo doesn't start at offset 0, but apparently rather at offset 0x08000000.

A bit more digging (setting the right breakpoint, using one more desmume patch to reveal registers R0 through R3) finally allowed me to get a stack trace....
And the offending memcpy was part of a buffer refill for waves.cmd file. For some reason, by incrementing the size, I hit a threshold where one more copy is needed, but then the very last bytes can't be read because the emulator believe they should always pick a 4 bytes from the current position (instead of an aligned 32-bit word holding the byte). Simply adding a zz.zz file that will come past the waves.cmd file make the code work again.

Finishing steps for School Rush

• [true] ensure the music track for the last level is different
• [done] bring in the amazing books as the background for the final level
• [>>>] make a funny "true ending" sequence
• [done] draw something for the missing loading screen(s?)
• [done] inkjets start aggressive in hard mode
• [wish?] page-swap bonuses as player progress into the levels to m4ke him b3liv3 th3 m4th 4r3 t4king 0v3r th3 w0r1d (originally mentioned here)
• [done] resume the normal level order/spawn points.

And I still don't have vertical movement for floating spongebop.

Yup. No code tonight. Just took some time to crawl through the old "todo" posts and collect a list of things that are still pending. As I can allow less and less time at once on my hobby project these days, I need to organize myself more ...

To be honest, I'm starting to be attracted more and more by things that aren't related to School Rush and less and less by finishing School Rush itself. Possibly because we're approaching a big release at work ... possibly because the Internet seems not to care a lot about the idea of rushing School Rush.

I wanted to temporarily disable the "window" feature on the torch-light GOB (just to check it has the shape it should), but when I do so, I get a cryptic "Panic! GameInfo reading out of buffer!" message from desmume... I'll have to investigate that.

edit:

• [done] With the window disabled, it looks like the OAM flipping isn't working for my torchlight-sprite. I'll have to understand why
• [done] While hacking the get-ready-to-swim fix, it looks like I broke a rule in the Bilou-got-hurt rules, allowing pendats (which are both hurting and solid) to combo-kill you

.

out'm'up

The inscene'99 visit had been quite as success, especially regading the 100K game competition. My brother and I then tried to figure out what we would do on the next instance - obviously, our chance of making a good game were higher than making a big demo like the one envisioned for "samedi, tous in my home".

A comment by my peer "Gedeon" about how it was a shame that crazy brix was only using boxes for collisions pushed me towards the implementation of some pixel-perfect collision routines. I remember I wanted to do some pinball game, but after all, it was decided to go for a shoot-em-up. Our secret "games to do" folder had a long list aborted shmups, from the "Polycosmos" conversion of "space Mission", the failed "cosmowars" on RSD Game-Maker, and the aborted "Bilou sky quest" ... Nothing getting any close to our childhood golden award "Warhawk". So I picked the "Tyrian" palette and started to pixel some ships.

Retournons au passage à l'an 2000. La Inscene '99 avait plutôt été un succès en particulier pour mon jeu 100K, Crazy Brix. Deux choses étaient claires: 1) on y retourne l'an prochain et 2) on a plus de chances de parvenir à refaire un p'tit jeu en 1 an que d'aligner une mégadémo sur le thème "Samedi tous in my home"... Gédéon m'avait motivé à dépasser le simple test de boîtes de collisions pour le prochain titre. ça pourrait convenir pour un pinball ou un shoot-em-up. 

Des shoot'em'up abandonés, j'en ai déjà une belle liste derrière moi, à l'époque: le Space Mission pour C64, la BD impliquant le polycosmos, le "Bilou Sky Quest" annulé par un verre de Franta et le Cosmowars foireux sous Game-Maker. Pourtant j'aime ça quand c'est bien fait. Que ce soit Warhawk ou Tyrian si il y a des étoiles et des barres de vies, je suis partant. Et comme j'avais la palette de couleurs de Tyrian sous la main, justement, je me suis lancé.

The assembly code for crazy Brix was quite horrible, and I remember taking care of increasing the quality of the organisation for out'm'up. Especially, frames-to-aminations, level layout, and to some extent the sprites behaviour were described in a "data-oriented" macros system that looked a bit like game script, but converted straight into binary pointers and values -- something that was apparently common in MegaDrive games development.

The second key development was to support a dynamic list of sprites, allowing fancy explosions, lots of shots and even powerups where crazybrix couldn't even accomodate for anything but a ball and a paddle. Two lists, in fact. This engine was the first time I decided to split objects in two separate casts to reduce the amount of collision checks required.

While the level design wasn't very inspired, the game received a brilliant soundtrack, a classic but good-looking starfield effect and Out'm'Up won the first place - although mostly due to the lack of significant competition.

Même s'il a disposé de 3 fois moins de temps que Crazy Brix, Out'm'Up a eu droit au niveau programmation à tout ce qui faisait défaut à son prédécesseur: des effets d'explosions, des power-ups, des sprites ennemis, des niveaux programmables.

J'avais même une structure 'scriptable' pour permettre à mon frangin de passer au level design une fois le travail sur le son terminé, mais il n'y a jamais montré beaucoup d'intérêt. L'aventure s'arrêtera donc une fois la première place de la Inscene y2k empochée. Ce sera mon dernier projet en VGA + S3M. mon dernier projet MS-DOS.

drop your weapons

One of the most vexing gameplay bug I can think of in School Rush is that you can't enter inkjets when carrying a dumblador. That can easily lead to moments of panic for most reactive players and frustrating death for others.

I now have it fixed, by dropping the requirement of NO_WEAPON when entering inkjets, adding a "THROW" test area when being in the inkjet and ensuring that we DROP_WEAPON if this area ever gets triggered.

C'est probablement un des bugs les plus agaçants de School Rush: impossible d'entrer dans un encrier avec un taille crayon dans les mains (ouais, essayez donc vous-même, vous verrez). En phase de playtesting, ça donne lieu à des moments de panique frustrants pour les joueurs. Je corrige donc en retirant une contrainte sur une transition et en ajoutant un nouvel effet de bord.

What took me a bit too much time to figure out is that the impulse to drop an inkjet must be define as you enter the state with a F_THROW test area, and not on the found-matching-object transition expression (likely because the blador-side of the expression evaluation happens before the bilou-side expression).

OBJ-WINDOW: Look through the ink

The DS video is made of multiple layers -- this should be no news for you. One of the video registers define which of these layers should be shown on screen, but that register also enables and disable a more obscure feature of the NDS: the windows -- that is, the ability to define multiple regions on screen and give them different set of layers to be shown. When the ink raise in School Rush, I'm not simply painting black squares over the scenery: I actually reduce the window through which the scenery can be seen (with a setup where nothing at all can be seen out of that window).

Petit tour d'horizon dans le document "gbatek" pour voir comment fonctionnent les sprites/fenêtres, une petite particularité de la console DS qui permet de basculer entre deux réglages de visibilité des différentes couches graphiques du jeu. Jusque là, je l'utilisais d'une manière assez simpliste pour dessiner l'encre ou les "rideaux" qui ferment la scène à la fin d'un niveau.

Un simple rectangle dans ce cas-là, qui permet de voir toutes les couches à l'intérieur de la fenêtre et aucune à l'extérieur.

The use I have so far of the "window" feature is pretty basic, but a recent talk with Adrian (GBA developer) made me realise that it would be just perfect to allow the game to give us a hint on where Bilou is when he's swimming up the ink to safety. The trick is that some sprites can be used to create another kind of window. Rather than being rectangular, it can have any shape ... and will be much easier to use than reprogramming the size of the window as we get horizontal interrupts amiga-style.

Pour que l'on puisse voir Bilou nager dans l'encre, il me faudrait donc une deuxième configuration qui laisse voir une partie du niveau tout en gardant assez de noir. Il devrait suffire pour ça de changer un simple bit dans la configuration.

J'hésite un peu quand à la manière d'implémenter ça ... Plus précisément, sur la manière d'indiquer depuis les scripts du jeu que l'on souhaite passer un certain sprite dans le mode "fenêtre". L'idéal serait probablement que l'information soit retenue dans les animations elles-même, mais sans nécessiter de modification de AnimEDS.

En même temps, l'utilisation d'AnimEDS n'est nécessaire que si j'essaie de micro-optimiser et d'éviter un sprite 32x32.

There are a few implementation details I'd like to sort out before implementing that. I already figured out that it should be under the responsibility of *Gob + GobAnim classes, the *Gob being the only class that can manipulate OAM entries (including the OBJ_WINDOW_MODE bits) and GobAnim being a natural place to setup flags indicating that "this appearance of the sprite should be a window (or alpha-blended, or rotated)". I might give it a try with a single 32x32 sprite and dedicated "flags xxx" script entry before I go for something more integrated that could replace the Flicker command currently in use by e.g. inkjets... 

edit: got it working. (by Oct. 14th) Some pixels to edit, now.

Thanks, ::Twig

On y est presque. Un mois après l'arrivée du Boox comme remplaçant du Cybook, j'ai réussi à faire un petit script Perl convertissant la sortie de Doxygen pour que le e-pub reader le plus puissant de l'appareil (point de vue navigation) parvienne à afficher correctement les extraits de code. Et ce grâce à l'aide d'un petit module plutôt bien foutu -- XML::Twig -- permettant d'écrire dès règles du style "si tu rencontres
<div class="line">...</div>, remplace par <tt>...</tt>".

Yo! One month later, I finally have a nice Perl script for converting stylesheet-heavy doxygen output for the super-navigating (but style-agnostic) reader application embedded on my Boox device.
The XML::Twig package I used for the job seems pretty powerful -- and much easier to use than XmlStylesheetsTransformationLanguage, as far as I am concerned.

I can't help but dreaming about pushing it further and have blog excerpts integrated with code snippets on an enlightening document that would progressively turns the readers into code writers that would contribute to dsgametools ...

Il serait très tentant d'utiliser ça pour faire aussi un peu de fusion blog/doxygen, d'ailleurs. histoire de reprendre les schémas UML dans le code navigable.