똥컴에서 그래픽 작업을 해야했던 프로그래머들의 노력

초창기, 그러니까 게임기는 커녕 PC라는 개념조차 이제 막 제시되기 시작하던 때에 게임기의 성능이란 정말로 조악하기 그지없었다.

지금이야 램으로 16GB정도는 달아야 괜찮은 컴퓨터 소리정도는 듣는 수준이고, 8GB는 거진 마지노선, 

4GB를 달면 스마트폰만도 못한 고리짝시절 컴퓨터 취급을 받는 게 아주 흔하지만,

초창기 컴퓨터들은 기가바이트는 커녕 킬로바이트대에서 아웅다웅하며 니가 낫네 내가 낫네 하는 수준이였다.

그 당시 빌 게이츠가 "램으로 640KB면 가정용으론 충분하다"라는 말을 했다는 루머는 아직까지도 유명하다. 

초창기 프로그래머들은 이딴 개똥 쓰레기 컴퓨터들로 게임 그래픽 구현을 하기 위해 갖은 수를 궁리했고,

그 결과 중 하나가 color cell 방식이였다.

자세히 파헤쳐보자.

당시 게임기에 탑재된 비디오 칩(=그래픽 카드)에는 오늘날의 그래픽 카드와 달리 별도의 메모리가 달려있지 않았기 때문에

그래픽 작업을 위해선 꼼짝없이 CPU와 함께 램을 이용해야 했다.

이는 즉, 게임의 실행 코드와 그래픽 코드가 같은 램 위에서 처리되어야 한다는 뜻.

16KB의 램 용량이 대부분이고 비싸야 32KB, 정말 많아야 64KB가 대부분이던

그 당시 게임기들에게는 매우 가혹한 환경이 아닐 수 없었다.

구체적으로 계산을 해보자. 그 당시 일반적인 게임 해상도는 대게 320X200으로, 계산해보면 총 64000픽셀을 처리해야 한다.

가장 단순한 흑백 스크린부터 시작해보자.

흑백을 표현하기 위해선 픽셀 켜짐(백색)/픽셀 꺼짐(흑색)만 표현하면 되므로,

각 픽셀에 2개의 상태를 처리할 메모리(램)만 주면 된다.

마침 메모리 최소 단위 1비트가 2개의 상태를 처리할 수 있으므로 각 픽셀에 1비트씩 주면,

64000*1=64000비트=8000바이트=8KB

(1바이트는 8비트,1KB는 1000바이트다)

그래픽 처리를 위해서 총 8KB가 필요하다.

16KB 램 용량의 절반을 썼지만, 이 정도면 남은 자리에 게임 코드를 넣기에는 문제가 없어 보인다.

그러나 사람이 흑백 스크린만 보면서 게임을 하는 걸로 만족할 수는 없는 법.

색깔을 넣으면 어떻게 될까?

컬러 표현을 위해 16색을 구현하고자 한다고 생각해보자.

이번에도 각 픽셀에 16색을 처리할 만큼의 메모리를 주어야 한다.

1비트는 2개의 정보를 처리할 수 있으므로, 16색, 즉 16개의 정보를 처리하고자 한다면,

1비트 4개를 이어붙여 4비트를 만들면 된다.(2⁴=16)

고로 16색을 표현하고자 한다면 한 픽셀에 4비트를 할당해야 한다.

픽셀의 개수는 총 64000개이므로 

64000*4=256000비트=32000바이트=32KB

갑자기 16KB는 커녕 32KB 램으로도 게임 구동이 불가능해졌다!

16색으로 이 지경이니 그보다 더 많은 256색이나(한 픽셀에 8비트 요구, 총 64KB 램 요구) 

현대식 트루컬러(한 픽셀에 24비트 요구, 총 192KB 램 요구) 따위를 구현하는 건 어림도 없을 일이였다.

이런 상황을 돌파하기 위해 만들어낸 기법이 바로 color cell.

화면을 여러 구역(cell)로 나누고, 그 안의 색만 바꾸는 것이다.

픽셀로 된 화면을 그려보겠다.

이 화면에서 글자를 출력하고 싶다고 가정하자.

cell, 즉 구역을 나눈다.

가로 8픽셀, 세로 8픽셀씩 나눈다.

구역을 나눴으므로 픽셀 하나하나 색을 바꾸는 것이 아니라, 

각 구역에서 색을 바꿀 픽셀의 위치와 그 픽셀의 색깔 정보만 처리하면 된다.

구역 안의 글자의 색, 배경의 색을 지정해준다.

처음엔 흑백이였던 글자에 색깔이 추가되었다.

이런 식으로 구역을 나누게 되면, 각 구역은 배경색과 글자색의 결정을 위해 1바이트의 메모리만 소모한다.

(각 구역 당 픽셀은 8*8=64개, 글자 위치 정보+글자 색깔 정보+배경 위치 정보+배경 색깔 정보로 총 4개의 정보를

각 픽셀이 처리하도록 할당해 주면, 64+64+64+64=256개의 정보 처리가 필요하다.

1바이트=8비트, 2⁸=256, 즉 각 구역당 1바이트가 소모된다.)

그러면 색깔을 다 넣고도 전체 그래픽 처리를 위해 단 9KB만 필요해진다!

기존 방식에서는 흑백 처리조차 8KB가 들었던 것을 생각해보면 대단히 효율적임을 알 수 있다.

그러나 이 방법은 한눈에 봐도 한 가지 치명적인 문제점이 드러난다.

이렇게, 구역 중간을 잇는 그래픽을 구현하고자 하는 경우.

위의 예시는 색깔 제한 2개를 넘었기 떄문에(글자색과 배경색) 구현될 수 없다.

두 구역을 넘나드는 요소를 구현하고 싶다면,

프로그래머는 각 구역을 따로따로 분리해 이어붙이는 식으로 구현하는 수밖에 없었다.

구역 당 색깔이 2개로 제한된 와중에 이런 제약이 붙게 된다면 

프로그래밍 난이도는 지옥으로 가버릴것이 뻔했다.

그래서 프로그래머들은 어떻게 이것을 구현했느냐?

그냥 노가다로 했다.

추가)

만약 프로그래머가 더 나은 컬러 출력을 원한다면, 이런 것도 가능했다.

당시 게임기중 하나인 코모도어 64는 멀티컬러 모드란 것을 지원했는데,

이것은 픽셀 너비를 2배로 늘려 픽셀의 위치 정보에 소모되는 메모리를 반으로 줄이는 대신,

각 구역에 색깔을 4개씩 할당할 수 있게 한 것.

픽셀이 커졌으니 해상도가 상대적으로 낮아지지만, 색깔 구현을 더 자유롭게 할 수 있으니 수용할만한 거래였다.

그리고 이건 그 결과물.

출처:How "oldschool" graphics worked Part 1 - Commodore and Nintendo - YouTube

(그래픽 구현에는 color cell 방식 말고 다른 방식도 있는 것 같던데, 그건 좀 지루해보여서 안 넣었음.

더 궁금하면 출처 찾아가서 보셈.)