2P by GN⁺ | ★ favorite | 댓글 1개
  • 모니터 픽셀 안의 서브픽셀을 게임 칸으로 쓰는 Snake 게임으로, 너무 작아 제대로 플레이하려면 현미경이 필요함
  • 기존 JavaScript Snake를 바탕으로 열 위치별 색상과 mix-blend-mode: lighten을 조합해, 같은 물리 픽셀 안의 여러 서브픽셀이 함께 보이게 만듦
  • 정상 동작하려면 RGB stripe 서브픽셀 구조와 CSS 픽셀·물리 픽셀 정렬이 필요하며, iMac에서는 줌아웃으로 맞췄지만 iPad에서는 통하지 않았음
  • 현미경으로 확인하자 sRGB 초록색이 초록 서브픽셀만 켜지지 않고 빨강·파랑도 함께 켰고, 최신 디스플레이의 더 넓은 색역이 원인으로 확인됨
  • Lab color를 쓰자 iMac에서 빨강과 초록 서브픽셀을 분리할 수 있었지만, 픽셀 구조가 RGB stripe에서 벗어나고 있어 장기 호환성은 약함

서브픽셀을 게임 보드로 쓰기

  • 이 Snake 게임은 모니터의 일반 픽셀이 아니라 픽셀 내부의 빨강·초록·파랑 서브픽셀을 게임 칸처럼 사용함
  • 가까이서 보면 화면의 픽셀은 여러 서브픽셀로 구성되어 있고, 멀리서 보면 사람 눈에는 이 빛들이 섞여 하나의 색으로 보임
  • 크리스마스에 받은 매크로 렌즈로 여러 화면을 촬영하면서, 디스플레이마다 서브픽셀 형태가 다르다는 점을 확인함
    • Chevron 형태
    • stripe 형태
    • diamond 패턴
  • 이런 배열 차이는 서브픽셀 기하 구조로 불리며, 제작자의 iMac은 RGB stripe 구조를 사용함

구현 방식과 현미경으로 드러난 한계

  • 15년 전에 만든 JavaScript Snake를 서브픽셀용으로 바꾸는 기본 구현은 비교적 단순했음
    • 게임 열 수를 줄임
    • 특정 열의 Snake 블록이 특정 색으로 표시되게 함
    • mix-blend-mode: lighten을 적용해 같은 픽셀 안에 여러 블록이 있어도 모두 보이게 함
  • 실제로 동작하려면 두 조건이 맞아야 했음
    • 사용자가 RGB stripe 서브픽셀 구조의 모니터를 써야 함
    • 브라우저의 CSS 픽셀이 물리 픽셀과 정렬되어야 함
  • CSS 픽셀 정렬은 줌아웃으로 맞출 수 있었지만, 이 방법은 iMac에서만 동작했고 iPad에서는 실패함
  • 구현은 빠르게 끝났지만 서브픽셀 단위 표시를 눈으로 확인할 수 없어, 온라인에서 산 저가 현미경으로 실제 화면을 촬영함
  • 현미경으로 보니 초록색을 표시할 때 초록 서브픽셀만 켜지지 않고 여러 서브픽셀이 함께 켜졌음
    • 처음에는 버그로 의심했지만 코드에는 문제가 없었음
    • 단색 초록을 확인하자 iMac에서 초록뿐 아니라 빨강·파랑 서브픽셀도 켜짐
    • 휴대폰에서도 초록색이 빨강 서브픽셀을 약하게 켰음
  • 서브픽셀 기하 구조 페이지 운영자에게 문의한 결과, 원인은 sRGB 표준과 최신 디스플레이 색역의 차이였음
    • sRGB는 화면 성능과 색역이 더 좁던 시기에 만들어짐
    • 최신 화면에서 초록 서브픽셀만 켜면 sRGB 초록보다 더 채도가 높은 색이 나올 수 있음
    • 원하는 sRGB 초록을 정확히 표시하려면 빨강, 경우에 따라 파랑도 함께 더해져야 함
  • RGB 색 정의를 Lab color로 바꾸자, 더 큰 색공간을 활용해 iMac에서 빨강과 초록 서브픽셀을 분리할 수 있었음
  • 다만 픽셀 기하 구조가 RGB stripe에서 멀어지고 있고, 미래의 서브픽셀이 지금과 완전히 다르게 켜질 수 있어 이 방식은 오래 유지되기 어려움

댓글과 토론

Hacker News 의견들
  • 링크된 Subpixel Zoo 글을 보고 PenTile이 아직도 엄청 널리 쓰인다는 걸 알게 됨
    처음 써본 PenTile 화면은 Motorola Droid 4였는데 정말 별로였음. 작은 글자는 글자색과 배경색에 따라 읽기 어려웠고, 색 사이 간격이 커서 빨강/초록/파랑 단색 영역이 체커보드처럼 보였음
    VR이 대중화되며 스크린 도어 효과라는 말이 흔해지기 전부터 이미 그런 느낌이 있었음. 그래서 PenTile이 아직도 쓰인다는 게 놀라웠고, 아마 더 좋아졌거나 서브픽셀 간격이 줄었거나, 더 높은 해상도와 픽셀 밀도가 Droid 4에서 보이던 약점을 가려주는 듯함

    • 초기 PenTile 디스플레이는 배열이 달랐음: [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)
      가로/세로 축에서 파랑, 초록, 빨강, 초록 순서라서 빨강 서브픽셀 하나가 초록 둘과 파랑 하나만큼 떨어져 있었음
      현대 PenTile 디스플레이는 보통 삼각형 배열을 씀: https://static1.xdaimages.com/wordpress/wp-content/uploads/w...
      텍스트 렌더링 전문가는 아니지만, 이 삼각형 배열이면 선형 배열보다 RGB 서브픽셀 조합을 훨씬 가깝게 만들 수 있어 보임. 게다가 Droid 4는 해상도도 낮았음. Apple은 2010년에 330ppi로 갔는데 Droid 4는 2012년에 275ppi였으니 당시 기준으로도 낮은 편이고, PenTile이 서브픽셀 3분의 1을 줄이면서 더 나빠졌을 것임
      요즘 Galaxy S25는 416ppi, iPhone 16은 460ppi라 픽셀이 훨씬 많음. 픽셀 밀도가 가장 큰 영향을 주겠지만, 현대 디스플레이의 삼각형 배열도 도움이 될 듯함
    • 정확히 그 때문임. Droid 4 해상도는 서브픽셀 배열이 눈에 보일 정도로 낮았고, 최신 디스플레이는 밀도가 높아서 서브픽셀이 아예 보이지 않음
  • 뱀이 이상하게 움직이는 건 서브픽셀이 정사각형이 아니기 때문
    실제 화면에서 사용자가 보기엔 어느 방향으로 가도 같은 속도로 보이도록, 세로 대비 가로 이동 속도를 서브픽셀 기준으로 더 높이면 좋겠음

  • 아케이드 레트로 게임에 집착해서 27인치 쿼드싱크 아날로그 RGB CRT가 들어간 고급 에뮬레이션 캐비닛을 직접 만든 입장에서 이 영상 좋았음
    초록 픽셀 문제를 만났다고 설명하는 순간 뭔가 흥미로운 걸 배우게 되겠다고 바로 느낌. 서브픽셀 구조, 형광체 색도 같은 건 파고들수록 재미있는 토끼굴이고, 오늘날 OLED, QLED 같은 디스플레이에도 여전히 관련이 큼
    80~90년대 클래식 아케이드나 콘솔 레트로 게임을 할 때는 CRT에서 하는 게 훨씬 좋고 더 원본에 가까움. 에뮬레이션으로 한다면 CRT 에뮬레이션 픽셀 셰이더를 켜면 됨(CRT Royale이 좋음). 이 픽셀 아트는 당시 개발자와 아티스트들이 CRT의 색 혼합과 주사선의 자연스러운 안티앨리어싱을 의도적으로 활용해 만든 것임. 원래 의도된 방식으로 볼 가치가 있음: https://i.redd.it/9fmozdvt6vya1.jpg

    • 진짜 레트로 하드웨어를 좋아하는 입장에서 그런 캐비닛은 멋져 보임. 몇 시간 동안 동전을 잔뜩 넣고 플레이하고 싶어짐
      이 글 때문에 CRT 시뮬레이션 토끼굴에 빠졌는데, 실제로 이런 게 있음
      https://github.com/blurbusters/crt-beam-simulator
    • 설정을 더 들어보고 싶음. 기록해 둔 블로그 같은 게 있으면 좋겠음
    • 흐릿한 LCD 느낌은 별로임. 누가 .ini를 해킹해서 안티앨리어싱을 한계보다 4배 높이고 모니터 앞에 방충망을 놓은 것 같음
      CRT에서 LCD로 넘어가던 시절에 게임을 했는데, CRT의 그래픽을 더 선호하는 사람은 없었음
      진짜 하향은 게임이 PC에서 콘솔로 옮겨가면서 전용 서버가 죽었을 때였음. 예전엔 10ms 지연 시간 서버를 골랐는데, 지금은 60~100ms 이상도 괜찮다고 여김
    • “원래 의도된 방식으로 봐야 한다”는 주장은 믿기 어려움. CRT로 게임하며 자랐지만, 실제 CRT들은 선명도, 색, 아티팩트가 제각각이었고 영상 출력/입력 방식에 따라서도 엄청 달랐음
      TV에 연결했는지, 싼 모니터였는지, 비싼 모니터였는지에 따라 달랐고, 확실히 말할 수 있는 건 CRT가 더 흐릿했다는 정도임. 제시한 비교 이미지는 밝기가 완전히 달라서 오해를 부름. LCD/LED 쪽이 올바른 감마를 쓰지 않는 듯함
      아무 CRT나 쓰면 피부색이 초록빛으로 변할 가능성도 꽤 있었고, CRT의 색상 아티팩트는 심각할 수 있었음. 에뮬레이터에서 계단 현상을 줄이려고 이미지를 흐리게 하는 건 이해하고, 레트로 CRT 효과도 재미있는 장식이지만 “게임이 의도한 모습”이라는 주장은 받아들이기 어려움. 90년대 음악을 싼 스피커와 도로 소음 속에서 들어야 “의도된 방식”이라는 말과 비슷함. 그건 그냥 당시 가능한 최선이었을 뿐임
    • 저건 비슷하지만 서로 다른 이미지인 것 같음
      CRT와 함께 자랐지만 CRT에서 “더 좋아 보이는” 게임은 아주 적었고, 대체로 깜빡임 효과를 만들려고 인터레이스를 쓴 게임 정도였음. 추가로 광선총은 타이밍 때문에 CRT가 필요함
      그 외에 CRT는 바이닐과 비슷함. 더 낫다고 온갖 이유를 만들어내는 사람도 있지만 실제로는 그렇지 않음
  • 정말 흥미로웠음. 색 공간과 그것이 서브픽셀에 어떻게 적용되는지 많이 배웠고, 영상을 보길 잘했음
    게임플레이 측면에서는 보드를 더 크게 만들고, 각 서브픽셀을 통과할 때 뱀의 속도를 보정해야 할 듯함. 좌우 이동 시 R에서 G로 가는 것은 B에서 R로 가는 것보다 가로 이동량이 작고, 세로 이동은 가로 이동에 비해 각 단계가 매우 큼
    위치가 색 스펙트럼의 어디인지에 따라 각 애니메이션 단계의 속도를 비율로 조정하면 꽤 쉽게 해결될 것 같고, 그러면 훨씬 다듬어진 느낌이 날 것임

  • 멋짐. 1440p 모니터에서 헤드밴드 확대경[1]을 쓰고 속도를 10배 늦추니 플레이할 수 있었음
    픽셀 밀도가 더 높으면 실제 현미경이 필요할 듯함
    [1] https://www.amazon.com/ProsKit-MA-016-Personal-Headband-Magn...

  • QBasic Nibbles도 ANSI 박스 그리기 문자로 같은 일을 했음
    세로 “셀”의 절반만 쓰는 텍스트 문자가 있었고, 전경/배경색을 영리하게 조합해서 텍스트 모드에서 세로 해상도를 두 배로 만들 수 있었음

  • 나처럼 멍청하게 실제로 플레이하려 한다면, Snake speed 값이 반대로 동작한다는 점을 알아두면 좋음

    • 속도는 프레임당 밀리초임
  • Windows XP에서 ClearType 조정하던 즐거움을 기억할 만큼 나이 든 사람 있나
    저해상도 LCD에서 더 부드러운 텍스트를 렌더링하기 위한 훌륭한 우회책이었음

    • Windows 10에서도 아직 할 수 있음. 이제 별로 재미가 없을 뿐임
  • 서브픽셀을 보는 가장 쉬운 방법은 디스플레이에 물방울을 하나 올려놓는 것임. 아마 이 방식으로 100배 확대쯤 될 것임 :)

  • 확대/축소로 CSS 픽셀을 실제 픽셀과 맞추는 부분은, 그냥 0.25px 같은 단위를 쓰면 되지 않을까 싶음
    아니면 JavaScript에서 window.devicePixelRatio로 나눠 동적으로 맞출 수도 있을 듯함