처음 C언어를 배워서 게임을 만드려고 했을때가 기억난다.
첫번째 게임은 테트리스였는데 그래픽을 다룰줄 몰랐기 때문에 텍스트 모드에서 만들었었다.
두번째 게임이었던 사다리 게임도 텍스트 모드에서 작업했다.
텍스트 모드에서의 작업은 꽤 직관적이고 쉬웠다.
그리고 세번째로 만드려고 생각했던 게임이 바로 테니스 게임이었는데...
테니스 게임은 그래픽 모드에서 만드려고 생각했다.
스크롤이나 그런건 할줄 몰랐지만 테니스라는 게임의 특성상 스크롤이 필요하지 않았으므로 그냥 테니스 선수와 공만 그리면 되었다.
허큘레스 해상도인 720*360으로 충분하다고 판단되었다.
그런데 막상 그래픽 모드에서 움직이는 공을 그리려고 하니까
이전에 그렸던 공이 문제가 되었다.
텍스트 모드에선 배경이란게 존재하지 않았다.
테트리스에서 움직이는 블럭을 그릴때도 그냥 이전걸 지우고 새로 그리면 그만이었다.
그러나 공은 그렇지 않았다. 단순히 지우는게 아니라 공의 위치에 맞게 배경이미지를 잘라붙여서 원상복구해야만 했다. 이 계산이 만만치가 않았다.
그나마 화면에 움직이는게 공 하나뿐이라면 이것도 할만한 작업이었다. 좌표계산해서 배경이미지에서 잘라붙이면 되니까.
그러나 공과 선수가 궤적에서 겹치게 되면 단순히 배경이미지만 잘라서 붙인다고 해결되는게 아니었다. 선수이미지도 잘라붙여야 하는 것이다.
화면에 움직이는 스프라이트가 달랑 3개뿐인데도 이렇게 복잡해진다니... 대체 슈팅게임같은건 어떻게 만드는걸까? 난 신기하기 짝이 없었다.
사실 이 의문은 본질적으로 윈도우 관리 시스템을 어떻게 만드느냐와도 같았다.
윈도우를 움직이면 그 윈도우에 가려져있던 아래쪽 윈도우가 드러나면서 일부분만 새로 그려진다.
어떻게 저게 가능할까? 나는 그게 너무 궁금했었다.
한참 나중에서야 알았다... 딱 직전과 비교해서 달라진 부분만큼만 화면을 복원하는 식의 우아한 알고리즘은 존재하지 않는다는 것을... 훨씬 더 무식한 방법으로 만들어진다는 것을...
게임은 매번 전체 화면을 다시 그리는 방식이었다. 배경이미지에서부터 시작해서 모든 스프라이트들을 제로 베이스로 다시 그리는 것이다. 그걸 1초에 수십번 반복하는 것이다. 즉 게임이란건 내가 아무것도 안하고 가만히만 있어도 CPU는 엄청 허벌나게 바쁜 것이다. (사실 게임뿐만 아니라 유저입력을 대기하는 모든 프로그램이 그렇다. 나는 그 당시에 유저입력(키보드, 마우스)를 어떻게 처리하는 것일까도 궁금해했는데 설마 무한루프를 돌면서 유저입력이 발생할때까지 무한대기를 하는거라고는 생각도 못했다.)
나는 설마 그렇게 무식한? 방법일거라고는 상상도 못했다. 내가 생각못하는 우아하고 깔끔한 그래서 컴퓨터의 작업량을 최소화하는 그런 알고리즘이 있을거라고 생각했는데... 그게 아니었다. 깔끔하게 계산이나 작업만 하는게 아니라 CPU는 항상 100% 바뻤다. (CPU점유율 어쩌구는 나중에 멀티태스킹이 나오고 나서의 얘기)
윈도우도 마찬가지다. 윈도우의 위치가 달라지면 그에 영향받는 모든 윈도우를 전체적으로 다시 그리는 것이다. 게임도 그렇고 윈도우도 그렇고 항상 전체를 다시 그리지만 그려지는 중간과정이 화면에 노출되지 않으므로 얼핏 보기에는 마치 아주 약간만 변경되는 것처럼 보이는 것이다.
이걸 나중에 알았을때 얼마나 허무하던지...
물론 이게 아주 비합리적?인 구조인건 맞다. 이건 어디까지나 옛날 도스 시절 이야기이고... 현대적인 OS가 등장하면서 이런 비효율은 우아하고 어려운 방법으로 개선된다. 적어도 윈도우는... 옛날처럼 사용자 입력을 무한루프로 대기하지도 않고 윈도우의 이동이 있을때마다 매번 윈도우를 다시 그리지도 않는다. (사실 어찌보면 훨씬 더 무식해졌다... 윈도우나 안드로이드도 게임처럼 화면 전체 갱신을 항상 다시 하고 있다. 그래서 부드러운 애니메이션 구현이 가능한거고) 다만 게임은 기본적으로 도스 시절과 구현 방법이 전혀 달라지지 않았다. 다만 요즘 게임 엔진 써서 게임 개발하면 아랫단 구현인지라 그걸 느끼기 어려울 뿐이다.
