기본 XNA 엔진을 최적화하고 싶습니다. 이 구조는 다소 비슷합니다. GameWorld 인스턴스와 더 많은 GameObject가 추가되었습니다. 이제는 모든 프레임에서 GameObjects 사이에 루프를 만들고 그 안에 draw 메서드를 호출합니다. 이 구현의 단점은 GameDevice 그리기 기능이 여러 번 호출된다는 것입니다.
이제 드로잉 호출을 줄이고 드로잉 메서드를 호출하기 전에 큰 벡터의 모든 지오메트리를 전송하여 모든 정점 데이터를 만들고 모든 드로잉 호출을 수행하여 모든 드로잉을 생성하는 구조를 구현하고자합니다.
효율적인 방법입니까? 누군가 나에게 최적화 할 솔루션을 말할 수 있습니까?
감사
기본 XNA 엔진에서 드로잉 호출 최적화
첫 번째 단계는 그리는 개체의 수를 줄이는 것입니다. , 가장 일반적으로이 작업을 수행하는 방법에는 여러 가지가 있습니다
프러스 텀 컬링 - 즉, 뷰 프러스 텀 이외의 모든 개체를 추려가
장면 쿼리 - 예를 들어, BSP 트리 또는 QuadTree를 사용하여 장면 구성 - 잠재적으로 보이는 객체 세트를 줄일 수있는 일부 데이터 구조
오 클루 젼 컬링 - 더 고급 주제이지만 경우에 따라 객체가 보이지 않는다고 판단 할 수 있습니다. 왜냐하면 다른 기하학에 의해 폐색되기 때문입니다.
이 모든 것을 다루는 웹에 많은 튜토리얼이 있습니다. 나는 위의 순서대로 그들을 공격 할 것이고 아마도 지금은 폐색을 무시할 것입니다. 모든 그래픽 엔진에서 가장 중요한 최적화는 드로잉 할 수있는 가장 빠른 프리미티브가 그릴 필요가 없다는 것입니다.
잠재적으로 보이는 개체 집합을 모두 GPU로 개별적으로 보내는 것이 좋지만 GPU의 상태 변화를 최소화하는 방법으로 작업해야합니다. 동일한 텍스처/재질 속성을 함께 사용하는 모든 오브젝트를 그룹화합니다.
일단 완료되면 모든 것이 꽤 빠름을 발견해야합니다. 당연히 당신은 항상 그것을 더 취할 수 있지만 위의 단계들은 아마도 시작하는 가장 좋은 방법 일 것입니다.
포인트를 분명히하기 위해서 - 더 적은 그리기 호출 = 더 빠르다고 가정하지 마십시오. 물론 하드웨어를 비롯한 여러 요소에 따라 다르지만 일반적으로 XNA/DirectX API는 파이프 라인을 통해 지오메트리를 대기열에 넣는 데 매우 효과적입니다. 이것이 결국 필요한 것입니다. 핵심은 호출을 최소화하는 것이 아니라 현장에서 필요한 상태 변화 (텍스처/쉐이더 등)를 최소화하는 것입니다.
아주 명확한 응답, 천 감사합니다! :) – Archedius
실제로 "그리기 프리미티브"기능 호출 수는 GPU로 전송 된 배치 수에 직접적으로 매핑됩니다. 배치는 CPU 한도입니다. 일반적으로 GPU를 사용하면 요즘 CPU가 새로운 상태로 보낼 수있는 것보다 빠르게 상태를 전환 할 수 있습니다. 상태 변경을 최소화하는 것은 매우, 아주 오래된 성능 조언입니다. 상태가 바뀌면 새로운 배치가 필요하기 때문에 요즘 만 적용됩니다. –
@Andrew. 의견에 감사드립니다.부분적으로는 동의 하겠지만 조언은 여전히 현재이며 DirectX 11에 대한 Microsoft의 도움이 있습니다 (XNA에 익숙하지 않습니다). 나는 당신의 출발점이 어디 있는지에 달려 있다고 생각합니다. 모든 Draw Primitive 호출이 상태 변경 일 때까지 엔진을 개발했다면 더 많은 것에 동의 할 것입니다. 그러나 OP가 아직 존재하지 않는다고 생각합니다. –
[이 게임 개발 사이트의 게시물]을 읽었습니까 (http://gamedev.stackexchange.com/questions/9277/optimizing-an-xna-2d-game/9289#9289)? –
실제로 나는 연결을위한 감사하지 않는다 :) – Archedius