En musique spectrale, on est amené à procéder à l'analyse harmonique d'un son, c'est-à-dire décomposer son timbre en une somme de signaux élémentaires, appelés harmoniques, généralement pour mieux pouvoir le reconstituer. Ici le processus est moins ambitieux : on se contente de parcourir une à une les premières harmoniques d'un nombre limité de notes, jouées au piano, sans chercher à les superposer. Mais pas n'importe comment.
\nL'algorithme à suivre est directement inspiré des règles du jeu de société Serpents et échelles, mais avec quelques différences.
\nLe tout se joue sur un plateau rectangulaire dont chaque case correspond à une note. Sur chaque rangée sont disposées une fréquence fondamentale et ses harmoniques, arrondies au demi-ton le plus proche. Les rangées sont elle-mêmes à un demi-ton d'intervalle.
\nChaque pion devient ici un doigt d'un pianiste, mais il pourrait tout à fait s'agir d'un instrument différent pour chaque pion. Lorsque qu'un doigt se rend sur une case, la note spécifiée est jouée.
\nInitialement, au lieu d'être tous placés sur la même case, les doigts sont répartis totalement aléatoirement sur la grille.
\nÀ chaque tour, le déplacement d'un doigt donné est le résultat de deux lancers de dé. Le premier, qui a autant de faces que la largeur du plateau, donne son déplacement horizontal. Contrairement au jeu de société, on ne change pas de rangée lorsqu'on arrive à une extrémité, on fait juste demi-tour. Le seul moyen de passer d'une rangée à une autre est d'emprunter un des serpents ou échelles qui relient les cases correspondant aux mêmes notes. C'est le second dé qui détermine sur laquelle de ces cases on se rend. À noter que serpents et échelles sont ici confondus. Ils peuvent être empruntés dans n'importe quel sens.
\nLe but du jeu est d'atteindre la case correspondant à la note la plus grave. Une fois qu'un doigt l'a atteinte, on laisse toutefois les autres doigts finir leur propre tour.
\nPour certaines tailles de plateau, il existe cependant des configurations initiales qui ne permettent pas de terminer la partie.
\nLes doigts ont donc exactement le même nombre de tours et donc de notes à jouer. Cependant, il ne jouent pas l'un après l'autre, mais indépendamment, sans aucune interruption, en commençant tout de même exactement en même temps, ce qui forme un accord duquel émergent des arpèges. L'interprétation d'une note reprend certains concepts de musique spectrale, déjà explorés dans la pièce Bien à toi de José Manuel López López : moins d'importance est donnée aux harmoniques lointaines de leurs fondamentales, en réduisant leur durée et leur intensité. Mais ici elles ne sont pas pour autant plus fréquentes. Puisque les durées varient, la note la plus grave n'est donc pas nécessairement la dernière à être entendue. Aussi, puisque les doigts sont indépendants, des notes appartenant à des spectres différents peuvent très bien être entendues en même temps.
\nUne démonstration en direct est aussi disponible ici. Le synthétiseur utilise la sound font Fluid R3 publiée par Frank Wen sous la licence MIT et pré-rendue par Benjamin Gleitzman sous la licence Creative Commons Attribution 3.0 United States.
\n", "banner_image": "./snakes-and-ladders/*.png", "tags": [] }, { "title": "Monitoring des traductions de Super Bear Adventure", "summary": "Outil utilisé par la communauté pour évaluer la qualité des traductions de Super Bear Adventure", "image": "./translations-monitor/*.svg", "date_published": "2023-09-05", "authors": [ { "name": "PolariTOON" } ], "external_url": "//github.com/PolariTOON/translations-monitor", "id": "translations-monitor", "content_html": "Ce projet a commencé en août 2022. La refonte de l'ultime niveau du jeu Super Bear Adventure, la ruche, était en développement et la nouvelle fin du jeu qui se profilait imposait une réécriture complète du scénario. Cela nécessitait de passer en revue et de mettre à jour l'intégralité des traductions existantes, soit plus de 600 lignes de textes pour chacun des 14 langages pris en charge. Les traductions étant hébergées dans Google Sheet, il n'était pas évident de suivre les évolutions de la version originale (l'anglais) et d'identifier ce sur quoi travailler, d'autant que le niveau de maintenance des différents langages était déjà assez disparate.
\nPour procéder à cet effort de manière méthodique et éviter de perdre en qualité au niveau des traductions, j'ai donc créé ce script assez simple exportant les traductions pour les versionner avec Git et pour générer des rapports d'avancement pour chaque langage. Le versionnage permettait d'identifier les modifications substantielles apportées à la version anglaise, tandis que les rapports fréquents permettaient de déterminer certaines lacunes historiques et certains besoin propres à chaque traduction vis à vis de la version anglaise.
\nVoici une description de la signification de chaque section dans les rapports, à destination des traducteurs :
\nextra
La ligne n'existe pas dans le fichier anglais, donc le jeu n'utilise pas cette ligne.
\n\t\tElle peut avoir été supprimée du fichier anglais ou vous pouvez vous être trompé sur son nom.
\n\t\tCorrigez le nom de la ligne ou supprimez-la.
\n\textra, but optional
La ligne existe dans le fichier anglais, et vous avez fait une traduction pour cette ligne dans votre fichier.
\n\t\tVous pouvez la retirer si la version anglaise a du sens dans votre langage.
\n\t\tCela apparaîtra dans missing, but optional
la prochaine fois.
missing
La ligne existe dans le fichier anglais mais pas dans votre langage.
\n\t\tIl peut s'agir d'une nouvelle ligne.
\n\t\tAjoutez la ligne à votre fichier et traduisez-la.
\n\tmissing, but optional
La ligne existe dans le fichier anglais, et vous n'avez pas fait de traduction pour cette ligne.
\n\t\tMais vous pouvez en ajouter une si la version anglaise n'a pas de sens dans votre langage.
\n\t\tCela apparaîtra dans extra, but optional
la prochaine fois.
multiple
Plusieurs lignes ont le même nom dans votre fichier, donc le jeu utilise la première.
\n\t\tLe développeur duplique parfois des lignes de manière à vous dire que la ligne anglaise a beaucoup changé.
\n\t\tSupprimez la ligne qui est obsolète.
\n\ttransparent
Ce sont exactement les mêmes mots que dans le fichier anglais.
\n\t\tCela peut être normal si la ligne se traduit par elle-même, ou alors elle peut encore être en anglais et vous avez oublié de la traduire.
\n\t\tTraduisez la ligne si besoin ou ignorez-la si c'est délibéré.
\n\tÀ noter que les rapports ne sont pas exhaustifs. L'outil ne détecte pas si les traductions sont dépassées ou si les lignes sont encore écrites en anglais sans pour autant être identiques à la version originale. Cependant, même en étant aussi rudimentaires, de telles informations ont été cruciales et ont permis à la communauté de réaliser des traductions complètes pour la plupart des langages pris en charge par le jeu en quelques mois seulement.
\nAvec l'accord du développeur du jeu, le code source est désormais disponible sur GitHub.
\n", "banner_image": "./translations-monitor/*.png", "tags": [] }, { "title": "Monitoring des speedruns de Super Bear Adventure", "summary": "Outil utilisé par la communauté pour visualiser la chronologie des speedruns de Super Bear Adventure", "image": "./speedruns-monitor/*.svg", "date_published": "2023-09-05", "authors": [ { "name": "PolariTOON" } ], "external_url": "//github.com/PolariTOON/speedruns-monitor", "id": "speedruns-monitor", "content_html": "Ce projet a commencé en juin 2021. La dernière mise à jour du jeu Super Bear Adventure, remplaçant le moteur physique du joueur par un nouveau, était à peine sortie qu'il apparaissait qu'elle apportait son lot de breaking changes en ce qui concerne les speedruns. En particulier, les changements relatifs au quad rendait impossible de rivaliser avec les records du monde dans deux sous-catégories des niveaux individuels. Il apparaîtra plus tard qu'un boss du jeu était aussi concerné, avec une incidence encore plus importante sur de nombreuses catégories l'incluant.
\nPour la première fois dans l'histoire des niveaux individuels de ce jeu, qui sont bien plus populaires que les catégories plus longues comme l'Any%
, il était nécessaire de scinder des catégories en deux, en fonction de la version du jeu utilisée, afin de permettre à la compétition de pouvoir reprendre. Or, jusqu'à peu, cette information n'avait jamais été demandée aux joueurs soumettant leurs speedruns, et ne pouvait pas systématiquement être identifiée avec certitude rien qu'à partir des vidéos, lorsqu'elles étaient toujours disponibles.
Pour correctement séparer les runs et éviter de rencontrer ce genre de difficultés dans le futur en cas de nouveau breaking change (ce qui arrivera plus d'une fois par la suite), j'ai donc étendu la tâche à l'intégralité des speedruns déjà soumis, que j'ai visionnés un par un et étiquetés lorsqu'il était possible d'être formel, en me basant sur les dates de soumission des speedruns, les dates des vidéos et différents indices à l'écran, après avoir déterminé au mieux les dates de sorties de chaque mise à jour, de chaque costume et de chaque changement majeur de l'interface graphique.
\nCependant, pour la majorité des speedruns, seule une fourchette de versions plus ou moins large pouvait être attribuée. J'ai donc créé ce script exportant les données des speedruns déjà connues, afin d'estimer les données manquantes en les interpolant ou extrapolant. Après quelques années, tous les speedruns valides ont été étiquetés.
\nLe code source est désormais disponible sur GitHub.
\n", "banner_image": "./speedruns-monitor/*.png", "tags": [] }, { "title": "Visionneuse Spotify", "summary": "Visualisation des titres favoris dans Spotify", "image": "./spotify-viewer/*.svg", "date_published": "2023-06-13", "authors": [ { "name": "PolariTOON" } ], "external_url": "//github.com/PolariTOON/spotify-viewer", "id": "spotify-viewer", "content_html": "Le nom n'est pas très original, comme il s'agit seulement d'une petite preuve de concept d'une application se connectant à un tiers (Spotify en l'occurrence) grâce à une autorisation OAuth 2.0. Elle permet à l'utilisateur de consulter et de modifier sa liste de musiques favorites via des appels à l'API. Pour éviter de complexifier, le jeton d'accès n'est ni stocké ni rafraîchi, ce qui a l'inconvénient de demander une autorisation à chaque ouverture de la page, ce qui bien sûr ne serait pas approprié pour un usage réel. Le code source est disponible sur GitHub.
\n", "banner_image": "./spotify-viewer/*.png", "tags": [] }, { "title": "Bruitage d'images vectorielles", "summary": "Un court pipeline de filtres générant une image du soleil", "date_published": "2021-03-16", "authors": [ { "name": "PolariTOON" } ], "external_url": "./vector-graphics-noising", "id": "vector-graphics-noising", "image": "./vector-graphics-noising/*.svg", "content_html": "Hier est paru un article sur CSS Tricks par Bence Szabó, traitant de la création de motifs à base de filtres SVG. Recourir à dégradés CSS pour générer des motifs ne m'est pas inconnu, mais je n'ai jamais pris le temps de me pencher réellement sur les techniques équivalentes en SVG. Or le champ des possibles qu'offre SVG me semble bien plus large, notamment grâce à la possibilité de générer du bruit. J'ai donc voulu essayer, et tel un enfant faisant son premier dessin, j'ai représenté... le soleil.
\nJ'ai repris quasiment telle quelle l'idée du fond étoilé généré pseudo-aléatoirement avec du bruit via l'élément <feTurbulence />. J'ai juste ajusté les différents poids de la matrice pour avoir des étoiles de couleurs variées, quoiqu'essentiellement jaunes, au lieu d'être systématiquement blanches.
<filter id=\"sky\">
<feTurbulence type=\"fractalNoise\" baseFrequency=\".25\" />
<feColorMatrix values=\"32 0 0 0 -24
24 0 0 0 -18
16 0 0 0 -12
0 0 0 0 1\" />
</filter>
<rect width=\"100%\" height=\"100%\" filter=\"url(#sky)\" />
![\"\"](\"./background.svg\")
Au passage, en voulant indenter la chose, j'ai découvert à mes dépens que Webkit n'apprécie pas les espaces en début et fin de la valeur de l'attribut values=\"\" de l'élément <feColorMatrix />. La solution de contournement est vite trouvée...
Un simple disque jaune pour dépeindre le soleil aurait fait tâche sur ce fond étoilé. Pour réprésenter son rayonnement et éviter d'avoir un contour trop net, j'ai ajouté un dégradé externe variant du jaune au rouge en partant du bord.
\n<radialGradient id=\"gradient\" fr=\"33.3%\" r=\"50%\">
<stop offset=\"3.125%\" stop-color=\"#ff0f\" />
<stop offset=\"6.25%\" stop-color=\"#fc0c\" />
<stop offset=\"12.5%\" stop-color=\"#f909\" />
<stop offset=\"25%\" stop-color=\"#f606\" />
<stop offset=\"50%\" stop-color=\"#f303\" />
<stop offset=\"100%\" stop-color=\"#f000\" />
</radialGradient>
<circle cx=\"50%\" cy=\"50%\" r=\"96\" fill=\"url(#gradient)\" />
![\"\"](\"./disk.svg\")
Mieux. Un peu trop parfait en fait. Comment faire pour avoir une forme un peu moins ronde ? Il se trouve que l'élément <feDisplacementMap/> permet précisément de créer un effet de distortion bidirectionnelle sur une image. Et en lui donnant du bruit en entrée, on peut obtenir une sorte de blob à la forme assez irrégulière ! N'en abusons pas, tout de même.
<filter id=\"sun\">
<feTurbulence type=\"fractalNoise\" baseFrequency=\".125\" numOctaves=\"2\" />
<feDisplacementMap xChannelSelector=\"R\" yChannelSelector=\"G\" in=\"SourceGraphic\" scale=\"16\" />
</filter>
<circle cx=\"50%\" cy=\"50%\" r=\"96\" filter=\"url(#sun)\" />
![\"\"](\"./blob.svg\")
Pas mal ! On croirait voir les éruptions solaires ionisant la couronne du soleil ! Il ne manque plus que la touche finale : animer le tout. Mais pour garder une animation régulière avec une échelle de bruit assez uniforme, la technique consacrée, bien qu'assez simple à mettre en place, semble vraiment relever de la magie. On peut en voir une démonstration sur Codepen par Michael Mullany. Au lieu d'animer la fréquence, l'astuce est de passer le bruit à travers un filtre de couleurs qui opère une rotation progressive sur la teinte selon le cercle chromatique. Cela permet d'exploiter le bruit généré sur le troisième canal de couleur, au lieu de se limiter à deux comme c'était le cas précédemment, mais aussi à l'animation de boucler.
\n<filter id=\"sun\">
<feTurbulence type=\"fractalNoise\" baseFrequency=\".125\" numOctaves=\"2\" />
<feColorMatrix type=\"hueRotate\">
<animate attributeName=\"values\" from=\"0\" to=\"360\" dur=\"4s\" repeatCount=\"indefinite\" />
</feColorMatrix>
<feDisplacementMap xChannelSelector=\"R\" yChannelSelector=\"G\" in=\"SourceGraphic\" scale=\"16\" />
</filter>
<circle cx=\"50%\" cy=\"50%\" r=\"96\" filter=\"url(#sun)\" />
![\"\"](\"./rotation.svg\")
Je reste étonné du si peu de code nécessaire pour parvenir à un tel effet. Assemblons tout ça et jetons un œil au résultat final sans plus attendre !
\n![\"\"](\"./sun-over-a-starry-sky.svg\")
Une démonstration est aussi disponible ici.
\n", "banner_image": "./vector-graphics-noising/*.png", "tags": [] }, { "title": "Lancer de rayons", "summary": "Deux fragment shaders affichant des sphères et des tétrahèdres", "date_published": "2020-02-28", "authors": [ { "name": "PolariTOON" } ], "external_url": "./ray-tracing", "id": "ray-tracing", "image": "./ray-tracing/*.svg", "content_html": "Dans le cadre d'un projet, j'ai eu l'occasion de découvrir GLSL (pour OpenGL Shading Language), et de programmer mes premiers shaders, mon expérience avec le graphisme par ordinateur se résumant jusque là à de la 2D avec SVG et l'élément HTML <canvas></canvas> (ou des technologies équivalentes). L'objectif ici est d'implémenter du lancer de rayon, de la 3D donc. Heureusement, des environnements comme Geoshade ou Shadertoy permettent d'itérer et d'obtenir un retour assez rapidement lors du développement de shaders, ou devrais-je dire, de fragment shaders pour être correct, ces outils ne couvrant pas les vertex shaders, une autre étape majeur du pipeline de rendu d'OpenGL. Le challenge est donc de parvenir à calculer un rendu complet dans un unique shader en faisant abstraction du reste du pipeline.
Les deux shaders présentés ici réalisent donc du lancer de rayons, que je présume physiquement simpliste et plutôt sous-optimal étant données les structures de données utilisées et leurs performances, sur deux types de surfaces, respectivement des sphères et des triangles assemblés en tétrahèdres. Ils n'en restent pas moins essentiellement identiques ; seuls la nature des objets, l'algorithme d'intersection et le calcul d'orientation des surfaces varient entre eux. Pour bénéficier des dernières fonctionnalités de GLSL, les shaders ont été développés et testés sur Shadertoy.
\nLes programmes macro-définissent trois constantes : SPHERE_COUNT / TETRAHEDRON_COUNT, RING_COUNT et REFLECTION_COUNT. Celles-ci représentent respectivement :
le nombre de sphères / tétrahèdres par anneau ;
\n\tle nombre d'anneaux ;
\n\tle nombre de réflexions.
\n\tVoici quelques ensembles de valeurs qui donnent des résultats intéressants :
\n{SPHERE_COUNT: 27, RING_COUNT: 1, REFLECTION_COUNT: 0}{TETRAHEDRON_COUNT: 9, RING_COUNT: 1, REFLECTION_COUNT: 0}Une simple chaîne de sphères mates / tétrahèdres mats tournoyant autour d'une source de lumière
\n\t{SPHERE_COUNT: 27, RING_COUNT: 1, REFLECTION_COUNT: 2}{TETRAHEDRON_COUNT: 9, RING_COUNT: 1, REFLECTION_COUNT: 2}La même scène, mais avec des surfaces polies
\n\t{SPHERE_COUNT: 9, RING_COUNT: 2, REFLECTION_COUNT: 0}{TETRAHEDRON_COUNT: 3, RING_COUNT: 2, REFLECTION_COUNT: 0}Deux couches de sphères mates / tétrahèdres mats tournoyant autour d'une source de lumière
\n\t{SPHERE_COUNT: 9, RING_COUNT: 2, REFLECTION_COUNT: 2}{TETRAHEDRON_COUNT: 3, RING_COUNT: 2, REFLECTION_COUNT: 2}La même scène, mais avec des surfaces polies
\n\tLes rendus ci-dessous ont été obtenus avec le dernier ensemble de paramètres. Contrairement aux sphères qui ne sont composées que d'une face, les tétrahèdres en ont quatre, ce qui a clairement une incidence sur les performances du second shader ; c'est pourquoi il convient de réduire le nombre de tétrahèdres.
\nLe fond à été bruité pseudo-aléatoirement pour éviter de le confondre avec les ombres qui sont quant à elles noires en absence de réflexions.
\nAu lieu d'utiliser une projection orthographique, la scène est rendue en perspective. Pour cela, il est nécessaire de définir la focale de la caméra dont l'objectif est le canevas. Dans le code, il s'agit de la variable perspective. Celle-ci peut être ajustée pour modifier l'impression de profondeur. Il faut noter que dans la démarche de lancer de rayons, le rayon part bien de l'objectif et non du foyer pour éviter d'afficher les objets se situant entre les deux.
La source de lumière est ponctuelle et au centre de la scène. L'intensité lumineuse de cette source est calculée de manière à être en tout point inversement proportionnelle au carré de la distance parcourue depuis la source (y compris après une réflexion). La puissance maximale de la source de lumière est stockée dans la variable power et peut être ajustée. Il faut noter que les surfaces sont orientées. Si la source se situe à l'intérieur d'un objet, alors la lumière le traverse mais ne s'y réfléchit pas : il cachera les objets se situant derrière, mais sans faire d'ombre à toute la scène.
Une démonstration en direct est aussi disponible ici. À savoir que les calculs sont potentiellement intensifs et des problèmes de rendu sont attendus sur les appareils avec une représentation des nombres à virgule flottante de moyenne / faible précision.
\n", "banner_image": "./ray-tracing/*.png", "tags": [] } ] }