닌텐도 64에서 가산 블렌딩을 구현하기, 30년 된 하드웨어의 한계와 싸우는 법

왜 지금 N64 이야기를 하는가

phoboslab.org를 운영하는 도미닉 슈잘리에(Dominic Szablewski)가 흥미로운 기술 글을 하나 올렸어요. 주제는 "닌텐도 64에서 가산 블렌딩(additive blending)을 구현하기"예요. 닌텐도 64라고 하면 1996년에 나온 게임기인데요, 마리오 64나 젤다 시간의 오카리나 같은 전설적인 게임들이 돌아갔던 그 콘솔이에요. 30년 전 하드웨어 얘기를 왜 지금 하느냐고요? 요즘 인디 개발자 사이에서 "레트로 콘솔용 홈브루(homebrew, 개인이 만든 비공식 게임) 개발"이 작은 르네상스를 맞고 있거든요. 특히 N64는 그래픽 파이프라인이 독특해서 도전 정신을 자극하는 플랫폼이에요.

도미닉은 wipEout이라는 고전 레이싱 게임을 N64로 포팅하는 작업을 하고 있는데, 그 과정에서 마주친 기술적 난관 하나를 풀어낸 글이에요. 바로 가산 블렌딩, 우리말로 풀면 "색을 더하는 방식의 합성"이에요.

가산 블렌딩이 뭐길래

이게 뭐냐면, 두 이미지를 겹칠 때 픽셀의 색깔을 단순히 "더하는" 합성 방식이에요. 예를 들어 검은 배경에 빨간 빛(R=255, G=0, B=0) 위에 파란 빛(R=0, G=0, B=255)을 가산 블렌딩으로 올리면 보라색이 아니라 자홍색(R=255, G=0, B=255)이 나와요. 빛이 더해지는 거니까 결과는 항상 더 밝아져요. 그래서 폭발, 레이저, 불꽃, 광원 효과 같은 "빛나는" 것들을 표현할 때 필수적인 기법이에요. 현대 GPU에서는 그냥 glBlendFunc(GL_ONE, GL_ONE) 한 줄이면 끝나는데, N64에서는 이게 쉽지 않아요.

N64의 그래픽 칩 RDP(Reality Display Processor)는 블렌딩 공식이 굉장히 제한적이에요. 정확히 말하면 (P A) + (M B) 같은 고정된 형태만 지원하는데, 여기서 P는 픽셀 색, M은 메모리(프레임버퍼) 색, A와 B는 알파 값이에요. 문제는 A와 B에 "1"을 직접 넣을 수 있는 옵션이 없다는 거예요. 알파 값을 통해서만 가중치를 조절할 수 있는데, 이 알파라는 게 0~255 범위라서 "그냥 더하기"를 표현하기가 까다로워요.

도미닉의 해법

글의 핵심은 이 제약 안에서 어떻게 가산 블렌딩을 흉내내느냐예요. 도미닉은 알파 채널을 영리하게 활용해서 "근사 가산 블렌딩"을 구현하는 방법을 설명해요. 텍스처의 알파 값을 미리 조정하고, 컴바이너(combiner) 단계에서 색상을 알파와 곱한 다음 프레임버퍼와 합치는 식이에요. 완벽한 가산은 아니지만, 시각적으로는 거의 구분이 안 가는 결과를 만들 수 있어요.

이때 또 다른 문제가 등장해요. N64의 프레임버퍼는 보통 16비트(RGBA 5551)인데, 이 비트 수로는 색 표현 정밀도가 낮아서 가산을 반복하면 밴딩(banding, 색이 띠처럼 끊겨 보이는 현상)이 생겨요. 도미닉은 디더링(dithering)을 적용하거나 일부 장면에서만 32비트 프레임버퍼를 쓰는 식으로 트레이드오프를 잡았어요. 게다가 N64는 메모리 대역폭이 악명 높을 정도로 좁아서("the N64 was bandwidth-starved"라는 표현이 유명해요), 블렌딩 호출 하나하나가 성능에 영향을 줘요.

N64 그래픽의 독특한 매력과 한계

N64는 당시로서는 혁신적인 콘솔이었어요. 3D 가속, 텍스처 필터링, 밉맵, Z-버퍼링 같은 "현대적인" 그래픽 기능을 가정용 콘솔에 처음 가져온 기계예요. 하지만 텍스처 캐시가 4KB밖에 안 돼서 큰 텍스처를 쓸 수가 없었고, 그래서 N64 게임 특유의 흐릿하고 부드러운 비주얼이 만들어진 거예요. 이게 단점이자 동시에 "N64 미학"이라는 독특한 정체성이 됐어요. 요즘 "N64 스타일 인디 게임"이 일부러 그 흐릿한 룩을 흉내내는 이유도 여기 있어요.

홈브루 씬에서는 libdragon이라는 오픈소스 N64 SDK가 활발하게 발전하고 있어요. 닌텐도의 공식 SDK가 아니라 커뮤니티가 리버스 엔지니어링해서 만든 거예요. 도미닉도 이 라이브러리를 활용해서 작업하고 있고, 비슷한 시기에 PlayStation 1용 PSn00bSDK, Saturn용 yaul 같은 다른 레트로 콘솔 SDK들도 같이 성장하고 있어요. 30년 전 하드웨어가 오히려 지금 더 잘 이해되고 있다는 게 재밌는 현상이에요.

왜 이런 일을 하는 사람이 있는가

어떤 분은 "왜 굳이 30년 전 기계에서 이런 짓을 하느냐"고 물을 수 있어요. 답은 여러 갈래예요. 첫째, 순수한 기술적 즐거움이에요. 제약이 많은 환경에서 문제를 푸는 건 퍼즐 게임 같은 매력이 있어요. 둘째, 하드웨어의 본질을 이해하는 훈련이 돼요. 요즘은 GPU 위에 추상화 레이어가 너무 많아서 "실제로 픽셀이 어떻게 그려지는지"를 잘 모르고 일하는 경우가 많은데, N64 같은 환경은 모든 걸 직접 다뤄야 해요. 셋째, 레트로 게임 보존이라는 의미도 있어요. 옛날 게임을 현대 기술로 분석하고 재해석하는 작업은 디지털 문화재 보존의 한 형태예요.

한국 개발자에게 주는 시사점

이런 글을 한국 개발자가 읽어두면 좋은 이유가 있어요. 임베디드나 게임 그래픽 프로그래밍, 또는 모바일 GPU 최적화를 하는 분이라면 "제약 조건 안에서 우아한 해법을 찾는" 사고방식이 직접적으로 도움이 돼요. 모바일 게임도 결국 발열, 배터리, 메모리 같은 제약과 싸우는 일이거든요. 가산 블렌딩 같은 기본 그래픽 개념을 가장 밑바닥 수준에서 이해하면, OpenGL이나 Vulkan, Metal을 쓸 때도 "이 한 줄이 GPU에서 실제로 뭘 하는 건지" 감이 잡혀요.

취미로 시작해보고 싶다면 libdragon으로 "Hello, Triangle" 정도부터 시작해보는 것도 추천해요. 실제 N64 카트리지로 굽지 않아도 ares나 Project64 같은 에뮬레이터에서 돌려볼 수 있어요.

마무리

30년 된 하드웨어의 제약 안에서 현대적인 그래픽 효과를 우겨넣는 작업은, 단순한 향수가 아니라 "엔지니어링이란 무엇인가"를 가장 순수한 형태로 보여주는 예시예요. 추상화 너머의 진짜 기계를 이해하는 사람은 어느 시대에도 강해요.

여러분은 가장 "제약이 심했던" 환경에서 코딩해본 경험이 있나요? 그때 배운 게 지금 어떤 일에 도움이 되고 있는지 들어보고 싶어요.