Tu (d)'chus, il chût

Le scrolling bouge un peu tard quand le personnage tombe, ce qui pourrait être délicat pour les scènes de plateforme avec du scrolling vertical.

Bigre! Il a raison, le bougre! Evidemment, je commence à connaître mes niveaux par coeur, donc je me promène dedans sans me rendre compte que la visibilité est insuffisante, ou que Bilou est presqu'en train de tomber hors de l'écran.

Il faut avouer que je tâtonne pas mal avec le scrolling. Ce serait assez simple de garder Bilou en permanence exactement au milieu de l'écran, mais je ne le souhaite pas. En particulier pas pendant un saut. Mais ça, je vous en avais déjà parlé, vidéos à l'appui. J'avais donc fait en sorte que seule la vitesse horizontale soit immédiatement prise en compte: les contrôleurs indiquent à la caméra la vitesse exacte de Bilou et la caméra s'y adapte. En plus de ça, j'ai toujours un "garde-fou" qui force la caméra à se recentrer sur Bilou si celui-ci est trop loin de l' écran (en gros, comme un BerryBat se rapproche de Bilou).

Morukutsu pointed out that it was pretty hard in my last release to fall down safely. The camera management tends to let Bilou get really close to the bottom of the screen when falling ... it may even let it "out" of the screen from times to times. I was shocked to realise how true he was. I guess I'm so used to my own game that I barely needs to read anything from screen and I can safely reach any area of the game "blindly". So I tried to sort it out.

It wouldn't be much of an issue to simply keep Bilou in the middle of the screen at all time, but that's definitely not what I want. It leads to very disturbing camera moves when you hop from platform to platform. Plus, it means that you loose track of what you're jumping over during the jump -- as I already said previously.

Mais du coup, dans certains cas, Bilou peut atteindre une telle vitesse que lorsque la caméra "réagit" pour tenter de le suivre, il est déjà trop tard et il se retrouve fort au bord de l'écran. Je corrige le tir avec une règle qui force la caméra à suivre la chute de Bilou dès qu'il va descendre plus bas que la hauteur d'où il a sauté.

Il me manque une rime en "eutre" ...

... euh pardon. Interférence. Il me manque encore une règle dans les contrôleurs "walking" et "idle" qui indiquerait à la caméra "recentre-toi sur Bilou verticalement, tant qu'à faire". Parce que pour l'instant, quand Bilou s'arrête dans les branches à la fin d'un saut, il peut parfaitement rester "fort au bord" (haut ou bas) de l'écran malgré tout. En attendant, j'ai modifié le "StopperController" pour qu'il permette au joueur de regarder en haut ou en bas avec le DPAD. C'est toujours ça.

I just missed that, if I don't update camera's position during a jump, it may be too late to track Bilou back to the center of the screen when he falls down. I thus adjusted so that we follow Bilou's speed again -- even when falling -- as soon as the "landing speed" is reached. By landing speed, I mean "the opposite of jump-off speed", and it is reached when you come back at the vertical position you're jumping from. It's not yet fully Commander Keen's Magic Scrolling, but it's getting close. And I added look up/look down in the "idle" state so that the player can force Bilou to get back in the center of the screen.

Berrybats!

Bion, ça ne va pas être un post extraordinaire parce que j'ai la crève. Et ce n'est pas une évolution extraordinaire non plus, en fait. C'est juste qu'à additionner 2 et 2, on finit par avoir 4. Et en l'occurence, ici, 4, c'est une baie sauvage volante non-identifiée qui colle Bilou au train dans les bois. Voyez plutôt. Ou jetez un coup d'oeil aux sources de la démo, c'est selon. Bien qu'ayant changé de nom à plusieurs reprises, les BerryBats restent l'ennemi le plus ancien de Bilou (bon, okay, il ne fallait pas trop se forcer pour y penser au départ). J'avais prévu un long post de rétrospective mais je vais plutôt finir de boire mon ciment et retourner me coucher. Je vous invite à retourner voir l'ensemble des posts marqués "berrybat" pour vous faire une idée de ce que j'aurais causé. I'm sick. So don't expect some very fancy stuff around. I just put the last bits together that were needed to have a berry bat flying around and tracking Bilou in the woods. It's mostly harmless at the moment. It's not even "turning back" nor does it sits sleeping until Bilou gets close. But it is the eldest of Bilou's ennemies and I had kept its pixels secret for too long. Enjoy. I'm gonna have my medecine and get some sleep. Enjoy the previous posts tagged "berrybats", that should tell it all. Oh, au passage, faites donc un tour sur Pixelation, j'y avais fortement fait évoluer le "look" des chauves-souris entre leur version "pomme" et leur version "baie".

Des Bilous Partout!

I pretty much love when the template code is written down and that you only have to add a few lines to increase functionalities. Enthusiast Coding, do I call it. I managed to have monsters moved around in LEDS yesterday evening, and today, I just hacked around to change their state, which includes changing which character or monster you have. I'm still missing "clone" and "kill" to be done.

I hope I'll find the time to write down "save monsters position to file" this week-end, between my Brother's Birthday, planned concert and crafting of my fairy's rocking chair.

C'est le moment que je préfère ... et difficile de contenir mon enthousiasme. La structure est là, les questions pénibles sont réglées, il n'y a plus qu'à ajouter quelques lignes par-ci par-là pour voir les fonctionnalités apparaître... un clic, je sélectionne un GOB, je maintiens L enfoncé et je le balade à la pointe de mon stylet ... A et B me permettent de choisir l'état suivant ou précédent (comme on 'naviguait' dans les samples sous Scream Tracker III), et voilà: y'a des Bilous partout!

Avec un peu de chance, j'aurai le temps de coder la sauvegarde de tout ça ce week-end (à caser entre le montage du rocking-chair et le concert de Witloof Bay, quand-même).

Monsters!

The "model" part is written down : the level editor is now capable of parsing a .cmd script, investigate sub-scripts for state and picture information, and the MapWindow can invoke MonstersManager::display() to spice up the rendered level scene with monsters. Now to the "controller" part and ensure that I can move object around, change the state they use, etc.

C'est bon. Le côté "modèle de données" pour les monstres est fini. L'éditeur est capable de lire les scripts .cmd et d'en extraire les informations nécessaires pour dessiner les monstres aux positions adéquates sur la map. Ca n'aura finalement pas été si terrible dès que je me suis remis en tête la différence entre setupOAM, setOAM et changeOAM dans (ma propre classe) SpritePage :)

Maintenant, il faudra passer au côté "view & controller" pour véritablement déplacer et éditer tout ça ... et je sens bien que le côté "réécrire le fichier .cmd avec les modifications" promet des moments ... intéressants.

parallaxe ... foireux.

Petit test de scrolling parallaxe ce matin (entre vidange du garage et achat de papier peint) qui est encourageant sans vraiment être satisfaisant. C'est ma première tentative de charger plusieurs tilesets différents en mémoire, et je dois maintenant combiner une "infinimap" (dont l'image est modifiée au fil du scroll) avec une "wrapping map" (dont l'image reste fixe mais "tourne en boucle").

Les pommes sur fond blanc témoignent d'une petite réorganisation de la VRAM. J'ai réglé tout ça un peu vite à mon goût et il faudra que je prenne le temps d'ajuster le code pour qu'il fonctionne correctement sans dépendre d'effets curieux du genre "if bg==2 ...".

I wanted to bring the real (parallax) background in my woods this morning, but it didn't came as 'fluently' as i hoped in the code. Things were not quite ready for mixing wrapping maps and large maps, not quite ready either to host several tilesets in vRAM or to load an odd number of colors. I had to put ugly patches here and there to show the feature. A proper way to "split" SpriteRam in several banks is required in the future, as well as a real "WrappingMap" class and an update of the map-related script parsing functions. Well, anyway, even though my camera isn't as neat as Kram's, it's more "sexy" this way than with the dark-red background.

PS: since the demo is now released, now, it's time for a new "todo list", reusing wishes from the former one.

• [done] have the "level exit" activated when enough apples have been picked.
• [done] increase homogeneity of collision detections
• [done] pre-define values when initializing GOBs in script (e.g. set Funghi's counter)
  
• [done] blocking ennemies: e.g. you can't pass through Funky
• [done] bilou can tell whether he has been "hit" by an ennemy or an apple
• [done] code cleanup : upgradable "block info"
• [done] register "action on counter back to zero"
• [think..., done] substrate for "shooting" (dust clouds, stars, etc.)
• [wish] code cleanup: more states, more anims (array -> maps in GameScript)
• [wish] support multi-palette environment (by now, i'm just lucky it works fine !) or 16 color backgrounds
  
• [wish] provide a cleaner way to have parallax scrolling (and more maps)
• [done] make sure we can change/end level!
• [done] add sound fx support
• [wish] add music selection in the GameScript!
• [done] loading SpriteSet with odd number of colors properly
  
• [done] execute scripts non-interactively in demos.

Note: le parallaxe figurait dans mes "todo list" depuis décembre 2007 quand même ...

Moon walk ?

As seen in former post: Scripting Sunday:

TODO: moving Bilou through the animation isn't the right way to go. Maybe "delay x" in the animation sequence to have the next frame triggered only when we move to the next pixel would be better

Faire marcher un personnage est loin d'être une tâche facile et en particulier, ça demande une synchronisation parfaite entre le déplacement du sprite et son animation. Le moindre décalage et le joueur aura l'impression que le personnage "glisse" sur le sol au lieu de marcher. En clair, le pied en contact avec le sol doit rester au même endroit par rapport au sol jusqu'à ce qu'il se lève. Ce genre de défaut était assez fréquent dans les jeux de mon enfance (hein, Eric ;). Une manière assez simple d'y remédier est évidemment de faire courir le personnage, de préférence "à la supermario"

La solution que je pensais y apporter était relativement simple: intégrer les déplacements dans l'animation à coup de "move x y" entre deux images. C'est comme ça que je déplace le wooworm et ça réussit plutôt bien. Le hic, c'est de combiner ça avec une vitesse éventuellement variable et le test des collisions qui a été ramené dans le contrôleur (qui ignore tout de l'animation en cours).

I've never been satisfied by typical game-making animation tool that just let you define a constant moving speed (e.g. one pixel per frame) and an walking animation that you try to match that. It always gave me the feeling that the hero is "sliperring" on the ground or walks with rollers. I initially planned to fix this by integrating moves to the animation itself (i.e. 'show frame A, then wait for 2 frames, move by 2 pixels horizontally and show frame B'). That's how woodworm works, but i couldn't simply extended to Bilou's walk... Not until a friend of mine suggested that i could also delay the animation _until sufficient movement has been accumulated to 'hop' two pixels away_. Here comes the specific code that does that (only when the animation is "self-moving", which would be typical from ladder climbing, walking and other "friction-based" moves.

C'est Pierrick qui m'a donné la solution a mon problème en racontant comment du temps du CPC il faisait faire des sauts "réalistes" à son petit bilou en modifiant la durée d'affichage à chaque emplacement vu qu'il lui était impossible de placer le bilou (eh oui, c'était lui) entre deux tiles (pas de sprites en CPC basic ?). Plutôt que de chercher midi à 14 heures (du genre "modifier la vitesse d'écoulement du temps pour que Bilou coure plus vite"), j'ai juste changé l'interprétation de "move x y" en "ne passe à l'étape d'animation suivante qu'une fois que le contrôleur aura 'accumulé' le décalage suffisant. Traduit en code, ça donne :

inline bool trymove(int dx, int dy) {
    forcechecks=false;
    if (selfmove) {
        int cflags  = cast==HERO?F_PLAYERTHRU:F_MONSTERTHRU;
        bool notyet = (dx>0 && cdata[4]<dx) || (dx<0 && cdata[4]>dx)
                   || (dy>0 && cdata[5]<dy) || (dy<0 && cdata[5]>dy);
        if (notyet) return false;
        if (cando(dx,dy, cflags)==cflags)  {
            x+=dx; cdata[4]-=dx;
            y+=dy; cdata[5]-=dy;
            return true;
        } else {
            cdata[4]=0; cdata[5]=0;
            return setstate(state->dochecks(x>>8,y>>8,world, cdata));
        }
    } else {
        x+=dx;
        y+=dy;
        return true;
    }
}

• selfmove est défini par état : true pour monter à l'échelle, false pour tomber, etc.
• cdata[STEPX] et [STEPY] accumule les valeurs de cdata[XSPEED] et cdata[YSPEED] (vitesses définies par le contrôleur) en mode "selfmove" (normalement, on a directement x+=cdata[0])
• trymove(dx,dy) est appelé lorsqu'une étape d'animation utilse la commande "MOVE"
• condloop et check permettent de vérifier les testpoints sur des frames données (p.ex. quand le personnage a de nouveau les pieds au sol).
  

Voilà. J'avais envie de démystifier ça. J'espère que ça sera utile à l'un ou l'autre.

A pair of per-object variables (cdata[])will thus be used to accumulate some intended move until that "step" size becomes large enough for the move x y instruction found in the animation list. The trymove(dx, dy) tells whether such a move is possible right now or must wait until more motion has been accumulated.

edit: De manière étonnante, Miyamoto avait lui fait le choix délibéré, dès Donkey Kong, de casser le lien entre animation et déplacement parce qu'il jugeait qu'une animation de marche réaliste "ne collait pas à l'action frénétique d'un jeu vidéo" (l'Histoire de Mario, p.240)

2024 #choice reality check: It is still there, and I like how it makes many character feel like they're in contact with the ground. But let's be honest, it makes the code a bit more complicated every year. It makes it possible to have characters whose motion accelerates and decelerates over one step with a constant average speed, but offseting the graphics for a truly-constant-speed could achieve something similar, and that wouldn't even be complicated for a compound sprite. So there I am. Maybe this was not a good choice, but I haven't replaced it yet.

Le Bilou Nouveau est arrivé...

Comme promis, voilà la nouvelle démo de mon moteur de jeu. Ce n'est pas encore parfait, bien sûr, tant au niveau technique qu'au niveau graphique ou gameplay, mais ça vous permettra de voir faire une meilleure idée de ce sur quoi je travaille.

L'objectif est de récolter toutes les pommes du niveau, et un petit "GREAT" vous félicitera si vous en trouvez 16. Vous pourrez vous faire "blesser" (aussi souvent que vous le voudrez) au sol, mais pour l'instant, vous êtes invincibles en saut. Et il me manque toujours un fond convainquant.

Bref ... Work in progress.

Here you finally get it: a new demonstration of my game engine with my most up-to-date pixel art. It's not perfect, of course. Neither graphically, technically or in regards to gameplay. But at least it gives a better view of what i'm working on.

So far, your mission is to collect as much apples as you get (and you can get all of them in one row), a message "**GREAT**" will show you you've got 16 of them. Note, too, that you'll never get hurt while jumping. And yeah, it'd be much better with a background of some sort.

download gedsdemo.nds


PS: dans cette version, il vous faut toujours appuyer quelques fois sur "Y" au démarrage de la démo pour lui forcer à "lire" le script du niveau. C'est une de mes priorités de retirer ça pour la prochaine démo, bien sûr.

PPS: last update: 2009/05/20: Kram reported a bug on real hardware. Fixed.

Greetings fly to: NODA (efs lib), OxTob (ntxm), the devkitpro team, Kram (DS2DS), CJ (R4), Pierrick & Tbob (music), lackey, victorX, pixelaroo, arachne, zeid, Helm and many more pixel pushers at Pixelation for artistic advices, sourceforge & blogger for project hosting.

Suivre le développement du projet ...
Read progress reports

Game Engine progress report

Bonne nouvelle: le mécanisme de gestion des collisions entre sprites (re)prend forme. J'avais déjà fait quelques tests dans la version précédente, mais cette fois-ci, la réaction aux collisions peut être programmée: Bilou sursaute lorsqu'un ver le touche mais il peut écraser le ver en question en lui sautant sur la tête, comme dans Mario.

Good news from the Game Engine: sprite-to-sprite collisions management is (re-)enabled. I already had a former release where the screen flashed to red when Bilou hit a monster, but this time i can script the desired response to collisions. For instance, Bilou will be "hit" when touched by a Woodworm, but he can stomp the same woodworm by jumping on its head.

Il y a encore un peu de boulot avant de pouvoir faire une "release" de la nouvelle petite démo:

• [wish] increase homogeneity of collision detections
• [done] have apples animated once again
• [done] have Bilou collecting apples
• [patched] more states, more anims (array -> maps in GameScript)
  
• [wish] have the "level exit" activated when all the apples have been picked.
• [done] rationalise memory use in libntxm (less mallocs/realloc) and track array overflows

Et au passage, il faudra aussi que je fasse un peu le ménage côté "gestion de la mémoire". La libntxm étant au départ prévue pour un éditeur de modules, elle a tendance à faire des reallocs dans tous les sens (trop souvent source d'erreur à mon goût) et j'ai régulièrement des pointeurs qui sont devenus (?) invalides au moment de la destruction du mod en cours.

(wishes and cleanups kept in the current todo list)

Scripting Sunday

Didn't quite got as far as i hoped in my "coding sunday", so it has rather be a "scripting - and - guru - meditation" sunday instead. Most has been done through state machine scripts or within Sprite/Level editor on the DS ... but some code will have to change. I cannot keep Bilou walking through walls or in the sky, can I ?

C'était un dimanche bien rempli donc, même si je n'ai pas vraiment coder autant que je l'avais prévu. Entre le bricolage de la machine d'état qui gère Bilou, les nouvelles animations et la construction d'un premier "niveau démo" avec les tiles que j'ai dessiné pendant l'année 2008. Pourtant, il faudra que j'y passe. Il y a quelque-chose de fondamentalement foireux dans le couplage "animation/déplacement" qui permet à Bilou de marcher à travers les murs ou dans le ciel ^^"

got the GameScript understand multi-set spritesheets (with one set for tiles and one for monsters all in the same file)

got Bilou walking animation done

bilou walks up/right, jumps and fall

sketched a little level for those new tiles i've been working on in 2008 ^_^

figured out that i'm still missing *many* tiles and a lot other tiles are unusable ^^"

fixed so weird memory things in libntxm, but i still have data corruption happening. Maybe a checksum of some internal arrays will help ... or replacing arrays with std::vectors somewhere ...

had fun with sprites on "mid" layer. Bilou can now hide within tree, so can woodworms :P

STill to do:

• [done] testpoints should be checked at every frame, not just when the animation loops
• [done] moving Bilou through the animation isn't the right way to go. Maybe "delay x" in the animation sequence to have the next frame triggered only when we move to the next pixel would be better.
• [done] check my own code for things that might corrupt libntxm's internal state. (identified some memory leaks, but no buffer overflows or double-frees)
• make sure we can see Bilou's feet on grass
• [doc] let animated blocks work with "extra tilesheets"rather than copying sheets "as needed".
• [done, leds] ignore extra sheets in the level editor (rather than just showing empty sheets)

spraddpage et compagnie.

Bon, puisque SEDS est "réparé", j'ai essayé de ramener l'entièreté de mes graphismes vers la DS. Certains avaient été faits sur la DS de mon frère (l'appleman, par exemple), d'autres sont des retouches dans Gimp, d'autres encore viennent du "vieux" jeu de tiles (oui, oui, celui qui a tout explosé en dépassant les 1024 tiles ;)

Découper, aligner sur la grille, rogner, convertir, re-convertir, compresser les palettes, transférer, fusionner, re-transférer ...

Je vous donne un petit aperçu en image de ce que ça donne, simplement pour fusionner un .spr qui était sur la DS et une image .png déjà préparée qui traine sur le PC ... puis je vous laisse imaginer le tableau quand il faut répéter l'opération avec quatre sources différentes ^_^

Ennfin. Je crois n'avoir rien perdu ni oublié dans la bagarre, ce qui relève presque de l'exploit !

1036 tiles is far too much.

J'ai foiré. Vendredi soir, j'ai voulu pour rire animer une petite touffe d'herbe en plus de mes pommes et après avoir sauvé, vlan, plus rien. Je ne panique pas et je démarre le moteur de jeu qui refuse de charger le niveau avec le message "1036 tiles is far too much". Argh! J'avais oublié ... A force de dupliquer des pages de sprites pour faire des essais, etc. J'étais arrivé *tout juste* à 64K de graphismes, ce qui correspond à la limite que j'avais imposée pour rester dans une gestion toute simple de la mémoire.

Bon, le problème sera vite résolu dans l'éditeur de niveau (qui était de toute façons prêt à gérer 256K de graphismes, c'est juste un oubli), mais pas en ce qui concerne le moteur de jeu. Il va donc falloir que je fasse le ménage mais pour l'instant, SEDS est complètement dépourvu de toute fonction "effacer". On peut dupliquer, ajouter, remplacer par un bloc complètement transparent, mais effacer, ça, non.

Oops. Trying to animate the grass in Bilou's woods turned out in no fun at all when the game engine refused to launch the game with "1036 tiles is far too much" error message. It seems like i forgot that i just reached the 64K of pixels the day before (well, out of which only roughly 1/4th of the tiles need to be kept :P) ... Patching the Sprite Editor to let it edit the spritesheet again was trivially easy, but it won't help as there is so far nothing that *deletes* data in my sprite editor ...

Du coup, je me suis fait un nouveau petit "plan de bataille" pour y remédier:

• [done] remise en route des "fichiers backup" en cas de sauvegarde
• [done] construction d'un "fichier archive" lorsqu'on remplace un des fichiers de travail par un nouveau tileset (p.ex. importé par WiFi)
• [done] une petite mémoire "undo" et un bouton pour rappeler sur la grille d'édition le dernier bloc "écrasé" lors d'un enregistrement dans la "SpriteTable"
• [done] ajouter la possibilité d'avoir un "bloc manquant" dans la SpriteTable, pour effacer des blocs tout en conservant l'alignement général -- et réorganisation des tiles contenus en conséquence.
• [done] effacer toute une page

Ceci fait, je devrais pouvoir 'réparer' ma p'tite forêt. Ensuite, eh bien, il sera temps de penser à la possibilité de séparer les tiles à charger directement en VRAM de ceux qui restent "dormants" en mémoire centrale (p.ex. pour les animations)

Une nouvelle démo

Bon, une petite anim' enregistrée et un nouveau petit .nds autonome pour que vous puissiez tester les amélioration de mon moteur de jeu sur votre DS à vous. Au programme, le nouveau scrolling , la gestion des collisions , les test-points conditionnels (avec moins de bugs dans la gestion des déplacements de Bilou).

Bref, faites-vous plaisir: téléchargez la "ROM" ;)
le programme va démarrer et afficher "Ready." sur la console, sur l'écran du haut. A ce moment, appuyez plusieurs fois sur Y pour exécuter le niveau pas à pas jusqu'à ce que Bilou tombe. Vous pouvez alors le diriger avec le pad. Vous pouvez aussi changer de méthode de scrolling en appuyant sur START.

Here comes a new demonstrator of my game engine, so that you can test the latest improvements on *your* DS : collision management, conditional test-points, new scrolling ... So stop hesitating and start downloading. Once launched, the program will display "ready" and then wait for you to press 'Y' button half a dozen of times to perform step-by-step initialization of the level. As soon as Bilou starts falling, you can control him with the D-pad. You can also toggle the scrolling algorithm by pressing "START".
Les bugs connus:

• lorsqu'il retombe sur le sol, il arrive que Bilou se mette à glisser sans s'arrêter
• si Bilou heurte un mur en saut, il y reste "scotché" tant que vous gardez le bouton "gauche" ou "droite" enfoncé
• quand Bilou n'est qu'à moitié sur une plate-forme, il "tremble" et l'écran du haut défile à toute vitesse. (ce n'est pas vraiment un bug: je n'ai pas encore d'animation pour le montrer en déséquilibre)

PS: il va falloir que je chipe le R4 de mon frère par contre. J'ai régulièrement des testeurs sur dev-fr qui m'indiquent que mes roms ne marchent pas chez eux, et là, en principe, c'est tellement simple que je ne vois pas ce qui peut ne pas marcher. Le DLDI, peut-être ?

edit: j'ai retiré le lien vers la version "efs2.0", qui ne résout apparemment rien pour les utilisateurs de R4. J'ai visiblement un problème avec le code ARM7 qui ne fonctionne pas comme prévu. Investigation en cours ...

my little world ... [please C&C]

Hello, all. I'm working on a little "green zone" for a homebrew platformer project on the nintendo DS. I'm a bit "on my own" for the art and code, without a strong artistic background nor digital painting / pixeling guru around in real world, so you guys are my best chance to come with a cute and great world for the game.

So C&C are (more than) welcome. the tree tops which still comes from Zelda: Minish Cap.

time-travel note: This is more or less how I presented my little demo to the people on Way of the Pixel ... But it was common on that board to update your front post as you make revision to your piece, so it might not be all they've seen. Likely I also posted the animated gif with Bilou bouncing on the ground that came with the demo. You've got the context for the "Even less interesting than kirby" post, now.

Voici donc comment j'avais présenté mon travail sur le forum d'artistes "Way of the Pixel" aka "Pixelation". ci-dessous, et l'image avec le texte qui l'a ensuite accompagnée. Je la reposte ici à la date où elle avait été postée là-bas. Par les pouvoirs du voyage dans le temps bloggique !_!

edit: managed to find the original capture on archive.org, with the pixelated theme the forum had back in August 2008 and the initial text:

Here's my little "green zone" for my platformer project on the nintendo DS. Sorry for the "trailing pixels" : this is actually a capture from the emulator (so i don't control everything).

Almost all art is from me (on my own sprite editor, still on the DS ) except the tree tops which still comes from Zelda: Minish Cap. I'm working on a replacement, but i can't come with something satisfying enough so far...

Ca, c'est fait.

Voilà, maintenant runme parvient à me charger des niveaux sur deux plans de tiles, et il scrolle dedans assez allègrement, ma foi. J'en ai profité pour ajuster le code de gestion des ennemis qui se servent du coup du "plan d'informations" (meta-layer) pour savoir s'ils sont dans un mur, sur le sol, dans le vide, etc.

Tout ça a finalement été beaucoup plus facilement que je ne l'avais imaginé ... Et, bande de p'tits veinards, je vous ai fait toute une démo de la chose en vidéo sur youtube pour la postérité, le tout commenté par votre serviteur.

It's not always easy to give you a correct idea of what my game development environment on the DS look like ... and it's certainly not easy to "show" how animations work with ... screenshots. So i decided to take the time to shoot these small videos where i'm doing some simple editions on my demo-level for Bilou's forest, swapping from the game engine (runme) to the level editor and back. It's commented in french, and unfortunately very blurry, but it's there.
And it means i now have dual-plane level scrolling in the game engine, with sprites that use per-tile metadata to tell the level properties (rather than just using tile numbers, obviously allowing secret passages) and animated bonuses ^_^

Bon, ceci dit, tout ça ne nous rendra pas la maison plus en ordre, donc j'vais m'atteler un peu au rangement de tout ce désordre qui s'est accumulé pendant mes scéances de crazy-coding. Restera à faire bouger les pommes ^_^ C'est fait aussi :P

Level Editor on DS : première photo !

Le voilà! J'ai enfin une photo potable de mon LEvel Editor (dont la plupart des "bêtes bugs" sont maintenant corrigés). Reste à améliorer son ergonomie (parce que là, on choisit son bloc "en aveugle" et pour peu qu'il faille un peu scroller, on attrape vite des crampes avec ces L+<direction>).

At last! Here's the first picture of my Level Editor. Most of the "stupid" bugs have been fixed and all i have to do is adding features (most notably saving your work) and improving the user interface. Switching from sprites to tile for the "available blocks" on the upper screen now allowed me to have up to 144 blocks immediately available (you can also select other 'pages', but page flipping may get annoying).

Btw, building levels on two layers is fun, and allows lot of amusing hacks such as using treetops as bushes in front of (or behind) other objects. I also intend to have a third "virtual" plane for collision information, so whether something is a wall or not is completely independent from whether you see the wall or not (and whether you have something in from/behind it). That means you can build your wall of dirt with the dirt being sometimes behind grass, and sometimes in front of (deeper) dirt. All this with only two planes.

Bon, évidemment, je n'ai pas encore de sauvegarde, donc c'est un peu idiot, mais ça permet déjà de se faire une petite idée. J'aime bien les sommets d'arbres "retravaillés" en buissons, tiens... Reste donc:

• à pouvoir sauver son travail
  
• écrire un petit widget "curseur" pour savoir quel bloc j'utilise
• passer les blocs de l'avant plan en transparence pendant qu'on édite l'arrière-plan
• deux modes de dessins : "un bloc à la fois" ou "tout un objet" (en cliquant sur des positions consécutives dans la map, on copie des blocs consécutifs du tileset, plutôt que de répéter tout le temps le même bloc. Ce sera chouette pour les arbres.
• un mode "survol", pour se déplacer rapidement dans la map ...

Et bien évidemment, il faut que je rajoute la gestion des "méta-données" qui indiquent si un bloc et bloquant ou non, s'il s'agit d'un bonus, etc. Mais c'est déjà un bon début.

Appleman

Petit passage dans le bureau de Cyril avant la pause-café... De temps en temps, quand Cyril n'est pas pret, j'en profite pour gribouiller un peu. Ici, c'est l'appleman de la foret de Greenwoods qui y passe. Une petite version "toute normale" d'abord, puis à force (et c'est tout l'intéret du tableau blanc), je me lache un peu et j'essaie des nouveaux concepts...

Premier dans la série : le parapple, un tantinet inspiré par les parakoopas et autre paragoombas de Super Mario. Tombant des hauteurs des arbres, voilà un appleman plus difficile à éliminer, vu qu'il ne suffit plus de sauter dessus. Enfin, si, mais à condition d'y parvenir. On pourrait meme doser la difficulté en lui permettant d'abandonner subitement son parachute si Bilou passe par-dessous.
On peut voir que je m'étais d'abord orienté vers un parachute "normal" avant de prendre ... une feuille d'arbre. Plus sympa, selon moi.

Poursuivons dans la série des délires. Les chauves-souris jouent un role essentiel dans le level-design de la foret. Le hic, c'est que leur concept à elles n'étaient pas terrible. Les "bubble-bat" en mauve et bleu de la version basic ne sont plus vraiment adaptées au jeu depuis que j'ai laissé tombé le bubble-dragon, la tic-tac-bombe et autre escargot-turbo des premières esquisses de Piet et Pierrick... Bref, en écoutant un morceau (virt+beek) nommé "fruitbat", j'ai eu l'idée de transformer nos pommes aussi en chauves-souris. Evidemment, ça ne volettera pas très bien, mais ça ne me dérange pas.

spr2html ^_^

Il parait que j'ai tendance à utiliser HTML pour tout et n'importe quoi ... j'ai bien peur d'avoir remis ça ... J'avais bien un petit script capable de transformer une image (de préférence un niveau de jeu) en un 'SpriteSet' (que j'utilisais pour les tests de scrolling), mais jusqu'ici je n'avais rien d'équivalent pour le sens "retour".

Et comme j'ai un peu la flemme d'écrire des pixels sur une image .png, je me suis plutôt tourner sur une jolie petite table HTML. Avouez que le résultat est plutôt réussi, non ? bon, évidemment pour l'instant on ne voit encore que les "tiles" un par un, tels qu'ils sont dans la mémoire vidéo, mais encore un peu de chipotage, et je pourrai les voir par "bloc" de 16x16 ...

De quoi simplifier les procédures de conversion de données que je vais devoir faire... Parce que là, sans un éditeur de map, je n'irai pas beaucoup plus loin. Animer les pommes qui n'utilisent pas des tiles consécutives. bof.

So far, the tiles you edited with SEDS could only be opened with SEDS (or shown on your DS screen through the 'runme' companion program). That was true until yesterday. Here comes the "spr2html" converter tool that can turn those "opaque" .spr files into a bunch of HTML tables that show palettes and tilesets contained in the spriteset. So far, it is mostly a debugging tool for the other manipulation scripts (merging sprite sheets, converting colors, etc) that prooved to be more efficient than beaming files to the DS and back, but it should be quite trivial to upgrade into a full-featured "exporter" that would produce .png pictures straight out of my .spr files...

edit: et je me rends compte de la raison des palettes "toutes mélangées" que j'ai obtenues dans mes "livres de sprites" qui rassemblent plusieurs planches séparées: je comptais les couleurs 1,10,11,...,19,2,20,21, ... 29,3 ... à chaque étape, alors forcément, quand on répête ça, on finit par un jeu de couleurs tellement mélangé qu'on est prêt pour une petite belote :P

oh, for those who wonders, i've used the "bgcolor" attribute of "td" tags and and solely filled my table cells with to ensure they'd have the proper size. That doesn't seem to please all browsers around, but as long as one of them (konqueror, but not firefox) renders it fine, i'm happy.

demi-tour, marche!

Et voilà. Le mécanisme des "testpoints" est ajouté. Avant de recommencer chaque étape d'animation, mon petit ver s'assure qu'il ne rentre pas dans un mur et qu'il ne tombe pas. Je ne suis pas certain que ça conviendra pour tout le monde (Bilou, en particulier).

Il faudra aussi que j'automatise le demi-tour (pour l'instant, le ver s'arrête au bord, et je lui fais faire demi-tour "à la main" en programmant la deuxième animation.

edit: yes! le petit ver est maintenant entièrement autonome et toujours avec un code 100% générique. Une petite machine d'état avec des animations de "pause" entre les allées et venues, et ça y est. Et je peux en mettre autant que je veux! il suffit de rajouter une ligne dans test.cmd ;) Etapes suivantes:

• animer les pommes
• désactiver/réactiver les OAM quand ils sortent de l'écran
• passer *réellement* à deux plans pour l'affichage du décor
• scrolling parallaxe
• (post-posé: animation composite pour Bilou).

J'ai aussi commencé un nouveau graphisme pour Bilou: là, je le trouve vraiment trop petit par rapport au "reste du monde".

Got the testpoints support added. Before playing the 'walk' animation again, the woodworm will check it wouldn't enter a wall and wouldn't fall down. It might not work for every entity (clearly not for Bilou), but it does the job here. Adding a turn-back ... there we are. Fully autonomous entity patrolling on a platform with completely generic code. First state machine ever, and I can replicate them here and there by just adding one line in test.cmd file.

Un autre arbre pour Bilou

Je me suis fait une petite scéance de "speed-pixels" ce midi. On ouvre the Gimp, on récupère les couleurs de la forêt de Donkey Kong: King of Swing et c'est parti.

L'idée, c'est de faire vite et de mettre les éléments en place: ils seront retravaillés plus tard dans mon sprite editor, mais ce dernier n'est pas encore très pratique quand on veut rapidement entasser quelques gros ronds pour faire une forme de feuillage (à noter pour plus tard, en blanc sur bleu, ça aurait pu faire de beaux nuages) ou les formes étirées du tronc d'arbre.

J'en dirai plus plus tard, mais je crois que c'est un bon début...

Le commentaire de Pierrick ...

J'avais envoyé le mockup de l'arbre à CJ et à Pierrick avant de le poster ici. CJ a répondu en direct, ce qui vous a d'ailleurs valu un passage en revue de tous les arbres trouvables dans des jeux vidéo. Quand à Pierrick, il m'a fait remarquer ce matin ceci:

Le trou dans ton tronc n'a pas de profondeur
On dirait que ton arbre est une feuille a cigarette
Pour arranger ca , je te propose de faire un arc de cercle de 2 ou 3 pixels dans le coin supérieur droit du trou avec un dégradé du clair au foncé puisque la lumiere vient de gauche
Mais sinon pour les autres trous c'est pas grave parce que le fond théorique des cavités est plus loin dans la roche.....

Mais une épaisseur de tronc ca se voit dans le trou normalement

Quand il est prit sous cet angle

Sinon .... soufflant ....

Pas évident, hein, quand on a pas l'image juste sous les yeux... Allez, je vous fait un "avant/après" (attention, j'ai mis l'image d'après à gauche de celle d'avant).

Bigre, c'est qu'il avait raison, le bougre ... ça donne bien mieux avec quelques pixels plus dans un coin ... et comme j'ai d'abord compris de travers de quoi il voulait parler, je me retrouve en prime avec une ombre portée sur le fond de l'arbre ... Plus que ça, c'est rajouter une tête de hibou dedans ... Hehe ... Avec les options "crayon ombreur" et "crayon éclaircisseur" de SEDS, ça va tout seul ^_^

Encore merci, vieux. Même après toutes ces années, tes conseils en pixels sont toujours aussi précieux et à propos...
Hey, il y a plus de 10 ans, il m'apprenait déjà des trucs pour faire des ronds ronds.

I got a mail from Pierrick this morning, commenting on the tree i'm planning to use in Bilou's forest and in Apple Rumble. He said the hole in the hollow tree isn't right: it has no thickness... If you look at such a tree with that angle, you not only see the hole, but also the thickness of the wood that is still there. The way it is drawn on the right makes it look like the tree was as thin as a sheet of paper -- unlikely to be what i want it to look like... And he was damn right!

It took me some time to exactly understand what he meant (it's not that easy to grab someone's comment on your drawing when you can't see him pointing at what his mind looks), so not only you have trunk thickness now, but also shadow casted inside the hollow trunk. That with the small mushrooms give an overall look that i like quite much better.

The only thing i could still do imho to improve it would be to put an owl head in the hole.