크로스 플랫폼 저수준 그래픽 API

11

시스템 추상화를 생성 할 때 가장 낮은 수준의 공통 인터페이스로 플랫폼에 다른 API를 숨기는 것이 좋습니다.

고정 기능 파이프 라인이없는 다른 최신 기본 그래픽 API (OpenGLES 2.0+, OpengGL 3.0+, DirectX 10.0+, Xbox DirectX 9, LibGCM)를 고려

하나는 만들 수 있었다면 무 저를 , 모두의 위에 앉아 수준의 그래픽 API를 가능한 한 빨리 얇은로 만들 가서 무엇을있는 가장 좋은 방법은 무엇인가요?

architecture  software-engineering  graphics  cross-platform 
— 녹턴 드래곤
소스
API가 무국적 이어야한다는 요구 사항 은 흥미 롭습니다. 예를 들어 OpenGL은 Stateful이며, 랩핑하는 Stateless API는 훨씬 높은 수준 인 경우에만 의미가 있으므로 예를 들어 각각에 대해 동일한 수학을 강요하고 터뜨리지 않아도됩니다. 렌더링되는 표면.
— SpoonMeiser
쓸모없는 상태 변경을 피하는 것은 여전히 ​​장치에 제출하기 전에 상태에 따라 렌더 호출을 정렬하는 것과 같이 더 높은 수준에서 구현 될 수 있습니다. 현재 상태와 다른 경우에만 상태를 설정합니다.
— NocturnDragon
그래도 상태가 아닙니다. 어쩌면 틀릴 수도 있지만 상태 비 저장을 생각할 때 각 호출이 이전 호출에 전혀 의존하지 않는 API입니다. 즉, 일반적으로 어딘가에 상태로 저장되는 모든 정보는 해당 정보가 필요한 모든 호출에서 전달되어야합니다. 예를 들어 OpenGL의 경우 스택, 조명, z- 버퍼링 및 정규화 옵션에 대한 문제가 있습니다.
— SpoonMeiser
그렇습니다. 모든 드로우 콜마다 메시 데이터, 블렌딩 상태, 바인딩 할 텍스처, 샘플링 상태 등이 필요합니다. API를 변경하지 않고 나중에 최적화 할 수 있습니다. 아니면 내가 당신의 의견을 잘못 읽고 있을지도 모릅니다.
— NocturnDragon

답변:

6

내 관점에서 이해하는 가장 낮은 수준은 vb / ib, 렌더 표면, 텍스처, 셰이더, 상태 블록 등 렌더링과 관련된 리소스에 대해 이야기하는 것입니다.

여기서 문제는 API에 따라 일부 형식이 다른 형식이어야한다는 것입니다. 가장 쉬운 방법은 해당 API의 정적 리소스를 사전 처리하는 것입니다. 동적 인 경우 쉐이더 만 사용 하여 생성하므로 기본 형식을 유지하는 것이 매우 간단합니다.

상위 레벨에서 수행하는 모든 작업은 첨부 된 리소스가있는 파이프 라인을 설정하고 GPU에 전달합니다. 특히 하드웨어 관련 트릭을 활용하는 경우 모든 방식을 멋지게 추상화 할 수있는 것은 아닙니다. 그러나 좋은 출발입니다.

(Sidenote : 플랫폼 별 트릭을 특수한 종류의 리소스로 취급하면이 전체 개념을 상당히 발전시킬 수 있습니다.)

따라서 하드웨어 리소스 관리자와 이러한 리소스의 DAG를 설정하기위한 툴킷 등 두 가지를 만듭니다.

— 레이첼 블룸
소스
플랫폼 관련 사항을 리소스로 취급하는 것에 대해 생각한 적이 없습니다. 아주 좋은 생각 인 것 같습니다! 감사.
— NocturnDragon
10

다루려는 광범위한 API가 주어지면 일반적인 줄 바꿈 방식은 비효율적이며 특정 기능을 다양한 수준으로 지원하거나 지원하지 않을 수있는 다른 여러 API에 API 개념을 매핑하는 데 어려움을 겪을 수 있습니다.

결과적으로 가장 합리적인 접근 방식은 기능 중심 API 를 만드는 것 입니다. 이 접근 방식은 API 사용자가 사용 가능한 모든 기능을 활용하지 못하도록하지만 각 백엔드의 구현을 크게 단순화하고 달리 불가능한 백엔드 별 최적화를 가능하게합니다.

또한 API 사용자를 위해 지원되지 않는 기능 관리를 크게 단순화합니다. 더 이상 기능 X가 존재하는지 점검하고 영향을받는 기능을 판별 할 필요가 없으며 기능 자체를 조회하여 현재 구성에서 지원되는지 확인하십시오. 기능에 대해 부분 또는 제한된 모드를 지원하더라도 제공되는 컨텍스트를 통해 훨씬 쉽게 관리 할 수 ​​있습니다.

상태 비 저장 ( 제출 기반 이라고도 함 ) 렌더러 를 만드는 경우 일반적 으로 64 비트 키 가 렌더링 명령을 압축하고 제출하는 데 사용됩니다. 이 시점부터 지원하려는 기능에 따라 명령 실행 방법 및 제출할 정보와 관련 하여 많은 융통성 이 있습니다.

— 제이슨 코 자크
소스
이것은 실제로 좋은 생각입니다. 그리고 내가 만들려고하는 디자인의 일부이지만, 내가 생각한 것은 일반적인 저수준 API 위에이 기능을 구현하는 것이 었습니다. 그러나 일부 기능의 경우 더 구체적인 경우를 위해 네이티브 API에 대해 깊이 알아야 할 수도 있습니다.
— NocturnDragon
아이디어의 일부는 공통 저수준 API를 작성하지 않고 최저 공통 분모 접근 방식으로 래핑을 처리해야하는 것입니다. 추상화 수준을 한 단계 높이면 기능 세트가 다소 제한되지만 각 플랫폼을 악용하는 기능도 얻게됩니다. 더 깊게 액세스해야하는 경우를 처리하기 위해 플랫폼 헤더와 일부 내부 도우미를 노출하는 헤더를 제공하는 것이 좋습니다. 버전마다 다를 수 있지만 필요한 경우 있습니다.
— Jason Kozak
1

우선, 각 API는 다르게 작동하므로 위의 모든 API를 래핑하는 것은 어려울 것입니다. 즉, 때로는 그렇게하는 것이 필요합니다. 어떤 시점에서 게임은 얼마나 어려운지에 관계없이 둘 이상의 플랫폼에서 실행하면됩니다.

이 작업을 수행하는 가장 좋은 방법은 모든 기본 API에서 구현할 수있는 기능을 구현하는 것입니다. 멀티 플랫폼 게임을 개발하는 경우 각 API가 지원하는 모호한 기능을 모두 구현하지는 않고 필요한 것만 구현하면됩니다. 또한 API를 작고 빠르게 유지하는 데 도움이됩니다.

각기 다른 API 구현의 혼란이 발생하지 않도록하려면 플랫폼 중립 헤더 파일 및 플랫폼 특정 코드 파일을 사용하여 컴파일해야합니다. 그런 다음, 대상 플랫폼에 특정한 코드 파일은 API를 작게 유지하면서 컴파일 된 유일한 파일입니다.

— 숀 제임스
소스
-4

SDL 라이브러리 또는 Allegro 를 확인하십시오 . 둘 다 저수준의 이식성이 뛰어난 게임 라이브러리로, OpenGL 컨텍스트에 연결하여 그래픽을 렌더링 할 수 있습니다. SDL은 Loki Games가 2000 년대에서 Linux로 인기있는 일부 게임을 포팅하는 데 사용되는 명성을 가지고 있으며 Allegro는 많은 시간을 보내고 아마추어 게임 개발자 커뮤니티를 보유하고 있습니다.

— Chiguire
소스
4
OpenGL과 DirectX를 모두 래핑하는 것이 가능하다는 점은 말할 것도없이이 질문에 대한 답은 아닙니다 (Ogre3D, Irrlicht 등 참조).
— Jason Kozak
당신이 한 게임을 고려하십시오. DirectX 또는 OpenGL을 사용할 수있는 옵션이 몇 개나 있습니까? 그것은 두 라이브러리가 어느 하나를 지원할 수있는 랩퍼를 몇 개나 만드는가입니다. 당신은 상상력이 제한되어 있습니다. :-P
— Ricket
OpenGL 또는 DirectX로 그래픽을 렌더링할지 여부를 선택할 수있는 게임이 있지만 크로스 플랫폼 API에 관한 질문이므로 답변이 적절하다고 생각합니다. 첫 번째 단락을 편집하겠습니다. 그러나.
— chiguire
1
문제는 크로스 플랫폼 상태 비 저장 저수준 API에 관한 것입니다. SDL과 Allegro는 이와 관련이 없습니다.
— NocturnDragon
@NocturnDragon-질문 제목은 약간 오해의 소지가 있습니다. 언뜻보기에 사용 가능한 API의 선택에 대한 질문이 예상 되었으며이 답변자가 그렇게했다고 가정합니다.
— a_m0d
당사 사이트를 사용함과 동시에 당사의 쿠키 정책과 개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.