C'est le tronc qui ment le moins.

J'avais pas mal tatonné au moment de faire le tronc de l'arbre pour la forêt de Bilou. Un des éléments qui m'avait été indiqué sur pixelation était le manque de "volume" retranscrit par mon graphisme. Et là, en faisant une petite promenade matinale dans les parcs de Torino, je constate avec stupeur que le tronc des arbres n'est absolument pas éclairé "principalement d'un côté, l'autre dans l'ombre.

Que se passe-t'il donc dans ce parc qui défie les lois de la physique ?

Eh bien, tout simplement, l'arbre a un feuillage suffisament large et dense pour faire de l'ombre à tout son tronc. Résultat, aucun éclairage direct pour lui. La lumière qui lui parvient est le résultat de la diffusion (tous azimuts) notamment par le sol. De plus, le tronc est rugueux, et pas lisse. Les rayons de lumières y sont eux aussi écartelés et n'auront donc pas de zones "highlights" comme le ferait une surface plus lisse.

Bien sûr, dans son jeu vidéo, on est libre de choisir les conditions d'éclairage de son arbre, tout en veillant à ce qu'elles soient cohérentes avec celles des objets alentours. Et si jamais on décide de faire un arbre au tronc assombri, il reste un élément qui peut lui donner du volume: la distortion des motifs. Ici, l'écorce de l'arbre s'est craquelée en une sorte d'entrelac de lianes sur un fond plus rougeâtre en vieillissant. Globalement, l'écart entre deux "lianes" est le même partout, mais on l'observe plus serré sur les bords qu'au centre.

Voilà. Dessinez bien, moi je vais tenter de rattraper mon retard de sommeil.

throwing bladors

I can be glad I'm done with the "bottom things" of my summer todo list. Now the winter is starting, and what is left is what is more linked to the game logic and the revised collision engine which is waiting to prove its superior capabilities with some dumblador stunning and throwing.
De temps en temps, ça fait du bien de retourner à une "liste de choses à faire" pour s'assurer que le projet avance effectivment. Bon, des "todo lists", vous devez tout doucement commencer à en avoir une indigestion, mais je parle ici de quelque-chose qui s'approche plus d'un "planning" que des micros-tâches à effectuer sur un temps de midi. Mon dernier planning datait de mi-juin ... voyons où on en est... tous les éléments "du bas" ont été satisfaits, à grand renfort de mises à jour de SEDS et AnimEDS. Je vais donc pouvoir cet hiver attaquer sérieusement les nouveaux types d'interactions entre personnages: assomer, attraper, balancer.

On dirait que les mois à venir vont être durs, chez les Dumbladors.

At those "milestones", I can close many former todo lists, by collecting in a new one the items that remains pending but that weren't really linked to the then-going activities. And yes, this is truly a milestone, since I now have fully operational CompoundGobs, including the definition of palettes for individual limbs (altering the palette while playing the animation will be for a next milestone :P)

• [done] looping move should only be generated for looping animations
• [done] initial Mx,y statement should be ignored by the game engine (actually, everything that delays the rendering of the first frame of the animation should be skipped). That will partly solve the "landing bug".
• [todo] most of blador's debugging could have been avoided if we had the state-initialisation expression feature implemented.
• [done] not detaching an attached GOB when "throwing" it may have weird effects, but I would have liked the display list to be re-ordered so that such side-effects wouldn't have systematically occured.

tint'm'up!

Avec les nouvelles version de SEDS et AnimEDS, je n'aurai plus à rougir de la variété des Koopa Troopa. Me voilà également capable de créer des personnages animés en changeant la teinte des différents sprites utilisés. Voilà qui complète agréablement les modifications apportées à mon éditeur de niveau début septembre. Je vais peut-être bien pouvoir en profiter pour faire un premier essai de "pendat" en 2D, même si au départ, j'avais prévu d'utiliser des polygones pour ce perso (et pour BangBash, d'ailleurs).

Ain't 'fraid o' Kolorful Koopas. No more. With my latest updates on SEDS and AnimEDS, I can use up to 8 distinct palettes for the sprites I use to build character and monsters animation. The same "hands&feet" spritesheet can be used for Bilou, Dumblador and even Pendats, with two separate shades for foreground and background. That should be quite enough.

Now I've got to focus on the thing I've left behind for a while: make the game engine support all this as well. Right now, the 'schoolzone test' has a 'donkey kong return' look: only the owl-styled background has colours, and everything else is plain black ^^". But not right now. Right now is Ravioli time.

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.

Multipalette de-briefing

I do want to have multi-palette in AnimEDS as well, so that you can tint your monsters and reuse e.g. the same sprite for Bilou's front and rear foot, or for Bilou and Pendats feet and hands. Right now, each foot sprite is cloned 4 times and I only have 1 monster so far ... seriously.

Allons-y: multi-palettes aussi dans l'éditeur d'animation. C'est vrai, quoi: pouvoir repeindre les bouquins dans l'éditeur de niveau, c'est bien beau, mais ça ne change en rien le fait que je suis obligé de maintenir chaque sprite de pied en 3 coloris séparés et 4 coloris pour les pieds. Vous comprenez bien que dans un contexte pareil, tenter de faire un "pendat" avec les pieds et les mains blanches (couleur règlementaire dans l'armée de Sqrt) est totalement hors de question >_<.

So it's time I track the core changes made to Level Editor so that it can benefit from multi-palettes:

• Initialisation of the Engine object needs an  (EXTENDED_PALETTES) additional argument;
• every call that sets DISPLAY_BGx_ACTIVE now also need to set DISPLAY_BG_EXT_PALETTE;
• SpriteRam should no longer be initialised with e.g. SPRITE_PALETTE but with one of the slots returned by Engine::editpal($slot,false));
• when calling SpriteSet::setpalette() to copy from/to VRAM, make sure you call  Engine::editpal($slot,true); before copying and Engine::editpal($any,false); when you're done.
• before loading a SPR file, define SpriteSet::ncolors and wrap SpriteSet::Load() with Engine::editpal calls as needed.

Now, AnimEDS will mostly require extended palettes for sprites, not for simply for tiles. So ...

• [done] make AnimEDS compile in the noswap branch
• [done] get rid of logo display.
• [done] only MAIN screen is given multi-pal capabilities. Tell GuiEngine on which screen console should be ; Window provide palette[] and layers abstract registers ?
• [done] move AnimWindow on MAIN screen; fix sprite-based widgets.
• [done] make sure a palette is initialised

Courir ?

En testant la démo "Back to School", Facet regrettait l'absence d'un bouton "RUN" dans le comportement actuel de Bilou. D'un côté, un mini-jeu comme "nuts'n'bolts" ne devrait pas avoir besoin d'un tel bouton (pas de grand trou à franchir, et un gameplay plus basé sur le timing que sur les réflexes). D'autre part, je ne suis pas encore décidé sur le mode de fonctionnement de la course.

Il faut un bouton pour courir, ça c'est assez évident. Mais sur le DPAD ou comme bouton d'action ? Est-il vraiment indispensable de le garder enfoncé tant qu'on veut courir ? A la fin d'une partie de Mario, on finit par attraper des crampes... Pourtant j'aime bien la phase "gagner de la vitesse" que ce genre d'approche permet, par rapport au mode "un coup de bouton X et ça y est, on court à pleine vitesse" dans Rayman. Au point que Peach et Shantae ont carrément un bouton "ne pas courir".

Have you felt the lack of a RUN mechanics in the latest Bilou demo too ? Facet surely did.

I was really missing a run button and the little pauses and lack of inertia take away from the fluidity. I'd like to bounce and slide more.

After I spent some time thinking about it, it becomes clear that "Bilou's adventure" will have such a RUN mechanics, where speed progressively increases, but that this would be absent of "Nuts and Bolts" (and possibly other in-between arcade games featuring Bilou).

I would like, however, to be able to release the button, and not force the power-player to keep RUN button pressed for 30 minutes if he wants to speed-run the game. Fundamentally, what I'd love to try is a sort of "cruise control" behaviour, where you press a button only when you want the DPAD to make you "accelerate". Once you release that button, you keep moving at the reached speed until you release the DPAD as well.

Mon impression, c'est que le fait d'accélérer progressivement ou non peut être découplé du mécanisme de "lecture" du gamepad. En d'autre termes, on pourrait avoir un bouton qui n'est pas "courir", mais "accélerer". Si le joueur mêne Bilou dans une direction sans enfoncer ce bouton, Bilou ne change pas d'allure. Par contre, dès que le bouton "accélerer" est enfoncé, la vitesse de Bilou augmente (plus ou moins) progressivement jusqu'à la vitesse maximale. Que celle-ci ait été atteinte ou non, Bilou conservera la vitesse acquise si on relâche le bouton d'accélération.

The poll is now open: which sort of RUN do you actually prefer ?
Mario: 62%
Rayman (PSX): 12%
Shantae: 0%
Kirby: 0%
Bilou (new): 25%

One Last Apple Assault.

Well, granted, 2 years after its initial release, there's not much more novelty I can bring to Apple Assault. I got feedback from Pierrick and his son about the latest modifications, just took the time to bring the last polish, and here's Apple Assault v1.6. At last. In appearance, not much changes since 1.5, but it's quite a strong difference in terms of rhythm and gameplay, imho. 

Voici la version 1.6b d'Apple Assault, enfin finalisée, avec juste quelques micro-règlages par rapport à la 1.6a sera mon dernier mot. 4 mois pour passer de la pré-release à la release définitive ... je vieillis, moi.