Saturday, January 29, 2011

Ne vous posez pas de questions ... (ou pas)

Entre une semaine de boulot bien chargé, le lave-vaisselle en panne (mais remplacé mardi prochain) et mon AMD64 qui boude la nouvelle LTS d'ubuntu, j'avais quand-même essayé d'avancer un peu dans le code de mon futur éditeur d'animations. Malheureusement, à chaque fois, je me retrouvais dans une impasse de design logiciel, à ne pas savoir quel était le bon bout des choses. Peut-être que "ne vous posez pas de questions, codez" ne s'applique pas bien à moi. Ou alors il ne s'applique pas bien au C++. Je suis donc revenu à mes bonnes vieilles habitudes: gribouille et pseudocode, avec un soupçon de "boi-boîtes et flé-flèches" UML pour aller un cran plus loin vers du code.

Is it the view ? should it be part of the model ? or of the controller ? aM Vram Cram ... I just couldn't sort it out straight ahead. No wonder why I always preferred unix's command line to the Visual Studio. If my editor series on the NintendoDs has taught me one lesson, at least, it is that "do not wonder: code" motto works poorly when *I* apply it to C++ for user interfaces. I tried several times this week to turn the 'animeds sketches' into code, but that was just like trying to dash a boulder with my bare hands.

The good news is that the "good old approach" still work well for me. Do not wonder how to code: write it down. Clarify the problem, throw arrow at those boxes until the real questions appear, let Bouli sort out what is *really* to be solved and which are the "academic" problems that are interesting from an algorithmic point of view, but that needn't to be addessed for such small values of N :P


Je vous les uploade donc ... je sais que certains d'entre-vous aiment encore bien ces petites feuilles remplies de Bilou. Mais surtout, une fois encore, ça me permettra de venir retrouver les idées dégrossies la prochaine fois que j'aurai une petite heure en fin de soirée ou sur le temps de midi pour coder un peu ...

Spoon: What's wrong ?
LAN: I'm sorry, my responses are limited...you must ask the right questions.
Spoon: "who is responsible for the VRAM and OAM slots involved in the timeline widget ?"
LAN: That, detective, is the right question. Program terminated.


Mon leitmotiv à moi sera donc "posez-vous les bonnes questions".

Sunday, January 23, 2011

La (old-)school zone

Après "Apple Assault", il y a de très fortes chances que le prochain "mini-jeu" de Bilou soit basé dans la School zone, ce curieux temple de la connaissance imaginé par Pierrick H. J'en ai déjà présenté pas mal d'éléments aux débuts de ce blog, vu que c'est dans la school zone que se plaçait le mini-récit qui m'a propulsé dans la blogosphère en 2006.

Précédent le premier Rayman de quelques mois, la school zone doit sans doute une bonne part de son inspiration à Zool, où elle n'aurait certainement pas fait tache entre le monde musical et le monde des outils.

Above you, the seminal sketches of Pierrick who suddenly decided to turn our daily school into a deathly zone where supplies are turned into monsters. Just below, a "pixelated" rendition some weeks later in '94. You'll note that there was no Rayman screenshot to be seen by that time. But there were many other games where the school zone could draw inspiration from. Zool is clearly one of them, and those school supplies would have perfectly fit between the musical and the toolbox worlds.

These supplies account for most of the ennemies I still plan for the DS version of Bilou (only BangBash is missing), although the movement patterns sketched by Pierrick have been strongly revised.

Le crayon, tout d'abord, a été promu pendat, milicien du désordre imposé par le boss. A noter que celà ne s'applique qu'aux crayons noirs, à mine dure. Les crayons de couleurs, à mine plus tendre, semblent tout à fait sympathique, bien que ne parlant pas.

The major drift came out while drawing the mini-comic: pencils turned into an organised army, under the control of the Big Book. Other encounters, such as the erasers, may be hot-headed, but they do not directly engage the fight.

Les gommes sauteuses sont restées, bien qu'ayant tendance aussi à faire de longues siestes ... un peu inspirées de certains blorks de Kid Paddle. Elles ne sont du camp de personne, et les pendats ont bien compris qu'il vallait mieux les éviter.

Quant aux encriers (maintenant 'inkjet'), s'ils sont si irritable, c'est simplement que ceux que l'on rencontre à l'extérieur tu Temple de l'Encre en sont les gardiens. Ils ne sont pas là pour rigoler, contrairement aux jeunes novices, qui eux, sont plutôt facétieux. Ils ont aussi acquis la faculté de flotter dans les airs (et donc utiles comme plate-forme mobiles) et peuvent projeter ce qui boucherait leur orifice au loin par la seule pression de leur encre. C'est de loin le personnage dont j'ai le plus ajusté le comportement.

By blogging further, many supplies started needing a "code name". Inkjets and spongebop name reflect their ability to serve as springs and moving platforms, respectively. This is somehow an attempt to understand what made the Mario series so interesting: interplay with monsters that create both counterpoint (the "tool" you need to solve a situation is hazardous) and deepness (you get richer interaction by combining sequence of simple actions).

Many have argued that the look of the inkjets doesn't invite interactions. This is somewhat deliberate: they are the guardians of the area and you are a stranger. They have no reason to show friendly although you have a common ennemy (the pendats). Hopefully, all you need to get help from them is to hop and bop on their top. Since this is how one dispatch ennemies, it should still allow the player to discover what to do.

L'éponge elle aussi a vu son comportement sérieusement remanié pour devenir ""Bop l'éponge". Pendue à son fil comme une araignée, pouvant flotter sur l'encre, elle joue à la fois le rôle de paratroopa et de plate-forme temporaire. Clairement, je veux construire un moteur de jeu riche en interactions là où les mouvements prévus pour par Pierrick étaient destinés à du BASIC en VGA.

Dumblador -- le taille crayon -- perd la faculté de se déplacer dans les airs: il sera plus utile comme projectile "vivant" (cf. les ShyGuy de Yoshi's Island) pour se débarasser de certains pendats trop encombrants. Une "clé organique", dirait Kirby Kid.

Le gros-livre-écraseur est toujours là, et son rictus lui vaut le surnom de "SquareRoot". Il serait un des professeurs de cet étrange école dont le caractère s'est empiré au point qu'il veuille dominer le monde. D'autres livres de ses collègues (notamment le Pr. Harraps) semblent heureusement avoir échappé à ce sort.

Some more drawing of the "big book" gave him the nick-name "Square Root", related to his eyebrows... And some more DS playing suggested a pre-battle level where one would have to keep climbing shelves while Sqrt follows you, causing shakes everytime it hits the ground, causing more supplies to fall down at you. That could be an interesting alternative to "Deep ink pit", btw.

Enfin, la "school zone" s'est aussi enrichie de PnJ tels que les tampons-encreurs, BangBash (totalement lié à une tentative de passer le jeu en 3D), et on y voit parfois de curieux Pr. Brush ou Pr. Atlas.

Saturday, January 22, 2011

FileWindow et SpriteTable

Je pense qu'on peut dire que le développement de mon éditeur d'animation a (enfin ?) commencé. Je me base sur le code du Sprite Editor, ce qui simplifie deux ou trois choses, mais amène aussi son lot de surprise...

J'avais plus ou moins oublié que la table des sprites qui apparaît sur la droite de l'éditeur dans SEDS est un objet "partagé" entre les différentes fenêtres, affiché par la "méta-fenêtre" qui a tout construit, notamment.

A small screenshot to illustrate that I've really started working on the animation editor. Reusing the sprite editor as a basis helps sometimes, but it also brings in some surprises. I had to refresh my memory on how the SpriteTable widget is generated and displayed by MetaWindow, while GridWindow, AnimWindow and FileWindow can manipulate it only because the MetaWindow passes a reference to that widget to their constructors. The widget accepts several listeners to be attached to it -- which is rather unusual -- and an "enabled" field in all those SpriteListenerInterfaces tells who actively reacts to an operation. release() and restore() methods of the different window enable() and disable() those listeners accordingly to achieve the desired effect.

Monday, January 17, 2011

ramno^1

En août 2008, poussé par un manque de mémoire vidéo,j'avais modifié SEDS pour qu'il puisse stocker les blocs séparément des sprites tout en gardant un seul fichier ".spr". Il aura fallu attendre février 2009 pour que cette modification soit pleinement supportée par le game engine et plus encore pour que l'éditeur de niveau en tienne compte.

The code snippet above is the handler for the "!extra!" button you can see below the Bilou sprites on the picture below. So far, it allows me to place whatever is drawn with SEDS either in the "blocks" tileset or in the "sprites" sheet. Since the Nintendo DS has separate VRAM banks for both, it's clearly worth the effort (the tale of this feature is now collected under the tag "ramno"). Last year, as I was sketching vines for the "nuts&bolts" project, I started using the "sprite" ram both for sprites and sketches. Soon or later, that's gonna catch me in the back. Since I'll have to update the sprite editor for r32, I'd like to add a separate "blockanim" and "draft" set. That could be helpful for the (yet to come) animation editor as well.

L'an dernier, alors que je fais un tour d'horizon des modifications à apporter pour Nuts&Bolts/AppleAssault, je dessine un paquet de lianes dans l'espace réservé au sprites (le tileset pour les blocs étant proche de la saturation), ne copiant que les blocs qui sont satisfaisants dans la zone de mémoire "blocs" utilisée par l'éditeur de niveau. Le texte "!extra!" sous les Bilous est donc le bouton permettant d'indiquer si la page fait partie du tileset par défaut (blocs) ou supplémentaire (sprites). Clairement, si j'avais eu plus de sprites, je me serais de nouveau retrouvé bloqué. Il faudra donc prochainement que je passe à un mécanisme à 4 positions: "blocs, sprites, blocanim, draft", la dernière position étant de fait réservée à des scribouillages internes au Sprite Editor. Je dis "prochainement", parce que l'éditeur d'animations, lui, n'aura que faire de ces scribouillage :P

Il y aura donc du rt^1 qui va devenir du (rt+1)%4 dans l'air prochainement.

Sunday, January 16, 2011

2To !?

Pas moyen de faire la mise à jour "LTS-vers-LTS" de la distribution Ubuntu présente sur "TuX", la machine à base d'AMD64 qui "trône" sous le scanner/imprimante de ma salle à manger. La bonne nouvelle, c'est que tous mes disques étaient des "bons vieux disques PATA" de 2001 (allez, peut-être 2003 pour le plus récent), et qu'il m'a suffit de descendre en ville acheter un disque SATA pour repartir sur de nouvelles bases.

Mon frère m'a aiguillé vers un disque 2To pour 130€ plutôt qu'un 1TB pour 100€. J'imagine qu'il a eu raison mais ... 2 000 000 000 000 de bytes !? ... mon premier disque dur faisait à peine 20 Mo! Qu'est-ce que je vais bien pouvoir mettre là-dessus ?? Je n'ose même pas imaginer la quantité de DVD nécessaire pour faire des backup de ce brol ! ... J'imagine que je vais appliquer la politique habituelle : faire une partition de ~ 512 Go pour nos compte utilisateurs, 50 Go pour le système, et garder le reste non-partitionné pour usage ultérieur.

(PS: vous l'aurez compris, l'appareil photo est en vadrouille, sans quoi je vous aurais ajouté une photo de la bête éventrée qui comporte maintenant 2 HDD "IDE", 1 HDD SATA, 1 graveur combo DVD+CD, un lecteur iomega ZIP et un lecteur de floppy 3"½, et peut potentiellement booter Ubuntu Lynx, Ubuntu Heron, SuSE 8.2 ou un "Win98 SE" qui serait probablement très étonné de voir à quel point le matos tout autour a changé :P)

Bon, prochain objectif: faire tourner "Tux-e-Do" dessus

Tuesday, January 11, 2011

swiSleep()

Je suis resté sans support de la mise en veille pour mes programmes jusqu'en juillet 2009, puis j'ai copié un petit bout de code qui permettait de s'approcher pas trop mal de cette fonction. Thoduv dans un post précédent, expliquait alors qu'il y avait techniquement moyen de faire mieux, que l'approche était en cours d'intégration dans la libnds, et que ça lui donnait du fil à retordre pour son "Lapinou Jumps" ...

Du coup, je me retrouve maintenant avec deux bouts de code qui tentent de mettre le programme en veille : mon "code utilisateur" sur l'ARM9 et le "code système" sur l'ARM7... et de temps en temps, le programme qui éteint la console au lieu de se mettre en veille >_<

Here's how 'sleeping' is implemented in the "devkitpro-r32" : there are SLEEP_DISABLE and SLEEP_ENABLE messages that can be sent to the powerValueHandler on the ARM7. When sleep is enabled on the ARM7, systemSleep() is invoked by inputGetAndSend() directly when the lid is closed for more than 20 frames (1/3 second). The ARM9 "acknowledges" this by echoing the PM_REQ_SLEEP message and the ARM7 side then proceed to the suspension of execution through the hardware power management register. swiSleep() on the ARM7 is the core of this shutdown. The rest is turning off the speaker, changing LED stats, etc.

So far, it makes my programs randomly shutdown with low probability when one closes the lid. I still have to define whether it's due to an intermix of the old code with the new lib or to something more intrinsic to swiSleep()... That's not really a problem for runme or apple assault, but it will definitely be a nuisance for the editors. Also, I haven't seen anything sending _SLEEP_DISABLE or _SLEEP_ENABLE, though, while it would be a good thing that I could prevent the DS to enter sleep mode in the middle of a wifi transfer. I'm also unsure of the reason for that 1/3 second delay, and I fear it could lead to gameplay issues (the game state change too much while I'm closing the lid).

Tuesday, January 04, 2011

dsgametools todo list

La nouvelle année semble un bon moment pour refaire le tour de ma "todo list" ... surtout combiné au fait que je viens de changer de devkit et que tous mes programmes (runme, seds, leds) auront besoin d'un brin de polish pour fonctionner sans hics dans ce nouvel environnement. Et pourquoi pas commencer par cet éditeur d'animation qui reste dans les cartons depuis si longtemps ? ...

Looks like shortening my todo-list could be a good #1 new year resolution (as far as homebrew deving is concerned. Fixing the dishwasher of course has higher priority ;)
Right now, the "animation editor" is receiving some more attention, but sprite and level editors will need some polish to work flawlessly with the new-and-improved devkitpro. I'd like to have a sketchy prototype of it by end of march, but Q1 is likely to be fairly intense at work :P


SEDSLEDSrunmeengine
non-square sprites (32x40, 32x48), flood fill for 16x16 grid, more tileset storage areas, complete palette edition mode, release
meta-tiles buttons bug, gobno bug, cursor bug, easier meta-tile edition, some more release (w/ biokid levels), copy/paste/save of areas, map resizing
3D model viewer, text editor, debugging r32
improved vertical scrolling, limit scope of external actions, state initialisation expressions, slope landing, and many more.