저번 포스팅에서 만든 프로젝트의 설정을 마무리해하기 위해 엔트리 포인트를 설정해보자. 그리고 앞으로 작성할 DirectX 2D 코드가 어떤 의미를 가지는지 알아보자
프로젝트의 기본 엔트리 포인트 세팅
저번 포스팅 때 만든 프로젝트에서, 우측의 프로젝트 탐색기 창에서 오른 클릭 -> 추가 -> 새 항목
C++ 파일 선택 -> 파일명으로 "Main.cpp"을 권장한다.
아래 사진을 보면 기본 파일들의 옵션 외에 윈도우 아이콘 모양을 한 추가적인 파일 옵션들이 보인다.
이는 비쥬얼 스튜디오의 DirectX 관련 추가 패키지들을 모두 설치한 후 생기는 옵션들로 현재로선 별 필요가 없다.
그냥 C++ 파일을 선택하자.
앞서 말했듯, Windows의 C나 C++ 컴파일러가 기본적으로 인식하는 엔트리 포인트 함수명으로 아래와 같은걸 쓴다.
- main()
- WinMain()
- wWinMain()
이런 함수명을 바꾸고자 할 때는 어딘가 추가적인 설정을 해서, 개발자의 이런 의사를 컴파일러에게 전해줘야 할 것이다.
이전 포스팅의 설명대로 만들었다면 엔트리 포인트는 WinMain()이나 wWinMain()이다 (Windows API용)
테스트를 위해 아래의 코드를 Main.cpp에 넣고 F5로 컴파일해보자
#include <Windows.h>
int APIENTRY wWinMain(_In_ HINSTANCE hInstance,
_In_opt_ HINSTANCE hPrevInstance,
_In_ LPWSTR lpCmdLine,
_In_ int nCmdShow)
{
return 0;
}만약 컴파일 시 Link에러가 뜨거나 하면 함수명을 wWinMain 대신 WinMain으로 해보자, 그것도 안돼면 main으로 해보자. (아마 될 것이다)
"참조를 확인할 수 없는 외부 기호" 같은 오류 메시지가 나올 것이다.
앞서 말했던 엔트리 함수(프로그램의 시작점)의 형식이 정확하지 않아서 발생한 문제다.
아래와 같은 절차로 직접 정의하자
- 솔루션 탐색기 -> 프로젝트 우클릭 -> 속성
- 링커 -> 시스템
- 하위 시스템 설정 (창/SUBSYSTEM:WINDOWS)
만들어진 프로젝트의 초기 엔트리 포인트명이 콘솔식(main)으로 설정되어 있던 것.
에러 없이 성공적으로 컴파일되고 실행되면 Visual Studio 2022에선 아래 메시지와 비슷한 메시지가 뜬다, 창은 안뜬다 만든게 없으니 뜰게 없다.
DirectX의 교과서 MSDN
본격적인 개발에 앞서 참조할만한 자료(레퍼런스)를 알아보자 근래에는 무적의 ChatGPT가 있지만 기본이라 볼수 있는 공식 자료 역시 존재한다.
MSDN - WindowsAPI를 설명하는 MicroSoft 사의 공식문서
앞으로 사용하게 될 DirectX 함수들의 기본 코드들은 보통 이 문서의 예제 코드나 샘플 코드에서 시작한다.
DirectX와 GDI
DirectX가 없던 시점에 윈도우는 WinAPI에서 기본적으로 제공되는 API(함수들)를 활용했으며 멀티미디어 처리를 하는데 이것들은 고성능 그래픽카드 등의 하드웨어에 의존하지 않는다.
그냥 Windows가 운영하고 있는 CPU의 고유 능력으로만 일을 하는 함수들.
이런 기초 이미지 처리 환경을 GDI 환경이라고 한다(Graphics Device Interface).
Windows 탐색기의 창이나, 바탕화면, 아이콘 처리등이 다 이 GDI API로 구현된 윈도우의 기본 그래픽 환경이다.
사실 GDI 만으로도 2D 게임 정도는 충분히 완성도 있는 결과물을 만들 수 있다.
그리고 GDI환경과 DirectX 2D 환경은 그 사용법만을 놓고 봤을 때 매우 흡사하다. 아래의 용어를 지금 다 알순 없지만 양쪽 환경에서 비슷한 도구를 호칭하는 단어라 보면 된다.
| GDI 환경 | DirectX 환경 |
| DC (Device Context) - 기본 그리기 도구 | RenderTarget |
| Rectangle() - 사각형 그리는 함수 | DrawRectangle() |
| CreatePen() - 그리기 도구에 꽂아서 사용할 팬 생성 | CreateSolidColorBrush() |
| LoadImage() - 비트맵 출력 | LoadBitmapFromFile() |
이런 과정이 좋은 게 GDI 환경이 매우 기초적인 환경이라 이걸로 먼저 만들어 놓으면 나중에 DirectX뿐 아니라 모바일이나 웹으로 이식하기도 편하다. (iOS 이전은 좀 불편)
단 GDI는 상대적으로 느리며 그래서 속도 개선을 위한 최적화 작업을 고려할 필요가 있는데, 이런 최적화 작업이 코드를 오히려 더 난해하게 만들어 버릴 수도 있다.
DirectX가 게임 시장에서 가진 의미
게임 개발 환경은 사용자의 니즈에 의해 많이 발전되어 왔다.
처음에는 콘솔 환경 아래서 게임이 시작되며, 모든 그래픽 처리 기능들을 게임 개발자가 다 만들어 줘야 했지만,
지금은 안정성과 생산성이 보장되는 다양한 게임엔진들이 개발자들에게 제공되고 있다.
아마 최초로 널리 알려진 게임 엔진은 쯔꾸루 시리즈였을 것이다.
현재는 유니티 엔진, 고도 엔진, 언리얼 엔진 등이 널리 사용되고 있으며 쯔꾸루와는 비교할 수 없는 막강한 구현 능력을 자랑한다. 반면에 게임 엔진의 사용 방법은 DirectX보다 훨씬 쉬워서 공대생이 아닌 미대생이나, 중고등학생들까지도 게임 개발을 해나가고 있을 정도다.
하지만 이런 개발 툴은 결국 어느 정도 정해진 형식을 따라서 만들어야 생산성이 극대화된다. 예를 들어 현재 게임 엔진으로 만들어진 게임 중에는 액션 게임이나, 건슈팅 게임은 많은데, 롤플레잉 게임이나 전략 시뮬레이션 게임들은 상대적으로 드물다
물론 개발 역량에 따라서 얼마든지 구현이 가능하다. 단지, 자유로운 형식의 게임 개발을 선호할수록 자체 게임 엔진에 대한 필요성이 커진다.
고도 엔진(Godot)역시 전문성있는 게임 개발에도 적합해 보인다. 아직 시장에 자리잡지는 못했다
게다가 대규모 게임 프로젝트일수록 게임엔진 사용을 위한 라이선스비가 크다. 경우에 따라 매달 게임엔진 프로그램을 사용하고 있는 개발자들의 수에 비례해서 꼬박꼬박 사용료를 내야 하거나, 엔진을 이용해 만든 게임이 수익을 낸것에 비례해서 사용료를 내야 한다. 게임 엔진 자체의 소스코드를 오픈받거나 그것을 개량하고 싶다면 또 상당한 양의 추가 비용을 지불해야 한다.
거기다 최적화 하는데는 약간 불리해서 게임이 조금 느릴 수 있다. 대규모 프로젝트로 게임을 만들 땐, 이래 저래 불리한 부분이 있는 것.
그래서 게임엔진을 이용한 게임 개발은 소규모 그룹에 유리하다. 언리얼 엔진은 대규모 프로젝트에서도 쓰이지만 유니티 같은 경우 상대적으로 작은 업체들이 이 게임 엔진을 쓰며,
스마일 게이트의 로스트 아크나 펄어비스의 검은 사막 등은 자체 개발 게임 엔진을 쓴다.
이때 이런 PC 기반 게임들은 자체 게임엔진을 만들 때 DirectX를 쓰고 있다.
DirectX 2D와 DirectX 3D
DirectX 2D는 DirectX 3D를 기반으로 사용하기 때문에 3D보다 상대적으로 느리다.
3D환경을 2D처럼 보이게 해서 사용하는 상황인 것.
그래서 아이러니하게도 그냥 Direct 3D를 써서 2D 게임을 구현하면 오히려 빠르다.
이 경우 많은 3D 설정과 마주하게 될 것이며 게임 코드가 2D API를 사용하는 것보다 난잡할 수 있다
다만 차후 필요한 경우 DirextX 2D 환경을 3D환경으로 이전하도록 하겠다.
위의 레이어 층에서 DXGI도 DirectX 3D가 관리하는 API중 하나인게 보인다.
이는 하드웨어에 직접적으로 닿아 있기 때문에 개발환경의 변화 속도가 느리다.
반면 DirectX 3D 본 레이어 부분은 하드웨어로부터 더 독립적인 성향이 있기에 빨리빨리 업데이트되고 패치되는 편이다.
Software Resterizer 파트는 그래픽 카드(GPU)의 고성능 기능을 사용할 수 없을 때 CPU만으로 관련 기능을 구현하기 위해 사용된다. (그래서 느리다)