Au ralenti ...

J'avais noté de fort ralentissement sur émulateur dans le nouveau niveau. Il me restait malheureusement à constater que les ralentissement se produisent aussi sur la console, du moins pendant que les encriers projettent et si j'ai assomé beaucoup de dumbladors sans permettre à leur pieds de les rejoindre.

Slow downs are only fun when you control'm

The new level wasn't playing well on emulator. In fact, it was so slow (about 15 fps rather than 60) that I  could barely test it. I first thought my PC was unable to emulate it -- I had similar issues with e.g. Yoshi's Island DS when trying to get some snapshots. Running it on real hardware seemed to work fine until I started stunning bladors. With their feet as additional GOBs to animate, the system started to show slow downs occasionally (when jumping while inkjets throws drops). In my former level, I was 4 monsters, 16 drops and 14 feet under the threshold of what the 66MHz of the Nintendo DS can sustain.

Il y a 45 intervenants dans le nouveau niveau, dont 8 encriers et 7 dumbladors, soit un potentiel pour générer 30 objets de plus -- près du double. Oui, c'est risible comparé aux systèmes de particules qui peuvent tourner sur les PC moderne. Même pour 66MHz, ça ne devrait pas faire une telle différence. Mais voilà, à permettre aux gouttes d'encre de s'arrêter sur les éponges, à veiller à ce qu'un encrier puisse interrompre la marche d'un pendat ... bref, en ajoutant des interaction entre les ennemis et pas uniquement entre Bilou et ses ennemis, j'augmente les nombre de tests de collision, et il est possible que ce soit ce genre de chose qui fasse grimper la charge de calcul.

Is it the extra processing with of those monsters, with the animation parsing ? I could get up to 100 of them in Apple Assault, unless I try to make them react against each other (that would mean ~10000 collision checks). I do have some of those monster-to-monster tests, especially with ink droplets since I want them stopped by spongebops you carry along.
My plan so far to address this issue was to create sections of the game and to allow for collision testing only between objects belonging to the same section. Putting that into code lines didn't come out fluently, so I opted for the Commander-Keen inspired approach of freezing GOBs that are out of display range (that is, more than one screen away of what's on-screen). You can still try to collide against them when they're frozen, but *they* won't try to do anything. It was enough. It works well with the current game's flow. I'll revise it to something more generic later.

J'ai bien esquissé un système permettant de rassember les ennemis selon des sections, les collisions étant limitées entre personnages appartenant à une même section. Mais au moment de passer à l'implémentation, rien ne se combinait avec le code existant de façon souple. Je suis donc repassé à une technique plus traditionnelle -- le gel complet des personnages qui se retrouvent en-dehors de l'écran, qui était déjà à moitié implémenté (ils n'étaient plus traités par la couche graphique). Les listes à parcourir pour les collisions restent longues, mais c'est tolérable, d'autant qu'il y a moins de personnages qui provoquent des tests de collision. Et vu la constitution du code "GameObject::play", avec ses chaînes de contrôleurs et ses listes de commandes d'animation à interpréter, il n'est pas évident que la centaine de comparaison de coordonnées supplémentaire pèse tellement lourd par rapport à 5 objets supplémentaires à gérer entièrement.

There's an important effect of this mechanism. Yesterday, the position of a moving inkjet when you approach it depended on the time you took to reach it, from the start of the level. Today, it only depends on the speed you approached it for the last 2 screens. It will make learning of patterns easiers, as the level can be broken down into smaller chunks. It also means that the pattern of multiple GOBs (like two-inkjet-close-to-each-other) can now be manipulated by how you approach them... much like in Super Mario World.