게임오븐을 보고... 며칠간 잠을 설쳤다. "디버깅이 되는구나... 디버깅이 되는구나... 디버깅이 되는구나... "
도대체 어떤 멋진 PM이 이런 계획을 세우고 또 어떤 멋진 프로그래머가 그 계획을 구체화 시켰을까...
진짜 부럽고 부럽고 부러웠다.

나도 저런 것 만들어보고 싶어~~ 라는 기분도 참 오래간만에 느껴보았다.
디버거만 있다면 우리 회사 기획자들을 내가 만든 루아지옥에서 건져올려 좀 더 가정에 충실하게 만들 수 있을텐데...

우리 게임의 경우 서버와 클라이언트의 글루함수 및 호출규약이 많이 다르다. 따라서 게임오븐처럼 통일된 IDE에서 클라이언트, 또는 서버를 구동시키는 것은 그다지 효율적이지 않다. 뭐 조금 바뀔 때 마다 툴도 손대야 하는 상황은 이제 정말 싫어... 한 번 만들어놓고 멀건 국물 나올 때 까지 울궈먹는 게 무엇보다 쵝오.

때문에 디버거를 루아 모듈로 만들어 기존 환경에서 구동시키는 쪽으로 살짝 생각을 바꿔보았다. 그래서 탄생한 물건이 바로 이 놈!!

dbgtest.zip

단독실행이 아닌 모듈이기 때문에 기존 루아환경에서 불러들여야 한다. 뭐 멀리서 찾을 것 없이 lua.org 에서 배포하는 윈32용 루아 바이너리를 내려받자.

선공, 또는 먹자 몬스터가 시야 내의 유저나 아이템을 발견할 때 사용한 방법.
2004. 6. 8. 작업노트로 부터 정리 해 둠.



오브젝트가 향하는 방향값은 다음과 같이 정의되어있다.

4	0	5
3	C	1
7	2	6

첫번째 테이블, 즉 거리가 1일 때의 갯수는 8개이며 거리에 비례해 8의 배수로 늘어난다.

1st Table
0, 4, 5, 3, 1, 7, 6, 2
1, 5, 6, 0, 2, 4, 7, 3
2, 6, 7, 1, 3, 5, 4, 0
3, 7, 4, 2, 0, 6, 5, 1
4, 3, 0, 7, 5, 2, 1, 6
5, 0, 1, 4, 6, 3, 2, 7
6, 1, 2, 5, 7, 0, 3, 4
7, 2, 3, 6, 4, 1, 0, 5

2nd Table
0-0, 4-0, 5-0, 4-4, 5-5, 4-3, 5-1, 3-3, 1-1, 7-3, 6-1, 7-7, 6-6, 7-2, 6-2, 2-2
0-0의 의미는 0번 방향에서 다시 0번방향이라는 의미...

이 관계를 테이블로 정리 해 보면 다음과 같다.

	4,4,4,4	4,4,4,0	4,4,0,0	4,0,0,0	0,0,0,0	5,0,0,0	5,5,0,0	5,5,5,0	5,5,5,5
	(-4,-4)	(-3,-4)	(-2,-4)	(-1,-4)	(0,-4)	(1,-4)	(2,-4)	(3,-4)	(4,-4)
	4,4,4,3	4,4,4	4,4,0	4,0,0	0,0,0	5,0,0	5,5,0	5,5,5	5,5,5,1
	(-4,-3)	(-3,-3)	(-2,-3)	(-1,-3)	(0,-3)	(1,-3)	(2,-3)	(3,-3)	(4,-3)
	4,4,3,3	4,4,3	4,4	4,0	0,0	5,0	5,5	5,5,1	5,5,1,1
	(-4,-2)	(-3,-2)	(-2,-2)	(-1,-2)	(0,-2)	(1,-2)	(2,-2)	(3,-2)	(4,-2)
	4,3,3,3	4,3,3	4,3	4	0	5	5,1	5,1,1	5,1,1,1
	(-4,-1)	(-3,-1)	(-2,-1)	(-1,-1)	(0,-1)	(1,-1)	(2,-1)	(3,-1)	(4,-1)
	3,3,3,3	3,3,3	3,3	3	C	1	1,1	1,1,1	1,1,1,1
	(-4,0)	(-3,0)	(-2,0)	(-1,0)	(0,0)	(1,0)	(2,0)	(3,0)	(4,0)
	7,3,3,3	7,3,3	7,3	7	2	6	6,1	6,1,1	6,1,1,1
	(-4,1)	(-3,1)	(-2,1)	(-1,1)	(0,1)	(1,1)	(2,1)	(3,1)	(4,1)
	7,7,3,3	7,7,3	7,7	7,2	2,2	6,2	6,6	6,6,1	6,6,1,1
	(-4,2)	(-3,2)	(-2,2)	(-1,2)	(0,2)	(1,2)	(2,2)	(3,2)	(4,2)
	7,7,7,3	7,7,7	7,7,2	7,2,2	2,2,2	6,2,2	6,6,2	6,6,6	6,6,6,1
	(-4,3)	(-3,3)	(-2,3)	(-1,3)	(0,3)	(1,3)	(2,3)	(3,3)	(4,3)
	7,7,7,7	7,7,7,2	7,7,2,2	7,2,2,2	2,2,2,2	6,2,2,2	6,6,2,2	6,6,6,2	6,6,6,6
	(-4,4)	(-3,4)	(-2,4)	(-1,4)	(0,4)	(1,4)	(2,4)	(3,4)	(4,4)

정리결과 재미난 규칙을 발견함.. 기준좌표를 중심으로 6-2-2-2 위치의 좌표는 6방향 옵셋값인 (1,1)과 2방향 옵셋값인 (0,1)을 그 반복횟수만큼 옵셋시킨 값이 된다. (1,1) + (0,1) + (0,1) + (0,1) = (1,4).

각 방향의 '어깨걸이' 방향을 좌우 순서로 정리하면 다음과 같다.

0 - 4, 5
1 - 5, 6
2 - 6, 7
3 - 7, 4
4 - 3, 0
5 - 0, 1
6 - 1, 2
7 - 2, 3

단계 1의 방향을 추출해 보자.

1의 왼쪽 오른쪽인 5, 6까지 추출... 5번의 왼쪽 0, 6번의 오른쪽 2,
다시 0번의 왼쪽 4, 2번의 오른쪽 7. 마지막으로 4의 왼쪽 3 또는 7의 오른쪽 3.

1, 5, 6, 0, 2, 4, 7, 3

어깨걸이 좌표 테이블로부터 추출이 가능하다는 얘기가 됨.

기준좌표로부터 거리 3인 위치를 6번방향 기준으로 추출할 경우...
먼저 3개의 인자를 갖는 바이트배열 두 개를 준비한다. 각각 오른쪽, 왼쪽값이 된다.
DirArr_R, DirArr_L : TByteArray;

초기값은 두 방향 모두 6-6-6 으로 채운다. DirArr_R[0], [1], [2] := 6;
이 인자들의 값을 해당 루프만큼 바꿔가며 방향을 추출할 수 있다.
총 루프 횟수는 거리값인 3 * 8 / 2 -1 = 11 번이 된다.
(하나의 방향이 모두 치환되는 횟수는 거리값, 즉 이경우 3번이 된다.)

시작방향이 0~3이면 앞부분을 치환, 4~7이면 뒷부분을 치환한다.

RepPos: Integer;

오른쪽을 기준으로 설명 해 보자. 시작방향, 즉 DirArr_R[0] 값이 6이므로 뒷부분 치환.

RefPos:= 0;
RepPos:= 거리 -1;
IncVal := -1; // RepPos를 줄이는 참조값.

또한 6의 오른쪽 방향은 ND2CD_TBL[6][7] => 2 이므로 루프 첫번째 값은 [6-6-2] 이다.
DirArr_R[RepPos] := ND2CD_TBL[ DirArr_R[RefPos] ][7];

RepPos는 하나 줄인다.
Inc(RepPos, IncVal);

RepPos가 0보다 작아지면 RepPos를 0으로, RefPos를 거리-1로, IncVal을 1로 수정.
RepPos가 거리보다 크거나 같아지면 RepPos를 거리-1로 RefPos를 0으로, IncVal을 -1로 수정.

이 과정을 총 루프횟수만큼 반복한 후 마지막 방향은 처음방향의 역방향으로 결정.
또는 왼쪽, 오른쪽 아무쪽이나 이 과정을 한 번 더 진행시켜 결정.

얻어낸 좌표옵셋의 거리제곱이 주어진 (거리+1)의 제곱보다 작은 경우만 범위로 인정.
이렇게 추출한 점열들은 결국 원형이 된다. 이 때 원형 내부에 꽉 차는 축직교 정사각형의 범위는 굳이 거리를 재지  않아도 원 내부이며 따라서 단순 비교문만으로 처리할 수 있다. 주어진 거리에 cos(45) 값을 곱한 후 반올림하면 사각영역의 경계값을 얻게 되며 이 경계안에 포함되는 영역은 거리비교를 하지 않도록 하자.
이 경계값은 스텝에 바로 대응된다. n번째 스탭에서 (n <= 경계값)의 조건을 만족 한다면 거리값을 잴 필요없이 원형 범위 이내가 된다는 이야기..

추출좌표의 총 갯수는 ((추출하려는 거리 * 2) -1)^2 -1 이 된다. 여기서 -1은 원점을 뺐기 때문이다.

지금까지의 정리를 코딩을 통해 확인. (델파이 5)

흰색 점 : 거리를 벗어난 셸
검은 점 : 거리 이내로 판단된 셸
회색 점 : 사각영역이므로 거리판단을 생략하고 무조건 추출한 셸

LNUM 패치가 적용된 루아 5.1.4 의 arm-wince 용 바이너리 이다.
컴파일러는 CeGCC 의 arm-mingw32ce 를 사용했다.

루아의 표준 라이브러리 중 io, os, loadlib 세 가지는 빼 버렸다.
따라서 io.open(), os.date(), package.loadlib() 등의 함수는 사용할 수 없다.
wince의 C런타임에 tmpfile() 같은 표준 C함수가 없기 때문에 이리저리 고민하다가
일단은 제거 빼 버렸는데, 사실 루아를 쓸 때 표준 라이브러리 의존도는 상대적으로
떨어지고 필요하면 글루함수로 만들어 추가하는 편이 나을 것이다.

(솔직히 루아는 테이블만 있으면~~~)


이제 이 라이브러리를 라자루스에 붙여볼까나~~~

 

2009.3.20
 
실수값에 float, 정수값에 int32 를 사용하는 버전.
luac.exe 를 사용해 컴파일한 바이트코드는 서로 다른 설정을 가진 루아 모듈 사이에서 호환되지 않는다.
따라서 동일한 설정으로 컴파일된 윈도32용 바이너리도 함께 넣어 두었다.

arm-wince 에는 표준 라이브러리 중 base, table, string, debug 만 포함되었다.
가급적 math는 집어넣으려 했지만, float모드로 사용할 때 발생한 atanhf 의 링크에러를
풀지 못했다. 따라서 필요하다면 글루함수로 만들어 제공해야 한다.

라자루스를 어디에 쓸까 고민하다가... 음력에 대한 공부도 할 겸 "달 구경" 프로그램을 짬짬이 만들고 있다.
날짜 선택을 위해 달력 컨트롤을 올려놓으려고 했더니... 응? 델파이의 TDateTimePicker에 해당하는 TKOLDateTimePicker 는 있는데 TMonthCalendar에 해당하는 컨트롤이 없다. 허걱~~ fpc의 wince 유니트를 열어보니 DateTimePicker와 MonthCal에 사용되는 ICC_DATE_CLASSES 가 주석으로 막혀있네~ (라자루스 0.9.24 의 LCL 윈CE 인터페이스는 현재 베타버전이다.)

그렇다면 KOL의 TKOLDateTimePicker 는 뭘까 싶어 다시 KOL.pas 를 뒤져보니... 여기에 다시 재정의 되어있었다. 그러나 애석하게도 달력 컨트롤에 대한 코드는 찾아볼 수 없었다.

처음에는 간단히 LCL로 DLL을 만들어 쓰려고 했었는데... 위에서 언급했듯이 아직 윈CE 인터페이스가 베타라 arm-wince 로 달력 컨트롤을 컴파일하면 에러가 발생한다. 뭐 여차저차해서 만들기로 했고, 아직 내공부족으로 KOL 컴포넌트화 할 수는 없었지만 그럭저럭 쓸만하기에 방법을 정리 해 본다.

달력 컨트롤에 관련된 상수들은 evc와 함께 설치한 STANDARDSDK 5.0 에 정의되어 있으며 "C:\Program Files\Windows CE Tools\wce500\STANDARDSDK_500\Include\...\commctrl.h" 에서 찾을 수 있다. 이 파일을 번역하려고 슬쩍 훑어보니 다행히 상수 및 구조체가 윈도 32와 99% 동일하다. 그렇다면?? 델파이의 VCL을 가져와 쓰자.


VCL은 오픈소스가 아니므로 여기에 옮길 수 없다. 델파이 5.0을 기준으로 과정만 소개 해 본다.


1. 먼저 라자루스의 File->NewUnit 를 선택, 새로 만들 달력 컨트롤이 담길 유니트를 만들어 준다. 이름은 적당히.

2. uses 섹션에는 Windows, Messages, KOL, CommCtrl 유니트를 적어넣는다.

3. ...\Delphi5\source\rtl\win\commctrl.pas 파일을 열고 다음 내용들을 복사 해 온다.