28년 전 레이싱 게임이 3DS로 간 이야기
F-Zero X는 1998년에 닌텐도64(N64)로 나온 레이싱 게임이에요. 이 게임은 특이한 점 때문에 유명한데요, 30대의 머신이 한 트랙에서 동시에 달리는데도 초당 60프레임을 유지했거든요. 대신 배경은 휑하고 머신 모델도 단순했어요. 그래픽 디테일을 과감하게 포기하고 '속도감'에 올인한 설계였죠.
최근 한 개발자가 이 게임을 닌텐도 3DS에서 돌아가게 만든 프로젝트의 포스트모템을 공개했어요. 포스트모템(postmortem)이 뭐냐면, 프로젝트를 끝낸 뒤에 '뭐가 잘 됐는지, 뭐가 힘들었는지, 다음엔 뭘 다르게 할지'를 정리하는 회고 문서예요. 구체적인 구현 과정과 삽질기는 원문에 자세히 나와 있으니 꼭 읽어보시고요, 이 글에서는 이런 포팅이 왜 어렵고 어떤 길을 거치는지를 배경 지식 위주로 풀어볼게요. 알고 읽으면 원문이 훨씬 재밌거든요.
에뮬레이션과 포팅은 다른 얘기예요
옛날 게임을 다른 기기에서 돌리는 방법은 크게 두 가지예요.
첫 번째는 에뮬레이션이에요. 원래 기기의 하드웨어를 소프트웨어로 통째로 흉내 내는 방식인데요, 게임 코드는 그대로 두고 'N64인 척하는 프로그램' 위에서 돌리는 거죠. 문제는 흉내 내는 비용이 엄청 크다는 거예요. CPU 명령어 하나하나를 해석하고 그래픽 칩의 동작까지 재현해야 하니까요. 참고로 3DS 공식 버추얼 콘솔에는 N64 게임이 없었어요. 닌텐도도 시간의 오카리나나 스타폭스64는 에뮬레이션 대신 3DS용으로 새로 만든 리메이크로 냈죠.
두 번째는 네이티브 포팅이에요. 게임 코드 자체를 3DS에서 직접 실행되는 프로그램으로 바꾸는 거죠. 그런데 닌텐도가 소스코드를 줄 리가 없잖아요? 그래서 커뮤니티는 우회로를 찾아냈어요.
- 디컴파일: 기계어를 사람이 읽을 수 있는 C 코드로 하나하나 되돌리는 작업이에요. 다시 컴파일했을 때 원본과 바이트 단위로 똑같아질 때까지 맞추는데요, 슈퍼마리오64 디컴파일이 완성되면서 PC 포트가 줄줄이 나왔어요.
- 정적 재컴파일: 사람 대신 도구가 MIPS 기계어를 C 코드로 자동 번역해요. N64Recomp와 이걸로 만든 무쥬라의 가면 PC 포트가 대표적이에요.
3DS가 더 최신인데 왜 어렵냐면
스펙만 보면 3DS가 압승이에요. N64는 93.75MHz MIPS CPU에 RAM 4MB였고, 구형 3DS도 268MHz ARM11에 RAM 128MB거든요. 그런데 숫자로는 안 보이는 함정이 있어요.
1. 그래픽 칩의 철학이 달라요. N64는 게임이 '디스플레이 리스트'라는 그리기 명령 목록을 만들어 넘기면, RSP가 좌표 변환을 하고 RDP가 실제 픽셀을 그렸어요. 특히 RDP의 컬러 컴바이너는 (A - B) * C + D라는 공식에 텍스처 색, 정점 색, 환경 색 같은 값을 끼워 넣어서 최종 색을 만들었죠.
PC 포트라면 이 공식을 픽셀 셰이더로 짜면 끝이에요. 그런데 3DS의 GPU인 PICA200은 정점 셰이더는 프로그래밍할 수 있어도 픽셀 단계는 고정 기능이에요. 이게 뭐냐면, 코드를 마음대로 짜는 대신 '텍스처 컴바이너'라는 정해진 계산 블록 몇 개를 조립해서 색을 만들어야 한다는 뜻이에요. 레고 블록 개수가 정해진 상태에서 N64가 만들던 모양을 똑같이 재현하는 퍼즐인 셈이죠.
2. 엔디안이 반대예요. 엔디안은 여러 바이트짜리 숫자를 메모리에 어떤 순서로 저장하느냐의 규칙인데요, N64는 빅 엔디안이고 3DS의 ARM은 리틀 엔디안이에요. 그대로 읽으면 ROM의 모델 데이터나 트랙 데이터가 전부 뒤죽박죽이 되니까, 데이터 구조를 하나하나 파악해서 바이트를 뒤집어줘야 해요.
3. 화면과 입체 3D. N64 게임은 보통 320x240이었는데 3DS 위 화면은 400x240 와이드예요. 화면비가 달라 시야 처리를 손봐야 하죠. 입체 3D까지 지원하려면 왼쪽 눈, 오른쪽 눈용으로 두 번 그려야 해서 렌더링 부담이 사실상 두 배가 되고요. 30대가 달리는 60fps 레이싱 게임에선 엄청난 부담이에요.
업계 맥락: 레트로 게임 재탄생 붐
요 몇 년간 N64 커뮤니티는 정말 뜨거웠어요. 슈퍼마리오64, 시간의 오카리나 같은 대작이 디컴파일되면서 PC에서 고해상도, 고프레임으로 돌리는 포트가 나왔고, 정적 재컴파일 도구 덕분에 작업 속도도 확 빨라졌죠.
그런데 대부분은 '훨씬 강한 기기'인 PC로 가는 방향이에요. 3DS 같은 애매하게 강한 기기는 얘기가 달라요. N64보다는 강하지만 셰이더도 제한적이고 메모리도 넉넉하진 않아서 최적화를 진짜로 해야 하거든요. 3DS는 2020년에 생산이 끝났고 eShop도 2023년에 문을 닫았지만, devkitARM, libctru, citro3d 같은 오픈소스 홈브루 도구 생태계는 여전히 살아 있어요.
한국 개발자에게 주는 시사점
당장 회사 일에 쓸 기술은 아니지만 배울 건 많아요.
제약된 환경에서 최적화하는 감각은 임베디드, IoT, 저사양 안드로이드 대응처럼 실무에서도 그대로 통해요. '몇 MB 아끼려고 데이터 구조를 다시 짠다'는 경험은 요즘처럼 풍족한 환경에선 일부러 찾지 않으면 얻기 어렵거든요.
그래픽스 파이프라인 공부로도 좋아요. 고정 기능 GPU에서 프로그래머블 셰이더로 넘어온 역사를 알면 지금의 셰이더가 왜 이렇게 생겼는지 훨씬 잘 이해돼요. 엔디안, 메모리 레이아웃, 리버스 엔지니어링은 시스템이나 보안 쪽 커리어에도 탄탄한 기초가 되고요. 서랍에 3DS가 굴러다닌다면 libctru 예제부터 빌드해보는 것도 꽤 재밌는 주말 프로젝트예요.
마무리
옛 게임을 새 하드웨어로 옮기는 일은, 두 시대의 하드웨어 철학을 번역하는 일이에요.
여러분은 꼭 다른 기기로 옮겨보고 싶은 옛날 게임이 있나요? 아니면 실무에서 '이 사양으로 이걸 돌리라고?' 싶었던 극한 최적화 경험이 있다면 댓글로 나눠주세요.
🔗 출처: Hacker News