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





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. 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!