2 puntos por GN⁺ 2025-01-26 | 1 comentarios | Compartir por WhatsApp
  • Un juego de Snake que usa los subpíxeles dentro de los píxeles del monitor como casillas del juego, tan pequeño que hace falta un microscopio para jugarlo bien
  • Basado en un JavaScript Snake existente, combina colores por posición de columna y mix-blend-mode: lighten para hacer visibles juntos varios subpíxeles dentro del mismo píxel físico
  • Para funcionar correctamente necesita una estructura de subpíxeles RGB stripe y alineación entre píxeles CSS y píxeles físicos; en iMac se ajustó haciendo zoom out, pero en iPad no funcionó
  • Al revisarlo con un microscopio, se vio que el verde sRGB no encendía solo el subpíxel verde, sino también el rojo y el azul, y se confirmó que la causa era la gama de color más amplia de las pantallas modernas
  • Al usar Lab color, fue posible separar los subpíxeles rojo y verde en iMac, pero como la estructura de píxeles se está alejando del RGB stripe, la compatibilidad a largo plazo es débil

Usar subpíxeles como tablero de juego

  • Este juego de Snake no usa los píxeles normales del monitor, sino los subpíxeles rojo, verde y azul dentro de cada píxel como si fueran casillas del juego
  • Vistos de cerca, los píxeles de la pantalla están compuestos por varios subpíxeles; vistos de lejos, el ojo humano percibe esas luces mezcladas como un solo color
  • Mientras fotografiaba varias pantallas con un lente macro que recibió en Navidad, confirmó que la forma de los subpíxeles varía según la pantalla
    • Forma chevron
    • Forma stripe
    • Patrón diamond
  • A estas diferencias de disposición se les llama geometría de subpíxeles, y el iMac del autor usa una estructura RGB stripe

Método de implementación y límites revelados por el microscopio

  • La implementación básica para adaptar un JavaScript Snake hecho hace 15 años a subpíxeles fue relativamente simple
    • Reducir la cantidad de columnas del juego
    • Hacer que los bloques de Snake en ciertas columnas se muestren con un color específico
    • Aplicar mix-blend-mode: lighten para que, aunque haya varios bloques dentro del mismo píxel, todos sigan siendo visibles
  • Para que realmente funcionara, tenían que cumplirse dos condiciones
    • El usuario debía usar un monitor con estructura de subpíxeles RGB stripe
    • Los píxeles CSS del navegador debían estar alineados con los píxeles físicos
  • La alineación de píxeles CSS podía ajustarse haciendo zoom out, pero este método solo funcionó en iMac y falló en iPad
  • La implementación se terminó rápido, pero como no era posible verificar a simple vista la visualización a nivel de subpíxel, el autor fotografió la pantalla real con un microscopio barato comprado en línea
  • Al verlo con el microscopio, notó que al mostrar color verde no se encendía solo el subpíxel verde, sino varios subpíxeles al mismo tiempo
    • Al principio sospechó de un bug, pero no había problemas en el código
    • Al comprobar un verde sólido, en el iMac se encendían no solo el verde sino también los subpíxeles rojo y azul
    • En el teléfono también el color verde encendía débilmente el subpíxel rojo
  • Tras consultar al responsable de una página sobre geometría de subpíxeles, se confirmó que la causa era la diferencia entre el estándar sRGB y la gama de color de las pantallas modernas
    • sRGB se creó en una época en la que el rendimiento y la gama de color de las pantallas eran más limitados
    • En pantallas modernas, encender solo el subpíxel verde puede producir un color más saturado que el verde sRGB
    • Para mostrar con precisión el verde sRGB deseado, también hay que añadir rojo y, en algunos casos, azul
  • Al cambiar la definición RGB a Lab color, fue posible aprovechar un espacio de color más grande para separar los subpíxeles rojo y verde en iMac
  • Aun así, la geometría de píxeles se está alejando del RGB stripe, y como en el futuro los subpíxeles podrían encenderse de una forma completamente distinta a la actual, este método será difícil de mantener durante mucho tiempo

1 comentarios

 
GN⁺ 2025-01-26
Opiniones en Hacker News
  • Al ver el artículo enlazado de Subpixel Zoo me enteré de que PenTile todavía se usa muchísimo
    La primera pantalla PenTile que probé fue la del Motorola Droid 4, y era realmente mala. El texto pequeño era difícil de leer según el color de la letra y el fondo, y como había mucho espacio entre colores, las áreas sólidas de rojo/verde/azul se veían como un tablero de ajedrez
    Ya tenía esa sensación incluso antes de que, con la popularización de la VR, se volviera común hablar del efecto de puerta de pantalla. Por eso me sorprendió que PenTile todavía se use; supongo que mejoró, o se redujo la separación entre subpíxeles, o la mayor resolución y densidad de píxeles ocultan las debilidades que se veían en el Droid 4

    • Las primeras pantallas PenTile tenían una disposición distinta: [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)
      En los ejes horizontal/vertical iban azul, verde, rojo, verde, así que un subpíxel rojo estaba separado tanto como dos verdes y uno azul
      Las pantallas PenTile modernas suelen usar una disposición triangular: https://static1.xdaimages.com/wordpress/wp-content/uploads/w...
      No soy experto en renderizado de texto, pero con esta disposición triangular parece que se pueden acercar mucho más las combinaciones de subpíxeles RGB que con una disposición lineal. Además, el Droid 4 también tenía baja resolución. Apple pasó a 330 ppi en 2010, mientras que el Droid 4 tenía 275 ppi en 2012, así que incluso para la época era más bien bajo, y PenTile lo habría empeorado al reducir un tercio de los subpíxeles
      Hoy el Galaxy S25 tiene 416 ppi y el iPhone 16, 460 ppi, así que hay muchísimos más píxeles. La densidad de píxeles probablemente sea lo que más influye, pero la disposición triangular de las pantallas modernas también debería ayudar
    • Exactamente por eso. La resolución del Droid 4 era lo bastante baja como para que se notara la disposición de subpíxeles, mientras que las pantallas actuales tienen tanta densidad que los subpíxeles directamente no se ven
  • La serpiente se mueve raro porque los subpíxeles no son cuadrados
    Para que en una pantalla real el usuario la vea moverse a la misma velocidad en cualquier dirección, convendría aumentar la velocidad de movimiento horizontal respecto de la vertical, medida en subpíxeles

  • Como alguien obsesionado con los juegos retro de arcade, que armó su propio gabinete de emulación de alta gama con un CRT analógico RGB quad-sync de 27 pulgadas, me gustó este video
    En cuanto explicó que se había topado con el problema del píxel verde, supe de inmediato que iba a aprender algo interesante. La estructura de subpíxeles, la cromaticidad de los fósforos y temas así son una madriguera fascinante cuanto más profundizas, y siguen siendo muy relevantes en pantallas actuales como OLED y QLED
    Para jugar clásicos retro de arcade o consola de los 80 y 90, es mucho mejor y más fiel al original hacerlo en un CRT. Si juegas por emulación, basta con activar un shader de píxeles de emulación CRT (CRT Royale es bueno). Este pixel art fue creado por desarrolladores y artistas de la época aprovechando deliberadamente la mezcla de colores y el antialiasing natural de las líneas de barrido de los CRT. Vale la pena verlo como fue concebido originalmente: https://i.redd.it/9fmozdvt6vya1.jpg

    • Como alguien a quien le gusta el hardware retro real, ese gabinete suena genial. Dan ganas de meterle un montón de monedas y jugar durante horas
      Por este texto caí en la madriguera de la simulación CRT, y resulta que esto existe
      https://github.com/blurbusters/crt-beam-simulator
    • Me gustaría saber más sobre tu configuración. Ojalá tengas algún blog donde la hayas documentado
    • No me gusta ese aspecto de LCD borroso. Parece como si alguien hubiera hackeado el .ini para subir el antialiasing a 4 veces por encima del límite y hubiera puesto una mosquitera frente al monitor
      Jugué durante la transición de CRT a LCD, y nadie prefería los gráficos de los CRT
      El verdadero retroceso fue cuando los juegos pasaron de PC a consolas y murieron los servidores dedicados. Antes elegías un servidor con 10 ms de latencia; ahora se considera aceptable 60–100 ms o más
    • Me cuesta creer el argumento de que “hay que verlo como fue concebido originalmente”. Crecí jugando en CRT, pero los CRT reales variaban muchísimo en nitidez, color y artefactos, y también cambiaban mucho según el método de salida/entrada de video
      Dependía de si lo conectabas a un televisor, a un monitor barato o a uno caro, y lo único que se podía afirmar con seguridad era que los CRT eran más borrosos. La imagen comparativa presentada induce a error porque el brillo es completamente distinto. Parece que el lado LCD/LED no usa la gamma correcta
      Con cualquier CRT había bastante probabilidad de que los tonos de piel se volvieran verdosos, y los artefactos de color de los CRT podían ser graves. Entiendo desenfocar la imagen en un emulador para reducir el aliasing, y los efectos retro de CRT son una decoración divertida, pero me cuesta aceptar que eso sea “cómo debía verse el juego”. Es parecido a decir que para escuchar música de los 90 “como fue concebida” hay que hacerlo con parlantes baratos y ruido de tráfico de fondo. Eso simplemente era lo mejor posible en ese momento
    • Eso parece una imagen parecida, pero distinta
      Crecí con CRT, pero muy pocos juegos se “veían mejor” en CRT; en general eran los que usaban entrelazado para crear efectos de parpadeo. Además, las pistolas de luz necesitan CRT por una cuestión de timing
      Fuera de eso, los CRT son como el vinilo. Hay gente que inventa todo tipo de razones para decir que es mejor, pero en realidad no lo es
  • Fue realmente interesante. Aprendí mucho sobre el espacio de color y cómo se aplica a los subpíxeles, y me alegra haber visto el video
    En cuanto al gameplay, creo que habría que agrandar el tablero y corregir la velocidad de la serpiente al pasar por cada subpíxel. Al moverse de izquierda a derecha, pasar de R a G implica menos desplazamiento horizontal que pasar de B a R, y el movimiento vertical tiene pasos muy grandes en comparación con el horizontal
    Creo que podría resolverse bastante fácil ajustando proporcionalmente la velocidad de cada paso de animación según en qué punto del espectro de color esté la posición, y eso daría una sensación mucho más pulida

  • Genial. En un monitor 1440p pude jugar usando una lupa de diadema[1] y bajando la velocidad 10 veces
    Con más densidad de píxeles probablemente haría falta un microscopio de verdad
    [1] https://www.amazon.com/ProsKit-MA-016-Personal-Headband-Magn...

  • QBasic Nibbles hacía lo mismo con caracteres ANSI de dibujo de cajas
    Había caracteres de texto que usaban solo la mitad de una “celda” vertical y, combinando de forma inteligente los colores de primer plano y fondo, se podía duplicar la resolución vertical en modo texto

  • Si, como yo, intentas jugarlo tontamente de verdad, conviene saber que el valor Snake speed funciona al revés

    • La velocidad está en milisegundos por cuadro
  • ¿Hay alguien lo bastante viejo como para recordar lo divertido que era ajustar ClearType en Windows XP?
    Era un excelente atajo para renderizar texto más suave en LCD de baja resolución

    • Todavía se puede hacer en Windows 10. Solo que ya no es tan divertido
  • La forma más fácil de ver los subpíxeles es poner una gota de agua sobre la pantalla. Probablemente con eso se logre algo así como 100× de aumento :)

  • Sobre la parte de hacer zoom para alinear los píxeles CSS con los píxeles reales, creo que bastaría con usar unidades como 0.25px
    O también se podría ajustar dinámicamente en JavaScript dividiendo por window.devicePixelRatio