Monday, December 2, 2013

Parser에서 신택스 트리를 반드시 작성해야 하는가?

Some parsers put out syntax trees as an intermediate data structure, rather than atom strings.

강제는 아님. 나는 꼭 만들어야 하는 줄 알았는데... 태균이 말이 맞았다.

Wednesday, November 13, 2013

NGUI의 UICenterOnChild 동작 원리

재밌는 방식으로 구성되어 있어 문서로 정리해 본다.

UICenterOnChild는 스크립트 콤포넌트로 추가되면 Draggable Object들을 화면 가운데로 정렬 하는데 이 정렬을 위해서 드래그가 끝났을 때 코드가 실행된다. UIDraggablePanel의 소스를 살펴 보면 UICenterOnChild와 연결된 부분은 전혀 없고

public OnDragFinished onDragFinished;

델리게이트 함수만 호출한다. 그런데 재밌는 점은 코드 어디에도 onDragFinished를 설정하는 부분이 없다는 점이다. 보통은 호출자에서 호출되는 부분의 함수를 연결하는데 NGUI는 그렇게 하지 않았다.

아무튼 onDragFinished가 연결되어 있다면 (null이 아니라면) 함수를 호출한다. 이는 다음과 같이 연결된다.

UICenterOnChild가 처음에 실행되면 OnEnable()가 호출되는데 여기서 Recenter()를 호출한다. Recenter는 OnDragFinished()가 호출될 때도 호출이 되는데 델리게이트를 연결하는 부분과 실제로 Center에 오브젝트를 정렬하는 기능 2개가 하나에 들어가 있다. (그래서 헷갈린다. 좋은 설계는 아니다.)

Recenter의 내부에 다음과 같은 코드가 있다.

---
if (mDrag == null)
{
mDrag = NGUITools.FindInParents<UIDraggablePanel>(gameObject);

if (mDrag == null)
{
Debug.LogWarning(GetType() + " requires " + typeof(UIDraggablePanel) + " on a parent object in order to work", this);
enabled = false;
return;
}
else
{
mDrag.onDragFinished = OnDragFinished;

if (mDrag.horizontalScrollBar != null)
mDrag.horizontalScrollBar.onDragFinished = OnDragFinished;

if (mDrag.verticalScrollBar != null)
mDrag.verticalScrollBar.onDragFinished = OnDragFinished;
}
}
if (mDrag.panel == null) return;

---

이 부분이 델리게이트를 연결하는 부분이ㅐ다. NGUITools의 FindINParents함수를 호출해서 현재 gameobject의 부모에 오브젝트를 가지고 온다. (그것은 UIDraggablePanel이 된다.)

그리고 mDrag의 onDragFinished에 현재 UICenterOnChild의 OnDragFinished 델리게이트를 연결한다. 이렇게 함으로써 UIDraggablePanel에서 드래그가 끝났을 때 UICenterOnChild의 OnDragFinished를 호출하고 여기서 오브젝트를 가운데로 정렬하는 로직이 실행된다.


끝.

Wednesday, October 23, 2013

프로젝트 아나키 NDK설정

프로젝트 아나키는 하복(Havok)에서 공개한 게임 엔진이며 안드로이드 예제를 실행하려는데 자꾸 NDK 설정 오류가 났다. NDK경로도 제대로 설정하고 Android SDK의 경로도 제대로 설정했는데 자꾸 오류가 나서 알아보니... x86용 NDK만 지원한단다...;

아직 64비트 버전은 돌아가지 않으므로 NDK를 다운로드 받을 때 x86용으로 받고 예제를 컴파일하면 실행 될 것이다.


Sunday, April 14, 2013

git 새로운 프로젝트 만들 때

항상 헷갈려서 메모 겸 적어 본다.

우선 디렉토리를 먼저 만든다.

mkdir testProject

그리고 testProject안에 들어가서 다음과 같이

git init으로 empty를 만든다. 그리고


cd .git

다음에

git --bare init

하자.

윈도우 환경변수 HOME등록

cygwin이 설치 되어 있고 윈도우 환경 변수에 HOME을 다음과 같이

/home/progc

하면 git사용할 때 이 폴더로 설정된다.


Tuesday, April 9, 2013

어스틴에서 개최했던 SXSW 사진들입니다.


호텔에 가면서 찍은 사진

LA공항에서 먹었던 점심... 맛은... 그냥...

월마트에 있던 SXSW광고

어메리칸 에어라인... 비행기는 대한항공/아시아나가 짱임.


게이밍 엑스포 입구


제품보다... 부스 아가씨가 이뻤던 곳

아기자기한 우리 회사 부스~

하얏트 호텔에서 아침

게임 설명 중...

인터뷰 중...

우리 회사 동영상을 10번 이상 반복으로 보던 아이들(그래서 나중에 대표님이 팔라독 인형 줬음 ㅋ)

트레이트 쇼 크기는 킨텍스 정도였다. 꽤나 컸음.

하얏트 호텔 로비에서 찍은 사진

멋졌음

어스틴 음식들이 너무 짜서 도저히 안맞았는데 초밥은 굳

마인드스톰을 사겠다는 의지가 강했으나... 실패



다리밑에 박쥐가 살아서 유명하다는 다리

깨알같은 페이즈캣 대표님




끝!

1년 정도 영어 안하다가 SXSW가서 영어 하는 바람에 처음에는 다소 버벅였지만 이내 적응해서 무사히 쇼를 끝낼 수 있었습니다. 참가 업체로서 쇼에 가는 바람에 다른 업체들이나 세션들은 제대로 보고/듣고 할 수 없었지만... 일단 그냥 무조건 열심히 했었습니다. :)

이상입니다.

Sunday, April 7, 2013

BMW 320i 에어컨 필터 교체

http://blogsuchulcar.com/140179553347


OGRE 3D 1.7 Application Development Cookbook 드디어 번역 완료했습니다!

번역하는데 너무 오래걸렸습니다. (사실 초벌은 끝내놓고 까먹고 안보내고 있었어요... ㅠㅠ)
중간에 코드 넣는 부분도 너무 오래 걸렸구요. 아무튼 드디어 끝났습니다!




오우거 사용법을 대충 알고 있고 예제별로 필요한 부분 가져다가 쓸 수 있게 되어 있는 책입니다. 초보가 볼 수 있는 책은 아니라고 생각합니다.

Thursday, April 4, 2013

이번에도 NDC13에서 강연합니다.

제목은 "아이폰 게임 <팔라독>개발에 적용한 버그 트래킹 시스템 맨티스를 적용 해보자!!" 입니다.

맨티스는 공짜로 사용할 수 있는 버그(이슈)관리 소프트웨어이며 이번 강연에서 소규모 회사에서도 곧바로 사용 가능하도록 버추얼박스로 시작해서 우분투 설치, MySQL, Apache, PHP, 맨티스 모두 설치하는 방법을 차례차례 따라만 해도 구축할 수 있도록 하고 관리자 email설정 및 실제 프로젝트에 어떻게 사용해서 버그들을 관리했는지 강연할 계획입니다.

버그 관리는 소프트웨어 개발에 있어서 상당히 중요함에도 불구하고 많은 회사들이 적용하지 않고 구두로 프로젝트를 진행하는 경우가 많은데 맨티스를 적용해보는 것을 강연을 듣고 한번 고려해보는것도 좋지 않을까 싶습니다.

북미의 큰 회사들의 경우 DevTrack이라는 프로그램을 사용하는데 프로그램 성능은 매우 좋으나 가격이 비쌉니다. 반면에 맨티스를 사용하면 공짜로 사용할 수 있고 그 성능또한 DevTrack과 크게 차이점이 없을 정도입니다.

또한 다른 버그 관리 툴은 DB를 외부로 두고 사용하는 경우도 있고 이는 보안상의 이유로 사용하기 껄끄러운 부분도 있습니다만 맨티스는 회사 내부에 설치하는 경우 보안에도 안전하다고 생각합니다.

4월 24일 오후 5:30분에 제 강연이 있으며 혹시라도 아시는 분이 오시면 인사라도 해주시면 감사하겠습니다. :]

그럼 그때 뵙겠습니다~


Tuesday, March 5, 2013

SXSW참가합니다.

페이즈켓이 이번 SXSW에 참가합니다. 저도 7일날 출국해서 14일날 돌아오구요.
혹시 가시는 한국분이 있으시면 페이즈켓에 놀러와 주세요 :)



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