Révision du LevelEditor

C'est reparti, donc, pour un tour sur l'éditeur de niveaux. Et ça risque de prendre un moment, compte tenu du fait que je ne me souvenais même plus de l'architecture que j'avais choisie pour les classes "*Window". Avant de m'attaquer aux gros morceaux comme "copier-coller de blocs" ou "rogner la carte", je vais déjà un peu rationaliser l'espace de travail, histoire d'éviter qu'il soit bêtement saturé.

Pour ça, je compte sur le bouton "R" pour passer du mode "édition précise" au mode "brouillon" et sur un nouveau système de "pull down window", c.a.d. des fenêtres qui deviennent actives (et visible sur l'écran tactile) tant que le Dpad est maintenu dans une direction donnée. Ceux qui ont joué à Zelda: Phantom Hourglass voient de quoi je parle.

I'm resuming work on the level editor. It's been so long that i need to draw UML diagrams again to figure out the relationship between the classes, and so on. As you can see on the figure, there are quite a lot of things i want to alter on the UI, most of them relying on a newly introduced trick to have "pull" windows (that is, windows that only remain active on the touch screen as long as you hold the DPAD in the direction that invoked them.

• [done] clean-up user-interaction
• [done] layer visibility, "grid magnetism", etc.
  
• [done] block-copy mode
• [wish] pattern-fill mode
• [todo] map cropping
• [todo] tile-swapping tool.
  
• [need] fix that dprint() macro !
  
• [done] .cmd parsing and monsters edition
• [wish] radar for moving around
• [done] status report out of the playground.
  

Compacting Tilesheet

'faut que je me méfie: j'atteinds de nouveau des taux d'occupation de ma tilesheet assez hauts. Il y a encore de la place (les bilous de la tilesheet peuvent être remplacés), mais j'aimerais autant éviter le genre de problème que j'ai eu dans le passé.

Et une solution pour ça consisterait à pouvoir réutiliser le même tile dans plusieurs blocs. C'est clairement un atout dans les blocs de terre, qui commencent à devenir fort nombreux. J'ai déjà des algorithmes pour ça sur le PC (en PERL), reste à voir si je parviendrais à les transposer en C++ sur la DS... Si c'est le cas, je descendrais de près de 1000 tiles à 666. Pas trop mal.

(PS: oui, je sais, c'est crapuleux de redimensionner une image comme ça. C'est pour ne pas gâcher la découverte des améliorations)

I'm done with the behaviour of appleman for now. It isn't perfect yet, and he can't be defeated, but it will do the trick for the next milestone. So i've started packaging all this into a new gedsdemo.nds, a job that has been greatly simplified with the addition of Noda's EFS library (when i don't forget to patch the .nds i produce :P) i still have to make sure the background music (and SFX) are properly loaded, and fix things here and there on the maps, but the last 5% shouldn't account for too much work.

Mais le "packaging" progresse bien. Du moins j'ai une première approximation pour faire des snapshots. Je la joue "ambitieux", mais je vais tenter d'ajouter le petit mod de Pierrick, cette foi-ci. Il y a encore du boulot pour arranger les maps et comme d'habitude, je me bagarre avec l'EFS de Noda. Je te parie que j'ai oublié de patcher le .nds, tiens.

Pour simplifier, j'oublie régulièrement un élément ici ou là, et je modifies les sources sans les mains pendant que je berce ma p'tite puce.

gun.shoot(this)

Tout comme les contrôleurs, les "générateurs-d'objets-en-cours-de-jeu" (baptisés iGun, pour faire simple) sont des classes C++ paramétrées par le script et associées à certains états ou transitions pour ajuster le comportement du jeu.
Pour les contrôleurs, je les avais associé à l'état courant. Facile (presque trop). Pour les "guns", j'hésite. Le script ? une transition ? un objet graphique ? Qui aura accès directement à la classe, et qui n'y accède qu'à travers les méthodes d'un autre ? C'est le genre d'indécision que je déteste en POO, typiquement parce qu'en programmation impérative, le problème ne se pose pas.

• C'est au niveau des transitions que les guns sont utilisés. Je peux éventuellement capturer ce qui m'intéresse lors du parsing.
  
• Je n'ai droit qu'à 16 guns dans une 'palette' d'effets
• Je veux éviter de devoir ré-instancier des guns identiques (contrairement à ce qui se passe pour l'instant avec les contrôleurs où je dois avoir autant de GravityController que d'états affectés par la gravité).

Not quite "analysis paralysis", but still not enough time after lunch to figure out the best way to add iGun into the object-oriented game engine. It is used by Expressions (after all, guns are used to shoot new GOBs into the playground), but it's only one of the 16 guns an expression has, and it is likely to be shared by many states. What scope should it have ? which object will 'host' it, etc.

I'm undecided. I'll have to leave it for further code refactoring.

Bref. Je devrai revoir cette partie-là un autre jour: mon temps de midi touche à sa fin...

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)

Color Reduction.

A nouveau, ma palette de couleur est devenue quasiment inutilisable. J'ai bien un outil de "réorganisation" efficace pour construire des dégradés, mais à force d'importer et de réimporter les pixels depuis mes bricolages dans Gimp, je me retrouve avec 3 ou 4 instances de la même couleur (à quelques variantes près, voire exactement les mêmes). Bref, l'arbre que j'avais soumis faisait 28 couleurs, alors qu'il n'y avait que 16 teintes vraiment uniques (au centre). Ce n'est qu'après cette étape de "réduction du nombre de couleurs" qu'on peut commencer à jouer sur le contraste des éléments (à droite) pour arriver à ce que Helm proposait (à gauche).

Je ne suis pas pour la réduction du nombre de couleurs à tout prix, mais là, j'avoue que ça devient ingérable. Trop de micro-variation sur la même couleur, je ne sais plus laquelle utiliser quand ... Bref, si je veux pouvoir continuer à faire des mockups facilement, à ajuster les niveaux de contraste, etc. , il faut que je bricole quelques nouvelles fonctions dans l'éditeur de palettes.

Once again, my palette is a big mess, which makes my art more and more difficult to manage, since some colors do not fit any raster any longer ... If i want to save hours of "clean up" duty when publishing a mock up, i'll have to improve the palette editor too ...

• [done] zap unused colors in the palette.
  
• click on color in the preview, and see where it is on the palette
• R recalls the former color (undo) ?
  
• swap mode for the PaletteEditor widget
• [done] click a color in the palette and see on the upper screen the n first blocks featuring that color
  
• [done] flashing the color for easier identification. This happens on the spritesheet only (not on the grid, nor on the lone tiles) when you hold on the color square.
  
• split the color square view out of the Palette widget, though, to be implement flashing correctly
  
• [done] after such identification, allow color to be replaced by another one. (but only the grid is modified)
  
• [done] fix block mode
  
• [done] fix overlay-loading
• remember grid size when switching windows
• [done] provide some "undo" for accidental (misplaced) R-R combos.
• [now] fix imlib2spr script so that it picks the *closest* SNES color for a given RGB color (not simply killing bits) and that it kills redundant SNES colors (even if they differ in the initial RGB space)
• [now] allow spr-addpage tool to understand the "extra tileset" ... and do a major rewrite of that tool to ease further development.
  

Parmi les outils manquant, identifier les tiles qui utilisent une couleur donnée est évidemment primordial ... Vient ensuite la possibilité de remplacer cette couleur par une autre. Curieusement, ne lister que les tiles véritablement utilisé se révèle plus complexe que prévu.

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.