WYSIWYG level

I had a bullet point in my "todo-before-release" list saying that the level shall be WYSIWYG -- the accronym for "What You See Is What You Get", which is just a coder jargon for form-fits-function. You see a solid structure, there is a solid structure. You don't see any, that's because there isn't any. No invisible wall, no subtle tunnels.

Unfortunately, I did have such a tunnel in my map. Tracking them right now means I have to scan the whole level in "meta-tile" mode. That's not quite comfortable and it proved unsufficient as I regularly break further the map when trying e.g. to adjust colors or fix some buggy pixels. Look at what I found yesterday on my on-going map: a hole dug into a wooden block that would make you walk into the should-be-solid area! How could that happen ? Simply because I tried to fix some un-esthetical combination of tiles.

Veiller à ce que le niveau ait effectivement des murs partout où des murs sont dessinés n'aura pas été une mince affaire pour ce niveau-anniversaire. En fait, je manque cruellement d'un outil capable de m'assister dans ce genre de tâche et il faut passer en revue le niveau en mode "propriétés" après chaque modification. Même un correctif purement cosmétique peut affecter la structure du niveau parce qu'un nouveau graphisme sur l'avant-plan va détruire les propriétés construites précédemment.

Il y a donc une sorte de "méga-raccourci" dans la version g88 qui fait très étrange (on se promène à moitié noyé dans le bois :P) et en voulant corriger une incohérence graphique (image ci-dessous), je me suis retrouver à introduire un nouveau "bug dans la matrice" (image ci-dessus). Bref, il est temps que j'équipe LEDS d'une sorte de radar permanent qui me permettrait d'avoir une vue un peu plus large des propriétés du niveau en cours d'édition qui se combinerait avec une map plus complète sur l'écran d'accueil, de sorte qu'il soit possible de positionner la fenêtre d'édition au stylet, visualiser l'emplacement des différents monstres, etc.

What's especially tricky with this map-bug is that it won't reveal easily when play-testing: Bilou slightly leaps when leaving the edge of a structure, and although it's technically small, that leap is large enough to clear one block. So you won't fall in a 16-pixels hole unles you hardly try and jump to align Bilou on the hole.

So it's now time I implement the "mini-radar" feature, at least able to show 64x64 tiles centered on the current editing screen, with 1 pixels for 1 tile.

• WelcomeWindow : down screen, prompt file names, etc.
• TileWindow : down screen (swapped up during edition), with TileTables for showing tileset content. [done] here be a mini-map of what we're editing.
• [todo] cleaner integration, widget laying on TileWindow although fed from MapWindow
• MonsterWindow, MapeditWindow both on the "up screen", with sprite memory already heavily loaded and the whole tileset present to show the content.

A new RadarWindow appearing together with WelcomeWindow (and thus on the 'up screen' when it's truly up) would be welcome to check whether we don't have broken structures just before we save/play the level, with a full level.



With a "bitmap" plane, I'd have to find 96K of VRAM.
With 16-color, 64x64 sprites, I'd cover the screen with 12 sprites, asking for 24KB ... Banks F and G offers 16KB each and can be mapped on "main sprites", complementing the 128KB already mapped there. Alternative would be to garbage-collect those slots in sprite VRAM that are holding sprites not bound to any state (and thus unable to be seen :P)