FF9을 설계 단계부터 재구축 하고 있는 이 시점...재 구축하면서 (쉽게 말해 다시 만든다고 -_-;) 틈틈히 작업일지도 같이 써 가고 있다.

집에 인토토토넷이 안되기 때문에, 작업일지와 작업한 것들에 대해서 일체 공개되지 않고 있다.!!

비 공개로 극비리(??)하게 제작되어지고 있는 "FF9Sc"이다.

FF9Sc는 풀네임으로 " FinalFantasy IX Scripter "를 줄인 것이다.

아주 놀라운 사실은 "설계"라는 것에 대한 힘이다.

전에 FF9Hex 를 만들때에 일본어를 읽고, 번역 하는 함수인 (가장 큰 핵심중 한개) JapLoad 함수의 수행 시간이 비교 및 검색 하는 부분만 시간을 잰 결과 25~26초 사이였다.

그렇기 때문에 대사파일을 읽고 난 뒤에 일본어 폰트표를 읽게되면 약 30초 정도의 시간이 소요되었다.

비효율적인 데이터 관리로 인해 많은 연산이 처리되고, 또 많은양의 데이터를 순차적으로 모두 엑세스 하기 때문에 반복도 수도없이 많이 하게 되었다. 1만 2만번 도는 수준이 아니라 보통

(3만 * 7)*2 정도의 숫자를 반복하게 된다. -_-;

저걸 반복하면서 + 연산만 해도 속도가 엄청날텐데, FF9Hex는 저 반복을 하면서 STL을 컨트롤 하게된다. 그러니 엄청나게 느리다.;;

현재 새롭게 구축된 FF9Sc 같은 경우 JapLoad 함수가 70% 정도 완성되었다. "번역"부분을 제외하고는 다 완성이 되어 있다. 시간을 재어본 결과 약 1초에서 2초로 10배 이상 단축된 것을 볼 수가 있었다. 역시 설계는 중요하다.

저번에 "클때" 부분까지 완성되어 있었다.

"작을때" 부분을 손대려고 했지만....로직이니 알고리즘이니 생각나는게 전혀 없고..

소스도 복잡하고 난잡하고 지저분해서 그런지 알수없고.....(.....)

하나하나 알고리즘을 집어 가고 있을 무렵.....

"어라..그냥 갔다 써도 되겠는데.."

그것이였다.. "클때" 나 "작을때"나 같은 코드를 쓰면 될것 같았다.

앞/수정할부분/뒤 이렇게 3개의 부분으로 분활한 뒤에 각각의 사이즈를 얻어 와서

새롭게 데이터를 조합하는 식의 알고리즘이여서 문자열이 크던지 작던지 모두 적용 되는 것 같았다. 내 예상은 아주 잘 맞았고, 다시 한번 "잘짰다. 후후" 라는 생각을 들게 했다. -_-

만약 분활해서 작업하지 않았더라면 나는 지금쯤 "작을때" 부분을 코딩하고 있었을 것이다. ㅡ_ㅡa;

역시 프로그램의 소스는 유연성과 범용성을 가저야 된다. 오늘은 이걸 아주 깊게 느꼈다.

다음에 내가 작업한 부분은 자잘한 부분들하고

없는 글자를 채크 하는 부분이였다.

한글 고유번호 표를 읽어와서 현재 수정한 데이터에서 표에 없는 글자가 있는지 없는지를 판별하는 코드이다.

수정해야될 데이터에는 문자와 숫자가 뒤죽박죽 섞여 있다는게 가장 큰 문제점 이였다.

"3ageer00235아3카34%아아45435"

즉 1byte와 2byte가 아주 재미있게 섞여 있다. -_-;;;;;

어떻게 걸러내야 되는지 무척 난감했고, Ps 기준으로 Byte를 새는 함수 (GetLen이라는...)를 만들다가 포기한것도 바로 이 부분 때문이였다. 그런데 오늘 그 해결책을 찾게 되었다.

아직 제대로 굴러가는지는 잘 모르겠지만...

어쨌든 되긴 된다. 그것은 0x80 (128) 에 있었다.

데브피아에서 검색하다보니까 나왔다. 한글은 Byte형으로 썼을때 0x80 이상의 숫자가 된다는 그런거였다.

처음에 거기에서 "0x80 이 꼭 들어 있다." 이런식으로 답글이 있어서 살짝 삽질을 하던 도중..

"혹시 0x80이상의 숫자가 아닐까?" 하는 의문이 딱 맞았다.

이것을 기준으로 한글과 다른 코드들을 때어 낼 수 있었다.

음 일어에 적용되는지 안되는지는 잘 모르겠지만...테스트 도중에 문제는 없었다. (일어로 테스트 한건 단 한번 -_-)

이제 데이터를 수정하는 것 까지는 거의 완벽하게 된다.

수정된 데이터를 File로 쓰기만 하면 완성된 한글대사 파일이 나오는 것이다!!!!

이건 언제 할수 있을지 몰겠네 ㅡ_ㅡa;;;

겨우겨우 CreateSHJ 함수와 Loading() 함수, 이렇게 중심이 되는 함수 2개를 완성 시켰다. (나머지는 부수적인 것들이다.)

이걸 계속 도스에서 테스트 하다가

내가 가지고 있는 소스에 적용하니까 엄청난 에러가 나는 것이 아닌가 -_-!!

그것은 읽어온 파일(SHJ파일)의 값들이 이상해저서 넘어 온다는 것이다.

고생고생 끝에 #pragma pack(1) 이것을 Shj파일헤더에 넣어주니까

잘 된다. -_-a;; 내가 자주 쓰는 전처리기 문은

#include

#define

#ifndef

#endif

요 4개 정도 이다. 그래서 다른 전처리기 문에 대해서는 잘 모른다.

#pragma pack(1) 이건 내 흐릿한 기억으로..

데이터들이 4바이트로 처리 되는걸 1바이트씩 처리 하는 걸로 바꾸는 거였던가??;;

그런거였던걸로 기억하는데...자세히는 모르겠다.

무심코 때려 넣은 코드로 인해 동작하니까 왠지 기분이 찝찝하다 =_=a;

일단 완성은 되었으니...

내일은 툴을 만들어 볼까...

ㅠ0ㅠ CreateSHJ 함수를 완성 시켰다. 어제 98% 정도 완성 시켜둔걸..

시간이 늦은 관계로 접고 잤다.

오늘 와서 1시간정도 테스트와 약간의 수정을 거친 뒤에 비로써 SHJ 파일을 생성하는데 성공~

간단한 파일 머지이지만 왠지 모르게 기분이 좋다. ^^a

앞으로 만들 게임들의 리소스 포맷으로 사용할 생각이다 ㅎㅎ

CreateSHJ() 함수는 완성시켰으니..

이제 SHJ 파일을 읽어서 다시 나누는 부분을 만들어야 된다. -_-a;;

자자 화이팅~~

완성되면 라이브러리 형태로 제공할께요~!!!

카페를 돌면서 이것저것 보고 있었다.

그렇게 보면서 돌아다니다가, 파일 머지 였던가??; 그런걸 보게 되었다.

그리고 허프만 방식의 압축 알고리즘(이건 왠만한 사람들 다 아는거죠;;)도 보고..

저번 게임을 만들때에는 bmp 포맷 그대로 사용했다.

그래서 그래픽 리소스가 그대로 노출된다는 점이 마음에 걸렸었다.

이곳저곳 돌다가 알게 된것이 파일 머지..

자기 마음대로 파일을 만드는 것이다. bmp 포맷을 예로 들면

bmp 포맷의 헤더는 2개로 나뉘어진다.

| BmpFileHeader | 와

| BmpInfoHeader | 이렇게 2가지가 있으며 헤더 다음에 데이터가 온다.

|      bmpData     | 이런 구조로 되어 있다.

|           .           | 자기 마음대로 포맷을 조정하면 된다.

물론 기존에 포맷을 일정한 공식으로 섞어서 파일머지를 시킬 수도 있을 것이다.

내가 생각한건 아래와 갔다.

1.파일 최상위에 내가 만든 헤더파일을 만든다.

2.Bmp파일이 최대 15개까지 이어서 붙일수 있도록 만든다.

가장 먼더 파일의 최상위에 헤더파일을 하나 만들어서 넣는다.

|  내가 만든 헤더  |

| BmpFileHeader1 |

| BmpInfoHeader1 |

|     bmpData1      |

|           ..            |

| BmpFileHeader2 |

| BmpInfoHeader2 |

|     bmpData2      |

|           ..           | 

             .

             .

이런식의 구조로 최대 15개의 Bmp 파일을 한개의 파일로 만드는 것이다.

헤더 정보는 공개 할수 없어욧 ~! 이 정도만 알아도 충분히 뜯어 내겠군 -_-a;;

어쨌든 어제 이것을 작업하고

거의 다 끝냈는데 시간이 모잘라서 더 이상은 못해보았다. ^^;;

오늘 학교 다녀와서 마저 작업하자~

확장자는 .shj 가 붙는다. shj는 내 이름의 이니셜일뿐 ㅡㅡa

후 어제 겨우 종료코드를 리플레쉬 하는 코드를 완성했다.

이것으로써 속도는 더욱 느려??다.

한면 적용 (◀)을 할때마다 종료코드를 다시 바꾸어주기 때문이다.

이것은 상당히 치명적일 수 있다. 꽤 높은 빈도수로 적용버튼을 누르기 때문이다.

하지만 처음부터 하드코딩 및 설계없이 진행했기 때문에

이런 일이 일어나버린 것이다. 후..

이제 실제적으로 데이터를 작성해서 적용하는 것까지는 모두 된다.

다만 아직 안된게 있다면.....PS 관점에서의 길이를 재야 한다.

그리고 기능과 기능 사이에서 여러가지 ?Z긴게 많다.

아직도 갈길이 험난하구나~

오늘은 다시 기획서 정리를 해야 하는데...

대사 스크립터기 작업을 꽤 미루고 미루다가 다시 손을 댔다.

음 1주일 정도 만에 다시 잡은 것 같다.

그 전에 어디에서 좌절을 했냐면

바로 메모리 공간과 길이 때문이였다.

한글hex(가칭) 창은 일본어 기준으로 메모리가 확보되어 있는 곳이다.

예를 들어 100 이라고 가정을 해보자.