이번에는 대사파일 분석에 대해 다루겠습니다.
대사파일 분석에 있어서 다음의 사항들을 체크해야 합니다.
1) Shift-JIS 코드를 사용하는가?
일본게임에서는 일본어 표시를 위해서 Shift-JIS 코드를 사용합니다.
순수하게 Shift-JIS만 사용하는 경우도 있지만 일부만 Shift-JIS를 사용하는 경우가 많고, 알아보기 힘든 형태로 변형시켜 사용하는 경우도 있습니다.
순수한 Shift-JIS만 사용하는 경우는 대부분 포인터를 사용하고 있고, 오히려 Shift-JIS처럼 보이지 않는 경우가 포인터를 사용하지 않을 가능성이 높습니다.
일부만 Shift-JIS를 사용하는 경우는 자주 쓰이는 문자를 1바이트 코드로 대체시켜 사용하는 경우가 많습니다.
이 1바이트 코드는 1바이트 카타카나 영역을 사용하는 경우가 많고 보통 제어코드 영역을 피해서 사용되고 있습니다.
2) 텍스트 파일인가?
여기서 말하는 텍스트 파일이란 일반 문서 편집기로 편집해도 문제가 생기지 않는 경우를 말합니다.
이 경우는 대부분 포인터를 사용하지 않으며 제어코드도 사용되지 않거나 인간이 이해할 수 있는 영단어로 되어있는 경우가 많습니다.
대부분의 경우 수정하기 용이하지만 대사창에 한번에 표시 가능한 문자의 숫가 적을 경우는 줄을 나누거나 해야 하는데 그 작업이 용이하지 않아서 한글화에 어려움을 겪을 수도 있습니다.
3) 포인터가 사용되는가?
대사의 시작 위치나 특정 위치로의 분기를 위해 포인터가 사용되는 경우가 있습니다.
포인터는 보통 대사파일의 맨 앞이나 맨 끝에 위치하는 경우가 많지만, 대사파일 중간 중간에 제어코드 형태로 특정 주소로 분기하는 형태로 존재할 수도 있습니다.
포인터는 대사파일 시작위치를 0으로 하는 경우가 있을 수 있고 헤더를 제외한 실제 대사영역을 0으로 하는 경우가 존재할 수 있습니다.
대사 위치를 가리키는 포인터도 있지만 특정 대사블록으로의 분기를 위한 주소를 가질 수도 있습니다.
4) 압축이나 암호화가 되어있는가?
아카이브 파일 중에는 암호화가 되어있는 경우가 있습니다.
암호화를 위해서 비트연산(Shift, Rotate, Xor 등...)이 사용되는 경우가 많습니다.
대사파일에서는 Shift-JIS를 특정한 계산식으로 변형시킨 경우가 존재할 수 있습니다.
압축이 쓰일 수도 있는데 LZ 형식이나 RLE 형식의 압축이 흔히 쓰입니다.
5) 반각문자를 지원하는가?
일본 게임 상당수는 반각문자를 지원하지 않습니다.
왜냐하면 반각문자 영역을 제어코드로 사용하는 경우가 적지 않기 때문입니다.
그러나 일부 경우에서 자유롭게, 또는 제한적으로 반각문자를 사용할 수 있는 것들이 존재합니다.
6) 대사파일 크기에 제한은 없는가?
옛날 컴퓨터들은 사용 가능한 메모리가 넉넉치 않아서 대사파일이 일정 크기를 넘으면 오류가 나는 경우가 있습니다.
파일 하나당 크기 제한이 있을 수도 있지만 두개 파일을 동시에 로드하는 경우는 두개 파일을 합친 크기가 제한 크기를 넘을 경우 에러가 발생할 수도 있습니다.
이 메모리 크게 제한 때문에 파일을 수십, 수백개로 나누거나 많이 쓰이는 글자를 1바이트 코드로 대체하거나 하는 게임들이 많이 존재합니다.
물론, 윈도우의 경우는 메모리 제약을 받지 않으므로 관계 없는 사항입니다만...
(피아캐롯1 같은 경우도 pc98용 버젼은 대사파일 크기에 제약이 있었지만 윈도우용은 그딴거 없었습니다.)
7) 아카이브 형태로 되어있는가?
아카이브(=여러 파일들을 하나로 묶어놓은 형태) 형태인 경우가 있습니다.
모든 파일들을 아카이브로 묶어놓은 경우도 있지만 텍스트 파일만 따로 모아서 묶어놓은 형태도 존재합니다.
이 경우는 아카이브 안에 각 텍스트 블록에 대한 포인터가 존재하고 개별 블록별로 대사 포인터가 존재할 수 있으므로 대사 포인터가 상대주소가 될 가능성이 높습니다.
잘 알려진 아카이브 형식은 Grapholic이나 Susie 같은 프로그램으로 해제가 가능하며, 아카이브를 해제한 형태로 실행 가능한 경우도 적지 않습니다.(ELF사를 비롯한 몇몇 회사 게임들이 아카이브를 해제한 형태의 실행방식을 지원합니다.)
8) 대사길이 변경이 용이한가?
텍스트 파일 형태의 경우 대부분 용이한 편이고 텍스트 파일 형태가 아니더라도 포인터가 사용되지 않는 경우는 대사 길이 변경이 용이한 편이지만 그런 경우가 많지는 않습니다.
포인터가 사용되는 경우나 특정 주소로 분기하는 제어코드가 쓰이는 경우는 대사길이 변경이 쉽지 않습니다.
이상으로 알아보았는데 대사파일 분석을 위해서는 텍스트 에디터보다는 헥사 에디터를 주로 사용하게 됩니다.
왜냐하면 대부분의 대사 파일은 텍스트 파일 형태가 아니므로 대사파일 구조를 분석하려면 헥사 에디터로 대사와 제어코드를 분리하고 포인터 구조를 분석하는 과정을 거쳐야 하기 때문입니다.
특히, 위에서 언급한 특정 주소로 분기하는 제어코드 형태의 경우는 많은 시행착오를 통해서 패턴을 분석할 필요가 있습니다.
(실행파일을 역어셈블 해서 대사 처리 과정을 분석하는 것이 좋겠지만 그것도 녹록한 작업은 아니니...)
또한, 프로텍트가 걸려서 disk explorer 같은 프로그램으로 디스크 이미지 파일을 열 수 없는 경우가 있습니다.
이 경우는 파일 단위로 작업하기 곤란하므로 작업 난이도가 더 올라간다고 할 수 있습니다.
이상으로 마치겠고...
다음번에는 대사파일 분석과정의 실제 예를 들어서 설명하도록 하겠습니다.
'한글화 강좌' 카테고리의 다른 글
#05 자주 쓰이는 도스 명령어 일람 (0) | 2012.10.04 |
---|---|
#04 대사파일 분석 예제 (0) | 2012.09.26 |
#02 한글화를 위한 준비와 과정... (0) | 2012.09.11 |
#01 HDI 파일을 생성해보자. (2) | 2012.09.10 |