거의 모든 Nintendo 64 게임을 네이티브 PC 포트로 재컴파일 가능

• 1996년에 출시된 Nintendo 64 게임을 에뮬레이션 대신 PC 네이티브 포트로 재컴파일해 레이 트레이싱, 울트라와이드, 고 FPS 같은 개선을 적용할 수 있게 됨
• GitHub의 Mr-Wiseguy가 공개한 N64Recomp와 Zelda64Recomp가 핵심 도구이며, Zelda64Recomp는 _The Legend of Zelda: Majora's Mask_를 PC로 포팅함
• 이 방식은 2020년 공개된 완전 디컴파일 기반 Super Mario 64 PC 포트와 다르지만, 둘 다 PC에서 네이티브로 실행되어 성능과 효과 정확도를 높일 수 있음
• 수동 디컴파일은 한 명 이상이 수년간 작업해야 하는 반면, N64Recomp는 N64 게임을 더 빠르게 PC에서 실행 가능한 형태로 바꾸는 접근임
• 결과물은 에셋을 포함하지 않아 플레이에는 ROM이 필요하며, Banjo-Kazooie, Rocket Robot, Superman 64도 실행 사례로 언급됨

---

N64 게임 포팅 방식의 변화

• 2024년에도 Nintendo 64의 원본 하드웨어와 게임은 애호가 커뮤니티에서 꾸준한 관심을 받고 있음
• 고급 N64 플레이의 다음 단계가 에뮬레이션이 아니라 재컴파일된 PC 포트가 될 가능성이 커짐
• GitHub의 Mr-Wiseguy가 N64Recomp와 Zelda64Recomp를 공개함
  • N64Recomp는 N64 게임을 PC 네이티브 포트로 만드는 기반 도구임
  • Zelda64Recomp는 _The Legend of Zelda: Majora's Mask_를 PC로 포팅하고 N64Recomp의 그래픽 및 편의성 개선을 적용함

PC 포트에서 가능한 개선

• 재컴파일된 PC 포트는 원본 N64 게임에 PC 환경의 개선을 더할 수 있음

  • 실제 레이 트레이싱

    • 프레임 제한 해제
    • 적절한 울트라와이드 지원
    • PC에서 기대되는 그래픽 및 편의성 개선
    • _Majora's Mask_는 에뮬레이션 방식과 네이티브 PC 재컴파일 방식의 울트라와이드 실행 비교 사례로 다뤄짐

Super Mario 64 PC 포트와의 차이

• 2020년 공개된 완전 디컴파일 기반 Super Mario 64 PC 포트는 레이 트레이싱과 전체 모델 교체 같은 기능을 가능하게 했고, 지금도 모드가 이어지고 있음
• 재컴파일 포트는 SM64 PC 포트 같은 디컴파일 포트와 제작 방식이 다름
• 두 방식 모두 PC에서 네이티브로 실행되며, 원본 하드웨어 대비 성능과 효과 정확도를 높이면서 에뮬레이션에서 기대되는 PC식 개선을 제공할 수 있음

N64Recomp가 중요한 이유

• N64Recomp는 재컴파일 접근으로 에뮬레이션과 네이티브 포트의 장점을 함께 노리는 도구임
• N64 게임을 수동으로 디컴파일하려면 한 명 이상이 수년간 작업해야 함
• 더 효율적으로 N64 게임을 PC에서 빠르게 실행 가능한 상태로 바꾸는 도구는 보존 활동가에게도 유용할 수 있음

RT64와 실행 사례

• Dario는 N64Recomp와 일부 N64 에뮬레이터에서 활용되는 RT64 플러그인을 만드는 개발자임
• Dario의 게시물에 따르면 Wiseguy는 완전한 디컴파일 없이 N64 게임의 PC 포트를 만드는 도구를 1년 동안 비공개로 작업함
• 결과물은 에셋을 포함하지 않으며, 플레이에는 ROM만 필요함
• 실행 사례로 다음 게임이 언급됨
  • Banjo-Kazooie
  • Rocket Robot
  • Superman 64

N64 생태계의 다른 움직임

• N64 라이브러리와 원본 하드웨어 팬을 위한 다른 진전도 이어지고 있음
• 오픈소스 SummerCart64는 기존 콘솔용 플래시 카트이며, 64DD 지원도 구현함
• 실제 하드웨어와 호환되는 홈브루 N64 게임과 ROM 해킹도 계속 출시되고 있음
  • 30명 파이터를 제공하는 Smash Remix
  • Mario 64 엔진 재작성 프로젝트인 Peach's Fury

[GN⁺]

Hacker News 의견들

• 이 도구를 쓰려면 여전히 먼저 ROM을 역어셈블하고, 다시 컴파일되도록 많은 주석을 달아야 함
  도구 자체는 훌륭하지만, 임의의 ROM을 거의 원클릭으로 독립 실행 파일로 만든다는 식의 과장은 지나쳐 보임

  • 그래도 N64는 PS2나 Game Boy와 달리 출시 게임이 388개뿐이라, 출시된 모든 게임을 이 과정을 거쳐 정리하는 건 현실적으로 가능해 보임
  • 그건 사실이 아닌 것 같음
    게시물의 영상에서는 이름 없는 N64 게임을 다시 컴파일해서 잘 실행했고, 별도 주석도 필요 없어 보였음
  • 그 작업은 한 번만 해두고 어딘가에 저장해 공유하면 됨
    ROM은 말 그대로 읽기 전용이니, ROM을 넣고 네이티브 포트를 얻는 식이 가능함
  • 왜 꼭 ROM을 먼저 역어셈블하고 많은 주석을 달아야 하는지 모르겠음
    바이너리 대 바이너리 변환이 더 직관적일 텐데, 사람의 입력도 필요 없을 것 같음
  • 그 과정이 구체적으로 뭔지, 그리고 일부라도 ChatGPT로 처리할 수 있는지 궁금함

• 정말 멋짐
  N64 디컴파일을 위해 만들어진 여러 기반 도구들이 다른 시스템 디컴파일 패키지로 퍼져 나가고 있음
  최근 본 https://decomp.me/는 여러 시스템에 대해 관련 SDK와 하드웨어 프리셋을 갖춘 협업 디컴파일을 지원함
  앞으로 몇 년 동안 더 많은 시스템에서 이런 흐름이 생길 것 같음

• 이게 나왔을 때 봤는데, ROM 해킹 쪽을 따라가지 않는 입장에서는 왜 이런 접근이 이렇게 늦게 나왔는지 궁금함
  어셈블리 명령을 C로 번역한 뒤 다시 컴파일하는 건 초기에 시도해볼 만한 뻔한 방법처럼 보이는데, 이전에는 불가능했고 이제 가능하게 만든 다른 돌파구가 있었는지 궁금함

  • N64에는 현대 GPU와는 다른 GPU가 있고, 그래픽을 렌더링하려면 그 GPU가 필요함
    GitHub 저장소를 훑어보니 광선 추적 지원에 내부적으로 rt64를 쓰는 것 같음(https://github.com/rt64/rt64)
    rt64는 GPU를 에뮬레이션하기 위해 우버셰이더 기법을 쓰며, 이 훌륭한 글이 우버셰이더가 무엇이고 왜 필요한지, 얼마나 정신없는지 설명함: https://dolphin-emu.org/blog/2017/07/30/ubershaders/
  • 다른 에뮬레이터들은 문제를 범용적으로 풀려 하지만, 이 해법은 완전히 그렇지는 않음
    한 기계어에서 다른 언어로 정적 재컴파일하는 건 실무에서 매우 어렵거나 일반적으로는 불가능한 영역 사이에 있음 [1]
    이런 재컴파일을 제대로 하려면 재컴파일을 쉽게 만들어주는 바이너리 쪽의 도움도 필요하고 [2], 그 위에 동작하게 만들기 위한 패치도 필요함 [3]
    동적 재컴파일은 이런 문제가 없어서, 원본 바이너리와 자산, 즉 ROM을 넣으면 대체로 에뮬레이션되는 소프트웨어를 만들 수 있음
    이 해법이 얼마나 범용적인지에 대해 혼동이 많음
    재컴파일이나 포트를 훨씬 쉽게 만들어주는 작업량 절감 측면에서는 매우 인상적이고 가치도 크지만, 전통적인 에뮬레이터의 필요성을 대체하지는 못함
    [1]: https://cs.stackexchange.com/questions/155511/why-is-static-...
    [2]: N64 게임 바이너리는 일반적인 정적 재컴파일을 어렵게 만드는 여러 요소를 우연히 피하고 있어서 이 접근에 도움이 될 수 있지만, 실제로는 잘 모름
    [3]: Majora's Mask 재컴파일 저장소에는 동작을 위해 손으로 만든 패치가 많이 들어 있음: https://github.com/Mr-Wiseguy/Zelda64Recomp
  • 하드웨어 에뮬레이션은 보통 병렬로 돌아가는 것들을 사이클 정확도로 에뮬레이션해야 해서, ROM 안의 프로그램만 처리하면 되는 단순한 문제가 아님
  • 자체 수정 코드나 이걸 어렵게 만드는 다른 요소를 쓰고 있는지 궁금함

• Jamulator는 이미 2013년에 NES 대상으로 이걸 했지만, 아무도 별로 신경 쓰지 않았던 것 같음
  https://andrewkelley.me/post/jamulator.html
  Android에서 Windows 프로그램을 실행하는 Winlator도 있음
  https://github.com/brunodev85/winlator
  그리고 글에 링크된 YouTube 영상은 AI 음성을 쓰는 건가?

  • 적어도 Mr WiseGuy는 신경 쓰는 것 같음
    N64Recomp GitHub 저장소[0]에 이렇게 적혀 있음:
    "This is not the first project that uses static recompilation on game console binaries. A well known example is jamulator, which targets NES binaries."
    [0]: https://github.com/Mr-Wiseguy/N64Recomp
  • Jamulator가 성공하지 못한 건 카트리지에 추가 하드웨어가 너무 많이 들어 있었기 때문임
    그런 상황에서는 재컴파일이 일을 복잡하게 만들 뿐 이점이 크지 않음
    N64는 고정 하드웨어라 조금 더 쉬움
    그래도 이 프로젝트는 여전히 RDP에 에뮬레이션을 쓰고 있음
    생성된 RSP 마이크로코드를 어떻게 처리하는지는 모르겠고, 아마 처리하지 않을 수도 있음
    많은 게임은 그냥 공식 라이브러리를 썼음
  • Jamulator는 실행 방식 외에는 NES 에뮬레이터가 할 수 있는 것 이상으로 나아가지 못했음
    Jamulator가 Zelda용 비슷한 개선 기능과 함께 나왔다면 훨씬 더 인기가 있었을 것임
    관심은 방식 자체보다 이제 그것으로 무엇을 할 수 있느냐에서 더 많이 나오는 듯함
    영상 내레이션은 그냥 Nerrel이라는 실제 사람이 한 것임
    요즘 AI 음성이 너무 좋아져서, 우리가 기대하는 방식으로 말하지 않는 사람을 AI로 의심하게 되는 게 흥미로운 의미에서 꽤 놀라움
  • 그냥 Nerrel임
    내레이션이 워낙 평평해서 예전부터 AI처럼 들렸고, 그게 유머와 섞이는 느낌을 좋아함

• 모든 게임 실행 파일이 WebAssembly와 비슷하게 운영체제에 독립적이면 좋겠음
  예를 들면 GameAssembly 같은 것
  이제 새 macOS에서는 32비트 게임을 할 수 없고, Wine에서도 32비트 Windows 게임이 안 됨
  Wine/Crossover에서 제대로 돌릴 수 있는 64비트 .exe 파일을 찾기도 거의 불가능함

  • 게임에서는 CPU에서 실행되는 코드가 오히려 작은 문제에 가깝다고 볼 수 있음
    콘솔의 경우, 특히 오래된 타이틀과 플랫폼 독점작은 매우 낮은 수준의 GPU 구현 세부사항에 의존하는 경우가 많음
    더 오래된 콘솔에는 단순 입출력 말고도 중요한 일을 하는 전용 칩이 더 있었음
    예를 들어 SNES의 사운드 칩은 CPU와 GPU와 병렬로 자기 작은 프로그램을 실행하는 완전히 독립적인 CPU였음
    물론 앞으로의 모든 게임 개발에 고수준 가상 머신을 의무화할 수는 있겠지만, 콘솔 하드웨어 사양이 고정돼 있다는 점을 생각하면 최신 그래픽을 활용하려는 타이틀에는 경쟁력이 없을 것임
  • 취지에는 동의하지만, x86_64 Linux에서 32비트 Windows 게임을 꽤 만족스럽게 실행해왔음
    Debian에서는 다음을 실행해야 했음
    dpkg --add-architecture i386 && apt-get update
    그다음 wine32 패키지를 설치하면 됨
  • 게임을 이식 가능하게 만들려면 이식 가능한 기계어만 제공하는 것으로는 부족함
    게임에는 그래픽 API, 창 API, 입력 API, 사운드 API, 디스크 API 등 다양한 API가 필요함
    때로는 안티치트나 복제 방지 기능 때문에 커널 모듈도 필요함
    아쉬운 건 오픈소스 운영체제들이 개발자가 코드를 한 번만 작성하고 테스트하면 어디서나 동작하도록 공통 API 집합을 제공하려 하지 않는다는 점임
    Flatpak이 있긴 하지만, 이해하기로는 API 집합을 제공하는 게 아니라 명세나 문서 없이 Linux 배포판을 가상 머신 안에 포장하는 것에 가까움
    보기 흉하고, Linux가 아닌 작은 운영체제들과의 호환성도 없음
  • Mac의 Wine에서도, 심지어 Apple Silicon에서도 32비트 Windows 게임을 실행할 수 있었음
    M1 mini에서 GTA IV를 돌렸음
    PlayOnMac이 설치하는 32비트 Wine 버전 안에 일종의 "32 on 64" 에뮬레이션이 들어 있는 듯한데, 검색이 너무 어려워서 실제로 어떻게 동작하는지는 모르겠음
    Mac이 오래된 Mac 프로그램보다 오래된 Windows 프로그램과 더 호환된다는 게 재미있음
  • JVM은 Minecraft에서 이걸 꽤 잘 해냄
    JVM이 없었다면 Minecraft가 Linux나 BSD 계열 등을 지원했을지 의문임
    JVM 버전이 아닌 Bedrock Edition은 Windows와 콘솔, 휴대폰을 지원하지만, 분명 가능할 텐데도 macOS는 지원하지 않음

• 이게 결국 Linux에서도 동작해서, 매우 저사양 휴대용 기기에서 N64 게임을 안정적으로 할 수 있으면 좋겠음
  N64는 에뮬레이션이 까다롭기로 악명 높지만, 플랫폼용으로 네이티브 빌드하면 성능 문제는 사라짐

  • N64Recomp를 통해 Linux가 네이티브로 지원되는 게 거의 확실함: https://github.com/Mr-Wiseguy/N64Recomp
    예시는 여기에서 볼 수 있음: https://github.com/Mr-Wiseguy/Zelda64Recomp?tab=readme-ov-fi...
  • N64가 에뮬레이션하기 까다롭다는 건 예상하지 못했음
    N64 에뮬레이션의 세부 사항은 잘 모르지만, 2010년대 초부터 N64 에뮬레이터를 완벽하게 돌려왔음
    주로 대형 고전작만 했기 때문에 더 틈새 타이틀의 성능은 잘 모름
  • Ubuntu PC에서 직접 해봤는데 아주 잘 동작함
    한 시간쯤 플레이했는데 문제 없었음
  • 며칠 전 이 글이 링크한 YouTube 영상을 봤는데, Linux 지원을 언급했고 특히 Steam Deck에서도 쓸 수 있어야 한다고 했음
  • 이미 Linux에서 동작함
    직접 테스트해봤음

• GoldenEye 같은 게임에 이게 꽤 유용할 수 있음
  이상한 조이스틱 입력을 전제로 해서 PC에서 하기 어려운데, 다른 FPS처럼 정상적인 마우스 동작을 가진 네이티브 GoldenEye 포트가 있으면 멋질 것 같음

  • WASD와 마우스 조준은 사실 그 게임과는 잘 맞지 않음
    조준의 모드 전환 방식과 커서가 이동하고 다시 중앙으로 돌아오는 시간이 게임의 재미있는 부분임
    PC FPS처럼 달리면서 자유 조준이 가능해지면, 캠페인이 그 전제에 맞춰 설계돼 있어서 오히려 망가질 것 같음
    어디서 멈춰 조준할지 고르고 조준 중 침착함을 유지하는 게 매력임
    다만 모드 전환은 유지하고, 마우스가 1) 스틱 좌우처럼 Bond를 회전시키고 2) R을 눌러 "조준 모드"일 때만 커서를 제어한다면 재미있을 수 있음
    솔직히 슈터들이 전부 Quake식 WASD+마우스 자유 조준으로 곧장 간 게 아쉬움
    모드 전환 방식이 GoldenEye에 좋아하는 물리적인 감각을 줌
  • GoldenEye에 WASD+마우스 지원을 추가하는 에뮬레이터 해킹이 있고, 잘 동작한다고 들었음
    https://github.com/Graslu/1964GEPD/releases/tag/latest
  • 그래도 여전히 이상한 조이스틱을 기대하지 않을까?
  • 마우스+WASD 해킹은 정말 잘 동작함
    Perfect Dark에서도 됨

• 꽤 흥미로운데, 이게 MiSTer에서 제대로 동작하는 Conker 버전으로 이어질 수 있는지 궁금함
  예를 들어 이걸 디컴파일 보조에 쓰고, 누군가 수정판을 만들 수 있을까?

• 에뮬레이터와 비교한 장점이 뭔지 궁금함
  결국 미리 번역해두는 형태의 에뮬레이터 아닌가?
  이런 방식은 예전에 Bleem 같은 것으로도 있었고, 성능상 유리할 수는 있지만 현대 PC에서는 좋은 에뮬레이터라면 대체로 잘 동작함
  https://en.wikipedia.org/wiki/Bleem!

  • 이 프로젝트의 목표와 N64 에뮬레이션의 목표는 꽤 다름
    N64 에뮬레이터의 목표는 보통 원래 콘솔의 동작을 정확히 재현하는 것임
    반대로 SM64, OOT, MM을 60fps, 와이드스크린, 텍스처 팩, 랜더마이저 같은 여러 그래픽 개선과 함께 하고 싶은 사람들도 많음
    이런 사람들에게는 이 게임들이 원래 N64에서 돌아갔다는 사실이 사실상 중요하지 않음
    오히려 장애물에 가까움
    N64의 그래픽 파이프라인은 에뮬레이션하기 번거롭고 현대적인 개선을 적극적으로 방해함
    이 프로젝트는 게임 자체를 현대적으로 다루고, N64 중심 요소를 방정식에서 완전히 빼는 데 더 초점을 둔 것으로 보임
  • JIT 에뮬레이션은 끊김을 만들 수 있지만 AOT는 그렇지 않을 것임
    지금은 컴퓨터가 N64보다 훨씬 빨라져서 차이가 눈에 띄지 않을 수도 있음
  • 영상에서는 이 방식을 쓰면 에뮬레이션 대비 여러 버그가 사라지는 걸 보여줌
  • 재컴파일은 에뮬레이션이 아님

• 일반적인 에뮬레이터들은 미리 컴파일하나, 아니면 JIT를 쓰나?
  아니라면 왜 안 하는지 궁금함
  이 접근, 즉 사전 컴파일은 큰 장점이 있어 보임

  • 컴파일이나 인터프리터 기법 이름을 아무거나 대도, 그걸 쓰는 에뮬레이터가 적어도 하나는 있음
  • 32비트 이후 세대 에뮬레이터 중에는 JIT 재컴파일을 쓰는 것이 꽤 많음
    다만 TeknoParrot이 그런 식으로 동작하는 게 아니라면, 사전 번역은 잘 모르겠음
    예를 들어 TeknoParrot으로 ELF 바이너리를 쓰는 Linux 아케이드 게임을 Windows에서 실행할 수는 있지만, 아키텍처가 같으니 어느 쪽이든 에뮬레이션이라고 부르지는 않겠음
  • 에뮬레이션 방식은 많지만, 해석 실행이 아마 가장 흔하거나 적어도 매우 흔함
    해석 실행은 기계의 여러 부분 상태를 표현하는 가상 머신을 작성하고, 정확도 수준을 달리하면서 그 상태를 바꾸는 명령을 실행하는 방식임

[lifeisliving]

덕후들의 능력이란! 에뮬레이터에 JIT컴파일러 장착을 넘어, 이젠 binary lifting으로 C로 변환후 재컴파일까지