세가새턴 (편집) (13)

(편집 필터 규칙)

=== 소프트웨어 ===
앞서 하드웨어 개발과정에서 보여졌듯 기기 개발 과정에서 상당 부분을 이미 만들어진 시스템을 개량해서 강화한 방식으로 3D그래픽을 지원하도록 기능이 변경되었다. 그러나 이러한 해결책은 근본적으로 다 땜질에 불과했고, 무엇보다 이렇게 복잡해진 구조는 프로그래밍하기 어렵다는 결과로 이어지게 된다.

이것이 가져오는 문제는 상상을 초월하게 복잡했다. 일단 새턴의 기본 프로그래밍 구조는 슈퍼패미컴이나 메가드라이브 시절과 별반 다를 바 없는 ‘무에서 유를 창조하는’ 수준의 프로그래밍을 요구했다. 사실 이 당시에도 이미 멀티 프로세서를 사용하는 장비들은 얼마든지 있었다. 당장 세가가 사용하는 세가 SYSTEM24만 해도 게임 롬 보드에 68000프로세서를 추가로 장착해서 돌아가는 게임이 있었고, 메가시디 (MEGA-CD, メガCD) 또한 본체와 별도로 추가 프로세서가 장착되어 있었다. 메가드라이브의 ‘버추어 레이싱’에도 카트리지 내부에 DSP를 내장해 그래픽 가속을 시켜 폴리곤 연산을 시키기도 했으며, 세가는 아니지만 닌텐도의 스타폭스 역시 비슷한 형태로 프로세서를 추가하고 있었다.

이처럼 전에 없던 구조가 아님에도 불구하고 새턴이 개발이 어렵다고 말해지는 것은 작업해야 하는 대상이 2D게임이 아닌 3D게임으로 변환되었기 때문이다. 당연히 작업은 복잡해지고, 처리해야 할 프로세스와 파이프라인은 늘어나는데 새턴에서 제공하는 개발툴로는 그 길어진 프로세스 라인을 메가드라이브 시절과 동일한 방식으로 풀어나가라고 강요받아야 했던 것이다.

일단 세가가 제공하는 라이브러리들이 상당히 빈약해서, OS와 기반은 갖춰져 있었지만 게임을 개발하는데 있어서 필요한 최소한의 것만이 갖춰져 있을 뿐, 현재의 OpenGL이나 DirectX같은 API로 구현된 부분은 거의 제공되지도 못했다. 더 문제는 앞서 하드웨어에서 설명했듯, 스프라이트와 BG를 처리하기 위해서 만들어진 VDP1과 VDP2를 활용해서 소프트웨어적으로 3D그래픽 처리를 하게 만들었기 때문에 사실상 ‘표준 API‘같은것은 애시당초 있지도 않았다. 세가가 제공한 3D엔진은 VDP에서 제네레이트된 폴리곤이나 기타 기능이 CPU로 전달되어서 CPU에서 연산을 해서 만들어진 그래픽을 뿌려주는 단순한 방식으로만 이뤄져 있었을 뿐이었다. 현재라면 프로그램을 API에 맞춰 짜고, 파이프라인 모니터를 통해 발생하는 병목현상이나 잡으면 되는 작업조차도 새턴에서는 하나부터 열까지 직접 계산하고, 돌아가는 것을 확인하고 체크해주지 않으면 안되었다.

특히 이러한 구조는 32비트 세대에 들어오면서 늘어난 용량과 작업량의 증가에 따라서 프로그래밍 언어가 C, 혹은 Cpp로 넘어가면서 총체적인 벽에 부딪히게 된다. 새턴이 선보인 1994년 당시에는 멀티 프로세서라고 하는 것은 저레벨 프로그래밍을 하지 않을 경우에 쓰이는 곳은 서버나 웍스테이션 등의 극히 제한된 곳 뿐이었다.[* 간단한 예를 들자면, 도스5.0 게임을 현재의 쿼드코어에서 돌려봐야 코어1개 밖에 못쓴단 이야기다. 물론 실제로는 돌지도 않는다. 16비트 처리 항목이 빠진지 오래되었기 때문에.] 거기에 MIPS 등의 전통적 아키텍쳐가 아닌 신규 브랜드인 히타치의 SH 시리즈에 맞는 소스는 더더욱 구할 방법도 없었다. 당연히 병렬 프로그래밍을 하기 위한 충실한 라이브러리도, 샘플 데이터도 없었으며, 세가가 그러한 것을 미리 준비해서 제조사에 나눠줬을 리도 없었기 때문에, 말그대로 게임 개발사들은 ‘맨땅에 해딩’해야하는 상황에 직면하게 된 것이다. 유일한 해결책은 고전적인 방식으로 직접 프로세서에서 작업할 스케줄을 수동으로 디자인하고 그것에 맞춰서 개별 프로그램을 짜서 운용하는 방법 뿐이었다.[* 당시 개발사들이 말하던 ‘새턴 개발비가 두배 든다’는 것은 이런 의미다.] 예를 들어서 버추어 파이터 같은 경우에는 아예 게임 캐릭터별로 프로세서를 분할해서 연산하도록 디자인을 해서, CPU0에서는 플레이어1의 캐릭터를, CPU1에서는 플레이어2이 캐릭터를 연산하는 식으로 게임을 개발했다. 당연히 이러한 단순무식하고 바닥을 기는 개발방식은 개발자들에게 기피 대상이 될 수밖에 없었고, 때문에 일부 게임들은 아예 멀티 프로세서를 전혀 쓰지않고 세가가 제공한 기본 라이브러리를 이용해서 싱글코어만을 사용한 게임을 만들기도 했다.[* 아무 생각없이 새턴의 기본 기능만 쓰면 나오는 게임 수준을 대표할 게임은, 단연 ‘[[데스크림존]]’일 것이다.]

또한 세가에서 제공하는 3D엔진은 기본적으로 세가의 아케이드 시스템인 ‘Model’시리즈의 영향으로 3각형이 아닌 4각형(쿼드)의 폴리곤을 사용하도록 디자인되어 실제 게임에 사용하는 디자인 구조에도 좋지 않은 영향을 미쳤다. 3각과 4각 폴리곤을 골라서 쓸 수 있는 것이 아니라 애시당초 4각형의 폴리곤밖에 생성할 수 없게 만들어져 있었던 것이다. 때문에 3각형으로 표현해야 부드럽게 묘사가 가능한 원형이나 곡선 등의 처리가 극도로 부자연스럽게 되거나 더 많은 자원을 투자해야 하는 문제가 발생하게 되었다. 일부 멀티 플랫폼 게임은 둥근 형상을 표현하기 힘들어서 바위 대신 상자를 배치하는 등 괴악하기 짝이 없는 모습을 보여주기도 했다. 심지어는 새턴판 툼레이더의 경우에는 라라 크로포드의 다리를 둥글게 표현하기가 어려워서 폴리곤으로 네모통을 만든다음 그로 쉐이딩으로 둥글게 보이게 처리만 해버렸다고 한다. (물론 사각형에 특화된 모델, 예를 들면 집같은 건물이나 차량처럼 각진 물체만 그리는 경우라면 이득이 있을 수도 있는 기능이기도 하다. 단적으로 그란디아의 마을 등을 생각하면 적당할 것이다)

반면에 라이벌 기종인 소니의 플레이스테이션은 실리콘 그래픽스가 장기간에 걸쳐 갖춰놓은 수많은 개발자 라이브러리와 샘플, 개발툴이 다 갖춰져 있었고, 비록 CPU에서 부동 소수점 연산을 전혀 지원하지는 못했지만 문제가 발생하지 않게 하는 방법과 해결책을 실리콘 그래픽스가 샘플로서 제공해주었다. 소니는 이러한 면을 매우 강조해서 홍보하면서 중소 개발사를 유혹했고, 게임 개발이 주요 업무가 아니었던 프롬 소프트웨어같은 회사들까지 개발사로 끌어들이는데 성공했다. 반면에 새턴 개발사들은 상당 부분을 개발하다가도 개발을 포기하고 플레이스테이션으로 플랫폼을 옮기는 상황이 벌어지게 되었다.

‘버추어 파이터2’와 ‘세가 랠리’ 등이 발매된 1995년 12월에는 해당 문제를 해결하기 위해서 세가 AM 연구소와 콘솔 게임 개발 부서에서 새로운 새턴용 OS를 배포하고[* 이 OS는 게임 개발시 디스크에 포함되는 것으로, 기계 자체에는 따로 설치하지 않는다.] 자신들이 개발하던 게임에서 유용하게 사용되는 트릭과 팁, 그래픽 모드의 활용을 위한 소스를 개발사에 배포하게 되는데, 이후 개발에 큰 도움이 되었다고 전해진다.

(임시 저장) (임시 저장 불러오기)

(↪️) (💎) (🛠️) (추가)

비로그인 상태입니다. 편집한 내용을 저장하면 지금 접속한 IP가 기록됩니다.

편집을 전송하면 당신은 이 문서의 기여자로서 본인이 작성한 내용이 CC BY 4.0에 따라 배포되고, 기여한 문서의 하이퍼링크나 URL로 저작자 표시가 충분하다는 것에 동의하는 것입니다.