Monsters & Levels.

Le week-end s'achève, et c'est une semaine plutôt exigeante qui se profile à sa suite. Du coup, je fais l'annonce ici et maintenant, plutôt que de passer mon lundi à essayer de ne pas la faire pour ne pas me laisser distraire dans mon travail.

Ca y est, la lecture des fichiers .cmd et l'édition de la position des monstres a été intégrée au "véritable" éditeur de niveaux. Comprenez: celui qui me permet de manipuler les fichiers utilisés par le moteur de jeu, pas juste un .nds créé pour les besoins du débugging.

Howdy! The 'real' level editor can now parse monsters position, move them around and alter the initial state of each GOB, and save the resulting 'commands' file that can then be played by the game engine in runme. That's pretty much a milestone, even though most of these features were already available in "debugging packages" for a specific level. With a few template file uploaded to the DS, I'll now be able to populate the green woods with tiles and sprites to move towards a more complete "Bilou Mining" demonstration game that could fill more than 3 minutes of game play. A good thing, since you seem to prefer this to all the alternatives that came to my mind lately.

here you go: cj-leds.nds
special "Bros. Birthday Release"

C'est une belle étape, qui -- moyennant envoi de quelques fichiers "template" vers la DS -- me permettra de construire des p'tits niveau avec monstres incorporés en "ambulatoire", quand je peux, ou je veux. Comme vous avez majoritairement marqué votre préférence pour "Bilou Mining" (c.à.d. le prolongement de la démo telle qu'elle existe actuellement), ça sera des plus appréciables.

PS: I hope you don't mind the "recycling" of sketch between the comics' blog and the coding blog when I'm short on time to shoot a screenshot or something alike...

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

Days left to vote: 4

Avis à ceux qui suivent ce flux uniquement par RSS, vous n'avez probablement pas remarqué le petit "sondage" sur les différents mini-jeux candidats pour la prochaine milestone. Il reste 4 jours pour voter.

Clickez ici pour relire le post et enregistrer votre vote

You may be reading this with a RSS reader, in which case you've likely missed the "poll" that came together with my previous post on the candidate mini-game for the next milestone. You've got 4 days left. Go! Go! Goo!

MonsterWidget ou MonsterWindow ?

Bon, voilà. J'ai fini de me créper le ch(amp)ignon avec "j'ajoute une fenêtre ou juste un widget". J'ai rajouté une fenêtre, et je peux commencer le "vrai" boulot, à savoir sélectionner, déplacer, dupliquer mes monstres, et tout ça. Si je me suis planté, ben au pire, vous me lirez râler d'ici peu. J'avais commencé à rédiger toute une tartine sur les options possibles, etc. mais finalement, je n'ai pas du tout suivi cette approche. Ce sera donc pour les plus English d'entre vous.

Well, finally i opted for giving monster edition its own, full-blown window "stacked" over the regular level editor. I've been struggling with OO design, once again. It's getting sort of a habbit. At last, I can start with "real" coding: positioning monsters over a level. I guess if I've been mistaken, you'll read me complaining about the odds of OOP once again :P Here follows the rant about the possible alternative that has not been retained.

The GUI of ?EDS tools mostly consists of "windows" through which you navigate. "Window" is a poorly chosed term, i admit. It should rather be "screens" or "layers" (since you can overlap them) that acts as container of widgets and contains the "application-specific logic". Again, the GUI toolkit is "in-house" development and grows together with the apps that grow together with the game projects.

When extending my applications on the DS, I recurrently stumble upon the same problem: I need some widget to be drawn or not, to receive events or not depending on the "application state". An obvious example is the "pop up buttons" I've added to the level editor recently. Another one is the "edit" button of the level editor's main window that only appear once you've got both a tileset and a map loaded in RAM.

I don't have (yet) a very clean and satisfying way to handle such situations. I mostly take advantage of the sequential testing of widgets within a window and alter Window->nbWidgets at run-time to make widgets appear or leave. I typically "snapshot" nbWidgets at various spots in the window initialisation code so that I can later "enable" a widget with something like

 void update_edit_buttons() {
 if (level->isready()) {
   nbWidgets=showedit; // show [edit] button.
   edit->render();     // force redraw
   // ... more actions if needed
 }
}

It is not alway possible to make it "that simple", though. Sometimes, the new widget will "shadow" an existing one. Edition of tile properties, for instance, needs the "regular" map to be drawn (a MapWidget), but additionally, the MetaLayer (widget that manipulate meta-information) and the MetaButtons (widget that let you pick a specific block type from a panel) become present. Plus, the MapWidget should no longer receive any event to prevent mess up of tiles graphics while editing tiles properties.

I then maintain metamap and normap, two copies of the window's nbWidgets that indicate the respective indexes of the MapWidget and MetaLayer. Window::swap(i,j) can help me moving around objects in the widget list so that we change the priority of both widgets. But this is tricky to extend cleanly to a "third state" as required for monsters positioning. Most likely, I'll have to keep track of the "current state" better than through the value of nbWidgets, and I'll need a reset_widgets() that returns from any state to the default (post-ctor) state so that I can properly alter stuff.

The alternative would be to add "hidden" and "disabled" states explicitly into the GUI engine, so that it can "skip" some objects.

Hopefully enough, the GUI engine also supports "stacked" windows where you can add a layer of widgets on top of another one, but it's a bit overkill to do that for every "dynamic" widget of a complex window. It *does* help when not only the display of a widget, but the whole controls layout (DPAD and physical) is redefined in the new state.

Get ready for the flood!

Flood-fill in a painting program is usually the thing that makes users happy and coders unhappy. It's not a trivial task comparable to e.g. filled block rendering. It's more like exploring a dungeon: when you face a room with three doors and you select the one on your left, you also need to mentally keep track that you should come back and visit the door on the right and that one in the middle afterwards. A computer can do this "mental track" with a data structure that looks like a todo list. It's manageable (unless you're in an odd language like the QuickBasic I used for my early sprite editors), but in evil-designed "dungeons", it may require you large amount of RAM, and with a sufficiently large-and-evil dungeons (pictures, should I say), you might very well run out of memory when "painting". It used to happen from times to times with Deluxe Paint II.

"Vous êtes dans la salle principale du donjon. Trois portes se présentent devant vous: une sur la gauche, une sur la droite, et une au centre... Laquelle allez-vous ouvrir". Bien connu des rôlistes, c'est aussi le genre de dilemme que doit résoudre votre programme de dessin chaque fois que l'artiste utilisera l'outil "remplissage".

Ce qui explique en partie qu'il n'y avait aucun outil de ce genre jusqu'ici dans SEDS: pour le réaliser, il faut maintenir une sorte de "todo list" des salles (pixels) à re-visiter plus tard et des directions qui y restent à explorer. C'est pénible, et on ne sait jamais trop bien quelle quantité de mémoire ça va demander. Deluxe Paint II me gueulait régulièrement dessus pour cette raison. Bon, avec 4Mo de RAM et une image en 32x32, ça ne devrait pas être la fin du monde, mais ce n'est pas marrant pour autant.

Mais j'ai trouvé une astuce pour contourner la difficulté: la DS fait la moitié du travail: remplir horizontalement uniquement, en s'arrètant sur les bords, et l'artiste fait l'autre moitié : balayer verticalement de son stylet la zone à remplir. Eh oui, c'est comme ça: les programmeurs sont des feignasses. Il faudra vous y faire. On verra à l'usage si ça suffit.

I figured out a few days ago that there was an "easy way out" for that situation. Rather than having the CPU doing all the job, I can safely share the job between the user and the CPU: The user will point out regions that needs to be filled, and the CPU fills them one scanline at a time. That is, to flood-fill a rectangle as the one depicted, you'll have to swipe it bottom-up (or top-down ;-) with the "bucket fill" tool (L+B). Pick another color and swipe it "not quite up to the corners", and you'll obtain something like the picture shown.
When there are "holes" in the border, the fill just "evades" horizontally, rahter than flooding the whole outer area as you'll usually see in painting programs.

So why don't you download the "nightly build" and give it a beta-try yourself ?

Super Princess Peach

Il faut l'avouer, elle est de toute beauté, la princesse champi, avec son pixel art parfait et son style épuré en ligne droite de la série de RPG "Mario & Luigi". Comme mon frère me re-prète sa cartouche, c'est l'occasion de comparer mes impressions aux siennes.

"Le gros soucis de ce jeu, c’est qu’il y a trop de choses !"

Des pièces pour acheter des nouveaux objets (dans mon cas, des parapluies plus perfectionner pour taper, planer,…) puis il y a des petits coeur à ramasser pour reprendre de la vie, et aussi des crystaux pour utiliser l’une des 4 magies possibles pour la princesse

Et pourtant, ça ne fait que 3 types d'items dans les niveaux. Supposons que Peach soit plutôt Duke, ça fait une barre d'énergie, une barre de munitions et des crédits pour acheter des power-ups. Les boutiques à Power-Up, c'est classique dans un platformer. Mickey Magical Quest comme Adventure Island le proposait. La subtilité de Peach est d'avoir cette boutique ouverte en permanence, accessible hors des niveaux. En plus des parapluies, on y retrouvera aussi les "fragments de coeur" et extensions de la barre de magie qui ne devrait pas dérouter ceux d'entre-vous qui ont joué à Zelda.

Trop de mouvements

A coté de cela… La princesse peu tuer les enemis en sautant dessus, en les frappant de son parapluies, en les attrapant et les projetant ou en les donnant à manger à son parapluie (histoire de regagner des pouvoir magique). Elle peut également transporter des trampolings histoires d’aller tenter quelques sauts plus haut à gauche ou à droite ou faire de courer/glisser pour butter les monstres et passer en dessous des blocs…

A l'exception des pouvoirs magiques, tu remarqueras que l'ensemble des mouvements que tu décris correspond à ce que Duck Tales permettait. En donnant un grand nombre de mouvements d'attaque, les concepteurs du jeu ont réduit les "zones de risque" pour Peach.

Le seul véritable danger, c'est que le ciel lui tombe sur la tête, en quelques sortes. De plus, presque tous les ennemis sont vulnérables à toutes les attaques, c'est donc entièrement une question de style de jeu (préfères-tu passer à travers tout en assomant les ennemis d'un coup de saut ou attendre qu'ils arrivent à ta portée pour les dégommer d'un coup de canapluie bien placé). Mon seul véritable reproche s'adresse aux carapaces de Koopa: pour un fidèle à Nintendo, le premier réflexe est de vouloir les transporter pour les lancer à l'occasion sur une série de monstres, mais la manip pour y parvenir vient rarement toute seule.

Bref, à tout moment, vous pouvez être en mesure de faire un choix parmi tout cela ! Pour corser un peu le tout, je trouve que les entrées dans les tuyaux sont mal gérées…

J'admet pour les tuyaux. C'est particulièrement désagréable de devoir faire un ajustement de précision pour une chose aussi élémentaire que passer à la suite du niveau. D'autant plus ridicule que les portes, elles, marchent sans problèmes.

Pour ce qui est des choix, un jeu intéressant *doit* offrir des choix. Dans Super Mario, où tu es contraint par le chrono, ce sera "est-ce que j'essaie de démolir cette structure pour trouver des bonus ou est-ce que je continue vers l'avant". Dans Commander Keen (niveau de difficulté normal) ce sera "je ramasse les bonus, ou je préfère ne pas prendre le risque de passer sous le champignon ?". Dans Prehistorik II, "Si j'arrive à dégommer cette saloperie de tigre, il me rendra mes os, mais si je le loupe, il me prendra un 2eme coeur".

J'utilise la magie ou pas ? et laquelle ?

On touche au coeur du problème. Peach n'est pas un jeu d'adresse ou d'endurance comme pourrait l'être un Mario. C'est un jeu d'exploration. Une sorte de puzzle où il faut apprendre à "lire" les indices

• trois pièces d'or alignées verticalement et un cristal magique au bout : 'faut voler, mon gars ...
• des trucs bleus dans le chemin ? une roue à aube ? Pleure un coup: ça ira mieux.

Le génie des concepteurs de SPP, c'est d'avoir en fait utilisé les 3 des 4 éléments (eau, feu, vent) sous le déguisement des émotions. Or c'est quelque-chose avec lequel nous sommes habitué à vivre: le feu brule, le vent souffle, etc. Une fois ce "grand principe" acquis, on ne se demandera plus que faire face à un nouvel élément dans un niveau . A mon avis, bien plus accessible que les quatres pouvoirs des tinies dans Fury of the Furries.

Et comme tous les platformers de Nintendo, ces actions supplémentaires (généralement destinées à sauver des Toads) sont facultative. L'exploration est récompensée, encouragée par le débloquage de chanson, etc. mais pas indispensable, là où Commander Keen ne saura pas finir le niveau à moins d'avoir collecté les clés appropriées et dans le bon ordre s'il vous plait.

Tu noteras aussi que tout (ou presque) est interchangeable dans le jeu, puisque tu peux convertir la magie en énergie, et l'énergie en magie (en prenant le risque d'attraper les ennemis pour les faire manger au parapluie). "Peach never dies", à moins que le joueur n'ait mal jugé de sa situation présente (plus assez de coeurs ou manque de magie). Il n'y a même pas de compteur de vies! On comprend mieux du coup le rôle des pièces d'or, puisqu'il n'y a plus de 1UP à obtenir au bout de 100 pièces. Logique, d'une certaine manière, le joueur n'ayant plus à mettre des pièces (de 20Fr) dans la machine pour acheter plus de vies (cf. nos vieilles bornes d'arcade). Mais dans les jeux nintendo, les pièces servent surtout à guider le joueur, l'entrainer vers des chemins plus risqué et le récompenser.

Puis dès le départ, une intro assez longuette, et un mini-jeu range champignon tout à fait inutile... Bref nous voilà arrivé dans un premier stage “tutoriel” peu accrocheur…

Là, je rejoint l'avis de mon frère. D'autant que dans un jeu d'exploration qui proposait déjà des "pièces de puzzle", il aurait été aussi intéressant (imho) de mettre ces ingrédients en "bonus accessibles à la demande". Fragments de journal du Commandant des Koopas Troops, etc.

Une zone du feu où il fait chaud, une zone des glace où ... ça glisse !

Commentaire d'un reviewer du jeu à sa sortie que je ne pourrais plus vous retrouver. J'avoue, SPP ne brille pas par l'originalité des mondes qu'il nous fait traverser. D'un autre côté, glisser pour glisser (quoi qu'on en dise, c'est un canon du jeu de plate-formes), autant que ce soit sur de la glace dans le monde des glaces plutôt que sur de la chantilly dans le monde des jouets ou sur de l'huile dans le monde des robots. Au moins, peach-de-feu peut la faire fondre, la glace, et peach-qui-pleure peut en faire apparaître là où il n'y en avait pas. Ca donne lieu à quelques puzzles sympas. Les moulins à vent et à eau des premiers mondes n'auront donc servi que de "déclencheur" pour ajuster l'esprit des joueurs à celui du jeu, et c'est tant mieux.

Bilou Dreams : Clone it !

As I said earlier, while the final "Bilou" project is a story-supported large platformer (yeah, think of Rayman vs Mr. Dark, you've got it) with a supporting game-making toolset, I know from my experience that I must split that down into chewable chunks unless I want to drop the project before anything is realised. The current "milestone" is a "explore, collect, think, collect, finish" game. The equivalent of Manic Miner or similar 8-bit arcade platformer But there are a few other things I think/dream of, while "sticking Bilou" as decided. Figures near each game title are the votes you have casted during the January Poll

Bilou sera un jeu de plate-formes. 8 zones différentes à explorer, des batailles épiques contre des boss à pics. Mais je sais aussi que je dois me mettre des étapes intermédiaires pour éviter que le projet ne tourne à rien, et j'ai la sensation que c'est à travers des mini-jeux permettant de tester les différents aspects sans exiger la cohérence de l'ensemble que j'y arriverai. "gedsdemo-999" en était un exemple. Ca me permettra aussi de m'assurer que les "gedstool" pour le game-making sur DS ne se limitent pas à un éditeur de niveau spécifique à un seul jeu. Voilà donc les quelques idées qui me trottent en tête pour la prochaine release sans que je ne puisse me décider. Mais vous avez voté, comme en témoignent les nombres à côté de chaque "titre de jeu".

Bilooyan (1/8) -- [forget it]

A pooyan clone, that would take place in Bilou's woods, starring Bilou and the applemen, and cameohs of Funky Funghi as the Smart Bomb, Bouli and possibly BerryBats. pros: most of the art is available, I love the soundtrack, especially as interpreted by wolk. cons: soundtrack avl. only in MP3 format, applying the gameplay to the current game engine is challenging, not straightforward.

Biloubulus (2/8) -- [forget it]

A nebulus clone that would take place in Bilou's woods, with all the existing monsters. pros: art available, except for the (central) tree, I love Nebulus but where to find the "maps"? cons: the pseudo-3D layout and important amount of "special platforms".
Un p'tit clone de Nebulus autour d'un arbre géant avec les appleman et autre berrybat en guise d'ennemis ... Ca serait sympa, non ? J'ai toujours adoré Nébulus. Le hic, c'est le côté pseudo-3D et la quantité de "plate-formes spéciales" à gérer ... Je ne sais pas trop comment transposer ça sur le moteur de jeu en cours.

Apple Assault (3/8) -- [released in 2010]

Inspired from this flashpunk video and partly from this tree monster, Bilou would have to survive waves of applemen (and possibly other ennemies) in an arena of angry trees that continuously throw applemen at him. pros: stresses the current engine, sets the ground for testing "shooting monsters". cons: no suitable music right now, no art for the "angry trees" so far, and they weren't mentioned anywhere in the synopsys of the game.
A chaque seconde, de nouveaux applemen sont crachés dans l'arène par des arbres mécontents. Bilou doit survivre le plus longtemps possible. pour: test de performances du moteur de jeu, tester la création dynamique d'ennemis. contre: pas de musique pour cette ambiance-là sous la main (Mais si! String Tracking par Cyborg Jeff!), pas de sprites des "arbres mécontents".

Deep Ink Pit (4/8) -- [work in progress, 2011]

Somewhere in the School Zone, Bilou must prove his valour to a veteran inker and its magic feather. He's thrown in the deepness of the Ink Pit where he must escape ever-rising (deathly) ink in a vertical-only scrolling. Gameplay is closer to GravityHook than it is from Rayman's jungle rain in that all Bilou can use are SpongeBops to bounce over or grab pros: would test how playable multi-bounce over spongebobs is. Sets environment for testing "grab" mechanisms. "BN chocolate" could be used as tune ... maybe. Magic feather is a nice opportunity to experiment with 3D objects. Got nice lineart for surrounding (menus) art mids: some (background) art available as lineart cons: fun only if I have an online leaderboard. Major art effort required (but welcomed later). Many "not yet available" items at once.
Bilou se trouve quelque part dans la School Zone et doit prouver à un Encrier Vétéran et sa Plume Magique qu'il est bien le héro légendaire. Du coup, il se retrouve plongé dans un puits d'encre où le niveau monte en permanence et où sa seule chance de survie est de rebondir le plus haut possible, d'éponge en éponge. pour: tester des comportements plus complexes tels que le "grabbing". tester l'intégration d'objets 3D (la plume). tester la jouabilité du "multi-bounce" pour des puzzle ou des éléments d'adresse dans les niveaux du "vrai" Bilou. contre: il faut un high-score en ligne pour que ce soit chouette. Presqu'aucun graphisme disponible là-tout-de-suite. Peut-être un peu trop tôt pour le moteur de jeu.

Rescue Mission (1/8) -- [forget it]

Inspired by vvvvvv, since Bilou and Bouli are space explorers, and given that game deserves better graphics. pros: provides some backstory. I'd love to tell a story about a space station in distress where things have turned wild since ... Blork Carnage. Simple (seemly) mechanics. Nice puzzles cons: would be fun only if I've got similar maps and if you can discover the plot. Graphics & Sound ?
Bin, finalement, Bilou et Bouli sont des explorateurs de l'espace. Donc un jeu comme
vvvvvv, ça pourrait marcher. pour: ça permettrait de construire un peu les personnages (qui étaient-ils avant de se planter sur la planète étrange ? etc.) Et puis j'ai toujours révé de raconter une hist:oire sur une station spatiale à la dérive. Les mécanismes sont plutôt simple. contre: il faudra des maps, et encore des maps. et une histoire. Et je n'ai rien au niveau graphisme & son.

Bilou "Mining" (6/8) -- [mid-term development]

Some sort of a "manic miner : lost levels" clone, with a more complete collision and physics engine. And "32-bit" pixel art. I'd love to achieve it since i've seen Arachne's mockup (just on your left. Yep, that one). This is straight continuation of the current "gedsdemo" I already provided, where you'd add conveyer platforms, ladders and the like. pros: in progress. cons: Needs work on the level editor to be continued. Needs some "real stuff to collect" (not just apples: I cannot come with a coherent backstory for "collect apples so that you can pass through the trunk"). And golden keys and doors would be completely misplaced in Bilou's woods.
C'est la continuité du "gedsdemo" déjà disponible. Récolter des items pour que la porte s'ouvre et pouvoir passer au niveau suivant. C'est le principe de Qwak, de Manic Miner et de Johnny Biscuit. pour: déjà en cours, contre: pour rester intéressant, il faut régulièrement introduire de nouveaux objets/mécanismes au fil des niveaux. Le jeu demande un éditeur de niveau plus costaud. Je n'ai pas de "clés & portes" adaptées à la forêt de Bilou.

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.

blog backup scripts

Ok, Blogger provides you a .xml blog export for backup purposes, which happens to export virtually everything (including template and settings) into a RSS format. But what about your blog images, which imho account for a good 50% of this blog's spirit.

I gave blog2print a try, and they weren't able to grab more than a few jpg photos. So I went for my own, custom, regular-expression powered, post-processing perl script. Here comes the output. All the meaningful pictures gathered in a single folder, sorted by location in the XML file so that they can later be included in e.g. the output of a blogger2TeX tool ...

That makes 512 unique pictures (after fdupes duplicata deletion, thanks to Cyril for the tip) for ~350 posts (including 24 unpublished drafts)

Touche finale sur les pentes

Totalement par hasard, alors que je m'installe un petit "cubicle" de 8m³ à la maison pour y poser mon portable, je retrouve ce tutoriel de Florian Hufsky sur les pentes (le site original a disparu). Je lui chippe donc une de ses illustrations pour vous parler d'une des petites choses qui me restent encore à régler par rapport à la gestion des pentes dans Bilou. L'algorithme doslopes permet de suivre une pente, mais les états "standing" et "falling" ignorent encore presque complètement l'existence des pentes, ce qui donne des effets parfois curieux.

It looks like i've sketched the UI for monsters placement on a lost print-out of Florian Hufsky's tutorial on slopes. I'll then reuse one of his pictures to illustrate a last problem I need to take care of : landing on a slope. So far, the GravityController has not been modified to be aware of slopes (only WalkingController follow slopes with the doslope algorithm), but when the update will come, I know I'll have to ensure I prevent sprites from digging in the slope without making the slope "magnetic" to the point it attract sprites on the ground as soon as they enter the tile.

Il faut être prudent dans ce genre de situation, à éviter de positionner trop tôt le personnage à son emplacement d'arrêt sur la pente s'il n'y est pas encore arrivé. Sans ça, les pentes vont avoir un effet "magnétique" plutôt désagréable qui donne l'impression d'un moteur de jeu amateur.

Bon, ça ne peut pas être pire que le RSD game maker de mon adolescence qui ignorait purement et simplement l'existence des pentes. Le seul moyen de les simuler consistait à mettre un tile en gravité négative ... une approximation pour le moins bancale puisque le personnage se mettait à "osciller" autour de la position souhaitée :P

Il y a Janvier, et Janvier.

Nous voilà en 2010. L'an MMX. Bonne année et meilleurs voeux à tous.

• Janvier 2000, et sa lettre de voeux à Gedeon datée de 1900, clin d'oeil au bug de l'an 2000 ...
• Janvier 2001, et une petite tentative d'imaginer Bilou sur GBA pendant que je prépare l'exam oral de réseau.
• Janvier 2002 ... en pleine lecture d'Hyperion, tranquille chez mes parents (?)
  
• Janvier 2003, à l'appart, de retour de Zurich, j'explore les possibilités de mon Sharp Zaurus, malheureusement terriblement pénible dans ses communications avec le PC.
  
• Janvier 2004, toujours à l'appart, mais cette fois-ci de retour de Kyoto. Où on ne m'a même pas emmené voir les locaux de Nintendo, tiens. Mais peu importe: je tiens le sujet de ma thèse de doctorat ! Et une fois encore, c'est un processeur ARM qui équippe les IXP2400 que je commence à étudier.
• Janvier 2005, plein feux sur Clicker32 dont la release 0.9.0 contient un petit Bilou en guise de curseur souris ... qui fait un gros effet sur la communauté osdev... un rouage s'enclenche, il y a de plus en plus de "BangBash" dans les codes hexa de mon débugging...
  
• Janvier 2006, ma première "planche de BD électronique" à partir de mon carnet de croquis met en scène le crayon jovial et la gomme endormie. Depuis, le mini-récit complet est disponible dans le "Bilou's Book". Et je viens d'avoir ma DS (je crois).
  
• Janvier 2007, prêt à déménager. premier "mockup" un peu complet (les étagères de la School Zone) prend forme par copier-coller depuis SEDS tournant dans desmume. Heureusement, depuis, j'ai un outil de conversion automatisé et l'export des fichiers .spr par runme... Et LEDS pour construire directement le niveau sur la DS.
• C'est en janvier 2008, justement, que je commence sérieusement le travail sur LEDS, mon éditeur de niveau... Entre Zelda: Phantom Hourglass, la lecture de la trilogie des joyaux (Eddings & Eddings) et un re-cablage de mon ancien C64.
• Janvier 2009, à Bâle, entre Johnny Biscuit et Giana sur DS, je me re-cible sur Bilou, mettant au garage mes "projets" de portage de Biokid et autre Seafox sur la DS. Et pour contrer le manque de connexion internet, runme peut passer la main au programme .nds qu'il vient de récupérer par "Wifi local".

Happy new Year MMX everyone. As you have noticed, I tell above the story of those previous January 200* ... A new technique for slopes in 2000, investigating the Gameboy Advance in 2001. I've already detailed this to you.
2002-2005 are more "mysterious" years because I was fully focusing (that is, programming-wise) on Clicker32, my operating system. Yet gadgets (the Sharp Zaurus) and thesis project made me slowly prepared to face cross-compiling and ARM-based embedded systems so that when I buy the Nintendo DS for Christmas 2005 I know I'll be able to program it as soon as I'll get a linker.
January 2006 see the first releases of the "Bilou, Bouli, the Crayon and the SharpenHer" on my former blog. This marks a new start of a new hobby-era that I'm still presently in. January 2007 seen the first "fake level screenshot" with tiles drawn in SEDS, since work on the level editor only started on January 2008 t... and you certainly remember of January 2009, when I was in Basel, deciding that "whatever the game, I stick with Bilou ..."

Edition des monstres ...

Petit moment sympa pendant le congé de Noël : j'essaie d'imaginer la manipulation des monstres sur la map dans le Level Editor... En général dans ces cas-là, j'essaie de me servir au maximum des contrôles de la DS pour garder le maximum de l'écran pour la "zone de travail" (en l'occurence la map).

Somewhere between shovelling of the driveway and wrapping up of gifts, I sketched up a possible user interaction for monster edition mode in my level editor ... I thought you might find it funny to see. My aim was to keep mostly the screen clear of buttons, and use the natural control (that is DS buttons and DPAD) to keep the touch screen purely as a "workbench" to select and move monsters.

This completes a former document that was more of an overview of the monster management process.

Dans le même genre,mais un poil plus ancien, une réfléxion plus complète sur "comment savoir quel monstre mettre où", etc.

sgIP_TCP: either buggy or awkward

L'implémentation de TCP sur DS me surprend un peu, et pourrait bien expliquer les "fuites de données" observées pendant les transfers DS->PC. Ou les "deadlocks" qui se produisent en cours de transmission". Sur la sellette, la gestion des ACK, ces signaux qui indiquent qu'un paquet a bien été reçu.
I've never seen a TCP implementation behaving like dswifi, and chances are that it might explain the "data losses" and deadlocks I'm experiencing with runme uploads recently. I've compared my version (2005-2006) against the latest version in devkitpro and did not noticed significant changes in the TCP protocol handling.
What looks odd is the management of ACKnowledgements, those little packets that just tell the sender that "okay, i've got your data, go ahead". First, the DS seems to acknowledge everything, including ACKs from the PC. Moreover, it doesn't look to take all ACKs into account when sending a packet, but only the oldest one ...

• d'abord, la DS émet un ACK même pour un paquet qui ne contenait aucune donnée (un ACK du PC, par exemple)
• ensuite, elle ne semble pas tenir compte du dernier ACK reçu au moment de renvoyer des données, si bien que la DS réémet des données que le PC a déjà acquittées.
  

Mon analyse est encore un peu imparfaite (la DS a-t-elle ou non reçu les ACK du PC ? difficile à dire)
En regardant les lignes 4060 et 4061 de la capture, il est évident que la DS a reçu un ack du PC, puisque le n° de séquence évolue pour la 1ere fois depuis la ligne 4050, mais alors que le PC vient de valider tous les bytes jusqu'à 101796 (compris), la DS retransmet tout de même à partir de 100633 (ç.a.d. seulement 256 bytes plus loin que le packet précédent).

Je travaille toujours avec la version 2005-2006 de la bibliothèque dswifi de Stephen Stair. Je devrais sans doute tenter une mise à jour.

edit: the third pass on my own code revealed a subtle error on how I handled "EWOULDBLOCK" when uploading from a file. sgIP_TCP thus did not lose any data and is just a bit awkward. Sgstair himself took the time to point me out that there are much more levels of queueing in the DS networking stack (including hardware buffers), which sheds another light on the problem ... I think I can live with small performance issues. But I'll keep on investigating the issue anyway.

FileWidgets

Let's welcome FileWidgets.cpp in libgeds and appropriate DirShow + TypeWord widgets on the beam-file-out-of-DS page of runme. Snapshot will come out later : it's past my bed time, already.

Bin voilà. Finalement j'ai pu transférer les FileWidgets depuis le LevelEditor dans libgeds, ce qui m'a permi du coup de les utiliser dans runme pour le choix du fichier à exporter. Mais là, je vais aller dormir :P

runme feature request

Le problème d'un petit outil bricolé à la demande, c'est justement que les fonctionnalités sont bricolées à la demande. Ainsi, runme est devenu assez fort pour recevoir des fichiers depuis le PC par wifi, à condition de préférer une connexion rapide à un nom de plus de 8 lettres ...
Pour ce qui est d'émettre des fichiers, par contre, je suis à la traine. C'était un ajout destiné à permettre le backup des fichiers créés par mon Sprite Editor, avec donc 4 boutons "A-B-X-Y" correspondant aux quatre fichiers de travail spriteA...spriteY eux-même liés au fait que pour sauver son travail dans SEDS, on fait START-R-[ABYX] pour choisir le fichier à écraser ou START-R-R pour "sauver le fichier en cours". Idem START-L-[ABYX] re-charge un fichier. Pas de boite de dialogue, donc. Du code assez simple pour une fonctionalité assez simple, parce que de toutes façons je n'avais pas besoin de plus (et je n'ai toujours pas eu besoin de plus jusqu'ici).

Runme's upload features (that is, DS-to-PC transfers) are still fairly limited, and become a boulder in the path of coding. All it offers is to pick one of the 4 spritesheets edited with SEDS, and that's all. How about the map i've just edited ? how about Bilou and foes state machines? how about any other file on my .nds i'd love to beam back on rotating magnets (that is, HDDs :P) ?
It's somehow getting a priority. I'm not hot about integrating those Directory-selection widget of LEDS into rumne, but I guess it's no longer an option. I hoped the PC-side could tell us the name of the file to pick, but it also look like the objects of my code are oriented in another direction. OOPs >_<.
Mais depuis, j'ai aussi un éditeur de map et si les fichiers .cmd qui définissent les niveaux sont toujours rédigés à la main sur PC, ils ne sont pas forcément sur ce PC. Bref, il me faut plus de souplesse dans le choix du fichier. Quelque-chose du genre du choix de fichier dans LEDS. J'avais pensé contourner le problème en sélectionnant le fichier à partir d'infos envoyées par le PC par Wifi, mais malheureusement, l'organisation POO du code s'y oppose.

Je pourrais aussi repécher les derniers fichiers ouverts lors du parsing des scripts, tiens.

Affaire à suivre, parce que du coup, le temps imparti est écoulé. Et je n'aurai pas pu aller bricoler Bilou pour qu'il saute moins haut quand on relâche le bouton...