Start+R+A

Reprise du boulot oblige, la progression de cette semaine est moins impressionnante, mais peut être tout aussi importante. Si DaySi a brillamment repris le flambeau depuis la chute de DarkneSs, elle se fait de plus en plus capricieuse avec son bouton R. Oh, il fonctionne, pas de soucis de ce côté ... mais il n'est plus très fiable. Il peut être nécessaire de pas mal le titiller pour déclencher quelque-chose, et quand il se décide, il n'est pas rare d'obtenir des "rebonds" du genre "on/off/on/off" en une seule pression du doigt.

Pressing Start+R+A or Start+R+R in SEDS lets you chose between "Save" or "Save As", changing the way a back-up copy of your file is created. When your 'R' button may automatically read as "R+R+R" for a single press, it quickly becomes unmanageable to have coherent file history. So I finally took the time to add some LOAD and SAVE clickable buttons (plus a tool option to invoke cursor mode in SEDS from the stylus) to compensate hardware deficiences of the DS.

Dans la mesure où ce bouton contrôle la "sauvegarde" dans SEDS et AnimEDS, c'est plutôt génant. A plusieurs reprises, j'ai du re-transférer d'anciennes versions de mes livres pendant que j'en faisais la mise à jour pour corriger une réécriture intempestive alors que je cherchais juste à activer le mode curseur (lui aussi déclenché par R). Mais voici donc une mise à jour de mes outils qui offrent des boutons cliquables (au stylet, donc) pour compenser ce genre de problème. A noter que le bon fonctionnement du bouton L, lui, reste incorrigiblement critique.

Pacman Dossier

Je suis tombé sur le document de Pittman "the Pacman Dossier" un peu par hasard, attiré par une illustration qui promettait d'expliquer "comment Pacman peut contourner les coins plutôt que de devoir passer super-précisément... or c'est justement un des défaut de mon moteur de jeu pour l'instant. Mario "contourne" un bloc-question quand il est au bord, Bilou en serait incapable.

English readers, rejoice: you don't have a translation of Pix'n'Love's mook on Pacman (and many others, but Pacman's paper was clearly the best of the mook, imho), but (assuming that you're into game design) you have access to the top-level "Pacman Dossier" by J. Pittman, where game-beating techniques are explained, inpsiration is revealed and behaviour/personality of ghosts is decrypted.

Oh, and make sure you don't miss RetroGameMechEx's video on the topic. The same information as in the dossier, but it sure helps to see the targets, distances and all rendered as a live overlay while you're being explained what is going on.

Le dossier équivalent dans Pix'n'Love m'avait pas mal plu, en particulier parce qu'il présentait comment des constructions simples avaient permis aux développeurs d'avoir des fantômes qui ont "une personnalité". J'ai été assez surpris de constater, en revanche, que les explications diffèrent, notamment en ce qui concerne Pinky et Clyde. La version de Pittman est corroborée par d'autres analyses, dont un désassemblage du code de Pinky, ce qui jette un voile de suspicion sur le travail d'investigation de la PnL Team, même si leur public-cible était clairement différent que celui de Pittman.

Edit:  https://nitter.net/pypebros/status/1275177777868800002 / https://shaunlebron.github.io/pacman-mazegen/ -- how one can craft Pacman-like mazes while playing TETRIS...

a link to the past ...

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.

Turning a Dream into Reality.

I was somewhat fed up of the fairly "narrow" layout of Blogger. I grabbed a page and toyed with Mozilla Composer (or whatever name it has now) to optimise css "divs" for 1024 pixel screens. Then, I opened the previous "top banner" and started extending it. 

The banner's core idea was "turning a dream into reality" -- which is more or less what this blog is all about. Sketches show on the left, then pixel art and code lines so that environment builds up into a game. I thought the picture my Bros' shot would fit quite nicely the right of the "timeline".

It's a temporary banner, anyway. So feel free to comment items you like/dislike about it, and to answer the little poll. The "polished" 1024-pixels wide will at least replace old "double-pixel" art by something fresh at full resolution. Stay tuned.

Je commençais à en avoir sérieusement marre du layout par défaut de Blogger où je ne sais même pas mettre deux captures d'écran côte à côte. J'ai donc profité du week-end pour mettre en place une petite expérience, élargissant la "zone de texte" à 640 pixels et le contenu du blog à 1024. Selon mes sources, aucun de vous n'utilise un écran plus étroit pour lire ce blog, de toutes façons.

Restait à mettre à jour la bonne vieille banderolle du mois d'aout 2007, et pour rester dans le thème "faire d'un rêve une réalité", je m'étais dit que, parmi les photos que j'ai, celle prise par CJ donnerait plutôt bien. Tout à gauche, le "monster design", tout en gribouillage ... puis du code et quelques pixels, et sur la droite, le jeu qui prend forme et vie sur DS. Qu'en dites-vous ? Ca reste une version temporaire, bricolée un peu à la va-vite, bien sûr. Je voudrais notamment remplacer Bilou(edit 11/03: c'est fait), le crayon et la souche en "gros pixels tout carrés" par des graphismes plus en phases avec mes dernières avancées, et à plein résolution (et c'est pas Gédéon qui s'en plaindra :). 

En toute franchise, ça risque de rester temporaire un moment ... A moins que l'un d'entre-vous ne veule mettre ses talents de webdesigner à l'ouvrage et me propose une banderolle alternative?.

Ah oui. Au départ, c'était le thème 'tic tac', en vert.

Bug ou Feature ?

Bin finalement, ça n'aura pas été trop compliqué de bidouiller SEDS pour qu'il me permette de copier mon "fameux tile perdu" d'un fichier à l'autre. Enfin, dès que j'ai pensé à bêtement retirer la carte microSD pour placer le backup dessus en tant que SPRITEX.SPR plutôt que de m'entêter à utiliser runme pour un transfer par Wifi ^^".

Un fichier .spr est organisé en "feuilles" (les spritesheets), c'est à dire la zone de 64x176 pixels sur la droite de l'écran d'édition, et au début de la version 0.3, j'avais ajouté un mode "copie feuille-à-feuille" avec un second "viewer" indépendant. Tellement indépendant, qu'en fait, si je commente une ligne dans mon code, il devient capable de conserver les données (en lecture seule) malgré les chargements de fichier. Juste ce qu'il me fallait pour sauver le week-end.

Et pourtant, je ne pense pas qu'il serait judicieux de garder ça comme une "feature" dans la prochaine version de SEDS. C'est totalement contre-intuitif, et 9 fois sur 10, la spritesheet du fichier précédent est de toutes façon inutilisable parce que travaillant avec une autre palette. J'ai beau penser que "Si on ne sait pas le désactiver (à la demande de l'utilisateur), ce n'est pas une "feature" : c'est un bug!", cette bidouille serait perçue comme un bug puisqu'il faut "ruser" avec le programme pour le faire fonctionner normalement rien que pour bénéficier d'une option en plus.

The Lost Tile has finally been recovered with a fairly simple hack on SEDS. Funny enough: the "hardest" part was to transfer the backup .SPR file on the media card ... which turned out to be trivial as soon as I stopped trying to use runme for that purpose ^^".

The solution is based on the "sheet-to-sheet" copy feature that I introduced a while ago, and that allows to view two sprite sheets (those 64x176 pixels area SEDS edits) face-to-face once you press the "START" button. The second sheet is "so independent" from the file we actually edit that -- when commenting out one line -- it can preserve its contents accross "load file" operations.

Now, unfortunately, this is not a "feature" I can keep. For the end-user, it will definitely look like a bug! Just like you wouldn't call a "feature" of a word processor the ability of copy-pasting from two different files if that implies you only have meaningful text pasted when the two files use exactly the same set of fonts. I have a rule to distinguish a(n unwanted) feature from a bug: if you can't disable it, then its a bug. I can disable this one, so I'll do.

Click the picture and discover more of the "spriteset management screen" of SEDS on flickr.

première photo du niveau 2 ...

Bon, on ne s'emballe pas : j'ai encore un paquet d'écrans à compléter dans ce niveau-là. Mais ça prend forme. Je teste des passages vicieux avec les Funky Funghi, etc.

J'essayais donc ce matin d'avancer un peu sur le comportement de l'appleman, et en particulier le faire "stresser" lorsqu'il aperçoit Bilou (une sorte de première phase d'attaque). J'ai donc ajouté une petite zone "déclencheuse de pièges" (cf. système de gestion des collisions) à Bilou (que je pourrais éventuellement désactiver lorsque Bilou a obtenu un bonus 'mode furtif'), et j'ajoutais une zone sensible à l'appleman. Bin pas de chance : ça n'a pas marché. J'avais oublié que si la zone active dans un test peut être plus grande que le personnage, il n'y aura vérification des zones passives que si l'objet lui-même est en contact. En d'autres termes, les zones passives sont toujours plus petites que les objets qu'elles recouvrent.

While I'm working on the improved behaviour of the Appleman, i have been tricked by the asymmetric nature of collisions in my own engine. While the *active* collision area can be larger than its own sprite, the *passive* area (that 'recieves' the collision, somehow) is inherently restricted by the bounding box of its sprite, meaning that the Appleman has to be active into detecting Bilou around (not the other way round). It requires a little more code to attach actions there that I'll write down as soon as we have sleep == (*deline && !me). I could also introduce a new kind of controller that simply fires an event when the player enters a given area, but for rectangular checks, it would just be useless work.
Alors on pourrait se dire "bah, il n'y a qu'à inverser" ... Le code n'était pas prêt pour ça, mais vous avez parfaitement raison. Alors cliquez sur un lien quelque-part pour continuer à lire, parce que moi ... bin Yaka.

Solide ou pas?

Hop. Petite preview rapide de ce que donne l'édition des propriétés du niveau dans LEDS. C'est encore très basique (il faut donner les propriétés tile par tile, à grand coup de stylet), mais ça permet déjà de bricoler.

Bien sûr, à terme, c'est directement sur le tileset que l'on donnera des propriétés (genre, tous les bonus ont le type spécial 0001), et le mode d'édition que je viens de fignoler sera là uniquement pour les retouches, les passages secrets, etc.

Quick news: now i can edit tiles properties with my Level Editor ... well, it's all still very sketchy and unperfect, but it stores 4-bit attributes where they're supposed to go for the Game Engine, and allows maps to be saved/reloaded. I intend to extend the system so that attributes can be defined on blocks in the tileset, rather than only on the map, but an unexpected side-effect of block cut-and-paste allows me to quickly build a big set of blocks that will be solid and refine afterwards.
It's a great tool for building secret passages too ^_^

edit: marrant. Je viens de faire la démo à Cyril et de me rendre compte d'un effet de bord imprévu: quand on repasse en édition "normale" de la map et que l'on copie des blocs pour lesquels on a changé les métadata, on copie en même temps les métadata pour le nouveau bloc. C'est déjà plus viable comme ça ^_^ ...

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.

Refactory

Re-thinking the .spr file format, writing command-line tools to manipulate sprite pages, extending "runme" application so that it can display and perform basic manipulations on both .spr and .pcx images, cleaning up the sources of the "wifi file transfer and self-update" component so that they can be later used in the 'refactored' version of SpriteEditor ... those things take time, plenty of little things to be modified, and requiring patches all over the source to keep the application working.

Well, at least now, i can merge all the "green"-related sprites in one single file, but i haven't most of the widgets that will be required to edit such file in SEDS.

That's progress, undoubtfully. Slow progress, but progress nonetheless.


Il faut repenser le format ".spr", écrire des petits outils en ligne de commande pour manipuler les tables de sprites (fusions/acquisition ... euh. je m'égare), ajouter des petites opérations de base sur les .spr et les .pcx dans "runme" pour en faire quelque chose d'utile. Ensuite, il faudra réintégrer tous les composants modifiés dans le Sprite Editor (j'ai bien pensé à un moment faire de runme le sprite editor, mais ça n'aurait pas de sens, un sprite editor avec un module player intégré :P).

Bref, bran-le-bas de combat: ça s'appelle du "code refactory". Réusinage de code ? Enfin, c'est le moment où on démonte tout pour le remonter (mieux) après, en espérant ne pas perdre l'état précédent qui ne marchait pas tout à fait si mal que ça, finalement :)

Flickr (t.a.g)

It is one of those online free services I had joined, before it got swallowed by some internet giant. But since I was there, I started collecting pictures I was shooting of NDS development as well.

So this tag should be used whenever a picture shown in a blog post is actually backed by a more complete photo on flickr, just in case somebody might one day want to print this all and have sub-pixels details of a screenshot.