1993년 그래픽, 현대 기술로 부활하다!

커뮤니티에서는 텍스처에 8x8 또는 16x16 라이트맵(Lightmaps)을 적용하여 깜빡이는 횃불(Flickering Torches)이나 복도를 비추는 로켓(Rockets Lighting Hallways)과 같은 동적 조명을 구현하는 기법이 논의되었습니다. 각 룩셀(Luxel)의 밝기 값을 계산하여 텍스처 룩업 테이블(Lookup Table)로 실제 픽셀 색상을 결정하는 방식은 당시 성능 제약 하에서 놀라운 렌더링 성능(Surprising Rendering Performance)을 제공했다고 언급됩니다.

글에서 소개된 레이캐스팅 엔진은 둠(Doom)의 영감과 함께 울펜슈타인 3D(Wolfenstein 3D)의 수직 벽(Perpendicular Walls) 및 고정 높이 바닥/천장(Constant Floor/Ceiling Height) 특징을 계승했습니다. 하지만 BSP 트리(BSP Tree) 엔진을 사용한 둠이나 듀크 뉴켐(Duke Nukem)과 달리, 벽이 교차하는 각도나 바닥/천장 높이에 유연성이 부족하다는 지적이 있습니다. 이는 다층 구조 설계(Multi-story Level Design)의 한계로 이어집니다.

본문에서 제시된 텍스처 생성 파이프라인(Texture Generation Pipeline)은 높이맵(Heightmap)을 사용하여 노멀맵(Normal Map)을 생성하고, 이를 통해 간단한 조명과 그림자(Simple Lighting and Shadows)를 구워내는 방식을 사용합니다. 댓글에서는 1993년에 이러한 접근 방식이 사용되지 않았으며, 당시에는 수작업 텍스처(Hand-drawn Textures)가 일반적이었다는 의견이 있습니다. 그럼에도 불구하고 현대적 기법이 더 나은 시각적 결과(Better-looking Result)를 제공할 수 있다는 점은 인정됩니다.

1990년대 초중반의 그래픽 프로그래밍은 메모리 맵 비디오 RAM(Memory-mapped Video RAM)에 직접 픽셀 데이터를 쓰는 방식으로 화면에 표시되었습니다. 당시 0xA0000 포인터만 있으면 API 없이 직접 제어가 가능했으며, 320x200 VGA 모드의 비정방형 픽셀은 16비트 세그먼트(16-bit Segment)에 맞는 64000바이트 버퍼 크기 때문이었다는 설명이 있습니다. 이는 16비트 코드/CPU(16-bit Code/CPUs) 환경에서 주소 지정의 용이성을 높였습니다.

소프트웨어 렌더링을 직접 경험하고 싶다면 SDL2를 사용하여 ARGB8888 2D 배열을 효율적으로 화면에 출력하는 C 코드를 참고할 수 있습니다. 다만, 320x200x8비트 팔레트 프레임버퍼(Palettized Framebuffer)를 ARGB로 변환하는 작업은 별도로 필요합니다. 팔레트 기반 프레임버퍼(Palettized Framebuffers)의 가능성을 보여주는 예시로 Canvas Cycle 데모와 Deluxe Paint IIe, Aseprite 같은 도구들이 언급됩니다.