html5

Formidable. On est en 2012, j'ai un dual-core à 5314.99 bogomips et là, je viens d'avoir mes cores saturés à 84+42% pour faire l'animation ... d'un effet starfield que je pouvais coder en QuickBasic et faire tourner de manière totalement satisfaisante en '95 sur mon Pentium 90.

Vous m'excuserez si je ne m'extasie donc pas plus sur le développement de jeux HTML5 (bien que j'admette que la Ludum Dare, c'était rigolo :) et que je reste concentré sur ma petite machine bien pensée et programmée directement ... la DS.

Ah, et si vous essayez de le faire tourner sur un i*, c'est pas encore dit que ça marchera, hein.

pitchenette

I managed to animate the ink in the school zone, target reached. AnimEditor should now be fixed and will be able to manipulate .spr files without dropping information, although I still need to track some memory-related bug.
So why not have a break and try that counter-stuff to better manage the number of applemen on screen.

au menu:
- on garde les berry bat;
- on revient à l'ancien comportement des pommes (merci SVN ;)
- seule la moitié des pommes entre direct dans l'arène;
- mode "pitchenette" pour repousser les pommes quand on a plus de punch-power;
- j'utilise (enfin?) les graphismes revisités l'an dernier.

Plus qu'à vérifier que ça donne effectivement un gameplay intéressant, corriger les éventuels "bugs de maps" et comprendre pourquoi j'ai parfois plus de pommes au total que prévu compris et corrigé: en augmentant le "nombre de pommes autorisé à l'écran" chaque fois qu'une pomme est morte, et en utilisant uniquement ce nombre (indépendamment du nombre, c7 de pommes restant à générer, c5), je pouvais autoriser la création de trop de pommes en fin de partie si le joueur fait un "combo" avant que les "générateurs" n'aient le temps de réagir.

I've sent beta-testing ROM to some friends, to see whether that's worth a world-wide release or not. It seemed the right time to integrate the new graphics for the green zone, revise maps and to give a new idea a try: the pitchenette ...

Now when you hit (B) when standing, you'll do something, whatever your punch level might be. When you don't have any power left, Bilou simply push a "stop hand", that is merely capable of repelling the applemen. It doesn't have any effect on stunned applemen nor on woodworms, though.

Piek's counter

Rencontre-surprise avec Piek, concepteur initial de ce qui a fini par devenir le Bilou que vous connaissez. Et double-combo-bonus: il venait juste de tester de manière plus approfondie Apple Assault (avec contre-expertise de son gamin que je situerais pas loin des 10 ans).

J'ai pensé à quelque chose qui pourrait discipliner un peu parfois un certain chaos... Je m'explique...

L'introduction dans ton code d'une simple variable qui en fait varierai selon la difficulté... Le nombre de pommes maximales en jeu en même temps...

D'une toute petite variable ajoutée, voici les avantages que tu pourrais en retirer...

• Cela permettrait que l'on évite de se planquer dans un coin sûr de la map et les attendre. On serait alors obligé d'aller chercher les pommes au contact et de sortir de sa zone de confort...
• Cela permettrait également d'éviter qu'elles ne sortent toutes à la fois de façon continue et de fait, d'éviter que l'on se retrouve avec 50 pommes groupées en bas de la map où il est très difficile de les battre...
• Cela t'apporterais un "curseur" de difficulté supplémentaire qui te permettrai de réutiliser tes maps mais en augmentant de fait leurs niveau de difficulté... (il est plus facile de se battre contre 5 pommes en même temps que 10 sur la même map)

An old-time fellow pops up while I'm on a walk ... Piek, inventor of the school zone, and initiator of Bilou's early look. He just gave Apple Assault a try with his 10-year-old boy and was eager to report his proposal: an on-screen appleman counter, separated from the 'to-be-defeated' counter. He's got coding background as well, so he came with a code proposal rather than a mere fuzzy feeling, but most importantly, he's a much better retro-gamer than I am, and supported his proposal with a quite complete set of weaknesses in gameplay that his proposal would (likely) fix.

I'll thus likely come back with an Apple Assault 'piek' 1.6 integrating that new counter with other revisions, such as "punch-button-always-has-an-effect-on-baddies", even if the effect is weak, and insufficient to beat them.

La plupart de ces soucis, je les avais déjà identifiés, mais pas vraiment traité avec succès. Mon meilleur coup reste BerryBat qui vient "punir" le joueur qui campe sans affronter les pommes. Mieux doser la quantité de pommes présentes sur la carte ne ferait pas de mal non plus, mais là, toutes mes tentatives ont été des échecs complets. Mais je persévère: ça ne devrait pas me coûter trop cher de faire le test.

Mon inquiétude se situe plutôt sur la manière de "doser" ce paramètre pour que le jeu reste intéressant. Je sais que pour le joueur déterminé, Apple Assault 1.4 + Berry Bat offre un challenge digne de ce nom et pourrait ce content de max_apples_on_screen=128. Pour le gamin de la voisine, qui n'a pas encore maîtrisé le coup de "rebondir puis puncher", 5 pommes au niveau 1, c'est déjà chaud. Probable donc qu'Apple Assault 1.6 introduira un 'bonus/malus' qui permet de récupérer toute sa barre de vie, mais au prix d'une augmentation sensible du nombre maximum de pommes à l'écran. Le baroudeur intrépide verra là une occasion d'aller droit au challenge en faisant des gros points.
Il y a un dernier point que j'aimerais revisiter dans cet Apple Assault 1.6: faire en sorte que le bouton de punch fasse toujours quelque-chose même quand la barre de punch de Bilou est à zéro. Sans doute une sorte de pitchenette à la Worms qui fait juste faire un bond en arrière aux applemen.

Funny enough, it sounded like Piek doesn't remember he's the one who settled the ground for Apple Assault gameplay in first place. I, for sure, haven't forgot ;)

Devoir de Vacances...

Bon, on est encore loin d'avoir une "school zone demo" convaincante, mais au moins, la première vague d'upgrade des outils touche à sa fin. J'aimerais avoir pour la fin de l'été une démo avec Bilou converti en animation composite (plus ou moins indispensable, vu que j'ai déjà effacé son corps pour les étapes de marche, ce qui explique le "clignotement" dans la dernière démo) et de l'encre animée qui tue (lentement si on veut).

Let me pick a chalkboard and try to map all the improvements I still have to bring to the Bilou-in-school-zone demo, so that I can identify priorities and schedule coding sessions for this summer (if we ever happen to have a summer here this year :P)

And the winner is ...

ink animation and repair Bilou walk animation

Rien que ça, ça nécessite déjà deux interventions immédiates sur SEDS et AnimEDS. Ensuite, j'aimerais pouvoir me rapprocher du look "pile de livres" proposé par Facet, mais ça, c'est plus ambitieux, et donc à garder pour une 2eme passe.

• GridWindow::save_back_tiles(), which is involved in the cursor-driven edition, already does some 32x32<->16x16 conversion. All I need to do is to move it where it really belongs -- EditorSpriteSheet : public SpriteSheet -- so that I can reuse it in FileWindow::event().
• 32x32->16x16 is now available and the ink tiles are converted.
• modifying one line in GameScript.cpp should allow to animate the ink, but there's more code cleanup waiting there, for more efficient memory management, for instance.

2012 ... toujours sur DS ?

Du point de vue de dev-fr, le développement sur DS est mort. Point. Peu d'espoir de tirer parti de la DSi, encore moins de la 3DS ... Alors qu'on commence à avoir tout doucement une idée de comment le mode DSi fonctionne, les linkers compatibles se font rares. Presque tous ceux qui avaient du mal à s'en sortir dans les specs de la DS et se concentraient autour de la PALib sont passé sur Androïd ou iPhone, et je ne peux pas vraiment leur en vouloir. Je fête aujourd'hui mes 6 ans de développement sur DS, et j'aimerais franchement pouvoir continuer encore quelques années, par passion pour ce type de hardware.

J'avais espéré pouvoir convertir ma DSi en station de développement une fois lassé de Shantae et Rayman, mais en fait, les producteurs du M3i Zero ont tout simplement décidé d'abandonner leur produit. Sans nouveau F_CORE.DAT pour tenir face au firmware mis à jour par Nintendo, le linker est donc inutilisable sur la console. Et rien n'indique que si je chope un Acekard2i ou qqch du style, il ne finira pas par lui arriver le même soucis. Avec DarkneSs qui est en réparation suite à une mauvaise chute, je dois avouer que ça m'inquiète un rien.

It is an anniversary, so it should be happy day: I've been doing NDS development for 6 years long. But there's little reason to rejoice, unfortunately. For most of the fellows I used to meet at dev-fr forum, NDS development is dead. Newly introduced DSi and 3DS are there, but tricky to use for homebrew development. Linkers to use them are hard to find and need more frequent updates than I'll feel comfortable with. Devers' who were happy to use PALib have migrated to Androïd or iPhone development and I cannot really blame them for it.

Yet, I'd love to keep working with the NDS, which has such great hardware, unmatched by the new devices. That means I'm back from "cool" to "weird" status again. I guess in a few months, I'll be no different from geeks doing retro-dev completing their Genesis/C64/AmstradCPC projects. Most of the people I'm hanging around don't even remember where they store they NDS power supply. Should I migrate to smartphones too ? Given Apple's policies, I'm really not appealed.

Je suis (re?)devenu une sorte d'énigme vivante pour mes contemporains, j'imagine. Dans quelques mois, serai-je vraiment différent de ces geeks illuminés (éclairés?) qui finalisent des projets sur Genesis, Commodore 64 ou Amstrad CPC ? Autour de moi, il n'y a plus grand-monde qui se souvienne précisément où il a rangé le chargeur de sa petite portable (dans le meilleur des cas).

Et pourtant, avec Apple qui possède des politiques du genre "interdiction formelle qu'il soit possible de développer avec votre application ... on veut bien tolérer du LUA, mais c'est tout", je dois bien avouer que les i* et autres *oïd ne me tentent franchement pas.

La bonne nouvelle, c'est que l'activité persiste sur gbadev.org ... j'y croise des gens qui s'intéressent à ce que je fais, et ça, c'est sympa ^_^

edit: à essayer dans les dernières découvertes:

• GravityDuck, http://www.nintendomax.com/viewtopic.php?t=14393&p=37082#p37082
• Ice Slider, http://www.nintendomax.com/viewtopic.php?t=14391&p=37080#p37080
• waikamu dare slides, http://disjointedstudio.blogspot.com/2010/12/welcome.html

ghost busting with spr2png.pl

No matter how much I improved SEDS, I still can't "optimize" my spriteset below 1024 tiles without messing up something. So I had to admit a disturbing possibility: maybe my tileset is *really* corrupted, and has been so unnoticed for some times ... maybe I'm suffering the equivalent of infamous cross clusters.

Let's recap: in .spr files, you find BLCK section that provides you the tile number for each block (logical entity) on that page. Then, you'll find one FREE section per "ram type" (block, sprite, streamed animations and drafts) telling you which tiles could be reused because you deleted its content. Good so far... except when they disagree.

Corriger ce spriteset de la school zone s'avère décidément plus complexe que prévu. Après une nouvelle série de corrections apportées à SEDS, toujours pas moyen d'avoir les bonnes images. En tentant de "rétrécir" les images, je me retrouve avec plusieurs sprites qui partagent les même données. Un vrai méli-mélo (in)digne du système de fichier FAT sur lequel tout celà est sauvé.

Permettez que je vous passe les détails techniques: il y a deux marquages des tiles occupés dans un fichier .spr (disons "vertical" et "horizontal"), et là, ils ne sont plus d'accord. Une stupide erreur au moment de sauver les sections 'FREE' des différents types de graphismes.

I already had modified spr2png.pl tool with a --cleanup mode that renders horizontal stripes accross tiles that weren't listed in any BLCK section earlier in the week, and now I've just added vertical stripes on tiles that are listed in the FREE section. We should thus see only solid sprites or 'dotted' tiles. But that's not exactly what happens: instead, I've got quite a lot of sprites with vertical stripes, that are thus supposed to be kept, but that could be erased as soon as I'll start editing new stuff.

My first mission, should I choose to accept it, will be to fix the .spr file so that all tiles stay safe. Then will come the hard stuff. Where in the code is the ghost maker... Have I forgot to adjust free lists when copying things around between spritesets?

Hopefully, not. It seems to be simpler than this: I have 3 FREE sections for the 'sprite' tileset. My bet is that I failed to set the proper spriteram identifier and have all "sprite, draft and streamanims free tiles" applied on the sprite tileset ^^"

Repaired, and still not working

Want a funny trivia? altough I got the spriteset "repaired", it's still too large for the game engine, after all. So I still don't see spongebop at all, but just some Bilou feet/hands again >_<

Maybe some blocks should be marked "free" and they aren't, maybe I really need to optimize so that I lower the allocation watermark ... or maybe it's something else.

At first, I thought some visualization of the spriteset content (preferably on SEDS's file window) would *definitely* help to figure out. Something like a 32x32 sprite can providing one-pixel-per-spritepage. But that'd be a bad idea.

I mean, *I* would find it handy, but it shouldn't be the problem of the sprite artist to organise the tileset so that sprites fit in. Doing something like "move this page to 'draft', click 'optimize' and then move the page back to 'sprite'" is a hack, not something I want to read (and definitely not write) in any user manual for my software.

The root of the problem is in the tiles allocation: it prefers allocating what has been recently freed, while it should prefer what has low values and would lead to a compact enough tileset. Think about it.

how to place monsters in LEDS

Oh, btw, I've updated the LEDS user guide page with instructions on how to add monsters in your level. That was some times ago ... I guess I was busy somehow by then.



Erhm... wait ... I still am (busy), am I not ?

such a mess ...

One file has the new (shrunk) inkjet ... the other has the survived ink swamp animation ... one has dumblador MEDS animation, the other lost them ...

This time, I could use runME to transfer the files (for some reason, I need to switch to "beam out" window, then back to "beam in" so that the "edit" spriteset button appears ?), but I wonder whether it could have dropped the animation information, somehow. Or is it something with the reading of autoexec.spr in SEDS that behaves differently from the typical START+L+* ?

Quelle histoire! Voilà la School Zone à peu près aussi sinistrée dans mes fichiers .spr que dans le monde de Bilou ... ici l'encre à disparu, là les encriers ont enfin retrouvé leur taille normale, mais dumblador ne marche plus... A force d'utiliser mes outils en cours de réparation pour tenter de réparer une bourde, les choses deviennent de plus en plus hasardeuses. Heureusement, j'ai les originaux de chaque fichier bien au chaud, sur mon disque dur (enfin, pas trop quand-même, hein ...)
Après avoir corrigé la copie de pages et la supression de blocs 32x32, je m'attaque à un dernier point mystérieux: la disparition des animations lorsque je transfère mes fichiers via runME (donc, avec un fichier 'autoexec.spr' présent au lancement de SEDS). Avec un peu de chance, j'arriverai (enfin) à récupérer tout le monde dans un seul .spr ...

Erhmm.. looks like it is. I'm missing an "&extdata" argument to keep track of "whatever the Sprite Editor doesn't natively understand"... such as animations. And all this happens with my brother's white DS, since DarkneSs is under repair after its "big fall"...

Ahaa ... got the autoexec.spr thingy fixed (yeah, there was the bug, as you may have guessed from checking the svn snippets). Some more beams and I also have the "smaller inkjet" copied into its proper place, the "minilevel" archived in the "draft" dataset ... Will I dare to run the engine on that ?

YES! pfew. I got it fixed, apparently. I will now be able to resume the attempts to bring ink swamp, inkjet and spongebop some life. howdy.

Oh, just not to forget it, the left-table on SEDS is still unable to offer 32x32 blocks properly, and it may still be required to switch back to the GridWindow before the right-table do it. That's a nuisance, and I think it took some 3 lines of code in AnimEDS to get it sorted out. Time for a merge-and-fix, dude-self. Done, thanks to doxygen-on-cybook ;)

cybook + doxygen = long

Le Sprite Editor est en rade, mon fichier d'images pour la school zone de plus en plus mal en point ... et pourtant je "perds mon temps" à essayer d'avoir du contenu 'bilou' sur mon nouveau gadget: le Cybook Odyssey. Encre électronique, écran tactile, ce n'est pas la noteslate que j'espérais, mais au moins il existe ... et avec un peu de chance, il me permettra d'avoir les yeux moins fatigués en fin de journée, au boulot.

L'appareil supporte les fichiers HTML en natif, donc les choses auraient dû être assez simples ... Sauf qu'en mode "lecture de fichier offline", les liens sont ignorés dans le mode HTML. Il me faut donc passer au format dédié "epub".

Je me suis perdu dans des tentatives de conversion doxygen xml -> docbook -> epub en passant par les feuilles de styles XSL de la bibliothèque boost ... alors qu'il suffisait de prendre un fichier HTML et de le passer à calibre pour qu'il me fasse un "joli" epub prêt à l'emploi (en près de 5 minutes quand-même :P), récupérant lui-même les pages inter-dépendantes, etc.

I wasn't much into amazon library, but I managed to purchase a french e-ink device to get some publications shown without having to print things all over the time: the Cybook Odyssey. It has a touchscreen (that was a must for me) and WiFi, and while it is not the NoteSlate I hoped to purchase, it should help me avoiding eye strain at the end of the day.

Since it natively supports HTML content, showing bilou-ish things on it should have been trivial, but unfortunately, if you check some HTML in offline mode, many things don't work. Hyperlink, for a start. And annotations. If I want to have some doxygen on it, I'll have to convert it to the dedicated e-book file format: epub.

Et là-dessus, je n'ai toujours pas corrigé plus SEDS ... et il est temps d'aller souhaiter bonne fête à mon papa ^^"

EDIT: note pour les autres utilisateurs de cybook: il y a malgré tout moyen d'avoir les annotations, surlignage et signets pour les fichiers PDF même si ça n'apparaît pas directement dans le menu contextuel. Tapottez un coup dans le coin supérieur droit de votre cybook (comme vous pouvez d'ailleurs le faire sur les .epub) pour avoir directement le menu "annotations" qui apparaît. C'est un peu hésitant (toucher/relâcher ne marchera pas, ni un petit glissement. Il faut vraiment une petite touche du bout du doigt comme si vous vouliez vérifier que la casserole n'est pas trop chaude sans risquer de vous brûler. Par contre, si votre pdf est un vieux document numérisé sans reconnaissance de caractères (au hasard, un mode d'emploi de C64 ? :P), oubliez tout ce qui nécessiterait un surlignage pour l'instant: le cybook prend vraiment trop longtemps à essayer de trouver le texte à surligner dans ce cas-là.

After some aborted attempts to go through docbook format, I realised that there was a tool (calibre) that could do straight HTML->epub conversion, producing some decent output. It takes a while to process the file, though. Easily up to 5 minutes. 

Oh, and you could have annotations and 'highlighting' with PDF files too, although it doesn't show up in the contextual menu. Just double-tap the upper-right corner to get the annotations menu showing up.

Bilou vs. Inkjet

Good thing: I at least have "real" pixel art for the inkjet. Something that I could use in-game without blushing. Too bad: it's oversized.

Ah bin, voilà: j'ai enfin des pixels pour l'encrier. Quelque-chose qui pourrait servir dans le jeu sans que je n'aie à rougir. Sauf que pas d'bol: c'est trop grand.

Les encriers sont plus grands que Bilou. ça au moins c'est clair. Que ce soit dans mes croquis ou dans la BD, mais pas deux fois plus grands. C'est d'autant plus ennuyeux que j'ai l'intention d'utiliser aussi les encriers comme des ascenceurs. Il faut donc que leur trou soit grand assez pour que Bilou y entre, mais juste assez étroit pour qu'il ne tombe pas dans l'encre. Il faudra que je les redimensionne, passer de la taille du milieu à la taille de gauche (24x24, je dirais).

Inkjets are larger than Bilou in both comic and concept art, but not twice as large. I could live with it if only Bilou was not using them as a transportation system. To achieve that, I need the "hole" of the inkjet to be just too narrow so that Bilou can't "fall" into the ink. That's clearly not the case with the middle inkjet. I'll have to resize it around 24x24 rather than 32x32 if I want it to work... and no: I don't really feel like scaling up Bilou :P

edit: drawing Inkjet is like playing DuckTales (GB): once you've found how to beat it once, it's easy to do it again. Small inkjet is now in the sprite file. Too bad, I did that *before* I merged back SEDS update, and saved the file with an old version ... which dropped my nice ink animation for the spriteset >_< I'll have to find back the trick I used previously to migrate some art between two sprite files.

fixing SEDS ...

(Flickr photo by amaky)

A blog is suppose to bring in updates, and yet after 6 years, I keep updating some posts again and again as the situation evolves. It happened again, I'm afraid.

So to keep you updated, I managed to fix the school spriteset using an upgraded version of SEDS. Spongebop now moves along and chase Bilou like a berrybat because I merely renamed "berrybat.cmd" into "spons.cmd" and then adjusted the animation statements :P

It turned out that most of the things I initially planned as "regression tests" for the editor trivially worked because they didn't care which SpriteRam they were working with... Yet many other things have been identified as broken/misbehaving, and will be fixed in the near future, but only after the revised SEDS is merged back on the trunk... and that will be after I'm back from my next conference. I'll allow myself the right to make SpongeBop behave as it should first, build up a proper animation for Bilou's walk and even to revise the pixel art for inkjet so that it indeed deserves the word "art" :P

Oh, mais oui, chers lecteurs francophones, merci à vous de rester là malgré mon emploi du temps surchargé qui me pousse à faire des posts monolingue pour l'instant.