Halo 2 HD 버전: 오리지널 Xbox의 한계에 도전하는 리마스터 프로젝트

 (icode4.coffee)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 오리지널 Xbox용 Halo 2 HD 패치는 실행 파일 수정, 콘솔 하드웨어 개조, 벤치마크 도구 제작을 묶어 480p를 넘어 720p와 1080p 렌더링을 시도한 프로젝트임
  • 기존 Halo 2는 480p 표기와 달리 내부적으로 640×480 백 버퍼에 그린 뒤 GPU가 720×480으로 업스케일했기 때문에, HD 지원에는 D3D 버퍼와 비디오 모드 처리가 함께 바뀌어야 했음
  • 720p 실행은 기본 64MB RAM으로 부족해 128MB RAM 업그레이드와 커널 핫 패치가 필요했고, GPU용 연속 물리 메모리를 상위 64MB에서도 할당하도록 제한을 우회함
  • 성능은 트리플 버퍼링, texaccum 렌더 타깃 타일링, GPU 233.33MHz→300MHz 오버클럭 등으로 개선됐고, Zanzibar 벤치마크 장면은 약 19FPS에서 27~28FPS 수준까지 올라감
  • 추가 RAM은 텍스처·지오메트리 캐시 확대와 HDD 전송 속도 개선에도 활용됐으며, 최종 패치는 720p를 실사용 가능한 수준으로 만들었지만 1080p는 주로 스크린샷용 보너스에 가까움

프로젝트 목표와 하드웨어 전제

  • 목표는 오리지널 Xbox 버전 Halo 2에 HD 해상도 지원을 추가하고, 개조된 콘솔 하드웨어가 어디까지 버틸 수 있는지 확인하는 것이었음
  • 작업 범위에는 게임 패치, Xbox 콘솔 하드웨어 수정, 성능 벤치마크용 커스텀 도구 작성이 포함됨
  • 프로젝트의 기반이 된 개조 Xbox는 “god box”로 불렸고 다음 변경을 포함함
    • 기본 733MHz Pentium 3 CPU를 커스텀 인터포저 보드로 1.4GHz Pentium 3 변형 CPU로 교체
    • CPU를 약 2GHz까지 오버클럭 가능
    • 추가 RAM과 SSD 사용
    • 하드웨어 개조를 지원하는 커스텀 커널 또는 BIOS 이미지 사용
  • Halo 2의 최대 지원 비디오 해상도는 480p였고, 720p와 가능하면 1080i 지원을 추가하는 것이 목표였음
  • 해상도를 올리면 픽셀 셰이더 계산량이 늘어 GPU 부하가 커지므로, GPU 오버클럭이 가능해야 작업할 가치가 있다고 판단함
    • 이후 GPU 약 15% 오버클럭이 가능해졌고, “GENESIS-3” 콘솔이 개발용으로 준비됨

Halo 2의 480p와 내부 렌더링 구조

  • Halo 2는 박스 표기상 480p를 지원하지만, D3D present parameter에 D3DPRESENTFLAG_PROGRESSIVE가 설정되지 않았고 화면 크기 스케일도 항상 1.0f였음
  • 내부 screen_bounds는 비디오 모드와 상관없이 640×480으로 설정됨
    • 오리지널 Xbox에서 480p는 720×480으로 취급됨
    • Halo 2는 640×480 백 버퍼에 렌더링한 뒤 GPU가 720×480으로 업스케일해 비디오 인코더로 보냄
  • 와이드스크린 모드에서는 1.33:1 애너모픽 카메라를 사용해 같은 640×480 표면에 더 넓은 화면을 압축해 렌더링함
    • 이 방식은 TV의 stretch 모드에서 가로 압축을 상쇄하려는 방식일 수 있음
    • 패치에는 애너모픽 스케일링을 끄는 옵션도 추가됨

HD 렌더링을 위한 D3D 패치

  • 해상도 지원을 위해 세 함수가 주요 수정 대상이 됨
    • _rasterizer_detect_video_mode: 720p에서도 progressive scan이 활성화되도록 변경
    • _rasterizer_init_screen_bounds: 비디오 모드에 따라 640×480, 720×480, 1280×720, 1920×1080 크기 설정
    • rasterizer_device_initialize: D3D 백 버퍼와 present flag 설정
  • 1080i 모드에서는 화면 폭이 1920인지 확인한 뒤 D3DPRESENTFLAG_PROGRESSIVE를 제거하고 D3DPRESENTFLAG_INTERLACED를 설정함
  • 초기 변경 후 메인 메뉴에서 파란 필터가 사라지고, 반복 줄무늬와 물 지오메트리 잘림 문제가 나타남
    • 일부 문제는 백/프런트/깊이 버퍼에 대한 하드코딩된 640×480 뷰 때문에 발생함
    • 동일 메모리를 서로 다른 폭으로 보는 텍스처/서피스 뷰가 생기며 scan line 배치가 어긋남

D3D 메모리와 렌더 타깃 재구성

  • 오리지널 Xbox는 CPU와 GPU가 같은 RAM을 쓰는 통합 메모리 구조임
    • PC처럼 VRAM에 D3D 할당을 만들고 GPU가 관리하는 구조가 아님
    • CPU가 텍스처, 렌더 타깃, vertex buffer 등의 메모리를 만들고 GPU에 직접 주소를 넘길 수 있음
  • Halo 2는 약 25개의 렌더 타깃을 쓰지만 실제 고유 버퍼 할당은 4~5개뿐임
    • 여러 렌더 타깃이 같은 메모리를 다른 리소스 뷰로 공유해 메모리를 절약함
  • rasterizer_primary_targets_initialize는 D3D가 만든 back/front/depth buffer에서 추가 렌더 타깃과 텍스처 뷰를 만들며 640×480 크기를 하드코딩하고 있었음
  • 패치는 해당 함수를 훅으로 감싸 원래 함수 실행 후 텍스처/서피스 크기를 현재 백 버퍼 해상도에 맞게 수정함
    • 타일드 메모리의 pitch는 일반적인 width * bpp와 다를 수 있어 D3D_CalcTilePitch로 계산함
    • 잘못된 pitch는 특히 1080i에서 줄무늬 효과를 만들 수 있음

texaccum 렌더 타깃 크기 수정

  • 메인 메뉴 물 지오메트리 잘림은 texaccum 렌더 타깃이 640×480으로 고정돼 있었기 때문임
  • Xbox DirectX 구현은 픽셀 셰이더 패스당 4개 텍스처 샘플링만 허용함
    • 4개보다 많은 입력 텍스처가 필요한 오브젝트는 여러 패스로 렌더링해야 함
    • texaccum 레이어는 디테일 텍스처들을 먼저 합성한 뒤, lightmap 패스의 입력으로 사용됨
  • rasterizer_targets_initialize는 texaccum 렌더 타깃을 640×480으로 할당하고 있었음
  • _rasterizer_alloc_and_create_render_target를 훅으로 감싸 target_index == 1인 texaccum 타깃의 폭과 높이를 현재 백 버퍼 크기로 바꿈
  • 이 변경 후 물 지오메트리 잘림이 사라지고, 맵 로딩 시 눈에 띄는 렌더링 문제도 없어짐
  • 파란 필터 문제는 단순 크기 체크 업데이트로 해결됐지만 상세 과정은 생략됨

720p 실행을 막은 메모리 한계

  • 720p로 설정하면 게임이 시작 시 크래시했으며, 원인은 커진 front/back/depth buffer와 rasterizer target으로 인한 메모리 부족이었음
  • 오리지널 Xbox에는 소비자용 64MB RAM 모델과 개발용 128MB RAM dev kit/debug console이 있었음
    • 리테일 보드에도 추가 RAM 칩 자리 자체는 존재함
    • RAM 칩을 납땜하고 수정 커널을 쓰면 추가 64MB에 접근할 수 있음
  • 720p 이상 실행에는 128MB RAM 업그레이드가 필요했음
  • 정상적인 480p도 RAM 업그레이드 없이 실행하려면 게임의 인메모리 텍스처 캐시에서 메모리를 가져와야 했고, 이 경우 텍스처 pop-in이 늘어남

Halo 2 메모리 관리자 패치

  • Halo 2는 시작 시 사용 가능한 64MB 중 약 48.9MB를 하나의 큰 런타임 데이터 영역으로 할당함
    • 이 영역은 레벨 메타데이터, 텍스처, 지오메트리, 애니메이션, 사운드 캐시, rasterizer target, 네트워크/시뮬레이션 리소스 등에 나뉘어 사용됨
  • 메모리 사용 시각화를 위해 XboxImageGrabber를 작성함
    • 페이지 테이블 엔트리를 순회해 RAM 사용 상태를 비트맵으로 시각화함
  • 런타임 데이터 영역은 0x80061000이라는 하드코딩된 주소에 할당됨
    • map 파일의 tag data가 이 기준 주소로 직렬화돼 있어 이 데이터는 항상 같은 주소에 있어야 함
    • 다른 런타임 데이터는 이동 가능함
  • 이동 대상으로 삼은 영역은 rasterizer target, texture cache, geometry cache임
    • 특정 할당 호출을 훅해 debug memory region으로 옮김
    • 새 레벨 로딩 등 해제 시점에는 적절한 free 호출을 추가함
    • 런타임 데이터 영역 크기도 줄여 낭비를 줄임
  • physical_memory_malloc은 컴파일러에 의해 인라인돼 있어 각 call site마다 별도 패치가 필요했음

Xbox 커널 핫 패치와 상위 64MB 물리 메모리

  • GPU에 넘기는 메모리 주소는 물리 주소여야 하며, 해당 메모리 범위는 연속적이어야 함
    • GPU에는 페이지 테이블이나 가상 주소 변환 개념이 없음
  • 128MB RAM 커널에서도 기본적으로 물리 연속 할당은 첫 64MB에서만 가능했고, 가상 할당은 128MB 전체에서 가능했음
  • 수동으로 상위 64MB 페이지 테이블 엔트리를 사용해 GPU 메모리처럼 쓰는 테스트는 성공함
    • 상위 64MB에서 GPU용 물리 메모리를 쓰지 못하는 제약은 하드웨어가 아니라 커널의 소프트웨어 제한이었음
  • MmAllocateContiguousMemoryEx 내부에는 MAX_USABLE_PFN 체크가 있었음
    • 기존 값은 0x83FE0000, 즉 64MB - 128KB에 해당함
    • 상위 128KB는 GPU scratch 영역 64KB와 CPU page table 64KB로 예약됨
  • 패치는 게임 부팅 시 콘솔에 128MB RAM이 있는지 확인한 뒤 MmAllocateContiguousMemoryEx에서 mov edx, 0x3FDF 값을 찾아 128MB 구성에 맞는 새 값으로 수정함
  • 이후 MmAllocateContiguousMemoryEx와 MmFreeContiguousMemory를 사용해 128MB 전체에서 연속 물리 메모리를 할당·해제함
  • 부작용도 있었음
    • 게임 종료 후 cold reboot 없이 dashboard 복귀나 DVD tray eject 등 warm reboot를 하면 다음 앱/게임에서 심한 그래픽 아티팩트와 크래시가 발생할 수 있음
    • 이를 숨기기 위해 게임 종료 시 cold reboot를 강제하는 추가 패치를 넣음

720p/1080p 렌더링 결과와 성능 병목

  • 720p 렌더링은 시각적으로 좋아졌지만, 무거운 장면에서는 FPS가 10 이하까지 떨어질 정도로 성능이 낮았음
  • 1080p는 네이티브 렌더링은 가능하지만 Xbox 콘솔 출력은 1080i 신호만 가능함
    • D3D back buffer를 직접 덤프하면 GPU가 비디오 인코더용 half frame으로 바꾸기 전의 1080p 스크린샷을 얻을 수 있었음
  • 성능 측정은 기본 Xbox, CPU만 오버클럭한 god box, CPU+GPU 오버클럭 god box 세 구성을 비교함
  • Zanzibar의 무거운 지점을 “zanzibar benchmark scene”으로 사용함
  • 초기 측정에서 세 구성의 FPS가 거의 같았고, 성능 그래프에서 swap stall이 원인으로 드러남
    • Halo 2는 vsync on과 double buffering을 사용함
    • GPU가 vblank를 기다리며 swap chain 회전을 못 해 stall되는 상황이 발생함

트리플 버퍼링과 GPU 병목 확인

  • 해결책으로 back buffer count를 2로 늘려 front buffer 1개와 back buffer 2개, 총 3개 버퍼를 사용하는 트리플 버퍼링을 적용함
  • D3DPRESENT_PARAMETERS에서 BackBufferCount = 2, D3DSWAPEFFECT_DISCARD, D3DPRESENT_INTERVAL_ONE을 설정함
  • Halo 2의 렌더링 엔진은 double buffering 기준으로 back/front buffer 포인터를 매 프레임 교환했기 때문에, swap hook과 primary target initialize hook도 수정해야 했음
    • 두 primary render surface와 texture view가 항상 현재 back buffer를 참조하도록 변경함
    • 게임이 내부적으로 두 포인터를 swap해도 같은 메모리를 가리키므로 사실상 no-op이 됨
  • Zanzibar 벤치마크 장면에서 기본 GPU 기준 FPS는 약 22FPS가 됨
    • 기존보다 약 3FPS 상승
    • 30FPS 캡 기준 약 10% 증가
    • swap stall이 사라지고 GPU 사용률이 최대가 되어 병목이 GPU임을 확인함

GPU와 RAM 오버클럭

  • texaccum 렌더 타깃을 타일드 메모리로 바꿔 추가로 1~2FPS를 얻음
    • Zanzibar 벤치마크 장면은 약 19FPS에서 23~24FPS까지 개선됨
  • god box의 GPU 오버클럭 상태에서는 Zanzibar 벤치마크 장면이 27~28FPS를 기록함
    • 맵을 돌아다닐 때는 대체로 30FPS를 유지했고 일부 무거운 영역에서만 떨어짐
  • BIOS 재플래시 요구를 피하기 위해 GPU clock generator의 memory-mapped IO register를 게임 시작 시 직접 조정함
  • GPU 클럭 계산은 NVPLL_COEFF의 M, N, P 값과 16.6667MHz base clock에 기반함
    • 기본 N 값 28은 233.33MHz GPU 클럭을 만듦
    • N 값을 조정해 약 8MHz 단위로 설정할 수 있게 했고 ini 파일로 구성 가능하게 만듦
  • 300MHz GPU 오버클럭은 기본 GPU 대비 Zanzibar 벤치마크에서 약 3FPS를 추가로 올림
  • GPU별 오버클럭 한계는 칩마다 달랐음
    • 1.0~1.4 revision 콘솔의 GPU는 low 300MHz 범위에서 한계가 보이는 경우가 많음
    • 1.6 revision 콘솔 GPU는 400MHz 이상 안정적으로 동작한 사례가 있었음
  • RAM 클럭도 테스트함
    • Xbox 메모리 버스 이론 최대 처리량은 6.4GB/s, 실사용 가능치는 약 70%인 4.5GB/s로 다뤄짐
    • RAM은 기본적으로 200MHz에 가까워 약 10MHz 정도만 올려도 불안정해질 수 있음
    • 약 208MHz 설정 테스트에서 0.7FPS 증가가 관찰됨
    • 250MHz 가능한 RAM 칩도 주문했지만, 글 작성 시점에는 설치와 추가 테스트를 하지 않음

pop-in 완화와 캐시 확장

  • Halo 2는 원래도 텍스처와 지오메트리 pop-in 문제가 있었고, 2000년대 초반 기계식 HDD를 쓰는 콘솔에서는 더 두드러짐
  • 추가 RAM을 활용해 texture cache와 geometry cache를 확장함
    • 기본 geometry cache는 싱글플레이 맵 6.5MB, 멀티플레이 맵 7MB
    • texture cache는 map 크기에 따라 달라지며 tag data 뒤와 low detail texture cache 앞의 남은 공간을 사용함
  • 캐시는 LRU 방식으로 동작함
    • 30프레임마다 최근 30프레임 동안 쓰이지 않은 데이터를 제거함
    • 캐시가 가득 차면 호출자가 강제 eviction을 지정하거나, 로드 요청이 실패하고 다음 프레임에 다시 시도함
  • 텍스처는 low/medium/high LOD 버퍼를 가질 수 있음
    • high LOD 로드가 실패하면 medium 또는 low LOD를 시도함
    • 낮은 LOD가 먼저 보였다가 이후 높은 LOD로 바뀌며 pop-in이 발생할 수 있음
  • 맵에는 2×2에서 최대 8×8 크기의 emergency low detail texture cache도 포함됨
    • 일반 텍스처 로드가 실패해도 모델을 임시로 화면에 그리기 위해 사용됨
    • Xbox Live 친구 메뉴를 열었다 닫으면 지형이 극저해상도 텍스처로 보이던 현상은 이 캐시 사용과 관련됨
  • Bungie debug build의 그래프 시각화 기능을 재구성해 cache 사용량을 직접 보며 크기를 조정함
  • 최종 설정은 geometry cache를 20MB로, texture cache를 고정 30MB로 늘림
    • 두 캐시 모두 기본 설정 대비 거의 두 배 수준으로 커짐
    • Outskirts 오프닝 컷신에서 Master Chief가 즉시 고해상도 텍스처로 표시되고 여유 캐시 공간도 남음
  • 남은 pop-in 완화를 위해 HDD 전송 속도도 높임
    • 기본 UDMA 2는 약 33.3MB/s
    • UDMA 3는 약 44.4MB/s
    • 80핀 IDE 케이블이 있으면 UDMA 5 약 100MB/s까지 설정 가능
    • 기본 IDE 케이블에서는 약 10%, 업그레이드 IDE 케이블에서는 이론상 최대 300% 전송 속도 향상을 제공함
  • 최종 720p 메모리 프로파일은 128MB RAM 중 75% 이상을 활용함
    • 1080p 모드에서는 swap chain과 rasterizer target 메모리 사용량이 너무 커 캐시 크기를 줄여야 했고, 사실상 128MB 대부분을 사용함

결과물

  • 전체적으로 720p 패치는 플레이 가능한 수준으로 개선됐고, 1080p 지원은 주로 스크린샷용 보너스에 가까움
  • 아직 성능과 메모리 변경에는 개선 여지가 남아 있지만, Halo 2와 Xbox 콘솔의 한계를 상당히 밀어붙인 결과임
  • Halo 2 HD 패치 다운로드와 소스 코드는 GitHub에 공개됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 글 하단 영상 링크: https://www.youtube.com/watch?v=O_nk21389u8
    영상에는 원본 업스케일 480p와 720p의 나란히 비교가 들어 있고, 7분쯤부터 720p를 얻으면서 약 30fps 게임플레이를 유지하려면 무엇이 필요한지 설명함
    글도 훌륭하지만, 더 높은 해상도를 위해 필요한 변경점을 요약하는 영상도 좋음

  • 720×480이 16:9 해상도가 아니라거나 “진짜 480p”가 아니라는 얘기는 사실 1970년대 ITU 표준화 쪽에 따져야 함: https://tech.ebu.ch/docs/techreview/trev_304-rec601_wood.pdf
    1980년 2월 메모에서 유럽 표준의 유효 주사선 기간을 모두 수용하려면 유효 라인당 샘플 수가 715.5보다 커야 한다고 했고, 이후 Rec. 601과 SMPTE 125에서 쓰인 720 샘플이 “동작하는” 첫 값으로 자리 잡음
    Rec. 601은 휘도 채널에 유효 라인당 720 샘플, 색차 신호에는 각각 360 샘플을 제공했고, HDTV를 정의할 때는 이 기존 TV 시스템의 수평 해상도를 두 배로 하고 16:9 화면비를 적용해 1920 샘플/라인과 1080 라인으로 이어짐
    1280×720 순차주사 시스템도 같은 720픽셀 계열에 속하며, 대부분의 디지털 TV·DVD·MPEG 기반 시스템이 이 4:2:2 기본 표준 형식에서 파생됨

    • DVD는 올바른 재생 화면비를 위해 비정사각 픽셀을 쓰는 4:3 아나모픽 영상만 지원한다고 알고 있었음

  • “해커 정신” 자체는 완전히 정당하지만, 콘솔에 메모리를 추가하고 GPU를 오버클록하는 수고를 들여 Halo 2를 이렇게 플레이할 이유가 PC 버전 대신 따로 있는지 궁금함

    • Halo 2의 PC 이식판은 예전에도 지금도 악명 높게 나빴고, Gearbox가 Halo 1에 했던 것보다도 더 심했음
      결함을 여러 수준으로 자세히 다루는 영상도 많음
      https://youtu.be/03K2Uz3s1hg?si=zaFO1XdzMcFvI1F6
    • 오래된 기기가 어떤 일을 하기엔 부적합하다고 여겨질 때, 바로 그 일을 해내게 만들면 보통 기분이 좋음
      충분히 가능하거나 심지어 더 낫다는 걸 증명하는 느낌임
      아마 심리적 장애에 가까울 수도 있지만 대체로 가볍고 재미있는 쪽이고, 인기 기기의 최신 모델을 누구보다 먼저 사려는 집착의 반대편 같음
      둘 다 일종의 우월감을 줌
    • 그냥 해커 정신임
      지금도 Halo 2는 온라인 로비나 캠페인으로 플레이할 수 있고, 343의 원본 그래픽이나 리마스터 HD 그래픽도 선택 가능함
    • 여전히 30fps라서 개인적으로는 자동으로 제외됨

  • 본문에서 “태그 데이터 시스템은 가능한 한 유연하고 빠르게 설계됐고, 내부 동작은 엔지니어링적으로 대단하다. Blam 엔진을 가장 유연한 엔진 중 하나로 만든다고 생각하는 이유만으로도 글 하나를 쓸 수 있지만 이 글과는 관련 없다”고 했는데, 그 글이 실제로 쓰이면 꼭 읽고 싶음

    • 이런 내용을 직접 쓴 적이 있거나, 쓴 사람을 알고 있다면 공유해주면 좋겠음
    • 어릴 때 Halo 2 모딩을 했지만 프로그래밍은 거의 몰랐고, 거기서 본 개념들이 정말 충격적이었음
      너무 초보라 어떻게 동작하는지 따라가기도 어려웠고, 너무 동적이라 그런 구조가 가능하다는 것 자체를 근본적으로 이해하지 못했음
      플레이어 위치가 설정을 가진 무기와 같은 맥락에 있고, 효과들까지 같은 목록 안에 있다는 게 어떻게 가능한지 이해가 안 됐음
      지금 관심 있는 많은 것들도 결국 이런 개념들 주변을 계속 맴돎

  • Xbox와 Halo 2 모딩의 시대가 현대에 다시 돌아왔으면 좋겠음
    그 시기가 진로 선택에 큰 영향을 줬고, 아직도 Halo 2가 역대 가장 혁신적인 온라인 게임이라고 믿음
    게임 세이브를 불러오는 간단한 도구만 사면 몇 분 안에 소프트 모드 Xbox를 만들 수 있었지만, 지금 콘솔은 e-fuse를 터뜨리고 다운그레이드를 막는 데다 보안 강화도 훨씬 많아짐
    Insignia가 Halo 2 지원을 시작하는 프로젝트와 맞물려, 클래식 Halo 2에는 정말 좋은 시기임

    • 좋든 나쁘든 지난 10년의 개발자들은 여러 면에서 자신들이 올라왔던 사다리를 걷어찬 것 같음
      지금 소프트웨어 엔지니어가 된 이유 중 하나는 웹페이지가 어떻게 동작하는지 쉽게 들여다보고, 프로그램 메모리를 건드리고, 하드웨어를 열어 내부를 볼 수 있었기 때문임
      Halo PC 시절에 레벨을 모딩하면서 게임 안에 무엇이 들어가는지 많이 배웠고, “BSP”가 뭔지 아는 건 쓸모없는 잡지식일 수 있지만 더 많은 걸 이해할 수 있다는 자신감을 줬음
      지금도 기술에 입문하고 배울 수는 있지만, 진짜 땜질을 통해 그렇게 되는 길은 보기 어려움
      소프트웨어는 크랙이나 디버깅이 훨씬 어려워졌고, 불가능하진 않지만 진입 장벽이 훨씬 높아졌음
      웹페이지도 여전히 들여다볼 수는 있지만, 요즘 많은 사이트는 축소·난독화된 JavaScript 괴물을 떠받치기 위한 div 더미가 되었고, 게임은 서버에서 콘텐츠를 스트리밍하는 의존성이 커져 아예 어려운 경우도 많음
      하드웨어도 기기를 벽돌로 만들 수 있는 보안 절차, 접착된 베젤을 열기 위한 열풍기, 영구 손상 위험을 감수해야 함
      이런 변화마다 이유는 있었겠지만, 그 과정에서 재미도 대부분 사라졌고, 오늘날 도구가 기술적으로 더 좋아졌어도 게임 모딩은 예전 같지 않음
    • 그 시절 Xbox는 커스텀 하드웨어라기보다 상용 부품으로 만든 PC에 가까웠기 때문에 게임 세이브 도구만으로 소프트 모드가 쉬웠음
      지금도 PC나 Steam Deck 같은 PC 기반 콘솔로는 충분히 땜질할 수 있는데, 굳이 잠기도록 설계된 독점 콘솔과 싸울 이유가 뭔지 모르겠음
      시장에서 싸게 살 수 있는 커스텀 x86 하드웨어 접근권을 얻는 것 말고 무엇을 얻는지도 애매함
    • “Halo 2가 역대 가장 혁신적인 온라인 게임”이라는 건 온라인 게임 맥락에서 거의 유일하게 만장일치에 가깝고 논쟁이 적은 절대명제 같음
    • Halo 2가 정확히 어떤 면에서 역대 가장 혁신적인 온라인 게임이었는지 궁금함
      강한 모딩 커뮤니티를 가진 경쟁 온라인 FPS는 PC에서 이미 10년 넘게 활발했음
    • PC에서도 멀티플레이 포함해 Halo 2를 아직 자주 플레이함
      Project Cartographer 덕분에 활성 커뮤니티가 있음: https://halo2.online/home/
    1. RAM을 다시 납땜해 VRAM을 64MB에서 128MB로 업그레이드하고, 2) 새 CPU를 콘솔에 납땜한 뒤 GPU 병목을 발견하고, 3) 원래 Xbox에서 GPU 오버클록을 켰지만 메모리 대역폭 한계에 부딪히고, 4) Halo 2 소스 코드를 역공학해 스케일링을 720p 또는 1080p로 설정하고(출력은 1080i 인터레이스), 5) 텍스처 로딩을 빠르게 하려고 하드 드라이브까지 가속함
      이 사람은 요즘 Bungie가 자기 IP에 쏟는 것보다 Halo 2에 더 헌신적인 듯함
    • Bungie는 더 이상 Halo에 관여하지 않음
      IP는 Microsoft가 소유하고 있고 개발은 343 Industries가 맡음
      Bungie는 지금 Destiny/Destiny 2와 곧 나올 Marathon 추출 슈터를 갖고 있음
    • 향수의 힘이 큼
      그 게임에 쏟은 시간이 정말 많았고, 나처럼 그 마법에 빠진 사람이 또 있어서 반가움
    • 엄청난 엔지니어링 성과이긴 하지만, 500달러짜리 Xbox Series X를 사서 리마스터 버전을 4K 120fps로 할 수 있다는 걸 알면 직접 하기는 어려울 것 같음
      그래도 이 정도 헌신은 존경스러움

  • 지나치게 냉소적으로 들릴 수 있지만, 프로젝트 자체는 정말 멋짐
    다만 CPU를 교체하고 오버클록하고, RAM을 늘리고, 솔리드 스테이트 저장장치를 추가하고, GPU까지 오버클록한 상태를 원래 Xbox의 한계까지 밀어붙인다고 할 수 있는지는 의문임
    그 시점에서는 사실상 Xbox가 아닌 것 같음

    • 그게 Xbox인지 여부는 논쟁 가능하지만, 이 주제와 글의 목적상 대부분은 의미론 싸움에 가까움
      Honda Civic에 엔진과 서스펜션 개조를 잔뜩 해서 한계까지 밀어붙인다고 할 때, “그래도 정말 Civic인가?”라고 묻는 건 기술적으로 맞을 수 있어도 말꼬리 잡기처럼 들릴 수 있음
      글쓴이는 원하는 제목을 붙일 권리가 있고, 머릿속에서 “OG Xbox를 죽기 직전까지 모딩하기” 정도로 바꿔 읽으면 됨
    • 여기서는 Xbox 모딩 맥락이라 “original Xbox”는 Xbox 360이 아니다라는 뜻으로 읽어야 함
      Halo 2는 360에서 더 높은 해상도로 실행될 수 있으니, 원래 Xbox를 대상으로 한 모딩 프로젝트라고 명확히 하는 건 유용함
      개조하지 않은 Xbox를 문자 그대로 말하는 게 아니라, 모딩 대상이 원래 Xbox였다는 뜻임
    • 같은 메인보드를 쓰는 건 그래도 의미가 있다고 봄
    • GitHub 저장소를 보면 CPU 업그레이드 콘솔이 없어도 이 패치를 쓸 수 있고, 테스트에서 추가 성능 향상도 측정하지 못했다고 되어 있음
      기본 IDE 케이블 콘솔에서는 전송 속도가 10% 늘고, 업그레이드된 IDE 케이블을 쓰면 이론상 최대 300%까지 늘 수 있다고도 함
      128MB RAM이 있으면 추가 RAM을 활용해 720p와 1080i 비디오 모드를 켜고 텍스처·지오메트리 메모리 캐시를 늘려 팝인을 거의 없앨 수 있음
      480p만 원하면 순정 콘솔에서 GPU를 오버클록하고 다른 IDE 케이블을 쓰면 됨
      SSD 관련 표현은 의도치 않게 오해를 부른 듯하고, 아마 80핀 케이블과 SSD 조합을 뜻했을 수도 있음
      오버클록된 CPU는 필요 없고 CPU가 병목도 아니며, 늘어난 RAM은 720p 이상을 원할 때만 필요함
      이 피드백은 전달했으니, 블로그 글이 이 부분을 더 명확히 업데이트할 수도 있음
    • 기존 하드웨어에서 최대한을 끌어내는 것 자체가 하나의 추구 대상임
      레트로 컴퓨터 씬이 그렇고, 자동차 튜닝도 비슷함
      어떤 사람은 공장 출고 상태의 완벽한 Corvette를 원하고, 어떤 사람은 50년 더 최신 엔진을 얹은 Model A를 원함
      익숙하고 알려진 물건을 자기 뜻대로 비트는 건 멋진 일임

  • 작업량이 엄청남
    친구 “doom”이 자기 정체를 밝히고 싶어 하지 않았다는 점도 흥미로움

    • 우리가 추측을 진지하게 받아들이거나 아예 추측할 일은 아니지만, 현실 신원을 Xbox 역공학과 연결하기 전에 한 번 더 생각하게 되는 업계에서 일한다면 충분히 그럴 수 있다고 봄
    • Doom9이 떠올랐음
    • 거의 확실히 grimdoomer일 것 같음
답변달기
GeekNews BeeBS 게시판 오픈! 자유로운 이야기와 소소한 일상을 함께 나눠보세요.