Devant ou au-dessus ?

 Pas mon masque, hein. La carapace de scorpion quand Bilou la transporte. Celle qui doit me permettre de faire quelques petits moments-koopa dans la pyramide. La logique voudrait qu'on la transporte au-dessus de la tête de Bilou, comme les Dumbladors et les éponges dans School Rush.

Mais voilà, je me souviens bien qu'un des trucs que je trouvais dommage dans Super Princess Peach, c'est la manière dont elle ramassait les carapaces pour les tenir par-dessus sa tête avec son ombrelle, la laissant du coup vulnérable à une attaque frontale du plus élémentaire goomba. Je préfère de loin la technique de Mario qui peut se protéger (voire foncer dans un ennemi sans hésitation) dès qu'il a ramassé une carapace.

Should Bilou carry throwable scorpion shells in front of him, like Mario and Diddy or should he carry them over is head like Donkey and Princess Peach ? Both Twitter and my bro agree: over-the-head is better. It sure looks better: the shell is too large to be handled any other way. Plus, other carry-me items in the game already gets carried I can't forget however that I preferred the experience of in-front in all the games I played so far. It shields you against incoming foes, let you find hidden areas without taking any risks and avoids functional blind spots when you're throwing them.

Idem dans la série DKC: une des choses qui fait que j'ai toujours préféré jouer Diddy plutôt que Donkey, c'est que Donkey porte ses tonneaux au-dessus de lui. ça les rend à la fois moins utile comme bouclier et comme détecteur de passages secret: Diddy peut se contenter de s'approcher du mur alors qu'avec DK, il faudra s'approcher pas trop et lancer le tonneau (ou alors, on se baisse et on dépose le tonneau, quitte à le reprendre si on a fait chou blanc)

Du coup, j'ai fait un p'tit poll sur twitter pour voir un peu vos avis ... Majoritairement en faveur du 'par dessus la tête', visiblement. ça paraît raisonnable. J'imagine qu'on devrait pouvoir garder un côté "bouclier" en s'abaissant pendant qu'on porte la carapace, façon Blues Brothers / Tic & Tac. Il faudra par contre que je sois attentif à ne pas laisser trop de "zone morte" au moment du lancer pour éviter le défaut de DK, en particulier si je veux être efficace contre des ennemis à peine plus hauts que Bilou.

I think I can fix the shielding issue with some duck-while-holding that would reduce Bilou's hitbox and increases the odds that the shell takes the hit instead.

I'll need to take care of the functional blind spot. The shell should leave at a speed high enough that it feels 'fast' to the player (might be the other issue with Super Princess Peach's throw move). I sure can't afford the blind spot to be as large as in DKC (anything between Kong and banana on the picture above is out of the barrel's reach)

edit: Maybe my memories of Super Princess Peach are skewed. Re-playing it a few minutes didn't give me that feeling that koopa shells were broken, and one reason for that is that Peach also gives a (short-range) umbrella attack while throwing. 

Possibly the real issue is with button mapping: you use PICK UP to take the shell, but if you use the same button again, you'll drop an harmless shell rather than throwing it as a long-range attack. And if you press the ATTACK button instead of PICK UP when you don't have the shell with you, you risk of destroying the shell instead of getting a weapon. None of this should occur with Bilou, hopefully. And when you see that the shell in Princess Peach has lowered by more than 1 block within the first 4 frames of animation. Low enough to hit any possible monster with almost no build-up time.

Une histoire de police

 C'est la série de p'tits fanart pixelisés de Rephil qui m'a mis la puce à l'oreille: une police en pixels, c'est quand même bien plus lisible avec un ombrage. Surtout quand on est pas déjà en noir-sur-blanc. (ou blanc sur noir). Et vous savez quoi, il arrive à le faire même en 5x5!

I guess it is the checkerboard pattern of Rephil's  (pixel|fan)art that lead me to realise is so much more readable when you drop a shadow. (yeah, that took me 15 years). So maybe it would be worth it to do the same on the DS for my game tools, right ? And maybe I could even push it further and use 'drop shadow' to indicate that some specific text is interactive! Someday ... maybe... Clearly not a high-priority thing to do.

Alors bin avec mes caractères 8x8, sur DS, il n'y a pas de raison que je m'en prive, si ? Dans presque chaque caractère, il y a une ligne vide en bas et une colonne vide à droite pour éviter qu'ils ne se 'collent' l'un à l'autre. Et ça n'est absolument pas gênant si les pixels d'ombre se colle aux pixels blanc des caractères suivant.

Petit mockup de ce que ça donnerait... On peut même raffiner en utilisant ce truc que pour les caractères "interactifs" des widgets. On peut même utiliser une couleur supplémentaire "highlight" qui disparaîtrait quand on active le widget alors que l'ombre passerait à la couleur de texte pour donner ce petit effet interactif "le bouton s'enfonce quand je pousse dessus" qui fait toujours du bien.

Maintenant que je suis passé à du multi-palettes dans tous mes outils, pourquoi s'en priver ?

edit: oh bin justement, quelqu'un a mis en ligne une belle collection de polices bitmap issues de la demoscene...

Water Pool

Une petite cascade, c'est bien, mais avoir aussi une idée de ce que donne les zones immergées, ce serait mieux. Alors bin j'ai ressorti mon Gimp pour essayer ça. Je peux dire que les "mares" de la Green Hill Zone de Sonic Mania ont agi comme un déclic.

Having a sweet waterfall is nice. But where is all that water going to ? How should I render water in Bilou's Dream Land ? (I want to have some!) ... I knew I had to give it a try for some time, and then I played Sonic Mania. They have some and I was struck by how simple they've done it. So I went for something similar (esp. on the surface)

• il faudra prévoir un effet "wobbling", horizontal comme vertical. 1 ou 2 pixels devrait suffire
• les p'tites bulles font une fameuse différence.
• les blocs solides peuvent facilement avoir une couleur plus proche du vert.

The palette-swap alone won't be enough, I'm afraid. The mockup above only turned convincing after I added little bubbles (these will be sprites, obviously) and some wobbling effect.

Unless it is required to make the water level change over the level, I shouldn't have to rely on interrupts to swap palettes. Just adjusting the palette of the background tiles in the editor should be enough.

The wobbling, however, will better work if I have some H-SYNC-ed DMA reprogrramming the horizontal and vertical scrolling registers. That means it will be tricky to mix water and non-water background on the same "scanline"... I'll have to check the existing level layout to see whether this is an issue.

Petite cascade

Bon, c'est pas énorme, mais ça faisait un moment que ça n'était pas arrivé. Je me suis pris une heure ou deux cet après-midi pour faire un p'tit montage de ce que donnerait une cascade sympa au milieu de l'environnement de Bilou.

I took a few hours this afternoon to make a mock up of what a nice waterfall would look like within Bilou's environment. Okay, it isn't much, but still: last time it happened was long ago. First attempt was nice, but could be perfected, so I threw in a few technique I had seen in earlier studies and I finally have something that 'imho fits better with the rest of the tileset.

C'était chouette, mais perfectible. En réimportant quelques trucs venus d'études précédentes, je finis par avoir quelque-chose de plus riche et qui s'intègre mieux avec le reste des décors (je trouve)

J'aime bien la possibilité de faire tomber l'eau verticalement en bout de plate-forme plutôt que de devoir me farcir un arc-de-cercle presque sans épaisseur. ça donnerait mal au crâne de celui qui devrait essayer de modéliser ça en 3D, mais soyons honnêtes: qui s'en tracasserait ?

Bon déconfinement à tous ;)

edit: Si Konami se permettait, à l'époque de la NES de faire de l'animation de cascade à grand coup de graphismes, j'ai bien le droit de faire sans palette cycling moi aussi!

original reference material by Daniel Freer

Les couleurs du désert

Un peu des couleurs que j'ai jusqu'ici, un peu de couleurs venant de Ilkke ou de Commander Keen ... quelques mélanges ... et je commence à avoir des combinaisons qui me semble intéressantes (sur la droite). Qu'est-ce que vous en dites ?

In the center, the mock-up I had previously for Bilou's desert zone. On the left, I tried using Lost Vikings, Commander Keen or one of my reference from Ilkke. On the right (and esp. in the corners), mixing of reference-based colors and current colors that imho provide interesting shades and hues. What do you think ? (I put the focus on ground tiles and background, btw. 'green' block and power-up were either untouched or got crushed in the blending process).

[x] comparer avec les couleurs d'Aladdin SNES/Genesis -- bof. Par contre le palais de Jafar a des éléments de décor intéressants.
[ ] comparer avec les couleurs de Sandopolis (Sonic) -- en fait non. Elles sont trop criardes à mon goût.
[x] essayer la palette de verts du chateau d'Hyrule qui avait inspiré les téléporteurs de Bilou's Quest ... sauf qu'ils n'étaient pas verts. (voir ci-dessous)

PS: je me suis concentré sur les couleurs des briques. J'aimerais que le bloc vert reste dans les tons verts, mais genre "masque de jade", que je n'ai pas encore réussi à reproduire. J'ai pris le temps de re-copier-coller Bilou avec les bonnes couleurs (presque?) sur chaque écran mais j'avoue que le bonus n'a pas eu droit à autant de considération

Je fais une deuxième passe. Les verts de Bilou's quest (top-right) retravaillées (bottom-right) me plaisent bien. J'ai essayé d'importer les couleurs d'Agrabah (mid-left et bottom-center) par contre, mais ça ne donne pas aussi bien.

edit: J.L.N a bien voulu laisser la NDS à son papa une demie-heure avant de rejouer un peu au niveau-où-l'encre-descend de School Rush. J'ai pu me faire une petite map, et j'ai aussi un second jet plus convaincant des "boules de poussières" inspirées des techniques de pixel-art de Fury of the Furries ...

ça serait probablement aussi une bonne occasion pour tenir compte des recherches de ThePtoing sur les graphismes de Metal Slug: utiliser des palettes de 15 couleurs + alpha dans lesquelles ont retrouve deux raster de 7 couleurs qui ne se super-posent pas tout à fait, ce qui permet par la suite de "teinter" plus subtilement les tiles.

Le livre qui dit tout...

Aah... enfin un moment pour transférer ma version du livret-qui-donne-des-indications-au-joueur. Qui serait bien utile au joueur occasionnel, si j'en crois un célèbre vendeur de bateaux des Caraïbes.

Il faudra aussi que je pense à une version qui rende le choix du niveau plus intuitif. La version actuelle est tout simplement inutilisable à moins de savoir exactement comment ça fonctionne.

Once upon a tile, I was drawing some background for the user interface and "head-up display" of School Rush. Tonight, I could beam them to my laptop, and build a mock-up of what it should look like once in-game.

I need the Rainbow Road

I started working on a last level for School Rush, where you'd have to climb up for safety. It was tedious, because navigating in the level in LEDS can only be done with L+DPAD at the moment, in 64-pixel increments. Yet this time, I had to move through 1024x8 pixels of emptyness before I reach the "bottom" of the level everytime I want to migrate something from the title screen.

And then, i tried to copy the current game on my brother's DS using my not-so-smartphone, so I lost that map. Sigh. I'm not re-doing it that way. I will first bring on a new tool in the Level Editor. Something like a "Quick Navigate" option. I thought a "Rainbow Road" would work okay. level structure is depicted by two rasters (one horizontal, the other one vertical), and auto-zooming so that you a square area covered with stripes, and touching one pixel of that square brings you immediately to the corresponding area of the level.

Bon, perdre un niveau qu'on édite, ce n'est pas drôle. Devoir recommencer en faisant des centaines de fois L+bas pour retourner au fond du niveau, ça l'est encore moins. J'ai pris un peu de temps cette semaine pour réfléchir à un moyen de se déplacer rapidement d'un point à l'autre de la map pendant l'édition, en tenant compte des ressources vidéo déjà largement sollicitées sur l'écran d'édition. Je propose la RainbowRoad: un carré sur lequel sera représenté le niveau en utilisant un dégradé bleu-rouge pour l'axe horizontal et un dégradé foncé-clair pour l'axe vertical.

As far as software engineering is concerned, I face once again the need for a given event (update of level coordinates) to be produced by any of M sources and consumed by N receivers. M and N are small, and constant once the program is built. A bus pattern could work, or possibly something like an object that sends notifications when updated.

Color selection in SEDS could also benefit from this pattern.
Post-Scriptum thoughts:

• [dont] Having QuickGo out of MapEditWindow allows to keep level edition full-screen. I have very limited options to introduce yet another window over MapEdit.
• The drawback is that currently MapEditWindow doesn't show when you toggle to TilesetWindow.
• [done] The transient "layer selection" overlay (available when map edition in "copy" mode) could host it as well.
• Maybe replacing one of the rasters with a overview of how "dense" the area represented by one pixel is (with transparent-to-white) would give a good feeling of where we will go ... 

Lost levels: the Clicker era

Et puisqu'on est dans une phase "déterrage de vieilleries", voici un mock'up de ce que j'espérais atteindre avec mes éditeurs de jeu ultimes aux alentours fin 1998, une fois que l'environnement Clicker serait suffisamment complet. Assez loin de SEDS, hein?

Allow me to chain to another oldies-digging: some mockups of what the Ultimate Game Maker should have looked like if Clicker was already working in 1998. The blue-balls background reuse some graphics I used for my very first website, The font is the default one for Deluxe Paint II. I guess that's before I get seriously into 3D modelling with moray, given the icons look, but we can already see the side handles for pull-menus discussed with one of my brother's musician contact who should have collaborated to the creation of the sound tracker.

Un tournant majeur du projet aura lieu en octobre 2001, lorsqu'Eugenia Loli-queru sur OSNews.com dresse la liste de tous les projets alternatifs à l'occasion de la sortie de Windows XP. Clicker32 y apparaîtra 2eme, derrière SkyOS et juste devant RDOS, provoquant 11436 visites en un jour (j'en avais jusque là une trentaine).

Chose amusante, c'est parce qu'un autre développeur d'OS amateur avait trouvé sympa le petit Bilou qui servait de curseur souris à la version 0.9.x de Clicker 32 que j'ai déterré mes autres Bilous puis que je m'y suis remis.

Prêt pour la rentrée ?

Il m'aura fallu du temps, mais j'ai enfin un décor intéressant pour la school zone ! Basé sur un dessin au trait puis converti à la dure (comprenez, avec Gimp, une souris standard et un calque "hue") et lui-même inspiré d'éléments de décor de Pinoccio et Blanche-Neige du Grand Walt.

Between engine re-factoring and Bilou animation upgrades, I've tried to find things to fill the background of the library level while keeping a "intimate" tone. I think I've got at last some ideas, thanks my little daughter watching Snow White and Pinoccio movies :)
I'm not very convinced by the sketch-to-pixel-"art" conversion process yet, but at least I've got something to fill the emptiness of the former mock-ups.

Now, I still have things to fix: the background layer is (for some odd reason) loaded as an InfiniMap as well, which means the game engine tries and update the map as if it had to stream in new tiles. That could explain some odd behaviours I noted with Apple Assault. I still hope I'll have a running demo for September 3rd so that kids all around the world can recover from their first day at school with a Bilou minute...

Il me reste à en faire le rendu de manière convenable, et ça, c'est pas encore gagné. Le décor (512x256 pixels) est pour l'instant chargé comme s'il s'agissait d'une couche "map" classique, et le moteur de jeu tente du coup de la faire scroller "normalement" aussi... sauf qu'elle scrolle 2x moins vite, parallaxe oblige. Du coup, les savants calculs destinés à garantir que le morceau affiché à l'écran soit toujours bon donne lieu à des "téléportages de hibou" plutôt étonnant.

Maintenant, il serait temps que ma DS rentre elle aussi de vacances, que je puisse finaliser tout ça.

... flawless victory ^_^

Roses are Red, Violets are Blue ...

And my books should be allowed to have whatever color I think fit. Or at least let me put it in a different way: that would be a waste of tiles if I could only have *red* books in the school zone, right ? (and only green binders). It's much more interesting if I can select an alternate palette when I want a blue-tinted book or a darker wood block.

The DS hardware allows all this (I mean, even the NES had it :P), extending the '256 colors' mode of the GBA to some fancy '16x256' colors. Granted, I *could* very likely work in 16x16 colors mode for the school zone, but I'm not yet a sufficiently good pixel artist to handle that.

I've took a first step yesterday by allowing some 4 palette slot selection in SEDS' palette editor. Before I give you a rainbow bookself, I still have to:

• [done] store all this in the SPR file (SpriteSet classes)
• [done] make sure SEDS has a palette large enough advertised to SpriteSet.
• [done] adjust the game engine so that it works in extended palette mode
• [done] provide palette set toggling in LEDS (only for the BG layer: the FG uses it to encode tile properties). That would be better to have it on the bottom screen, and not part of the "tileset" screen as depicted on the mock-up
• [done] provide palette setting in AnimEDS as well (so that dumblador and Bilou (and pendats) can share feet tiles. Being able to define it when the sprite' skeletton is created should be a good first step

Oh, and don't worry: there will be an polish on the transanims and a schooldemo.nds by the end of august. I just need to recover a DS lite for that, so I'm messing up with other parts of the summer-todo-list.

BoxWidget ... beyond the code.

I missed a "svn commit" this morning, so all I can do is some mock-up to think about how the "BoxWidget" will be used to define hitboxes in AnimEDS... It seems like I'd rather not jump into implementation immediately and think a little bit about the options: boxes are defined on a per-animation basis, not a per-frame basis, so maybe they could be edited on the FileWindow rather than on the AnimWindow.


Bon, bin quand on a pas synchronisé son code à la fin du week-end, on peut toujours se faire un p'tit mockup pour voir comment le nouveau widget "définir une zone rectangulaire" va pouvoir aider à la définition des zones de collision. Mock-up pas totalement convaincant, d'ailleurs. Fort confus, même si je ne vois pas bien comment faire mieux. Ça me paraissait une bonne idée, au départ, de juste "suggérer" la zone de collision en marquant ses coins, mais la plupart des problèmes de collisions rencontrés jusqu'ici provenait d'un recouvrement entre zones. Du coup, pouvoir en visualiser plusieurs d'un coup ne serait sans doute pas plus mal...

It could also be interesting to be able to visualize more than one box at a time, similarly to what happens with InspectorWidget: many "collision bugs" were due to improperly overlapping windows. That could require another form of display

SUB or not SUB ?

When I started working on SEDS, most widget was supposed to be on a very specific screen. I now have 4 tools that share the same "GUI engine" and widget library (libgeds), and some will sometimes be on the "main" screen on the DS and sometimes on the "sub" screen. Which screen is rendered where (top/bottom) can be easily swapped by the hardware, but the video memory dedicated to one of the screen cannot. When you put colours in BG_PALETTE_SUB, only one screen can use them.

Rhaa! Je sais que j'avais trouvé un truc pour que les widgets à l'écran puissent choisir d'eux-même s'ils étaient sur l'écran principal ou l'écran secondaire, mais impossible de me souvenir d'où j'avais fait ça ... Je sors mon casque de mineur des vivres pour 3 jours ... si je ne suis pas revenu du SVN à la fin de la semaine, appelez les secours

Là! Ça y est! le petit curseur de SEDS dont j'avais eu besoin dans LEDS pour la sélection du tile courant et dans AnimEDS pour enregistrer une animation. Ouf.

I finally found a trick to let the widget automatically allocate the proper resources (sprites, tiles, colours) depending on which window hosts it, by delaying the allocation to "widget placement" time... well, the trick is roughly one year old, now. No wonder why I had a hard time to remember on which widget I prototyped it :P

Sinon, comment vous trouvez le premier jet du décor de fond pour la bibliothèque ?

Oh, yeah, and that's a first draft of the new intended background for the library in the school zone. Do you like it ?

Colour Balance ...

J'essaie d'ajuster un peu les couleurs des différents éléments de la "school zone" histoire d'avoir quelque-chose de plus harmonieux que les derniers mock-ups. La difficulté, avec les bruns et les verts, c'est que le moindre faux-pas casse tout. Je suis assez content des teintes sur la gauche de l'image (gimp-power), mais le hic, c'est évidemment que la DS a moins de souplesse de ce côté-là: 5 bits par couleur au lieu de 8, on se retrouve vite avec un écart trop grand ou trop petit entre deux couleurs si on se contente d'essayer de réappliquer les valeurs HSV de l'un à l'autre.

Not so easy to make sure that the different objects fit together well, esp. when lights and colours come into the game. On your left, binders and small wooden blocks with Gimp-revamped colours. On your right, books and larger wood block as they exist right now on the DS. I'd love to have the wood blocks use the same colour, but unfortunately, it turns out that the RGB values fined-tuned in Gimp do not fit the 5-bit-per-color-channel constraint of the DS hardware. Whatever "brainless" conversion I try to apply inevitably ends up with exagerated contrast here or flattened colours there.

I guess I'll have to do something similar to the process through which I revised the green zone's dust background: bring in the desired background colour and some misc. objects, finetune colours on the DS and then rework my rasters accordingly. It's just a pity that SEDS does not provide a way to visualise which colour of the palette is where (on tiles) in palette edition mode >_<

Et pour ne pas changer, il me manque le "petit plus" pour faire des essais facilement avec SEDS, à savoir visualiser dans l'image une couleur choisie sur la palette... Quand j'aurai ajusté ça, il faudra aussi que règle les vieux bugs de mon Level Editor, parce que si pour les maps simples d'Apple Assault, j'avais pu "faire avec", là, c'est un peu la catastrophe. Dès que j'essaie de définir un objet comme solide, j'ai une chance sur deux d'en effacer un autre >_<

Puis il faudra que je permette d'ajuster le niveau de zoom du frame editor d'AnimEDS pour pouvoir travailler sur Bilou, dumblador et les autres qui se sente un peu perdu dans un cadre de 64x64 :P Et puis permettre à SEDS et LEDS d'utiliser les palettes alternatives de la DS, histoire de varier un peu les couleurs des livres sans faire exploser le nombre de tiles pour autant.

edit: it's been 3 evenings I spend trying to adjust colours on the DS, where everything looks "just fine" when viewed at the proper angle. If I really want homogeneity in art, woudln't that be wise to first check that my FG is harmonious against existing background ... like the one of the green zone ? ... imho, it works fairly well, regardless of the actual "tint" of that background. Don't you think ? Now, all I need to do is draw some books and school stuff with those tints :P

deep ink pit mockup tout moche

J'essaie de rendre "deep ink pit" un peu plus concret, mais j'ai du mal avec ce classeur qui ne veut pas sortir de mon stylet >_< Je devrais peut-être essayer de travailler avec une autre couleur que le violet. Les Bop'Eponges donnent pas encore trop mal pour quelque-chose de bricolé en 2 minutes dans Gimp. Par contre, l'encre, clairement, il faudra que je me documente pour avoir quelque-chose de décent. Comme quoi, quand je disais que je n'ai pas encore ce qu'il faut au niveau graphismes, je ne vous racontais pas de bobards.

Well, you may remember that poll where you had to vote for different game designs. Deep ink pit was then first presented. A kind of "tower climbing" game where you'd hop from spongebop to spongebop and try to get high enough to convince the Inkjet Master that you're the hero and that he should help you on your quest. I think that will be my next mini-game, featuring 'BN chocolate' soundtrack from my brother. Unfortunately, I'm not much more advanced related to the graphics that I was initially. At least, since I've made a game with the green zone graphics, I'm now free to craft some more graphics. Let's hope it will improve soon, because this seminal mock-up looks ugly to my eye.

edit: dans la cité des images de Rayman, seuls les contours de l'encre sont colorés. Enfin, quand je dis colorés, c'est plutôt un reflet blanc qu'une coloration.

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 >_<

anim0-10 = spr0.anim0-10

I forgot to commit the few modifications I made to AnimEDS this week-end. That sort of rules out any lunchtime coding today ^^". So instead, let's plan a little bit what has to be done to allow the new animations to be used by the game engine ...

Les animations sont attachées au fichier qui a servi lors de spr.load "$FILENAME":$SPRSETNO. On souhaitera sans-doute en charger plusieurs à la fois, e.g. via anim$FIRSTNO..$LASTNO = spr$ANIMSHEET.anim$FIRST..$LAST. Cette "simple" instruction dans un fichier .cmd construit les structures GobAnim comme l'aurait fait une commande anim$NO $SPRPAGENO { ... }.

L'idée est de pouvoir ensuite réutiliser state$SNO : anim$ANNO { ... } sans plus devoir se soucier du type d'animation créée. Celà veut dire aussi qu'au moment d'interpréter gob$NO : state$SNO ($X, $Y) , le GameScript devra inspecter le GobState enregistré dans sa table pour décider s'il doit construire un SimpleGob ou un MultiGob.

Flip !

Reprise timide du développement sur AnimEditor, maintenant que les "problèmes de logistique" sont réglés. deux petits boutons pour inverser un des sprites horizontalement et verticalement, petit ajustement des zones de sensibilité de la TimeLine et de la prévisualisation de l'animation ...

Now that I got "logistics" issues fixed, I can resume development on the Animation Editor. Oh, well. Slowly resuming: I still have time-consuming activities in the office hours and much to do at home to get the staircases fixed this summer. However, I've tackled the difficulties of having two small buttons flipping limbs on the frame editor and during the animation preview.

Tiens, et tant qu'à faire, un vis-à-vis avec les fonctionnalités à rajouter ^_^

And well, since I've got a new screenshot (above) featuring Mr. Egg, let's turn it into a mockup showing what's left to do.
First, we'll need more limbs for those bugs in the caves, that will require more "limbs". Second, I'll need better control over the timeline: looping, inserting a pause at the end and so on.
An onion skin identification of the previous frame would help as well. Finally, I'll plan some room to host more advanced features such as controlling how the character would move in the world following the animation, and possibly defining hitboxes in a graphical fashion.

Mais avant ça:

• [done] supprimer une étape dans une animation
• [done] définir un nouveau "squelette" pour des animations.
• [done] modifier un sprite dans tous les cellulos suivants ou précédents (en plus du cellulos en cours).
• [need] dé-sélectionner le sprite en cours sans toucher à nouveau le FrameEditor avec le stylet: L-touch puis L
• [done] Click sur AnimShow => joue une fois l'animation; L-Click => joue l'animation en boucle.
• [bugfix] revenir correctement aux premiers sprites lorsque l'animation boucle.
• [bugfix] charger plusieurs fois une "nouvelle" animation la rallonge

AnimEDS: main screen mockup.

Permettez que j'appelle Rayman à la rescousse pour venir poser pour un petit mockup de mon éditeur d'animation sur DS, puisque, par un vieux hasard, il est clairement basé sur la même technique d'animation que celle prévue pour Bilou (et utilisée dans la version BASIC, d'ailleurs :P). Les gribouilles que j'avais jusqu'ici n'étaient effectivement pas terriblement claires pour expliquer mes intentions.

Le Frame Editor, au centre, permet de positionner les différents éléments. Le "Component Selector", à gauche, permet de choisir un des constituants (dans cette image, c'est la tête de rayman qui est sélectionnée) alors que le SpriteSelector (sur la droite) montre la SpritePage correspondante pour permettre de remplacer l'image utilisée dans l'étape d'animation en cours. La Timeline (en bas) montre l'animation déroulée dans le temps et permet de sélectionner l'étape à éditer sur le Frame Editor, mais aussi de déplacer les étapes déjà "dessinées" sur la ligne du temps pour changer la dynamique de l'animation.

edit: avec une zone de 128x128 pour positionner les "morceaux" de sprites, je vais devoir me limiter à un zoom x2 si je veux pouvoir gérer des personnages suffisamment grands (les sprites peuvent au plus occuper une zone 2x plus grande que leur taille propre avec le hardware de la DS, de toutes façon). Comme l'éditeur ne gère que des blocs jusqu'à 32x32, ça ne devrait pas poser trop de problèmes. Le contournement de ces limites pour les objets plus gros ou un zoom plus important des objets plus petits, ce sera pour plus tard.

Hey! Qui vient jouer les trouble-fête ?

Bounce & Shoot

Petite tentative de mettre en image les petits essais de ce midi, dans le cadre du mini-jeu "Apple Assault". L'idée est d'avoir une jauge d'attaque que Bilou peut remplir en rebondissant sur des monstres (représenté par les 2 transitions en haut de l'image) et qui lui permet de lancer une étoile (à remplacer par un coup de poing).

Cette jauge n'est toutefois pas permanente: quand Bilou est au sol, elle retombe progressivement à 0, réutilisant le même mécanisme que celui qui fait ralentir les Applemen. Cette "vue synthétique" de toutes les interactions faisant intervenir une variable donnée pourrait bien venir compléter d'autres fenêtres de dialogue plus "classique" (éditer toutes les transitions de / vers un état) dans un éditeur de comportement tournant directement sur la DS ... à venir plus tard.

This week-end has seen virtually no code written for the engine, but massive update and improvement on the "gobscripts" defining Bilou and the Applemen. Bilou now actually 'bounces' when he stuns appelmen, and you can bounce higher by pressing the jump button with the proper timing. In an attempt to get closer to the "apple assault" milestone, I was toying this lunch time with a bounce counter that could be use to enable the "shot of some placeholder" that is meant to become a "finishing move" that would clear the area of stunned (or running) applemen.

Here's a conceptual mockup of how that job would have been done if the "behaviour editor for DS" was already implemented... or at least how you could visually provide hints on what is using that bounce counter by identifying all the predicates and action that use "variable #6". In order to add that behaviour, you'd have to start with the "falling" state, alter "monster found" behaviour, then browse neighbour states and decide what to do with v6 in order to implement the "depleting counter" that only let you "throw a star" shortly after you've hit the ground.