상세 컨텐츠

본문 제목

메뉴용 폰트와 대사용 폰트를 나눌지 판단하는 기준

AI한글화 팁

by retrace 2026. 9. 30. 21:08

본문

반응형

폰트를 꼭 나눠야 하는 것은 아니다  

메뉴용 폰트와 대사용 폰트를 분리할지는 화면 이름만으로 정할 수 없다. 먼저 각 화면이 같은 폰트 로더와 문자 테이블을 쓰는지, 두 글꼴이 동시에 메모리에 올라가는지 확인한다. 한 아틀라스(atlas)에 글자가 들어 있어도 화면이 다른 문자 코드표나 별도 렌더링 경로를 쓰면 그 글자를 찾아 그리지 못할 수 있다.
글리프(glyph)는 문자 하나를 그리는 모양과 위치 정보다. 아틀라스는 여러 글리프의 픽셀을 한 이미지나 타일 영역에 모아 둔 것이다. 글리프 수와 실제 메모리 사용량은 같지 않다. 글리프 크기, 픽셀당 비트 수, 정렬, 팔레트, 압축 방식이 영향을 준다.

분리 여부를 판단하는 네 가지 확인

  1. 메뉴, 대사, 전투, 이름 입력에서 한글 한 글자와 영문·숫자가 실제로 어떤 폰트 테이블과 그리기 코드를 통과하는지 확인한다.
  2. 화면별로 필요한 고유 글리프 집합을 만든다. 공통 글리프와 특정 화면에서만 쓰는 글리프를 나누면 중복 저장량을 계산할 수 있다.
  3. 각 폰트 데이터의 크기 제한과 로드·해제 시점을 확인한다. 화면 전환 뒤 이전 폰트가 메모리에 남는지도 실제 실행에서 본다.
  4. 두 화면이 동시에 표시될 수 있는지 확인한다. 대화 중 메뉴 오버레이가 뜬다면 두 폰트의 동시 적재량이 필요하다.

메모리 계산 예시

압축 전 4bpp(픽셀당 4비트) 이미지라고 가정하면, 512×256 아틀라스는 약 64KiB, 512×512 아틀라스는 약 128KiB다. 메뉴용 64KiB와 대사용 128KiB를 분리해 둘 다 동시에 올리면 픽셀 데이터만 약 192KiB가 필요하다. 두 화면이 서로 배타적이고 이전 아틀라스를 해제한다면 순간 최대치는 약 128KiB다.
이 수치는 픽셀 배열만 계산한 예다. 팔레트, 글리프 표, 정렬 여유, 압축 해제 버퍼와 다른 런타임 할당은 포함하지 않는다. 실제 예산은 게임이 메모리를 할당하는 방식과 원본 데이터 형식으로 확인한다.

통합하거나 분리할 기준

  • 같은 로더와 문자 테이블을 쓰고, 모든 화면의 글리프가 정해진 용량에 들어가며, 필요한 동안 함께 유지해도 메모리 예산을 넘지 않으면 공유 폰트가 간단하다.
  • 화면마다 문자 코드표·글리프 크기·저장 형식이 다르거나, 화면이 서로 배타적이고 이전 아틀라스를 확실히 해제할 수 있다면 분리할 근거가 있다.
  • 두 폰트가 동시에 필요한데 둘 다 별도 고정 영역을 차지한다면, 분리는 메모리를 줄이지 않고 오히려 중복 글리프 때문에 사용량을 늘릴 수 있다.

결정 뒤에는 메인 메뉴, 긴 대사, 이름 입력, 메뉴와 대사가 겹치는 화면을 각각 실행해 한글·영문·숫자의 글리프가 모두 올바른지 확인한다. 화면 전환 뒤에만 글자가 사라지거나 다른 모양으로 바뀌면 용량보다 로더, 코드표, 폰트 포인터를 먼저 조사한다.

반응형

관련글 더보기