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é

TrackSequence : public Animator

Ce coup-ci, c'est fait: j'ai enfin la possibilité de programmer des séquences d'actions en réutilisant la partition musicale comme "séquenceur". Ce n'est encore que moyennement utile vu le petit nombre d'actions disponibles dans le "dictionnaire" de guns.cxx, mais ça me permet par exemple de faire tourner une petite musique "Level Clear" avant de lancer le démarrage du niveau 2. A terme, je devrais pouvoir y insérer fade-in, fade-out, etc.

Cleared. I can now have a sequence of action performed timely with a musical pattern. The TrackSequence acts as a timeline on which you can insert new "guns" actions. I still have to populate the "dictionary of available actions" with more useful things for the effect to be any impressive, but it allows me to inform the player that he's done with one level (with a sub-tune) *before* I actually launch the loading of the next level. Fade-in/Fade out would come next, then remote control of remaining Gobs (esp. Bilou).

Btw, you'll find a new little poll on the blog, a companion for the 1.3 release of apple assault. Personnally, I think AA is barely a shareware demo for a not-yet-existing game, but we're now in the era of InstantFun(tm), downloadable content and casual gaming where you can buy iFart on the market. So by curiosity, how much do you think "Bilou : Apple Assault" is worth (per unit) if it was completed and available on such a store ?

Au passage : nouveau petit sondage sur le blog : combien selon vous vaut "Apple Assault" ? Perso, je le vois comme une démo un peu plus aboutie ... une sorte de "teaser shareware" pour un jeu complet qui n'est pas encore là, mais vous, là, qui téléchargez des oeufs de Zerg sur votre iPhone à la pièce, vous en donneriez combien, sur DSiWare ? (je parle d'une version achevée, bien sûr, avec les effets de transition terminés)

edit: résultats du poll.

on pattern(%%) do { ... } as x

One of the next challenge to handle for the GEDS engine will be the support for timed sequence. Such as "close the door, shake the ground, and now the boss can enter". Or more simply, "play the 'dead' animation, fade out, reload the level". As mentioned earlier, I could simply associate each of these individual actions to a row in a pattern of the soundtrack. That makes timing implicit, and it should ease the synchronisation between the two.

Beyond the syntax, the idea is to have TrackSequence as an external action that stores its own list of external actions and associate each of them with a row number. The TrackSequenceReader would then be an Animator that launches the individual actions appropriately. Well, my brother has partly "recovered" the improved soundtrack, and I have modified the NTXM player so that I could look at the current pattern/row position... things are getting in place for some tests.

S'il reste un aspect encore fort "amateur" de AppleAssault, c'est sans aucun doute la gestion des évènements genre "oups. t'es mort", "level clear" et autres "game over man". Didier les comparait même à des "crash windows" ... Avec mon système axé sur les machines d'état et tout ça, j'ai longtemps galéré pour trouver une approche, puis je me suis rendu compte que je pouvais tout simplement associer ça au suivi d'un pattern dans la musique. Il y a même moyen de procéder assez simplement en réutilisant les "iGun" déjà en place dans la machine d'état pour capturer les actions à effectuer dans un TrackSequenceGun qui lance leur exécution dans un Animator supplémentaire (lesquels me servent plus ou moins d'activités parallèles sur la DS).

Surprisingly, it seems that the most complicated part doesn't lie there, but in the management of the "shuriken rush" sub-tune that needs to be activated and de-activated depending on your "punch bar". "Surprising" in that the HUD logic -- and not the game logic -- is the place where it fits the best. Troublesome, isn't it ? And untidy, too.

edit: It's getting in place, but still buggy on many aspects.

todo: add Bxx support to NTXM so that we can loop sub-sections of the module.

Sound Effects

Bon, il est temps de faire du bruit. Voilà le bout de code de la libntxm qui traite les nouvelles notes lors de la lecture du pattern. Le reste du temps, le player se contente d'ajuster le volume et de traiter les effets définis par une "cell" (une case du pattern).

Pour pouvoir faire des effets sonores, il faudra en quelques sortes que j'appelle ce même code à la demande depuis le processeur ARM9, probablement en réutilisant la technique d'IPC qui a servi à indiquer que le module devait être lancé ou arrêté (cf. NTXM7::updateCommands et le fichier command7.cpp)

It's been roughly 1 year that my game engine is waiting for sound effects. Let's see how to proceed, and add them to the ARM7 NTXM player that is the core of sound playback on the DS. This post is a sort of "exploration mission" to see how i'll proceed with programming them.
Primo, if i want to issue sound effects, the first thing to do is to ensure that I can invoke the "playNote" function (and surrounding code) on request from the game engine running on ARM9 . The most likely approach will be to mimmic the IPC approach 0xtob used to instruct the ARM7 to start or stop playing the whole song.
Funny enough, all the "commands handling code" always look the same. PLAY_SAMPLE and PLAY_INST commands already exist (i guess 0xtob needed them for the nitrotracker), but the actual stubs are missing. On the other hand, the "proxy" functions at the ARM9 are already present in command9.cpp ; they just lack an API in ntxm9.cpp ...

It should be running in a couple of evenings. It's really a shame it took me so0o long to check it out. It sounds that most of the effort will be to make GobExpression invoke ntxm9::playNote(), after all.

Tss. Même après l'an 2000, tous ces codes de "gestion des commandes" se ressemblent. PLAY_SAMPLE et PLAY_INST existent déjà, j'ai même déjà struct PlayInstCommand. Ils ne sont juste pas encore implémentés, mais Oxtob a bien préparé le terrain, pas de doute. Eh bien on va y remédier.
Cerise sur le gateau: CommandPlayInst et CommandStopInst sont déjà là dans command9.cpp ... Il reste juste à ajouter ça à NTXM9 et à faire en sorte que ce soit appelable depuis le GameScript et confrères.

edit: okay. Ca marche. Les pommes font "bzing!" quand on les prend. Il a fallu un peu plus de code que prévu du côté du game engine: c'est la première fois qu'une GobExpression du script appelle du code C++ ;)