리소스 관리자-좋은가요?

소스 코드에서 많은 시간을 보았습니다. [이것은 의사 C ++ 아이디어에 가깝습니다.]

typedef shared_ptr<Resource> ResourcePtr;// for ease  
ResourcePtr sound1 = resourceManager.Get<SoundResource>("boom.ogg");  
sound1->Play();  
ResourcePtr sprite = resourceManager.Get<Image>("sprite.png");

나는 이와 같은 수업이 얼마나 유용한 지 궁금했습니다.

• 로드 된 미디어 파일
• 그것들을 메모리에 저장
• 레벨 로딩 화면 시작시이 작업을 수행했습니다.
• 정리

다음과 같은 시스템을 갖추기보다는

• 자원은 엔티티에 의해서만 보유되거나 느슨합니다.
• 메모리에 대한 자체로드를 담당합니다.

첫 번째는 '관리자'입니다. 내가 느끼는 것은 사용이 잘못되었음을 나타냅니다. 그러나로드해야 할 모든 것을 찾는 데 어려움을 겪지 않고 리소스 이름 벡터와 같은 것을 전달할 수 있습니다.

훌륭한 리소스 관리자는 게임 '엔진'이 얼마나 잘, 그리고 얼마나 유연하게 될지 결정하는 열쇠입니다.

저수준 리소스 관리와 관련된 많은 문제를 해결할뿐만 아니라 리소스가 한 번만로드 된 다음 이미로드 된 경우 재사용되도록하는 데 도움이됩니다.

리소스 시스템이 잘 추상화되면 기본 세부 사항이 파일 시스템, physfs 스토리지, SQL 사이에서도 경계 할 수 있습니다.

당신은 단지 자원을 요청하고 당신에게 제공됩니다.

리소스 ID 및 이와 유사한 것에 대해 걱정할 필요가 없습니다.

중복 리소스 충돌 처리 등

자원 관리자가이를 정리하도록하십시오.

디자인 방식에 따라-C ++ 인 경우 장면 관리 클래스와 친구가되어 소유권을 올바르게 처리해야합니다.

리소스 풀?

문제 없어.

자원 공개를 잊어 버리셨습니까?

문제 없어.

메모리, 디스크, 아카이브, 네트워크 등 리소스에 상관없이 동일한 인터페이스.

문제 없어.

스트리밍 하시겠습니까?

스레딩?

자원 관리 허브가이를 처리하도록하십시오.

그리고 리소스를 사용할 준비가되면 알려줄 것입니다.

오우거 3D는 매우 유연한 자원 관리 시스템을 가지고 있지만, 다른 '외부'가 있다고 확신합니다.

나는 최근에 내 사건에 잘 맞는 자원 관리자를 썼습니다. 주요 특징:

• 리소스는 문자열 ID (예 :)로 요청됩니다 ResourceManager::instance().getTexture("textures/player.png"). 텍스처 ID는 현재 디스크의 파일에 직접 매핑되어 개발 중에 편리하지만 나중에 일부 아카이브에서 조회로 대체됩니다.

• 자원 관리자는 자원에 대한 ID 맵을 보유하므로 이미로드 된 자원을 다시로드하지 않습니다.

• 위의 호출은 Texture객체가 아니라 객체를 반환 Resource<Texture>합니다. 호출자는 Resource<Texture>실제 텍스처가 아닌 오브젝트 를 저장해야 합니다. 이것에 Resource<Texture>대한 스마트 포인터처럼 행동 Texture; 그것의 operator*()반환 Texture개체 자체. 모든 클라이언트를 업데이트 할 필요없이 실제 텍스처를 다시로드하거나 언로드 할 수 있다는 장점이 있습니다.

• 자원 관리자는 디스크의 파일이 변경되었는지 정기적으로 확인하고 필요한 경우 다시로드합니다. 이를 통해 텍스처 나 쉐이더를 수정하고 게임을 다시 시작하지 않고도 결과를 볼 수 있습니다.

• 자원은 서로 의존적 일 수 있습니다. 전부는 아니더라도 대부분의 File리소스 는 리소스 (자원이로드 된 파일) 에 의존합니다 . 예를 들어 모델이 텍스처에 의존하는 경우 디스크에서 텍스처 파일이 변경 될 때마다 모델이 다시로드됩니다.

• 자원을 찾을 수 없거나로드에 실패하면 기본 자원이 자동으로 대체됩니다. 이를 통해 게임을 중단하지 않고 아직 생성하지 않은 리소스를 사용할 수 있습니다. (계획된 기능 : 게임이 제대로 실행되지 않는 GPGPU 쉐이더와 같은 "필수"리소스를 나타냅니다.)

• 참조 카운팅 및 미사용 리소스 언로드를 쉽게 추가 할 수 있습니다. 내 게임이 매우 작기 때문에 아직이 작업이 필요하지 않았습니다.

이 기능 목록은 리소스 관리자가 훌륭 할 수 있음을 보여줍니다.

자원 관리자가있는 이유 중 하나는 자원 공유입니다. 예를 들어,을 호출 할 때 resourceManager.Get("sprite.png")"sprite.png"가 이미로드 된 경우 리소스 관리자는 새 이미지를 만들어 디스크에서 다시로드하지 않고 이미로드 된 스프라이트 리소스에 대한 포인터를 반환 할 수 있습니다.

자원 관리자는 또한 자원을 캐시 할 수 있으므로 자원에 대한 마지막 참조가 삭제되었지만 가까운 장래에 다시로드 될 경우 자원 관리자가 메모리에 유지하도록 선택할 수 있습니다. 자원 관리자는 자원으로 모든 메모리 관리를 자동으로 처리하도록 프로그래밍됩니다.

마지막으로, 매우 유용한 기능은 게임 내 리소스 리로드입니다. 리소스 관리자는 모든 게임 리소스에 대한 핸들을 보유하고 있기 때문에 모든 리소스를 디스크에서 다시로드하고 실시간으로 게임을 업데이트하는 기능을 만들 수 있습니다. 이는 게임을 작업하는 아티스트 / 디자이너에게 매우 유용합니다 .

캐싱 및 참조 카운팅 외에도 또 다른 이점은 종속성 (모델 a 텍스처 b? 나중에 얻을 것입니다!) 및로드 순서 문제 (모델 a가 쉐이더 b에 필요한 것을 알아야합니까?)를 처리 할 수 ​​있다는 것입니다. b 모델을로드하기 전에!)