[winAPI 10] Resource & Path Manager

 

 

지금까지는 단순히 도형만을 다루어봤다면 이제는 본격적으로 리소스를 활용해보자. 실제 게임에서는 이미지, 사운드 등 여러 리소스가 있고 이를 이용해 화면에 여러 장면을 그려 유저에게 보여준다.

 

우선 이 리소스가 기본적으로 가져야 할 데이터를 모아 Res클래스를 만들어준다 (부모격 클래스)

리소스를 구별하기 위해 고유의 ID와 이 리소스가 어느 파일에 위치해 있는 지를 알려주어야 함으로 경로를 갖고 있어야 한다.

 

// Res.h

#pragma once

class Res {
private:
	wstring key;			// 고유 ID
	wstring strRelativePath;	// 리소스 상대 경로(폴더 내의 변하지 않는 경로)

public:
	Res();
	~Res();

	void SetKey(const wstring& _key) { key = _key; }
	void SetRelativePath(const wstring& _str) { strRelativePath = _str; }

	const wstring& GetKey() { return key; }
	const wstring& GetRelativePath() { return strRelativePath; }
};


// Res.cpp
#include "pch.h"
#include "Res.h"

Res::Res()
{
}

Res::~Res()
{
}

 

 

이때의 경로는 상대 경로로 실행 파일을 기준으로 바뀌지 않도록 하는 부분을 의미한다. 따라서 이 경로를 구하는 관리자가 필요하다.

 

이를 Path Manager라고 하겠다.

 

클래스를 구현하기 전에 우리가 VS로 만든 프로그램을 돌리면 해당 exe 파일이 나오게 되는데, 얘가 실행 파일이다. Debug모드는 우리가 게임을 배포하기 전에 개발 단계에서 디버깅이 용이하도록 하는 버전, Release모드는 배포 버전이라 생각하면 된다. 보통 유저에게 배포하거나 과제를 제출할 때 이 Release 모드로 하면 된다.

 

그렇다면 우리가 게임을 배포할 때 exe파일을 하는데 그 내부의 리소스와 관련 경로는 어떻게 해야 할까?

Release 파일 내부에 리소스 파일을 만들어 놓으면 된다. 

 

일단 이를 위해서 기존에 생성된 파일을 삭제하고 우리가 실행해서 만든 exe파일들을 Output이라는 파일로 관리하도록 설정하자.

 

프로젝트 → 속성 →  구성 : Debug / Release (둘 다 각각 설정해주도록 한다) → 일반 → 출력 디렉터리 설정

 

Debug 설정 : $(SolutionDir)Output\bin_debug\

Release 설정 : $(SolutionDir)Output\bin\

 

이렇게 설정하고 각 버전에서 실행시킨 후 파일을 들여다 보면 아래의 사진처럼 파일이 만들어진 것을 확인할 수 있다.

 

 

bin 파일이 Release모드, bin_debug가 Debug모드로 컴파일 했을 때 생기는 exe파일로, 각 파일에 들어가 exe를 눌러보면 정상적으로 실행되는 것을 볼 수 있다. 

 

 

bin 파일 내부에 리소스를 넣을 Content라는 파일을 넣고 Texture, Sound 등 파일을 만들어보자.

 

bin\Content

 

근데 이러면 Debug 버전으로 돌릴 때 리소스 파일을 어떻게 접근해야 할까? 같은 리소스 파일을 또 만드는 것은 낭비임으로 경로를 설정하여 Release 모드 안의 리소스 파일을 접근해 사용하도록 한다.

 

이제 본격적으로 Path Manager을 만들고 설정해보도록 하자.

 

// PathManager.h

#pragma once
class PathManager{
	SINGLE(PathManager);
private:
	wchar_t		contentPath[255];

public:
	void init();
	const wchar_t* GetContentPath() { return contentPath; }
};


// PathManager.cpp
#include "pch.h"
#include "PathManager.h"

#include "Core.h"

PathManager::PathManager()
	: contentPath{}
{

}

PathManager::~PathManager()
{

}

void PathManager::init()
{
	GetCurrentDirectory(255, contentPath);

	int len = wcslen(contentPath);
	for (int i = len - 1; 0 <= i; --i) {
		if ('\\' == contentPath[i]) {
			contentPath[i] = '\0';
			break;
		}
	}

	wcscat_s(contentPath, 255, L"\\bin\\Content\\");

	SetWindowText(Core::Instance()->getMainHandle(), contentPath);
}

 

 

 

현재 우리가 수행하고 있는 프로그램 실행 파일을 기준으로 경로를 알아오는 함수 GetCurrentDirectory()를 사용하도록 한다. 이를 사용하면 contentPath에 현재 경로가 채워진다. 하지만 리소스 파일은 bin파일에 있음으로 내가 가져온 경로에서 전 파일로 거슬러 올라가야 하는 작업이 필요하다.

 

이는 문자열 관련 헤더 파일을 이용하는 법이 있지만, 간단하게 문자열로 구현이 가능하다.

 

 

가져온 경로를 거꾸로 탐색하여  '\\' 를 만나면 거기서 멈추면 된다.

 

근데 여기서 한 가지 문제가 발생하는데

F5와 Ctrl + F5의 실행 결과는 다른 경로로 진행된다는 점이다. 그래서 F5를 눌렀을 때도 기존 생성된 리소스 파일로 접근이 가능하도록 해야 한다.

 

아래의 설정을 하면 된다.

 

프로젝트 → 속성 →  구성 : 모든 구성 → 디버깅 → 작업 디렉터리 변경

$(SolutionDir)Output\bin\

 

 

 

경로를 끊었기 때문에 그 다음에 bin파일의 리소스 파일로 접근하는 경로를 붙여주면 된다.

 

설정된 경로

 

 

 

PathManager의 init()을 Core 클래스 내부에서 불러주는 작업도 잊지 말고 해야 한다.

이렇게 하면 exe가 포함된 파일의 위치가 변경되더라도 정상적으로 리소스가 반영될 수 있다.

 

---

 

 

 

게임 내의 여러 이미지 파일을 Texture라고 부르는데 여러 모델링에 관련 텍스쳐를 입혀 물체를 나타내는 방식이 많다.

 

// Texture.h

class Texture : public Res {
private:
	HDC			dc;
	HBITMAP		bit;
	BITMAP		info;

public:
	Texture();
	~Texture();

	void Load(const wstring& _str);
	UINT Width() { return info.bmWidth; }
	UINT Height() { return info.bmHeight; }

	HDC GetDC() { return dc; }
};


// Texture.cpp
#include "pch.h"
#include "Texture.h"

#include "Core.h"

Texture::Texture()
	: bit(0)
	, dc(0)
	, info{}
{
}

Texture::~Texture()
{
	DeleteDC(dc);
	DeleteObject(bit);
}

void Texture::Load(const wstring& _str)
{
	bit = (HBITMAP)LoadImage(nullptr, _str.c_str(), IMAGE_BITMAP, 0, 0, LR_CREATEDIBSECTION | LR_LOADFROMFILE);
	assert(bit);	// 비트맵이 없을 경우의 에러 처리

	// 비트맵과 연결할 DC
	dc = CreateCompatibleDC(Core::Instance()->GetMainDC());

	// 비트맵과 DC 연결
	HBITMAP preBit = (HBITMAP)SelectObject(dc, bit);
	DeleteObject(preBit);

	// 가로 세로 길이
	GetObject(bit, sizeof(BITMAP), &info);
}

 

 

우리가 조작하는 플레이어를 리소스를 활용해 표현해보자.

 

// Player.h

#pragma once
#include "Object.h"

class Texture;		// 추가

class Player : public Object {
private:
	Texture* tex;

	void CreateMissile();

public:
	Player();
	~Player();

	virtual void update();
	virtual void render(HDC _dc);	// 추가
};


// Player.cpp


#include "PathManager.h"
#include "Texture.h"

Player::Player()
	: tex(nullptr)
{
	// Texture Loading
	tex = new Texture;
	wstring strPath = PathManager::Instance()->GetContentPath();
	strPath += L"Texture\\Player.bmp";
	tex->Load(strPath);
}

Player::~Player()
{
	if(nullptr != tex)
		delete tex;
}

void Player::render(HDC _dc)
{
	int width = (int)tex->Width();
	int height = (int)tex->Height();

	Vec2 vPos = getPos();

	vPos.x - (float)(width / 2);
	vPos.y - (float)(height / 2);

	TransparentBlt(_dc
		, int(vPos.x - (float)(width / 2))
		, int(vPos.y - (float)(height / 2))
		, width, height
		, tex->GetDC()
		, 0, 0, width, height
		, RGB(255, 0, 255));
}

 

 

Player가 생성될 때 해당 리소스를 만들고 소멸될 때 해제하도록 한다.

기존 Object에서 그렸지만, 이제는 리소스를 갖고 그려야 하므로 render함수를 만들어야 한다.

 

만약 위의 코드가 아니라 아래의 BitBlt으로 그리면 모든 픽셀을 옮겨 찍음으로 리소스를 통째로 찍게 된다.

	BitBlt(_dc
		,int(vPos.x - (float)(width / 2))
		,int(vPos.y - (float)(height / 2))
		,width, height
		, tex->GetDC()
		, 0, 0, SRCCOPY);

 

 

 

그렇기에 특정 색을 제외하고 그리는 방식이 있는데 이때 이 특정색은 보통 RPG(255, 0, 255) 의 마젠타 색을 사용한다. 여기서 마젠타 색은 현실에서 거의 안 쓰는 색을 의미한다.

 

 

 

TransparentBlt 함수가 특정 색을 제외하고 그리는 함수다. 자세한 설명은 아래 포스팅을 참고하도록 해라.

https://blog.naver.com/power2845/50147965306 

TransparentBlt 함수

 

 [ 주의 ]

이 함수를 쓰려면 해당 라이브러리가 필요하다. pch 파일에 아래를 추가해주어야 한다!!!

#pragma comment(lib, "Msimg32.lib")

 

결과

미사일도 OK

 

 

 

지금까지 포스팅한 코드는 여기서 확인이 가능하다.

포스팅을 기준으로 커밋하여 나누어 놨다.

https://github.com/MiyeongEom/GameBasic/commits/main/

GitHub - MiyeongEom/GameBasic

 

 

사용한 텍스처 파일도 위의 깃허브에서 받을 수 있다. 갤러그에서 따온건데 바탕은 내가 열심히 처리함..

 

---

 

 

우리가 지금까지 짠 코드에 문제가 없을까?

만약 몬스터도 이와 같이 짠다면, 몬스터를 몇 천마리, 몇 만마리를 생성하게 되면 리소스가 그만큼 동적으로 할당된다😵😵😵. 이렇게 됐을 경우 메모리를 먹다가 용량 부족으로 죽을 수도 있고 그전에 일단 같은 리소스를 계속해서 불러 만드는 것 자체가 비효율적이다.

 

따라서 필요한 것이 Resource Manager다.

얘를 통해 모든 리소스를 관리하게 되면, 오류가 생겼을 때도 금방 찾을 수 있게 구조가 짜여서 좋다.