Friday, August 23, 2013

Sheets for AnimEDS.

The set of animations for the school zone is quite full now (here, you don't see the spongebop, for instance).
Some of them could be dropped in specific levels, but I just don't want to lose things I've crafted so carefully, especially if I know I might use them later on.

So, just like you have "sheets" of sprites in SEDS, there will be some "sheets" of animations in AnimEDS asap. I love thinking of "sheets" for that because i) the DS display is too small to show them all and ii) scrolling through linear large set has never felt comfortable when working with RSD game-maker.

On dirait bien que j'ai quand-même rempli le jeu d'animations auquel AnimEDS me donnait droit. Je vais donc introduire des 'planches d'animation' tout comme il y a eu des 'planches de sprites' dans SEDS. J'aime bien penser en terme de planches. Ca s'adapte assez bien à l'espace limité de l'écran DS et c'est plus confortable que les interminables listes déroulantes de l'éditeur RSD.

Ce n'est pas forcément la chose la plus urgente à faire là-maintenant, mais le fait que la page soit pleine n'aide pas à ajouter des choses comme "Bilou-dans-l'encrier", "la gomme tournée dans l'autre sens" ou "le crayon assommé". Du coup ...

RSD map editor: you had to scroll
in a flat list to get another tile.
Random thoughts:
  • there are 8 columns per sheet, and less than 8 lines. That suggest using octal numbers for animations in game script could mean 226 is natevly translated into "page 2, row 2, column 6".
  • [done] We'll need a way to move things around pages. It would be useful to consider the last two lines as belonging to a sticky page (e.g. page 7) that can be used as buffer space to move things between "structured" pages.
  • [done] We'll need an input to dismiss one animation completely.
  • [done] preserve ongoing animation while switching page
  • [done] keep an "undo" for deleted animation, recall them pressing "DELETE" again.
  • [wish] sticky page remains sticky across loads (implies content wouldn't be saved :-/)
  • [done] avoid additional issues with LEDS' monsters rendering.
  • [done] some random replacement still occur, apparently when coming back from the editor window
  • [fixme] restoring deleted animation on another slot randomly makes source slot show an animation again.
  • [wish] find some way to flip to the next/prev sheet (preferably without the stylus). 
  • [wish] I can live with pendat's hands not having pendats colors on the thumbnail, but body's color reflecting the real choice could be important for level editor.
  • [wish] flipped limbs rendered flipped on the thumbnail.
It might not be the most critical thing to do to progress on the project, but it might also be that none of the monsters have progressed this summer because this sheet is full. No room for Bilou-in-inkjet... No room for swapped bopping eraser ... No room for stunned pendat ...

Thursday, August 22, 2013

runbox 0.8 then LEDS ...

That's the result of summer re-factory: runme can now be used to navigate the content offline, launching levels and tools, and pre-viewing pictures and musics (although some more regression testing on those last features would be welcome). The top-screen show me where I am, what the current filter pattern is (e.g. SC*.MAP) or the selected file once a file has been selected.

Now, I'd like to make Level Editor to benefit from these improvement as well. The "map filename" mechanism has been fairly disturbing lately. It lacks contextual re-naming/cloning of one map as already wished back in March.

So yeah, LEDS time again, but on the front end rather than on the back end.
  • [reverted] Having 'dirname' and 'typed text' on the top-screen MetaWindow is not such a good idea in LEDS: it makes noise on the level editor and could potentially corrupt the level.
  • [done] I'd need a "mapname" widget (not merely a button) that embeds file name, size (current or suggested) crop, drop and re-name sub-buttons.
  • [done] update cmd filename too, and make sure that new mapname is reflected in the saved cmd file.
  • [won't] Maybe GuiEvent should be completed with a BLUR event, when someone clicks another widget. RELEASE is "stroke started inside an object and ends outside", and complements CLICK ("stroke started inside and ending inside") but we have no complement to TOUCH ("new stroke starting inside.") -- but that might interfere with W_DIRECTORY events generated in the "PICKMAP" context >_<

Wednesday, August 21, 2013

10 minutes a day.

Sometimes I can't help looking backwards and tell to myslef "Doh! It's k weeks (months?) since I said that would be my next target, and I'm still far away from it! What the heck have I done with my time during those weeks?" ... That usually happen in times like now, when IRL stuff are crowding in my agenda -- either at the office or at home -- and barely leave me 10-minute sessions (2 of them if I'm lucky) to progress on my homebrew projects.

But don't we all have moments when we wish we had more time available ? Or would better control the way we spend our time ?

Wednesday, August 14, 2013

Widgets come and go.

Hmm ... allow me to use one post as a documentation-to-self for a feature of the GuiEngine that I haven't used a lot, yet: the ability to dynamically control widgets showing up on screen.

  • one static widgets list per window
  • nbWidgets may tune how far you can go in that list
  • wstart indicates where you start reading from.
  • add(x,y,Widget) populate the list, normally in the Window's CTOR.
  • setmark() inserts a terminator in the list.
  • setmark(HOP_TO_ZERO) inserts a "goto" item that forces the list to be read from the start. This is allowed only when wstart>nbWidgets, which implies that you must reset nbWidget to the position returned by the earlier setmark(). I'm not happy with this constraint.
When one wants a (set of) widget(s) to be optional, the prefered approach is to place it after a terminator and followed by a HOP_TO_ZERO to further process the "permanent" widgets. That also gives those "tabbed/pop-up" widget precedence over permanent widgets.

if (wstart==nbox) {
    wstart=0; box->hide();
} else {
    wstart=nbox; box->render();
Note that visibility of the 'pop-up' widget needs to be manually adjusted with render()/hide() and that we need to force the Gui Engine to lose widget focus to make it work. In setup, the current location of the optional widget (here box) needs to be captured (in nbox):

add(64,0,(box=new BoxWidget(...))->attach(...));
If you want the 'pop-up widget' to be hidden when you'll enter that window again, you'll have to complete your Window::release() method with a conditional test:

if (wstart==nbox) {

Thursday, August 08, 2013

RunME needs a fix.

Mid-summer has been fairily hostile to game/tool development, unfortunately... I'm stuck on level editor progress because I can't easily ensure levels I edit are working properly, as RunME struggle to launch them. The best I could do while *deline was exploring the joy of the sea-side was some documentation of RunME so that the following fixes could be performed:
  • [done] file/directory selection information should get its own space on top-screen
  • [done] not only the FILE*, but also the extension name (file type) should be accesible from the L+A launcher button.
  • [done] beam-in files in the last directory used for beam-out.  [todo] currently, only typing a new mask on the "alphanum keypad" will activate that directory.
  • [todo] buttons (SEDS/edit) shouldn't overlap.
  • [todo] ensure we can move back to SEDS/LEDS/download mode at all time.
  • [done] don't try connecting when there's no sink on a given slot
  • allow beam-out to be cancelled.
  • [wish] global_connectAP and wfcWindow::autoconnect should belong to WiFi widget. 
  • [done] IP address and [wish] SSID shown on the top screen once the connection is established.
  • [wish] allow .spr files to become autoexec.spr even though they're too large to fit our 256K buffer.  
  • [todo] spritesheet loaded with L+A in RAM should be able to display their colours, despite the "extra palettes" setup.
  • [done] a way to try again the WFC connection settings from the "access point selection" list, as they may contain WEP keys, too.
  • [wish] enter WEP key in AP selection list.  
  • [wish] use flag if "clicking on other screen's button" is a bug rather than a feature.
^ UI/transfers -- level running v
  • [done] fix the 'unregister XFER' loop bug.
  • [done] proper cleanup when 'returning' to beaming activities from a test.
  • [todo] avoid InspectorWidget/LoadingWindow interference (active areas not reacting anymore, beam-in offers cluttering the display)
  • [done] report hero/ennemy/none class in InspectorWidget.
  • [todo] control log display, clear and end-of-test from Inpector widget. 
  • [think] special InspectorWidget display mode on (breakpoint collision), showing both colliding GOBs' state *before evaluation occurs*, with the ability to step to the next frame (after collision occurs)
  • [done] double-check .spr and .xm loading support: no jamming allowed.
  • [fix?] how could die() end up showing blank screens (when leaving the running game)?
That makes a NeoCompo entry very unlikely this year, unfortunately.
But at least, it gave me time to sit down and think about what mechanics could nicely complement JUMP in the full-blown adventure game.

post-trauma-edit: I just picked Surt's tileset I used for LEDS release 0.1 with the hope that I could use it to prepare a "tutorial map" and ship LEDS for NeoCompo ... result? I quite certainly screwed'up my (and will have to recover it from some git) with parts of the tuto map because I hadn't changed *that* filename in "tuto.cmd" ...
When I tried to save back the map under "", the map got all cleared ... Unfortunately, LEDS is not ready for shipping to the world and an extended 4-days week-end won't help even though I'd decide to invest all those free hours in a compo rush, I'm afraid.