vendredi, mai 26, 2017

SaturdayScreenshot

Et voilà. J'ai un petit effet sympa pour attirer l'attention sur les boules bleues redonnant de l'énergie au joueur. Ça aura été un peu de chipotage pour intégrer les nouvelles animations dans les 4 niveaux existants, par contre. Pour la suite, il va vraiment falloir que je veille à ce qu'on puisse inclure les déclarations de bloc spécial de la même façon qu'on inclut les machines d'état pour les personnages.

Demain, je pourrai mettre ça sur Twitter et participer au micro-évènement "postez un screenshot de votre jeu en cours de développement".

Don't you love that blinking effect on the healing bonus ? Not as hypnotic as bouncing on a pink eraser, but i'm quite satisfied with the result. I'll have some work to do to allow such things be used in multiple levels without having to rely on manual copy-and-pasting across multiple script files.

mercredi, mai 24, 2017

Quelques détails

à régler avant de refaire une release:

  • récupérer le dernier .spr avec les petites étoiles en jaune pour les lettres
  • ajouter un effet quand on récupère un point de vie
  • corriger la fin du niveau 1 et les pilliers du niveau 4 pour qu'il n'y ait pas des bouts de gommes au lieu des graphismes.
  • veiller à repasser en mode "jeu complet sans Inspector Widget"
Mais au moins l'ensemble des niveaux reste jouable avec les niveaux d'encre ajustés.

dimanche, mai 21, 2017

shell to cybook

I got the z-list issue fixed. The error was what I suspected, but what is more interesting is that I have been able to write a test case that reproduced the bug systematically, and thus that demonstrate that the problem is gone with the fix.

I had to change my approach for investigating that because I've been doing so much on-line activities these last days that my eyes started to "panic". So rather than staring at my laptop top understand the outcome of a test, I pushed it into a .html file that I could browse with my e-ink cybook.


python -m SimpleHTTPServer 8000 &

(echo "<html><body><pre>" ; 
  ./testme ; 
  echo "</pre></body></html>") > /tmp/html/out.html

(echo "<html><body><pre>" ; 
  grep -h -C14 prepare libgeds/source/* 
    | sed -e 's:&:&amp;:g;' 
    | sed -e "s:<:\&lt;:g;" 
    | sed -e 's:>:\&gt;:g;' ; 
  echo "</pre></body></html>") > /tmp/html/code.html

Bon, ça n'a pas été une semaine simple, mais j'ai réussi à pouvoir prouver que le bug d'affichage de Bilou est corrigé tout en reposant suffisamment mes yeux qui criaient "au secours" la semaine d'avant. J'ai notamment utilisé assez abondamment ma liseuse pour passer en revue les résultats des tests (puisque oui, j'ai choisi l'approche "test automatique plutôt que l'approche "debugging interactif raffiné", la faute aux yeux précédemment cités). Celà dit, je vais rester prudent et laisser les détails techniques uniquement en Anglais pour cette fois-ci. Dès que j'aurai compris pourquoi l'encre refuse de s'arrêter à la hauteur demandée, je pourrai faire une release améliorée de School Rush.

The test itself is actually fairly simple conceptually: I just drag Bilou around in the level, back and forth, emulating the camera and the game logic after each displacement. As the camera moves through the level, some game objects freeze and unfreeze, recycling the hardware sprites, and inkjets use the top-layer sprites so that ink drops look to come from within it.

On the first round, the bug did not happen, but I had programmed a "trap" to report what I thought to be the precondition to reproduce the bug (having the inkjet frozen while it had one hardware sprite at top priority). The test then showed me that this happened, but less often that I thought. Actually, it only happened with one inkjet near the end of the level.

Then, I extended the test so that I would make an increased number of scrolls through the level. There I got the bug appearing systematically on one of the levels. I had to filter out some of the events reported during the scroll (I reported every change in the zlist's size as well as any arrival/departure of hardware sprites): inkjets throwing ink corresponding for instance to 4 correlated events. Making sure that the camera coordinates are reported (instead of Bilou's coordinate) helped as well.

lundi, mai 08, 2017

Another Inspector Widget ?

I have another instance of sprites disappearing and re-appearing in School Rush. It is likely something with the "pull part on top of every other sprite (aka. zlist[0]). I believe the issue happens when a modular sprite gets frozen while it had one of its component pulled to zlist[0], and then comes back to activity.

It would be great to investigate those situations to have an alternate widget for the Inspector Window Something that would show the on-screen area, the "GPU-active area" around it (where hardware sprites are are still programmed to be shown), and the area where the objects are still active although their OAMs are all disabled to avoid display glitches.


Bon, je tape un peu en vrac mes cogitations du week-end. Si je n'ai pas encore refait une release avec les améliorations de School Rush du mois dernier, c'est que je suis confronté à un retour des sprites-fantômes. Au départ, c'était juste dans la tour encrièrnale, mais ça se généralise à tout le jeu School Rush... J'ai ma petite idée sur la cause, mais j'aurais bien aimé en avoir la preuve avant de tenter une correction du code. Histoire d'être en mesure de montrer que c'est bien corrigé.

L'ennui c'est que j'estime le rapport entre corriger et démontrer que c'est corrigé de 1 à 10 au minimum. Voire de 1 à 100. L'autre ennui, c'est que ni l'amélioration d'Inspector Widget (qui aurait de la gueule) ni l'écriture de cas de tests (qui serait en aveugle) ne me paraît préférable

Ideally, it should be able to show "regular" and "pulled" sprites differently so that we can spot what state they are in and when. It should of course allow pausing and step-by-step processing to maximize our chances to reproduce the believed cause of the crash. Would that be enough ? should I rather try to have that investigated through "unit" testing ? I don't know yet.


lundi, mai 01, 2017

MapAnim : done

Once again, properly mapping the codebase before starting to program got a loong-delayed-feature added to the engine within an afternoon. The code was actually written bottom up, starting with the revision of the "clearblock" function up to the script parsing code. 

I love so much the new little bounces and stars, I couldn't play the game without them anymore :P

Et donc les voilà, ces petites étoiles qui accompagnent la disparition des bonus et cette gomme rebondissante que l'on me recommandait. Je vais bien vite me refaire une version de School Rush qui intègre tout ça, parce qu'on y prend terriblement vite goût ^_^

Le nouveau système me permet aussi d'affiner un peu le comportement de la gomme rebondissante: elle ne projette plus Bilou immédiatement en l'air: au départ, elle n'est qu'un détecteur et devient un rebondisseur uniquement avec la première étape d'animation. Du coup, ça permet au joueur de mieux ajuster ses mouvement avec ce qui se passe dans le jeu (enfin, je trouve).

samedi, avril 29, 2017

Adding the MapAnim

 Allons-y donc pour l'ajout d'un nouveau type d'animations dans mon moteur de jeu: la modification du contenu de la map elle-même dans le temps. Jusqu'ici, c'était limité à "faire disparaître le bloc en (x,y)" ou "retire-lui ses propriétés, mais laisse-le visible" (pour les bonus cachés). ça peut marcher pour certaines choses, mais ça suppose que les éventuels effets liés à la disparition soient entièrement pris en charge par un sprite supplémentaire. Idéal si l'image doit quitter son emplacement (un morceau de pont qui tombe, un décompte des points qui monte, etc), celà dit.

Let's have one more way of animating things in my game engine. One that would be suited to special blocks, and that update the map content at a specific location over time. The only thing I could do so far would be to shoot a sprite-manipulating game object and make the block disappear. That's mostly appealing if you want a picture to move away, like broken bricks, falling logs and the like. 
The "BlockAnim", used to animate the ink, is not interactive and apply simultaneously to all the instances on screen. It can make SMW coins spin, but it cannot leave a trail of sprinkling sparkles behind.

Now, let's resume the coding, I'll keep you updated on the outcome. I already love the animation I designed last night for the bouncing erasers ^_^.

Il y avait aussi les "blockanims", qui permettraient par exemple de faire tourner les pièces de Super Mario World sur elles-même. On procède alors par une mise à jour de la mémoire "tiles" et toutes les instances de l'objet sont mises à jour simultanément sur l'image à l'écran.

Le nouveau "MapAnim", lui, correspond plutôt aux besoins pour faire bouger un buisson devant lequel on passe, mettre des petites étoiles là où il y avait un bonus, etc. Comme vous pouvez le constater sur les diagrames, le mécanisme qui permet de mettre à jour le niveau (les données gérées par la classe InfiniMap) n'est pas particulièrement simple. Il met en jeu une description de chaque type de bloc spécial (les BlockInfos) et un objet temporaire capturant "tel bloc à tel endroit" (le BlockArea) qui permet d'interagir avec le personnage (GameObject) qui vient de passer par là. C'est finalement InfiniMap lui-même qui procède à l'effacement sur base du résultat du test de collision. La seule bonne nouvelle, c'est que c'est assez souple pour permettre des (petites) portes, des bonus, des bumpers et même les guides invisibles qui font faire demi-tour aux encriers.


Koopa 3D

Houlalaa... je retombe sur une vieille image de synthèse que j'avais réalisée dans moray/povray et présentée à la Inscene '99 ...

Quand je vous dis que la 3D, ce n'est pas pour moi, c'est pas une blague, hein.