Un nouveau mode d'action pour LEDS

Ajuster les propriétés des blocs d'un niveau, ça devient fréquent et c'est loin d'être une partie de plaisir dans LEDS. L'encodage par tiles spéciaux numérotés de 0 à 3 est techniquement suffisant, mais c'est une vraie plaie pour l'édition de niveau et encore pire pour la maintenance du genre "faire en sorte que l'encre réagisse aussi avec les monstres" ce qui suppose de passer tous les blocs d'encre de 2002 à 3002 >_<.

Tout celà serait plus efficace avec un mode "inversé" où l'utilisateur peut préparer un bloc de 2x2 tiles avec les propriétés souhaitées puis toucher un des blocs proposé comme graphisme pour que l'ensemble des blocs similaires à l'écran voient leurs propriétés mises à jour. L'idée est simple en apparence, mais on est dans du C++ et donc ce genre de modification est à peu près aussi confortable que de déplacer une porte dans une maison: mieux vaut d'abord faire un bon relevé des murs porteurs ...

Hey there. I hope I will find time to introduce a handy feature in LEDS this summer: the ability to quick-update the properties of blocs appearing on-screen. I spent some time identifying constraints and spotting the locations in the code where I'll be able to insert hooks for this. Wait and see. I have to apologize for the poor picture quality this time. I want to focus my available time on actually *coding* the modifications ^^"

J'avais fait, au moment d'ajouter "l'appel transient du tileset" une cartographie des "fenêtres" de LEDS qui n'est pas loin d'être le plus complexe de mes 3 éditeurs pour DS. Cette semaine "offline" fut l'occasion de me re-familiariser avec tout ça, retrouver les bouts de code correspondants (imprimés sur 25 feuilles de brouillon, vu l'état de mon cybook), de compléter avec les dépendances entre classes et d'essayer de trouver le meilleur emplacement pour la véranda ... pardon ... pour la nouvelle "fenêtre d'édition rapide des propriétés du niveau".

Les contraintes sont donc les suivantes:

• SpecialsWindow doit s'enchaîner sur MapeditWindow, qui s'enchaîne elle-même sur TilesetWindow pour avoir l'affichage souhaité. Faire des sous-listes de widgets au sein de TilesetWindow aurait pour effet de rendre la map invisible pendant l'utilisation du nouvel écran.
• SpecialsWindow doit être créé par TilesetWindow qui lui donnera l'accès à deux de ses SpriteTables (sprwidgets)
• L'activation de SpecialsWindow ne peut être décidée que par MapeditWindow, seul composant capable de dire si on se trouve ou non en mode "édition des propriétés du niveau". On peut déléguer l'exécution de cette décision au TilesetWindow ou à la fenêtre-racine de l'application.
• MetaLayer (widget) est le mieux placé pour effectuer le remplacement des données une fois que la SpriteTable aura lancé l'évènement indiquant quel est le bloc-cible.
• [done] J'ai 96 caractères disponibles pour des affichages adaptés (p.ex. un bloc fendillé plutôt que 0202). Le nom apparaissant en (2) sur le mockup et les caractère spécial affiché sur la map sera défini via le fichier .cmd et ses structures 'bloc $no { @commands } '

Je crois qu'on peut dire "heureusement qu'on aura pas besoin du mécanisme "transient windows" cette fois-ci" :P (qui permet d'avoir le GuiEngine qui produit un évènement 'GUI_ANYKEY' aussi lorsqu'on relâche les boutons).