3P by GN⁺ | ★ favorite | 댓글 1개
  • 1992년 Wolfenstein 3D 원본 소스는 현대 시스템과 바로 맞지 않지만, DosBoxBorland C++ 3.1 환경을 재현하면 다시 컴파일할 수 있음
  • 필요한 구성은 Wolfenstein 3D 소스 코드, DosBox, Borland C++ 3.1, 실행용 shareware 자산으로 정리됨
  • 빌드 과정에서는 Borland C++ 프로젝트 설정뿐 아니라 PATH, SIGNON.OBJ, GAMEPAL.OBJ 경로를 직접 고쳐야 함
  • 처음 실행 시 그래픽이 깨지는 이유는 엔진에 컴파일된 그래픽 인덱스와 자산 파일 내부 위치가 서로 어긋나기 때문임
  • 재생성된 VGA 자산을 복사하고 DosBox의 aspect correction을 켜면 1992년 CRT 화면비에 가까운 형태로 실행 가능함

1992년 빌드 환경 재현

  • Wolfenstein 3D의 1992년 원본 소스 코드는 20년 넘게 지난 현대 시스템에서는 그대로 쓰기 어렵지만, 당시 도구와 실행 환경을 맞추면 컴파일할 수 있음
  • 필요한 구성은 다음 네 가지임
    • Wolfenstein 3D 소스 코드
    • DosBox
    • Borland C++ 3.1
    • Wolfenstein 3D shareware 자산

DOS 드라이브처럼 쓸 디렉터리 준비

  • 로컬에 DOS 드라이브처럼 사용할 디렉터리 2개를 만듦
    • system/c
    • system/a
  • system/a에는 Borland C++ 3.1 압축 파일을 받음
  • system/c에는 Wolfenstein 3D 소스 코드와 VGA 파일을 받음
  • 압축 해제 후 파일 배치는 다음처럼 정리됨
    • system/a: BCPP31.zip
    • system/c: wolfsrc.zip, vgafiles.zip

DosBox에서 컴파일러와 소스 설치

  • DosBox를 실행한 뒤 로컬 폴더를 DOS 드라이브로 마운트함
    • ~/system/cC:로 마운트
    • ~/system/aA:로 마운트
  • A:\BCPP31에서 install을 실행해 Borland C++ 3.1을 설치함
    • 기본 설정을 유지하고 설치를 시작함
    • Microsoft Windows 폴더를 찾을 수 없다는 경고는 필요하지 않아 Enter로 넘어감
  • C:\에서 Wolfenstein 3D 소스 설치 프로그램을 실행하고 기본 경로 \WOLFSRC를 사용함

Borland C++ 프로젝트 빌드

  • C:\BORLANDC\BIN\BC.EXE로 Borland C++ 3.1을 실행함
  • ..\..\WOLFSRC\WOLF3D.PRJ 프로젝트를 열고 디렉터리를 다음처럼 설정함
    • Include Directories: C:\BORLANDC\INCLUDE
    • Library Directories: C:\BORLANDC\LIB
    • Output Directories: OBJ
    • Source Directories: C:\WOLFSRC
  • 첫 빌드에서는 Cannot find executable TASM 오류가 발생함
    • Borland C++를 종료하고 PATH=C:\BORLANDC\BIN을 설정한 뒤 다시 실행함
  • 다음 빌드에서는 링크 단계에서 Unable to find OBJ file 오류가 발생함
    • SIGNON.OBJGAMEPAL.OBJ가 프로젝트에서 C:\SOURCE\WOLF\ 경로로 잘못 지정되어 있음
    • 두 항목을 프로젝트에서 삭제한 뒤 WOLFSRC\OBJ\SIGNON.OBJ, WOLFSRC\OBJ\GAMEPAL.OBJ로 다시 추가함
  • 이후 Compile -> Build All을 실행하면 빌드가 성공함

실행 자산과 그래픽 깨짐 원인

  • 컴파일된 실행 파일을 실행하려면 Wolfenstein 3D shareware 또는 정식 버전 자산이 필요함
  • shareware 설치 후 컴파일된 .EXE를 게임 폴더에 복사해 실행하면 화면이 이상하게 표시됨
  • 원인은 그래픽 파일을 만드는 제작 파이프라인과 엔진의 자산 접근 방식에 있음
    • Adrian Carmack와 Kevin Cloud가 그래픽 파일을 만든 뒤 IGRABed 도구로 묶음
    • 출력은 VGAHEAD.WL1, VGAGRAPH.WL1, VGADICT.WL1 3개 파일과 GRE.H, GRE.EQU 2개 파일로 구성됨
  • VGAHEAD.WL1VGAGRAPH.WL1 내부 데이터 위치를 가리키는 인덱스임
    • VGAGRAPH.WL1에는 Huffman 압축 데이터가 저장됨
    • VGADICT.WL1에는 압축 해제용 Huffman 딕셔너리가 들어 있음
  • GRE.HGRE.EQU는 엔진이 자산을 이름으로 접근하게 해주는 파일임
    • 예를 들어 L_GUYPIC 같은 논리 이름이 실제 인덱스 값과 연결됨
    • 엔진은 이미지 인덱스를 하드코딩한 상태로 빌드됨
  • Wolfenstein 3D shareware 출시 이후 자산과 코드베이스가 Spears of Destiny와 함께 변하면서, 새로 컴파일한 게임의 인덱스가 기존 자산 파일의 위치와 맞지 않게 됨

VGA 자산 교체와 화면비 보정

  • 해결 방법은 소스 코드에 포함된 .H, .EQU 인덱스와 맞도록 재생성된 VGA 자산을 게임 폴더에 복사하는 것임
  • shareware 자산을 사용할 경우 파일 확장자를 .WL6에서 .WL1로 바꿔 복사해야 함
    • VGADICT.WL6VGADICT.WL1
    • VGAGRAPH.WL6VGAGRAPH.WL1
    • VGAHEAD.WL6VGAHEAD.WL1
  • 교체 후 WOLF3D.EXE를 다시 실행하면 게임이 정상 동작함
  • DosBox 기본 화면은 1992년에 사람들이 본 원래 화면과 다름
    • VGA 프레임버퍼는 320x200
    • CRT 모니터는 4:3 화면비라 출력 시 세로로 늘어나 보였음
  • DosBox 설정에서 [render]aspect=falseaspect=true로 바꾸면 화면비 보정이 적용됨
  • 화면비 보정까지 적용하면 Wolfenstein 3D가 당시 CRT 표시 방식에 가까운 모습으로 실행됨

댓글과 토론

Hacker News 의견들
  • 글 끝에 언급된 Wolfenstein 3D 책을 강력 추천함. 기술적인 내용인데도 딱딱하거나 지루하지 않고, 벽 텍스처 스케일링용으로 펼쳐 둔 함수 64개, 스프라이트를 “옆으로” 저장하는 방식, 괴상한 그래픽 카드 다루기, 애초에 게임처럼 보이게 하려고 그래픽 모드를 해킹하는 방식 같은 옛날식 최적화가 많이 나옴

    • 추천 고마움. 게임 엔진에 관한 431쪽 PDF를 방금 내려받았고, John Carmack의 서문까지 들어 있음
    • 이 책 말하는 건가? https://fabiensanglard.net/Game_Engine_Black_Book/index.php
      아직 나온 건 아닌 것처럼 보이는데, 맞나?
    • 전적으로 동의함. 이런 책이 있는 줄도 몰랐는데 Wolfenstein 3D와 Doom 책 둘 다 정말 재미있게 읽었음. 그가 Quake/i586 책은 쓰지 않을 거라는 점이 아쉬움
    • 후속작인 Doom 책도 훌륭하게 읽힘
  • 레트로 시스템의 좋은 점은 도구만 모으면 다시 빌드할 수 있다는 것임. 최근 재미로 오래된 Uplink 게임을 다시 컴파일했는데, 필요한 건 Visual Studio 6.0뿐이었고 개발 아카이브에 빌드에 필요한 의존성이 다 들어 있었음
    의존성 맞추는 데 한 시간쯤 걸렸지만 결국 성공했고 게임도 잘 돌아감. 사소한 결함도 고치고 여기저기 작은 개선도 넣었음. 요즘 소프트웨어를 만진다고 생각하면 정말 광기임

    • 그건 Linux 패키지 관리가 엉망인 경우에 더 해당하는 듯함. 내가 본 상용 임베디드/Windows 쪽은 보통 의존성을 thirdparty/ 폴더에 벤더링하고, 사용하는 툴체인도 고정해 둬서 설정이 항상 재현 가능했음
    • 요즘은 필요한 것의 상당 부분이 그냥 맞는 버전의 UnityUnreal을 설치하는 것임. Unity 이전 시대에 대해서는 확실히 맞는 말임
    • Uplink 소스 코드가 공개되어 있는 줄은 몰랐음. 멋진 게임
  • Borland Turbo C++ 로 프로그래밍을 배웠음. 그때가 그리운 이유 중 하나는 복잡해 보이는 일을 너무 쉽게 할 수 있었다는 점임. 기하 도형 함수를 호출하기만 해도 화면에 그림이 그려졌고, 도형을 그린 뒤 약간 다른 도형에 xor 함수를 호출하면 애니메이션도 만들 수 있었음
    친구들과 이런 기법으로 Final Fantasy 비슷한 게임을 만들었고, 손으로 만든 스프라이트와 화면 단위 맵, 가장자리로 가면 인접 맵으로 넘어가는 월드, 매 걸음마다 자연수 1이 나오면 전투에 들어가는 구조까지 만들었음. 번거롭긴 했지만 고등학생에게는 정말 재미있었고, 오늘날처럼 시작부터 SFML, ActiveX, OpenGL을 배워야 하는 대신 그냥 circle을 호출하면 됐다는 점이 컸음

    • 아이들이 간단한 도형 프로그래밍을 할 수 있는 환경을 찾으려면 지금도 그런 건 있을 것 같음. 차이는 “전문가용 도구”와 “어린이/입문자용 도구”가 더 크게 갈라졌다는 점이고, Turbo C++ 나 내 시절의 Turbo Pascal은 둘 다에 가까웠음
    • 어릴 때 Borland Turbo C++ 와 학습 자료를 접할 수 있었다는 게 좀 부러움. 나는 지역 컴퓨터 잡지의 리뷰를 읽는 정도가 전부였고, 설령 복사본을 구했더라도 읽을 자료 없이는 뭘 해야 할지 몰랐을 것임. 당시 영어 실력으로는 자료가 있어도 얼마나 이해했을지 모르겠음
    • 현대 2D 그래픽은 프레임버퍼에 픽셀을 찍는 방식이 아니라 텍스처서피스가 시스템의 기본 요소이고 합성은 별도 단계로 처리됨. 그래서 “간단한 스프라이트”를 만드는 건 오히려 쉬워졌고, 합성된 서피스를 하드웨어 스프라이트의 더 일반적인 형태로 생각하면 됨
    • 좋은 옛날의 conio.h와 Borland의 BGI graphics.h가 떠오름. 요즘은 SDL이 어느 정도 그 역할을 하지만 그렇게 단순하진 않음
    • Borland Turbo C++ 는 지금도 내가 가장 좋아하는 IDE로 압도적 1위임
  • 여기서 몇 년 동안 여러 번 언급되는 걸 보고 몇 달 전에 드디어 Masters of Doom을 읽었는데 훌륭한 책이었음. 당시 그들이 만들던 게임은 플레이 자체도 엄청나게 흥미로웠지만, 뒤돌아보면 가진 것 적은 젊은 개발자 몇 명이 무엇을 만들 수 있었는지가 더 큰 영감을 줌

    • Romero가 최근 회고록 Doom Guy를 냈던데, 읽어본 사람이 있는지 궁금함. 괜찮은 책인지 알고 싶음
  • DOS의 텍스트 기반 UI가 정말 그리움. 1997년쯤까지 계속 쓰던 믿음직한 PS/2가 생각남

    • 터미널에서 Midnight Commander라도 쓸 수는 있음
  • C 드라이브에 설치라니, 사치였음! 하드디스크가 없어서 A와 B 드라이브 사이에 플로피를 계속 바꿔 끼웠고, 컴파일러의 교체된 부분을 계속 요구했음. 그래도 우리는 즐겼음. 요즘 애들은 이런 얘기를 늘어놓아도 믿지 않음

    • 1992년에 8.9MB짜리 5.25인치 더블 하이트 하드디스크가 있었고, 5.25인치 360KB 플로피 드라이브도 두 개 있었음. 친구의 720KB 디스크 드라이브와 30MB 하드디스크가 달린 Mac이 부러웠지만, 그 시스템은 내 PC의 아마 6배쯤 비쌌을 것임
    • 1982년이 아니라 1992년
  • Borland C++ 는 정말 뛰어났음. C++ 컴파일러, 표준 라이브러리, 디버거가 있는 IDE가 약 5MB에 들어갔고, 노란색 글자와 파란색 배경의 아늑한 Borland 색상표까지 있었음

    • C++ 튜토리얼이 들어 있는 인쇄 매뉴얼도 함께 제공됐음. 그걸로 예전에 C++를 배웠음
    • OWL도 꽤 좋았음
    • Zortech가 훨씬 나았음
  • Borland의 MS-DOS IDE들은 달콤한 추억임

    • 이런 향수가 있다면 Free Pascal을 확인해 볼 만함. 오픈소스 Pascal/Delphi 클론이고, 파란색 DOS Turbo Pascal 편집기 클론도 들어 있어서 원하는 분위기를 느낄 수 있음
      올해 Advent of Code 며칠치에 써 봤지만 향수는 금방 사라졌음. 현대 환경에 익숙해진 상태에서 IDE의 제약과 Pascal의 장황함은 매일 쓰기에 “재미” 있지는 않았음. 그래도 추억은 확실히 달콤함
    • RHIDE는 마지막 업데이트가 23년 전이긴 해도 아직 소스 코드가 남아 있을 것 같음. 이런 터미널 모드 GUI를 구현할 때 진짜 문제는 Unix/Linux 터미널이 MS-DOS 텍스트 모드 프로그램의 기능을 다 제공하지 않는 터미널 표준에 붙잡혀 있었다는 점임
      특히 Alt 키 단독 입력, Alt+문자 조합, Ctrl+Shift+좌/우 방향키를 인식하지 못함
    • 예전 책장 공간에 Turbo C 매뉴얼이 든 상자를 아직 보관하고 있음
  • 관련 글: Let’s compile like it’s 1992 (2014) - https://news.ycombinator.com/item?id=13750097 - 2017년 2월, 댓글 80개

  • 아카이브를 여는 데 문제가 있었음. wolfsrc.zip에서 End-of-central-directory signature not found 오류가 나고, zip 파일이 아니거나 여러 디스크로 나뉜 아카이브의 일부일 수 있다고 나왔음