Snake de subpixel [Vídeo]

• Um jogo de Snake que usa os subpixels dentro dos pixels do monitor como casas do tabuleiro; é tão pequeno que, para jogar de verdade, seria preciso um microscópio
• Com base no JavaScript Snake original, combina cores por posição de coluna com mix-blend-mode: lighten para fazer vários subpixels dentro do mesmo pixel físico aparecerem juntos
• Para funcionar corretamente, são necessários uma estrutura de subpixels RGB stripe e o alinhamento entre pixels CSS e pixels físicos; no iMac isso foi ajustado com zoom out, mas no iPad não funcionou
• Ao verificar com um microscópio, descobriu-se que o verde sRGB não acendia apenas o subpixel verde, mas também o vermelho e o azul; confirmou-se que a causa era a gama de cores mais ampla dos displays modernos
• Ao usar Lab color, foi possível separar os subpixels vermelho e verde no iMac, mas como a estrutura dos pixels está se afastando do padrão RGB stripe, a compatibilidade de longo prazo é fraca

---

Usando subpixels como tabuleiro de jogo

• Este jogo de Snake usa não os pixels normais do monitor, mas os subpixels vermelho, verde e azul dentro de cada pixel como se fossem as casas do jogo
• De perto, os pixels da tela são compostos por vários subpixels; de longe, esses pontos de luz se misturam aos olhos humanos e parecem uma única cor
• Ao fotografar várias telas com uma lente macro recebida no Natal, foi possível confirmar que o formato dos subpixels varia de display para display
  • formato chevron
  • formato stripe
  • padrão diamond
• Essas diferenças de arranjo são chamadas de geometria de subpixels, e o iMac do autor usa uma estrutura RGB stripe

Método de implementação e limitações reveladas pelo microscópio

• A implementação básica para adaptar o JavaScript Snake feito há 15 anos para subpixels foi relativamente simples
  • reduzir o número de colunas do jogo
  • fazer com que blocos da Snake em determinadas colunas apareçam em cores específicas
  • aplicar mix-blend-mode: lighten para que, mesmo havendo vários blocos dentro do mesmo pixel, todos possam ser vistos
• Para funcionar de fato, duas condições precisavam ser atendidas
  • o usuário precisava usar um monitor com estrutura de subpixels RGB stripe
  • os pixels CSS do navegador precisavam estar alinhados com os pixels físicos
• O alinhamento dos pixels CSS podia ser ajustado com zoom out, mas esse método só funcionou no iMac e falhou no iPad
• A implementação terminou rapidamente, mas como não era possível verificar a exibição em nível de subpixel a olho nu, o autor fotografou a tela real com um microscópio barato comprado online
• Observando pelo microscópio, ao exibir a cor verde, não se acendia apenas o subpixel verde; vários subpixels eram ativados ao mesmo tempo
  • no início suspeitou-se de um bug, mas não havia problema no código
  • ao verificar um verde sólido, no iMac acendiam não só o subpixel verde, mas também os vermelho e azul
  • no celular, a cor verde também acendia fracamente o subpixel vermelho
• Segundo o responsável pela página sobre geometria de subpixels, a causa era a diferença entre o padrão sRGB e a gama de cores dos displays modernos
  • o sRGB foi criado em uma época em que o desempenho das telas e a gama de cores eram mais limitados
  • em telas modernas, acender apenas o subpixel verde pode gerar uma cor mais saturada do que o verde sRGB
  • para exibir com precisão o verde sRGB desejado, é preciso adicionar também vermelho e, em alguns casos, azul
• Ao mudar a definição de RGB para Lab color, foi possível usar um espaço de cor maior e separar os subpixels vermelho e verde no iMac
• Ainda assim, como a geometria dos pixels está se afastando do padrão RGB stripe e os subpixels do futuro podem acender de forma completamente diferente da atual, esse método tende a ser difícil de manter por muito tempo

[GN⁺]

Comentários no Hacker News

• Ao ler o texto vinculado do Subpixel Zoo, descobri que PenTile ainda é usado de forma extremamente ampla.
  A primeira tela PenTile que usei foi a do Motorola Droid 4, e ela era bem ruim. Textos pequenos eram difíceis de ler dependendo da cor do texto e do fundo, e como o espaçamento entre as cores era grande, áreas sólidas em vermelho/verde/azul pareciam um tabuleiro xadrez.
  Antes mesmo de o termo screen door effect ficar comum com a popularização da RV, ela já dava essa impressão. Por isso fiquei surpreso ao saber que PenTile ainda é usado; provavelmente ele melhorou, ou o espaçamento entre subpixels diminuiu, ou a resolução e a densidade de pixels maiores escondem as fraquezas que apareciam no Droid 4.

  • As primeiras telas PenTile tinham um arranjo diferente: [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)
    Nos eixos horizontal/vertical, a ordem era azul, verde, vermelho, verde, então um subpixel vermelho ficava tão distante quanto dois verdes e um azul.
    Telas PenTile modernas geralmente usam um arranjo triangular: https://static1.xdaimages.com/wordpress/wp-content/uploads/w...
    Não sou especialista em renderização de texto, mas com esse arranjo triangular parece ser possível colocar combinações de subpixels RGB muito mais próximas do que em um arranjo linear. Além disso, o Droid 4 tinha resolução baixa. A Apple foi para 330 ppi em 2010, enquanto o Droid 4 tinha 275 ppi em 2012, então era baixo até para a época, e o PenTile deve ter piorado isso ao reduzir um terço dos subpixels.
    Hoje, o Galaxy S25 tem 416 ppi e o iPhone 16 tem 460 ppi, então há muito mais pixels. A densidade de pixels provavelmente é o fator que mais pesa, mas o arranjo triangular das telas modernas também deve ajudar.
  • É exatamente por isso. A resolução do Droid 4 era baixa o bastante para o arranjo de subpixels ficar visível, enquanto as telas modernas têm densidade alta e os subpixels simplesmente não aparecem.

• A cobra se move de um jeito estranho porque os subpixels não são quadrados.
  Seria melhor aumentar a velocidade de movimento horizontal em relação à vertical, tomando os subpixels como referência, para que, na tela real, o usuário a veja se movendo à mesma velocidade em qualquer direção.

• Como alguém obcecado por jogos retrô de arcade, que montou por conta própria um gabinete de emulação de ponta com um CRT analógico RGB quad-sync de 27 polegadas, gostei deste vídeo.
  No momento em que ele explicou que encontrou o problema do pixel verde, senti na hora que aprenderia algo interessante. Estrutura de subpixels, cromaticidade dos fósforos e coisas do tipo são uma toca de coelho divertida quanto mais você se aprofunda, e continuam muito relevantes nas telas de hoje, como OLED e QLED.
  Para jogar clássicos retrô de arcade ou console dos anos 80 e 90, é muito melhor e mais próximo do original jogar em um CRT. Se for por emulação, basta ativar um pixel shader de emulação de CRT (CRT Royale é bom). Essa pixel art foi criada por desenvolvedores e artistas da época explorando intencionalmente a mistura de cores e o antialiasing natural das scanlines dos CRTs. Vale a pena vê-la do modo originalmente pretendido: https://i.redd.it/9fmozdvt6vya1.jpg

  • Como alguém que gosta de hardware retrô de verdade, esse gabinete parece incrível. Dá vontade de colocar um monte de moedas e jogar por horas.
    Este texto me fez cair na toca de coelho da simulação de CRT, e isso realmente existe:
    https://github.com/blurbusters/crt-beam-simulator
  • Gostaria de ouvir mais sobre a configuração. Seria ótimo se houvesse um blog com o registro disso.
  • Não gosto daquele visual borrado de LCD. Parece que alguém hackeou um .ini para aumentar o antialiasing para quatro vezes acima do limite e colocou uma tela mosquiteira na frente do monitor.
    Eu joguei na época da transição dos CRTs para LCDs, e ninguém preferia os gráficos dos CRTs.
    O verdadeiro retrocesso foi quando os jogos saíram do PC e foram para os consoles, matando os servidores dedicados. Antes, eu escolhia servidores com latência de 10 ms; hoje, 60 a 100 ms ou mais é considerado aceitável.
  • É difícil acreditar na afirmação de que “é preciso ver do modo originalmente pretendido”. Cresci jogando em CRTs, mas os CRTs reais variavam muito em nitidez, cor e artefatos, e também mudavam enormemente conforme o tipo de saída/entrada de vídeo.
    Dependia de estar ligado a uma TV, a um monitor barato ou a um monitor caro, e a única coisa que dá para afirmar com certeza é que os CRTs eram mais borrados. A imagem comparativa apresentada é enganosa porque o brilho é completamente diferente. O lado LCD/LED parece não estar usando a gama correta.
    Usar um CRT qualquer tinha uma boa chance de transformar tons de pele em algo esverdeado, e os artefatos de cor dos CRTs podiam ser sérios. Entendo borrar a imagem em emuladores para reduzir serrilhado, e efeitos retrô de CRT são enfeites divertidos, mas não consigo aceitar a afirmação de que era “a aparência pretendida do jogo”. É parecido com dizer que música dos anos 90 precisa ser ouvida em alto-falantes baratos e com barulho de estrada para estar “do jeito pretendido”. Era simplesmente o melhor que era possível na época.
  • Aquilo parece ser imagens parecidas, mas diferentes.
    Cresci com CRTs, mas pouquíssimos jogos “ficavam melhores” em CRT; em geral eram jogos que usavam entrelaçamento para criar efeitos de cintilação. Além disso, pistolas de luz precisam de CRT por causa do timing.
    Fora isso, CRT é parecido com vinil. Há quem invente todo tipo de motivo para dizer que é melhor, mas na prática não é.

• Foi realmente fascinante. Aprendi bastante sobre espaço de cores e como isso se aplica aos subpixels, e valeu a pena assistir ao vídeo.
  Do ponto de vista da jogabilidade, acho que seria preciso aumentar o tabuleiro e compensar a velocidade da cobra ao passar por cada subpixel. Ao se mover para a esquerda ou para a direita, ir de R para G envolve um deslocamento horizontal menor do que ir de B para R, e no movimento vertical cada etapa é muito grande em comparação com a horizontal.
  Ajustar proporcionalmente a velocidade de cada etapa da animação conforme a posição no espectro de cores parece resolver isso com bastante facilidade, e daria uma sensação muito mais polida.

• Legal. Em um monitor 1440p, consegui jogar usando uma lupa de cabeça[1] e reduzindo a velocidade em 10 vezes.
  Com densidade de pixels maior, acho que seria necessário um microscópio de verdade.
  [1] https://www.amazon.com/ProsKit-MA-016-Personal-Headband-Magn...

• QBasic Nibbles também fazia a mesma coisa com caracteres ANSI de desenho de caixas.
  Havia um caractere de texto que usava só metade da “célula” vertical e, combinando de forma esperta as cores de primeiro plano e de fundo, dava para dobrar a resolução vertical no modo texto.

• Se você, como eu, for bobo o bastante para tentar jogar de verdade, é bom saber que o valor de Snake speed funciona ao contrário.

  • A velocidade é em milissegundos por frame.

• Alguém aqui é velho o bastante para lembrar a diversão que era ajustar o ClearType no Windows XP?
  Era uma ótima gambiarra para renderizar texto mais suave em LCDs de baixa resolução.

  • Ainda dá para fazer isso no Windows 10. Só não é mais tão divertido.

• A maneira mais fácil de ver subpixels é colocar uma gota d’água sobre a tela. Provavelmente dá algo como 100x de ampliação :)

• Na parte de ajustar o zoom para alinhar pixels CSS com pixels reais, acho que bastaria usar unidades como 0.25px.
  Ou talvez dividir dinamicamente por window.devicePixelRatio em JavaScript.