Vieux vieux pixels ...

Quand je vous disais qu'au début de l'aventure de Bilou, je réalisais mes décors sur des feuilles millimétrées. Je vous ai retrouvé le tout premier "tileset" de la green zone...

Here come some oldies ... tiles on a millimeter-grain sheet of paper, waiting to be converted into list of numbers. 

That's how you develop video games when you're allowed to use the computer at most 1 hour a day... and don't have a colour screen. 
Monsters were designed in the same way, but it wasn't easy to make sure animations would work well. That's why I shifted to modular animation instead for the BASIC version.

Et en bonus, le tout premier appleman, le boss de la green zone et SpongeBop du temps où elle trainait par terre.

Wonder Girl ?

Il y a quelques semaines, Super Papa Bros regardait avec *deline l'intégrale de "Monster World IV", un jeu intermédiaire entre Wonder Boy et Shantae, avec de sympathiques petits personnages ronds, "les pepelogoos" que *deline a beaucoup apprécié.

Je n'ai pas eu l'occasion d'y jouer, je ne suis pas sûr que je chercherai à le faire -- le gameplay à la Wonder Boy ne m'a jamais vraiment attiré. Mais il y avait quelques éléments graphiques qui m'inspiraient bien pour mes temples perdus.

A grand adventure, cute fellows and a heroine. Monster World IV -- afaik one of the last episodes of the Wonder Boy franchise -- had everything to please *deline. It isn't exactly the kind of gameplay I'm after, but it was definitely entertaining to watch on youtube, and there were a couple of nice background design elements that I sketched in my game-art-study book.

However, I am quite puzzled by the similarity between MW4's pepelogoo and Ardy Lightfoot's companion. I should dig that further ... It's interesting, too, to see how that game seems to set up the basics for the Shantae series, as if WayForward tried to make a tribute game that surclassed the original some 8 years later.

Le look des pepelogoo m'a particulièrement surpris, puisqu'identique au petit perso qui accompagne Ardy Lightfoot dans ses aventures. Même son rôle dans le gameplay est similaire, lancé à l'attaque des ennemis.

A la mi-1997, je construisais un dernier jeu Game-Maker avec un personnage au look saïyen du nom de "Futurboy", évoluant dans un décor apocalyptique qui était accompagné par une boule sauteuse tout à fait sur ce moule-là. Mais moi, je savais que je cherchais à reproduire le duo Ardy-et-son-ami. Il n'en reste que le modèle du personnage au bandana mauve, repris dans "4 to save toonland", qui lui, avait survécu.

Salut, vieux.

T'as pas pu t'en empécher, hein ? Tu es encore revenu dans les archives perdues de ton blog pour essayer de te souvenir comment il est possible qu'il y ait eu un "trou" de plusieurs semaines entre la version 0.8 et 0.9 que tu n'as d'ailleurs jamais pris la peine de numéroter d'un petit jeu baptisé "School Rush". Et tu vas nous pondre un article nostalgique sur le thème du visiteur temporel. Forcément.

Eh bien, je vais te rafraîchir la mémoire.

Tu vois, c'est sympa, le développement pour le fun. On code un p'tit bout par ci, un p'tit bout par là. Mais voilà, à force de construire des étages les uns par-dessus les autres, tu t'es retrouvé avec une sorte de tour de Pise qui a terriblement besoin qu'on revoie ses fondations. Il y a trop de choses que tu as perdu de vues, au point que tu t'es retrouvé avec du code redondant ou incohérent. Tu étais bien décidé à ne pas baisser les bras. Le projet en vaut la peine: c'est juste un contretemps. Mais là où tu mettais un point d'honneur à te montrer à toi-même que tu étais capable de relever ce genre de défi quand tu étais chercheur universitaire, tu es maintenant dans un job où ce genre de défi, c'est aussi ton lot quotidien dans les semaines de release.

Alors, la prochaine fois que tu éprouveras du dédain pour ceux qui construisent un jeu dans un moteur "2 minutes au four", rappelle-toi qu'ils font ça exactement pour la raison qui fait que tu compiles avec GCC : pour avoir une base solide sur laquelle s'appuyer.

Maintenant, éteins ton ordinateur et monte te coucher: la journée de demain pourrait bien être pas mal gratinée. Moi, demain, si j'ai un moment de calme, je vais en profiter pour gribouiller un peu et continuer à chercher ce qui me plaît dans les "déviations" que j'aime bien. Ça me changera les idées.

/Toi-même du passé.

iScriptException ...

Something uncomfortably wrong occurs in the game engine. Objects I'm trying to restore have invalid state attached. I believe this is the reason why there has been "guru meditation" screens during last playtests with friends. It seems linked to abnormal use of the memory: while the infringing object seems to have proper structure, it seems linked to a state that is absolutely not looking like a state structure, but rather some animeds content...
That could quite match with some earlier dig into the issue where I had invalid pointers at some delete() operators, leading to red "guru meditation" screens. I unpacked my gdb-remote-analyzers-and-setup-perl scritps. It takes ages to launch the game in that fashion, but I should get a list of stack trace for those locations that shouldn't have been released. I may need to find a proper path to reproduce the issue first.

Meditate on this I will...

3 days later, with 2 runs on the first level, I managed to trigger the exception again in the "demulator", producing 1GB worth(?) of log. I have hopefully a shorter summary of the 11 addresses involved in operations that looked suspicious. I need to program the software eyes that will scrutinize those operations and explain what happened.

2 more days and "PERL's eyes" are ready. I get detailed reports with stack trace of the last allocation, the last sound deletion and the offending "double-free" issue. But what should I think about some memory block that is first allocated in "GobState::addOnDone" (thus should be a transition, somehow, or the vector of transitions), gets deleted as GobState is destroyed, and then destroyed again as a GobAnim ?_?

Finally, one object, shot during some state transition is delete twice, with a time locality pattern that makes it look like a real issue, not some side-effect. Both deletion happens during Engine::animate(), likely at a few frames interval. How has that occured ?

What transition create that object ? What object is it ? Which object created it ? ... At least those questions can be answered with the whole recording of memory allocations. I know from stack trace the address of the transition that created the "faulty" object. From there, running "Perl's eyes" once again, I find it belongs to a "fall->hit" transition of Bilou, and the object generated is a "power-down" object. That might help reproducing the error ... tomorrow.

Question: while there has been only one "constructor" call, could there be two "reganim", making the object linked twice in the objects list ?
Question: if there's a single "reganim" for two "delanim", what is the cause ? Who messed up with the list's invariant ?