Bilou HomeBrew's Blog

runme is working with WEP ^_^

2012-02-08T20:43:00.002+01:00

Bonne nouvelle: runme supporte maintenant le WEP, pourvu que le point d'accès ait été configuré avec un programme Nintendo officiel (Zelda: Phantom Hourglass, par exemple ;). C'était probablement déjà le cas depuis un moment, vu que je n'ai rien eu à changer dans le code pour que ce soit le cas, juste passer le nouveau modem de mon ISP en mode WEP (sauf erreur de ma part, la DS lite ne supporte pas WPA).

I bet it actually did support it for longer, but with my former WiFi router, I had no need to configure it. The newer one has only WPA or WEP mode, so I had no choice but giving it a try.

Berry Bat Things

2012-02-04T14:42:00.006+01:00

Hey, there! Cleaning up and tuning in are done. If you enjoyed once AppleAssault, but then stopped playing it because you didn't feel the challenge anymore, here's an update that you might love: AppleAssault -- BerryBat Things. The idea is simple: you've got limited time to clear up a level. As long as you punch applemen out of the arena, nothing bad will happen... But if you get lazy and that the applemen count remains the same for too long, a berry bat will come and tease you. You could manage to get rid of it, of course, but then another one will come soon, and then again another and another, again and again until you surrender (or focus on punching Applemen, after all).

So how comes you're still reading this ? Go and download it!

Bilou! Le revoilou! Ok, je suis supposé bosser sur la School zone, mais j'ai une très bonne excuse pour recycler AppleAssault en ce début d'année 2012. J'ai enfin intégré les "berrybats" dans le jeu. Si vous aviez fini par faire le tour du jeu de 2010, autant vous prévenir tout de suite: vous allez faire une rechute!

A priori, le principe est toujours le même: assommez les pommes en leur sautant dessus, puis expédiez-les hors de l'arène d'un bon coup de poing. Ouaip. Sauf que maintenant, si vous passez trop de temps sans dégommer de pomme, une chauve-berrie (berrybat) viendra vous tirer les oreilles. Oh, bien sûr, vous parviendrez sans doute à vous en défaire, mais il en viendra alors encore et encore, de plus en plus vite. Jusqu'à ce que vous vous décidiez à vous concentrer sur la mission première: virer les pommes.

Prêts ? Moteur ... et .... Action!

Oh, and btw, make sure you're voting for the "success" of the new features in the side panel if you've played to v1.4 as well ;)

When ID software is keen to hide ...

2012-01-31T13:37:00.001+01:00

There's an interesting thing with this "tunnel" level of Keen Commander V, that reveals the way ID software did conceived secret passages as rewards for exploration to players. Exploration is a key part of Keen games: you're not supposed to zoom through levels, as many keys and doors will require you to take detours. In small corners, you might find hidden by-passes and hidden bonuses (like just above the blue rays on 1st figure). But here, they did a different approach. A huge, black door teases the player. You see there's something there, but how to get in ? is that supposed to be input or output ? It's a miracle you've got the time to think about that just after you avoided being zapped by Robo Red ! But no matter how hard you may try to get in, you're not in the right place yet (level is played right-to-left here).

C'est une idée intéressante qu'ID software a utilisé dans ce niveau de Keen5.exe : au début du niveau apparaît une porte mystérieuse -- une chose assez peu courante, dans les Keen. Apparemment, aucun moyen de l'atteindre. Et tout autour, c'est assez dangereux de traîner, avec Robo Red et tout ces shelleys ...

So good luck. Keep going. If you feel like exploring again when approaching the door from the left somewhat later, beware the smart bomb that will jump off the platform (oh ... just like an Appleman ? ... no: this one means death-on-contact and explodes into deathly bits when it hits the ground). Do you feel like rushing instead ? too bad: you're actually missing the entry to something ... you don't know what yet.

Only when approaching the exit door, you'll be shown what you've missed: a 1-UP. A pretty precious thing in Keen, but no: hollow walls around only give you a few bonuses. Will you head back for the hidden door and search more ? Or will you save the current life and exit ?

Ce n'est qu'à la fin du niveau que le joueur aura le fin mot de l'histoire: une vie, bien visible mais inaccessible. Ding, le franc tombe. Le joueur qui avait jeté l'éponge va sans doute retourner en arrière pour parvenir à atteindre la 1ere porte. Je pense, ceci dit, que Tom Hall aurait pu faire encore mieux. Primo, une seule porte, dans un niveau qui n'en contient aucune c'est louche. D'autant qu'il n'y a rien d'autre que la porte à cet endroit. Quelques gros bonus auraient pu faire croire au joueur que c'est une arrivée, pas un départ. Deuxio, il n'y a finalement pas de grand challenge à repartir en arrière, à ce stade, la plupart des dangers étant situés dans des embranchements latéraux ... ou ont été éliminés lors du 1er passage.

That's where imho the design becomes a bit weak. I'd have personally ensure that there is a significant risk in back-tracking to the access door ... Something like Robo Red, moving spikes, or a combination of shooting lasers and moving platforms (since normal monsters do not respawn in Keen). The only challenge here is a set of shooting lasers, but on solid ground, so you can move through that without too much trouble.

Voilà. Bon anniversaire, Piet ;)

Unclump'm

2012-01-30T06:46:00.011+01:00

Well, I've been using AppleAssault as a regression test when developing the new collision engine ... really just to make sure I'm not broking everything up, as there's nothing in AppleAssault that could benefit from the new engine, anyway. No pushable/carriable ennemies, no platforms. Nothing.

But of course, being in that source tree again (^_^), I wanted to give some ideas a try. The first one was to integrate berrybats in the game, as a way to force the player to focus on defeating applemen, and not just hop around. It now acts like a sort of indirect timer, appearing when you've been unfocused for too long... and appearing again and again until the lesson has been learnt :)
I'll need to work on the timing, though, so that the game doesn't become completely unfair :P

The second thing is linked to Kirby Kid's comments: Applemen tend to stick to each others, overcrowding on platforms, which isn't very realistic. I don't want to go for goombas-like behaviour: Applemen are design to be able to cross each other. Still, there shouldn't be 10 of them on 2 pixels. So I need to have a sort of applemen/applemen collision detection, but that should be handled with care, otherwise I could easily overload the collision engine with hundreds of (unnecessary) checks and dry the DS batteries in no time.

The approach I picked is to take advantage of a small transient state where the Applemen halts in front of a cliff, checking whether it will jump -- which you'd barely notice when playing the game. Only during these 2 frames, it actively checks for other Applemen in its immediate neighbourhood, and get "knocked out" of the platform if there was. Expect a revised .nds file to download in early February, as now, I still need to remove a *lot* of debugging printf ... and have a shower...
Oh, and some coffee would be nice as well... And a commit :)

Cheers :)

Dans le temple perdu

2012-01-26T16:18:00.008+01:00

Un temple, quasi-inaccessible, témoin d'une civilisation disparue ... un endroit imprégné de mystères et de questions sans réponses. Depuis que mon frère a composé le thème "Maya Zone" pour "Logic Labyrinth II", je brûle d'en faire un niveau de jeu vidéo. Du coup, je le remets sur la carte en reprenant le synopsys de Bilou en main.

Oui, mais le temple de quoi ? et qu'y affronte-t'on. Le premier point détermine le look à donner au niveau ... le 2eme conditionne le gameplay et l'esprit du niveau.

Le déclic, ça a été d'y implanter les lianes de la forêt. Des berrybats dans le temple perdu ...

I think I at last managed to turn the two words "lost temple" into some interesting and original design idea for both monsters and area look. I have studied art of Rayman and Shantae closer, sketching some original derivative here and there, keeping them secret until I'd have something coherent -- although it isn't pixel art and certainly not a playable demo yet. But let's face it: how would a playable demo "protect" my idea better than a sketch ? It's not like I was trying to win a race with a competitor here, not willing to let X know what I'm doing. Sure, I don't want the idea to be ripped, but I can't prevent someone else to do the same. So I bet my best defence is to do it publicly.

But anyway, just look at that "golem" thingy, animated by the berrybats vines (with berries too young to turn bats :) -- *that* will put you into trouble when you'll play the level ... well, if you manage to find the level in the final game, because it's not called "lost" temple in vain. Trust me: I won't reveal you the slightest bit of information on how you'll get there.
Allez, encore un petit effort. Des berrybats, oui, mais pas tout seul. Et si ... et si les lianes vivantes s'emparaient (au sens propre) des ruines du temple pour construire un golem géant ...

Là, je tiens mon idée de design. Le truc inédit, qui donne une identité propre par rapport à Lost Vickings, Rick Dangerous, Sonic et même Rayman. Alors je le poste, pour marquer l'antériorité. Voilà. C'est mon idée, j'en suis fier. Elle s'appuie sur 3 ans de marquage de favoris dans DeviantArt sans pour autant copier un design de quelqu'un d'autre, je pense. L'imagination est notre ultime frontière. Voici pour vous une planète supplémentaire, aux portes de l'inconnu pour vous lancer à votre tour dans les confins inexplorés de l'imaginaire vierge. Have fun.

(merci à Cyril et son Sony pour les photos, parce que j'aurais jamais trouvé le temps de scanner ça avant ... houuu ... le surlendemain de la St-Valentin ?)

all rights reserved.

C'est ça, être branché.

2012-01-23T20:55:00.002+01:00

Dans le monde de Bilou, le tileset et ses habitants vivent en paix. Le GameEngine maintient l'équilibre et l'harmonie de ce monde. Désolé, les amis. Apparemment, ça ne va pas durer...

Car, un funeste jour, l'horrible Mr. Pype bidouille le GameEngine et neutralise les pouvoirs du Makefile qui cherchait à le recompiler! Les GobStates, qui gravitaient autour de l'Engine perdent soudain leur stabilité naturelle ... et s'éparpillent dans tout l'disque dur! Préoccupant, non ?
Et en plus, ça fait désordre.

Dans ce monde à présent déséquilibré, d'étrange phénomènes se produisent ... des Applemen hostiles apparaissent plus vite que prévu, et quand on essaie de les assomer, ils se téléportent sur la gauche avant de revenir à la charge de plus belle ... non sans s'être momentanément transmuté en BerryBat ou en buisson ...

Remember when everything in Bilou's world was messed up to the point that Bilou turned into a jumping bush wandering around bubble-headed-trees? Well, with the regression test I applied to AppleAssault with the game-engine modification that are supposed to bring in compound animation, it appeared again. Applemen being flooded over the level rather than appearing progressively, they'd also stay stunned for much shorter and show some odd "side-effects", such as temporarily turning into berry bat on wake-up and even sometimes "teleporting" to the left while being pwned.

I had just introduced CommonGob, that captures the GobState management, including the reaction to an event (evaluating expressions, and so on), while the animation itself is still manipulated by SimpleGob (now a class deriving from CommonGob). It took me a couple of fixes to separate them right while still having the animation restarted from scratch when we switch states (and some more tests to handle the state3->state3 case). It would have been a mere lunchtime debugging session not worth mention if GDB hadn't decide to black-hole the SimpleGob class. No line numbers, no breakpoint, no variable or structure interpretation. Nothing but instruction stepping and register values >_<. I still haven't found out why, but I fixed the code nonetheless.

Bref, on aurait bien voulu appeler DDD à la rescousse, mais pas de chance: il ne parvient plus à interpréter une partie des annotations qui accompagnent les quelques classes maîtresses ... plus de visualisation des objets, plus de suivi des instructions ligne-par-ligne ... rien. sauf dans objdump. A en perdre son latin.

Picking a Tile size.

2012-01-20T08:00:00.003+01:00

Reading further through the Sonic Physics Guide, I noted that the collision mechanisms used (two "vertical sensing bars" for each feat and one "horizontal sensing bar") calls for a certain ratio between the character's collision box and the tile size. The rule is simple: your character should be able to stand on a single tile, and it should also be able to fall into a hole that's one tile wide only.

Another observation is that Sonic is 2 tiles high, which makes it more convenient to push items, but which also makes the 1-tile-high obstacle more convincing. Let's think about it this way: if there was a boulder that's half your size high (let's say almost up to your belt), would you have to do a special action (e.g. jump) to go over it? How about an obstacle that comes only up to your knees ? And halfway on your tights ?

My feeling is that, visually, an obstacle that's only coming up to your knees can be simply stepped on. Something that comes up to your belt is a real barrier. That's what a tile should be.

And well, unfortunately, Bilou isn't quite following those guidelines so far, but Bilou is quite far away from the Vitruvian Man (despite equally being an alien ;-)

2 tiles de haut contre 1 de large. Pour un personnage bipède, c'est l'idéal, si je tire les conclusions qui s'imposent de la lecture du Sonic Physics Guide. Attention, je parle ici de la zone de collision. À aucun moment celà n'implique que l'on doive caser tous ses dessins dans un rectangle de 20x40 comme dans le RSD game-maker, hein ?

En revanche, il est indispensable que le personnage puisse "tenir debout" sur un élément constitué d'un seul "tile" sans que ça ne paraisse bizarre au joueur. Idéalement, il devrait aussi pouvoir tomber dans un trou qui ne fait qu'un seul tile de large.

Difficile de dire si c'est le cas ou non pour Bilou, par contre. Ok, il est loin d'avoir les proportions de l'homme de Vitruve, et sera plus proche de 16x24 pixels dans la school zone qu'autre chose. Difficile aussi de lui appliquer la règle "un obstacle doit plus ou moins arriver à la ceinture pour avoir l'air un rien costaud"... Mais je garde ça en tête pour la révision de Badman...

(ces 2 croquis Biloupométriques datent de 2005, quand je m'étais mis en tête de faire une version 3D de la school zone en utilisant OGRE ... et que je me suis rendu compte que je ne parvenais plus à dessiner un Bilou correct qu'une fois sur 4 :P)

Countless Great Designs

2012-01-19T11:26:00.006+01:00

Petite pépite que je renseigne à l'intention d'armitage, en espérant qu'il trouve souvent ce qu'il cherche quand ses scéances de google le font atterir sur la planète Bilou: le générateur ultime d'entropie ... le test de Rorschack (toute ressemblance avec un nom existant est un pur coup de bol ;) version Pixel art.

Trouvé sur wayofthepixel, bien sûr ... mais où, ça ...

I have to call for your scientific forgiveness, although I find myself unable to \cite{my-sources} correctly this time. It's just a too marvellous tool that was presented on wayofthepixel. I just can't let it rest in the shadow for longer: behold the Rorschak test for pixel artists ... the ultimate inspiration generator that randomly fills a sprite sheet with monocrhomatic (and usually symmetric) pixels. What you see in here will only depend on who you are. I do see countless great design, and also a first step towards space-invaders-meeting-netcraft ^_^

And if you still don't see anything, click the picture and you'll get another sheet for you to play.

branch/companim

2012-01-14T09:29:00.008+01:00

Rien de tel qu'un peu d'UML pour commencer la nouvelle branche du SVN "animation composée" (imho). Ah, mais peut-être voulez-vous un mot d'explication sur les "branches"? C'est l'équivalent pour un programmeur de "Dis, on va commencer par dupliquer la maison dans un univers parallèle avant d'attaquer les travaux pour la véranda. Comme ça, si on doit chercher les clés à un moment donné, on a qu'à le faire dans la copie de base. Et puis on peut laisser les enfants dormir dans celle-là, aussi: inutile de les envoyer dans la copie où on a abattu le mur du salon et où l'eau ne va plus jusqu'aux WC, hein ?"

Convaincus ?

I was quite confuse on where to start working on the compound anim support, so I just started by depicting the current situation into an UML blueprint, trying to precise which are the different phases of SimpleGob::play, which member variables where involved when, and where in the class hierarchy they stand. Part of my indecision came from the fact that the abstract class GameObject is designed to capture what controllers use, so I wasn't quite tempted to push up the state management there.

And to my suprise, that alone suffice to show me the right path to take: introduce a CommonGob class that capture what's not-in-GameObject but should be in all the technical variation of the animated objects.

Bon, première tâche dans cette branche, donc, c'est de refaire un peu l'état des lieux. Une animation composée, ça change essentiellement l'animation des GOBs, mais l'état, les contrôleurs, les collisions, tout ça reste identique. Ouais, sauf que jusqu'ici, tout ça est uniquement dans SimpleGob.

Une fois tout à plat sur ce joli "bluescreen" (excusez ma nostalgie d'ex-codeur en QuickBasic), la solution devient évidente: introduire une classe "CommonGob" qui regroupe tout ce dont SimpleGob et CompoundGob auront besoin dans leur fonctions "play" sans toucher au GameObject héréditaire endogène ... ce qui fera sans doute plaisir à BlockArea, accessoirement.

If you don't get a word of UML then ... well ... I guess the sketched-up version of a former, similar reflexion might help you to figure out what is this CompoundGob stuff all about.

Pendant ce temps, dans le code ...

2012-01-12T12:30:00.002+01:00

Oh, pas de soucis: je n'oublie pas Bilou, malgré tout cet intérêt renouvelé pour mon perso Ubisoft favori... Mais comme les études de Rayman et de Shantae ont pour objectif de construire le synopsys lointain, comprenez que je garde ça "en réserve" pour plus tard... Il faut quand-même bien que vous ayez le plaisir de la découverte quand je vous proposerai 4 écrans par monde dans nuts'n'bolts, hein :)

Don't worry: I keep working on Bilou, even though it's sort of top-secret sketching of distant scenario ideas for whatever will happen beyond the green & school zones you already know. I'll start working on the integration of animations edited with AnimEDS into the game engine. Please allow me to keep my todo-list in French only and focus back to my soup now :P

Entre-temps, il va falloir que je voie à intégrer les animations complexes générées par AnimEDS dans le moteur de jeu, sinon, c'est moins rigolo :P

le GameScript pourra se servir des informations de anim[i] pour décider de créer un SimpleGob ou un CompoundGob (j'ai déjà une super-classe, ici)
pas de bloc "anim%u %x { ... }" pour les animations composée, donc pas d'appel à parse(). Je pourrais soit détourner "state%u :anim%u { ... }" avec "state%u :spr%.anim%", soit pré-déclarer les animations "anim%u = spr%.%" -- l'idée étant d'autoriser des "pages d'animations" et d'avoir de préférence une page par fichier de commande.
j'ai des commandes générales et des commandes "d'affichage" dans les anims. Est-ce que ça vaut la peine d'essayer de ne conserver qu'une seule copie des commandes générales ?
Dès que je vais vouloir utiliser des déplacements automatiques, il me faudra de l'état par composant, ce qui rend moins attirant l'inclusion du code qui gère case ANIM_SET_SPR au sein de GobAnim ...

Origins band land

2012-01-11T19:00:00.002+01:00

"Je suis arrivé au 2eme monde: la musique" me dit mon frère. Il venait de lire mon éloge du premier monde de Rayman Origins, mais il était un peu déçu par ce nouveau monde "c'est tout creux, vide quoi. Un peu mort aussi". Je souris: je viens de refaire le "Band Land" du Rayman d'origine, "Band Land" signifiant à la fois le pays des groupes (de rock/jazz) avec un jeu de mot sur "Bad Lands", les terres arides et rocailleuses ... Mais une fois la manette en main, je dois bien reconnaître qu'il n'a pas tort: les mêmes instruments tordus encore et encore, quelques tambours-tremplins ...

Il faut dire que le 1er monde avait placé la barre assez haut. Retournons voir les images trouvées ça et là sur Internet ...

Non seulement c'est beau et détaillé, mais un plus, c'est particulièrement varié. On passe, l'espace de quelques niveaux, d'une forêt sombre et dense à une caverne moussue, puis une sorte de plage avant de partir à l'assaut des montagnes. Rien de ce genre (ou presque) dans le niveau musical. L'action a beau être variée, le niveau "des angry birds" reste un monologue visuel. Même dans les passages secrets où l'on délivre les électoons, on reste en environnement ouverts (moi, j'aurais bien vu ça à l'intérieur d'un tambour ou d'un saxophone :P).

Mais entre les câbles électriques, le planage le long des mélodies et les niveaux venteux, on ne s'ennuie pas jusqu'au monde des desserts glacés, qui -- je l'espère -- nous remettra une deuxième claque graphique pour enfoncer le clou ;)

Evidemment, dans Rayman version PSX, on a pas du tout cette idée de "désert" pour la zone musicale, vu qu'il était conçu comme "Ciel Chromatique" par une équipe franchement francophone.

The Art of Rayman

2012-01-08T20:52:00.008+01:00

Armé de mes Copic et de ma DSi sur laquelle j'ai fraîchement installé le Rayman de mon adolescence, j'entamme le même genre d'analyse du graphisme du jeu que ce que j'ai fait pour Shantae. Bon, évidemment, le graphisme de Rayman est en grande partie de la peinture retouchée, et pas du Pixel Art, donc je ne sais pas en tirer le même genre d'enseignements ... n'empèche...

C'est étonnant de voir qu'il n'y a plus ou moins aucun arbre "normal" dans tout le premier monde. Des troncs-champignon, ça oui. Avec même des "mains" qui vous supportent. Pourtant, les couleurs et la texture sont celles du bois, et donc, on voit du bois.

Étonné, aussi, de voir que certains éléments de décor peuvent être allongés ou raccourci, malgré leur complexité. Chapeau! Les troncs couchés et les "palmiers", notamment. Il est rare d'avoir un même objet de grande taille plus de 2 fois dans un seul niveau, mais par contre, beaucoup moins rare d'avoir un objet repris à moitié découpé sur le bord de l'écran en début ou fin de niveau, où l'impression de "copié-collé" sera moins forte.

Autre grosse différence avec ma "green zone": Pas de terre dans la forêt primordiale de Rayman. Des cailloux, oui. Des entrelacs super-serrés de lianes, aussi. Mais de la terre, schnoll. Nada.

Pour pouvoir construire leurs niveaux, les p'tits gars d'Ubisoft n'ont pas hésité à utiliser un truc courant (mais souvent mal utilisé) chez les pixel artists: le contre-jour. En-dehors des pierres détaillés, certaines zones plus sombres sont tout simplement d'une couleur unie, souvent au bord des zones.

So I've got new Copic markers and a freshly downloaded Rayman for DSi. Neat. Just what I need to do some graphics analysis the same way I did for Shantae, although it's clearly non-pixel-art, but rather converted and carefully fixed painting.
Each level in the Dream Forest features one or two "large background element" that gives it a unique style compared to the generic "green & rocks & water" template that has been seen in so many games. Some of them are interactive (mushroom trees), other are purely decorative. It's rare to see them repeated more than twice in a single level, but it's frequent to see them repeated (but only partially) near the begin or the end of the level.

It's also surprising to see that, despite the "wooden" colours and textures of some components, we never see a real "tree" in the foreground in that forest. Are these vegetal tentacles ? Are these mushrooms-on-branches ? It's just some fantasy. Rayman Origins is much more conventional, to that regards.

Another impressive thing: the way the artists managed to create variations of some relatively complex element. That's especially visible with that sort of "palmtree" seen during the "bzzit fight". Here, they strip a part of the full-size tree. There, they duplicate a part to extend it. Simply thanks to a bumpy detail that makes the seamless connections possible. Well done, dudes.

PS: thanks fly to the maintainers of the raywiki: some of the screenshots they have were quite useful.

Climb up, and start the ro .. nevermind.

2012-01-07T18:50:00.000+01:00

Voilà bien le genre de "mini-cave" cachée dans le monde de Shantae qui m'aura fait souffrir ... (et qui renforce mon impression que le jeu tient presqu'autant du "zelda" que d'un jeu de plate-forme classique, au passage). Pourquoi ? parce qu'il va falloir sauter de chaîne en chaîne jusqu'au coffre ... et retour. Et assez curieusement, dans Shantae, s'accrocher à une "corde" verticale en cours de saut est assez délicat.

Grab a "rope", climb up, hop, grab the next rope, climb down a bit, hop, grab, hop, grab, climb ... This is sure nothing new. I think even Pharaoh's curse had a screen that was designed along that rule. And you'll sure face it a couple of time in the armaggedon machine as well. So why is it so tedious to perform it right here ?

Pour s'accrocher, il faudra que le joueur presse le DPAD en direction "haut" pendant qu'il saute (vers l'avant, de préférence). Et on dirait bien que sur la DSi, ce genre de manipulation est assez peu pratique. On passe un tout petit peu trop facilement de la diagonale "haut-droite" à la position "juste vers le haut", auquel cas Shantae s'immobilise presqu'immédiatement et tombe si le joueur n'a pas bien estimé la largeur de la zone de collision de la chaîne.

Well, first, I'm playing Shantae on the DSi, with a DPAD, while I mostly grow my platforming skills with a keyboard, where there's no such thing like a "diagonal" position. And apparently, holding the DPAD in a diagonal position is not so easy. As Shantae quickly loses her horizontal velocity if you release the "right" direction in-air, you're better have a very precise understanding of how wide the collision area for those "ropes" is, or you might end up to instruct the game to "climb" when that cannot be done (not yet), and just start falling where you are. I'll have to keep that in mind when I'll implement vines-climbing in Bilou.

Keen demande lui aussi que l'on presse vers le haut pour s'accrocher aux "barres verticales". Mais ayant majoritairement joué sur clavier, ça ne me posait aucun problème.

symbol 240,60,126,255,254,255,126,60,62

2012-01-04T20:02:00.002+01:00

Premier passage de Pierrick chez moi, en 1993. Il attrape une feuille au hasard sur mon bureau pour me montrer comment il réalise des personnages sur son Amstrad CPC, à l'aide de la commande "SYMBOL" qui reprogramme les caractères graphiques. La feuille était en réalité le dos du plan du premier niveau de Calimero ... ce petit croquis a donc voyagé dans le temps jusqu'en 2012 ^_^

Heh. That one survived too, on the back of a level map that my brother had with him at school: the bubble-shaped character that Pierrick used as hero for small flip-screen platformers on his CPC. I've long time wished that reprogramming characters on the C64 basic was as easy as SYMBOL x,... but even for sprites, it was a PEEK/POKE nightmare, so almost all my C64 games attempts were merely using PETSCII.

Celà se passe sans doutelégèrement après que mon frère ait dessiné la page d'introduction de "Bubule Warrior", sans doute parce que Pierrick dessine depuis longtemps des personnages tous ronds autour de ses feuilles de cours.

Happy New Year !

2012-01-01T22:45:00.004+01:00

En guise de carte de voeux, une "fractale du temps" de toutes les "releases" de mon projet sur DS depuis 2006. J'espère la compléter dans le courant du mois avec les "choix stratégiques" sur le moteur de jeu, etc.

Maybe a fractal timeline is too geeky for my audience, but at least, it allows me to tile all the downloadable material released on this blog since 2006. Let's pretend it's my new year's wishes card for 2012

branch/newcollide : buggy

2011-12-27T16:29:00.007+01:00

Voilà environ 3 mois que j'ai entammé la révision du moteur de collision de Bilou, avec pour objectif de permettre la gestion de blocs, plate-formes et autres. Je n'ai pas avancé très vite, mais le code compile et fait tourner AppleAssault ... enfin, presque. Voyez plutôt ....

3 monthes to get a first prototype of the new collision engine. I haven't been very quick on that, but at last, Apple Assault mostly work again ... well ... sort of. I'll let you judge that.
-- btw, I wonder whether desmume-cli --record-movie would be easier to use than byzanz-record for those posts. Please, allow me to debug that on-line:

# stopped by monster-player collision.
statW0->statF2 on found1 (v0 ~ :0 200 ~ :1)
statW1->statF3 on found1 (v0 ~ :0 200 ~ :1)

Makes the appleman bounce when it hurts Bilou

#hit
state4..7->statH15 on hit0
\\   [wc 1 ? we 0 < &] (256 ~ :1 512 ~ :0 0 :6 x1)
state4..7->statH16 on hit0
\\   [wc 1 ? we 0 >= &] (256 ~ :1 512 :0 0 :6 x1)

The collision halfly works, on the video above: the applemen indeed bounces and the collision is triggered. But Bilou isn't affected. Afaik, that's because something got wrong in the guardian expression (conditions between the square braces) that can no longer be true in the new collision engine. Before we actually take a transition to the "hit-to-left" (H16) or "hit-to-right" (H15) state, one must detect where the collision came from (test on 'we', other dude's variable #14, which holds centrum-to-centrum horizontal distance), and whether it was actually something that hurts (test on 'wc', the other dude's variable that indicates the matching collision bits on both active and passive collisions area). For some reason,

case OP_GETCTX:
   if (sp>=STACKSIZE-1) return oops("vCTX");
   if (c[1].data==0) return oops("!CTX");
   if ((op&0xf)>=0xc) stack[sp++]=xcontext[op&0x3];
   else stack[sp++]=c[1].data[op&0xf];
break;

Did return at the oops("!CTX") line. In that case, the expression is never true. Bilou won't ever got hurt. I must be missing something that swaps contexts in the code that manages collisions, at the root. Some gc[2]=gc[0]; on line 1742 could do the trick...

that and some silly boolean inversion in the c[1].data =? NULL condition ^^"

Plus de dessins ...

2011-12-25T11:21:00.002+01:00

Eh bien donc, à défaut de la tablette de mes rêves qui n'existe visiblement pas, voici au moins quelques outils qui vont donner un petit coup de jeune aux croquis sur papier qui me plaisent tant. Trouvaille de ma fée, les "Copic multiliner", avec une précision en-dessous de 0.1mm. Je ne savais même pas qu'une telle chose pouvait exister. De quoi se rapprocher des ombrages au porte-mine affûté :)
Et en complément, des "uni-ball UB-157", avec lesquels j'avais déjà eu l'occasion de faire quelques essais à Bâle, mais que je n'avais jamais retrouvé en magasin jusqu'ici. Visiblement, ma fée, elle, elle a trouvé ^_^

One man and his (an)droid

2011-12-21T09:24:00.011+01:00

Je me suis arrêté d'abord sur le prix: 90€. Non, pas de 3 ou de 4 devant, juste 90€. C'est bien le système androïd qui tourne sur un processeur ARM à 600MHz, avec 256Mo de RAM et 4Go de stockage interne. Lecteur de carte média ? check. Connectivité Wifi ? check. Evidemment, à ce prix-là, ni 3G, ni téléphone, mais on a quand-même l'écran tactile. L'écran ne fait que 10cm avec une résolution plutôt miteuse (480x272 ... ils ont été chercher ça où ?), mais comme kit de développement, ça place la barre nettement plus bas, et c'est tant mieux.

The iPad is not for me. That's a fact. The more I test "my brother's one", the more I'm comfident with that. Paying +400€ for an Android phone ? well, I don't think so. My little vgmap-themed Siemens C60 does the job so far. But that doesn't mean I don't see any interest in androïd development ... at least that's what I realise when I see in an advertisement magazine an ARM-powered device with WiFi and SD media card for 90€. No kidding. You would barely find an iPhing *stylus* for that price :P. Either that or the digitizing pen from Staedler, with the hope that it would work correctly under Linux.

On y verra plus clair après test en magasin. Sinon, il restera l'Asus Transformer, mais nettement moins abordable ...
D'un autre côté, pour 20€ de plus, on passe à 18cm d'écran (800x480, mpman720) pour une tablette taille A5. On fait des stylets, pour écrans résistifs ? oui. ça, j'aime :)

Mais tout au fond de moi, je crois bien que ce qui me serait le plus utile, vu ma manière de travailler (que ce soit pour le boulot ou le Bilou), c'est cet espèce de bic-numérisateur autonome ... 'faut juste voir si la suite d'outil que Staedler propose avec fonctionne sous Linux :)

Evidemment, si les gusses qui avaient proposé le projet Noteslate avaient effectivement réalisé ce qu'ils promettaient, je ne me poserais pas tant de questions.

Of course, both are pathetic replacement for the missing noteslate on my christmas wish list.

Dernière possibilité, aux alentours de 180€, le e-Reader de Sony (PRS-T1) avec la technologie "e-Ink" annoncée dans la noteslate, wifi et écran tactile. Mais c'est Sony. Les connaissant, ça ne va pas aller sans mal de faire du homebrew là-dessus ... quoi que ...

The missing BlockAction

2011-12-20T13:06:00.005+01:00

Here's a scan that discusses a missing abstraction in my model so far, to carry on a "thread" on a map location (as compared to a tileset location). I figured out I was missing it when I tried to implement crumbling floors for the "nut's'blots" intermediate project, in june 2010. It remained a draft sketch all that long.

An amusing fact: despite this is still missing from the *model*, there is actually creation of a GameObject derivative (BlockArea) so that you can proceed with evaluation of the "block:on hit" expression ... so all it would require would be to capture this derivative for longer than just a collision. I just realised that while investigating why the new collision system no longer works with interactive blocks...

Un vieux scan de Juin 2010 avec, en Français, le détail des "BlockAction" qui manquent encore à mon modèle de jeu. D'une manière assez amusante, la manière dont les interactions sont gérées vont déjà dans ce sens même s'il n'y a rien au niveau du "gobscript" qui permette d'en exploiter plus largement les possibilités.

A less amusing fact: this was all coded before we had dynamic gob lists, and it's now trying to de-register a Gob from the game engine several times every frame (especially when the interactive block is not de-activated by the collision). That could explain some performance issues observed in early AppleAssault prototypes.

wanted features

2011-12-12T13:08:00.017+01:00

There are things I would like to improve in each of my tools. Maybe it's a good time to collect them in one place. Various features I'd like to add to LEDS depend on the ability to display the map at once. I planned a radar widget in a corner of the TilesetWindow, but that's only 64 pixels wide. If I want 1 pixel per tile, that's only 2 screens wide.

To do better, I'll need to fit at least 8x8 tiles per pixel, thus I'll need direct-color rendering to vary the "gray" level to the number of "solid" tiles in an area.

I've already some code that creates a direct-color sprite (SpriteEditor, PaletteWindow, GrayPreview), but I remember I had a hard time making it work. Reading gbatek again wouldn't hurt.

On the other hand, it would be good if I could have a "stencil" feature (as in Deluxe Paint IIe) in SEDS. I realised when packing the new version for Atnas that I had a serious bug with my previous attempt to have it running. The 'quickpal' widget could be used more appropriatedly to build that idea.

Last thing, I'd need some alternate zoom level for the animation editor. Bilou, dumblador, ... they aren't the size of that Mr. Egg. I did a try a few weeks ago, but at some point, the code that enforce that position is at a specific pixel (not a fraction) despite the zoom level wasn't planned to work at other levels. More thouhgts needed.

edit: Oh, well, and of course, there's the revised collision engine, still pending in its branch. Maybe *that* should be the immediate focus ...

edit+: My milestone for the next release of LEDS should be to ensure that it's fun for a middle-aged kid to draw his own level. That may require the ability to "freely draw" an object for which no pixel art exist yet, and to allow that object to be imported in SEDS later.

The art of Shantae

2011-12-10T15:04:00.009+01:00

Prenez votre princesses des 1001 nuits préférée, assurez-vous qu'un djinn lui offre ses pouvoirs histoire de se transformer à volonté et qu'elle sait vous envoyer claquer ses cheveux à la figure sans trop craindre le tour de rein. Rétrécissez-là pour qu'elle ne dépasse pas les 64 pixels de haut, et vous avez un assez bon aperçu de Shantae, l'héroïne qui me garde scotché à ma DSi ces derniers temps.

Il faut dire qu'avec les graphismes de Henk Neiborg et la musique de Jake 'Virt' Kaufman, la demoiselle me faisait déjà de l'oeil quand elle n'était qu'au stade d'esquisse dans les cartons de WayForward en 2008 ... Au point que j'avais fini par désespérer d'y jouer un jour avant que sa sortie ne soit annoncée ... sur le DSiware exclusivement. Un choix que je comprends mieux maintenant que je suis au portes du repaire de Risky après 6h30 de jeu (et 3 donjons uniquement), une distribution en grande surface n'aurait probablement pas valu le coup.

If you own a DSi and enjoy platformers, Shantae: Risky's Revenge is definitely worth 1000 of your dsiware 'points'. No kidding. WayForward studios know where to find pixel and chiptune experts to bring you into an unprecendented experience. Three dungeons only, but connected by a nice overworld for you to explore with hidden treasures here and there that will allow you to upgrade your character at the town's shop. Does it sounds like an RPG instead ? Well, there are definitely some quest-based elements in that little gem as well. More than Mario inspiration, imho.

Côté gameplay, on est clairement dans un jeu de plate-forme, "armes à la main" (pas de rebonds à la Mario, donc), mais à portée réduite (donc, pas à la Megaman non plus). En fait, avec son échoppe du village qui vend de la crème de soin pour cheveux et les pouvoirs magiques à faire grimper au fil du jeu, avec ses boss qui dialoguent et son design narratif, c'est encore à un Zelda que Shantae ressemble le plus, assez paradoxalement. Les phases d'explorations entre 2 donjons sont là, elles aussi, avec des objets ridicules à récupérer pour faire un Cafe-latte à l'oeuf pourri pour les frangins de votre copine la zombie ...

C'est aussi la conception du 1er donjon qui m'a mis dans cet état d'esprit "un zelda dans un jeu de plate-forme". Des jarres à casser pour récupérer des petits coeurs, des fioles vertes pour reprendre de la magie, un parcours tortueux où l'on constate que "rhaa! impossible d'atteindre ce coffre", jusqu'au moment où l'on trouve un autel magique qui donne accès au pouvoir de transformation en petit singe. Et désolé pour les fans de Sailor X, Shantae garde bien tous ses vêtements lors de ses transformations, mais se déhanche sur des pas de danses qui remettent dans l'ambiance "foufi et le tapis magique" ceux dont l'esprit se serait trop égaré du côté d'Hyrule.

I have plans for a "lost temple" zone in Bilou since I've seen TomF's temple level on pixelation. But that's not a environment I'm comfortable, so I also gave Shantae a second run and picked my sketchPad to capture as much knowledge as I could on how it is built up. I hope I'll be able to use that later to create great pixels ...

Alors comme je manque un peu de références pour faire un bon environnement "temple perdu" pour Bilou (inspiré de la 'Maya Zone' proposé il y a longtemps par mon frère pour un autre jeu), je reprends la DSi et le "sketchbook" que mon beau-frère m'a offert l'autre jour et j'analyse les graphismes de mon mieux. Curieux, d'ailleurs, de constater que si l'overworld de Shantae est varié et chatoyant, tous les donjons (et grottes) utilisent plus ou moins les même graphismes, beaucoup plus simples -- rien à voir avec les coups d'essais de Henk en 2008. Mais une savante combinaison de décors chatoyant (dans un donjon, oui, oui) et de variation de teintes feront que le joueur se focalisera sur ce qui est "dans le thème" et ne se rendra compte de ce détail que s'il fait explicitement attention aux graphismes. Et quelle maîtrise. Ici, le buisson pend du plafond, là il est posé sur le sol. Même une salle rectangulaire "toute simple" est rendue graphiquement intéressante par une foule de ruses.

Bref, j'en ai encore une fameuse dose à apprendre et à maîtriser.

And yeah, the game is a bit short, esp. compared to what the GBC version offered

Ubiart: mission réussie.

2011-12-08T20:20:00.001+01:00

La 2D fait un grand retour dans les jeux vidéos. Ce qui a commencé avec les pixels tout anguleux de Cave Story s'est poursuivi dans un style beaucoup plus inédit pour Braid, et confirmé avec une reprise de "Boy & his Blob" (par WayForward ... tiens, tiens ;) tout à fait croustillante et merveilleuse. Le livre-pour-enfants-dont-vous-êtes le héros était plus ou moins né. Par un merveilleux détournement des capacités graphiques de nos consoles modernes, il devient possible de construire des mondes vidéo-ludiques sans jamais avoir à se tracasser du nombre de couleurs, de la résolution, ou d'une quelconque limitation matérielle. En gros: dessinez, c'est gagné.

There was a time were video games were slaves of the third dimension and polygon counts. No game would be seriously considered if it hadn't 360° exploration, jerky textures when approached too close and odd camera decisions (or a secondary direction stick for direct camera control). Hopefully, in 2004, the world realised that a old-fashioned, 2D video game could attract masses as well if, like Cave Story, it had inherent soul that made it interresting to play.

Oui, mais alors, on va pouvoir de nouveau faire des jeux vidéos comme au bon vieux temps ? un graphiste pour les décor, un animateur pour les sprites et un gars qui sait coder convenablement pour lier un peu le tout ... Plus besoin d'une équipe de 40 personne avec trois managers et tout un château pour leur permettre de bosser? On va enfin pouvoir donner libre cours à sa créativité sans devoir d'abord convaincre la moitié de l'équipe qu'on tient le bon bout ?
It took some time for this truth to reach the major videogame studios, but Nintendo got it clearly: New Super Mario Bros used the 3D power of the DS to bring it diversity in moves and greater control over the character, but the gameplay was back to something simple, that can be mastered in a few days, not in months.

And with the Wii edition, platforming rediscovered its true nature: to bring in a fun experience where cooperation amongst player is the key to success.

Sauf erreur de ma part, c'est la le pari de UbiArt, le "kit de développement" derrière la réalisation de Rayman: Origins.

Parce qu'entre temps, même Nintendo s'est remis à la 2D "remasterisée". New Super Mario Bros, Kirby ... Le hard-core gamer peut continuer à se tordre les pouces sur ses manettes bizarres, nous on s'en sort très bien avec nos vieux pads et nos 3 boutons. D'autant que cette vue sur le côté permet bien plus facilement de faire intervenir plusieurs joueurs dans la même pièce. Un argument de poids qui donne au titre un aspect super-convivial. Familial, même. De quoi délier les bourses à l'approche de Noël autour du nouveau phénomène: le jeu-vidéo-de-société.

It was now only a matter of tools that video game could once again become the affair of a small team, where creativity and fun can prevail over technical effects and shaders. Ubisoft built that tool and created Rayman: Origins with roughly 5 people, where the original "Rayman vs. Mr Dark" on PSX ultimately enrolled up to 100 people, artists, coders, animators ... to make something simpler come to life. And not only the world of Rayman: Origins is beautiful. It really feels alife.
Il restait à Michel Ancel un défi à relever: rendre son monde virtuel vivant. Bien plus difficile dans un jeu vidéo que dans un dessin animé, car le joueur peut s'arrêter à tout moment, et ce sera alors à l'environnement du jeu de convaincre qu'on est pas juste devant un joli tableau mais dans un monde. Sans ça, l'immersion tombe -- et l'immersion, c'est un point déterminant pour avoir un jeu réussi. Eh bien, pas de soucis. Par un impressionnant mélange de parallaxe, d'ajustement du niveau de détail, d'animation vectorielle et j'en passe, le défi est relevé. Je n'étais franchement pas un fan du "nouveau look" de Rayman, qui semble avoir subi un croisement avec les blork de Kid Paddle, mais le résultat est là. Amusant, dynamique, de toute beauté ... Je n'ai pas de PS3 et croyez bien que j'attend avec impatience la prochaine invitation de mon frangin ;)
This multiple levels of parallax scrolling with hand-painted hills and grass give a feeling of immersion and environmental freedom that is imho unprecedented, even in Mario 64 and its friends. The action is still almost purely 2D, but you'll never feel like "why the hack can't I pass *next to* this monster rather than fight it". Reason number one is that at some other places, you clearly had some depth around you. The second reason is that it's quite fun to fight monsters here :)

SEDS interface revision with Atnas

2011-12-06T22:00:00.003+01:00

One of Pixelation forum moderator started investigating tools for pixel-art (essentially game art) on DS/DSi. The only competitors listed against SEDS were actually animation programs (animatee and InchWorm on the DSiware). Pocket Pixies and Smoove are defunct homebrew. Yet, SEDS is still far from being user-friendly.

My main problem with the interface is even with the documentation, I have no idea what anything does and the controls don't respond as I'd expect, in fact at times they seem situational. I think if a little screenspace was dedicated to a tiny toolbox it would help things a lot. Another option is a sort of pop up menu like animanatee does: when you hold a key, in their case it's L, all the options are at your fingertips.

Also, sometimes when I'm fooling around with the tools to try to learn them, I get locked out and cant find my way back to drawing and need to restart. While I pixel I'll only ever have one hand for buttons, so making the left (or right, its usually mirrored in ds tools) dpad (buttons) contain everything I'll need is a plus.
If you want, I could give you a mockup of what sort of thing would be most helpful. SEDS is much more powerful than anything else out there, it's just much harder to use.

My first modification was thus to make sure you can always return to the normal "drawing" mode, by the addition of a "Draw" button on every sub-screens (such as palette screen or animator screen). That should avoid guest to get lost, even though they explore the controls. Pave they way out to the "normal" screen. I hope those colour-reduction buttons will not cause trouble.

SEDS est difficile à prendre en main. Ce n'est plus un scoop. Mais quand c'est un modérateur sur Pixelation qui en fait la remarque alors qu'il cherche un moyen de dessiner des graphismes pour un jeu avec une DS, ça a de quoi me motiver ... et pas qu'un peu. En attendant qu'il me propose un 'mock-up' pour une interface graphique remaniée et réponde à mon questionnaire, j'essaie déjà de résoudre les deux problèmes principaux que j'ai pu identifier en discutant avec lui: permettre à tout moment de recommencer à dessiner et choisir ses outils de dessin sans le secours des boutons ABXY.

Second message I've heard: keep the stylus-holding hand free. I mapped quite a lot of controls on the ABXY buttons, especially on the grid. If one doesn't know too well the drawing options available, it's easy to be confused. The "block", for instance, doesn't immediately draw, but needs two touches for the two extreme corners. Now, the tool you're using is always highlighted, and you can select a tool by just clicking the toolset on the top line.

Now, I still have to work on a way to provide a "menu" for secondary actions. Colour reduction, palette re-ordering and similar actions could be candidates, but I'll have to think which one must really go there to unclutter the UI without making most actions being multi-click.

There are other features I'd like to bring to SEDS, and one of them is free-hand sketching at "real DS resolution" over the "grid", so that you can then do your anti-aliasing or curves rendering with some guide-line.

Anyway. I'm waiting for Atnas' feedback in form of a UI mock-up ... Let's see whether we'll also have SEDS revised for christmas ;)

release_name="svn SEDS r" REVISION ;

2011-11-30T22:45:00.005+01:00

Once again, I ended up fighting on my DS with a tool (AnimEDS) that has a bug (timeline edition) I'm pretty sure I've addressed weeks ago. Question is: is the DS running the latest version or not ? well, except if I manage to re-create various versions of the software and compare their MD5 with the one on the DS ... hmmm ... unlikely to work with DLDI patching :-/

So I just acted at the source: modified the makefiles so that they extract the revision number from svn info and turn that into a C string I can display from the welcome screen. I won't pretend it's clever: there are sure tons of way to achieve that, 90% of them being largely proof-tested and documented. I just needed one version that works for my own development, so I won't even look at automake or $CVS or whatsoever. A grep|head|sed> oneliner just makes it.

Avec un peu de chance, je ne perdrai plus mon temps, dans la suite du projet sur DS, à tenter de deviner si j'ai bien la dernière version d'un de mes outils sur ma DS quand je repère un bug. Je viens de remodifier les sources de LEDS, SEDS et AnimEDS pour qu'ils annoncent automatiquement la "version svn" qui a servi à les compiler (bon, ça marchera surtout si je fais un commit avant de faire le "make all install" ;). Pas particulièrement propre, sûrement pas original, et même pas repompé d'un truc préexistant. Bricolé en 1/2 heure. Mais je sens que ça va être drôlement utile.

Allez, ciao. Je vous en montre plus dès que j'ai réussi à faire passer mon commit à travers ce firewall à 2 balles.

edit: there's a danger that remains: when I re-build one of the projects, I may miss to re-build libgeds or runme first on that platform, which could lead to some features not to work properly. That just happened with "wfcWindow::restore()" that wasn't called for some odd vtable-linking messy reason.

Lake District.

2011-11-29T07:52:00.005+01:00

6h du mat... si j'ai dormi 4 heures sur la nuit, c'est beaucoup. Le lit est une vraie planche, et si mes voisins de paliers ne sont pas franchement bruyants, l'accoustique du bâtiment ne permet pas d'apprécier leurs tentatives de discrétion à leur juste valeur. Je suis en visite dans le district des lacs pour la semaine ... et je sens que ça va être un longue, très longue semaine.

Avec du café et des bananes.

Mais bon, faisons un peu le point. Début de l'année, je me fixais pour objectif de faire une première release publique de l'éditeur de niveau et de passer mes autres outils sous le "nouveau" devkitpro. C'est fait. Je me suis autorisé à faire de nouveaux graphismes pour la School zone, étant donné "qu'un premier jeu a été réalisé avec les graphismes de la green zone". Ils ne sont pas encore au complet (il me manque un décor potable, par exemple, peut-être en transformant la bibliothèque en un vrai campus), mais ils prennent forme. Le prochain jeu d'arcade de Bilou se fera dans la school zone. Ce sera sans doute "deep ink pit", mais il y aura une ou deux "gedsdemo" avant ça, pour tester le comportement des monstres... et m'amuser un peu ^_^

Ce serait peut-êtr bien le moment, tiens, de mettre le couvert avec les monsstrrrres. Un bien grand mot pour Bop, Dumblador et les encriers que ma petite puce nomme maintenant avec excitation. "Tu vas dessiner Bilou, toi?" me demande-t'elle à chaque allumage de ma DS(i) ... et ces derniers jours la réponse était plutôt "non, ma puce, Papa essaie le jeu de quelqu'un d'autre" (Shantae. On en reparlera). Voyons...

Bop, l'éponge, pendue à son fil. Ça demande un contrôleur nouveau, capable de gérer ses oscillations. Je me suis déjà amusé à voir comment faire ça avec de "simples" accélérations autour d'un point... sur le papier, ça tient la route, mais il faudra le coder pour voir.
"inkjet", l'encrier. Lui, il attendra sans doute que j'ai une version qui compile du nouveau moteur de collision: il est le candidat idéal pour les alignements de Gobs qui rende possible les poussées, transports et autres plate-formes mobiles.
Dumblador. Je devrais probablement commencer par là. En plus, c'est le candidat idéal pour faire quelques tests d'animations modulaire, vu que je ne lui ai pas dessiné de pieds. J'aimerais reprendre les pieds de Bilou, mais en rouge. Solution de facilité ? les recoloriser. Solution idéale ? activer enfin le support multi-palettes, puisque la DS supporte en réalité 32 palettes de 256 couleurs (16 pour les tiles et 16 pour les sprites).

Je crois que je vais choisir la facilité pour l'instant. Sinon, on risque fort d'en causer encore à Noël. Or, ce serait plus sympa de faire des essais dans gedsdemo-books, à Noël, non ?

Bon, là-dessus, il est enfin 7h ... je vais aller trainer mes baskets jusqu'au bâtiment où ils servent le petit déj.

Oh, well. Sorry, english-speaking folks. I was just "thinking out loud" to figure out where to move now. Since I'll have to speak english the whole week (travelling), please allow me not to provide a personnal translation this time :P

Level Editor for DS : 0.1

2011-11-27T16:46:00.007+01:00

Nous y voilà enfin: mon éditeur de niveaux disponible au téléchargement, avec les bugs corrigés, même si l'interface reste assez expérimentale. Avec en prime deux tilesets Creative Common pour vos petits tests: "generic.spr" par Surt (CC-BY-SA) et "frogatto-dirt.spr" (CC0) par Guido Bos. Amusez-vous bien, les tifous: la version française du tutoriel est en construction sur le fil "dev-fr".

Huzzah! At last, you've got it. My long-delayed Level Editor for Nintendo DS (LEDS) is at last available for download with some sample tilesets to toy with ^_^. Thanks fly to Surt and Guido Bos for releasing their game art under creative-common license on OpenGameArt.

The software is still a bit rough on the angles, so make sure you've got the tutorial page displayed on some screen when you'll use it for the first time(s)...
and now ...
Go create!

Features that I still wish to see appearing in a future release (check back this post for UI mock-up):

[hint] provide a way to change "type of tile" when editing the meta-layer, without requiring on-map display. (we have the whole ABXY buttons disabled in that mode, right ?)
flipped tiles that also work in "copy" mode
area manipulation (overlays?)
map size edition (crop, extend)
map sketching (zoomed-out drawing)
map radar widget
multi-palette support on the BG layer (needs SEDS coordination)
more robust monster edition mode.
use the ARGV protocol to quick-load a map from runMe *at a specific position*.

LEDS & OpenGameArt ...

2011-11-20T17:24:00.012+01:00

Si vous en connaissez pas encore opengameart, c'est bien dommage. Des dizaines de graphismes pour des jeux vidéos offerts à la réutilisation par leurs créateurs, voilà qui devrait éviter de passer par la case "voler les sprites de Mario" à bien des game-makers amateurs.

Comme je recommence à bosser sur mon éditeur de niveaux, la question se pose à nouveau "quels graphismes pour une version démo", histoire que vous puissiez essayer le soft même si le pixel art est totalement obscur pour vous. Eh bien, pourquoi pas ces anciens graphismes du jeu frogatto, justement ?

It looks like you won't get biokid-inspired tiles for the ~~demo~~ first release of LEDS. Neither will you get that 8-bit-restricted tileset for Apple Assault. Why would I push poor/old game art of mine where there's some ready-for-use tilesets on OpenGameArt, hmm ? These old frogatto tiles, for instance, dropped into public domain, would be perfectly fine. With some luck, annoying bugs should be gone by end of the week, and I'll be (at last) able to offer you a level-editor release 0.1 to toy with ^_^.

La question étant réglée, il me reste quand même

à m'arranger pour que la partie du niveau à l'écran ne soit pas perdue quand on quitte le mode "édition des monstres" -> done
à permettre de nommer la map au moment de la sauvegarde -> done
à vider le lave-vaisselle.
à permettre le "flipping" des graphismes dans l'éditeur de map. -> test
à garantir la cohérence du "curseur" sur le tileset. -> done
à empêcher le passage en mode "draw" depuis le "meta-layer" -> done.

edit: fichier converti avec les mêmes options que la "spritesheet" de Badman, l'automne dernier (déjà!).

Biokid strikes again

2011-11-19T11:31:00.003+01:00

Nouvelle journée passé à faire des recherches sur les attaques distribuées au boulot hier, nouvelle insomnie biokidienne cette nuit. Après un parcours ardu entre les fichiers log et les dll compressées, biokid parvient à abaisser les défenses d'un C5-C0 en l'assaillant de 'YAP' plus vites que ses buffers ne le supportent, évitant de justesse les bombes que ce lourdaut lui envoie en guise de défense

It looks like everytime I work on intrusion detection, I end up daydreaming of Biokid while I should be sleeping. No matter how hard I tried to sleep, the little blue dude kept jumping around, shooting at C5-C0 defense bots to stay unnoticed in the system he landed on. Then, in a flash, he broke into the bot's defense, scattering its internal logic and try to gather as many part of that logic as he can before the bot blow up. With all the pieces gathered, he'll be able to copy C5-C0's bombing ability.

Et tout d'un coup, juste avant que l'ennemi ne grille en un "core dump" définitif, un "dash" bien placé permet à Biokid de s'infiltrer au coeur même de ses défenses, éclatant sa logique interne dont il essaie de récupérer rapidement les morceaux ... Il faudra sans doute répéter l'opération sur un ou deux autres bots, mais quand les 16 fragments de C5-C0 auront été récupérés, Biokid pourra alors à son tour utiliser des bombes logiques ... et les C3-C0 actinalgiques n'auront qu'à bien se tenir...

Fire Zone

2011-11-16T23:00:00.006+01:00

Tout au fond de la Planète Mystérieuse où Bilou et Bouli sont crashés, il y a la "Zone du Feu", alias le "Volcan Terrible", alias la Forge de Vulcain. Inspiré par les étranges stalactites du niveau "manger chez Joé" du premier Rayman, j'imagine une sorte de marmite de lave naturelle ou les dragons-fourchettes et autres chefs enflammés chercheraient à utiliser notre sympathique boule bleue comme épice exotique ...

I'd like to come with something more interesting than a plain "fire zone" for Bilou... something like a giant foundry or ... yeah. A lava-cooking area with pepper-dispenser-shaped stalacmits and fork-headed dragons. Yes, that'd definitely be original ... or maybe the fire level in Rayman Origin is very original, and I've seen it before, but only remember it unconciously and will have to scratch my head to find something else :P

Mais après avoir joué à la démo de Rayman Origins chez mon frère ... on dirait bien que je vais devoir trouver autre chose. Cette fois-ci, j'ai dû clairement subir une influence subliminale d'un screenshot ici où là.

You voted for ... both.

2011-11-15T17:17:00.006+01:00

Here ends the poll on the school zone aesthetics. Thanks to the 8 readers who participated. I cannot say there is a "clear winner", but globally, the "newer" wood got slight preference as it is more "joyful". But that's for readers alone.

Simultaneously, I got feedback from two graphism artists (including one pixel artist) who didn't exactly "voted" to this poll, and they clearly stated that "the old wood was better, because it looks more like wood". That's something I cannot ignore, so I'm back at world 1-1 : *I* have to make the decision, or to come up with something that would combine the advantages of both. And the picture I just shoot at work might help.

Voilà. Cloture des votes sur un score plutôt mitigé. Si on peut dire qu'une majorité des lecteurs de ce blog ont préféré les nouvelles couleurs, plus vives et plus joyeuses, en revanche, les 2 graphistes qui ont jeté un oeil sont unanimes: l'ancienne version est nettement plus réussie, donnant plus un look "bois". pour ce bois-là, le fond clair est trop gris, et le fond sombre montre trop de contraste -- rien de difficile à ajuster.

Alors je reprends une petite photo du couloir, histoire de me faire un "vrai" raster de bois et de voir si je peux faire une version intermédiaire *aussi* pour le bloc de bois...

meta_buttons_shown=false

2011-11-14T23:33:00.004+01:00

Comme je devais tester une imprimante, ce week-end, je me suis imprimé quelques fichiers sources de l'éditeur de niveau, histoire de comprendre d'où vient le comportement erratique des "meta-buttons", cette petite palette en haut à droite de l'image qui permet d'indiquer quelle portion d'un niveau est solide, où sont les pentes, etc. Pour pouvoir éditer les "arènes" d'Apple Assault, je les avais rendus "escamotables", mais c'est loin d'être un succès. Ils donnent l'impression d'être actifs ou non indépendamment du fait qu'ils soient visibles ou non. Malheureusement, le Level Editor est aussi le dernier outil qui n'a pas encore été "porté" pour la nouvelle release du devkitpro. Du boulot en perspective, comme la réactivation de la lecture des répertoires, les nouveaux mécanismes pour initialiser la console, etc.

loadNDS_Vram turns into runNdsFile : http://dsgametools.svn.sourceforge.net/viewvc/dsgametools/trunk/SpriteEditor/source/main.cpp?r1=617&r2=824
convert to the new console system : http://dsgametools.svn.sourceforge.net/viewvc/dsgametools/trunk/runMe/arm9/source/main.cpp?r1=735&r2=750
at least those two must be done and checked before I can start fixing the huge mess that appeared on the Level Editor user interface when I tried to make the "meta-buttons" a pop-up widget... Yes, LEDS is the latest of my tools that has not received a revision since I switched to "devkitpro 32" ...

edit: done... maybe ?

choose your colour

2011-11-08T08:00:00.000+01:00

Deux tonalités possibles pour les blocs de bois: l'ancien et le nouveau. Deux tonalités possibles pour l'arrière plan: clair ou sombre. Faites votre choix sur le sondage à droite.

Two available tints for wooden blocks: new (yellow-ish) and old (grey-ish). Two available tints for the background: light or dark. Pick your favourite style using the poll on the right.

The google, the Bad, and the Ugly

2011-11-06T11:41:00.000+01:00

So even Google can fall into "we're too big to be wrong", obviously. Empty space everywhere, reduced reading area, "share" features lost and most ugly-and-depressive user interface I've ever seen. Yes, I even prefer the plain black-and-white of early Apple computers. Do you think that's how you'll convert me to G+ ? How can you hire so many people and just miss the good sense to avoid such horror ? when I happen to click on a "reader" tab now, I just want to close it as soon as possible.

You failed. Insert coin to try again.

On repeind l'école ...

2011-11-06T09:32:00.007+01:00

Après pas mal de soirées à effacer les modifications que j'avais faites, j'ai enfin une variante des "blocs de bois" pour l'école qui soit un peu plus colorée que la version de 2007 ... La tentative de "miniature" pour définir une nouvelle palette aura donc porté ses fruits ^_^

Last week, I tried to update the school zone pixels so that foreground and background would look like a common, 3D environment. It sounded a good way to start with colours that worked well as BG in the school zone. It was a flop. The picture was all greyish. I tried something new to solve it: a miniature level (started as a 32x32 bitmap and zoomed to 64x64) where I could do all the colour experiments I wanted, as they had no link with the former spriteset. Then it took me almost all the week to make some decent wooden block with those saturate-and-nicely-mixing colours. I think I finally managed to get something that works. It still needs a bit of anti-aliasing and some more touches here and there, of course.

Interpolation pour AnimEDS

2011-11-03T22:22:00.001+01:00

Je pourrais peut-être bien me remettre à plancher sur AnimEDS avec pour objectif d'offrir une "interpolation des mouvements" un peu plus automatique. Parce que pour l'instant, il faut encore "encoder" toutes les étapes d'animations en positionnant exactement les différents sprites, et quand on veut "réviser" une animation, ça devient vite l'horreur. Or en graphisme, les révisions, c'est plutôt fondamental.

Tracer un déplacement à main levée, ce serait assez simple, tirer k étapes intermédiaires le long des différents déplacements aussi. Chouette. Ce qui m'avait freiné jusqu'ici, c'est que dans ce genre d'approche, il n'y a pas moyen de "freiner" le mouvement, d'avoir un effet "balancier" indispensable pour une animation fluide et réussie ... sauf si je permets de tracer aussi la courbe "k en fonction du temps" ... Il suffisait d'y penser, j'imagine.

Mais n'oublions pas: il lui faudra d'abord un "zoom" pour contrôler la taille du cadre de travail.

Oh, DSi !

2011-11-03T12:20:00.003+01:00

Etat quasi-neuf, stock de protège-écran et de stylets de rechange, me voilà capable de faire tourner le "dsiware" pour tester les jeux qui me font de l'oeil depuis un moment. C'est aussi une "mesure de protection" pour pouvoir continuer le développement sur Bilou si jamais l'écran de ma DSlite venait à souffrir prématurément ou qqch comme ça. *deline a fracassé la cartouche de Qwak il y a quelques jours, et c'est un miracle si j'arrive encore à le faire tourner. Vu qu'il est hors de question que je prenne une 3DS dans les conditions actuelles, cette petite occase est plutôt la bienvenue.

I hope I'll be able to give Shantae a try soon. A second hand DSi joins my ARM device family today. That shouldn't mean a lot of changes for Bilou development, but I hope it will mean a longer life to the hobby games I make. The only darker point is that I'm losing a beta tester, but he seemed to be dedicated to sell any way, so ... 900 points to go :P

PoP C64 2011

2011-10-30T22:56:00.008+01:00

Prenez un succès incontournable du jeu vidéo des années '90 (allez, 1989): Prince of Persia. Prenez un briscard de la programmation sur une machine mythique et merveilleuse: MrSid et son C64. Arriva ce qui devait arriver: après la SNES, le PC, l'Amiga, les téléphones Java et l'iPod et la calculatrice HP48, le titre à succès de l'Apple II arrive sur Commodore 64.

Au départ, je pense à une ancienne version qui aurait refait surface, mais non: MrSid refait bel et bien le jeu entre 2008 et 2011 -- chacun son hobby. L'Apple II et le C64 tournent avec le même processeur, le MOS 6502. C'est énorme. Ca signifie qu'en prenant simplement le "binaire" de PoP sur Apple II, une partie du jeu "tournerait" directement sur C64 ... toute la "logique" du jeu, en fait. Les mécanismes graphiques et sonores des deux machines sont totalement différentes, en revanche. Et à relire pour la 3eme fois le peu d'information que je trouve sur le graphisme de l'Apple II, j'aime autant dire que cette différence est importante. La machine de Steve Wozniak travaille essentiellement avec un gros 'framebuffer' (une image bitmap unique, remise à jour à chaque étape du jeu) alors que le C64 a un hardware inspiré des consoles et machine d'arcade de l'époque: caractères reprogrammables et sprites hardware. Le moteur de rendu devra donc être intégralement refait.

Well, if you read English, you can simply head to MrSid's post "Why would anyone want to port Prince of Persia on the C64". I guess he'll explain his reasons and give you crunchy details and videos much better than I could ever do ;)

La tâche à laquelle MrSid s'attelle donc, c'est de reprendre le binaire de la version Apple II, le désassembler et le cartographier. Il s'est évidemment mis en chasse du code source d'origine, qui a été perdu corps et bien ... eh oui, on travaillait sur floppy à l'époque >_<. Ce qui a survécu, en revanche, et que MrSid exploite au maximum, c'est la "documentation" du jeu. Quelques schémas qui expliquent les grandes lignes du moteur graphique, la liste des animations, l'organisation en mémoire des objets, leur position, les animations, et tout ça. Ca fait toute la différence! Au milieu de l'inconnu, il y a maintenant des points de repère qui permettent de comprendre le code parfois curieux de Jordan Mechner. Code-trampoline, liste d'instructions ... Si tout ça vous parle, ne vous en tenez pas à ce que je vous raconte: allez lire le blog dans lequel MrSid raconte en détail sa réalisation étape par étape... vidéos à l'appui.

Au fait, MrSid, c'était aussi le portage de Giana Sister (version C64) et International Karate sur DS. ^_^

(pour le blog Commodore Users Charleroi

Vieux Bouquins

2011-10-29T10:03:00.004+02:00

Selon Helm, il faut que je retravaille mes "vieux bouquins" ... il est peut-être donc temps que je mette en ligne mes images de références trouvées sur flickr, histoire de les avoir plus facilement sous les yeux. (Encore que, en principe, je les avais imprimées :P)

These should be my references for drawing old books in pixel art.

Colour Balance ...

2011-10-25T18:30:00.004+02:00

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

Playing Diamond Hollow

2011-10-24T22:13:00.003+02:00

A nice chippy music, simple graphics that reminds me of (good) DOS sharewares and nice level design, Diamond Hollow could be a dynamic game created with RSD game-maker if it wasn't for the sophisticated, immediately available weapon upgrade system. You collect diamonds in caves and fight blobs, spiders and some undefined creatures. That's fairly classical, but in video game like in cinema, there are some classics that can't be made wrong.

One thing that really puzzles me is the control system. Am I supposed to control the player with keys and space bar with one hand and aim my fire with the mouse ? That's fair enough in level 1 and 2 with relatively stubborn monsters that don't really attack me and the "autofire" power up. There is no timer in the game (i.e. power up dropped by monsters are permanent: you've got as much time to gather them as you want), so I can just stop in a safe position, move the mouse with the touchpad (yeah, laptop here), and then jump around to shoot the monsters. Leaving the "mouse" untouched means I'll always fire towards the same absolute X position (moving left/right won't change my target) and the same relative Y position (jumping makes change my target). Sure, the game designer wanted that feature and freedom very hard, but allow me to be brutally honest: it's useless. 4-directions firing would have been largely enough, and it would likely have involved the player much more by intense action when risk must be taken rather than doing precision adjustment to shoot plain blobs. When controls are awkward, I will just minimize the risks of getting into trouble. too bad. It really had a cute little something.

wooden pixels

2011-10-21T22:10:00.001+02:00

Vous avez remarqué qu'il y avait du bois sur chaque image présentée dans mon post précédent ? Pas un hasard, bien sûr: je cherchais des références pour les étagères du niveau "bibliothèque" ... parce que les "briquettes" du dernier mockup ... bof. Mais où trouver du bois dans un jeu vidéo ? Pas dans la cité des images de Rayman, en tout cas! Tout est en gomme, et tant pis pour ta pomme!

Première pioche: les bâteaux volants de SMB3. Un dégradé assez riche, mais qui reste principalement sur la même teinte (hue=35), sauf pour les extrèmes. Les rondins sont essentiellement un dégradé auquel on rajoute une "texture" en traçant des traîts horizontal de la couleur un cran plus claire dans chaque bande de couleur. Assez réaliste et réussi, mais on est pas du tout à l'échelle qui m'intéresse. Et puis, une étagère n'est pas en rondin, donc les irrégularités ne seront pas identiques.

Etonamment peu de teintes pour le niveau "off da wall" the Coolspot. On pourrait presque transposer directement ces graphismes-là sur NES. Les différents portages de Coolspot (SNES, PC, Amiga) sont très inégaux sur le plan graphique, et je n'ai pas la certitude d'avoir trouvé un screenshot de la version MegaDrive originale (afaik). Saturation surprenament élevée, et des patterns qui font allègrement usage du tramage, ce qui colle plutôt bien avec l'aspect "vieux grenier" souhaité. Une plaie à reproduire, par contre. Sous Master System (la version utilisée sur vgmaps pour en tirer les cartes du jeu), la "planche" d'un étage fait 32 pixels de haut avec un pattern de 32 pixels de large.

Couleurs super-saturées pour Zool -- mais ce n'est pas une surprise: le monde de zool est dans des tonalités systématiquement saturées. Même le fond est parsemé d'objets hétéroclytes qu'on a même pas tenté de rendre visuellement distants en les passant en tons pastels. On est ici à une taille un peu plus petite que celle de Cool Spot avec des "veines" d'un pixel de large, travaillant beaucoup sur l'anti-aliasing (surtout pour le bois plus clair). Un point-clé, c'est la grande régularité de l'espace entre deux veines, de 3 pixels. Sans ça, on a juste des traîts barbouillés dans tous les sens, comme ce que j'ai fait sur la droite :P Pattern de 32x32, de nouveau.

Petit retour à SMB3 ? Il faut dire que les "briques de bois" ont un comportement tellement particulier dans ce jeu (cachant parfois des plumes-tanooki mais nécessitant de les cogner *sur le côté*) que j'ai tendance à croire qu'il y a du bois partout ... en fait, il est plutôt rare ^^"

Ici, pas de "veines" dessinées dans le bois, mais l'impression qu'on voit un morceau de tronc débité dans la longueur, avec les anneaux caractéristiques. L'effet de dégradé obtenu n'est pas ce qu'on a vu de plus esthétique dans le jeu, mais personne n'ira suggérer que ce sont des tablettes de caramel. Pour faire des plates-formes dans les niveaux aquatiques, eh bien, les p'tits gars de chez Nintendo ont simplement répété une "vague" tous les 8 pixels, jusqu'à arriver au bloc "bord droit". Nettement moins crédible (bin oui, c'est supposé être concentrique), mais ça marche quand-même. Par contre, tout ça est (de nouveau) à une échelle qui ne colle pas à celle de Bilou. Rideau.

Et les Rangers du Risque ? eh bien, même technique que pour Zool, mais avec des veines nettement plus courtes et une limite de 3 couleurs par palette (noir, brun clair, et sisi-c'est-pas-du-rouge-c'est-du-brun-foncé). Bien réussi pour l'époque, mais je n'irai pas en faire une référence, ni au niveau des couleurs, ni au niveau des pixels eux-même.

Influences for Bilou ...

2011-10-20T13:10:00.007+02:00

Facile de voir que la school zone de Bilou ressemble à la cité des images de Rayman. Et pourtant, c'est une pure coïncidence: quand mon frère m'a ramené les nouveaux monstres de Pierrick, personne n'avait jamais entendu parlé du curieux bonhomme sans bras à moins d'être dans l'entourage rapproché de Michel Ancel... Ce dont je ne peux malheureusement pas me vanter.

Mais ce n'est pas pour autant dire qu'il n'y avait rien avant, même si à 15 ans, on avait passé le cap de "refaire un Sonic avec Calimero", il y avait forcément des jeux qui nous avaient marqués et qui nous ont donné envie donner vie à des objets genre "Alice au Pays des Merveilles"dans des environnement "zoomés". Coolspot ('93) fait ça un peu tout le temps. L'animation gag et fluide du jeu de David Perry a largement contribué dans mes influences pour les jeux vidéos, c'est clair.

I long for the "school zone" to get more monsters so that people stop saying that I should have mentioned Rayman (PSX) as an influence. No, rayman was still a top secret project (on SNES?) when we started sketching Sqrt and the pendats. But the video game album was already featuring a few dudes that shown us the way of micro-characters-in-macro-areas (just in case our daily dose of Wonderland weren't enough ;). Coolspot's attic is frequently appearing in my mind when I try to get references for the library level of the school zone, for instance. And of course, Zool had an even greater influence, with its objects-brought-to-life monsters.

L'année avant, l'ovni farfelu, c'était sur Amiga, c'était Zool, le ninja trans-dimensionel. Château des Délices -- euh, zone Chuppa Chups, je veux dire -- puis monde de la musique (tiens, tiens!), Jardin Géant, Boîte à Outils et magasin de Jouets.

Oui, ce "tueur de Sonic" à très certainement marqué le terrain d'une manière plutôt décisive, et je me demande même dans quel mesure il ne figure pas également dans les influences de Michel ;)

Ou alors serait-ce les Rangers du Risque (sur NES, dès 1990) ? Avec leurs niveaux à kangourous smasheurs dans une bibliothèque ? Si ce jeu figure parmi mes référence en terme de gameplay coopératif, en revanche, je ne crois pas être allé jusque là, ni même avoir jamais vu quelqu'un y jouer. Il faudra chercher ailleurs.

Oh, and just FYI, yes, I enjoyed Rescue Rangers a lot, especially due to its innovative and fun co-op play, but I'm afraid I never managed to beat the game up to the library level. So, no, this wasn't a reference for me. That's funny to note that Zool's first two levels just match Rayman's Cake and Music levels, by the way ^_^

branches/newcollide

2011-10-18T09:26:00.008+02:00

So I finally started a new SVN branch with the collision engine modification that I sketched in the train. It's not going to be testable anytime soon, I'm afraid. The current collision engine was already abusing some "setContext(...)" calls to set static variables into GobExpression so that you can e.g. shoot things despites the eval() has no such thing in its argument. With the new "attach" and "align" features I want to develop, that becomes a huge mess of things to capture at various places in the GOB -> GOB -> area -> state -> expression call chain that happens at every collision. I bet the best move will be to extract all this context (including some of the things that are currently plain arguments) into a GobCollision structure which would have temporary lifetime (i.e. allocated on the stack) that would be passed around ...

Well, that'd be better unless the compiler is able to keep all the arguments in registers otherwise :P

Je dirais bien "assez causé, implémentons ces fameuses nouvelles collisions". Sauf qu'en fait non. Les petites modif' faites par-ci par-là dans le Boutdlard Express ne compilent pas, et si je fais ce qu'il faut pour qu'elles compilent, ça va être une véritable pagaille dans le code. Genre "la famille araignée en vacances dans une boites de spaghetti géante", voyez? J'ai une petite idée pour rationaliser tout ça sans perdre en souplesse ni (trop?) en performance. Je vous en dis plus après avoir fait le test.

a link to the past ...

2011-10-13T13:07:00.002+02:00

Everytime you explicitly save your SEDS work to a file, SEDS archives the former content under /data/seds/[ABXY]<year><month><day><sno>.spr. That way, you should not accidentally lose some work, and you can keep working forward despite the fact you can only save to 4 slots. If you want to retrieve something from those files, you had so far two options: either take your media card out and copy the file, or switch to runme and beam it out to a PC.

5 ans après, la politique de gestion des fichiers dans SEDS n'a toujours pas changé, et je la trouve toujours aussi pratique. 4 fichiers, "A,B,X,Y" que je choisis en appuyant sur le bouton correspondant de la DS sur l'écran-fichier après le bouton L(oad) ou (sto)R(e). Pour éviter de se tromper au moment de la sauvegarde, R-R réécrit sur le fichier ouvert (les anciennes données étant alors placées dans un fichier .bak). Quand je veux travailler sur quelque-chose de neuf, je sauve explicitement vers un des fichiers [ABXY], ce qui "repousse" l'ancien contenu dans un fichier-archive dans /data/seds.

Ce qui n'était pas pratique, par contre, jusqu'ici, c'était de parcourir le contenu de ces archives à la recherche d'un "travail à continuer". Mais avec les dernières modifications apportées à runMe, ça devrait bientôt être possible.

I had to do that last month when I wanted to revive work on the schoolzone pixel art, but tests with AnimEDS had pushed the schoolzone sprites into the archive. What's ridiculous is that runme can show you a preview of a .spr file that has just been beamed in, but it couldn't show you a preview before you beam out :P I made a few tweaks to runme these last days, fixed a couple of bugs in the SpriteSet.unpack(memory_buffer), too, and added an "offline" button so that you can navigate files with runMe even in the country side, far away from any WiFi base station. I'm not yet satisfied with the resulting usage flow, though. It does the trick, but explaining to anyone *why* it works so would be tedious. That will be for another lunchtime.

Apple Assault fait mouche

2011-10-09T21:43:00.009+02:00

J'étais donc dans le Zurich-Bruxelles le week-end dernier. Presqu'une journée entière, en fait. Après quelques tentatives d'encrage du Bilou's Book abandonnées pour cause de virages un peu plus serrés que prévus, je déplie mon PC pour tenter de mettre en oeuvre les modifications du moteur de collisions dont j'ai parlé ces derniers jours... de mémoire, vu que si la SNCF a équipé son Vauban(?) de prises de courants depuis 2008, je n'ai toujours pas d'abonnement wifi-dans-le-train :P

C'est alors que débarquent Lucius, Harry et Ron qui viennent squatter "ma" banquette. Pendant que Lucius et Ron se chamaillent à coup d'iPhone, Harry tente désespérément de faire son devoir d'arithmancie. Il pose à ses camarades une question du genre "si, tu sais, t'as une droite ou un point et tu dois refaire un point ou une droite ...". Au bout de 2 minutes, je risque "symétrie", histoire d'avoir la paix. C'était bien ça. Ron, assis à côté de moi, semble impressionné, et me demande "c'est quoi mon métier". "Informaticien", que je réponds. "C'est vos e-mails", demande-t-il en voyant la fenêtre Xemacs. "Non", que je réponds, "c'est du code. Du C++. C'est mon moteur de jeu". Il n'a pas immédiatement relevé, mais au bout de 10 minutes de questions, je finis par lui sortir ma DS, lancer la dernière version de Apple Assault et je lui mets la console entre les mains. "Voilà: c'est le jeu que j'ai fait l'an dernier avec mon moteur de jeu. Maintenant j'essaie de l'améliorer pour pouvoir faire d'autres jeux".

Imagine, Ron, Lucius and Harry in regular clothes, coming in your train and sitting next to you while you're coding upgrade to your collision engine. Ron was so curious about my job (since I was able to hint Harry on his math homework), and what is "code" for, what does a "game engine" do, en so on ... I finally picked up my DS in my bag and claimed. "Look, that's the video game I made last year with the code I'm updating now".

It merely took him some gameplay tips to start enjoying the game to the point Lucius couldn't resist to stand up and check what was going on. Both were previously toying with their iPhones, but Ron never complained about Apple Assault to be flat, old-school, odd or boring or whatever. He enjoyed it the same way I enjoyed Bomb Jack at his age... And when he handled me my DS back at his end station, he said "Informatics, that rulez!" -- "Yeah, I replied, but then you need to listen to your math and physics teacher well ;)"

Il lui a fallu quelques petits conseils pour pouvoir passer le premier niveau ("Waaaa, mortel!"), mais ensuite, le voilà lancé, posant ça et là des questions du genre "c'est vous qu'avez fait les pixels?" ou "on peut faire un jeu comme ça tout seul ?". Harry bougonne et continue son devoir, mais Lucius tend de plus en plus l'oeil par-dessus la console et finit par faire le tour pour s'asseoir sur l'accoudoir :) Ron ne me rendra la console qu'au moment de descendre du train, avec pour conclusion "C'est trop cool, informaticien !".
"Ouaip", que je réponds, "mais il faut bien bosser ses maths et sa physique".

quick gameplay note: despite my repeated suggestions that pressing (A) again while bouncing on ennemies would build up punch power faster, neither Ron, nor my colleague (and WP leader) Maugrey seemed to look at using that technique. As a result, they mostly had access to small-punch with limited range and efficience. Shooting a shuriken or doing a "big-punch" almost never occured during their game. When building levels further, bouncing on ennemies to reach a goal should be a refinement, not a basic feature to reach the level's exit.

SpongeBop & Dumblador revisités

2011-10-05T12:30:00.002+02:00

Je n'ai pas eu autant de commentaires que j'espérais sur Pixelation, mais ça m'a quand-même suffisamment motivé pour retravailler l'animation de l'encre dans le train, en revenant de Zurich, peaufiner les bouquins et faire une version un peu décente de mon éponge ainsi qu'un lifting pour Dumblador, le taille-crayon grognon. Par contre, je persiste et signe: ce sera une école "rétro" avec le matos des années septantes (voire antérieur), encriers, tampons, éponges molles et jaunes plutôt que stylo-bille et "brosses pour tableau". C'est ça l'esprit de la school zone depuis '94, et tant pis si certains trouvent que "ça fait bizarre, les nuages jaunes" :P

I remember of Pixelation being more reactive when I was working on the green zone graphics. I guess that's the recent datacenter failure combined with the lack of on-board zoom feature that makes the board itself less attractive to artists. Anyway, having some feedback motivated me enough to keep improving books, ink, spongebop, and even dig for (2006) unpublished pixels of Dumblador and revamp them. Hope you enjoy it. At least, I think I managed to be somehow close to my own design sketches.

L'encre de Rayman ... et de Bilou

2011-09-30T18:02:00.001+02:00

L'encre, c'est noir. Facile. Des vagues pointues plutôt que sinusoïdales. C'est noté. Les "highlights" sont localisés à la surface (logique) et fort étroits. Dernière note: presque pas de teinte dans le highlight. C'est essentiellement du gris, avec une très légère teinte brune (saturation maximale 10%)

Make it black, and make it spiky rather than wavy. Keep the highlight thin, focused at the top, and use almost 'pure' greys for the shading. That's what we can learn from analysing Rayman's ink sea in Picture City. So here's (below) what it produces when I follow those advices. It animates nicely, but maybe a 16 pixels-wide tile was a bit too small 0_o.

Bon, celà dit, je ne dois pas me fier aveuglément au graphisme de Rayman. Quand on lit l'article de Pix'n'Love, on se rend compte que les graphismes étaient essentiellement réalisés avec des techniques classiques de dessin animé, puis "retravaillés" pour le jeu vidéo. Moi, je la joue directement "pixel art" avec moins de couleurs etc. (entre autres parce que je n'ai pas une équipe de 60 personnes avec moi :P)

blocking GOBs

2011-09-29T20:02:00.002+02:00

Vous vous souvenez peut-être d'un commentaire de mon frère CJ comme quoi "il faudrait quand-même à un moment donné qu'on puisse avoir des ennemis à travers lesquels on ne passe pas même si Bilou est invincible... une chose que je n'avais pas vraiment prévu de rendre possible dans le moteur de jeu de "Apple Assault": Bilou ne sait pas traverser Funky Funghi simplement parce que dès qu'il le touche, il est blessé et repoussé en arrière. Mais pour les encriers et les plate-formes mobiles, ça risque de causer bien d'autres soucis.

It may look like Bilou can't walk through Funky Funghi in the released demos so far, but I'm actually cheating. What happens is that every time Bilou touches Funky, he's hurt and slightly bounce backwards. It wouldn't be possible that have an harmless, blocking sprite with the Apple Assault engine ... fairly annoying to implement inkjets in the schoolzone, isn't it ? I't's been a background question for a while now, and many solutions have been dismissed already, but I quite like the latest one: have object-to-object alignment primitives in GobExpressions so that you can say "hero is moved out of inker's area" between "play a 'ding' sound" and "shoot a sparkle"

Du coup, pourquoi ne pas simplement prévoir quelques actions "de base" d'alignement au niveau des expressions gobScript ? Plus besoin de définir des flags "sprite solide" ou "non-solide", "solide uniquement de haut en bas", pas besoin de venir bricoler les contrôleurs de comportement: on prévoit simplement qu'un des personnages impliqués dans une collision puisse donner l'instruction "repousse l'autre hors de ma zone de collision verticalement" ou "centre l'autre sur ma zone de collision horizontalement". Même la création d'un lien "transporteur/transporté" peut s'y retrouver. Chouettos.

Personnally, I like how "clean" this approach is. No need to hack something about the collision classes, no need to hard-code some directions of collision, no need to expose more things like absolute location or area properties to the gobScript. Just "block-x, center-x, attach" instructions that will be interpreted in a context where both areas are known by the engine. Just one little detail shows up when reading back the code of the collision engine: only "passive objects" will be capable of using those new operations, because state transitions for the "active object" in a collision are taken after collision tests for that object. Who had collided is no longer known. "on found [...] (...)" is thus not allowed to use any of the 'extra context' information.

Par contre, en relisant le code, je me rends compte que seul l'objet "passif" dans une collision aura la possibilité d'ajuster sa position ou celle de l'autre objet. Toutes les notes "on found" sont donc en réalité impossibles à moins de changer aussi le coeur du système de gestion des collisions: il faut les ramener à "on hit[]". On garde les plate-formes passives même si c'est elles qui contiennent le code qui aligne les objets.

Conséquence: si je veux qu'à la fois l(a plupart d)es ennemis et les personnages puissent déclencher une réaction avec des plate-formes "passives", il me faudra une classe "Solid Moving OBject" en plus de "HERO" et "EVIL".

That may have some impact on the way we script those objects. Most of the use cases do not cause strong problem, except the "platform that carries both heroes and foes". There, I'd love to make sure that 1) the platform is passive, so that it holds the collision logic 2) I don't end up with O(#foes²) tests in collision tests. It sounds like I'll need a SOLID class in addition to HERO/EVIL, so far...
Small battle plan:
add a "transported" state. (e.g. standing on platform)
enforce coordinates alignment.
make sure you're free to move when transported
handle disappearing platform.

indie monkey in lost temple

2011-09-23T20:02:00.002+02:00

I'm not the author of that game nor affiliated in any way. I'm just a fan. I loved the look of the rendered mockups and the "strategy guides" presenting the obstacles. It inpsired me today to craft the "cave level screens" of "nuts'n'bolts" based on different gems or stones. My brother's gonna love that: he used to memorise (in my brain) the geology pages of his atlas when we were kids. Only bad thing: I can't remember of the game project's name, nor find it back on the Internet anywhere.

~~If you recognize it, just post a link as comment, please. You'll receive a dedicated drawing in return ^_^.~~
Thanks to Furan for identifying "adventure apes" by "scary potato salad"

Un p'tit singe perdu dans un temple ... un projet de jeu de (puzzle?)-platformer plutôt sympa qui m'a inspiré l'utilisation d'un "thème géologique" pour chaque écran dans les grottes du monde de Bilou. Seul hic: impossible de retrouver le projet d'origine pour faire le lien. Le premier à me retrouver le lien vers le jeu d'origine gagne un dessin dédicacé ;)

deep ink pit mockup tout moche

2011-09-22T20:02:00.004+02:00

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.

run, you fools!

2011-09-15T22:27:00.003+02:00

Mario, Sonic, Rayman ... chacun d'eux peut courir, mais l'impact sur le gameplay est chaque fois différent. Voilà un petit dessin-du-dimanche pour refaire le point. L'élément intéressant (pour un platformer) n'est pas tant qu'on va plus vite en courant, mais plutôt la manière dont on va exiger plus de maîtrise de la part du joueur quand il doit affronter "un saut plus compliqué".

It's not that much about going faster, but rather about clearing longer holes with a jump. In most platformers, this is achieved through the RUN mechanics ... but not all. Check out my scribbled notes for details ^_^

Dans SuperMario, il faudra gagner en vitesse, donc essentiellement contrôler l'absence d'obstacles. Le "triple saut" des épisodes du nouveau millénaire poussent cette contrainte encore plus à l'extrème.

Rayman, en comparaison a un bouton de course "binaire". Un seul bloc suffit à faire un saut long. Par contre, le jeu est beaucoup plus pointilleux sur le timing du saut (point-test unique contre deux tests pour Sonic, peut-être ?).

Keen, lui ne court jamais (ou tout le temps, c'est selon), mais l'activation du pogo permet de faire des sauts plus longs (mais ici aussi, il faut faire d'avantage attention au timing et à l'environnement). Fury est un peu un mélange de Keen et Sonic: on court de plus en plus vite, et on saute d'autant plus haut qu'on enchaine les sauts (il suffit de garder le bouton enfoncé).

Animer Bilou

2011-09-14T21:12:00.003+02:00

Petite image d'archive, pour meubler un petit peu pendant que je tripatouille les entrailles de runme. Entre mes notes de philo, je gribouillais déjà en '96 des animations complète de Bilou à réintégrer dans le jeu QuickBasic. A partir de là, je pouvais identifier les positions à dessiner pour le "corps" dans mon Sprite Editor de l'époque, puis définir les coordonnées des 2 mains et des 4 morceaux de pieds à chaque étape. Bien moins agréable qu'avec AnimEDS, hein ?
Côté animation proprement dite, l'influence de Fury of the Furries a été déterminante.

I retrieved last week-end the full set of hand-drawn animations that were used to produce the QBasic version of Bilou platformer game... I'm sure you can feel the "Fury of the Furries" inspiration here. That was later used to plot the various (but restricted) 10x10 sprites for Bilou's body in my custom Sprite Editor, and then to write down the code that set the position of hands and feet ... 6 coordinates pair for every move. Sure it would have been easier if I had the AnimEDS as well by then ^_^

Vu sur Internet ...

2011-09-09T10:14:00.011+02:00

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

Pourquoi l'éditeur d'animations ? ...

2011-09-07T20:06:00.002+02:00

Souvenez-vous: on est en janvier, je viens de faire une release des sources de Apple Assault, je me suis un peu pris la tête avec les responsables de devkitpro et plutôt que d'attaquer un nouveau mini-jeu, je commence le développement d'un éditeur d'"animations à la rayman". Développement qui aura donc duré 9 mois (mais alors, pas intensif pour un sou, hein ;) avant qu'une version un peu utilisable ne voie le jour. "Ma Perché?" me direz-vous.

Eh bien, c'est qu'en janvier, mon frère s'est rendu compte qu'un p'tit bonhomme, ça grandit vite. "Ce serait chouette de refaire mimi pour eux, Pype", dit-il, "et si on veut qu'ils y jouent tant qu'ils trouvent ça rigolo, il va falloir s'y mettre.

Mimi ... "mimi la fourmi", alias "mimi à la campagne" ... un jeu C64 réalisé par 2 québecquois et distribué par Logidisque qui avait fini dans le rayon du GB, puis dans le caddie de mon paternel. Un petit écran bucolique habité par une petite fourmi. A chaque touche enfoncée, une petite musique et une animation ... de quoi apprendre aux charmantes têtes blondes à reconnaître les lettres du clavier en s'amusant. Ma soeur (4-5 ans à l'époque) y a passé un temps certain. Mon frère et moi, on chipait alors le clavier pour enregistrer des "macros" ... une sorte de mini-histoire en enchaînant (N)uit, (R)eve, (J)our, (P)apillon.

"Mimi la fourmi" was a C64 game that defined a part of our family's childhood. Press a key (e.g. 'N' for 'N'ight) and the little ant will do something on screen such as cutting some flowers or bring a cake to a friend, together with some classical theme played through the SID. Between calimero and the discovery of RSD game-maker, there have been projects to port this little jewel to the PC world during my teenage years. Nothing ever got coded, though.

Since my bros' and I are now parents, the idea popped up to revive the game on the DS. Almost everything is in place, except that there are quite many animations for that game ... too much for classical techniques, but not for modular animations. That's why I've spent the last 9 month on a tool that seems so far away from creating one more Bilou game.

Chouettes souvenirs, donc. A peine avais-je maîtrisé les commandes "draw" et "play" du QBasic que j'envisageais déjà un portage sur PC, qui n'a jamais été vraiment commencé. Mimi la fourmi, une coccinelle qui passe sur l'air de "la cuccaracha", une abeille qui apporte du miel, un -- non, deux -- petits vers ... tout ça pourrait en effet être bien sympathique.

Mais il y a beaucoup d'animations différentes dans le jeu C64. A l'époque 8 bit, ce n'était pas un vrai problème. Une image à l'arrêt, une image assise, une debout ... deux pour la marche dans chaque sens. En monochrome 24x24, les graphismes sont vite règlés. Mais en 256 couleurs sur la DS, à 60 images secondes, je me vois mal faire toutes les images à la base. Or, c'est le genre de petits bonshommes qui passent encore bien en animation modulaire -- qui était prévue pour Bilou depuis le départ, mais pas encore disponible. Alors oui, je me suis mis à créer l'outil nécessaire pour faire tout ça.

Et toi, Piet, t'es prêt avec tes MODs ? T'as téléchargé AnimEDS pour te mettre à l'animation ?

AnimEDS: l'écran "fichier"

2011-09-06T21:40:00.004+02:00

Le menu "fichier" a pas mal été révisé avec la version 0.3 d'AnimEDS. Ca vaut peut-être la peine de passer les nouvelles fonctionnalités en revue:
Pour enregistrer une animation et en commencer une autre

pressez (START) pour passer en mode "fichier"
utilisez le DPAD pour choisir un slot, puis pressez (Y) pour y sauver votre animation
choisissez une autre animation et presssez (A) pour la prévisualiser
pressez à nouveau (START) pour revenir au mode d'édition

N.B.: (A) sauve l'animation en cours d'édition dans son slot d'origine. Pour abandonner les dernières modification et charger une autre animation, pressez (B).

Pressez (R)-(R) en mode 'fichier' pour sauver de façon permanente votre fichier sur la carte-mémoire. Alternativement, (R)-(A), (R)-(B), (R)-(X) et (R)-(Y) permettent d'enregistrer sur un des fichiers de travail précis.

Define your own character
That's a major new feature added with AnimEDS 0.3: you're no longer tied to a pre-coded character structure. You can come with a fresh .spr file you've drawn with SEDS and proceed as follows:
use '-' and '+' buttons to define how many component your character will have
use '>>' and '<<' buttons to navigate to the proper sprite sheet, touch the picture you want to use as "thumbnail" for a component, and finally L-touch the limb in the limbs table on the left.
repeat this process until all the limbs have a picture defined.
click 'OK' to start a fresh animation with that skeletton, or L-click "OK" to resume edition of the current animation with the updated skeletton.
N.B.: the order in the limbs table also define priority among limb sprites.

modifier la structure du personnage:
L'éditeur prépare un personnage à 2 mains, 2 pieds, 1 corps et 1 tête. Chaque "composant" est associé à une palette de sprites (la "sprite sheet" sur la droite) et ne peut utiliser que des sprites appartenant à cette palette. En revanche, plusieurs composants peuvent utiliser la même palette.

utilisez les boutons '-' et '+' pour définir le nombre de composants dans votre nouveau personnage.
pour chaque composant, déplacez-vous vers la bonne palette à l'aide de '<<' et '>>', puis touchez du stylet le sprite qui servira de "représentant" pour ce composant et L-touchez le composant en question dans la table de gauche.
répétez l'opération avec les composants suivants jusqu'à ce que le personnage soit entièrement défini
cliquez sur 'OK' pour commencer une nouvelle animation avec cette structure, ou cliquez en maintenant 'L' enfoncé pour retourner à l'animation en cours en appliquant les modifications de structure.

N.B.: l'ordre d'apparition dans la table de gauche défini aussi la priorité relative des composants (p.ex. 1 main et 1 pied par-devant le corps, 1 main et 1 pied par-derrière, et les yeux par-dessus tout).
Truc: une fois la structure définie, positionnez les différents composants pour une image fixe que vous enregistrez immédiatement (START-Y) avant de commencer à animer. Enregistrer votre première animation sur un slot différent de façon à pouvoir facilement commencer une 2eme puis une 3eme animation en repartant d'une structure déjà dégrossie.

Manage your animations
Once in the "file" area, you can move the cursor on the top screen with your DPAD to select an animation slot. In v0.3, you're given 48 slots where you can record animations. By default, your "ongoing" work is nowhere yet in those slots, but the program remembers where it came from. So,
(A) will save current work where it came from, and load the selected slot
(B) will drop current work, and load the selected slot
(Y) will overwrite the selected slot with your current work.
(X) should clear the selected slot, and keep your current work untouched (experimental feature).
When saving your work to a file (with START-R-[ABYX]), the program will automatically write back your current work into the slot it came from.

AnimEDS version 0.3

2011-09-06T13:14:00.006+02:00

timeline management reviewed, bug fixed, next/previous location of the selected component are depicted on screen ... well, I think we've got everything we could like for a 0.3 release of my animation editor. Enjoy...

start: toggle file/edition screens
in file mode:
DPAD selects the animation slot to use
A : write back current work and load select slot
B : drop current work and load selected slot
X : (delete selected slot ?)
Y : overwrite selected slot with current work
L : load file
R: save to file
edition, with a selected limb: DPAD = move limb precisely, L=deselect
edition, no limb selected:
left = move frame earlier in time, right = move frame later in time
up = edit previous frame, down = edit next frame
Y = copy the current frame
X = delete the current frame
To get started: unpack the zip file, place AnimEditor.nds wherever you want, place the shipped "spritey.spr" at the root of your media card -- if there was any other file there, backup it first. Then boot your DS, launch the editor and press [START]-L-Y to load the file, then [START] again and use DPAD+A to preview animations.

Bien. Bugs résolus, manipulation du temps parachevée, visualisation trans-temporelle des composants d'un personnage ... Je pense que tout y est. On peut faire la release 0.3 de AnimEDS. Amusez-vous bien. Les instructions sont traduites en français sur dev-fr.

See this post for additional user instructions

OAM Alpha

2011-09-03T14:40:00.008+02:00

Résumons un peu:
- si je veux un niveau de transparence variable pour un sprite, le seul moyen est d'utiliser un sprite en mode bitmap/direct color ((Attr 0, Bit10-11) to a value of 3) et d'utiliser le champ prévu pour le no de palette pour "personnaliser" le niveau de transparence.
- pour les sprites à palette, ce sont les mêmes registres "BLDCNT" et "BLDALPHA" qui régulent la transparence des sprites depuis le GBA.

REG_BLDCNT_SUB = BLEND_DST_BG0|BLEND_DST_BG3| BLEND_SRC_BG2|BLEND_SRC_SPRITE|BLEND_ALPHA; permet donc d'afficher des sprites et le calque 2 transparents par-dessus BG0 et BG3 (pour autant que ces deux calques soient effectivement derrière eux, sans autre chose pour faire obstruction).

Mais comment faire pour que seuls certains sprites soient transparents?

OBJs that are defined as 'Semi-Transparent' in OAM memory are always selected as 1st Target (regardless of BLDCNT Bit 4), and are always using Alpha Blending mode (regardless of BLDCNT Bit 6-7).

nous apprend-on sur gbatek.

C'est donc le rôle de ATTR0_TYPE_BLENDED (à utiliser à la place de ATTR0_TYPE_NORMAL) qui sélectionne le sprite en question comme "source d'alpha-blending" indépendamment de la valeur de BLEND_SRC_SPRITE dans le registre BLDCNT.

Cool. Je suis prêt à attaquer l'implémentation de "l'onion skin" dans AnimEDS ^_^

I need 'onion skin' preview of the previous/next frame in AnimEDS, which suppose some sort of alpha-blending on the frame editor, which is made of sprites. I've got a DS alpha-blending tutorial around for some years now, but my last attempt to have that working in the level editor was rather disappointing. So here's a recap:

You can make all the sprites have some alpha-blending by turning on BLEND_SRC_SPRITE in REG_BLDCNT_SUB ... not that useful. You're more likely to want a BG translucent that let sprites show through as well. That's with REG_BLDCNT_SUB|=BLEND_DST_SPRITE
You can selectively turn on blending of some sprites by using ATTR0_TYPE_BLENDED. That's what I need in my editors, but the blending level will be the same for all sprites (and layers).c

bitmap-type sprites use direct colors (bypassing the palettes), so the ATTR2_PALETTE() field of GBA sprites is useless and has been recycled into ATTR2_ALPHA. I guess you still depend on REG_BLDCNT to tell *what* you're transparent against... Oh, and don't forget to set REG_BLDALPHA to some value, of course.

Back in time ...

2011-08-29T13:37:00.002+02:00

Well, I still have to work on a few aspects to make AnimEDS more comfortable to work with before I start using those new animation in the game engine. But at last, the "core modification" of how the timeline is managed is fixed. Pauses and loops can be visualised and manipulated. Do you like their "musical" style ?

vendredi soir} Bion, j'ai donc réussi à faire une version minimale de l'augmentation de délai. Encore un peu trop minimale, puisque je suis obligé de sauver l'animation puis de la recharger pour que le délai fasse effet ... bizarre, bizarre ...
samedi} Ou alors il suffirait de "valider" l'animation ? ...
dimanche} Allez, on re-génère la version compilée de l'animation lorsqu'on clique sur la preview, et on en parle plus. Mais pourquoi diable mes petits contrôles de boucle n'apparaissent-il pas ?
lundi midi} ça y est. Les contrôles apparaissent. La ligne du temps reste ordonnée quand j'y déplace un cellulos. On va pouvoir passer au prochain point sur la todo list ... la transparence ~~ou les zones de collisions~~ ?

n33333d c000000de

2011-08-26T17:42:00.002+02:00

Pfff. Ponçage d'escalier, rangement de maison, upgrade de PC, visites médicales, rédaction d'énoncé, lecture de TFE, surveillance d'examen, rédaction d'avis et correction d'examens ... tout ça c'est bien beau ... mais là, moi, je veux coooodeeeeer.

Scrolling issues: done.

2011-08-19T11:02:00.007+02:00

Oh, btw, horizontal scrolling issues are now fixed -- it was about time!. Hope you enjoy it.

Juste pour vous tenir au courant: le scrolling horizontal marche maintenant aussi bien que le vertical. Ca ne faisait finalement que presqu'1 an qu'on attendait ça ... ou depuis le mois de février 2010 pour Morukutsu :P

Et il m'en reste encore pas mal, des vieux 'todo' comme ça ... la plupart visant l'éditeur de niveau (qui n'a toujours pas eu droit à une release officielle), d'autres sur des extensions des capacités du moteur de jeu ou de l'éditeur de sprite. Affaire à suivre.

Revising animation delays

2011-08-18T13:19:00.007+02:00

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.

2011-08-16T11:43:00.008+02:00

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 perspective~~terminé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

Stacking Troubles

2011-08-12T10:02:00.005+02:00

Fix a bug, another appear. Does that sound any familiar ? I had to reorganise the "window" that constitute my animation editor, so that I would no longer miss some data while saving my work. Those "windows" are widgets container that you can stack over each other. When the GUI engine needs to deliver an event, it starts trying to give it to the top-level window and digs deeper until one of the window has one widget that can process e.g. the click.

The reorganisation consisted of introducing the ThumbWindow (see snapshot) below the FileWindow, so that one can control the slot where an animation should be saved while he's building new skelettons and making "save animation to slot" a natural operation when you're on the road to save to a file.

at first, it seemed to work fine, unless I realised that a single click on any of the limbs or sprite tables disabled all the actions on the "bottom screen" widget. I had overlooked the fact that two of my widgets on the bottom screen (the tables) were actually not part of the "FileWindow", but something laying on the main (application-wide) MetaWindow (in red), so that they could be shared by both file storage and animation edition activities.
Unfortunately, because MetaWindow is the lowest layer of the software, it were obscured by the screen-wide "SpriteTable" that contains all the thumbs. No way to go through. Of course, this is ridiculous: those thumbs are not on the touch screen so they shouldn't be receiving any stylus-based event ... but well, they are. For some odd (historical?-) reason, the GuiEngine ignores facts as trivial as "the top window is a DownWindow, so any UpWindow in the stack shouldn't receive GUI_CLICKED". Hopefully, it features an "active" flag that windows can set and clear to indicate their will to receive/ignore such events. It's to the application author (me ^^") to ensure Window::release() and Window::restore() update this flag accordingly to the desired effect. ... which is now done.

Now, if you don't mind, I have a staircase to polish.

(-1)/8 = guru meditation error.

2011-08-07T08:11:00.002+02:00

Et chroot! J'avais donc commencé à dessiner la tête et le corps d'un Badman avec la version "gamma" de mon sprite editor. J'en étais à une animation (plutôt réussie, à mon sens) de sa cape, l'idée étant d'en faire un perso annimable avec AnimEDS. Plutôt sympa pour commencer mes 2 semaines de congés pendant que ma fée est toujours dans le tome 1 de la Trilogie des Périls (Eddings). Je veux ajuster un poil la vitesse de mon animation et là, bardaf!

GURU MEDITATION ERROR

quelque part, un widget n'a pas été prévu pour recevoir des coordonnées négatives... Il ne devrait en toute logique pas y avoir de coordonnées négatives sur la DS, d'ailleurs. Nulle part. Mais là, pas de chance, ça m'a tout planté avant que je n'aie eu le temps de sauver mes p'tits dessins.
Enfin, j'ai trouvé la cause de l'erreur. ~~Je vais patcher ça fissa.~~ Patché.

Hey there. If you happen to be using the 'latest beta' of my Sprite Editor (that is, SEDSGAMA.nds since I've switched to dkp-r32), be warned: there's a nasty bug in the "animation preview" part that may make you lose your work. I figured out what the problem is and ~~will update that version soon~~.

Edit: fixed: if you are using sedsgama, launch it near your favourite WiFi access point and press [START] then [SELECT] to download and use the latest version (N.B.: the updated sedsgama.nds will always be downloaded at the root of your media card.

now to the horizontal scrolling ...

2011-08-03T13:29:00.004+02:00

Hello, there. If you missed the english translation on my former post, Sonic Camera Management, it's now done. The new scrolling is implemented and works fairly well for the vertical direction. Unfortunately, it doesn't work as well for horizontal scrolling.

The reason is that Bilou is not moving at the speed of 1px/frame but rather 2px every 2 frames, to match the animation speed. Former platformers would typically have running characters instead, since they are more flexible. When running, it's easier to make it so that (animation) frames where a feet is in contact with the ground only last for 1 (screen) frame. Well. Anyway. The result is that right now, the horizontal scrolling is not smooth anymore, but rather "pushed a bit" at every step, then it sits back, then pushed again. Ugly. I need a mixture of the two techniques, which means a bit more code hacking.

Youpie. J'ai donc un chouette scrolling vertical bien plus professionnel. Hélas, trois fois hélas, le scrolling horizontal en a pris pour son grade. Que je m'explique. Bilou se déplace de 2 pixels tous les 1/30eme de secondes alors que le jeu tourne à 60Hz. Il reste donc 2 "coups" de jeu au même endroit bien qu'ayant une vitesse moyenne de 60px/seconde. Le hic, c'est que si j'applique la politique "le personnage pousse l'écran en quittant la zone neutre du scrolling", eh bien, mon scrolling ne bouge plus qu'à 30Hz, 2 pixels à la fois. Et ça, c'est assez moche et nauzéeux. Bref, il faut que je passe à une approche hybride qui combine le nouveau scrolling vertical et l'ancien scrolling horizontal ... soit encore un peu plus de bricolage sur iCamera :P

... and well ... I will need to build a place where I can test things with the full-quality pixel art ... not restricted to that "open-source 8-bit" color reduction thingy :P

Sonic Camera Management

2011-07-31T14:10:00.009+02:00

Le suivi de Sonic par la caméra fonctionne donc sur le principe d'une "zone" de focus dans laquelle le centre de Sonic est confiné. Selon qu'il est au sol ou non, la taille de la zone change, mais surtout, dès qu'il en sort, la caméra se déplace d'autant qu'il faut pour y ramener Sonic (avec tout de même une vitesse limite qui permet parfois à Sonic de "larguer" la caméra... et le joueur).

La grande différence avec le code dans Bilou, c'est que jusqu'ici, quand Bilou sortait de la zone de la caméra, j'accélérais le déplacement de la camera, pour ne le décélérer que si Bilou débordait à nouveau de l'autre côté, ce qui amenait des "oscillations" particulièrement gènantes en cas de saut, car l'écran allait continuer à monter de plus en plus vite alors que Bilou commençait déjà à redescendre.

Voyons un peu si ça colle avec mes "désidératas".

A state-dependent "allowed onscreen window" and a speed limit. That's all you need to get sonic-perfect scrolling. That is, the area of the screen where your character is allowed to appear vary depends on whether you're on the ground or on-airborn. I cross-checked with my requirement list for an ideal scrolling, and everything is there (further translation to come soon).

Centré au sol et sur la chute
Presqu'automatique si la zone de tracking est "applatie" à une seule coordonnée lorsque le personnage est au sol. La caméra enchaînera "presqu'immédiatement" pour suivre la chute si le bas de la zone autorisée pendant une chute est très proche de cette position de référence au sol.
My first requirement is that the camera tracks precisely Bilou (vertically) when he's walking so that climbing slopes happens smoothly, but that it starts scrolling down quickly when a fall starts. This achieved by a very narrow Y windown for "on-ground" state, and keeping bottom limits close to each other when falling.

garder un oeil sur ce que l'on évite en sautant
Ce sera le moyen n° 1 de se sortir d'une situation délicate dans un "platformer": sauter par-dessus. Ce mouvement doit pouvoir se faire sans déconcentrer le joueur. On doit pouvoir passer de plate-forme en plate-forme (alignées horizontalement) au-dessus d'une mare de lave sans attraper le tournis. Simple aussi : il faut qu'un saut tienne en entier dans la hauteur de la "zone de non-scrolling" à partir de la position de repos (au sol). Ce n'est qu'en enchaînant les sauts que l'on parvient en haut de l'écran (et donc que l'on active le scrolling), mais dès qu'on retombe d'un de ces sauts, le scrolling cesse de monter jusqu'au saut suivant (objectif #5).
Jumping is the #1 action in a platformer like Bilou (that is, where the hero has no weapon). It must be possible to hop from one platform to the next one without having the scrolling "bounce over and over" as well (which would give the player nausea). That's achieved with a fairly high "top limit" when the player is "on air". Yet if the player is "climbing up", he'll be kept on-screen. always.

Recentrer sans à-coups
De nouveau, ça tient au fait que le scrolling va ajuster la position de la caméra à la position du héros mais avec une vitesse limitée. Quand Bilou arrive au sol, on "rétrécit" à une ligne la zone de tolérance verticale de la caméra. Celle-ci va donc recentrer Bilou, mais en donnant une vitesse verticale maximale relativement basse (de 6px/fr pour Sonic alors que la limite horizontale est de 16px/fr), ce recentrage semble plus naturel.
Now, that's okay to have the scrolling "keeping an eye on the danger from below", but when the action "moves on" on the new platform, it's annoying to press UP or DOWN just to move yourself back in the center of the screen. This can be safely achieved by a narrow "on-ground" Y window, but a slow speed limit on the camera (in my case, "slow" will be 1px/frame).

Chouette. Tout y est. Plus qu'à coder tout ça. GravityController ou WalkingController auront donc la responsabilité de définir la "fenêtre autorisée" et la vitesse maximale, la caméra s'occupe du reste. Andiamo!

DSertyuiop

2011-07-26T21:46:00.005+02:00

Parce que je vais re-travailler AnimEDS pour éviter les pertes de données, et que pour ça, je dois utiliser plus largement ABXY et un peu moins L et R, voilà un petit pense-bête de leur emplacement sur desmume-cli... quand on a un clavier AZERTY.

I'd really be happy if people using QWERTY keyboard around the world and developing e.g. games or emulators could take note that other keyboards also exists. Playing Doukutsu, Frogatto or Iconoclasts with W and Z swapped or Q and A swapped is a pain. It's obvious desmume-cli was also targetted at QWERTY given that if I swap things, I fall back to a "logical" layout with A nexto B, X nexto Y and L nexto R. But I have an AZERTY keyboard, hence the cheat sheet.

Sonic Physics Guide

2011-07-26T13:07:00.005+02:00

ça faisait un moment que je n'étais plus tombé sur de la lecture chouette comme celle-là. "pentes & blocs à pousser", "collisions", "gestion de la camera", etc. Ca va me faire de la lecture ... Attendez-vous à ce que je vous en dise d'avantage dans les prochains jours.

A neat pick: the Sonic physics Guide starring handling of slopes, curves, camera movement ... knowledge likely generated from years of hacking the good'old Sonic 1 and Sonic 2 roms (for SEGA Genesis). Expect some more detailed posts when I'll be done with my readings.

Entering the Shadowlands ...

2011-07-23T13:37:00.001+02:00

Episode 4 of Commander Keen is not far from fascinating me. That's likely the game I played the most (excluding beta-tests of PPP Team productions), and likely the game I'd love the most to replay once again. Of course, I'd love that some people would once say that about Bilou adventures as well, and somehow I hope I can learn something from CK4 that would help me reaching that goal.

Si je reprends la carte de Commander Keen 4 et que j'y reporte les différents éléments, on se rend finalement compte qu'il n'y a que 2 niveaux "gratuits" (c.à.d. qui n'apportent rien au niveau de la quête). Autre élément intéressant, dès les 2 premiers niveaux passés, la quasi-totalité du reste du jeu devient immédiatement accessible. Et ces deux premiers niveaux peuvent être franchis d'une traite par le joueur habitué tout en servant d'introduction à la majorité des mécanismes du jeu pour les autres. Une chouette manière d'éviter les "tutoriels".

I think one interesting aspect of CK4 is its overworld. It's mostly a select-your-level menu, and your goal should be to focus on those levels where a Guardian of Wisdom is being held captive. Of course, you don't initially know where they are, so there's some exploration dimension. The overworld is large enough so that you'll rarely see more than 3 levels on screen, but small enough so that you can travel it end-to-end in something a dozen of seconds.
During some spare time, I lost some time plotting which levels contain what "quest items". Guardians to be saved (red wizzrobes), hints from Floating Princess Lindsey that ultimately guide you to the Mighty Foot of Travel which can take you to the Pyramid of the Forbidden -- the otherwise unaccessible level. The major item is the swimming suit, hidden in Miragia, the disappearing desert city, which unlocks access to the three islands. Only the Isle of Tar and Sand Yego are "free fun levels" where you've nothing to earn (quest-speaking), not even a lot of lives or ammunition. They're rather an extra challenge, with fun-but-dangerous elements.

Beside this "swim lock", there's two gate levels (villages) at the start of the game, that can imho be seen as the frontier between basic skill acquisition and real danger. Both can be zoomed-through by the experienced player (just move to the left, hop over some monsters or spikes and you're done). It's interesting to see how the novice player is even -guided- through the sandbox area either by a friendly slope or an open door vs. a set of spikes.

For the novice players, they're a great introduction to the basic mechanics of the games, in a free-exploration fashion. Poles, doors, shots, switches ... everything is there, except key gems. It's interesting to see that a sandbox works as well as a tutorial to that regard. Of course, Commander Keen does not learn new moves during the game (vs. Rayman) and his move set is nuanced (ultra-pogo jump or rope-hop-while-blasting-downwards being examples) rather than complex (vs. Yoshi's Island or Super Princess Peach -- complexity arising from the number of possible actions and negative rewards from doing the wrong action at the wrong time).

Tout qui a joué à un Keen sait qu'un niveau ne peut être visité qu'une seule fois par partie. Sortir d'un niveau sans avoir trouvé le secret qu'il contient, c'est perdre définitivement ce secret jusqu'à ce qu'on recommence le jeu. Evidemment, pour éviter de bloquer le joueur, les mages seront le seul moyen de sortir d'un niveau quand ils s'y trouvent. Ce ne sont donc que les indices de Lindsey et le méga-pied-transporteur de la pyramide de la lune qui pourraient être loupés. Mais le résultat, c'est qu'on aura d'avantage tendance à explorer les moindres recoins du jeu, là où, dans Super Mario 3-*, j'ai davantage tendance à filer vers la sortie dès que les choses se compliquent, entre-autres parce que je sais que je pourrait refaire ce niveau-là plus tard (avec un meilleur power-up ou un peu plus de vies ...). Pourtant c'est bien Keen 4 le "platformer" auquel j'ai le plus joué et celui auquel je serais le plus succeptible de refaire une partie prochainement ^_^

Through the Commander Keen series, levels can be completed only once in a game: you never re-enter a completed level. That means if you complete a level holding a secret without finding it, you won't have the chance to get that secret before you replay the whole game. Imho, this is a key component that puts the player in an explorative mood, while you'll rather play a SuperMario game trying to zoom to the exit as soon as you don't feel easy in the level. The overworld reinforce that explorative mood by being itself open (once you've complete the two gates level at the start, 11/14 remaining levels become immediately accessible).

The overworld of the next opus -- the armaggedon machine -- is much stricter, with virtually every level being a gate to something else. There's very little room for exploration, just sufficient alternate ordering between the tunnels/balls pair to allow the player who faces a challenge beyond his skills at one place to try something else somewhere else. I spot that the two "mission-less" levels of Commander Keen 2 are also the ones where important plot/gameplay hints are unveiled. I'll investigate that further on another time.

Futurs pixel-artistes: ne vous découragez pas

2011-07-22T21:12:00.007+02:00

Ca me fait toujours sourire quand on me dit que je "dessine bien". J'aime ça, mais faites un tour sur pixelation ou deviant-art, et vous verrez que "dessiner bien", c'est autre chose. Voyons un peu ce que ça donnait en '96

Une vieille (~1997) tentative d'amélioration du graphisme de Bilou. Je venais donc de finir mon "modplayer" 6 pistes en assembleur, j'avais racheté à Pascal son scanner Logitech et je m'attaquais à convertir le nouveau look de la "green zone" en pixels "prêts à l'emploi". Mes nouvelles connaissances sur le mode X aurait dû fournir le dernier élément pour faire de Bilou un jeu MS-DOS capable de rivaliser (hum hum ^^") avec Rayman "himself".

Sauf que n'ayant pas une équipe de 100 personnes avec moi, j'avais encore beaucoup à faire.

Here's an old file dating back from '97 where I saved the steps to convert the output of a scaled-down scan into pixels "ready for integration in a game". As you can see guys, don't feel disappointed if your pixel art is not yet on par with your favourite artist. Mine wasn't either (and still isn't, by a large extent). I'm quite glad I had already learnt that one should not use black artlines at pixel-art scale. A dark color is much better. I hadn't learnt yet that hue shift is the key to nice colours, and I was using "plain value ramps" (where you build linear gradients from a saturated color towards white and black, making everything just look like plastic). And of course, I was overusing automated gradients. That may have saved me from pillow-shading, but it makes the petal looks like spheres rather than having the curve they deserve.

Il y a pas mal d'erreurs de débutants dans ces graphismes. Sur-utilisation des dégradés automatiques de Deluxe Paint qui rajoute une texture granuleuse à tout (que ce soit le bienvenu ou non) et aucun "hue shift" : chaque dégradé part d'une couleur et en diminue linéairement les composantes RVB vers le noir. Point. Pour le jaune et le vert, l'effet est particulièrement raté.
En revanche, déjà là, j'avais appris à fuir comme la peste les "art lines en noir", quitte à refaire entièrement le contour. à la main. Il faut dire que devoir supporter "Skunny the Wild West" m'a ouvert les yeux sur l'horreur que ça donne au final. Et j'ai évité le "pillow shading". C'est toujours ça de pris.

update on BG colors.

2011-07-19T17:36:00.008+02:00

So that's the tileset as you know it so far. Used in "greenwoods demo" and "Apple Assault". It took me a few more missed attempts while trying to blindly copy Eyecraft's colours but I finally got it working... And what made it work was to build up a mockup first (the small image nearby) with BG, FG and character tiles alltogether in such a way that contrast issues became obvious. Once in that setup, with a 32x32 area to focus on where all the important things were there, I could bring the BG colours down, almost to grey, although keeping the blues with a higher value (blues and purple = dark, cold shadows. That's how our bluesky world and cone-rod eyes work ^_^)
Ingrédients: un tileset pas bien coloré, un sprite de référence, un éditeur capable de cloner des couleurs et une pinte de bonne humeur

Créer une nouvelle Sprite Page et y copier l'intégralité des tiles à recolorer
Copier également les tiles qui doivent avoir un bon contraste et le sprite de référence (personnage principal du jeu).
Superposer l'arrière-plan et l'avant-plan en utilisant sur-chargeant avec (B) en mode curseur plutôt qu'avec (A). Construire un mini-mockup avec les tiles ainsi obtenus.
Sélectionner un des tiles d'arrière-plan, cliquer sur "SCAN"
Clicker sur une zone de la palette encore vierge pour définir la destination des couleurs clonées, puis L-cliquer sur le bouton [+] du sélecteur de couleur (QuickPal). Clicker sur "SYNC" pour valider les nouvelles couleurs.
Passer la grille en 32x32 et charger (R-déplacer le curseur-A) la zone entourant le personnage.
Basculer en mode "édition de palette" (SELECT)
Ramener les couleurs clonées vers du gris. Vérifier sur la zone de preview en gris que le contraste est suffisant.
Clicker sur "okay" pour prévisualiser les modifications sur l'ensemble de la page, puis validez en cliquant sur "sure". Retourner à la grille en pressant à nouveau SELECT
Si nécessaire, pressez "START" et utilisez les boutons "<<" et ">>" pour faire apparaître en vis-à-vis la page avant et après modification. Clicker sur un tile "d'avant" puis L-clicker sur un emplacement "d'après" pour effectuer le transport.

See that horizontal area between [+] and [-] under your spriting grid ? This is the QuickPal widget. when you click [SCAN], all the colours present on the grid are copied there. "cloning" the colors consist of copying those colours at an alternate location in the palette. You first pick that target location by touching the palette widget, then launch the cloning by clicking [+] while holding L shoulder button of your console. All the tiles on your working sheet (on screen) will then use the new colours. All the remaining tiles are unchanged, included the backup copy of your working sheet, meaning that you can reimport some old tiles if you need to do so.

PS: ce blog comprend maintenant exactement 600 posts (dont 55 brouillons :P)

palette experiments

2011-07-17T21:13:00.008+02:00

I owe EyeCraft quite a lot for his edit on my former "level 2", although the Apple Assault milestone did not allowed me to improve my own art to match this level. A first thing I wanted to experiment with -- even back then in 2009 -- was to alter the tint on the background dirt tiles.

EyeCraft m'avait proposé une révision assez épatante de ma petite forêt il y a déjà presque 2 ans. Comme je m'étais lancé dans "Apple Assault", j'avais plus ou moins laissé tombé ce genre de mises à jour pour me concentrer sur le moteur de jeu ... d'autant que de toutes façons, il y avait une "impasse technique" au niveau de l'éditeur de sprites.

Today's attempt was to allow the sprite editor to clone a set of colours so that tweaks done on the clones would not affect the original colours, as there are some shades of brown shared by the background and foreground dirt tiles. It's not yet perfect (it should only upgrade those colours present on the currently edited page), but it allows me to do some tweaking attempt... which turns out to be harder than I expected due to the "granularity" I have on colours. There's a large jump between "pure grey" and the closest "very desaturated hue" I can have nearby ... Having the desired contrast and brightness will need more trials

On voit déjà sur le niveau retouché par EyeCraft qu'au moins une des teintes du fond (terre) est aussi présente dans les "murs" de terre (et dans les morceaux de bois, au passage). Si je veux pouvoir changer la teinte du fond pour la rendre "plus froide" et avoir un meilleur contraste entre les deux, il me faut pouvoir "cloner" des couleurs sur la palette. Ca au moins, c'est chose faite, après plusieurs tentatives plus ou moins foireuses (modifications des pixels de tous les blocs pour utiliser les couleurs clonées ... ce qui rend les couleurs initiales inutiles ^^"). Il me reste à trouver les "bonnes" couleurs pour ce fond, ce qui, compte tenu des restrictions à 5 bit par canal (R/G/B), ne s'annonce pas sans difficulté.

Implémenter les plate-formes.

2011-07-16T22:42:00.009+02:00

Aah. De vraies vacances, ça fait du bien, même si ce n'est que quelques jours... qui se terminaient par un peu de baby-sitting à un mariage cet après-midi. L'occasion de refaire un peu le point sur les problème des plate-formes mobiles. Le point essentiel, c'est que -- tout comme le transport d'objets par Bilou -- ces plate-formes dépendent de la possibilité de lier un gob à un autre temporairement. Un micro-contrôleur "follow", donc, qui déplace p.ex. l'appleman à l'identique de Bilou.

At last some day off ... really off. Not even some Bilou thinking until this afternoon "_". And I had no documentation or current code state with me when doing so, which somehow explained why I focused on a fairly remote problem such as moving platforms. The last thoughts came to the conclusion that being carried would involve a dedicated "follow" micro-controller where a Gob is attached to another.

Be coherent
Comment s'assurer que la plate-forme aura déjà fait son déplacement au moment de déplacer ce qui s'est posé dessus ? Sans ça, on risque d'avoir des effets de "décalage" chaque fois que la plate-forme modifie sa vitesse, comme ceux qu'on peut observer dans Zool.

To make that work, however, it is mandatory that the carrying object has moved before the carried object's movement is evaluated. Otherwise, the player will experience zool-like glitches everytime the absolute speed of the carrier is altered. The FollowController must thus be able to detect whether there is an not-yet-processed carrier situation and execute anticipatively the "animation" of that carrier. That will require some more book-keeping at the core of Engine::animate(), but I think it'd be more flexible than pre-encoded priority levels.

Pour y parvenir, le mieux sera de faire en sorte que FollowController::think() puisse détecter si son objet-cible a déjà été exécuté ou non. On joue là au plus profond du moteur de jeu, qui appelle Animator::play() sur chaque objet qui s'est enregistré via reganim(). J'ai déjà une liste "pending" séparée de "todo", il me reste à noter au niveau de Animator lui-même où on en est. Après ça, il suffira de se faire un petit if (target.state==QUEUED) target.play(). L'objet-transporté voit alors son exécution interrompue le temps que l'objet-transporteur soit mis à jour.

Thou shall not follow the NULL pointer
Avec ce mécanisme, je vais introduire pour la toute première fois une référénce directe entre deux personnages du jeu. Jusque là, je passais systématiquement par le tableau GameScript::gob[] ou je me limitais à une interaction éphémère lors d'une collision. Si je ne fais rien de spécial, une plate-forme détruite pourrait amener les objets transportés dans un état incohérent, voire provoquer de sérieux problèmes au gestionnaire de mémoire ou planter sauvagement le jeu.

The second challenge I addressed is to ensure that we can handle the disappearing of the carrier transparently for the carried object(s). We can do that in different ways, some including list of cross-references, etc. but it looks like the best way around could be to delay actual Animator::DELETE requests by one frame so that the former carrier can be caught in DISCARDED state by FollowController::think() method that would drop then the reference.

Je pourrais exiger du "programmeur gobscript" qu'il règle ça lui-même en prévoyant des états-tampons ou des collisions de désolidarisation, mais ça signifierait qu'une erreur de script dans la machine d'état d'un objet pourrait se traduire en un dysfonctionnement du moteur lui-même... à proscrire à tout prix. Ca risque donc de me coûter un Engine::animate() un peu plus sophistiqué, mais l'idée est de garantir que tout objet "qui s'en va" sera présent au moins pendant une frame dans l'état "DISCARDED".

tcsh pour les experts...

2011-07-13T16:16:00.002+02:00

Bin moi, mon script de prédilection sous Linux, c'est TCSH. C'est ainsi depuis qu'on me l'a "imposé" pour un TP (base de données ou NS2 ... va savoir). Sous SuSE8.2, ça se passait pas trop mal: bonne auto-complétion, coloration, aliases sympa ... Sous ubuntu, en revanche, c'est quasiment le minimex, au point que j'ai longtemps remplacé les fichiers /etc/profile.d/complete.tcsh et autres d'une vieille SuSE sur mes ubuntu fraîchement installé.

Mais ça aussi, j'ai fini par en avoir marre, donc maintenant, j'ai "fait mienne" toute la super-logique en réutilisant le fichier ".csh.expert" prévu pour permettre à un guru du shell (ou à ses sbires, comme moi :-) de contourner les préférences du sysop. Bin pas de bol, même là, les gars d'Ubuntu ont manqué à leurs devoirs. Alors du coup,


diff -burN /etc/csh.cshrc "/MY/etc/csh.cshrc"@@ -1,4 +1,11 @@
 # /etc/csh.cshrc: system-wide .cshrc file for csh(1) and tcsh(1)
+# Expert mode: if we find $HOME/.csh.expert we skip our settings
+# used for interactive sessions and read in the expert file.
+#
+if (-r $HOME/.csh.expert) then
+    source $HOME/.csh.expert
+        goto end
+endif

 if ($?tcsh && $?prompt) then

@@ -14,3 +21,10 @@
        set prompt = "%U%m%u:%B%~%b%# "

 endif
+
+end:
+onintr
+#
+# csh.cshrc end here
+#
+if ( -r $HOME/.tcshrc ) source $HOME/.tcshrc

Me voilà un peu plus chez moi dans cette ré-installation du Lynx sur mon disque de 2To :P

Goro mode activated

2011-06-29T13:28:00.008+02:00

There are still a few things that are unpolished, such as (sprite-based) widgets that remain sticky between the FileWindow and the AnimWindow ... or whose state isn't coherent among the two. But at least, the basic feature is there: you can expand your "character" and give him more limbs if needed. Look at this 4-handed Mr. Egg, for instance. Isn't he wonderfully promising of future fun ?

Bin ça n'aura pas été une semaine très causante, sur ce blog, hein ? Que voulez-vous, c'est qu'en-dehors des "grands travaux", il y a parfois une série de petites choses ingrates qui n'ont droit qu'à une ligne dans une todo-list et une autre ligne lors de leur commit SVN. Mais ce coup-ci, les epsilon se sont additionnés suffisamment pour devenir un delta: je peux (enfin) modifier la "structure" de mes personnages (le nombre de sprites utilisés, les pages parmi lesquelles choisir les images et l'image de référence) depuis l'application DS elle-même. Il reste encore pas mal de nettoyage à faire pour éliminer les incohérences de l'application, bien sûr ... mais on a fait un bon pas en avant.

On s'approche déjà de la release 0.3 ... bonne chose.

[bugfix] : la "petite main" réapparaît quand je sélectionne qqch dans la spritetable de droite, AnimWindow
[bugfix partiel] : si je réouvre une animation 2-mains, elle est "promue" animation 3-mains-3-pieds :P
[now] : si je sauve par START+R+R, l'animation en cours n'est pas réécrite dans la feuille d'animations avant la sauvegarde (et donc pas sauvée).

Wii ! Une raclée pour Morton !

2011-06-27T12:12:00.000+02:00

Sisi, souvenez-vous, c'était en 2007. Je venais de finir New Super Mario Bros et je faisais le point sur les hauts et les bas du jeu, le comparant notamment à SMB3. Eh bien mon frère a finalement de nouveau une Wii avec le Mario multi-joueur ... et qu'est ce qu'on s'éclate! Je crois bien qu'un jeu de plate-forme n'avait plus été aussi fun depuis ... houu ... Tic & Tac Rescue Rangers sur NES ?

Tous les éléments intéressants des maps n'ont pas été repris (quelqu'un a vu une boîte à musique ou des rochers à détruire ?), mais on garde les mini-combats avec monstres sur la map et les chemins alternatifs qui deviennent disponibles ou non d'un niveau à l'autre (cf. monde forestier). On est dans quelque-chose d'intermédiaire entre SMW et SMB3, en somme. Il faut bien dire que la gestion des "maps" était tellement poussée dans SMB3 qu'on se retrouve pour ainsi dire dans un "overworld" qui devient presque un mini-jeu tour à tour.

Le contrôle des power-ups est beaucoup plus proche de celui de SMB3, avec le chapeau-volant pour contrer la gravité -- qui reste votre ennemie numéro 1 dans un Mario -- qui vient remplacer la plume magique, et le costume de pingouin qui fait écho au costume de grenouille ... en mieux. Il manque peut-être, me semble-t-il, un power-up "rare". L'équivalent de la tenue des frères marteaux ou du costume de tanooki. Mais peut-être que je ne l'ai tout simplement pas encore trouvé ^_^

Creating new skelettons.

2011-06-23T13:37:00.005+02:00

Animation skeletton, GobStructure ... I haven't found yet the term that best describe "the set of pages to be used for the limbs of a compound GameObject". And I also struggle making it part of the AnimEditor. So I took the lunch to chart the three main components involved - AnimWindow, ThumbsWindow and FileWindow - and how they use each others. I want the skeletton to be defined on the FileWindow because it's convenient to navigate through available pages there (and I have plenty of room for widgets).

Je cale un peu sur la manière d'implémenter la création de la "structure" d'un sprite composite (quelle page de sprites utiliser pour quel "membre" et combien de membres y aura-t'il en tout. Entendons-nous bien: quand je dis "je cale", ici, ça signifie que je ne parviens pas à déméler la pelotte de code sur la demie-heure de disponible entre le souper et le bibi de *deline.
Dans ces cas-là rien de tel qu'un petit temps-de-midi-uml pour cartographier les alentours, même si je n'ai pas respecté la moitié des règles de bonnes pratique que je connais ^^".

Red path: FileWindow directly save the new structure into one of the animations under the selected thumb slot. Boulder: FileWindow can't convert a skeletton into a serialised representation.
Blue path: FileWindow just notify AnimWindow of the skeletton modification. Question: what should happen with the current animation ?

Edit: à bien y réfléchir, c'est quand-même un peu ridicule de se prendre à ce point la tête pour une telle bêtise! c'est tout le temps comme ça, le développement en C++ ?

"hackers handheld gaming platform"

2011-06-22T09:04:00.003+02:00

G. Andrew Stone, author of the RSD Game-Maker has shown up. On his blog, he unveils some nice trivias on Game-Maker development.

Of course, I had to post a comment pointing out my own DS development, since the spirit is very similar to the one of RSD Game-Maker. I had the pleasure to read this reply this morning :
Hi! Great to hear from you and see the RSD Gamemaker helped you find your avocation! I read your posts on the DS and that is a pretty good idea; it would be great to have sort of a hackers handheld gaming platform!

Presque 15 ans plus tard, grâce à Aderack, je peux enfin mettre un nom sur le créateur du Game-Maker qui nous a permis mon frère et moi de laisser parler notre créativité de grands ados: G. Andrew Stone. Sur son blog, Andrew nous donne quelques détails techniques sur la réalisation du logiciel, qui était probablement le premier outil "do it yourself" à offrir tant de flexibilité (le Shoot-em-up Construction Kit de Sensible Software est plus ancien, mais limité à un seul type de jeu et s'apparente du coup d'avantage à un "level editor" avant l'heure).

L'absence de toute technique de protection du contenu (un utilisateur de RSD peut réimporter et modifier les jeux écrits par d'autres) était volontaire et vue comme une sorte de "creative common license" avant l'heure. Le plus étonnant, c'est que cet outil a lui aussi été développé par des jeunes, ne recevant du soutient d'adultes que pour les aspects "distribution, marketting", etc. La version 3.0 est sans doute sortie alors qu'Andrew et son frère étaient en 1ere année de collège (l'équivalent aux States des études supérieures ici).

Pourtant, Andrew n'a pas poussé plus loin le développement de jeu. Il nous parle majoritairement de jobs dans des sociétés en tant qu'informaticien détaché, et bricole des petits projets sur FPGA.

anim0-10 = spr0.anim0-10

2011-06-14T13:37:00.001+02:00

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 !

2011-06-10T23:01:00.011+02:00

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

Microsoft cannot read!

2011-06-10T09:35:00.008+02:00

Quand on se mêle d'écrire un serveur Web, le moins qu'on puisse espérer, c'est que les développeurs se soient correctement renseignés sur "ce que c'est, le Web" (donc au moins le RFC du protocole HTTP). Document dans lequel on trouve par exemple à la section 4.4

The transfer-length of a message is the length of the message-body as
it appears in the message; (...) 
   
If a Content-Length header field (section 14.13) is present, its
decimal value in OCTETs represents both the entity-length and the
transfer-length. The Content-Length header field MUST NOT be sent
if these two lengths are different

Seriously, dudes. When one dares to write books where chapters are entitled "users can't read" where you explain how to design GUIs, the same one should prove that *he* does read. And more obviously, when one pretend to ship a web server, the same one should ensure that it actually serves _the_ web and not _what you'd prefer the web to be_. Read the specification snippet above. Read the reply trace below. Any sound heard in your brain ?

En d'autre termes, si la taille du fichier (sur le serveur) et la taille des données envoyées (dans la réponse HTTP) diffèrent, l'en-tête Content-Length est interdit. C'est ce qu'il peut y avoir de plus fort dans un RFC qui se contente généralement de "SHOULD" et autres "MAY". Pensiez-vous que ça suffise aux guignols de Redmond ? Eh bien non.

13720 recv(12, "
HTTP/1.1 206 Partial Content\r\n
Content-Type: application/x-zip-compressed\r\n
Last-Modified: Mon, 16 May 2011 04:21:42 GMT\r\n
Accept-Ranges: bytes\r\n
ETag: \"6fe34bc28013cc1:0\"\r\n
Server: Microsoft-IIS/7.5\r\n
X-Powered-By: ASP.NET\r\n
Date: Thu, 09 Jun 2011 17:12:04 GMT\r\n
Content-Length: 4000000\r\n
Content-Range: bytes 0-3999999/38651711\r\n
\r\n
PK\3\4\24\0\0\0\10\0n\212;>\204\10\231\20\265\253\25\0
\222\202\26\0\25\0\0\0secret_garden_lrg.jpg\354|y8\324
"..., 8192, 0) = 1368

Voici donc une réponse qui dit à la fois "le fichier fait 4,000,000 bytes" (Content-Length == Entity-Length) et "le fichier fait 38,651,711 bytes" (Content-Range).

So the file is both 4,000,000 and 38,651,711 bytes long, right ?
No wonder why you dodged the IPv6 day, eh ?

=IPv6=

2011-06-08T13:59:00.004+02:00

Pas de doodle-google pour célébrer la "journée IPv6" ... juste un logo "blogger" animé sur le dashboard (ça énèèèèèrve @_@). Pas de statistiques sur sourceforge.net, non plus, ni d'images, si bien qu'en voulant cliquer quand même sur les statistiques de téléchargement de mon SpriteEditor(0.)4, j'ai finalement cliqué sur le # qui voulait dire "effacer le fichier".

Ca m'aura pris un bon quart-d'heure sur Nintendomax pour retrouver le .zip (packagé sur un autre ordi :P) et le réenvoyer >_< Désolé pour ceux qui ont eu un "black-out de téléchargement" pendant ce temps-là.

#define atoi(str) Integer.parseInt(str)

2011-06-07T11:32:00.001+02:00

J'ai beau essayer, essayer encore, y mettre de la bonne volonté, je ne comprends pas comment la version Java "Integer.parseInt(...)" peut être préférable à ma bonne vieille A(scii)TO()I(nteger). Les programmeurs sont supposés être des spécialistes. Celui qui trouve que strlen(itoa(42)) est obscur doit tout simplement pratiquer davantage et pas écrire un langage dans lequel il faille écrire new Integer(42).toString().length(), si ?

Je risque un deuxième coup de gueule contre Java the Hutt... Qui a été bourrer le crâne des gens au point que je me retrouve avec une classe Instances qui gère un vecteur de Instances, mais en donnant de nouveaux noms (numInstances(), enumerateInstances(), addInstance()) ? Hmmm ? Personne ne se dénonce? Eh bien vous serez tous privés de stdout! Tant pis pour vous.

J'ai peut-être bien été trop entrainé en secondaire à retenir "le sens" des choses plutôt que de retenir par coeur des phrases toutes faites ... Quant à dire que Java est le "langage plus simple qui crie pour sortir de C++", bin sorry, mais je ne ferai pas le pas: mes petits outils de conversion, ils resteront en PERL.

Bon, c'est pas tout ça, 'faut que je me replonge sur ce programme. Oh. length() n'est pas une méthode des tableaux, mais une ... euh. Une quoi, au fait? Rien d'autre dans Java ne semble se comporter de la même manière que args.length.

Tout n'est pas noir, dans Java, mais tout n'est pas rose non plus. Ils nous ont ajouté à la version 5 l'équivalent du foreach du PERL ... sympa et concis. Sauf que ça ne marche que sur les Iterators, qui avaient été introduits en remplacement des Enumeration -- dont les noms de méthodes avaient alors été jugés trop longs. Alors c'est vrai que getNextElement(), ça ne m'a jamais épaté, mais du coup, si j'utilise une bibliothèque (Weka ?) qui est restées aux Enumerations, je ne peux pas me servir de foreach >_<.

Welcome, libfat 1.0.9

2011-06-06T21:41:00.008+02:00

While I was busy on a tons of things (including building up the first prototypes of AnimEDS) in february, Wintermute and his friends at devkitpro did a major revamp of the libfat, separating "what's good for the DS" from "what's good for the Wii". When it comes to mass storage performance, the two beasts are strongly different ... L1 cache, data transfer speeds, amount of L2 memory ... The release (1.0.7) I used in my "dkp-r32" setup tried (and failed) to provide a uniformised solution. I tried a few hacks that at some point looked to improve the performance, but didn't find the time to quantify the boost in a systemic way. I offered a patch, but ignoring the project's habbits made it doomed to /dev/null.

Hopefully, the new build seems to provide good performance again (PC->AP->DS transfer rates of 64-80KB/s at home).

Oh well, one annoying difference remain: i *have* to apply a DLDI patch manually for SCSD device (which used to have a built-in driver in former libfat). I also have an issue with directory scanning ... ~~I hope it won't take too long to figure out what it is.~~ it looks like I underestimated the MAX_FILENAME_LENGTH ... again ...

J'étais tellement à la bourre en février que j'ai complètement loupé la sortie de la version 1.0.9 de la libfat. Heureusement que je suis repassé jeter un oeil sur le forum de devkitpro après avoir tenté de refaire le point sur l'état du cache la semaine dernière, sinon j'aurais bêtement perdu plein de temps. Enfin, donc, une version qui traite la DS indépendamment de la Wii et de la gamecube, même si j'ai du ruser pour contourner les problèmes de __io_dsisd manquant et patchouiller mes programme pour m'ajuster à une augmentation de MAX_FILENAME_LENGTH visant à améliorer le support d'UTF8. Enfin, c'est réglé.

Une vitesse de transfer entre 64 et 80kB/s (@home en utilisant le wifi entre le PC et le routeur et entre le routeur et la DS), c'est tout ce que je demandais.

Bon, maintenant, 'faudra que je regarde comment faire en sorte que ma fonction die() marche à nouveau ...

(PS: oui, j'ai testé tout ça sur la PHAT de ma fée, histoire de limiter la casse et les pertes de données au cas où... honte à moi ^^" ... ~~quoi que, avec le binaire de SEDS qui crèe systématiquement des fichiers de taille 0 datant de janvier 1979 ...~~)

Et ... qu'est-ce qu'on fait maintenant ?

2011-05-31T19:00:00.000+02:00

Bion première release de AnimEDS: check, mise à jour de SEDS : check. Quoi d'autre ?

En premier, une petite uniformisation de mon environnement de compilation ne serait peut-être pas une mauvaise idée. J'avais identifié un problème de performances dans la libfat pendant les congés de Noël ... ça pourrait valoir la peine de revenir dessus histoire de soumettre un "vrai" patch pour le projet devkitpro. Pour l'instant:
- démarrer SEDSgama.nds depuis le menu R4 et faire un "QUIT" vers rungama.nds: ok
- mise à jour interne de SEDSgama et rungama: ok, mais lent (compilé sur beetle)
- démarrer SEDSgama depuis runbeta: ok, mais empèche d'utiliser le loader pour sortir de SEDSgama.

Ensuite, on pourra voir pour les histoires d'effets miroir dans AnimEDS, la définition d'autres structures de sprites (changer le nombre de membres et l'utilisation des pages de sprites) et le support de tout ça dans le moteur de jeu (eh oui, l'idée, ça reste de faire des jeux).

Download Sprite Editor 0.4

2011-05-28T21:37:00.005+02:00

Here we go: The newest version of my Sprite Editor for Nintendo DS.

Palette editor has been improved and made more comfortable,
new functions on the grid: swapping, colour scan, overlays stamping
bucket-fill tool (L+B)
many small (obscure) tools to assist colour reduction tasks.
compatibility with my brand-new Animation Editor for DS.

Nous y voilà. Enfin toutes les améliorations apportées à mon Sprite Editor pour DS depuis fin 2008 regroupées, contrôlées, et documentées dans la version 0.4:

éditeur de palette complet et plus ergonomique
fonctions miroir, superpositions d'images et remplissage rapide
Réorganisation et réduction de couleurs (non-documenté)
compatibilité avec les animations produites par AnimEDS

Press L+R in the application for hints, or read the detailed manual

grayscale preview : done.

2011-05-26T13:43:00.007+02:00

Well, I guess it would be fair enough to admit that my knowledge in image processing turned out to be insufficient to provide a "magic contrast boost" slider in SEDS. Yet I regularly have contrast issues with my sprites, and I've learnt on Pixelation forums that turning your sprite into grayscale is a nice way to investigate whether a sprite is contrasted and readable enough. So the plan was

gray = red*.30+grn*.59+blu*.11

C'est la formule qui permet de passer d'une couleur RGB à un niveau de gris "équivalent". Or, passer son sprite en niveau de gris, c'est le truc ultime des gurus de Pixelation pour savoir si le contraste est suffisant ou non. A défaut d'un "boosteur de contraste" magique, c'est le moins que je puisse tenter.

Reste à le mettre en oeuvre. C'est le genre de chose qui aurait été impensable avec mes éditeurs sous DOS, n'ayant qu'une palette unique de 256 couleurs ... Mais ici, avec le soutient des "sprites DirectColor" (ou ATTR0_BMP), c'est une autre histoire ... Moyennant une consommation de mémoire vidéo un peu plus importante, je peux directement donner les composant RGB de chaque pixel individuellement et indépendamment des palettes "background" et "sprite".

Ca n'aura pas été sans mal quand même, tant le fonctionnement de ces sprites diffère de celui de mes "bons vieux sprites habituels". D'abord, exit le tiling. Le pixel (x,y) à l'intérieur du sprite est stocké dans le y*width+x ème "short", tout simplement. Vu que la dénomination officielle est "SPR_BITMAP", il fallait un peu s'y attendre, celà dit :P
Deuxio, ces sprites-là ont leur propre bits de contrôle dans REG_DISPCNT, et peuvent donc rester en "mode 2D" alors que les autres sprites sont en mode 1D. On dirait d'ailleurs que desmume a encore quelques soucis avec ça et qu'il utilise ces sprites en mode 1D quoi qu'il advienne 0_0.
Enfin, le "numéro de tile" n'est plus du tout interprété de la même manière. L'interprétation exacte est donnée sur gbatek, mais en ce qui me concerne je me suis contenté d'une heuristique du genre "tileno/2" avec un 'padding' pour aligner les données du sprites sur le bloc de 32 tiles le plus proche:

tileno=Engine::allocate(Engine::RES_SPRITETILE,32+PAD); // will use directcolor. if (PAD && tileno&(PAD-1)) tileno=(tileno+PAD)&(~(PAD-1)); sprdata = SPRITE_GFX + tileno*32; Engine::sprites[oam].attribute[0]=ATTR0_BMP|ATTR0_ROTSCALE_DOUBLE|OBJ_Y(0); Engine::sprites[oam].attribute[1]=ATTR1_ROTDATA(rot)|ATTR1_SIZE_32|OBJ_X(96); Engine::sprites[oam].attribute[2]=ATTR2_PRIORITY(1)|ATTR2_ALPHA(1)|(tileno/2);

The idea was to use "direct-color" sprites in order to have the freedom of picking RGB colors without messing up with the sprite palette (sprites are already used to render the whole palette at the bottom of the editor, so that we have enough freedom for widgets). That would only cost me some more video memory (clearly affordable in this context) ... and some discovery of these new sprites' oddities...
A separate control on 1D/2D sprites, a specific scheme for reading data out of the VRAM (lowest bits of "tileno" are now used as a horizontal shift in an otherwise bitmap area) ... And of course, no tiling of the sprite data (these are named "BITMAP" sprites. What exactly did you expect, hmm ?)

Well, that's all done, now. Just give me some more time to remove debugging statements, and I should be able to release Sprite Editor 0.4 by Monday.

Contrast Boost ...

2011-05-25T13:43:00.005+02:00

J'ai la fâcheuse manie de dessiner avec un contraste trop faible entre mes couleurs (cf image du milieu), et du coup, toutes mes tentatives d'ombrage et de lumière ont tendance à tomber à plat, en particulier sur des décors plus variés... du coup, je corrige a posteriori dans The Gimp, avec un résultat plus ou moins heureux, vu que je ne sais pas ajuster la disposition des pixels en fonction des nouvelles couleurs...

J'avais donc dans l'idée d'ajouter un bouton (ou une règlette) "augmenter le contraste" dans SEDS pour sa prochaine révision ... encore faudrait-il savoir ce que cette règlette serait supposée faire. Le contraste automatique de Gimp agit à la fois sur la saturation en couleurs (augmentée dans tous les cas) et sur la valeur (hsV), mais pas évident d'en déduire ce qui est effectivement fait.
La difficulté, à la main, serait de revoir l'ensemble des couleurs d'un dégradé tout en gardant la cohérence du dégradé. J'ai tenté de modifier les "sliders" de l'éditeur de palette pour faciliter l'édition d'une succession de couleurs .. pour rien: la fonction souhaitée (sélectionner un slider sans le modifier) était déjà disponible avec L+click :P

Je pourrais peut-être déjà proposer une variante "niveaux de gris" du sprite, ce qui a tendance à faire ressortir les problèmes de contrastes pour les gens qui se laissent trop facilement distraire par la "chrominance" ... comme moi, apparemment :P

Pas de 3DS pour moi.

2011-05-21T14:09:00.002+02:00

Devant, un bijou technologique. Derrière, un appareil sur lequel vous n'avez finalement aucun contrôle, qui s'apparente d'avantage à un mouchard déposé chez vous par Nintendo qu'à une console de jeu!

Que Nintendo veuille protéger ses ventes, très bien pour moi. Qu'ils poursuivent en justice les gens qui vendent du matériel destiné au piratage de leurs jeux, pas de soucis avec ça non plus. Les jeux qui m'intéressent sont parfois bien dur à trouver, mais jusqu'ici, j'ai presque toujours fini par mettre la main dessus, que ce soit à la médiathèque ou en magasin. Qu'ils bloquent l'accès au "DSiWare" quand un composant non-conforme est présent (ou a laissé des traces dans le système), "fair enough".

En revanche, s'octroyer le droit de rendre l'appareil que vous avez acheté définitivement hors d'usage, là je dis non. Sony qui retire à distance la fonction Other OS, c'était déjà exagéré, mais menacer (et avoir techniquement prévu) de transformer l'appareil en un tas de transistors inutilisables est tout simplement inacceptable. S'octroyer le droit d'utiliser les commentaires et les photos prises par l'utilisateur, c'est du Big Bowser à l'état pur. Mille sabords, on l'a acheté, cet engin, ou on s'est vendu ?

Je suis malheureusement trop tard pour la campagne, mais mon choix est fait: votre percée technologique, vous pouvez vous asseoir dessus, messieurs. Je suis seul maître à bord et seul responsable de mes actes en 192.168.*.* et j'entends bien le rester. Comptez sur moi pour avertir tous les parents aux alentours de ne pas acheter cet engin à leurs gamins!

Cliquez sur l'image pour accéder aux informations de la campagne contre Nintendo of America.

srpite eoitdr rleasee psotpnoed

2011-05-20T13:48:00.006+02:00

Ouhlà! Qu'est-ce que c'est que ce souk !?? Je savais que j'avais fait pas mal de modification à ma bibliothèque de "support" pour le Sprite Editor, mais là, on nage en plein délire !? Les widgets "grille 16x16" et "grille 32x32" sont inversées ou quelque-chose du genre. Du coup, ce n'est plus l'image à l'écran qui est manipulée, mais une autre, hors-écran. Bin il va y avoir un peu de nettoyage à faire avant de faire une release du Sprite Editor, on dirait bien.

WTH? I knew the "core" libgeds library (the Gui Engine) had been reviewed several times since the last SpriteEditor release ... and obviously I should have proceeded with back-compatibility tests more often, because it looks like *nothing* works with this SEDS 0.4 release candidate. Oh, well, the palette edition window do work flawlessly, but there's something horribly wrong with the grid widgets. It looks like the 32x32 grid handle clicks when the 16x16 grid is displayed and vice-versa. The hell if I know why. More clean-up, code printing, overlining, and UML teacup to come ahead, I'm afraid.

The release is postponed until I can figure out where all this mess comes from.

Sprite Editor v0.4 pour bientôt ?

2011-05-17T14:48:00.014+02:00

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" ...

AnimEditor 0.2 for download !

2011-05-11T13:15:00.002+02:00

At last, here you go. Have fun with Mr. Easter Egg. See this post for how to use the editor.

Stay tuned for updates.

Using AnimEDS

2011-05-11T12:20:00.001+02:00

1) download it, ensure you've got a DS linker ready.
2) install spritex.spr at the root of your media card
3) place AnimEditor.nds anywhere you like on your media card
4) launch the .nds file with your linker.

START-L-X : load the spritex.spr file (other spritesheets can be built with SEDS)
Click the limbs on the central area to select them, then move them around with the stylus or the DPAD. press L to de-select the current limb.
Press Y to copY the current frame and edit the next (copied) frame.
When no limb is selected, press UP or DOWN on the DPAD to move from frame to frame. Press LEFT or RIGHT to move the selected frame around the timeline.
Use the limbs miniature on the left to select a limb more accurately or to make its associate spritesheet appearing on the right.
Touch one of the sprites on the right sheet to change which image is displayed.
press R-R to write back that animation to the "thumb window". When the thumbs window is displayed (pressing R once) on the bottom screen, use DPAD to select an animation slot, A to load it in the editor, R to save the editor's content and L to return to the editor without writing back.
press START-R-R to save back your work.

DISCLAIMER:

AnimEditor v0.2 is still hard-coded for a specific layout of the .spr file (esp. regarding which page to use for the different limbs). This may result in odd content displayed on screen before you load a file.

Une petite vidéo d'AnimEDS 0.1

2011-05-08T14:35:00.008+02:00

'Faut que je fasse de la place sur mon appareil photo avant la visite du Keukenhof ... ce qui fait que j'ai retrouvé la petite vidéo de démonstration des possibilités d'AnimEDS 0.1

Evidemment, ç'aurait été mieux d'en faire une nouvelle avec la version courante qui devient progressivement "presqu'utilisable", mais le temps est plus ou moins limité ici.

Better late than never, I hope: two commits ahead of AnimEDS 0.2, I finally uploaded the demo video of AnimEDS 0.1 that demonstrates the basic user interface. Stay tuned.

Iteraatooor ... Giv'me Innformationnn.

2011-05-04T13:01:00.004+02:00

Donc, se donner un objet représentant "une position dans une séquence" sur lequel il soit possible de faire les opérations habituelles "avancer à l'élément suivant" ou "obtenir le contenu de l'élément actuel" comme si on avait affaire à un "bon vieux pointeur dans un tableau C", c'était l'idée de std::{whatever}::iterator.

Si c'est sympa à la base (surtout pour ceux qui n'ont jamais fait de programmation fonctionnelle et pour qui les manipulations de listes à coup de grep ou map semblent occultes), en revanche, ça donne parfois des effets troublants dans la mesure où l'itérateur risque (s'il y a la moindre faille dans votre vigilance) de parcourir un objet qui n'existe plus.

Du moins, c'est l'explication la plus probable des fantaisies que j'observe dans mon éditeur d'animations.

AnimShow -- le retour.

2011-05-02T23:34:00.003+02:00

At last, I can preview the animation in the animation editor. That should bring release 0.2 one step closer. Now I only need to do some polish ... and get some sleep :P

Et voilà. Enfin des animations animées dans mon éditeur d'animations. Je vais devoir vous demander d'attendre encore un peu -- un minimum de polish et de tests en live sur DS -- avant de vous proposer la release 0.2 et son Easter Egg ...

UI revision for AnimEDS

2011-04-26T12:54:00.003+02:00

Puisque mon petit éditeur d'animations marchait plutôt bien ce week-end, j'ai voulu le faire essayer à ma fée et à mon frère avant une petite "pre-release" destinées à nos charmantes têtes blondes en mal d'inspiration pour jouer aux playmobils. C'est là que je me suis rendu compte que le programme avait tout de l'instrument de torture:

il faut maintenir L enfoncé pendant qu'on déplace un des composant de l'animation. Ca devient fatiguant pour les poignets au bout de 10 minutes d'utilisation, et ça demande de sérieuses contorsions pour un utilisateur gaucher >_<
sans confirmation visuelle du composant sélectionné pour le déplacement, les choses deviennent franchement hasardeuses dès que l'on superpose certains éléments
pour passer au cellulos suivant ou précédent, il faut impérativement cliquer sur la ligne du temps, ce qui empêche de faire des corrections rapides sur une animation complète.
On déplace fréquemment un objet par erreur. Il serait préférable de pouvoir le renvoyer à sa dernière position.

Operating the animation editor turns out to be a pain. I mean physically: you feel strain in your wrist after some 10 minutes. I need to revise a few things, and I intend to do that revision while focusing on the primary function of the various widgets. For instance, moving limbs around -- not selecting them -- is the primary function of the FrameEditor, and therefore, this must be the action bound to GUI_TOUCHED. I also need to ensure that it will be possible to quickly revise the movement of one limb along a given animation, which isn't possible right now as you need to have the timeline selected for that purpose.

Bref, je vais devoir revoir ma copie: je n'ai pas prévu de faire de cet éditeur une arme paralysante.

Almost done ...

2011-04-22T14:15:00.007+02:00

As soon as you realise that the DMA unit of the nintendo DS cannot manipulate whatever is on the stack because the stack (DTCM) is basically connected directly to the ARM9 cpu and therefore not accessible through the system bus, it gets easier to debug the rest of the code.
It required some cleanup and head-scratching, but at last I have thumbs for the frames rendered on the timeline and a similar thumb for each animation slot rendered on the upper screen. All I still need to get done for release 0.2 is now to allow multiple animations to be saved ... Oh, and I might also need to check that the sprite editor can manipulate the pixels of a .spr file without trashing the animations it contains.

errm. Wait ... I might need something to preview the animation as well ^^"

C++ doesn't help!

2011-04-19T10:54:00.008+02:00

I really feel the lack of any "package" protection level in C++. Every significant new piece of software triggers some hide-and-seek problems that must be solved before the code can actually get written. Something like saving animations and re-loading them, for instance.

I struggled with "how I could share the animation data so that AnimWindow doesn't have to know the details of writing to files, but that FileWindow doesn't need to know the details of animations structures... Then came the ghosts of deep object copy and reference counting bats (they are quite frequent in the caves of poor design).

Curieux, non ? Dans la petite "todo list" basée sur les premiers essais sur DS, aucune mention de "sauver l'animation créée" ... C'est pourtant la fonctionnalité primaire qui manquait encore et qui devait recevoir la priorité. C'est qu'à nouveau, on touche à "qui peut manipuler quoi" dans le programme, et le C++ n'aide vraiment pas dans ce domaine-là. Par moment, j'en viens à regretter la "visibilité par package" du Java. C'est dire!

Hopefully, a light sparkled in the darkness: I needed animation data to be shared by the two windows, but that didn't mean the objects must be accessed by the two. The animation being edited can remain held in AnimWindow::tlist and AnimWindow::anim, as the other components won't edit frames or timeline. And that allowed me to apply the coding practice that works the best for me: interfaces. All I need is that AnimWindow offers a iAnimHolder to the rest of the software. That interface serialise the current animation into a vector of information with the only constraint that it must be easy to reconstruct the editable object. pfew.

From that point on, things went better: it was a mere matter of mimmicking the Scream Tracker's approach to pattern compression: if value is repeated, don't repeat it. Bare "unsigned" encoding command-class, command (e.g. move limb, delay, change sprite ...), object identifier (which limb, usually) and leaving 16 bits for the actual data (number of frames to wait, sprite reference or pair of coordinates relative to the "center" of the frame editor) was enough. And they could naturally be packed into an large DataBlock before being pushed to a .spr file.

Heureusement, à force d'accumuler les tentatives UML, j'ai fini par constater que les besoins de AnimWindow::tlist ne sont pas similaires à ceux de ThumbsWindow et FileWindow: seul l'AnimWindow doit manipuler les animations en tant qu'objet. Pour le reste, il me suffira de "stocker" les animations pour pouvoir les resservir plus tard. En somme, il suffit que l'AnimWindow offre une interface de sérialisation/désérialisation et rien de plus.

Comme la sauvegarde et le chargement de fichiers .spr prévoyait déjà la possibilité de manipuler des blocs "de données inconnues", le reste n'était que pure formalité: voilà donc AnimEds capable de sauver et recharger une animation. Encore quelques widgets et on pourra en manipuler autant qu'on veut et passer de l'une à l'autre comme s'il s'agissait de simples sprites.

Oh, btw, if you missed the post "animation editor 0.1", it has been translated earlier today.

Animation editor ... 0.1

2011-04-17T16:57:00.003+02:00

La bonne nouvelle, c'est que mon éditeur d'animations est plus ou moins au stade 0.1: on sait à présent définir une série "cellulos" en déplaçant les membres du personnage et les passer en revue avec le DPAD. Si ça manque encore un peu de finesse et d'intuitivité, la fonction primaire est là.

Good news first: AnimEDS has reached what we can hope for version 0.1: you can select limbs by touching them on the FrameEditor widget, move limbs around on a frame by holding L, press Y to save that frame and proceed to the next one, etc. Once you're done, just click any frame on the timeline and then use 'UP' and 'DOWN' on the DPAD to preview the animation. No way to save it, though.

Where things gets less funny, is that although I can provide you a download link for the app, I cannot ship the raymanim.spr file that turns it into a "raymanimator" -- not without the blessing of Michel Ancel or Ubisoft. And so far, some parameters of the animation (such as the number of limbs, and which one is on which SpritePage) are still hard-coded, so even if you had the time to draw the limbs for another character (I can't afford it right now), you would have hard time planning its use with AnimEDS :-/

La moins bonne nouvelle, c'est que même si je fais une release du programme, il restera inutilisable. La sélection des "membres" dans un fichier .spr est pour l'instant encodée en dur dans le programme pour coller avec mon fichier "rayman.spr", et sans l'accord d'Ubisoft ou de Michel Ancel, je ne peux pas distribuer ce fichier... Dommage, parce que je connais plus d'une tête blonde qui se serait bien amusé à faire faire quelque mouvements à ce personnage bien sympathique. Alors évidemment, je pourrais vous proposer un autre personnage de mon crû avec lequel jouer au marionnettes. N'étant pas graphiste, celà risquerait de me prendre un temps de dingue. Il faudrait peut-être que je lance une annonce sur Deviant Art ou Pixelation ...