Next steps

• [done] sound effect for airgrab = sound effect for grab
• [done] import fixed maps
• [done] hint page for "hold B to grab sponge"
• [wish] keep easy/normal/hard text during the whole menu session
• [done] allow up/down to select the difficulty level during menu session
• [done] sparkles or something when you get a power-up.
• [done] colors matching for FLOAT power-up on both screens.
• [done] make sure the number of Punch power-up shown on the "book" are accurate.
• [done] get rid of the ARGH letters and dever's power-up on the main menu.

I believe when I got this sorted out, I'm ready to tease VIP players with my little game. But I'll have to proceed gently, one tiny step at a time or I'll be exhausted before the official summer break starts.

18/7: I got the sparkles thing done.

On s'approche, on s'approche. J'ai pu rassembler quelques derniers points à travailler sur School Rush lors d'une petite session de tests avec mon frère et la S-Team. Je pense qu'une fois tout celà traité, je serai prêt pour une release à montrer aux ténors tels que Kirby Kid, Eric Zmiro et le joueur du grenier. Celà dit, je vais quand-même y aller en douceur histoire de ne pas me retrouver à nouveau dans un état d'épuisement où je ne parviens même plus à lire les posts sur les forums quand je passe dessus ...

selective WiFi transfers.

My .spr files are becoming large. That's especially annoying when you remember that issue with DS-to-PC bandwidth issue, which I still haven't investigated more. Look at all that grey and all that purple: these are not used by the game engine. I started an evolution of RunMe where you could selectively transfer "tiles" or "sprites" or "animations" of one .spr file, and then reconstruct the whole file on the PC side, but it's dormant, waiting (yep, that one too) for the game to be properly polished.

Les limites du GobScript

Ramasser des éponges alors qu'on pouvait déjà ramasser des tailles-crayons ... ça n'aurait pas dû être aussi difficile que celà n'a été. Le fait que les objets soient numérotés plutôt que nommés empèchait toute possibilité de détecter les erreurs. L'autre, c'est que le copié-collé est le seul moyen de réutiliser une région substantielle de code.

Current GobScript is meant to be human-readable bytecode for the state machine. Yes, truly. The most obvious way to realise that is how everything is *indexed* rather than *named*. The upgrade introducing C pre-processor in the make process to avoid code duplication in the behaviour script has been generalized to all monsters of the School Zone.

Yet the recent modification of these behaviour show that it becomes quite tricky to maintain coherency when adding new features. For instance,

• [done] picking up spongebops was missing triggers and repeated bugs about stuck carried GOB when hit.
• [done] Pendat rushing don't hurt Bilou when stomping him because I haven't copied hitboxes when creating the new state
• [done] Stomp-and-grab blador in one move kills Bilou's horizontal speed and creates bogus camera conditions.
• [done] We may enter walls when trying to pick something on the ground, because of a missing 'stopper' micro-controller
• [done] stomping a blador while doing a air-grab allowed to move through because of a missing hitbox.

All this claims that I should now work on a higher-level language for editing, where I could express that "SpongeBop allows carry_me" and "blador allows carry_me" and that would imply some new states added to state machines, specific hitboxes in other states, transitions and such. Don't be surprised if I take that excuse to practice some Haskell, as there is currenty a professional incentive to master that language.

Je me vois mal utiliser les macros du pré-processeur C pour reproduire un motif du genre "une zone de collision dans l'état X permet de passer dans un état $CARRIED puis dans un état $THROWN jusqu'à ce qu'on heurte le sol, ce qui nous ramène dans l'état Y." par la seule ligne "using CARRY_ME(X,Y)" ou quelque-chose de ce genre. Dans le meilleur des cas, celà reviendrait à définir CARRY_IN=X et CARRY_OUT=Y avant un #include "carry_me.cmd.h" ... pas franchement le plus élégant, mais sans doute préférable à une duplication du code...

Ne vous étonnez donc pas si je prends le prétexte d'un convertisseur d'une version "maintenable" du GobScript vers sa version "machine" pour mettre un peu d'Haskell en pratique dans les prochains mois, hein ;)

DLODs for runme.

Scribbled notes on how to extend runme tool with a way to import plug-ins (or Dynamically-Loadable Object Directories -- DLODs) that would contain a set of controller, guns and effects required for a given game. So far, changing some of Bilou's behaviour require that you recompile controllers.cxx, which in turns mean that you also need to re-compile runme if you want it to work with your new code. I'd like instead that the map file indicating where the support code entry points are so that we can have DLODs that are statically-linked to work with one instance of runme, and loaded at a specific location in the DS's 4MB of RAM.

That's on my secret todo-list for about 7 years, but that won't be for this summer.

In a similar approach, I'd like a gobscript-to-c++ compiler that would replace run-time parsing of the script with build-time generation of a series of constructor/setters or static data.

Dinner Time. See ya.

Fixme list

"Don't Repeat Yourself" supported.

The few feedback I got for the "upgraded" school zone level provide some fairly interesting hint: some gameplay features will not be properly managed by players unless they're sufficiently pure. Give any reason for the player to believe that holding B could let him run and he'll fail to discover that he's got to hold R for that to work. So to get pure gameplay in Bilou, I still need:

• [blador:ok] Introduce monsters/ink interaction
• [MEDS] Dedicated animation when Bilou picks up something
• [done] Never "randomly start running", no longer run-on-turn-back, only run-on-land when one had running speed in the air.
• [done] no invisible ceiling to kill your jumps.
• [done] visual clue to tell whether you'll bounce or not.
• [done] visual clue that chalk may break when sufficiently stressed.
• [wish, D.I.P] bouncy-idle-sponge vs. low-bounce-swinging-bops.
• [patch] HUD with life meter. (and speed meter ?)
• [wish, adventure] visual hint for dead ends (?)

Il y a une leçon qui réapparaît à travers les divers retours que j'ai reçu de ma démo de la school zone: les éléments de gameplay ne sont correctement maîtrisés par les joueurs que s'ils sont suffisamment purs (les éléments, pas les joueurs). Par 'pur', j'entends 'le mécanisme se déclenche sur base des inputs, à chaque fois et uniquement dans ce cas-là'. Qu'il y ait la moindre raison que le joueur puisse se mettre à courir en appuyant sur B et celui qui en arrive là lors de sa première partie n'essaiera pas de maintenir R enfoncé pour courir. Par contre, il nous indiquera que 'ouais, courir, des fois ça va, des fois ça va pas'.

Le même genre de leçon peut être tirée pour les animations: une action différente du personnage sur son environnement réclame une animation différente. Le joueur doit pouvoir "voir" que son personnage fait quelque-chose de particulier. Pas d'animation "essaie de ramasser" quand il n'y a rien à ramasser, et il n'y a pas de raison que le joueur essaie de ramasser un truc quand enfin il s'en présente un.

(old) non-symbolic gobscript

All this (and further introduction of power-up with more conditional state transitions) will require more work on the state machine for Bilou which is already fairly complex (32 states, 170 transitions 0_0). 

I don't want to make the parser smarter on the DS side (e.g. I still don't want symbol tables or function definitions) but it's truly time I adapt the Makefiles so that e.g. GCC's pre-processor can be used to produce the "compiled" state machine out of more symbolic description.

(new) symbolic gobscript

Mais pour pouvoir modifier tout ça, il va falloir que j'aille replonger dans la machine d'états de Bilou, qui est déjà pas mal complexe (32 états, 170 transitions).

Je n'ai pas trop envie de devoir augmenter aussi la complexité du parseur qui tourne sur la DS (pas de table de symboles ou de définitions de fonctions, par exemple). mais je pourrais arranger quelque-chose pour utiliser le pré-processeur C pour me convertir une description plus 'symbolique' vers le texte brut compris par le code DS...

Pendat ready [zero day]

it's marching, it turns back. That's roughly all. I need to fix collision boxes, testpoint coordinates, make sure throwing a blador can stun them, etc.
Yes, you're right, I should be delivering you a .nds of that new level. Let's see how long it will be overdue :P

Desired state for the release:

• [done] The five monsters being present: Spongebop, Inkjet, Dumblador, Pendat and RectoVerso;
• [done] Monster behaviour is complete: it hurts you when you step in, it can be defeated unless it is planned to be invulnerable, it doesn't stop moving for some coder-could-guess reason;
• [done] Level is WYSIWYG: no trailing "invisible walls", no endless fall to some out-of-screen no-man's-land nor structures you go through although the same was solid just two screen before;
• [done] Hazards hurt: ink, pencils; Bonuses can be collected;
• [done] transition (at least a pause) when Bilou dies, so that player may analyze and improve;
• [done] bonus to guide player into perilous fall;
• [done] use (B) to pickup/throw bladors;
• [done] can't ride spongebop/inkjet when carrying a blador. 
• [ongoing] Some incentive to improve your exploration and play the level again.
• Coherent soundscape.

Le jour J est arrivé. Le .nds pas. Le pendat marche et fait demi-tour, celà dit, mais c'est à peu près tout. Il faut que je lui règle ses boîtes de collision, ses testpoints, faire en sorte qu'on puisse l'assomer avec les taille-crayons, etc. Bref, le mieux que je peux vous proposer c'est de faire le tri entre ce qui mérite qu'on retarde la sortie du jeu-anniversaire (liste ci-dessus) et ce qui peut attendre une autre release (liste ci-dessous).

Allowed to miss in the release:

• some sound effects;
• [wish] power ups; 
• throwing bladors mid-air
• [wish] sparkles, dust clouds, broken bits and other visual feedbacks;
• [ongoing] dedicated stunned animation for some monsters;
• [done] perfect alignment of Bilou when inkjet prepares for a throw;
• [wish] push-able inkjets;
• level 2;
• [done] fix for spongebop-out-of-screen bug; 
• [wish] reloading the whole level when you die.
• [done] ability to look down what is available;
• [done] clean display of Bilou's hand when holding a blador;
• [done] Clean RUN mechanics.
• [done] spongebop's coordinate reference for circular movement is the center of the character (same for the pin), not the top-left corner.
  

Sheets for AnimEDS.

The set of animations for the school zone is quite full now (here, you don't see the spongebop, for instance).
Some of them could be dropped in specific levels, but I just don't want to lose things I've crafted so carefully, especially if I know I might use them later on.

So, just like you have "sheets" of sprites in SEDS, there will be some "sheets" of animations in AnimEDS asap. I love thinking of "sheets" for that because i) the DS display is too small to show them all and ii) scrolling through linear large set has never felt comfortable when working with RSD game-maker.

On dirait bien que j'ai quand-même rempli le jeu d'animations auquel AnimEDS me donnait droit. Je vais donc introduire des 'planches d'animation' tout comme il y a eu des 'planches de sprites' dans SEDS. J'aime bien penser en terme de planches. Ca s'adapte assez bien à l'espace limité de l'écran DS et c'est plus confortable que les interminables listes déroulantes de l'éditeur RSD.

Ce n'est pas forcément la chose la plus urgente à faire là-maintenant, mais le fait que la page soit pleine n'aide pas à ajouter des choses comme "Bilou-dans-l'encrier", "la gomme tournée dans l'autre sens" ou "le crayon assommé". Du coup ...

RSD map editor: you had to scroll

in a flat list to get another tile.

Random thoughts:

• there are 8 columns per sheet, and less than 8 lines. That suggest using octal numbers for animations in game script could mean 226 is natevly translated into "page 2, row 2, column 6".
• [done] We'll need a way to move things around pages. It would be useful to consider the last two lines as belonging to a sticky page (e.g. page 7) that can be used as buffer space to move things between "structured" pages.
• [done] We'll need an input to dismiss one animation completely.
• [done] preserve ongoing animation while switching page
• [done] keep an "undo" for deleted animation, recall them pressing "DELETE" again.
• [wish] sticky page remains sticky across loads (implies content wouldn't be saved :-/)
• [done] avoid additional issues with LEDS' monsters rendering.
• [done] some random replacement still occur, apparently when coming back from the editor window
• [fixme] restoring deleted animation on another slot randomly makes source slot show an animation again.
• [wish] find some way to flip to the next/prev sheet (preferably without the stylus). 
• [wish] I can live with pendat's hands not having pendats colors on the thumbnail, but body's color reflecting the real choice could be important for level editor.
• [wish] flipped limbs rendered flipped on the thumbnail.

It might not be the most critical thing to do to progress on the project, but it might also be that none of the monsters have progressed this summer because this sheet is full. No room for Bilou-in-inkjet... No room for swapped bopping eraser ... No room for stunned pendat ...

RunME needs a fix.

Mid-summer has been fairily hostile to game/tool development, unfortunately... I'm stuck on level editor progress because I can't easily ensure levels I edit are working properly, as RunME struggle to launch them. The best I could do while *deline was exploring the joy of the sea-side was some documentation of RunME so that the following fixes could be performed:

• [done] file/directory selection information should get its own space on top-screen
• [done] not only the FILE*, but also the extension name (file type) should be accesible from the L+A launcher button.
• [done] beam-in files in the last directory used for beam-out.  [todo] currently, only typing a new mask on the "alphanum keypad" will activate that directory.
• [todo] buttons (SEDS/edit) shouldn't overlap.
• [todo] ensure we can move back to SEDS/LEDS/download mode at all time.
• [done] don't try connecting when there's no sink on a given slot
• allow beam-out to be cancelled.
• [wish] global_connectAP and wfcWindow::autoconnect should belong to WiFi widget. 
• [done] IP address and [wish] SSID shown on the top screen once the connection is established.
• [wish] allow .spr files to become autoexec.spr even though they're too large to fit our 256K buffer.  
• [todo] spritesheet loaded with L+A in RAM should be able to display their colours, despite the "extra palettes" setup.
• [done] a way to try again the WFC connection settings from the "access point selection" list, as they may contain WEP keys, too.
• [wish] enter WEP key in AP selection list.  
• [wish] use Window.active flag if "clicking on other screen's button" is a bug rather than a feature.

^ UI/transfers -- level running v

• [done] fix the 'unregister XFER' loop bug.
• [done] proper cleanup when 'returning' to beaming activities from a test.
• [todo] avoid InspectorWidget/LoadingWindow interference (active areas not reacting anymore, beam-in offers cluttering the display)
• [done] report hero/ennemy/none class in InspectorWidget.
• [todo] control log display, clear and end-of-test from Inpector widget. 
• [think] special InspectorWidget display mode on (breakpoint collision), showing both colliding GOBs' state *before evaluation occurs*, with the ability to step to the next frame (after collision occurs)
• [done] double-check .spr and .xm loading support: no jamming allowed.
• [fix?] how could die() end up showing blank screens (when leaving the running game)?

That makes a NeoCompo entry very unlikely this year, unfortunately.
But at least, it gave me time to sit down and think about what mechanics could nicely complement JUMP in the full-blown adventure game.

post-trauma-edit: I just picked Surt's tileset I used for LEDS release 0.1 with the hope that I could use it to prepare a "tutorial map" and ship LEDS for NeoCompo ... result? I quite certainly screwed'up my school0.map (and will have to recover it from some git) with parts of the tuto map because I hadn't changed *that* filename in "tuto.cmd" ...
When I tried to save back the map under "tuto1.map", the map got all cleared ... Unfortunately, LEDS is not ready for shipping to the world and an extended 4-days week-end won't help even though I'd decide to invest all those free hours in a compo rush, I'm afraid.

Spongebop Rodeo

I now have a (partly-)working prototype where Bilou can grab a Sponge bop and stay hooked while swinging, but I have to hard-code the offset between Bilou and the Sponge as arguments of the copycoords controller. Not so elegant. Plus, if I also allow to grab on Bladors (granted, that's a silly idea, but it helped for debugging :), those offsets are no longer correct and we're rather grabbing some point in the air over Blador's top-right corner >_<

Bien. Bilou peut maintenant s'accrocher aux éponges en balance. Il y a encore des soucis non résolus avec l'animation prévue à cet effet (d'où l'absence de démo jusqu'ici) et un désagrément mineur: il m'a fallu ajuster à la main et préciser dans les paramètres du comportement "accroché à X" la position relative de Bilou et de l'éponge. Au moment d'ajouter le comportement "assis dans un encrier", ça me démange un peu.

I initially had plans for making those "grabs" act on an are, and it would make sense to actually state "copycoords(a.bottom=b.top ; a.center=b.center)", but I've just said that accessing GobAreas within a controller isn't practical.
Expressions handling a collision have access to some extra-context variables (wc-wf) which were just involved in that "repel" behaviour that made inkjet "solid".

• xcontext[0] - wc -- collision flags
• xcontext[1] - wd -- unused (0)
• xcontext[2] - we -- X-axis center-to-center distance
• xcontext[3] - wf -- Y-axis center-to-center distance
• xcontext[4] -- not in GobScript - X-axis area overlap
• xcontext[5] -- not in GobScript - Y-axis area overlap

 The idea would be to use some GobScript to compute/force the desired location, possibly record it in some GOB variables and have the CopyCoords controller simply enforce that offset from the GOB variables.

Il y aurait bien des solutions techniques pour automatiser ces coordonnées relatives en "alignement vertical, centrage horizontal", à la façon des éditeurs de diagramme ... il y aurait même un "chemin de moindre résistance" pour construire ça dans le contexte actuel. Mais soyons honnête: ce n'est *pas* un élément nécessaire pour le programme. J'ai un seul objet auquel Bilou puisse s'accrocher de la sorte (l'éponge) et je dois de toutes façon utiliser une autre animation pour Bilou-dans-l'encrier (donc, autre état et autres paramètres). Ce serait donc de la généralisation intempestive et prématurée! Caramba! Ça le ferait pas!

I could thus extend the "interaction opcodes":

• A[p]: attach [with path] evaluating object to context object (works in hit and found)

D: detach evaluating object (works in any transition)

R[xy]: repels context object away from the evaluating object (works in hit and found) [only along x/y axis]

L[xy]: line up the evaluating object with context object (mirrored repel)

C[xy]: center the evaluating object with context object (wish)

Now, let's be honest. That's a "wish", not a "todo". I only have one grabbable ennemy so far, and only Bilou grabs it. "hard-coded" offset are just fine in that context, and alternative are "premature generalization". I thought about all this because I'll also need a "copycoords" when Bilou sits in an inkjet, but that will be another animation and another state, so other copycoords offset is just fine.

translucent ?

I managed to have some translucent effect through fast (60Hz) sprite flickering. That's mandatory if I want sprite-versus-sprite transparency. So if I want Bilou to look "inside" the inkjet, I need an extra patch of glass that will flicker over Bilou to partially obscure him.

J'étais tombé par hasard sur l'épisode "Spécial Disney" du joueur du grenier, dernièrement.  Après une bonne tranche de rire avec ma fée sur la partie "La Belle et La Bête", l'analyse (nettement plus grossière) de Fantasia par Infogrames me rappelle à quel point il est important de soigner la communication des règles du gameplay à travers l'aspect visuel. Le livre géant et menaçant qui est en réalité un bonus (et non un ennemi comme son aspect le suggère) et l'espèce de rond dans l'eau qui est en réalité une plate-forme.

Mais maintenant que j'ai le moyen technique de rendre les sprites transparents les uns par rapport aux autres, est-il intéressant de rendre l'encrier transparent ? C'est plus réaliste, sans aucun doute mais ça n'est pas forcément mieux pour autant. L'aspect d'Inkjet doit transmettre au joueur "solide, dangereux, mais pas blessant", et pas "fantôme immatériel mélangé à l'arrière plan". J'ai donc fort probablement commencé l'ajout des sprites rectangulaires (pourtant attendu depuis longtemps) sans que ça n'ait aucune utilité immédiate.

That being done, shouldn't the inkjet itself be translucent (against the background), and if so, how do I achieve that, given that the ink itself must remain opaque ? Basically, the only way is to separate the "glass" of the inkjet and the ink itself. That puts enormous stress on the vram as inkjet animation takes almost 1/4th of the spriteset so far. doubling it ? aouch. Hopefully, the ink only takes 16 pixels high, so that would be worth an update of SEDS to support wide (and tall?) in addition to square sprites.

Although its in progress, is it really wise to go that way ? Does the translucent inkjet on the right look better than the non-translucent (except for the patch) on the left ? Or does it rather look ghost-like rear object which you wouldn't expect to be solid and ride-able ? After all, form-fits-function is crucial in video games, and the only way to allow the player to have "eureka" feeling rather than progressing through frustrating trial-and-error.

Bref, c'est l'occasion de rajouter le terme "Form Fits Function" au tagtionaire... ce lien entre l'aspect et l'effet si cher à Miyamoto et qu'Infogrames a systématiquement ignoré.

PS: the DS also has 16-color sprites, and obviously, the inkjet shouldn't need more. Converting the whole sprite page into 16 colors could do the trick ... but that's not supported neither by the Game Engine nor by the Sprite Editor at the time of writing. At best, it's a wish.

PPS: pour ceux qui voudraient essayer le jeu, c'est par ici.

More slopes

J'ai envie d'avoir plus de souplesse dans les pentes que juste "45° dans quel sens?". Si ça n'apporte pas grand-chose au niveau du gameplay en tant que tel (un ennemi-marcheur en haut d'une pente garde un avantage stratégique même pour d'autres formes de pentes), ça permet de construire des niveaux plus "organiques", ce qui n'est déjà pas si mal.

I deliberately picked a side item that should somewhat be less braintensive to work on as Lil'son is now released. In clear, something that can take place in a FridayAfternoon branch. So let's see how we could introduce more slope angles (and shapes) in my game engine. I assume that most of these "extra slopes" will be designed in larger chunks of 64 pixel wide, like a staircase, a curved hill top or a pair of 22.5° slopes. 

En revanche, j'ai déjà saturé le nombre de "type de blocs" dont je dispose vu ma technique d'encodage. L'idée cette fois serait de combiner le "type" (encodé par élément 8x8) avec la position du tile au sein d'un bloc de 64x16. Si ça reste jouable au niveau du moteur de jeu, ça demande un support spécifique dans l'éditeur de sprite pour "préparer" ces blocs de 64x16 contenant 16 tiles alloués de manière contigüe dans la SpriteRam (alors qu'ils sont normalement alloués par bloc de 4) puis de les disposer conformément à ce qui est prévu pour un des type d'obstacles souhaités.
You may remember that I have 16 major tiles types, which can be freely assigned to any tile. This "chunking" is thus actually required so that we can use the offset of tiles within a chunk as an additional clue of "which sub-type of slope" we're walking on (and eventually convert that into the appropriate height array in the engine's data. No real difficulty is expected from the game engine code, but it requires that we can alter tiles arrangement in the sprite editors so that the "curved hill" uses appropriate tile numbers. Some UML/C++ joy expected ahead. One that really insists on implementing a SMW clone could rather use "gradual" (11.25) slopes rather than those curves.

En comparaison, le moteur de SMW (selon Lunar Magic) offre 3 angles de pente: 'normal' (22.5), 'gradual' (11.) et 'steep' (45). Au niveau du gameplay, les pentes 'steep' étaient les seules à pousser d'office le joueur vers le bas (si ma mémoire est bonne).

Bon, je sais, ce n'est sans doute pas ultra-prioritaire pour faire avancer Bilou, mais mon petit J.l.n est né vendredi dernier, ce qui réduit un peu ma liberté d'action. Un peu de bidouille dans les éditeurs devrait donc être plus aisé que d'aller créer du code pour de nouvelles interactions avec Inkjet.

Games of Thrown

1MB. throwing in action ...

mises à jour du moteur de jeu terminées: on peut ramasser et lancer des Dumbladors ... puis les re-ramasser et les lancer de nouveau. Enfin, toujours dans la même direction, je le crains, mais lancer quand-même.
Je vais pouvoir passer à l'implémentation des inkjets, du coup ^_^b

PS: attendez-vous à un ralentissement brutal et imprévu du rythme des messages de ce blog dans le courant du mois: *deline attend son petit frère j.l.n mi-janvier.

The game engine now supports throwing of bladors. Pick it up, throw it, repeat. Many things could still be refined including

• [done] having feet really hidden during the stunned animation.
• [drawn] having the bouncing feet looking like feet
• [done]allow the engine to shoot compound gobs too (new feet anim)
• [done] allow runMe to launch the level as well.
• [done] avoid one-way platform to corrupt behaviour of bouncing feet
• [done] throw in both direction, and just drop if you feel so.
• [wish] blador can stun baddies (and Bilou ?) while falling
• [done] fix the map
• [done] use dynamic palette assignment and get rid of those "crosses" marking Bilou feets in jump animations
• [done] areas that can trigger only one other GOB (or a single foot can be consumed by 2 dumbladors simultaneously)
• [wish] climb on stunned bladors, but still walk through them. 
• [done] multi-color that works in runMe too.
• [done] make sure we restart the level if killed, with colours.
• [done] allow bladors to recover next to walls.
• [done] Blador recovers when 2 feet have touched it.

I'll do my best to get all that sorted out quickly so that I could offer the world a new playable demo for Christmas. Earlier arrival of lil'sson could force me to tolerate some imperfections in that release, though.

pick a slot

I'd say "good. things are progressing" if that progress hadn't been done while I can't get due sleep, coughing and sneezing. Anyway, I'm done with some basic steps to confirm that a multi-slot palette can be loaded in AnimEDS. Much remains, that will need more lunch-thinking.

• [done] ensure multi-slot palettes are read correctly.
• [done] buttons to pick slot on skeletton-setup page.
• [done] selected slots reflect in anim edition window.
• [done] move swap bits of AnimCommands to their hardware place, to make room for palette bits.
• [done] limbs table can reflect palette slots
• [done] palette slot preference stored in animations
• [todo] frame editor that obey colour preferences
• [done] preview using real colours
• [wish] timeline using real colours
• [done] size up to 8 palette slots for pendats to come in.
• [done] dumblador using multicols and bilou's feet.
• [done] Bilou using multicols for darker foot & hand. 
• [bugfix] saving something multipal with AnimEDS kills all the palettes
• [bug] sticky palettes selection when changing sprites?
• [SEDS, done] ensure palette reorganization works in multipalette .spr files.

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.

Gauchers

Utiliser SEDS n'était déjà pas très facile pour un gaucher ... LEDS et AnimEDS, c'est encore pire. Or, mon frangin et mon filieul sont gauchers et clairement intéressés à faire leur propres petites maps...

si ça, c'est pas un tout-doux-il-t'aime, alors il n'y en a aucun sur ce blog :P

How sort of a godfather would I have been if I couldn't hear the crying voice of a little left-handed boy who's willing to draw maps with LEDS but struggle to use the current controls ...

So let's do a first try and allow swapping of L and R trigger buttons that should already help a lot. I'll need to meet a left-handed again to check whether keeping map navigation with R+DPAD sounds like a good idea or whether I should also swap DPAD and ABXY...

Vu sur Internet ...

J'aime assez bien la "jaquette" que les rédacteurs de scenebeta.com ont mise en place pour mon éditeur de sprite, lors de sa version n° 4. Elle me donne d'ailleurs une idée pour une extension d'enfer: encodez un bitly, et on "charge" l'image correspondante sous forme .spr directement comme spritepage supplémentaire ^_^

Par contre, les échos qui me reviennent parlent régulièrement d'interface perturbante, où on ne sait pas trop qui fait quoi... Comme dit Morukutsu "on sent que c'est fait pour moi, et pas pour un utilisateur". Ce qui n'est pas totalement faux, mais qui doit le devenir :P

Voilà à quoi ressembleraient (imho) les écrans "gestion du fichier" dans SEDS et AnimEDS respectivement, avec cette nouvelle "ouverture au monde extérieur".

The notification of AnimEDS' new release has started propagating from newsboard to newsboard in a totally uncontrollable fashion. Welcome to the world of homebrew :P I just hope that the next wave of newsers will check out this blog rather than blindly quoting gbatemp's news, as 'AnotherWorld' has completely missed what was new in this release : you can create your own character skeletton.

Meanwhile, I also stumbled upon a post about the latest version of SEDS on scenebeta, where the newser made up a funny "cover" for the tool, depicting a megaman sprite re-worked again and again to show various Capcom characters ... yes, that too could be a use of SEDS. I guess all I still lack is a simple way to import some graphics from the Internet for that ... Maybe some online png->spr tool combined with a bitly encoding of the source URL would do it ?

Dans le même temps, un rédacteur de gbatemp a repris la niouze de la sortie de AnimEDS 0.2, mais sans trop se fouler. Notamment, il reprend texto "The application is still in the early stages of development and is hardcoded for a specific layout of the .spr file.", alors que la création de nouvelles structures, c'est justement ça que j'ai apporté entre la 0.2 et la 0.3 >_<

Revising animation delays

A chaque utilisation d'AnimEDS, la liste des imperfections s'allonge. Ici, c'est la gestion de la ligne du temps -- le composant le plus ancien -- qui devra être revue dès que j'en ai fini avec ce fichu escalier imponçable.

Thought: Since we have an abstract TItem class, we could introduce a new TIControl in addition to TIFrame that would support things such as loops and end-of-animation. It would generate a static thumbnail and could be moved at wish.

Implementation detail : TI* structures do not directly know their position. The TIList consists of (unsigned, TIFrame) pairs indicating each TIFrame's absolute position. Relative delays are inferred in exportAnim() in order to produce the C_CONTROL:I_DELAY entries.

Thought: There's a "delay" plus/minus control right now, that control delay when a new item is inserted and the additional delay at the end of the animation. We'd rather have it affect directly how long a given frame is displayed.

• [done] add AnimWindow::adjust_positions() to perform one-shot delay update
• [done] rewrite code for '+', '-' and FRAME_SELECTED accordingly
• [wish] possibly use the 'prv' and 'nxt' checkbuttons to uniformly rescale the animation.
• [done] introduce TIControl for loop and end-of-animation
• [done] make sure moving frames across other frames do not break animation order

Badman.

Deux boules superposées, deux mains rondouillettes et pareil pour les pieds, Badman est un candidat idéal pour l'animation modulaire lui aussi!

Quelques coups de stylet dans le SpriteEditor, une petite animation-test d'une course plutôt concluante. C'est bon. Mais en redessinant une cape hier soir, je me rends compte qu'il est impossible de la lui ajouter sans devoir refaire toute mon animation. Nouvelle session de code en perspectiveterminée ...

Among PPP Team characters, Badman is another good candidate for AnimEDS testing: balls for head, body and hands ... simple feet ... A few stylus stroke in SEDS, a simplified shading style and we're already ready to make him run ^_^ Compared to the '96 sprite sheet, that's a lot of work saved! Adding the waving cape required a bit more code on AnimEDS -- I hadn't drawn it at first, but defining a new skeletton (the 'ok' button on the FileWindow) would clear the animation. There's now a way to keep the animation by L-clicking that "ok" button.

Okay, so next steps:

• automate export of animation into e.g. animated GIFs.
• onion skin, at least for specified object, later for complete character

Sprite Editor v0.4 pour bientôt ?

Dur à croire, mais SEDS v0.3, c'était il y a plus de 2 ans 1/2 déjà. Entretemps, j'ai ajouté l'outil "seau de couleur" (L+B), récemment ajusté pour fonctionner aussi en 16x16. Au passage, avec l'éditeur d'animation qui ajoute de nouvelles informations dans les fichiers .spr, je dois ajuster le Sprite Editor pour qu'il ne perde pas les animations dès qu'on édite les images ...
L'idéal, bien sûr, ce sera d'intégrer les deux outils, mais on en est pas encore là (prototypage oblige).

Autre soucis: le devkitpro "32", ou plus exactement, le mécanisme "standardisé" pour passer d'un programme à l'autre. Pour l'instant, le nouveau SEDS n'est capable de passer à un autre programme que si "quelqu'un d'autre" (runme, hbmenu) a placé le stub en mémoire... Celà dit, il y aura quand-même encore quelques petites choses à régler dans la partie "palette" (qui traînent depuis un bail :P)

[done]click on color in the preview, and see where it is on the palette [done]R recalls the former color (undo) swap mode for the PaletteEditor widget

These are "todo items" pending on the Sprite editor for two years and a half, now. The latest SpriteEditor release is virtually as old, and had no idea what to do with animations present in .spr ... So an update will be required soon so that people can start drawing their *own* 'puppets'. That, plus support for "horizontal flood fill" will make version 0.4, which I hope to make available fairly soon.
Let us also add:

• [done]a visual hint of which gradient color has been picked last
• [done]a tool for "reversing" a gradient on the gradient-generator widget (for hues) (that was already available with A/X buttons :P)
• [wish] a slider for boosting / lowering the contrast for a range of colours.
• [done]sprite swapping on the grid
• [wish] colour stencil à la Deluxe paint (possibly using the quickpal widget)
  

Ideally, both tools will end up integrated into a single binary, for more efficient workflow. That's not yet possible as one is still in prototype stage and the other "in production" ...

Yahoo!

Hey! Regardez: c'est Rayman ... reconstitué sur l'écran de la DS. Il y a encore un paquet de choses à régler, mais c'est la première compilation de mon éditeur d'animations qui permet de positionner les différents "membres" sur l'écran! Wouhouu!

Howdy! It works! It's still for sure full of bugs and needs a lot of polish and fixups, but for the very first time, it works: I can drag the different limbs of rayman to actually make it look ... like Rayman! No idea how long it will still take for release 0.1, but it's über-motivating, for sure ^_^

• [done]refernce position should be the *center* of the limb
• [fixed]moving a limb above the area will hide it definitively
• fix the "selection hit" area
• [done]double-sized frame editor
• [done]enable selection of an alternate sprite for the limb.
• [done]save frame and edit the next one.
• [done]visual confirmation of the selected limb
• [wish]preview animations by sweeping the timeline (?)
• [done]actual thumbs on the timeline
• [done]1x animation preview
• [done]buttons for flipping limbs
• [done]arrows to move to the previous/next frame
• [done]arrows to precisely set limbs
• ensure there's no collision between sprites for timeline and sprites for other widgets.