GameForFun

일단 우리가 필요한 정보는 다음과 같다.

1. 이미지의 시작점, 가로와 세로의 크기.

2. 해당 이미지가 어떤 값을 대표하는가.

따라서 숫자 0,1,2,3,4를 쭉 이어놓은 이미지라 하면

('0'의 아스키), 0, 0, 10, 10 을 얻어오게 되고 우리는 (0,0) ~ (10,10)을 사각형의 메쉬 uv값으로 정해주면 된다.

문자들의 출력을 담당하는 것은 다음과 같이 하면 된다.

int[]를 가지고 있는다 -> 이놈은 어떤 문자가 몇번째에 와야되는지 저장하는 버퍼의 역할이다.

int[]의 수만큼 mesh의 사각형을 생성하고, 우리가 가져올 이미지의 가로 크기 + 일정 간격만큼 좌, 혹은 우로 옴겨준다.

http://gamedevforever.com/19

간단히 그래픽스에서 그려지는 것의 내용에 대해 정리해보기 위해 글을 쓴다.

한 면, 삼각형은 3 점으로 구성된다. 간단하게 생각하기 위하여 삼각형을 화면에 그린다고 생각하자.

삼각형의 3 점은 해당 좌표계에 적절히 배치되어 있을 것이다. Local Space
그런데 우리는 삼각형을 그리기 위해서는 3점을 World Space(월드 좌표계)에 위치시켜줘야 되는데, 이는 이동행렬을 곱해주어 정확한 월드 좌표계에 놓일 수 있도록 해준다. (이동 행렬을 안곱해주면 항상 원점(0,0,0)을 중심으로 3점이 배치가 되어 있을 것이다)
추가로 Scale, Rotate의 행렬을 곱해줘, 정점의 위치를 모두 바꿔준다. 그러나 Rotate 행렬을 해줄때는 Gimble Lock이라는 현상이 발생할 수도 있으므로, 사원수를 사용하여 계산 부담도 덜고, Gimbal Lock 현상도 없애는 이득을 볼 수 있다.

월드 좌표계에 정점의 배치가 끝났으면, 이제 해야 할 것은 바로 카메라의 배치이다. 카메라의 배치 또한 모델 배치와 비슷하며, 더 해줘야 할 것은 바라볼 방향과 UpVector를 설정해 주는 것이다.

이제 카메라도 설치가 완료되었다. 그러면 해줘야 할 것이 바로 화면에 그려주는 것이다
바로 3D -> 2D로 바뀌는 작업인 것이다.
이 방법에는 2가지가 존재하는데
1. 직교투영(평행투영)
2. 원근 투영이 존재한다. 
적절히 계산.

위의 단계를 거치면 어떤 점이 화면에 보여야 되는지에 대한 설정이 끝난다.
이제 마지막으로 해줘야 할 것이 바로, 면에 대한 처리이다.

면을 처리한다는 것은 3점이 이루는 영역에 얼마만큼의 빛이 들어오는 지를 체크하는 것이라 할 수 있다.

자체 색과 빛과의 각도를 계산, 그 외에 반사정도 등등을 설정해주면, 점들이 이루는 영역에 얼만큼의 빛이 존재하는지를 알 수 있고 어떤 색을 띌 지를 알 수 있다.
따라서, 해당 점을 이은 도형의 영역 안에 존재하는 픽셀들의 색을 계산을 통해 얻은 색으로 바꿔주면 되는 것이다.

1: 좌표계 변환.... 흔히 Unity에서 heriarchy로 하기 위해 쓰는 변환이라는 것 같다.

2: Gimbal Lock 
 http://en.wikipedia.org/wiki/Gimbal_lock
행렬로 회전을 할때 생기는 현상이다. 한 축의 회전이 손실되는 현상.
이러한 현상 때문에 4원수를 쓴다.

플랫 쉐이딩 - 면의 벡터를 가지고 음영을 처리하는 방법이다.

고로 쉐이딩 - 정점의 벡터를 가지고 정점의 밝기를 계산하는 방법이다.

퐁 쉐이딩 - 픽셀의 법선벡터를 가지고 픽셀의 밝기를 계산하는 방법이다. 

텍스쳐 기반의 게임을 짜다보면 zbuffer가 가장 중요한 요소중 하나를 차지한다.
zbuffer를 사용한다고 해서 무조건 투명화가 처리되는 것은 아니다. zbuffer를 설정해준 배치 그대로 그려주는 순서또한 맞춰줘야 한다.

가령 A - zbuffer 1; B- zbuffer 0.5f C - zbuffer 0.1f 이러한 3개의 텍스쳐 A,B,C가 있다고 가정하면, 
A->B->C 순서대로 그려줘야 된다는 것이다.
A->C->B순서대로 그린다면 B와 C으 이미지가 겹치는 순간, C의 투명화된 부분에 A의 배경이 들어가게 된다....

따라서 자신이 정의한 sprite 클래스를 생성했을때, 생성과 동시에 특정 class가 managing을 해준다면, 아주 쉽게 해결되는 문제라 생각 된다.

텍스쳐 = 게임에서 사용되는 이미지 ... 글을 쓰다가 텍스쳐/이미지를 혼합해서 쓸것 같으니 햇갈리지 마요.

게임을 만들다보면(물론 내가 많이 만들지는 않았지만) 가중 중요한 것들 중에 하나가 게임에서 사용되는 텍스쳐들을 관리하는 것도 포함이 된다. 

뭐 엔진을 써서 게임을 편히 만들면 모르겠는데... 일단 DX, OPENGL과 같은 것들을 쓴다면, 유저는 이러한 텍스쳐들을 관리해줘야 된다.

텍스쳐를 관리한다는 것은, 뭐 이미지들을 폴더에 넣어서 관리한다는 의미가 아니라, 프로그래밍 할떄, 어느 텍스쳐를 메모리에 올려 둘 것인가? 등의 관리를 말하는 것이다.

간단한 게임

아주 간단한 게임을 짠다면 솔직히 위에 텍스쳐 관리에 대해 신경 쓸 필요는 없다. 그냥 모든 텍스쳐를 메모리에 올려놓고, 내가 필요한 텍스쳐와 String을 Map으로 관리하여, 필요한 것을 불러오면 될테니까.

나같은 경우는 TextureLibrary라는 static한 class를 하나 만들어서, 모든 텍스쳐를 넣어서 관리하곤 했다.

그러나 게임의 스케일이 커지다보면, 텍스쳐가 수백개, 수천개(? 오반가?) 필요할지도 모른다. 이런 경우까지 간다면 텍스쳐를 모두 메모리에 올려놓아 사용하는것은 불가능하게 된다. 
텍스쳐만 로딩하다 게임이 죽어버리게 되는 경우를 부딪히게 되겠지...

규모가 큰 게임

이를 해결하는 방법이 텍스쳐를 동적으로 메모리에 할당/해제 하는 것이다. 그럼 무엇을 기준으로 텍스쳐를 동적으로 할당/해제를 할까? 그냥 멋모르고 계속 할당/해제하면 게임이 뚝뚝 끊긴다!!!!! 텍스쳐 3개만 로딩하려해도 끊길껄?

OS에서의 프로세스 관리

OS에서 프로세스를 관리하는 것처럼 구현을 할까?
OS에서는 프로그램들을 여러가지 방법으로 관리를한다. 우선순위, 실행 빈도 등등 여러 데이터를 근거로 프로그램들을 관리하는데, 텍스처들도 간단히 말하자면 이런 방법으로 관리가 가능하다.

이미지의 구분

먼저, 텍스쳐의 용도를 크게 2가지로 나눠보자.
1. 특정 상황에서만 필요한 텍스쳐
2. 항상 필요한 텍스쳐

음... 아무래도 텍스쳐 관리 얘기다 보니까 던파를 예로 드는 것이 적절할 것 같다.
던파를 위의 2가지 기준으로 나눠 얘기해보자. (물론 내가 던파를 구현 안해서 밑은 어디까지나 그냥 분석)

1. 특정 상황에서만 필요한 이미지
-> 마을 배경, 캐릭터가 싸우는 모습의 텍스쳐들(왜냐하면 마을에서는 돌아다니기만 하니까 걷는 애니메이션만 필요하거덩).
마을배경 - 마을은 마을마다 다르다. 게임을 하면서 맵을 이동할 때마다  잠깐의 로딩시간이 존재하는 것을 볼 수 있을텐데, 이 떄 새로운 뒷 배경 텍스쳐를 로딩한다고 보면 된다.
캐릭터 텍스쳐 - 여기서 말하는 이미지들은 싸울때 사용하는 이미지들을 뜻한다. 던파가 마을에서는 안싸운다.(물론 결투 제외) 따라서, 쓸데없이 싸우는 모션들을 메모리에 할당해놔서 게임의 성능을 떨어뜨릴 필요는 없다. 

2. 항상 필요한 이미지
-> 캐릭터의 hp바, 경험치바, (esc를 눌렀을때)옵션 바 등등.
위의 것들은 모두 동감하겠찌...
esc 옵션 - 이것은 메모리에 항상 할당 해 놓는것이 좋다고 생각한다. 왜냐하면 esc를 눌렀는데 게임이 끊기면 짜증날테니까.

여튼! 위에서 언급한것들은 모두 항상 필요한 것, 혹은 사용자가 입력했을때 즉각적으로 나타나야할 것들을 언급한 것이다.

그렇다면, 맵에 랜덤으로 발생하는 이벤트와 같은 것들은 어떨까?

3. 랜덤으로 발생하는 이벤트
던파에 이런게 있는지는 모르겠지만, 뭐 배경에(게임 플레이와 아무 상관 없는) 갑자기 별들이 쏟아지는 이벤트가 발생한다고 치자. 
저 10분에 1번 일어 날까 말까한 이벤트를 위해서 80개나 되는 이미지를 메모리에 업로드 시켜놓는다면 이는 정말 막대한 낭비가 될것이다.
그렇다고 별들이 쏟아지는 이벤트가 발생했을때 바로 메모리를 업로드 할것인가?!!

틀린 얘기는 아니지만, Single Thread를 쓴다면 틀린얘기다. Single Thread로 80개의 텍스쳐를 메모리에 업로드하기 위해서는 1초의 시간이 소요될수도 있다. 그러면 플레이어는 영문도 모르고 1초동안 게임화면을 멍하니 바라봐야되잖는가...

따라서 사용해야 할것이, Multi Threading 기법이다. 실제 게임은 계속 돌아가고, 이벤트가 발생 신호-> 다른 Thread에서 이미지 업로드 -> 이미지 업로드 되면 이벤트 실행.  이러한 구조로 짜면, 플레이어는 지속적으로 게임 플레이가 가능하고, 우리는 쓸데없는 메모리 낭비를 없애는 WIN_WIN이 형성될 것이다.