Wednesday, February 20, 2013

Java에서 function pointer, member function pointer, callback와 같은것 구현하기

보통 UI시스템을 만들 때 주로 사용하는 것이 콜백 함수입니다. 예를 들어서 버튼을 하나 만들고 이 버튼이 클릭 되었을 때 처리하는 바인딩 코드를 내가 원하는 어떠한 함수를 호출하게 하기 위해서 콜백을 사용하지요.

제가 DeadEngine을 만들 때는 멤버 함수 포인터를 이용해서 이를 구현했습니다. 그리고 최근에 안드로이드 작업하면서 자바를 사용하게 되었는데 (자바는 아주 옛날에 써보고 최근에는 거의 안써본...) 자바에는 함수 포인터를 사용할 수가 없습니다. 하지만 Inner class를 이용해서 이것이 구현 가능 합니다. 이 글을 참고하면 됩니다.

http://www.devx.com/tips/Tip/5849

// 사라질까봐 내용 복사. (원문에 대한 저작권은 Ajit Sagar가 가집니다.)


Java's Alternative to Function Pointers

Although Java borrows a lot of concepts and syntax from C++, it also leaves out some of C++'s main features to meet its goal of simplicity. For example, Java excluded memory pointers and function pointers from its arsenal. Function pointers allow flexibility in method invocation at run time. A pointer to the function that needs to be called can be passed in as an argument to the calling function. A method can "call back" another method that is specified as one of its arguments.The inner class construct in JDK 1.1 provides a novel approach to achieve the same goal that function pointers achieve in C++. Anonymous classes in method invocations allow a dynamically defined class to be passed in as a parameter. As a result, the calling class can invoke a method on this class. For example:
 
1.     interface CallbackIfc {
2.       public void callMe();
3.     }
4. 
5.     // This class calls a method on class B.
6.     public class CallbackTester {
7.       CallerClass cc = new CallerClass();
8. 
9.       public void sendCallback() {
10.         cc.callback (new CallbackIfc() {     
11.                        public void callMe() {
12.                          // Implementation code here
13.                        }
14.                      }
15.                    );
16.         }
17.     }
18. 
19. // This class calls back a method on class CallbackIfc.
20. class CallerClass {
21.   public void callback (CallbackIfc c) {
22.     c.callMe();
23.   }
24. }
Lines 1-3 define a new interface called CallbackIfc to be used as a callback class. CallbackIfc defines a single method (callMe()). Lines 20-24 define a class called CallerClass that will exercise the callback. CallerClass has a single method (callback()) that calls a method (callMe()) on an object of the class CallbackIfc. This object is passed in as an argument. Lines 5-17 define the class that invokes callback() on the class CallerClass. It defines a single method (sendCallback()) that calls the method callback() on an object of the class CallerClass. Note that it defines an instance of the interface CallbackIfc within the parentheses. This defines an anonymous class that implements the interface CallbackIfc.


Saturday, February 16, 2013

슈팅 게임 알고리즘 매니악스 -총알 생성, 소멸-

총알을 관리하기 위해서 배열이나 리스트를 사용하는데 이 책에서는 MoveGroup이라는 클래스를 이용해서 총알(및 모든 것)을 관리한다.

화면에 나타나는 모든 객체는 Mover클래스가 담당하고 있으며 Mover는 Spawn배열을 가진다.

Spawn의 구조는 다음과 같다.

int NumSpawns;
typedef struct {
CMover* Model;
float RX, RY;
int Timer, Cycle, Count;
int NWayCount;
float NWayAngle;
int CircleCount;
bool CircleOdd;
} SPAWN;

Model은 보통 총알의 모양을 가지고 있는 포인터다.

업데이트가 될 때 마다 Spawn목록을 방문하면서 실제로 총알 오브젝트를 생성한다.


for (int i=0; i<NumSpawns; i++) {
SPAWN* spawn=&Spawns[i];
assert(spawn->Timer>=0);
if (spawn->Count!=0) {
if (spawn->Timer==0) {
if (spawn->Count>0) spawn->Count--;
spawn->Timer=spawn->Cycle;
if (spawn->NWayCount>0) SpawnNWay(spawn); else
if (spawn->CircleCount>0) SpawnCircle(spawn); else
{
CMover* mover=New(spawn->Model);
if (mover) {
mover->RX=spawn->RX;
mover->RY=spawn->RY;
}
}
} else {
spawn->Timer--;
}
}
}

눈여겨 볼만한 것은 빨간색으로 처리한 부분이다.

CMover* mover=New(spawn->Model);

새로운 오브젝트를 생성해서 배열이나 리스트에 넣는 부분이 감추어져 있다. 이 부분은 모두 New함수 내부에서 결정된다.


CMover* CMover::New(CMover* model) {
if (!model) return NULL;
CMover* mover=model->Group->New();
if (mover) mover->Init(model, this);
return mover;
}

파라메터로 넘겨진 model의 그룹은 Bullet Group으로 등록되어 있고 이 Bullet Group에서 모든 총알을 관리한다. (총알의 생성과 소멸, 업데이트, 렌더링 모두 관리)
생성 부분은 Group의 New에 있고 내부를 살펴 보면


CMover* CMoverGroup::New() {
if (NumFreeMovers==0) return NULL;
--NumFreeMovers;
CMover* mover=FreeMovers[NumFreeMovers];
mover->Used=true;
return mover;
}


오브젝트를 생성하는데 단순히 FreeMovers리스트에서 현재 설정되어 있는 NumFreeMovers의 인덱스로 오브젝트를 가져올 수 있다. 객체가 사용되고 있다는걸 설정하기 위해서 Used를 true로 설정한다.

이제 Free하는 부분을 살펴 보자.


void CMoverGroup::Delete(CMover* mover) {
assert(NumFreeMovers<NumAllMovers);
FreeMovers[NumFreeMovers++]=mover;
mover->Used=false;
}

현재 삭제될 객체가 mover이고 이것을 단순히 FreeMovers에 넣는다. 그리고 used값을 false로 설정한다. 언뜻보면 이해가 잘 안되는데 예를 들어서 이해해보자.

가령 MoveGroup하나에 오브젝트 a,b,c를 추가하자. 그리고 이것들의 메모리 어드레스는 다음과 같다.

1번째 슬롯 aObject : 0x67D7FD0
2번째 슬롯 bObject : 0x67D8C78
3번째 슬롯 cObject : 0x67D9920

그리고 차례대로 New를 호출할 때 마다 끝 부분에서 하나씩 오브젝트를 가져온다. (앞서 살펴본 소스에 의하면) 그러므로 처음 New를 호출해서 얻는 오브젝트는 cObject이다. 그리고 2번째 New를 호출하면 bObject를 얻는다.

이제 소멸을 하는데 bObject를 소멸하는것은 이해가 되지만 cObject를 소멸 가능해야 한다. 그렇게 되면 FreeMovers에는 bObject의 어드레스 0x67D8C78이 사라지게 된다.
(왜냐하면 소멸 소스에는 해당 인덱스에 Mover객체를 그냥 할당하므로)

결국 FreeMovers에는


1번째 슬롯 : 0x67D7FD0
2번째 슬롯 : 0x67D9920
3번째 슬롯 : 0x67D9920

2번째 슬롯에 cObject가 할당되게 된다. 물론 cObject의 used값은 false로 설정되지만 말이다. 이제 bObject를 삭제 해보자. 현 시점에서 남은 마지막으로 사용하고 있는 인덱스는 3번째 슬롯이기 때문에 3번째 슬롯에 bObject를 넣고 used를 false로 설정한다. 초기에 있던



1번째 슬롯 aObject : 0x67D7FD0
2번째 슬롯 bObject : 0x67D8C78
3번째 슬롯 cObject : 0x67D9920


을 비교하면 마지막에는 다음과 같이


1번째 슬롯 aObject : 0x67D7FD0
2번째 슬롯 cObject : 0x67D9920
3번째 슬롯 bObject : 0x67D8C78

2, 3번째 슬롯에 b, c object가 바뀌어 있다. 바뀌어 있어도 상관이 없다. 왜냐하면 객체를 업데이트 하거나 렌더링 하기 위해서는 FreeMovers를 사용하는 것이 아니라 UsedMovers를 사용하기 때문이다. 이 UsedMovers들은 다음과 같이 얻는다.


NumUsedMovers=0;
for (i=0; i<NumAllMovers; i++) {
CMover* mover=AllMovers[i];
if (mover->Used) UsedMovers[NumUsedMovers++]=mover;
}

결국 현재 사용하고 있는 오브젝트들의 총 리스트를 얻기 위해서는 NumAllMovers만큼 루프를 돌고 Used가 셋팅되어 있는지의 여부에 따라 UsedMovers에 넣어서 관리한다.
FreeMovers의 장점은 New, Delete할 때 O(1)이라는 점이다. 하지만 현재 사용하고 있는 오브젝트를 얻기 위해서는 루프를 모두 돌면서 셋팅해줘야 하기 때문에 O(N)성능을 얻는다.









Monday, February 4, 2013

Inner class를 이용해 Attribute와 변수를 구분하기

게임에서 사용되는 유닛이나 무기 정보들은 보통 DB에 저장하고 게임에서는 이를 참고해서 로직을 작성하게 됩니다. 이때 클래스 내부에 DB정보를 저장하고 이를 로직에서 사용할 때 private로 변수를 선언하게 되더라도 이를 로직에서 사용할 때 변경이 되어도 되는 변수인지 아닌지 헷갈릴 때가 많은데요.

가령 mFireRate와 같은 변수가 DB에서 얻은 값이고 이 값을 이용해서 다음과 같은 로직이 있다고 칩니다.

mCount++;

if ( mCount >= mFireRate )
{
then fire it.
}

문제는 mFireRate가 DB변수값인지 아닌지 변수명 자체로는 구분하기가 힘들다는 점입니다. 이것을 해결하기 위해서 mFireRateDB와 같이 변수명에 구분을 하기 위한 접두어나 접미사를 써주는 경우가 있는데 이것 역시 마음에 드는 방식은 아닙니다. 해서... 저는 보통 Inner struct, class를 사용해서 다음과 같이 사용합니다.

class Attribute
{
    int mFireRate;
} mAttrib;

이렇게 하면 앞서 살펴본 코드가 다음과 같이

mCount++;

if ( mCount >= mAttrib.mFireRate )
{
then fire it
}

구분할 수 있게 됩니다. 그렇게 되면 저는 mCount보다는 다음과 같이 변수명을 바꿀 것입니다.


mFireRate++;

if ( mFireRate >= mAttrib.mFireRate )
{
fire it
}

Attribute안에 들어간 값은 읽기 전용이라고 생각하면 코드를 볼 때 더 이해하기가 쉽습니다. 물론 메소드로 표현하면 더 괜찮겠지만 코드 작성하는게 좀 귀찮긴 하지요 :)


mFireRate++;

if ( mFireRate >= mAttrib.GetFireRate() )
{
fire it
}


Task in UnrealEngine

 https://www.youtube.com/watch?v=1lBadANnJaw