시스템 추상화를 생성 할 때 가장 낮은 수준의 공통 인터페이스로 플랫폼에 다른 API를 숨기는 것이 좋습니다.
고정 기능 파이프 라인이없는 다른 최신 기본 그래픽 API (OpenGLES 2.0+, OpengGL 3.0+, DirectX 10.0+, Xbox DirectX 9, LibGCM)를 고려
하나는 만들 수 있었다면 무 저를 , 모두의 위에 앉아 수준의 그래픽 API를 가능한 한 빨리 얇은로 만들 가서 무엇을있는 가장 좋은 방법은 무엇인가요?
답변
내 관점에서 이해하는 가장 낮은 수준은 vb / ib, 렌더 표면, 텍스처, 셰이더, 상태 블록 등 렌더링과 관련된 리소스에 대해 이야기하는 것입니다.
여기서 문제는 API에 따라 일부 형식이 다른 형식이어야한다는 것입니다. 가장 쉬운 방법은 해당 API의 정적 리소스를 사전 처리하는 것입니다. 동적 인 경우 쉐이더 만 사용 하여 생성하므로 기본 형식을 유지하는 것이 매우 간단합니다.
상위 레벨에서 수행하는 모든 작업은 첨부 된 리소스가있는 파이프 라인을 설정하고 GPU에 전달합니다. 특히 하드웨어 관련 트릭을 활용하는 경우 모든 방식을 멋지게 추상화 할 수있는 것은 아닙니다. 그러나 좋은 출발입니다.
(Sidenote : 플랫폼 별 트릭을 특수한 종류의 리소스로 취급하면이 전체 개념을 상당히 발전시킬 수 있습니다.)
따라서 하드웨어 리소스 관리자와 이러한 리소스의 DAG를 설정하기위한 툴킷 등 두 가지를 만듭니다.
답변
다루려는 광범위한 API가 주어지면 일반적인 줄 바꿈 방식은 비효율적이며 특정 기능을 다양한 수준으로 지원하거나 지원하지 않을 수있는 다른 여러 API에 API 개념을 매핑하는 데 어려움을 겪을 수 있습니다.
결과적으로 가장 합리적인 접근 방식은 기능 중심 API 를 만드는 것 입니다. 이 접근 방식은 API 사용자가 사용 가능한 모든 기능을 활용하지 못하도록하지만 각 백엔드의 구현을 크게 단순화하고 달리 불가능한 백엔드 별 최적화를 가능하게합니다.
또한 API 사용자를 위해 지원되지 않는 기능 관리를 크게 단순화합니다. 더 이상 기능 X가 존재하는지 점검하고 영향을받는 기능을 판별 할 필요가 없으며 기능 자체를 조회하여 현재 구성에서 지원되는지 확인하십시오. 기능에 대해 부분 또는 제한된 모드를 지원하더라도 제공되는 컨텍스트를 통해 훨씬 쉽게 관리 할 수 있습니다.
상태 비 저장 ( 제출 기반 이라고도 함 ) 렌더러 를 만드는 경우 일반적 으로 64 비트 키 가 렌더링 명령을 압축하고 제출하는 데 사용됩니다. 이 시점부터 지원하려는 기능에 따라 명령 실행 방법 및 제출할 정보와 관련 하여 많은 융통성 이 있습니다.
답변
우선, 각 API는 다르게 작동하므로 위의 모든 API를 래핑하는 것은 어려울 것입니다. 즉, 때로는 그렇게하는 것이 필요합니다. 어떤 시점에서 게임은 얼마나 어려운지에 관계없이 둘 이상의 플랫폼에서 실행하면됩니다.
이 작업을 수행하는 가장 좋은 방법은 모든 기본 API에서 구현할 수있는 기능을 구현하는 것입니다. 멀티 플랫폼 게임을 개발하는 경우 각 API가 지원하는 모호한 기능을 모두 구현하지는 않고 필요한 것만 구현하면됩니다. 또한 API를 작고 빠르게 유지하는 데 도움이됩니다.
각기 다른 API 구현의 혼란이 발생하지 않도록하려면 플랫폼 중립 헤더 파일 및 플랫폼 특정 코드 파일을 사용하여 컴파일해야합니다. 그런 다음, 대상 플랫폼에 특정한 코드 파일은 API를 작게 유지하면서 컴파일 된 유일한 파일입니다.
답변
Emil Persson (Humus)의 GPU Pro 관련 기사가 있습니다.
http://gpupro.blogspot.com/2009/12/making-it-large-beautiful-fast-and.html
렌더링을위한 크로스 플랫폼 인터페이스. 하나의 장점과 DX10을 DX9 콘솔과의 공통 인터페이스로 구성하고 좋은 성능을 유지 한 방법.