Snake en sous-pixels [vidéo]

 (youtube.com)
2 points par GN⁺ 2025-01-26 | 1 commentaires | Partager sur WhatsApp
  • Un jeu de Snake qui utilise les sous-pixels à l’intérieur des pixels du moniteur comme cases de jeu, si petits qu’il faut un microscope pour y jouer correctement
  • À partir d’un Snake en JavaScript existant, il combine la couleur selon la position en colonne et mix-blend-mode: lighten pour rendre visibles plusieurs sous-pixels au sein d’un même pixel physique
  • Pour fonctionner correctement, il faut une structure de sous-pixels RGB stripe et un alignement entre pixels CSS et pixels physiques ; sur l’iMac, cela a pu être ajusté en zoomant en arrière, mais pas sur l’iPad
  • En vérifiant au microscope, le vert sRGB n’allumait pas uniquement le sous-pixel vert, mais aussi les rouges et bleus ; la cause a été attribuée à la gamme de couleurs plus large des écrans récents
  • En utilisant la couleur Lab, il a été possible de séparer les sous-pixels rouges et verts sur l’iMac, mais la compatibilité à long terme reste faible car la structure des pixels s’éloigne du RGB stripe

Utiliser les sous-pixels comme plateau de jeu

  • Ce jeu de Snake n’utilise pas les pixels ordinaires du moniteur, mais les sous-pixels rouge, vert et bleu à l’intérieur des pixels comme cases de jeu
  • Vu de près, les pixels de l’écran sont composés de plusieurs sous-pixels ; vus de loin, l’œil humain perçoit la lumière combinée comme une seule couleur
  • En photographiant plusieurs écrans avec un objectif macro reçu à Noël, il a constaté que la forme des sous-pixels variait selon les écrans
    • forme chevron
    • forme stripe
    • motif en diamant
  • Ces différences d’agencement relèvent de la géométrie des sous-pixels, et l’iMac de l’auteur utilise une structure RGB stripe

Mise en œuvre et limites révélées par le microscope

  • L’adaptation en version sous-pixels d’un Snake en JavaScript créé il y a 15 ans a été relativement simple
    • réduire le nombre de colonnes du jeu
    • faire afficher les blocs du Snake d’une certaine colonne dans une certaine couleur
    • appliquer mix-blend-mode: lighten pour que plusieurs blocs présents dans un même pixel restent tous visibles
  • Pour que cela fonctionne réellement, deux conditions devaient être réunies
    • l’utilisateur devait disposer d’un moniteur à structure de sous-pixels RGB stripe
    • les pixels CSS du navigateur devaient être alignés avec les pixels physiques
  • L’alignement des pixels CSS pouvait être obtenu en zoomant en arrière, mais cette méthode n’a fonctionné que sur l’iMac et a échoué sur l’iPad
  • L’implémentation a été rapide, mais comme il était impossible de vérifier visuellement l’affichage au niveau des sous-pixels, un microscope bon marché acheté en ligne a servi à photographier l’écran réel
  • Au microscope, il est apparu que l’affichage du vert n’allumait pas seulement le sous-pixel vert, mais plusieurs sous-pixels à la fois
    • au début, cela a été pris pour un bug, mais le code n’avait pas de problème
    • en vérifiant un vert uni, l’iMac allumait non seulement le sous-pixel vert, mais aussi les sous-pixels rouge et bleu
    • sur téléphone aussi, le vert allumait faiblement le sous-pixel rouge
  • Après avoir contacté l’administrateur d’un site consacré à la géométrie des sous-pixels, il est apparu que la cause venait de l’écart entre le standard sRGB et la gamme de couleurs des écrans récents
    • sRGB a été conçu à une époque où les performances et la gamme de couleurs des écrans étaient plus limitées
    • sur un écran récent, n’allumer que le sous-pixel vert peut produire une couleur plus saturée que le vert sRGB
    • pour afficher précisément le vert sRGB voulu, il faut aussi ajouter du rouge, et parfois du bleu
  • En remplaçant la définition RGB des couleurs par la couleur Lab, il a été possible d’exploiter un espace colorimétrique plus large pour séparer les sous-pixels rouges et verts sur l’iMac
  • Toutefois, la géométrie des pixels s’éloigne du RGB stripe, et les sous-pixels du futur pourraient s’allumer d’une manière complètement différente de celle d’aujourd’hui, ce qui rend cette approche difficile à maintenir dans la durée

À lire aussi

1 commentaires

 
GN⁺ 2025-01-26
Avis sur Hacker News

  • En lisant l’article lié Subpixel Zoo, j’ai découvert que PenTile est encore très largement utilisé
    Le premier écran PenTile que j’ai utilisé était celui du Motorola Droid 4, et il était vraiment mauvais. Les petits caractères étaient difficiles à lire selon la couleur du texte et celle du fond, et l’espacement important entre les couleurs faisait que les zones unies rouges/vertes/bleues ressemblaient à un damier
    J’avais déjà cette impression avant même que l’expression effet de grille ne devienne courante avec la démocratisation de la VR. J’ai donc été surpris que PenTile soit encore utilisé ; il s’est probablement amélioré, ou bien l’espacement entre sous-pixels a diminué, ou encore les résolutions et densités de pixels plus élevées masquent les faiblesses visibles sur le Droid 4

    • Les premiers écrans PenTile avaient une disposition différente : [https://en.wikipedia.org/wiki/PenTile_matrix_family#/media/F...](https://en.wikipedia.org/wiki/PenTile_matrix_family#/media/File:Nexus_one_screen_microscope.jpg)
      Sur les axes horizontal/vertical, l’ordre était bleu, vert, rouge, vert, si bien qu’un sous-pixel rouge était aussi éloigné que deux verts et un bleu
      Les écrans PenTile modernes utilisent généralement une disposition triangulaire : https://static1.xdaimages.com/wordpress/wp-content/uploads/w...
      Je ne suis pas spécialiste du rendu de texte, mais avec cette disposition triangulaire, il semble possible de rapprocher bien davantage les combinaisons de sous-pixels RGB qu’avec une disposition linéaire. En plus, le Droid 4 avait une faible résolution. Apple était passé à 330 ppp en 2010, tandis que le Droid 4 était à 275 ppp en 2012, ce qui était déjà plutôt bas pour l’époque, et PenTile a probablement aggravé les choses en retirant un tiers des sous-pixels
      Aujourd’hui, le Galaxy S25 est à 416 ppp et l’iPhone 16 à 460 ppp, donc il y a beaucoup plus de pixels. La densité de pixels est sans doute le facteur principal, mais la disposition triangulaire des écrans modernes doit aussi aider
    • C’est exactement pour cette raison. La résolution du Droid 4 était assez basse pour que la disposition des sous-pixels soit visible à l’œil nu, alors que les écrans récents ont une densité telle que les sous-pixels ne se voient plus du tout

  • Si le serpent se déplace bizarrement, c’est parce que les sous-pixels ne sont pas carrés
    Pour que l’utilisateur ait l’impression, sur un vrai écran, qu’il avance à la même vitesse quelle que soit la direction, il faudrait augmenter la vitesse horizontale par rapport à la verticale en termes de sous-pixels

  • En tant que passionné de jeux rétro d’arcade au point d’avoir construit moi-même une borne d’émulation haut de gamme avec un CRT analogique RGB quadrisync de 27 pouces, j’ai apprécié cette vidéo
    Dès le moment où il explique avoir rencontré le problème des pixels verts, j’ai senti que j’allais apprendre quelque chose d’intéressant. La structure des sous-pixels, la chromaticité des phosphores, etc., sont des terriers fascinants dès qu’on commence à creuser, et restent très pertinents pour les écrans actuels comme les OLED et QLED
    Pour les jeux rétro classiques d’arcade ou de console des années 80-90, jouer sur CRT est bien meilleur et plus proche de l’original. Si vous passez par l’émulation, activez un pixel shader d’émulation CRT (CRT Royale est excellent). Ce pixel art a été créé par les développeurs et artistes de l’époque en tirant délibérément parti du mélange des couleurs et de l’anticrénelage naturel des lignes de balayage des CRT. Cela vaut la peine de le voir de la manière prévue à l’origine : https://i.redd.it/9fmozdvt6vya1.jpg

    • En tant qu’amateur de vrai matériel rétro, une borne comme ça a l’air géniale. Ça donne envie d’y mettre des tas de pièces pendant des heures
      À cause de ce commentaire, je suis tombé dans le terrier de la simulation CRT, et il existe vraiment des choses comme ça
      https://github.com/blurbusters/crt-beam-simulator
    • J’aimerais en savoir plus sur ta configuration. Ce serait bien si tu avais un blog ou quelque chose du genre où tu l’as documentée
    • Je n’aime pas ce rendu LCD flou. On dirait que quelqu’un a hacké un .ini pour pousser l’anticrénelage quatre fois au-delà de la limite, puis a posé une moustiquaire devant le moniteur
      J’ai joué à l’époque de la transition du CRT vers le LCD, et personne ne préférait les graphismes des CRT
      Le vrai recul, c’est quand les jeux sont passés du PC aux consoles et que les serveurs dédiés ont disparu. Avant, on choisissait un serveur à 10 ms de latence ; maintenant, 60 à 100 ms ou plus est considéré comme acceptable
    • L’argument selon lequel il faut « voir les choses comme elles étaient prévues à l’origine » est difficile à croire. J’ai grandi en jouant sur CRT, mais les vrais CRT variaient énormément en netteté, en couleurs et en artefacts, et cela dépendait aussi beaucoup des modes de sortie/entrée vidéo
      Selon qu’on était branché à une télé, à un moniteur bon marché ou à un moniteur cher, le rendu changeait ; la seule chose qu’on puisse dire avec certitude, c’est que les CRT étaient plus flous. L’image de comparaison proposée est trompeuse, car la luminosité est complètement différente. Le côté LCD/LED ne semble pas utiliser le bon gamma
      Avec n’importe quel CRT, il y avait aussi de bonnes chances que les tons chair virent au vert, et les artefacts de couleur des CRT pouvaient être sérieux. Je comprends qu’on floute l’image dans les émulateurs pour réduire l’effet d’escalier, et les effets CRT rétro sont un décor amusant, mais j’ai du mal à accepter l’idée que ce soit « l’apparence voulue par le jeu ». C’est un peu comme dire qu’il faut écouter la musique des années 90 sur des enceintes bon marché au milieu du bruit de la circulation pour l’entendre « comme prévu ». C’était simplement le mieux qu’on pouvait faire à l’époque
    • On dirait que ce sont deux images similaires, mais différentes
      J’ai grandi avec des CRT, mais très peu de jeux y paraissaient « meilleurs » ; c’était surtout le cas de jeux qui utilisaient l’entrelacement pour créer des effets de scintillement. Les pistolets optiques nécessitent aussi un CRT pour des raisons de timing
      Pour le reste, les CRT ressemblent au vinyle. Certains inventent toutes sortes de raisons pour dire que c’est mieux, mais en réalité ce n’est pas le cas

  • C’était vraiment fascinant. J’ai beaucoup appris sur les espaces colorimétriques et sur la manière dont ils s’appliquent aux sous-pixels, et je suis content d’avoir regardé la vidéo
    Côté gameplay, il faudrait probablement agrandir le plateau et corriger la vitesse du serpent lorsqu’il traverse chaque sous-pixel. Lors d’un déplacement horizontal, passer de R à G représente un déplacement horizontal plus petit que de B à R, et verticalement chaque étape est très grande par rapport à l’horizontale
    Il semble assez simple de corriger la vitesse de chaque étape d’animation en proportion selon la position dans le spectre de couleurs, et le résultat paraîtrait beaucoup plus soigné

  • Excellent. Sur un moniteur 1440p, avec une loupe serre-tête[1] et une vitesse ralentie par 10, j’ai pu y jouer
    Avec une densité de pixels plus élevée, il faudrait probablement un vrai microscope
    [1] https://www.amazon.com/ProsKit-MA-016-Personal-Headband-Magn...

  • QBasic Nibbles faisait déjà la même chose avec les caractères ANSI de tracé de boîtes
    Il y avait un caractère texte qui n’utilisait que la moitié d’une « cellule » verticale, et en combinant astucieusement les couleurs de premier plan et d’arrière-plan, on pouvait doubler la résolution verticale en mode texte

  • Si, comme moi, vous êtes assez idiot pour essayer d’y jouer pour de vrai, sachez que la valeur Snake speed fonctionne à l’envers

    • La vitesse est exprimée en millisecondes par image

  • Y a-t-il ici des gens assez vieux pour se souvenir du plaisir de régler ClearType sous Windows XP ?
    C’était un excellent contournement pour rendre du texte plus lisse sur les LCD basse résolution

    • On peut encore le faire sous Windows 10. C’est juste beaucoup moins amusant maintenant

  • La manière la plus simple de voir les sous-pixels consiste à poser une goutte d’eau sur l’écran. Ça doit probablement faire un grossissement d’environ 100× :)

  • Pour la partie où il ajuste le zoom afin d’aligner les pixels CSS sur les vrais pixels, je me dis qu’il suffirait d’utiliser une unité comme 0.25px
    Ou alors, en JavaScript, on pourrait l’ajuster dynamiquement en divisant par window.devicePixelRatio