신세이가
2024.10.13 22:01:17
출처:
유출파일을 뒤져보다가 갑자기 대뜸 마리오카트로 시작하는 워드 문서가 있어서 GPT와 Deepl로 번역해봤읍니다
마리오카트 DS 프로그래밍 관련 강의
일시: 2005년 6월 6일 16:00 -
장소: 기획개발부 A 회의실
참석자: 정보기획부 야마모토 님, 사토 님
기획개발부 니시다 님
게임프리크 소가베, 모리, 타마다
🌑 프레임 수 결정에 대해
"마리오카트"는 슈퍼패미컴, 게임큐브 버전 모두 1/60 프레임으로 동작했으며,
DS에서도 처음부터 1/60 프레임으로 작동하도록 설정함.
→ 팀 전원 해당 내용 숙지하고 있음.
🌑 온 메모리 상태에서의 메모리 구성
• 4MB 메인 메모리 중
o 약 1MB에서 1.5MB가 프로그램 영역으로 사용됨.
o 1MB는 사운드에 할당 (너무 많은 편으로, 700~800KB가 적절함).
"마리오 64 DS"도 약 1MB를 사용하지만 모두 사용하지 않음.
"닌텐독스"는 약 700~800KB 사용.
o 나머지 약 2MB는 그래픽과 힙(heap)으로 사용됨.
그래픽에 1MB를 할당, 일반적인 타이틀보다 적게 사용됨.
2D 데이터가 의외로 용량을 많이 차지함 (문자 데이터와 맵 데이터로 약 300KB, 나머지 700KB 정도에 3D 데이터를 담음).
게임 중 사용되는 객체 및 폴리곤 수
• 객체 수:
o 카트 (카트 본체 + 플레이어 캐릭터) × 8 = 16
o 플레이어 카트의 타이어 4개는 별도의 객체로 처리 → 4
o 아이템 (빌보드) → 10~15
o 이펙트 (빌보드) → 30~40
o 아이템 박스 → 10~15
o 지형 전체 (렌더링 처리에 약 0.1 프레임 소요)
• 폴리곤 수:
o 일반적으로 1000개 이상, 약 1300개 정도 사용되지만 최대 2048개까지 가능.
렌더링 속도 최적화에 대해
• 플레이어 카트에 집중된 애니메이션과 이펙트 사용:
플레이어가 조작하는 카트는 애니메이션과 이펙트를 풍부하게 사용하지만, 적들은 조인트가 없는 단순한 모델을 사용하며 애니메이션은 적용되지 않음. 이펙트 또한 최소한으로 억제함. 통신 시에도 자기 DS에서는 자신의 카트만 애니메이션이 적용되고, 다른 플레이어의 카트는 간소화된 그래픽으로 처리됨.
이 사항은 프로젝트 초기 단계에서 디자이너에게 전달되어, 그에 맞게 모델링 데이터가 제작됨.
• 렌더링 부하 감소를 위한 방법:
렌더링 부하를 줄이기 위해 중요한 요소는 사용되는 재질(Material)의 수를 줄이는 것임.
• 컬링(Culling):
컬링은 효율에 비해 효과가 크지 않아 많이 사용하지 않음. 지형은 그대로 렌더링하지만, 카트는 컬링 처리함.
• 1/60 프레임을 유지하는 개념:
디자이너와 기획자 모두 1/60 프레임을 유지해야 한다는 개념을 이해하고 있음. 팀 전체가 1/60 프레임을 유지하는 것이 중요한 컨셉으로 자리 잡음.
o 1/60 프레임이든 1/30 프레임이든 어느 것이든 상관없지만, 한 번 설정한 프레임 레이트를 변경하지 않고 유지하는 것이 중요함.
o 프레임 레이트가 중간에 변경되면 애니메이션 데이터의 타이밍도 다시 맞춰야 하는 등의 추가 작업이 발생할 수 있음.
NitroSDK/NitroSystem 사용 방법
• NNS_G3dDraw와 NNS_G3dDraw1Mat1Shp의 사용 구분:
모델 데이터의 구조를 보고, 자동으로 적절한 함수를 선택하여 사용함.
• SDK 레벨에서의 커스터마이징:
SDK 수준에서의 커스터마이징은 거의 하지 않음.
• NitroSystem에서 매크로 정의 변경:
매크로 정의를 변경하여 콜백을 비활성화할 수 있음. 불필요한 기능을 제거하여 약간의 속도 향상을 도모함.
• 수학 함수 최적화:
SDK 레벨에서 수학 함수를 커스텀 버전으로 변경하여 속도 향상을 시도했으나 큰 효과는 없었음. 시간을 들일 만큼 가치가 없다고 판단됨.
• ITCM에서의 최적화:
차량의 움직임 제어 루틴을 ITCM에 바로 옮김으로써 약 10%의 처리 속도 향상을 얻음. 그 외 작은 툴 루틴을 옮겨도 큰 차이는 없었음. 이는 "닌텐독스"에서도 비슷한 방식으로 처리됨.
• CodeWarrior의 IDE 환경에서 오토 인라인 기능:
코드 양은 늘어나지만, 지정된 깊이까지 함수가 자동으로 인라인 확장됨. 일련의 작업을 수행하는 코드에 적용하면 캐시 히트율이 높아져 속도 향상이 쉬워짐.
• 빌보드 표시 시스템 최적화:
NitroSystem에서 사용하는 기본 시스템은 초기 계산 등에서 불필요한 처리가 있었기에, 해당 부분을 간소화한 시스템을 개발하여 사용함. 이 부분만 깊게 손봤으며, NitroSystem 소스는 공개되어 있으나 수정 시 동작 지원은 하지 않음.
통신 부하에 대해
• 통신 부하:
전체 처리에서 통신이 차지하는 부하는 약 5~10% 정도로 평가됨.
• VRAM 사용:
VRAM 뱅크 하나(128KB)를 통신 라이브러리에 할당하여, ichneumon이라는 컴포넌트를 사용해 VRAM-D에 라이브러리를 탑재함.
→ 초기에는 8대 통신 시 3프레임 정도 소요되었으나, 이후 상당히 빠르게 최적화됨.
• 무선 통신의 신뢰성:
일반적인 무선 통신(MP)은 데이터 손실이 없다는 전제로 설계됨.
→ 무선 시스템의 재전송 처리 신뢰성을 높게 평가하며, 데이터 손실이 발생하면 에러로 처리함.
• 통신 방식:
데이터 손실이 없는 경우, 키 공유 방식으로 통신 대전을 구현함.
→ 마리오 DS와 요시 DS 등 다른 DS 타이틀에서도 이와 같은 키 공유 방식을 사용함.
• WiFi 통신:
WiFi 통신은 데이터 손실을 전제로 설계되었으며, 라이브러리 처리 부하가 커서 4인 대전이 상한선.
→ MP 통신에서는 최대 8인 대전이 가능하지만, 16인은 화면 처리 부하가 너무 커서 불가능하다고 판단됨.
• 메모리 최적화:
WiFi 통신은 메모리를 많이 필요로 하기 때문에 최적화가 필요했음. VRAM으로 전송된 후 텍스처 데이터는 메인 메모리에서 삭제되도록 하였고, 필요 없는 프로그램은 오버레이를 사용해 메모리를 절약하며 호출함.
• 화면 전환 시 초기화 처리:
화면이 어두워진 후 초기화 처리를 1프레임 이상 소요되는 경우가 있었으나, 통신이 끊어지거나 문제가 발생하는 일은 없었음.
________________________________________
처리 부하 및 메모리 사용량 모니터링
• 실시간 모니터링:
메모리 사용량 및 처리 부하는 항상 화면에 표시됨. 처리 부하는 15종류 이상의 세부 처리마다 부하가 표시됨. 메모리 사용량도 유사하게 모니터링됨.
• 데이터 기록:
처리 부하에 대한 데이터는 기획자가 매일 확인하며, 회사 내부 개발 페이지에 측정 데이터를 업로드함. 이 데이터를 통해 언제부터 부하가 증가했는지 추적할 수 있음.
• 메모리 할당 방식:
힙을 세부 용도로 나누기보다는 큰 힙에서 메모리를 할당하고, 메모리 할당 시 ID를 부여하여 용도별 힙 사용량을 측정함.
→ 레이스 종료 시 모든 메모리를 클리어할 수 있어 메모리 누수는 크게 걱정할 필요가 없음.
________________________________________
기타 최적화
• 이펙트 처리:
3D로 이펙트를 처리하면 느리기 때문에 빌보드를 사용해 처리함.
• 마이크 라이브러리:
마이크 라이브러리는 처리 부하가 크기 때문에 통신과 병행하기 어려움. 터치 패널은 기획적 판단에 따라 많이 사용하지 않았으나, 통신과 병행하여 사용할 땐 문제없음.
(샘플링 속도는 4/프레임 정도였으며, 정보 개발 부에서는 모두 이 속도로 설정함.)
• DTCM 사용:
사인·코사인 테이블을 DTCM에 올려보기도 했으나, 눈에 띄는 속도 향상은 없었음. 스택에 더 많은 메모리를 할당하는 것이 좋을 수 있음.
________________________________________
디버깅에 대해
• 통신 디버깅:
o 통신 관련 디버깅은 주로 OS_printf 등의 도구를 사용하여 처리함. MP 통신에서는 로직이 어긋나는 경우가 발생할 수 있으며, 이를 해결하기 위해 Printf의 출력 결과를 하나하나 추적하며 차이를 찾아냄.
• 디버그 버전 문제:
o 통신 디버깅은 OS_printf 등으로 열심히 하고 있었다.
MP 통신에서는 어긋나는 로직이 어쩔 수 없이 들어갈 수 있기 때문에, Printf의 표시 결과를 하나하나 추적하여 차이를 찾아내려고 노력했다.
o 디버그 버전은 처음부터 롬에 구울 수 없는 상황이었다. 마리오 카트는 릴리즈 빌드로만 개발하고 있다. 그런데도 디버깅용 코드나 데이터가 메모리에 남아있지 않았다.
• WiFi 및 일반 버전 통합:
o E3 이후 WiFi 버전과 일반 버전을 통합했는데, 롬에서 버티지 못해 디버거 상의 후반부 4M에 힙을 할당해 사용하고 있다.
이 때문에 현재는 파이널 버전 외에는 롬에 구울 수 없다.
여기서 놀라운 사실은 게임프리크는 "최적화"라는 단어의 의미를 알며 그에 맞는 노력을 했었고
지금은 쒸빨 뭘 잘못 처먹었는지 스칼렛 바이올렛이란 최악의 최적화를 보여주었다
그리고 어느 기기나 최적의 최적화를 해서 나오는 마리오카트 시리즈의 대단함을 볼 수 있는 문서
역시 기종별 판매량 1위 타이틀이야
