Tuesday, October 16, 2018

Final Scene

Immense pardon d'avance à tous les développeurs de jeux que j'ai terminés (pas si nombreux que ça, donc) et dont la séquence de fin m'a déçu. J'en suis à l'étape de faire la séquence de fin et je dois reconnaître que c'est extrêmement difficile de contourner les limites techniques pour parvenir à faire passer quelque-chose qui ressemble à l'idée que je m'étais faite de la séquence de fin qui soit fun pour le joueur sans devenir un casse-tête complet.

Et évidemment, le blog n'aide plus vraiment à rester motivé pour terminer ça parce que 1) on est plus en 2006 et mes lecteurs sont nettements moins assidûs et 2) j'aimerais que ça reste une surprise, donc je ne peux pas vraiment faire du teasing avec les images.

13/10: une p'tite idée gribouillée sur papier pour l'écran "game over": un pendat arrive par le côté et pousse Bilou assomé dans un trou. Les lettres "G" et "O" de gameover se décrochent et viennent se placer pour faire le "GO" de l'écran titre. Retour à l'écran-titre.
14/10: bonne idée pour intégrer les derniers crédits et l'enregistrement des scores
15/10: mise au point d'un des derniers éléments interactifs qui sera quand-même dans la séquence de fin
16/10: nouvelle tentative pour la map correspondante (2x1 écrans). Peut-être un peu trop dense, par contre. La présentation de "Verso" y est simplifiée à l'extrême par rapport à l'idée de départ.

Et il est temps de conclure, parce que

http://sylvainhb.blogspot.com/2015/03/il-faut-que-je-finisse-school-rush.html
http://sylvainhb.blogspot.com/2017/10/finishing-steps-for-school-rush.html
...

Monday, October 15, 2018

Bug Punch

I have one last bug (hopefully) to fix in School Rush: with the latest builds, there is an unexpected additional Bilou head showing in addition to the big punch, and stays until the “shot sprite” takes over the regular animation..

Doing some more testing, it appears that the latest unaffected build is last year’s “xmas” release. It could be something that went wrong with the refactoring, or it could be an accidental modification of the site sheet itself.

A look at the source shows that I implemented an “invisible” sprite by not picking any sprite until the 6th frame. This isn’t clean and chances are that I was exploiting some undefined behaviour. I should definitely have a dedicated command that hides the sprite through the animation that works whatever the contents of the sprite page.

Well at last, in the refactored code, there is a clean INVALID_BLOCKNO value that is set to the frame number as the GOB is created. All I need now is to make sure the sprite remains hidden until we give it another value.

Thursday, October 11, 2018

Amy Zing

It only took Ant a few days to include my little "Amy Zing" sprites into his neat labyrinth crawler homebrew, actually. For some reason, I completely missed it by then (March '18) and only realised that the game was released thanks to some anonymous internet folk who followed a link from simian zombie web site to mine, leaving a mark into the logging system which I tracked backwards to hit the page with the release.

So I grabbed the game, enjoyed it, enjoyed again, tried the various resolutions (normal is my favourite one) and smiled: that was my first ever homebrew collab as a spriter ^_^. And then started to wonder... Could such simple labyrinths work for Bilou, under gravity ?

I traced some of them in a notebook and started to check where I would put collectibles or hazards and why. In a platformer, you shouldn't (imho) try to make your labyrinth with individual blocks, because the player will need some room to manoeuver. If I pick 4x3 Bilou-sized blocks as a "maze cell" (3 blocks being a standard jump height), the maze now scrolls over 4x3 screens. You can no longer plan your move easily with that limited visibility, so you'll end up more often in dead ends and will have to back-track. Hence the rewards and hazards.

And well, Imho, with properly tuned jump distances and some wall-kick mechanics, you might not even need fancy ladders or similar tricks to support those labyrinths.

That's not quite "infinite pyramid", but it could be a nice step towards it.

edit: good news: my 5-year-old J.L.N wasn't afraid of the half-dead monkey and accepted the maze game as something to do when he's bored.

Monday, October 08, 2018

Trotôptimiser

Je voulais faire une pyramides de taille-crayons. Quelque-chose de fun, original et un peu inattendu pour récompenser les joueurs persévérant. Mais voilà. ça veut dire beaucoup de sprites ... beaucoup de collisions ... alors est-ce que le moteur de jeu va le supporter. J'ai passé déjà quelques après-midi et cogiter la chose.

Basculer entre tiles et sprites, peut-être ? ou simplement entre une version mono-sprite du taille-crayon assomé et une version trois-sprites comme celle utilisée dans le reste du jeu ? Oui, parce que les pieds de taille-crayon sont animés avec des sprites séparés histoire de pouvoir faire plus d'étape d'animations avec le même nombre de pixels, mais le moteur de jeu ne supporte pas qu'un objet existant doive acquérir ou libérer des sprites hardware au fil de son existence. Quand le taille-crayon est assommé, ses pieds sont cachés par-derrière lui alors que deux nouveaux objets d'un seul sprite sont créés pour les pieds projetés au loin.

J'aurais donc pu faire ma pyramide avec des tailles-crayons-d'un-seul-sprite. ça m'aurait permis d'en faire tenir jusqu'à trois fois plus à l'écran. Sauf que quand Bilou transporte un taille crayon, les pieds-cachés deviennent les mains de Bilou tandis que les sprites hardware de Bilou sont temporairement désactivés. Ce n'est donc pas quand le taille-crayon reprend ses pieds qu'il faudrait passer (en détruisant un objet pour en reconstruire un autre) à 3 sprites hardware, mais bien quand on ramasse le taille-crayon pour la première fois.

Oui mais et si le joueur réempile les taille-crayons ailleurs, alors ? on va se retrouver avec le même nombre d'objets mais cette fois à 3 sprites ? ça va mal finir ça.

Heureusement, un premier test montre qu'on tient toujours les 60 images secondes avec une trentaine de taille-crayons à l'écran rien qu'avec l'objet de base, tel qu'il intervient dans le jeu. Même les empilements ne posent pas de soucis, sans doute parce qu'en réalités, ils ne sont pas gérés comme des collisions.

A la place, c'est le mécanisme de plate-forme mobile qui entre en jeu, dans lequel on se contente de vérifier la relation avec l'objet auquel on s'était attaché précédemment. Les collisions proprement dites (nécessitant de comparer chacun des taille-crayons avec chacun des ennemis) n'aura lieu que depuis les tailles crayons qui tombent.

Je m'inquiétais donc pour rien. Par contre en en profitant pour mettre un générateur de pieds-baladeurs dans le niveau, J'ai compté jusqu'à 28 pieds générés sans que l'émulateur ne tombe sous les 55fps (la DS serait donc probablement toujours à 60), mais par contre après ça, il y a trop d'objets à gérer et certains d'entre eux ne sont tout simplement plus affichés (un bug bien connu du moteur de jeu actuel, contre lequel il n'y a pas grand chose à faire à part éviter d'en arriver là par le level design). Bon à savoir je calibrerai mes générateurs de pieds en conséquence, un peu comme j'avais fait avec les générateurs d'applemen dans Apple Assault.



Sunday, September 30, 2018

Another devkitpro update

Another laptop update ... The previous one started to act pretty weird regarding AC power. I survived a couple of week with the old (2007) laptop, enjoyed the music collection it has and the larger screen. This one is more similar to the faulty one with a 1350x768 screen, but it has SSD.

Well, it was also the opportunity to try dsgametools with the latest devkitpro. And it was pretty disturbing. At first, you now have to install a package manager first before you install what you need. It could have been done with a custom apt-get setup but they opted for pacman with a binary package you have to pre-install from their github. Not really the way I believe open source should work ...

I'll keep the new error messages and improved warnings of g++ 8.1.0 for another post. Here, I missed some headers or other stuff to rebuild everything

  • errno definition for dswifi ... that is likely an old one. manually installing sgIP_errno.h apparently fixed things. I'd prefer to get the sources of current dswifi to ensure everything is fine. Hope I'll find them.
  • load_bin,load_bin_size as well as bootstub_bin, bootstub_bin_size (for nds_loader_arm9, used in runME and self-upgrade features) are missing. Iirc, they should be built from .bin files ... They are still in libppp9/data ... I'll have to find out why they were not processed.

Friday, September 28, 2018

/r/NDSHacks

During my HTML Quest to find people interested in NDS development nowadays, I stumbled upon a discord channel named /r/NDSHacks. I'm not much into Discord, but since I made an account this summer to follow the gosh-sad-panda-put-Nectarine-offline discussions, I did my best to enter #homebrew_development ...

With some luck it might make my tutorial more meaningful and get some beta-testers more easily. We'll see.

Tuesday, September 11, 2018

Truly Testable Level Editor

There was one annoying thing with the scripts while adding 1-up, and  that was I had to add the new rules in every level. This is the kind of things that should be written only once, and as far as the script parser is concerned, it could be written once, in the "rules.gam" file. The problem is, this file would be ignored by the level editor, and thus is not used so far.

And unfortunately, there are some design flaws in the way LEDS' own parser is written, making any change in that part pretty tricky to do right. It would be nice to refactor that a bit, but such a refactory with no easy way to test things would be errors-prone. My next move must be towards testable LEDs logic.



And I realised my first idea for the tests, with modified readers and all, was over designed. Instead, it would be interesting to have two simple programs that run checks on parsed levels (eg. what are the coordinates of game object #42 , or how to display special block#3) or that do simple changes and then write back the result. Test cases are then simple shell scripts combining calls to those tools and to standard file comparison tools.

What I still need to figure out is how I'll extract specific information (e.g. what gob another gob links to) out of the full data. And how to compare the extracted data.

Friday, September 07, 2018

Retro-game mechanics explain: golden!

I just went into a super video (link below) about how collision code can be exploited in Super Mario World to beat the game faster. I'm not much into speedrunning myself, but I love whatever can teach us how those old games where built and what is the logic behind their engine. And tool-assisted speedrunning quickly gets quite deep into those subjects. So let's go.

C'est du tout bon. Une vraie pépite. Une fois encore, "retro-game mechanics explained" confirme que même quand on a pas l'intention de pratiquer le speed-run intensif, les découvertes des speedrunners sont une mine d'or pour qui s'intéresse aux techniques de programmation utilisées par les anciens de l'ère 8/16-bit. Et cette fois, c'est Super Mario world qui s'y colle.

When a tile is activated, it is deleted, and a sprite version of the block will displayed in its place. When that sprite returns to its initial position, it is removed, and another tile is set in its place (usually a brown block).
Well, that was an expected one. And as he explains, it was already used in SMB3 (and probably also back in SMB1). It is something I'd like to put into my own game engine as well, although the closest I have so far is simply the "mapanim" to replace tiles of a specific location on the map along an animation triggered by a collision.

Si vous avez déjà un peu cogité la manière dont les consoles nintendo construisaient leurs images à base de mosaïques de "tiles" et des "sprites" par-dessus, vous aurez aussi deviné que pour faire sursauter un bloc-question quand on le touche, il faut effacer le bloc de décor (à base de tiles, donc) et le remplacer par un graphisme librement positionnable (un sprite) le temps de son sursaut, puis remettre à nouveau des tiles pour le bloc transformé. C'est sympa d'en avoir une confirmation depuis l'analyse du code (et oui, j'ajouterai ça dans ma todoux-liste un de ces quatres).

The next one is a bit more unexpected.

Which tile is activated during sprite/tile collision is determined by a point that is a mix (blue) between the the sprite's position (green) and its clipping box (red). If that point is not within the tile that was activated [...] there will be block duplication.
Of course, that duplication is the whole point in SMW - Level End Glitches video by RG Mech EX:  the location where to spawn the bopping block and set the new brown block won't match the original question block location, which will remain unchanged. Interrestingly, this is partly because sprites that are located inside a solid tile are ejected outwards so that they don't get stuck. I always thought that would be mario-specific, but actually no: it applies to all objects.

Un peu plus inattendu: en plus de leur zone active -- la hitbox, en rouge sur la carapace -- qui doit rester en-dehors des zones solides du jeu, les objets ont un point unique qui sert à déterminer quel bloc a été touché. Si on cogne un bloc-question avec une carapace lancée vers le haut, c'est d'abord le carré rouge qui va renseigner qu'il y a collision puis le point bleu servira à trouver avec quoi il y a collision. Chose intéressante, tous les objets subissent le traitement "repoussé par les murs" qui autorise Mario à contourner un bloc lors d'un saut plutôt que de s'y cogner méchamment comme une Giana sister.

En revanche, le fait d'avoir mis le point-test en dehors de la zone de collision m'intrigue. Quelle est la raison ? ou est-ce juste un bug ? et cette possibilité d'avoir changé de position entre les deux opérations du test de collision (boîte et point) trahit-elle une optimisation du genre "on ne teste les blocs-question qu'une frame sur 4" ?

A few wonders ...
- is there a good reason for that blue hot spot not being with the red box (other than saving computation cycles) ? It just sounds like a bug to my ears, since the red box is what triggers the collision.
- is that "ejected first but still triggering the initial block" linked to some lower rate for the collision code compared to the motion code ?


And did you know ?

In order to reduce the number of distinct objects, some power-up blocks have different contents depending on their X coordinate on screen.
The limit on the number of objects you can have in a game engine is a old opponent. I know him a bit too well myself. But still ... Thinking of editing your level and having to shift that key pick-up one block to the left or one to the right so that it actually contains a key feels just mind-blowing. Naturally, it might not have been a big deal for Miyamoto's team who already knew player needs wide enough areas to move their avatar around ... and possibly went for "aha! guess which of those 4 ?-blocks hold a key and which are mere coins ;-)". But still. That's pretty unexpected.

Mais il reste le plus croustillant. Le truc que explique qu'un bloc supposé contenir une clé peut tout d'un coup donner des ailes à yoshi. Visiblement, je ne suis pas le seul à avoir choisi trop peu d'information par bloc dans mon format de niveau, et pour pouvoir représenter tous les power-ups et bonus possibles dans Super Mario World, l'équipe de Myamoto a choisi d'utiliser la position du bloc au sein du niveau pour choisir quel objet serait offert au joueur. Pas la position absolue, hein, mais le fait qu'il soit sur un bloc pair, multiple de 4, impair, etc.

C'est à la fois génial et complètement déroutant. Dans un commander keen, je ne me serais jamais attendu à un truc du genre "si le bonus est au 2eme étage du building, alors c'est une glace à 2000 points. S'il est au 1er c'est un donuts à 1000 points et au 3eme un nounours à 5000". Mais ici, dans un contexte où les blocs-question sont souvents présentés alignés comme les gobelets d'un jeu de hasard, le truc prend tout son sens. Il reste à considérer le "numéro" stocké dans le niveau non plus comme un identifiant d'objet à créer mais plutôt comme l'identifiant du générateur d'objets correspondant. Au moins, ils ont évité les contraintes du genre "un niveau peut offrir soit les ailes, soit une clé, soit un ballon, mais jamais une combinaison de ceux-ci."

Wednesday, September 05, 2018

gimme a (control-)break!

Out of TheOffice unexpectedly. TheOffice runs Windows systems and recently decided that VPN solutions should be replaced by a remote desktop gateway. Oh yeah. Back then I had made a quick try with xfreerdp. It was quite ugly to setup (especially because xfreerdp **wants** you to provide your password on the command line) but it did worked.

Couldn't get it to work again in my sick-on-Monday mode. So I tried to find something better with remmina. After re-installing the software from vendor repositories (rather than distro repositories, which I typically prefer) to get access to the gateway-support plugin I managed again to connect. It wasn't nice (256 colors by default), it wasn't fast, but it did the trick. But unfortunately, i clicked "connect" rather than "save and connect" and my setup got lost.

Unfortunately, I couldn't set it up right again.

So let's try xfreerdp again

let $WUSER be my 'THEOFFICE\\brosp' domain/user name à la windows
let $WACHINE be the name of my machine at the office w-brosp-hb.example.org
let $GATEWAY be the name of the gateway like thegateway.example.org
and let's say get_a_password is a shell function that will just read one line of text and return it without showing it on screen ...

then

xfreerdp /u:$WUSER /p:$(get_a_password) /v:$WACHINE /g:$GATEWAY

did the trick.

It worked, it is nicer (i'd say I got true colors) but just scrolling to the output of the console is a pain. Give me a SSH login **please**. My firth thought of "yeah, I know, I'm going to run a SSH server at home (hopefully I can get my public IP address quite easily nowadays, although it won't be the same everyday) and I'll setup a reverse tunnel from work. The firewall/NAT on the ISP box might not like that as much as I do, though. I'll have to tweak it to give my laptop a fixed IP, etc. That won't be for today, I'm afraid.


Thursday, August 30, 2018

1-ups... At last.

Finally, something good does happen when you collect letters in School Rush. Nothing fancy, and not even anything original, I'm afraid: you just get an extra life. Yet, considering the difficulty of the -final level, this might be welcome.

It required some new tools, though. Lives, hit points and collectibles are managed through counters in the game engine. counters can normally get their value defined only when you parse the level script. Then, you would only increment or decrement the counter as game events occur. Then, you can define one or more actions that happen when the counter reaches zero.


Enfin! Ça vaut enfin la peine de faire la collecte des lettres dans "School Rush". Rien que du très conventionnel, j'en ai peur (on prend une vie supplémentaire), mais bon, vu la difficulté du dernier niveau, quelques vies supplémentaires ne seront sans doute pas de refus. Mais cela ne s'est pas fait sans de nouveaux outils.

When hit points counter gets to zero, for instance, a jingle and a death animation are played. We can even force a domino effect that decreases the "lives" counter then. But that mostly works because I load level" action also allow an expression to be defined, and because you're then allowed to reset the hit points value when reloading the level.

To provide 1-ups, I had to introduce a new elementary action dubbed "setcounters" that offers that freedom out of the level-loading machinery.


Les vies, les points de vie, les objets à récolter, tout cela est géré à travers des compteurs dans mon moteur de jeu. Normalement, on ne sait definir la valeur d'un compteur qu'au chargement du niveau. Durant le niveau, en revanche, on ne sait qu'augmenter ou diminuer la valeur petit à petit.

Le gros intérêt de ces compteurs, c'est qu'on peut forcer l'exécution d'une action lorsqu'ils arrivent à zéro. Comme redémarrer le niveau, changer la musique ou, faire apparaître un nouvel objet. Mais idéalement, ici, il faut surtout augmenter un autre compteur (les vies) et reprogrammer pe compteur arrivé à échéance (le nombre de lettres avant la prochaine vie). Bref, ce sera le rôle de l'action "setcounters", fraîchement ajoutée à la panoplie du parfait programmeur de GobScript.

Tuesday, August 07, 2018

Air Control

Bon, voyons un peu ces histoires de contrôle aérien, maintenant. Je sais qu'il y a des effets que je veux éviter et d'autres auxquels je tiens. Et ce à quoi je tiens par-dessus tout, c'est que le joueur ait la sensation qu'il tombe lorsque la gravité reprend le dessus. Pas question donc que le déplacement horizontal puisse devenir plus rapide que le déplacement vertical si ce n'était pas le cas au moment de commencer à sauter.

En fait, en l'absence de vent, et si on peut tomber suffisamment longtemps, ça ne devrait même tout simplement pas être possible: la friction de l'air est la même dans tous les sens. La seule chose qui peut faire qu'on se déplace plus vite horizontalement qu'on ne peut tomber, c'est le fait de planer. Et ça, j'ai déjà un power-up pour le gérer.

Maintenant, soyons honnètes: je viens de me repasser des vidéos de Super Meat Boy et de N+ jusqu'à plus-de-vaisselle-à-essuyer ce week-end et je n'ai jamais pu mettre en évidence ce "point d'inflexion" ou la vitesse horizontale accélèrerait plus vite que la vitesse verticale. Par contre, la gravité est tellement basse qu'on peut difficilement dire qu'on a l'impression de tomber.

Deuxième élément: la portée du saut doit être prévisible. Si Bilou se déplace à sa vitesse maximale au sol (soit en courant, soit en marchant), il n'y a aucune raison qu'il se mette à accélérer une fois en l'air. Si on met exactement 1 seconde à franchir N blocs en marchant, alors on prendra 1 seconde à franchir ces N blocs en sautant pendant la marche et on saura les franchir si et seulement si le saut dure au moins une seconde.

L'exception à ce principe, c'est le saut depuis l'arrêt. Ici, on ne sait pas conserver l'énergie d'origine du personnage. Par contre, il me semble important que le joueur ne puisse pas atteindre la vitesse de course à partir d'un saut-à-l'arrêt.
Jusqu'ici, on va plutôt dans le sens de garder ce qui a déjà été développé. Une chose que je voudrais améliorer, par contre, c'est le tuning du saut à plus grande vitesse.

Le simple fait de relacher la direction "avant" lors d'un saut permet dans Bilou de retomber à une vitesse horizontale nulle. Par contre, si la vitesse retombe en-dessous de celle de la marche, il est impossible de remonter de nouveau à une vitesse plus élevée...
J'aimerais mieux pouvoir moduler la vitesse en relachant puis ré-enfonçant le pad. On pourrait du coup avoir n'importe quelle vitesse
entre la marche et la course.

Grosse difference par rapport au contrôle de Super Mario, donc, où si on veut si arrêter son saut, il faudra faire demi-tour avant d'avoir atteint la hauteur maximale.

Mais pour être franc, je dois admettre que j'aurais du mal à me séparer du comportement actuel. En particulier parce que ça donne la possibilité d'annuler un saut si jamais je n'avais pas assez de vitesse. un confort que Mario n'offre qu'aux plus ratons d'entre-nous.



Friday, August 03, 2018

Rolling Random Number.

I decided to map every known token of the GobExpressions onto the ASCII charset some other day. And it struck me that there was a pattern like "upper case for mostly side-effect actions" and "lower case for mostly functional actions". To some extent, the 'x' being used to call eXtra functions such as spawning new game objects, triggering sound effects and the like should be replaced by X. Tracking that in all the command files won't be trivial, though.

It could be tempting to use S(for score) as a function since we have i(ncrement counter) and d(ecrement counter), but unlike game counters, the score cannot be read again. It's more a side effect to change it than really some functional extension to the core arithmetics.

So where should "roll a dice to get a random number" go ? likely 'r'. What should be used to "get/set game state bit %n". That could be 'g' and 's'. Pretty handy map.

Et dans Wordpress ?

Peut-être qu'un jour je devrai migrer tout ceci hors de blogger. Avec google, qui peut savoir ? Ce qui est sûr, c'est que blogger depuis une tablette, c'est décevant. Et depuis un boox qui tourne un vieil androïd 4, c'est encore pire. Comme je suis tombé sur un autre bloggueur de homebrew sur wordpress et que je me suis rendu compte qu'il y avait une fonction "notification pour les (réponses aux) commentaires", j'ai voulu vérifier si le passage blogger->wordpress était possible. Un p'tit compte gratuit, un coup d'oeil dans les FAQs et en avant.

Côté PC, l'interface est assez chouette. Plus fonctionnelle et réactive la version dont je me souvenais pour l'avoir fait tourner sur le serveur de l'Université. Rien que les miniatures dans la liste des posts, c'est chouette et sympa.

Côté tablette, c'est un peu moins réussi. les miniatures sont devenues des images énormes: il y a à peine deux articles accessibles par écran. Aucun contrôle pour changer l'ordre, filtrer ni rien de ce genre ... Il faudrait scroller et scroller encore (avec la vitesse de rafraîchissement de l'écran à encre électronique qui ferait passer les pluies sahariennes pour un coup de karcher :-/). Et pour ne rien arranger, les posts brouillons sont mis en avant, dans un ordre que je peine encore à définir. Et des brouillons, j'en ai. 158. Enfin, au moins ça devrait m'encourager à en mettre plus au net.

Et la bonne nouvelle, c'est que le texte de tout ce petit monde semble avoir été téléchargé dans la tablette et que je peux donc éditer à l'envi tout ça du fond du jardin. Enfin, à condition de ne pas être rebuté par l'éditeur en version Andröid qui semble penser que juste de l'HTML brut, c'est assez pour tout le monde :-/

Mais bon, je peux le faire au stylet, écriture manuscrite et sans écran. Et ça, c'est présssscieux.

Mais le plus impressionnant dans l'aventure c'est sans doute que wordpress a ré-importé automatiquement les 500+ illustrations du blog. Difficile évidemment de s'assurer qu'elles y sont bien toutes, mais c'est déjà un énorme travail d'évité. Et la galerie fonctionne aussi sur tablette (à condition d'être connecté. 'faut pas trop en demander quand-même: 7.5% de 3Go, ça fait son poids dans la gestion de mémoire cache du boox.

Mais il doit en manquer parce que l'album google "photos de votre blog" en comptait pas loin de 1240...

Tuesday, July 31, 2018

Please define 'casual'

Is the NintendoDS retro ? will it ever be ? the question raised on twitter. Thinking about it, how it was launched and how different the titles available at launch were from other now-definitely-retro consoles (including SNES, PS1, and even GBA),
I'd say the NDS will have harder time to feel retro in general (although some games certainly will). The reason is that, by the time the Nintendo DS came out, the kind of games we played had changed significantly. GBA games play much like slightly simplified versions of SNES games all over the life time of the console. And they play themselves much like more refined versions of the NES games. The reason for all this is the controller.

To me, holding an SNES controller is a well-known feel. I don't have to think about where X or A stands. It is immediate. And it definitely wasn't the case when the SNES cames out: SMW gave me a hard time compared to the 1-button + dpad games I was used to (okay, I pressed SML B button from times to times). And for most games on those devices, it was frequent that you'd need to train yourself to the core mechanics and grow your controller skills before you could proceed further than world 1.

The DS, instead, came up in the world of casual games. Not games that you happen to play casually (as opposed to competitively), but those explicitly designed so that you don't really need training to experience their core gameplay. Zoo Keeper, for once, perfectly fits that line of titles targetted at bejeweled players. They're built around more intuitive and direct actions (thanks to the stylus). Any grown up can start playing them even when they have almost no training with gaming devices. They don't require players to know that they should hunt for 1-UPs or stock power-ups if they want to stand a chance against the end-of-world boss. Really, these are games that Hudson Hawk could have enjoyed despite he's been in jail since Pong is out.

That doesn't mean that there are no retro-like games on the system, but they were pretty rare gems compared to the avalanche of stylus-driven titles. And chances are that the youngster who had a DS as her first gaming system will have nostalgy towards titles that no longer plays like a DPAD+buttons retro game.

Will the NDS ever be retro ? of course. But it might have to wait until we no longer use touch screen as our primary model to design games. When virtual/augmented reality games become the norm, maybe.

Thursday, July 26, 2018

Madness? this is refactory !

Maybe you remember this picture, the first one I scanned with my iris mouse. Maybe you remember the times where I mentioned some more things in the collision engine needed a revision. At last, I'm at it.

When two objects collide, they need to have access to each other for some times until all the rules of their state machine have been evaluated. To do this, I used a "GobCollision" object, linking to the related objects, script variables and hit boxes (GobAreas). That was a nice first step towards clean design, but it still has some drawbacks, like using weird arrays of so-called "GobCollision" that each captured only one side of the collision, and copies into the array to somehow "swap" orders when the collision initiator finally runs the 'found' rule with the collided object as "other" (while it just was 'other' for the 'hit' rule on the collided object).

But I had a small extra "Swap()" call dangling around. With some odd effects on the game, as you can see. But hopefully, I just got it sorted out. Now I'll be ready to be gone with the "collision-specific variables" telling how much hitboxes overlap each other, which is currently stored as a game-wide static array, while it should really belong to the new, real collision state object.

Saturday, July 21, 2018

Junko Ozawa's Secrets

(re?-)Bienvenue à Upsilandre dans la blogosphère! Quel plaisir de pouvoir découvrir en détail ses analyses des techniques ancestrales de programmation assis confortablement avec ma liseuse. Son analyse de la "basse sunsoft" et l'utilisation du canal 'triangle' pour faire les drums (plutôt que le canal d-PCM comme dans SMB3) était un vrai délice. Du coup, j'ai envie de ressortir cette série de snapshot de l'interview de Junko Ozawa, responsable son et musique sur les jeux arcade Namco.

Très tôt déjà, alors que les générateurs simplistes de la NES semblaient riches en possibilités et que la FM faisaient ses premiers balbutiements, les machines NAMCO travaillaient déjà avec des échantillons. Enfin presque. Le hardware était capable de rejouer du contenu par modulation d'amplitude (PCM) sur 16 niveaux (4 bits) mais extrêmement courts ... disons 16 à 32 points par son. Plutôt que d'y envoyer par DMA un son enregistré en live de basse ou de trompette, Madame Ozawa va s'en servir pour comme d'un SID avec des ondes programmables. Des sons totalement synthétiques mais avec une signature unique. Pendant que Myamoto retranscrivait sur des petits carreaux les traits de Donkey Kong pour faire du pixel art, Madame se livrait au même travail à partir d'un son visualisé à l'oscilloscope pour faire reproduire à son soundchip une "trompette pixelisée" ou un "violon pixelisé".


La puissance, la tonalité, la rondeur, tout est personnalisable. Ecoutez donc Tower of Duaga de 1984. On est à des années-lumière de la sonorité d'une console atari! et la NES est encore sur Pluton.

Sa bibliotèque de sons, c'est le trésor de Mme Ozawa. Elle les conserve dans un cahier, vu l'absence d'éditeur numérique pour ce genre de choses. Et il faudra bien longtemps avant qu'un synthé ne puisse interpréter en direct les sons imaginés pour le Namco WSG.

[Les wave tables], c'est la base notamment du son PC-Engine dès 87, mais on retrouve ca aussi dans le Famicom Disk en 86 (y a qu'un seul canal mais de bonne résolution, 64x64), dans la Gameboy ou on a une wavetable 32x16 qui remplace le triangle wave de la NES (j'aurais aimé la même chose pour la NES), aussi dans le soundchip SCC de Konami qu'on retrouve dans les cartouches MSX de Konami tel que Contra.
Effectivement, je n'avais pas fait le rapprochement, mais c'est bien la même technique qui permet à la version "Famicom Disk System" de Legend of Zelda d'avoir quelques sons inédits par rapport à sa version NES (dixit Nathan dans "I AM ERROR"). Et on voit bien les patterns un peu exotiques tout en étant très clairement des ondes simples dans la séquence de fin de Link's Awakening.  


Bref, de mon côté (et surtout vu que je suis assez fan des sonorités de Coryoon et Soldier Blade sur PC-Engine), ça me donne furyeusement envie de coder un petit Wave Editor for DS ...


Friday, July 13, 2018

whipseey

A lovely setting, charming character, platforming action in pixel art, and above all, a "whip/ninja rope" mechanics I'm in love with since Fury of the Furries and Mickey Magical Quest. You bet I'm following @whipseey in his quest recovering the Lost Atlas ^_^. And the fact it is drawing inspiration from the legendary Mr. Gimmick is just the perfect spice to complete the gift.

Yet, while watching I realised that one of the sceneries had an issue that also existed in Bilou School Rush and that was pointed out by Kirby Kid when he gave feedback on the early version of the game: one-block-wide pillars.

You have a lot of "one block wide" or "character width wide" platforms. I find this irritating. They put a lot of stress on the mechanics and they also slow down the gameplay a lot. Open the platform spaces up some more.

 For the untrained player, these will put strong stress on the player's knowledge of the game engine's intimacy, like how much exactly gravity and momentum there is, so that one can land her favourite pink avatar on such a tiny spot.

One think I like to do on Twitter is to dream how I'd approach those short video  sequences myself. Preferably in the original character's abilities set, a bit like how Myamoto and his team decided to make Popeye be able to jump over barrels in the early prototypes of Donkey Kong as it was the most natural thing to do if it wasn't a videogame.

And what would be the most natural thing to do if you barely missed a jump to a pillar while carrying a magical yoyo/whip/rope thing ? Well I bet I'd try to wrap the rope around the pillar to be safe again.

That in turn raised the question of "how would I do such a thing for Bilou in my own engine?"  Should the 'whip' be an extension of the player's gob (that is, the internal software element ruling the sprite's behaviour) or be a gob of its own ? Should the pillar be made of special tiles or would the whip-end object (if any) be able to detect a pattern of solid-but-small-enough area ? Both approaches would be valid in each question, but as you may have guessed from the way I ask (or read in the sketches), I'd rather opt for the second answers if I was immediately ready to introduce that ;-)



Tuesday, July 10, 2018

contretemps

Non, ce n'est pas juste de la procrastination, ni juste des hunger games, ni de la démotivation ni juste ma déclaration d'impôts. Pas même une diablite mundialesque.

C'est le fichier de l'été. Tendinite à soigner. La semaine dernière, tenir un crayon était une torture. ça va un peu mieux.

Friday, June 29, 2018

Grand nettoyage de printemps ?

Bon, j'ai presque fini avec la révision des "évènements" provenant des contrôleurs de comportement (juste encore un peu de cleanup). Les histoires de signe sont réglées, Bilou fait à nouveau ses pirouettes comme il faut... et oui, j'ai encore fait du débugging avec des p'tits dessins.

Le dernier sur la liste des "grands nettoyages de printemps" devrait être l'élimination de GobExpression::xcontext, et je devrais avoir quelques notes là-dedans sur mon boox.

Après ça, il sera temps de tourner la page (parce que ça devient limite trop long, comme "printemps") vers de nouvelles aventures. J'ai bien progressé dans les recherches sur l'évolution du langage de scripting. Suis-je prêt pour attaquer le "behaviour editor on DS" ?

Tuesday, June 26, 2018

Guru Meditation again

Bon, je me suis retrouvé après avoir fait quelques essais du nouveau système de gestion des évènements de mon moteur de jeu avec un bel écran bleu. Sur DS uniquement, évidemment. Après quelques tentatives infructueuses de régler ça en une demie-heure, j'ai fini par profiter du fait que ma fée était en réunion pour me faire une soirée "guru méditation" à l'ancienne.

Papier quadrillé, désassemblage des fonctions impliquées (au moins, la position dans le programme était correcte), déduction de quel registre contient quelle variable (pour pouvoir exploiter le contenu de l'écran bleu) et structure physique des différents objets impliqués à grand coup de ddd en comparant le contenu "brut" de la mémoire et des affichages haut-niveau.

Vu que le crash se produit à cause d'un accès à la mémoire via quelque-chose qui n'a rien à voir avec un pointeur, j'étais prêt à rajouter des "nombres magiques" ça et là pour pouvoir reconnaître une transition, un état, une expression, etc. Mais en réalité, je n'ai besoin de rien de tout cela. Tous mes objets critiques ont au moins une méthode virtuelle, ce qui signifie que je peux utiliser la référence vers la vtable pour déterminer directement si une zone de mémoire donnée contient toujours un objet d'un type donné ou si elle a été écrasée.

A partir de là, c'est de la navigation dans la mémoire de la DS en suivant les pointeurs retrouvés sur l'écran bleu pour reconstruire l'état des objets impliqués dans le crash. Et au terme de tout ce sudoku-géant je finis par trouver deux indices troublant:
- l'adresse d'une des transitions à tester en cas d'évènement est un anagramme de l'adresse qui a causé le crash
- l'adresse de la liste de transitions correspondante n'est pas multiple de 4 alors que toutes les adresses ont une taille de 4 (bytes, mon cher Wattson).

L'émulateur voyant cet accès étrange aura "redresser" l'adresse, ignorant les bits les plus faibles. Parce que, oui, la machine sait que je veux prendre 32 bits quand-même. Le CPU de la DS, lui ... eh bien, il m'a sorti une variante mélangée des 32-bits se trouvant à l'adresse utilisée par l'émulateur. Les 8 bits "les plus à droite" de la valeur en mémoire se sont retrouvés à gauche pendant que tous les autres étaient décalés vers la droite.

Friday, June 22, 2018

deep blue InfiniMap

CommonMap revision changed the lookAt/scrollTo interface of background layers to take unsigned positions. After all, it shouldn't be possible to set the center of the screen into negative coordinates when the top-most corner is (0,0).

But I will need to keep internal computation of signed integers anyway. else I get blue meditation screens...

The core of the problem is that processors have two main way to understand numbers: one where the top bit of the number has no special meaning (we call them 'unsigned' numbers and they're all positive), and one where it tells whether the number is positive or negative (with some tweaks, and we call them 'signed' numbers). And among the operations the CPU can perform on number one behaves very differently on signed and unsigned numbers: division. Divide an unsigned number by two, and you'll always have to insert a zero in the top bit. Divide a signed number by two and the top bit remains sticky.

If you mess with the numbers signedness (issue unsigned operations when you should have used signed operations) and you may easily turn a small, negative number into a big, positive number during a division. That's what I did with my update ... this is what I have to fix now... hmm... tomorrow. It's time I give my eyes and brain some rest.

once upon a skunny

Ok, il y a les jeux qui vous motivent à les imiter, puis il y a les jeux qui vous motivent à faire mieux qu'eux pour prouver que c'est faisable. D'aussi loin que ça remonte, Skunny in the Wild West appartient à cette deuxième catégorie. Alors qu'on rêvait de pouvoir faire nos preuves sur Super Nintendo dans Bubsy, mon frangin ramène une diskette du supermarché avec la version shareware de Skunny. Une sorte de Mr Nutz pour PC ?

côté graphismes, Skunny nous démontre par l'absurde l'importance de la cohérence du style au sein d'un jeu. Un grand nombre des principes que je me suis juré de suivre du point de vue du pixel art vienne d'une négation de ce qui se passait dans ce jeu
- Tu ne numérisera pas des photos pour mettre dans ton jeu
- tu n'utilisera pas des lignes noires pour le contour de tes personnages.
- tu n'abusera pas des dégradés ni des tramages automatiques.

Rien que sur la séquence d'intro, Skunny fait tout l'inverse

Alors oui, ce dégradé pour le ciel est superbe. Et le canyon rend pas trop mal du tout pour du 256 couleurs. L'ennui, c'est que ça ne correspond absolument pas aux personnages ni au terrain du jeu. Exactement comme si vous preniez les playmobils des gamins et que vous les mettiez devant la peinture à l'huile de mamy pour tourner un mini-film avec des arbres en pâte à modeler.

Les personnages aux lignes noires (qui tuent le contraste et les applatissent) donnent un effet grotesque et décalé, style "bip-bip et le coyote". Le jeu devrait donc être humoristique et pris au second degré. Mais le décor, lui, est réaliste et avec perspective et profondeur, ce qui induit une forme de dramatisme. Au final, le mélange a un goût d'artifice. Comme un tour de magie dont on verrait le truc.

Autre exemple, le sol suggère que le les plate-formes se rétrécissent sur les bords gauche et droite. Un peu comme si on était sur un de ces plateaux circulaires. Mais la partie "verticale" de ce même sol reste elle parfaitement plate, sans aucun effet de luminosité ou de torsion de la texture pour soutenir ce que suggère la partie horizontale.

Alors oui, quand Morris dessine son "Canyon Apache", il utilise de l'encre de chine noire pour les traits. Mais l'épaisseur de trait par rapport à la surface du personnage n'a rien avoir avec du pixel art en 320x200. Et il n'a pas non plus besoin de faire de l'anti-aliasing. D'ailleurs, si on zoome sur une des cases de la BD, on se rend compte que les traits ne sont plus noirs, une fois la numérisation accomplie. Ils se sont mélangés avec la couleur de ce qu'ils entourent. Pour donner du brun le plus souvent. Et la résolution des sprites de skunny est 3 à 4 fois plus faible.

Je tente donc d'appliquer ça rapidement au screenshot de skunny. Et j'en profite pour essayer de corriger le dernier problème: l'équilibre entre le contraste de l'avant plan et de l'arrière plan. Les structures sur lesquelles ont doit se déplacer sont extrêmement délavées dans le jeu original, alors que le décor lui est dans des tonalités chaudes.

Or notre oeil à l'habitude que la distance "bleuisse" les choses et atténue les contraste. Il faudrait donc faire l'inverse: pousser le contraste et la saturation de l'avant-plan (et le ramener vers le rouge) tout en atténuant le contraste de l'arrière plan, diminuant également sa saturation en couleur (aller plus vers du pastel, quoi) et le décaler légèrement vers les bleus. Je n'ai pas touché au ciel lui-même: il est suffisamment en-dehors de la zone de jeu.

Et bien sûr, on s'abstient de faire pareil avec les masques gauche et droite. Ils avaient le gros défaut d'utiliser à peu près les même couleurs que le sol dans l'image originale, ce qui augmente encore la confusion.

Bon, ça ne sauverait pas le jeu dont le gameplay est infogramesque au possible (n'espérez pas ramasser plus d'une demi-douzaine de mouton lors de votre première partie), mais au moins on y verrait plus clair.

Bon, en dépit de tout ça, je dois reconnaître un sacré talent de programmation sur le moteur de jeu. Du scrolling parallaxe en 256 couleurs et fluide avec des sprites de cette taille-là, en 1994, j'aurais aimé en voir plus souvent. Et si la musique est répétitive, elle est présente et entraînante comme il se doit. Je ne peux pas m'empêcher de me demander ce que ça aurait donné si j'avais disposé de cette technologie pour réaliser Badman et Bilou... parce que le jeu est Belge! eh oui!

Saturday, June 16, 2018

iris mouse to the rescue

It is pretty handy to have the boox to draw sketches, but I don't find them as nice as the one I draw on paper. . Plus, when I'm using the boox to read the code, I can't update notes too. If I ever try, I'll have to face a near-minute swapping time every time.

So as I found the 'IRIScan Mouse' near my boarding gate, I just bought it. It's pretty funny. It's a hand-moved scanner (like the very first one I had) but fit into a mouse, and it can do both ... on Windows at least.

So it won't really make the USB printer/scanner obsolete at home, but it will certainly be helpful at the office. it has pretty nice rendering of my tiny handscript, avoids doing JPEG-by-default (afaik) and makes export of captured files pretty easy.

Or well, it should have been useful. Unfortunately, plugging the dongle into my Windows7 workstation didn't let me use the scanner feature. The mouse remains unreachable through the WiFi.

On my Linux laptop, all I see is a USB device with vendor ID 274f (Systech Electronics, according to dmesg) and product ID c001 (Zcan Wireless). no text identification of the device. The "mouse" feature does work, though. but I don't get an additional WiFi interface. So what is in the dongle exactly ? Some forum post suggests it is using the uvcvideo driver. It indeeds gets loaded. It doesn't seem like the USB device offers multiple

The dongle could be featuring just one NRF LU1P16 chip (there's one additional 1101GE marking), possibly made by NORDIC, although I couldn't find such a chip in their catalog.

But the original manufacturer's manual is clear:
Scan function requires Wi-Fi connection between computer and Zcan Wireless directly. Please add a Wi-Fi adapter (802.11 n is recommended) if Wi-Fi function is not available in your computer
my workstation at the office doesn't have any WiFi, and the dongle won't provide it. It also explains why scanning would fail on the office's laptop I've used so far when I had wifi enabled. When I'm actually connected to a network with my WiFi, the scanner can no longer reconfigure the WiFi interface to communicate with the mouse. Looks like I'll have to do some more shopping ...

Sunday, June 10, 2018

simplifying events engine

I want to get rid of some static pointers in the management of events. The idea turned cleaner as I was flying over Denmark. But the result isn't convincing yet.
- you can't jump out of inkjets anymore (event from dpad controller is ignored - apparently because TrackAttached produced an event too -- although it has no corresponding transitions)
- you might get pushed away from spongebops when you try to grab them -- weird things still occur here with my best solution for inkjets.
- if Bilou starts swimming up, he'll keep swimming up forever -- that's fixed with swapped-priorities
- the little stars shining around you when you pick a health bonus keep shining forever. -- seems fixed with swapped-priorities too.

The thing is, when I want to combine the "thoughts" of two controllers, only one events list can survive. And of course, things don't get fixed if I swap the order in which they are produced (unless I swap them properly, that is). Weird things remains with that swapped-priorities, though. Like why don't we play the 'roll-in-the-air' animation anymore when Bilou's direction is changed while jumping ? I'll have to re-activate InspectorWidget and use the combined powers of InspectorWidgets and DDD to find out.

By the way, did you know that we could have methods, operators overloading and constructors for unions ?

Friday, June 08, 2018

GameObject::useEvent() should go away.

https://sourceforge.net/p/dsgametools/hg/ci/refactory-engine/tree/libgeds/include/GameObject.h#l175
That shouldn't happen. The way controllers fire an event is not satisfying. A static pointer set by class X so that it is used by class Y with no restriction on who does what and that merely works because we know X calling ::useEvent() and Y checking *::doevents happens to take place with the right timing ? No.

I mean, look at the documentation: "assumes no re-entrance until gobRunController". That has turned false the minute I introduced 'attach-to-other-game-object' feature where you might have to run the object you're attached to before you can run yourself.

I'd like to convert {NONE, FAIL, EVENT}  enum into something else that allow "EVENT" to carry the list of transitions to check by itself.

Sunday, June 03, 2018

bubsy

I think I was 20 years younger the last time I need a SNES gamepad to press start on Bubsy title screen. After a month of training, I was able to reach world 4 and found a few 2"continues". I couldn't beat the level 3 last week-end, but at least I got the confirmation that Bubsy "claws encounters" is a fun game.

It might be the only fun thing made with that character (I do not expect much of Black Forrest's "woolies strike back"), it may have arguable pixel art, the tunes are catchy, the atmosphere is playful, the character is fun, and there is enough variety in the level design to keep us entertained.


It is clearly difficult and sometimes even frustrating without becoming utterly unfair or boring. As far as I've played it, it is challenging.


It is far from being a masterpiece in terms of game mechanics, though. The air control is sometimes a bit awkward, Packing precision, - and the "GLIDE" mechanics isn't always sufficient to save the day, But what really seem broken is what happen when you jump off a slope. First, you don't move purely upwards (if standing), but slightly backwards on a climbing slope. You'll have to compensate that with more air control. I've never seen that happening to any mammal in the real world, presumably because we feel the slope and compensate when jumping. But I can accept it: it makes sense from a pure physics perspective, and it echoes a similar mechanics in Sonic. What is broken is that if you then release the directions pad, you will find yourself pushed backwards again!