여기에 많은 답변이 정말 좋습니다. 그러나 OpenGL 및 Direct3D (D3D) 문제를 해결해야합니다. 그리고 그것은 ... 역사 수업이 필요합니다.
시작하기 전에 Direct3D 보다 OpenGL 에 대해 훨씬 더 많이 알고 있습니다. 나는 평생 D3D 코드를 작성하지 않았으며 OpenGL에 대한 자습서를 작성했습니다. 제가 말하려는 것은 편견의 문제가 아닙니다. 그것은 단순히 역사의 문제입니다.
갈등의 탄생
어느 날 90 년대 초반 Microsoft는 주변을 둘러 보았습니다. 그들은 SNES 와 Sega Genesis 가 훌륭하고 많은 액션 게임을 실행하는 것을 보았습니다 . 그리고 그들은 DOS 를 보았습니다 . 개발자는 콘솔 게임과 같은 DOS 게임을 코딩했습니다. 그러나 SNES 게임을 만든 개발자가 사용자의 하드웨어를 알고있는 콘솔과 달리 DOS 개발자는 여러 가지 가능한 구성을 작성해야했습니다. 그리고 이것은 소리보다 다소 어렵습니다.
그리고 Microsoft는 더 큰 문제인 Windows를 가지고있었습니다. 개발자가 무엇이든 할 수있는 DOS와 달리 Windows는 하드웨어를 소유하고 싶어했습니다. 응용 프로그램 간 협력을 위해서는 하드웨어 소유가 필요합니다. 협력은 게임 개발자가 싫어하는 데 사용되는 소중한 하드웨어 리소스를 사용하기 때문에 게임 개발자가 싫어하는 것입니다.
Windows에서 게임 개발을 촉진하기 위해 Microsoft는 낮은 수준의 균일 한 API가 필요했지만 Windows에서 속도를 늦추지 않고 Windows에서 실행했으며 대부분의 크로스 하드웨어 였습니다. 모든 그래픽, 사운드 및 입력 하드웨어를위한 단일 API.
따라서 DirectX 가 탄생했습니다.
3D 가속기는 몇 달 후에 태어났습니다. 그리고 마이크로 소프트는 어려움에 부딪쳤다. DirectX의 그래픽 구성 요소 인 DirectDraw는 2D 그래픽 만 처리했습니다. 그래픽 메모리 할당 및 서로 다른 할당 된 메모리 섹션간에 비트 블리트 수행.
그래서 마이크로 소프트는 미들웨어의 비트를 구입하고 그것이 Direct3D를 버전 3으로 그것을 유행 보편적으로 욕. 그리고 합당한 이유가 있습니다. D3D v3 코드를 보는 것은 언약궤를 쳐다 보는 것과 같습니다.
Id Software의 Old John Carmack은 그 쓰레기를 한 번 살펴보면서 "나사를 돌려라!" OpenGL이라는 다른 API를 작성하기로 결정했습니다.
마이크로 소프트의 많은 짐승의 또 다른 부분은 Windows 용 OpenGL 구현에서 SGI와 함께 일하는 데 바빴다. 여기서 아이디어는 일반적인 GL 응용 프로그램 개발자 인 워크 스테이션 응용 프로그램에 적용되었습니다. CAD 도구, 모델링, 그런 것. 게임은 마음에 가장 먼 곳이었습니다. 이것은 주로 Windows NT 였지만 Microsoft는 Windows NT에도 추가하기로 결정했습니다.
Microsoft는 워크 스테이션 개발자를 Windows에 유인하기위한 방법으로 새로운 3D 그래픽 카드에 대한 액세스 권한을 부여하기로 결정했습니다. Microsoft는 Installable Client Driver 프로토콜을 구현했습니다. 그래픽 카드 제조업체는 하드웨어 기반의 소프트웨어로 Microsoft의 소프트웨어 OpenGL 구현을 무시할 수 있습니다. 코드는 사용 가능한 하드웨어 OpenGL 구현을 자동으로 사용할 수 있습니다.
초기에는 소비자 수준의 비디오 카드가 OpenGL을 지원하지 않았습니다. Carmack이 SGI 워크 스테이션에서 Quake를 OpenGL (GLQuake)로 포팅하는 것을 막지 못했습니다. GLQuake readme에서 읽을 수있는 것처럼 :
이론적으로, glquake는 텍스처 객체 확장을 지원하는 모든 호환 OpenGL에서 실행되지만 필요한 모든 것을 가속화하는 매우 강력한 하드웨어가 아니라면 게임 플레이가 허용되지 않습니다. 소프트웨어 에뮬레이션 경로를 거쳐야하는 경우 성능은 초당 1 프레임 미만일 것입니다.
현재 (97 년 3 월), glquake를 합리적으로 수행 할 수있는 유일한 표준 opengl 하드웨어는 intergraph realizm인데, 이는 매우 비싼 카드입니다. 3dlabs의 성능이 크게 향상되었지만 사용 가능한 드라이버로는 여전히 재생하기에 충분하지 않습니다. 글 린트 및 미디어 보드 용 현재 3dlabs 드라이버 중 일부는 전체 화면 실행에서 나갈 때 NT와 충돌 할 수 있으므로 3dlabs 하드웨어에서 glquake를 실행하지 않는 것이 좋습니다.
3dfx는 glquake에 필요한 모든 것을 구현하는 opengl32.dll을 제공했지만 전체 opengl 구현은 아닙니다. 다른 OpenGL 응용 프로그램은 작동하지 않을 수 있으므로 기본적으로 "glquake 드라이버"를 고려하십시오.
이것은 miniGL 드라이버의 탄생이었습니다. 하드웨어가 하드웨어에서 대부분의 OpenGL 기능을 구현할 수있을만큼 강력 해짐에 따라 결국 전체 OpenGL 구현으로 발전했습니다. nVidia는 전체 OpenGL 구현을 제공 한 최초의 기업입니다. 다른 많은 벤더들이 어려움을 겪었고, 이것이 개발자들이 Direct3D를 선호하는 이유 중 하나입니다. 더 광범위한 하드웨어에서 호환되었습니다. 결국 nVidia와 ATI (현재 AMD) 만 남았으며 둘 다 OpenGL 구현이 양호했습니다.
OpenGL 어센 던트
따라서 스테이지는 Direct3D와 OpenGL로 설정됩니다. D3D v3이 얼마나 나쁜지를 고려하면 정말 놀라운 이야기입니다.
ABB (OpenGL Architectural Review Board)는 OpenGL 유지 관리를 담당하는 조직입니다. 이들은 여러 확장을 발행하고 확장 저장소를 유지 보수하며 새 버전의 API를 작성합니다. ARB는 여러 그래픽 산업 플레이어와 일부 OS 제조업체로 구성된위원회입니다. Apple과 Microsoft는 여러 번 ARB의 회원이었습니다.
3Dfx는 Voodoo2와 함께 제공됩니다. 이것은 다중 텍스처링을 수행 할 수있는 최초의 하드웨어이며 OpenGL은 이전에는 할 수 없었습니다. 3Dfx는 OpenGL과 강력하게 반대하지만 차세대 멀티 텍스처링 그래픽 칩 (TNT1) 제조업체 인 엔비디아는이를 좋아했습니다. 따라서 ARB는 GL_ARB_multitexture라는 확장을 발행하여 다중 텍스처링에 액세스 할 수있게되었습니다.
한편 Direct3D v5가 나옵니다. 이제 D3D는 고양이가 구토하는 것이 아니라 실제 API 가되었습니다 . 문제? 다중 텍스처링이 없습니다.
죄송합니다.
사람들이 멀티 텍스쳐링을 많이 사용하지 않았기 때문에 이제는 원하는만큼 아프지 않을 것입니다. 직접 아닙니다. 멀티 텍스쳐링은 성능을 상당히 저하 시켰으며, 많은 경우 멀티 패스와 비교할 때 가치가 없었습니다. 물론 게임 개발자는 게임이 멀티 텍스쳐링이 없었던 구형 하드웨어에서 작동하도록하는 것을 좋아합니다.
따라서 D3D는 추방되었다.
시간이 지남에 따라 NVIDIA는 GeForce 256 (GeForce GT-250이 아닌 최초의 GeForce)을 배포하여 향후 2 년간 그래픽 카드 경쟁이 거의 끝났습니다. 주요 판매 포인트는 하드웨어에서 정점 변환 및 조명 (T & L)을 수행하는 기능입니다. 뿐만 아니라 NVIDIA는 OpenGL을 매우 좋아하여 T & L 엔진이 효과적으로 OpenGL 이었습니다 . 거의 문자 그대로; 내가 이해하는 것처럼 일부 레지스터는 실제로 OpenGL 열거자를 직접 값으로 사용했습니다.
Direct3D v6이 나옵니다. 결국 다중 텍스처이지만 하드웨어 T & L은 없습니다. OpenGL은 256 이전에 소프트웨어로 구현되었지만 항상 T & L 파이프 라인을 가지고있었습니다. 따라서 NVIDIA는 소프트웨어 구현을 하드웨어 솔루션으로 변환하기가 매우 쉬웠습니다. D3D가 마침내 하드웨어 T & L을 지원할 때까지 D3D v7까지는 없었습니다.
Shaders의 새벽, OpenGL의 황혼
그런 다음 GeForce 3이 나왔습니다. 동시에 많은 일들이 일어났습니다.
마이크로 소프트는 다시는 늦지 않기로 결정했다. 따라서 엔비디아가하고있는 일을보고 그 사실을 복사 한 것이 아니라 그들에게 가서 대화하는 놀라운 위치를 차지했습니다. 그리고 그들은 사랑에 빠졌고 작은 콘솔을 가지고있었습니다.
혼란스러운 이혼이 뒤 따랐다. 그러나 그것은 또 다른 시간입니다.
이것이 PC의 의미는 GeForce 3이 D3D v8과 동시에 나왔다는 것입니다. 그리고 GeForce 3가 D3D 8의 쉐이더에 어떤 영향을 미치는지 알기가 어렵지 않습니다. Shader Model 1.0의 픽셀 쉐이더는 NVIDIA의 하드웨어에 매우 고유했습니다. NVIDIA의 하드웨어를 추상화하려는 시도는 없었습니다. SM 1.0은 GeForce 3의 기능입니다.
ATI가 Radeon 8500과 함께 성능 그래픽 카드 경쟁에 뛰어 들기 시작했을 때 문제가있었습니다. 8500의 픽셀 처리 파이프 라인은 NVIDIA의 것보다 강력했습니다. 따라서 Microsoft는 Shader Model 1.1을 발행했는데 기본적으로 "8500의 기능"입니다.
그것은 D3D의 실패처럼 들릴 수 있습니다. 그러나 실패와 성공은 학위의 문제입니다. 그리고 OpenGL-land에서 서사시의 실패가 일어나고있었습니다.
NVIDIA는 OpenGL을 좋아했기 때문에 GeForce 3가 출시 될 때 수많은 OpenGL 확장 기능을 발표했습니다. 독점적 인 OpenGL 확장 : NVIDIA 전용. 당연히 8500이 나타 났을 때 그것들 중 어느 것도 사용할 수 없었습니다.
적어도 D3D 8 랜드에서는 ATI 하드웨어에서 SM 1.0 셰이더를 실행할 수 있습니다. 물론, 8500의 차가움을 이용하려면 새 셰이더를 작성해야하지만 최소한 코드 는 효과가 있었습니다.
OpenGL에서 Radeon 8500에 어떤 종류의 셰이더를 갖기 위해 ATI는 여러 OpenGL 확장을 작성해야했습니다. 독점적 OpenGL 확장 : ATI 전용. 따라서 셰이더 를 사용 하려면 NVIDIA 코드 경로와 ATI 코드 경로가 필요했습니다 .
이제 "OpenGL을 최신 상태로 유지하는 것이 OpenGL ARB의 역할은 무엇입니까?"라고 물을 수 있습니다. 많은위원회가 종종 끝나는 곳 : 멍청한 행동.
위의 ARB_multitexture는이 모든 것을 깊이 고려하기 때문에 위에서 언급했습니다. ARB는 (외부인의 관점에서) 쉐이더의 아이디어를 완전히 피하고 싶었습니다. 그들은 고정 기능 파이프 라인에 충분한 구성 기능을 제공하면 셰이더 파이프 라인의 기능과 같을 수 있다고 생각했습니다.
따라서 ARB는 확장 후 확장을 릴리스했습니다. "texture_env"라는 단어가 포함 된 모든 확장은이 에이징 디자인을 패치하려는 또 다른 시도였습니다. 레지스트리를 확인하십시오. ARB와 EXT 확장 사이 에는이 확장 중 8 개가 있습니다. 많은 사람들이 OpenGL 코어 버전으로 승격되었습니다.
현재 Microsoft는 ARB의 일부였습니다. 그들은 D3D 9가 맞을 때쯤 떠났다. 그래서 그들은 어떤 식 으로든 OpenGL을 방해하려고 노력했을 가능성이 있습니다. 나는 두 가지 이유로이 이론을 개인적으로 의심한다. 하나는 다른 ARB 회원들로부터 도움을 얻어야했을 것입니다. 각 회원은 한 표만 얻었 기 때문입니다. 그리고 가장 중요한 두 가지는 ARB가 문제를 해결하기 위해 Microsoft의 도움을 필요로하지 않았다는 것입니다. 그에 대한 추가 증거를 볼 수 있습니다.
결국 ATI와 NVIDIA (능동적 인 멤버 모두)의 위협을 받고있는 ARB는 결국 실제 어셈블리 스타일 쉐이더를 제공 할 정도로 오랫동안 머리를 뽑아 냈습니다.
더 바보 같은 것을 원하십니까?
하드웨어 T & L. OpenGL이 먼저 가지고 있었던 것 . 글쎄요. 하드웨어 T & L에서 최대한의 성능을 얻으려면 꼭짓점 데이터를 GPU에 저장해야합니다. 결국, 실제로 정점 데이터를 사용하려는 것은 GPU입니다.
D3D v7에서 Microsoft는 Vertex Buffers라는 개념을 도입했습니다. 이들은 정점 데이터를 저장하기 위해 GPU 메모리를 할당합니다.
OpenGL이 언제 이와 동등한 지 알고 싶습니까? 오, NVIDIA는 OpenGL (독점적 인 NVIDIA 확장 인 경우)을 좋아하는 GeForce 256이 처음 출시 될 때 정점 배열 범위 확장을 발표했습니다. 그러나 ARB는 언제 비슷한 기능을 제공하기로 결정 했습니까?
2 년 후 . 정점 및 프래그먼트 셰이더 (D3D 언어의 픽셀)를 승인 한 후 였습니다 . ARB가 GPU 메모리에 정점 데이터를 저장하기위한 크로스 플랫폼 솔루션을 개발하는 데 시간이 오래 걸렸습니다. 다시 말하지만 하드웨어 T & L 이 최대 성능을 달성하는 데 필요한 것 입니다.
그들 모두를 망칠 하나의 언어
그래서 OpenGL 개발 환경은 한동안 파괴되었습니다. 크로스 하드웨어 셰이더, 크로스 하드웨어 GPU 버텍스 스토리지가 없으며 D3D 사용자는 둘 다 즐겼습니다. 더 나빠질 수 있습니까?
당신은 ... 그렇게 말할 수 있습니다. 3D Labs를 입력하십시오 .
그들이 누구냐고 물어봐도 될까요? 그들은 OpenGL의 진정한 살인자라고 생각하는 쓸모없는 회사입니다. 물론 ARB의 일반적인 부적절 성으로 인해 OpenGL은 D3D를 소유해야했을 때 취약했습니다. 그러나 3D 랩은 아마도 OpenGL의 현재 시장 상태에 대한 가장 큰 이유 일 것입니다. 그것들을 유발시키기 위해 무엇을 할 수 있었습니까?
그들은 OpenGL Shading Language를 디자인했습니다.
3D Labs는 죽어가는 회사였습니다. 엔비디아는 워크 스테이션 시장에 대한 압박이 가중되면서 고가의 GPU를 소외시키고있었습니다. NVIDIA와 달리 3D Labs는 주류 시장에 존재하지 않았습니다. 엔비디아가 이기면 죽었다.
그들이 한 일.
따라서 제품을 원하지 않는 세계에서 관련성을 유지하기 위해 3D Labs는 "OpenGL 2.0"이라는 프레젠테이션을하는 게임 개발자 컨퍼런스에 참가했습니다. 이것은 OpenGL API를 완전히 처음부터 다시 쓴 것입니다. 그리고 그것은 말이됩니다; 당시 OpenGL의 API 에는 많은 균열이있었습니다 (참고 : 그 균열은 여전히 존재합니다). 텍스처 로딩과 바인딩이 어떻게 작동하는지 살펴보십시오. 세미 아칸입니다.
그들의 제안 중 일부는 음영 언어였습니다. 당연히. 그러나 현재 크로스 플랫폼 ARB 확장과 달리 음영 언어는 "고수준"입니다 (C는 음영 언어에 대해 높은 수준입니다).
이제 Microsoft는 자체적 인 고급 음영 언어를 연구하고있었습니다. 그것들은 마이크로 소프트의 모든 상상에서 HLSL (High Level Shading Language)이라고 불렀습니다. 그러나 그것들은 언어에 대한 근본적으로 다른 접근법이었습니다.
3D Labs의 셰이더 언어의 가장 큰 문제는 내장 언어라는 것이 었습니다. HLSL은 Microsoft에서 정의한 언어였습니다. 그들은 그것을 위해 컴파일러를 출시했으며, Shader Model 2.0 (또는 이후 쉐이더 모델) 어셈블리 코드를 생성했습니다. D3D v9 일 동안 HLSL은 D3D에 의해 직접 만지지 않았습니다. 멋진 추상화 였지만 순전히 선택 사항이었습니다. 그리고 개발자는 항상 컴파일러를 뒤져서 최대 성능을 위해 출력을 조정할 수있는 기회를 가졌습니다.
3D Labs 언어에는 그러한 기능 이 없었 습니다. 드라이버에게 C와 같은 언어를 제공하고 셰이더를 생성했습니다. 이야기의 끝. 어셈블리 셰이더가 아닌 다른 무언가를 공급하는 것이 아닙니다. 셰이더를 나타내는 실제 OpenGL 객체입니다.
이것이 의미하는 바는 OpenGL 사용자가 단지 어셈블리와 같은 언어를 컴파일하는 개발자들에게 열려 있음을 의미합니다. 새로 버그 화 된 OpenGL Shading Language (GLSL)에서 컴파일러 버그가 만연해 있었습니다. 더 나쁜 것은 셰이더가 여러 플랫폼에서 올바르게 컴파일되도록 (임의의 묘기가 아님) 계속 해서 오늘날 의 옵티 마이저 에 노출 된 것입니다. 그들이 할 수있는만큼 최적이 아닙니다.
이것이 GLSL에서 가장 큰 결함 이었지만 유일한 결함은 아닙니다. 으로 까지 .
D3D 및 OpenGL의 이전 어셈블리 언어에서는 정점 및 조각 (픽셀) 셰이더를 혼합하고 일치시킬 수 있습니다. 동일한 인터페이스와 통신하는 한 호환 가능한 조각 쉐이더와 함께 모든 버텍스 쉐이더를 사용할 수 있습니다. 그리고 그들이 수용 할 수있는 비 호환성 수준도있었습니다. 버텍스 셰이더는 프래그먼트 셰이더가 읽지 않은 출력을 작성할 수 있습니다. 기타 등등.
GLSL에는 그중 아무것도 없었습니다. 정점 및 프래그먼트 셰이더는 3D Labs에서 "프로그램 객체"라고하는 것과 함께 융합되었습니다. 따라서 정점 및 프래그먼트 프로그램을 공유하려면 여러 프로그램 오브젝트를 빌드해야합니다. 그리고 이것은 두 번째로 큰 문제를 일으켰습니다.
3D Labs는 그들이 영리하다고 생각했습니다. 그들은 GLSL의 컴파일 모델을 C / C ++에 기반했다. .c 또는 .cpp를 가져 와서 객체 파일로 컴파일합니다. 그런 다음 하나 이상의 객체 파일을 가져 와서 프로그램에 연결합니다. 이것이 GLSL이 컴파일하는 방식입니다. 셰이더 (정점 또는 조각)를 셰이더 객체로 컴파일합니다. 그런 다음 해당 쉐이더 객체를 프로그램 객체에 넣고 함께 연결하여 실제 프로그램을 형성합니다.
이것이 주요 셰이더가 호출 할 수있는 추가 코드를 포함하는 "라이브러리"셰이더를 갖는 것과 같은 멋진 아이디어를 허용했지만 실제로 의미는 셰이더가 두 번 컴파일되었다는 것 입니다. 컴파일 단계에서 한 번, 연결 단계에서 한 번. 특히 NVIDIA의 컴파일러는 기본적으로 컴파일을 두 번 실행하는 것으로 알려져 있습니다. 어떤 종류의 객체 코드 중개자를 생성하지 않았습니다. 방금 한 번 컴파일하고 답변을 버린 다음 링크 타임에 다시 컴파일했습니다.
따라서 정점 셰이더를 두 개의 다른 조각 셰이더에 연결하려는 경우에도 D3D보다 훨씬 더 많은 컴파일 작업을 수행해야합니다. 특히 C와 같은 언어의 컴파일은 프로그램 실행의 시작이 아닌 오프라인 에서 모두 수행 되었으므로 .
GLSL에 다른 문제가있었습니다. ARB가 결국 언어를 승인하고 통합했기 때문에 3D 연구소에 책임을지는 것은 아마도 잘못된 것 같습니다 (하지만 "OpenGL 2.0"이니셔티브의 다른 것들은 없습니다). 그러나 그것은 그들의 생각이었습니다.
그리고 여기 정말 슬픈 부분이 있습니다 : 3D Labs가 옳았습니다 (주로). GLSL은 당시 HLSL과 같은 벡터 기반 음영 언어가 아닙니다. 이는 3D Labs의 하드웨어가 스칼라 하드웨어 (현대 NVIDIA 하드웨어와 유사) 였지만 많은 하드웨어 제조업체가 하드웨어와 함께 사용하는 방향에 궁극적으로 맞았 기 때문입니다.
그들은 "고수준"언어를위한 온라인 컴파일 모델을 가지고 갈 권리가 있었다. D3D는 결국 그로 전환했습니다.
문제는 3D 랩이 제때 에 잘못되었다는 것이 었습니다 . 그리고 미래를 너무 일찍 소환하려고 노력하고 미래에 대비하려고 노력하면서 그들은 현재를 버렸습니다 . OpenGL이 항상 T & L 기능을 사용할 수 있었던 방식과 비슷합니다. OpenGL의 T & L 파이프 라인은 하드웨어 T & L보다 여전히 유용 했지만 GLSL은 전 세계가이를 따라 잡기 전에 책임을졌습니다.
GLSL은 지금 좋은 언어 입니다. 그러나 당분간? 끔직했다. 그리고 OpenGL이 어려움을 겪었습니다.
Apotheosis로 떨어지는
3D Labs가 치명적인 타격을 입었다 고 유지하면서 ARB 자체가 관의 마지막 못을 박았습니다.
이것은 당신이 들어 본 이야기입니다. OpenGL 2.1 당시에는 OpenGL에 문제가 발생했습니다. 레거시 크래프트 가 많았습니다 . 더 이상 API를 사용하기가 쉽지 않았습니다. 작업을 수행하는 5 가지 방법이 있었으며 어느 것이 가장 빠른지 알 수 없었습니다. 간단한 자습서를 통해 OpenGL을 "학습"할 수 있지만 실제 성능과 그래픽 성능을 제공하는 OpenGL API는 실제로 배우지 못했습니다.
따라서 ARB는 OpenGL의 또 다른 재발 명을 시도하기로 결정했습니다. 이것은 3D Labs의 "OpenGL 2.0"과 유사하지만 ARB가 뒤에 있기 때문에 더 좋습니다. 그들은 그것을 "롱 피크"라고 불렀습니다.
API를 개선하는 데 시간이 걸리는 것이 왜 그렇게 나쁜가요? 마이크로 소프트가 스스로 취약 해 졌기 때문에 이것은 나빴다. 참조 이 비스타 전환의 시간이었다.
Vista를 통해 Microsoft는 디스플레이 드라이버에 필요한 변경 사항을 적용하기로 결정했습니다. 그들은 그래픽 메모리 가상화 및 기타 여러 가지를 위해 드라이버를 OS에 제출하도록 강요했습니다.
마이크로 소프트가 D3D 10을 비스타 (및 그 이상)로만 간주 한 것은 사실이다. D3D 10 을 지원 하는 하드웨어가 있어도 Vista를 실행하지 않고도 D3D 10 응용 프로그램을 실행할 수 없었습니다.
Vista를 기억할 수도 있습니다. 음, 제대로 작동하지 않았다고 가정 해 봅시다. 따라서 성능이 낮은 OS, 해당 OS에서만 실행되는 새로운 API 및 이전 세대보다 빠른 작업을 수행하기 위해 해당 API 및 OS 가 필요한 새로운 세대의 하드웨어가 있었습니다.
그러나 개발자 는 OpenGL을 통해 D3D 10 급 기능에 액세스 할 수 있습니다. ARB가 Longs Peak에서 바쁘지 않았다면 글쎄요.
기본적으로 ARB는 API를 개선하기 위해 1 년 반에서 2 년 정도의 노력을 들였습니다. 실제로 OpenGL 3.0이 출시 될 때 Vista 채택이 시작되고 Win7이 Vista를 뒤엎을 수있었습니다. 대부분의 게임 개발자는 D3D-10 클래스 기능에 신경 쓰지 않았습니다. 결국 D3D 10 하드웨어는 D3D 9 응용 프로그램을 제대로 실행했습니다. 그리고 PC-to-console 포트 (또는 PC 개발자가 콘솔 개발에 뛰어 들었습니다. 선택하십시오)의 등장으로 개발자들은 D3D 10 클래스 기능이 필요하지 않았습니다.
이제 개발자가 WinXP 시스템에서 OpenGL을 통해 이전에 이러한 기능에 액세스 한 경우 OpenGL 개발에 많은 도움이되었을 것입니다. 그러나 ARB는 그들의 기회를 놓쳤다. 그리고 최악의 부분을 알고 싶습니까?
API를 처음부터 다시 작성하는 데 2 년이 걸렸음에도 불구하고 여전히 실패했으며 현재 상태로 되돌아갔습니다 (사용 중단 메커니즘 제외).
따라서 ARB는 중요한 기회 창을 놓쳤을뿐만 아니라 기회를 놓치게하는 작업도 수행하지 않았습니다. 거의 모든 서사시가 실패합니다.
이것이 OpenGL과 Direct3D의 이야기입니다. 놓친 기회, 심한 어리 석음, 고의적 인 실명 및 단순한 어리 석음에 대한 이야기.