Plummet (2)

Et si le fait d'avoir une plume changeait fondamentalement l'humeur des encriers de la School Zone ? Au point qu'il ne leur vienne même plus à l'esprit de lancer des gouttes d'encre.
Et si ces plumes, Bilou pouvait les transporter d'un encrier à l'autre profitant d'un vol plané d'encrier à encrier.

Techniquement, ce ne sera pas pour School Rush, mais j'aime bien l'idée...

The recent chat about techniques that could extend the number of sprites the GEDS engine could support on the DS opened some new paths and led me to funny ideas such as "what if Bilou could use quills to move from one inkjet to the next one ?" and then "how would an inkjet feel (and look) when he's got a quill in ?".

That might not reshape the SchoolRush game, but I love how it turned out

revising build system

Once upon a commit, was runME, a tool to assist game development on NintendoDS by embedding a game engine, WiFi transfer functions and launch buttons to sprite, level and animation editors. Revising a level should have been as simple as click "LEDS", update the area that wasn't suited to the gameplay, "save and play" to return to runME that would allow you to run the game with its new layout. Editing monster's behaviour should have involved at most a similar trip to SEDS and uploading some revised scripts from a laptop PC.

Nothing like that still occur with SchoolRush. The code layout and the build system makes it extremely tedious to maintain identical feature set for the game's own binary and runME. Slight differences between the two means the game will not play as expected and even will even fail to run on runME because some 'plugin' controllers (the C++ toolkit to build game state machines) expect different arguments. RunME is almost exclusively used to beam .spr and .map files out of the DS to be tested in emulator on the integrated game binary and them beam back the .nds into the DS after some preliminary tests were made on emulator. That's likely the slowest development cycle you could think of :(

Un jeu est sorti. Je m'autorise donc à prendre un peu de temps pour faire de la maintenance dans du code qui en a bien besoin. En particulier le système de gestion des compilations. Ce ne sera pas aussi élégant que ce qu'on a construit au boulot avec mes collègues, mais je reprends quand-même quelques idées... J'élimine les VPATH, notamment. Je regroupe ce qui peut l'être dans un 'common.mk' inclus depuis le makefile de chaque projet, etc.

J'espère que ça me permettra de recommencer à faire de l'exécution dans runME quelque-chose de plus fiable, de façon à pouvoir tester un niveau gribouillé sur DS sans devoir le re-passer par le PC.

I'm on a quest to make it better, drawing experience from the buildroot-derivative project we're dealing with at work. I have hope it will also ease the task of writing unit-tests for LEDS and SEDS that will make them more reliable tools: I've got way too many instances of "data recovery" in the last edits of School Rush.

Maybe I'll have to push myself to avoid re-inventing a "dlod" systems for the plugins and accept that a static library and proper re-compiling statements is all I need: a first intermediate build of "plugins.a" allows me to look at all the things that the bunch of controllers need from the environment to do their job. If I was able to offer that via in-runME patching, I could just upload a new "ppplatformer.bin" to the NDS and have runme work with the update functions. Admittedly, beaming a new runme is simpler and does the job.


[edit] J'aurais pu suivre une alternative intéressante: celle des modules Linux. Dans ce cas-là, c'est l'équivalent de mon "common.mk" qui est fourni à make, et l'emplacement du module à compiler est passé en ligne de commande avec un M=. Du coup, les "raccourcis usuels" qui donnent presque l'impression qu'on a affaire à un dialecte de makefile sont encore plus transparents. Un inconvénient pour un projet dont la base d'utilisateur est plus réduite, peut-être ?

make -p et LevelEditor.elf

Bon, moins drôle. En voulant tester une variante de LevelEditor qui ne conserverait que les personnages effectivement sur la map, je me rends compte que LEDS ne compile plus. En fait, SEDS et AnimEDS non plus: j'ai oublié de vérifier que mes modifications du game engine ne "cassait" pas les éditeurs ^^". Heureusement qu'au boulot, j'ai des "buildbots" pour m'éviter ce genre de mésaventures.

Allow me to be much more technical, please. I have some build system issues with the editors. Somehow, I forgot to maintain them as I was upgrading the core library for the game engine library, and some parts of the engine are shared with the editors. Although I don't have build bots setup for this project, I can use some makefile-debugging techniques I developed working on buildroot-based project. The #1 trick being the existence of '-p' flag for GNU make, that let you review every single variable and rule instantiation and understand what goes wrong much faster than by adding echo commands here and there.

Heureusement aussi, j'ai découvert l'année dernière l'existence du flag "-p" pour GNU make, qui nous fait un dump de l'ensemble des variables internes du makefile, avec en prime la ligne de makefile qui a défini cette variable. De quoi retrouver sans trop de difficulté que les options pour générer la "map" au moment du link sont erronées, et de rajouter un "--cref" histoire d'en apprendre un peu plus.

The core issue I'm facing is that LEDS is now trying to include the core part of the game engine, that parses scripts and does game object updates frame by frame. Clearly, it's not required for the editors. And the editors are not ready to include it, because they don't provide details on the kind of game they are. As soon as 'make -p' allowed me to locate where to define additional flags for the linker and what the current flags are, I can enable the creation of a linking map, that will indicate which symbol triggered inclusion of GameScript.o and in which source file of the level editor it was invoked.

Oui, parce que le problème que je rencontre ici, c'est que tout d'un coup l'éditeur de niveau s'est mis à avoir besoin de la quasi-totalité du moteur de jeu. Qui en retour a besoin qu'on lui indique comment marche le jeu.

Reste à découvrir pourquoi "level.o" s'est mis à faire référence à ce AllocContext::active qui a "attiré" le parseur de GameScript à l'intérieur de l'éditeur de niveau ... ça, c'est un job pour GCC avec son flag -E (pour "fais juste le pre-processing et arrête-toi"). Pour ça, j'ai ré-injecter dans ds_rules du "devkitarm" une technique découverte ce matin dans buildroot: plutôt que d'utiliser directement '@' (oui, oui, comme dans les autoexec.bat ;) pour masquer l'appel d'une commande pour ne pas surcharger la console du développeur, on utilise '$Q ' avec 'Q ?= @'. Il suffit alors d'appeler 'make Q= ' pour avoir l'information complète, voire de ne définir la valeur par défaut de Q que si V n'a pas encore de valeur, ce qui permet un 'make V=1' pour '--verbose' bien plus facile à mémoriser. Je peux alors voir la commande exacte de compilation du fichier "level.cpp" et en introduire une variante avec mon fameux flag -E.

The last step is to understand why this "AllocContext" variable (it turned out not to be a function) is used. My best move for that is to capture the exact command that compile level.cpp and replay it with the '-E' flag that only goes through pre-processing and dump the result. I can then see the same thing as the compiler sees, search through it in a single pass. Once it's done and understood, it's merely a matter of moving those static variables into their own compilation unit, so that the linker can pick AllocContextDefault.o to satisfy level.o's needs without pulling the whole game engine along.

Et voici le chaînon manquant: un script est devenu un contexte d'allocation, et la définition du contexte d'allocation se trouve dans GameScript. Un petit déplacement de la variable "active", et ce sera réglé.

LivingStone, I presume

Les ennemis de Rayman, sur PSX étaient assez évolués dans leur comportement. Les "livingstone" par exemple -- existant en deux tailles -- ne se contentent pas de patrouiller sur leur plate-forme: le grand livingstone peut faire des pauses pour ajuster son casque, fuir effrayé ou se faire assommer d'un coup de prune.

Le petit "teigneux" lui, peut se mettre à pourchasser rayman, mains en avant, tenter de l'aggriper à distance et s'abaisser pour se mettre hors de portée de nos coups de poings. Pas encore exactement un personnage de Street Fighter, mais nettement plus sophistiqué qu'un goomba.

Ennemies in Rayman PSX were fairly sophisticated in their behaviour. The Livingstones -- one of the first monster you encouter -- not only patrol on their platform. They pause here and there, they can be frightened or stunned with bouncing fruits. Then you have the smaller living stone, detecting Rayman's presence, chasing him, or attacking with its hands. It is not yet as complex as a Street Fighter encounter, but not quite your average goomba either. 

J'étais donc assez surpris de constater que les "lividstone" de Rayman Origins sont fondamentalement statiques, occupant sans avancer (ni même se retourner ?) une plate-forme unique. Certains ont un bâton en main, d'autre une balle. Mais d'un point de vue "gameplay", ça ne change rien: ils se contentent d'attendre Rayman. Ils sont assez comparable à des blocs à pics sur lesquels ont peut sauter et qu'on peut casser. Enfin presque: une fois touchés, on peut se servir de leur "bulle" pour aller plus haut, encore que je n'ai pas encore vu beaucoup d'endroit dans les niveaux où cet élément est développé.

Comparatively, I was shocked to see Lividstones of Rayman: Origins almost static, standing on their platform wiht no additional move, not trying to hit rayman with their stick when they have one... just waiting to get smacked. They're functionally equivalent to spiky blocks that you could break with a punch. The "why" is pretty clear: make the game easier. What puzzles me is "how does it come it works? Why haven't I got any feeling of core gameplay being lost ?"

Que s'est-il passé, donc ? Pourquoi cette simplification à l'extrême et surtout où est la "compensation" dans le reste du gameplay qui fait que cette simplification n'a pas d'impact négatif sur l'intérêt du jeu ?

Dans "l'histoire de Rayman", on nous présente la méthode Hascoët qui répartit les challenge contenus dans les niveaux en quatre catégories:

• Rapidité: aller plus vite que la lave, grimper plus vite que l'eau, suivre un scrolling imposé, être parti d'un nuage avant qu'il ne disparaisse ... d'une fleur avant qu'elle ne se fanne... Bref, tout ce qui incite le joueur à rester en mouvement. Dans Rayman Origin, ce rôle est essentiellement joué par le "roi des lums" (score doublé temporairement) et par les bonus-en-bulle dont on ne saura profiter que si on arrive assez vite dessus. Mais il y aura aussi des pans entiers de montagne qui s'abaissent et mettent le joueur trop lambin en danger.
• Astuce: tout ce qui demande au joueur de réfléchir un peu pour résoudre un problème, comme le coup de la prune sur la tête du livingstone, ou parvenir à lui mettre un coup malgré ses stratégies d'évasion. Dans "Origins", l'astuce est souvent secondaire, mais les développeurs ont prévu de nombreuses situations où les plantes-interrupteur font apparaître ou disparaître des plate-formes ou des yeux-à-pointe. On peut ainsi à distance précipiter les lividstone vers leur défaite, les prenant à leur propre jeu. Bien rigolo à faire, en tout cas. Faute d'une récompense intégrée au jeu, on est récompensé par un sentiment de supériorité sur ces mécréants pathétiques.

• Précision: sauter/frapper pour atteindre un endroit en hauteur, ce sera l'élément principal dans Rayman PSX. Rayman Origins monte fortement les exigences ici, en particulière avec les défis des "pièces de la mort" qui demande des sauts et des rebonds impeccables. Je suis aussi tenté de penser que les nuances possibles que dans Rayman PSX, ne serait-ce parce qu'il y a plus d'inertie dans la course du personnage. En plus, ça n'aura échappé à personne, Rayman peut maintenant rebondir sur les têtes des ennemis, et on a droit à plusieurs constructions dans les niveaux ou on joue au parakoopa en rebondissant d'ennemi en ennemi pour les éliminer tous.
• Synchronisation: passer au bon moment ou frapper au bon moment. C'est peut-être un des éléments qui est en retrait, en tout cas dans les premiers mondes, encore qu'il reste quelques plate-formes mobiles pour aller récupérer des pièces de la mort, justement.

Tout vient d'la cache

Quand Eric parlait de faire des mises à jour à la volée de la mémoire au fil de l'animation des sprites, je pensais spontanément à un système semblable à celui de Donkey Kong Country: chaque personnage se voit attribué un emplacement en VRAM et les mises à jours pour ce personnage-là viennent systématiquement à l'emplacement alloué à l'apparition du personnage. Du coup, s'il y a deux "kritters" en même temps à l'écran, il n'y aura aucun partage entre eux: le nombre d'objets à l'écran devient fortement contraint, même s'il y a peu d'images indépendantes, comme dans le cas d'Apple Assault.

In my first attempt to understand Eric Zmiro's animation engine I thought the video memory would be managed somehow similarly to what happens in DKC on SNES: every new object on screen would receive a chunk of video memory large enough for the most complex frame it has to render and it would update its content during the vertical synchronization timeslice (or at some other time slice when the GPU isn't busy looking up those pixels). To some extent, the DKC engine would be an auwfully bad choice to implement a game such as Apple Assault, where there are a large number of similar ennemies on screen and high probability that a single block of VRAM is in use by multiple ennemies at the same time. That was failing to include the key ingredient in Zmiro's engine.

J'avais oublié un élément essentiel des moteurs de jeu à la sauce Zmiro:

Chez moi, tout est en cache : Fichier, sprites, palettes, bloc... tu n'allais tout de même pas dupliquer les blocs autant de fois qu'il y a d'instance ? si ? [...] avec ce systeme (développé sur GBA en 2000), on fait actuellement l'affichage de fonte (du texte!) avec caractères proportionnel sur XBOX one et PS4, codé en utf-8 et disposant de toutes les langues y compris chinoix, japonais et coréen ! Tu vois, c'est souple.

Like for tileset used by a gigantic and varied map, Eric introduced cache management algorithm deep into the animation rendering. Animation data refer to logical blocks and the mapping to VRAM location happens dynamically, reusing blocks when possible, importing new ones only when they are not yet in VRAM somewhere else and dropping unused one only when room is needed, keeping them available for the next animation cycle when you have few sprites on screen.

With this approach, no need for pre-defined locations, no need to do spritesheet optimizations such as "let's keep only one VRAM slot for the stunned dumblador and update it from main RAM to get the desired animation on screen". For every block in the SpriteSet, all we need is an additional short integer indicating whether the block is currently missing in VRAM or stored at some location between 0 and 1023. Everytime an OAM need to be patched to reference one logical sprite block (like "page 4, block 21), you can check the corresponding VRAM slot in the spriteset and copy to a free VRAM slot if none is currently assigned.

Fini donc les emplacements pré-établis. Finies les acrobaties du genre "je vais garder une seule image pour 'dumblador assomé' sur la spritesheet et j'aurai un SprAnim qui change son contenu depuis la banque d'image restée en RAM (je fais pareil avec les vagues d'encre actuellement): pour chaque bloc de données contenues dans le spriteset, il nous faut un nombre supplémentaire, entre -1 (absent) et 1023 qui indique l'endroit en VRAM où on peut trouver cette image-là.

A chaque fois que l'on veut reprogrammer un OAM pour qu'il fasse référence au bloc "page 4, image 21", on regarde l'emplacement VRAM associé, et on en alloue un en réutilisant un emplacement libre si le bloc correspondant n'est pas encore en VRAM. Avec 1024 blocs de 16x16, on peut avoir assez de pixels différents dans les sprites pour couvrir 5 fois l'écran de la DS. Le risque d'un objet invisible par faute de mémoire vidéo est virtuellement nul. Dans mon organisation actuelle, j'ai 128Ko pour les sprites, soit moitié moins, mais ça reste tout à fait viable.

Le côté génial du truc, c'est que tant qu'on alloue sur des blocs qui ne sont pas actuellement présents à l'écran (marqués comme libres), on peut faire la mise à jour de la mémoire vidéo pendant la phase longue où le GPU retrace les pixels à l'écran. Seules les substitutions où on est obligé d'éjecter un bloc utilisé lors de l'image actuellement dessinée devront se faire pendant la phase courte émulant un "retour de balayage".

Now, how would that work with Bilou's spritesheet ? I'm currently using about 1/4th of the video memory for Bilou's heads while only one is shown at every single frame. Streaming Bilou's head into a double-buffer as the animation needs it was one of my top improvements for AnimEDS. With a Zmiro-cache, I no longer need to allocate VRAM slots to GOBs. I no longer need AnimEDS updates. And potentially, I could have the whole set of heads used by the current animation in video memory, having only gradual updates of the VRAM as I switch between actions.

Alors, est-ce que ça marcherait avec Bilou ? Un bon quart de la VRAM est utilisé actuellement pour toutes ses "têtes" et une seule est affichée à la fois. J'avais bien l'intention de faire une sorte de "streaming par double-buffer de la RAM vers la VRAM" dans une révision de AnimEDS. Le Zmiro-cache permet de passer souplement d'un double-buffer à "seules les têtes utilisées dans l'action en cours restent en mémoire vidéo". Je gagne de la place et je peux (enfin) me permettre d'autres petites animations avec des grimaces, etc.

Les mains et pieds partagés par les crayons, les taille-crayons et Bilou ? Ils n'occupent pas beaucoup de place et ont de bonnes chances de rester présents en permanence.

Shared hands and feet (used by Bilou, pendats and dumbladors) only use a small area of the whole spritesheet. It's likely a 'least-recently-used' policy would keep them permanently in video memory. Bonuses, ink drops, dust clouds would likely come and go as needed, giving more room for ennemies frames.

How many ennemies could we host ? Well the critical point is more "how much VRAM slots will be off-screen at every frame?". If you have a free (off-screen) slot for every block you need to bring in for the next frame, then you don't need time-critical copies during the blanking interval. You have 128KB of sprites memory, which means 512 different 16x16 blocks. enough to cover 2.5 times the 256x192 screen of the NDS. The gameplay will become cluttered well before you hit the cache limits. 

Les bonus, gouttes d'encre et autres nuages-de-poussière-encore-à-dessiner ferait probablement des apparitions éphémères, forçant des objets dont l'animation tient plus déjà du "streaming" (p.ex. inkjet) à faire revenir une image de la mémoire centrale vers la VRAM.

Bref, vu le nombre de fois où je me suis "cogné la tête au plafond" de la quantité de VRAM disponible juste sur le projet "School Rush", introduire cette technique de cache pour gérer la mémoire vidéo serait sans doute la bienvenue avant d'envisager un jeu plus ambitieux ... disons de la taille d'un Commander Keen ?

Si j'étais graphiste ...

Si j'étais graphiste, mes sprites auraient plutôt cette trogne-là. Je saurais qu'une bonne animation, c'est une animation où on a pas peur de casser les cadres et j'arriverais à l'appliquer. Du coup, le meilleur environnement pour faire du bon travail, ce serait quelque-chose qui soit le plus souple possible. avoir suffisamment d'images disponibles simultanément pour les copier-coller et les comparaison. Bref, un outil comme SEDS ne me semblerait probablement jamais franchement pratique.

Let's be honest: I'm far from getting any close to what a real pixel artist produces. If I was, my spritesheets would look like those featured in Titus's Prehistorik II: I would not let canvas restrict myself and I would apply squash/stretch so that animations work fine. There would be significant pixels variation between frames, too. In a word, the SEDS+AnimEDS would be very unlikely to suit me. I'd need something more flexible, and in return, my game engine would need something to easily convert such flat sheets into usable assets.

Mais pour mettre des graphismes dans un jeu, faire des graphismes ne suffit pas: il faut aussi qu'ils puissent être intégré au jeu. Il faut que l'artiste puisse le plus librement possible retoucher son animation, y compris faire grandir ou rétrécir certaines images.

L'idéal pour ça, comme l'expliquait hier Eric Zmiro -- concepteur avec plus de 20 ans de métier -- c'est d'avoir le système le plus automatisé possible. Voici donc ce que j'ai compris du système qu'il décrit.

 I had the opportunity to compare the tools used in my own "School Rush" with the kind of tools and techniques that Eric Zmiro (now at Magic Pocket, and formerly developer of Prehistorik II at Titus). The core idea is to make the spritesheet-to-game data conversion as automated as possible. There cannot be any "great hotspot positioning tool" because there shouldn't be any human doing such task in first place.

From his explanations, I started to think about such automated framing tool, which is mostly a matter of separating lines that contain pixels from lines that contain none -- and having some conventions such as "an animation is bottom-aligned horizontally". Of course, there is still need to identify a reference position for each frame, so that e.g. the character's nose stays at the same position on screen while scrolling at constant speed, but a mere line of lone pixels could do the trick.

Sur base de la première planche de sprites, le premier algorithme à faire tourner est un système qui identifie les zones dans lesquelles il y a des images des zones vides. Une ou plusieurs lignes horizontale ne contenant aucun pixel (gris foncé): c'est une nouvelle animation. Une ou plusieurs lignes verticales ne contenant aucun pixels (gris clair) à l'intérieur d'une tranche d'animation: c'est une séparation entre deux étapes d'animation. On peut ensuite raffiner pour rétrécir verticalement la zone active d'un sprite.

1) on découpe les animations par planche (1 planche = 1 animation)
2) on a un outil qui capture les sprites, les convertie en bloc
3) quand un bloc existe déjà dans la banque des bloc, il ne le rajoute pas.
4) pour chaque sprite indique : [x, y, flipXY, color_index, bloc_number, size] (j'espère n'avoir rien oublié)

Si deux sprites sont identiques, ils seront partagés. Mieux, certains blocs peuvent être partagé même si ils appartiennent a des sprites différents
Encore mieux, des blocs peuvent être identique apres flip, ou être identique a une transposition de palette prêt..

Si elle me semble contre-productive, la décision "une animation par fichier" trouve tout son sens dans une équipe soumise à une date de sortie: sur une planche "prehistorik-man.png", on peut effectivement laisser le logiciel découper les bandes d'animations et faire référence à prun = pman[0][*]; pcrawl = pman[1][*]; pswim = pman[2][*]; pjump=pman[3][*]; etc. Mais imaginons qu'au terme de la production on décide finalement de laisser tomber le niveau aquatique. L'animation de nage tombe aussi et pjump devient maintenant pman[2][*]. Tous les autres animations doivent également être re-numérotée. On s'en passerait bien vu qu'il faut livrer la ROM fin de semaine pour que le jeu soit prêt début décembre...

But my understanding was yet one productivity-step below the Zmiro approach: by enforcing only one animation per sprites file, we now have a strong filename-to-game asset relationship. If the file is named pcrawl.png, then we can gather all the corresponding sprites as pcrawl[*]. When instead the 'crawl' animation is simply refered as the 5th one on pman.png, then we become vulnerable to the removal of e.g. 4th or 3rd animation, for instance because "well, the water level doesn't work, we drop the swim animation".

Yet, having the art split into multiple bitmaps doesn't mean that the tool importing them all cannot identify shared frames (or blocks) across the whole dataset. The final touch, for every frame the auto-cropper found, will be to isolate solid pixels into a minimum set of hardware-compatible blocks and pack the pixels of those blocks into tiles. The DS video chip, for instance, will only work with 8*W x 8*H blocks with W/H ratios of 0.5, 1 or 2 and a maximum size of 64*64 pixels. Even with a simple greedy algorithm, we can easily shrunk the amount of video memory required for a sprite to 1/3rd of the brute-force 64x64 sprite approach. Each batch of tiles has a companion set of OAM data that can configure hardware sprites' size, ratio position and indexes so that your 7 sprites actually look like a single, seamless cro-magnon protagonist to the player.

Reste à faire manger ça par le hardware d'une console comme la DS, qui ne fonctionne qu'avec des sprites hardware de 8x8, 16x8, 8x16, 16x16, 16x32, 32x16, 32x32, etc. jusqu'à 64x64. Sa mémoire est limitée, aussi donc avec un seul bloc de 64x64, le nombre de sprites affichables simultanément est sérieusement réduit. Ici, p.ex., on a un cro-magnon de 37x49 pixels qui prendrait 64x64. Avec un simpe algorithme de découpe "glouton", on peut le couvrir avec 4 blocs de 16x16 et 3 blocs de 8x16. Soit 6/16 de la mémoire nécessaire pour l'afficher d'un seul bloc.

AnimEDS travaille par petites éditions successives. Mais AnimEDS suppose que le contenu de la mémoire vidéo est constant. Ici, il n'y a aucun intérêt à garder un morceau de cro-magnon en mémoire si cette image-là n'est pas à l'écran. Du coup, tout ce qu'il faut c'est allouer un bloc de N tiles de sprites -- avec N assez grand pour la plus grosse étape d'animation -- et assez de blocs 'OAM' pour les contrôler. Pendant la synchronisation vidéo, c'est un nouvel ensemble "VRAM+OAM" qui est transféré simultanément pour changer les pixels que la console peut afficher et l'information sur quoi afficher où (les OAMs).

Then you need to have a game engine that can make the best use of these list of OAM datas. A real animator like those who work with Eric will easily saturate the 128K of sprite memory the DS has, so every new frame is likely to see new sprites tiles updated in VRAM together with the OAM updates. More on that in a future post.

Mais je ne suis pas graphiste. Il y aura encore pas mal d'eau coulant sous des ponts avant que je n'accouche d'un personnage pareil ... donc je vais garder SEDS et AnimEDS encore un petit moment. Par contre, si mon moteur de jeu évolue dans le bon sens, on pourrait envisager un outil d'importation des .png en .spr qui ferait ce genre de travail pour faciliter l'importation de graphismes non-SEDS dans un jeu tournant grâce à libgeds.

Climbing level and end-of-game

• [don't] don't insist on players grabbing "GO" to start playing. Pressing START anytime on the menu screen should work as well.
• [done] update LEDS so that it crops out-of-boundary monsters when saving -- that should be easier than at loading.
• [done] unit-test SEDS components and figure out what corrupts .spr files when editting
• [need] show number of lives and grant an extra life every 100 letters.
• [need] update build system so that the same controllers and 'guns' code can be shared by runme and games.
• [wish] Tease players with CJ's "hurry up" theme
• [done] implement pictures when the last level is beaten to support some story - or show it through some other mean.
• [done] update libgeds so that GOBs freeze/restore also react to the vertical axis

ps: oops that shouldn't have evaded to the Web so early :-P Well. You may remember I wrote once that I'd like School Rush to conclude in an ascend-the-tower like level. There are a couple of technical barriers before I can integrate that, but none should be a major issue.

Eh! Un post échappé. Mais rattrappez-le! Rattrappez-le! Rhaa! mais ils sont tous en train de courir après des pokemons ... Bon bin c'est pas grave. Voilà: je mettrais bien un niveau grimpe-jusqu'en-haut pour conclure School Rush. Il y avait quelques bricolages à terminer avant de l'ajouter pour de vrai au jeu (bon, puis il faudra que je le construise, évidemment). J'avais commencé une petite "toudouliss" pépère, et j'ai dû cliquer sur "Publish" au lieu de "Save" malgré la différence de couleur.

edit: petite idée qui m'est venu comme ça pour la séquence de fin: Bilou retourne gentiment vers la gauche d'où il vient pendant que l'encre redescend assis sur une éponge qui flotte. En chemin, on voit des "recto/verso" calmés qui font la sieste, des dumbladors rassurés qui peuvent enfin rejoindre les leurs, etc.