(d+019) OpenGL

#devjournal #gamedev #learning

스팀, 프로그래밍 게임 축제

스팀을 오랜만에 켜보니 프로그래밍 게임 대축제를 하고 있다. 퍼즐게임을 워낙 좋아해서 한번 쭉 훑어봤지만 뭔가 구미가 당기지 않는다. 차라리 이럴꺼면 하던거 마저할까? 이런 생각이 들었다.

며칠전부터 만들어온 타일맵에 드로우콜(렌더링호출)을 줄이고 렌더속도를 올리고자 타일맵에 Atlas를 적용해 보았다.
타일을 화면에 표시할때 비디오램에서 같은 텍스쳐를 가져와서 한번에 렌더링을 해야 하는데 엉성하게 만든 클래스 조합이 발목을 잡는다. 처음에는 타일마다 렌더링 객체를 붙혀 작성하여 관리가 편하게 느껴졌지만 배치렌더링을 위해 기존에 있던 것들을 다 부시고 만들었다. 눈으로 보기에는 그저께 그렸던 것과 똑같지만 내부는 완전히 새로운 것으로 바뀌어 나름의 뿌듯함이 느껴졌지만... 눈에 보이는 바뀐점이 없으니 조금은 아쉽다는 생각이 들었다.
타일맵에서 더 해볼것들이 많이 있으나... 여기서 계속 눌러 앉기에는 다음할 것 들이 태산이다... 그래서 액터를 등록하고 움직이는 객체를 추가하는 것은 다음으로 넘겼다. 게다가 다음장부터는 렌더러를 바꾸기 때문에 오늘까지 만들어둔 2D 기반의 렌더러는 더 이상 사용하지 않는다.

타일맵 만든다고 일주일이나 소모했다. 나름 이것저것 해본다고 C++가 친해졌다. OOP 개념이야 평소에 기본적으로 잘 사용하고 있다고 생각했지만 낯선 느낌이 난다. 최근 몇년 업무에 사용하는 언어가 Go, TS 다 보니 다형성 관련해서 쓸일이 없어 아마 기억속 저 너머로 잊혀지고 있었던것 같다. 게다가 C++ 에는 다중상속(Mix-in)이 되고 Java 의 객체 구조와 다르게 접근제한자도 의미가 소폭 다르다. 알고있던 것들을 기반으로 코딩을 하다보니 어처구니 없는 실수를 계속했다.
"새 술은 새 부대에 담아라" 라고 했는데 나는 자꾸 기존의 판단의 관성에서 벗어나질 못한다. 템플릿함수도 기존에 알고 있던 제네릭이랑 상이해서 2단계 조회 후 순환참조 때문에 한참을 고생했다.
대략 10년을 컴퓨터로 밥벌어먹고 살았는데, 내가 이정도로 무지했나 싶을 정도로 너무 섬세하고 풍부한 언어다. 최적화를 위해 맴버변수의 크기(정확히는 패딩)에 따라 순서도 정해서 나열해야 하는 것마저 신비롭기만 하다. 그 동안 컴퓨팅 성능과 상관없이 개발자가 읽기 편하고 관리하기 편한 코드를 작성하는데 큰 힘을 들였다면 게임은 그 정반대가 되어야 한다. 기계친화적이고 비인간적이어야 하니... 머리가 조금 아프다.

책의 5장 부터 이제 본격적인 3D 화면을 그릴 준비를 한다. 4장까지는 2D 기본 SDL 렌더러를 사용했지만 이제는 OpenGL 을 사용한다고 한다. 뭔가 알아볼수록 구닥다리의 냄새가 나지만 이게 기초중에 기초고, 이걸로 어느정도 기초개념을 쌓은 다음에 Vulkan 이나 DX3D 로 가는 것이 순리라고 하니 바닥을 잘 다져나가야 겠다.
덕분에 지금까지 해온 엔진에서 렌더링 부분을 통째로 걷어냈다. OpenGL 관련된 기능은 초기화 이외에 추가하지 않아서 ... 어쩌면 2주전 처음 검정색 화면을 봤던 그때로 다시 돌아간 느낌이다. 그때랑 다른거는 이제 어느정도 게임루프에 맞춰 최적화된 프로그래밍을 해야한다는것. 그리고 60프레임 (16.66 ms) 안에서 어느정도 컴퓨팅 파워(속도)가 남았는지 체크하는 로거가 등장한다는 것이다. 주말내에 검정화면에 뭐라도 하나 띄울수 있으면 좋겠다.