Buradaki cevapların çoğu gerçekten çok iyi. Ancak, OpenGL ve Direct3D (D3D) sorunu muhtemelen ele alınmalıdır. Bu da ... tarih dersini gerektirir.
Ve başlamadan önce, OpenGL hakkında Direct3D'den daha fazla şey biliyorum . Hayatımda hiçbir zaman bir D3D kodu satırı yazmadım ve OpenGL üzerine dersler yazdım. Söyleyeceğim şey bir önyargı meselesi değil. Bu sadece bir tarih meselesidir.
Çatışmanın Doğuşu
Bir gün, bazen 90'ların başlarında, Microsoft etrafına baktı. SNES ve Sega Genesis'in harika olduklarını, pek çok aksiyon oyunu oynadıklarını gördüler . Ve DOS’u gördüler . Geliştiriciler konsol oyunları gibi DOS oyunlarını kodladı: doğrudan metale. Ancak, SNES oyunu yapan bir geliştiricinin kullanıcının hangi donanıma sahip olduğunu bildiği konsollardan farklı olarak, DOS geliştiricileri birden fazla olası yapılandırma için yazmak zorunda kaldı. Ve bu göründüğünden daha zordur.
Microsoft'un daha büyük bir problemi vardı: Windows. Bakın, Windows, donanıma ne olursa olsun hemen hemen izin veren DOS'un aksine, donanıma sahip olmak istedi. Uygulamalar arasında işbirliğini sağlamak için donanıma sahip olmak gerekir. İşbirliği, oyun geliştiricilerin nefret ettiği şeydir, çünkü harika olmak için kullanabilecekleri değerli donanım kaynaklarını kullanır.
Windows'ta oyun geliştirmeyi teşvik etmek için Microsoft'un düşük seviyeli, Windows tarafından yavaşlatılmadan çalıştırılan ve tüm çapraz donanıma sahip düzgün bir API'ye ihtiyacı vardı . Tüm grafikler, ses ve giriş donanımı için tek bir API.
Böylece, DirectX doğdu.
3D hızlandırıcılar birkaç ay sonra doğdu. Microsoft da bir sorunla karşılaştı. DirectX’in grafik bileşeni olan DirectDraw’a bakın, yalnızca 2D grafiklerle ilgileniyor: grafik belleği ayırma ve belleğin farklı ayrılmış bölümleri arasında bit harmanlama işlemi yapma.
Yani Microsoft, ara katman biraz satın alınan ve O edildi Direct3D Version 3. içine moda evrensel reviled. Ve iyi bir sebeple; D3D v3 koduna bakmak, Ahit Sandığı'na bakmak gibidir.
Id Software'den Old John Carmack o çöp kutusuna bir bakış attı ve "Vidala!" Dedi. ve başka bir API'ye yazmaya karar verdim: OpenGL.
Bakın, Microsoft’un çok kafalı canavarın bir bölümü, SGI’da Windows için bir OpenGL uygulaması için çalışmakla meşguldü. Buradaki fikir, tipik GL uygulamalarının geliştiricilerini mahkemeye çıkarmaktı: iş istasyonu uygulamaları. CAD araçları, modelleme, bu tür şeyler. Oyunlar akıllarındaki en uzak şeydi. Bu öncelikle bir Windows NT olayıydı, fakat Microsoft Win95'e de eklemeye karar verdi.
İş istasyonu geliştiricilerini Windows’a çekmenin bir yolu olarak Microsoft, bu yeni çıkıntılı 3D grafik kartlarına erişerek onlara rüşvet vermeye çalışmaya karar verdi. Microsoft, Yüklenebilir İstemci Sürücüsü protokolünü uyguladı: bir grafik kartı üreticisi, Microsoft'un yazılım tabanlı OpenGL uygulamasını donanım tabanlı bir sürümle geçersiz kılabilir. Varsa, kod otomatik olarak yalnızca bir donanım OpenGL uygulamasını kullanabilirdi.
İlk günlerde, tüketici düzeyindeki video kartlarında OpenGL desteği yoktu. Bu, Carmack'in SGI iş istasyonunda Quake'i OpenGL'ye (GLQuake) taşımasını engellemedi. GLQuake readme'den okuyabildiğimiz gibi:
Teorik olarak, glquake, doku nesnesi uzantılarını destekleyen herhangi bir uyumlu OpenGL üzerinde çalışacaktır, ancak gereken her şeyi hızlandıran çok güçlü bir donanım olmadığı sürece, oyun kabul edilemez. Herhangi bir yazılım öykünme yolundan geçmesi gerekiyorsa, performans muhtemelen saniyede bir kare altında gerçekleşir.
Şu anda (Mart '97), makul ölçüde glquake oynayabilen tek standart opengl donanım, ÇOK pahalı bir kart olan bir intergraph realizm. 3dlabs performanslarını önemli ölçüde artırıyor, ancak mevcut sürücülerle hala oynamak için yeterince iyi değil. Şu anki 3dlabs sürücülerinin parlama ve permedia panoları için sürücüleri tam ekrandan çıkarken NT'yi çökertebilir, bu yüzden 3dlabs donanımında glquake çalıştırmayı önermiyorum.
3dfx, glquake'in gereksinim duyduğu her şeyi uygulayan bir opengl32.dll sağladı, ancak tam bir opengl uygulaması değil. Diğer opengl uygulamaları onunla çalışmak pek mümkün değildir, bu yüzden temel olarak bir "glquake sürücüsü" olarak düşünün.
Bu miniGL sürücülerinin doğumuydu. Bunlar, donanımın çoğu OpenGL işlevselliğini uygulayabilecek kadar güçlü hale gelmesiyle sonuçta tam OpenGL uygulamalarına dönüştü. nVidia, eksiksiz bir OpenGL uygulaması sunan ilk kişi oldu. Diğer birçok satıcı mücadele etti, bu nedenle geliştiricilerin Direct3D'yi tercih etmelerinin bir nedeni: daha geniş bir donanım yelpazesinde uyumlu olmaları. Sonunda sadece nVidia ve ATI (şimdi AMD) kaldı ve her ikisi de iyi bir OpenGL uygulamasına sahipti.
OpenGL Yükselen
Böylece sahne ayarlanır: Direct3D ve OpenGL. D3D v3'ün ne kadar kötü olduğunu düşünen gerçekten şaşırtıcı bir hikaye.
OpenGL Mimari İnceleme Kurulu (ARB), OpenGL'nin korunmasından sorumlu olan organizasyondur. Birkaç uzantı yayınlarlar, uzantı deposunu korurlar ve API'nin yeni sürümlerini oluştururlar. ARB, bazı OS yapımcılarının yanı sıra grafik endüstrisi oyuncularının çoğundan oluşan bir komitedir. Apple ve Microsoft çeşitli zamanlarda ARB üyesi olmuştur.
3Dfx Voodoo2 ile çıkıyor. OpenGL'nin daha önce yapamadığı bir şey olan çoklu dokunuş yapabilen ilk donanım bu. 3Dfx OpenGL'e karşı güçlü bir şekilde çalışırken, bir sonraki çoklu dokunan grafik çipinin (TNT1) yapımcıları NVIDIA onu çok sevdi. Böylece ARB bir uzantı yayınladı: GL_ARB_multitexture, çok-yapıya erişime izin verecek.
Bu arada, Direct3D v5 çıkıyor. Şimdi, D3D, bir kedinin kusabileceği bir şey yerine gerçek bir API haline geldi. Sorun? Çoklu dokunma yok.
Hata.
Şimdi, bu kişi olması gerektiği kadar canını yakmayacak, çünkü insanlar çoklu dokunuşları fazla kullanmadılar. Direkt olarak değil. Çoklu dokunma performansı biraz acı çekti ve çoğu durumda çoklu geçişe kıyasla değmezdi. Ve elbette, oyun geliştiricileri, oyunlarının, çoklu dokunuşları olmayan eski donanımlar üzerinde çalışmasını sağlamayı sever, bu yüzden birçok oyun onsuz gönderilir.
D3D böylece bir erteleme verildi.
Zaman geçiyor ve NVIDIA, gelecek iki yıl boyunca grafik kartlarında rekabete son veren GeForce 256'yı (GeForce GT-250 değil; ilk GeForce) kullanıyor. Ana satış noktası, donanımda köşe dönüşümü ve aydınlatma (T&L) yapabilme yeteneğidir. Sadece bu değil, NVIDIA OpenGL'yi o kadar çok sevdi ki, T&L motorları etkin bir şekilde OpenGL idi. Neredeyse tam anlamıyla; Anladığım kadarıyla kayıtlarından bazıları aslında OpenGL numaralandırıcılarını doğrudan değer olarak aldı .
Direct3D v6 çıkıyor. Sonunda çok yüzeyli ama ... donanım yok T&L. OpenGL , 256'dan önce yazılımda kullanılmasına rağmen, her zaman bir T&L boru hattına sahipti. Bu yüzden NVIDIA'nın yazılım uygulamalarını bir donanım çözümüne dönüştürmesi çok kolaydı. D3D v7'ye kadar D3D sonunda donanım T&L desteğine sahip olamazdı.
Shader Şafağı, OpenGL Alacakaranlık
Ardından GeForce 3 çıktı. Ve aynı anda birçok şey oldu.
Microsoft, yine geç kalmayacaklarına karar vermişti. Böylece NVIDIA'nın yaptıklarına bakmak ve sonra gerçeği kopyalamak yerine, kendilerine gitme ve onlarla konuşma gibi şaşırtıcı bir pozisyon aldı. Sonra birbirlerine aşık oldular ve küçük bir konsola sahiplerdi.
Dağınık bir boşanma daha sonra başladı. Ama bu başka bir zaman için.
PC için bunun anlamı, GeForce 3'ün D3D v8 ile aynı anda ortaya çıkmasıydı. GeForce 3'ün D3D 8'in gölgelendiricilerini nasıl etkilediğini görmek de zor değil. Shader Model 1.0'ın piksel gölgelendiricileri, NVIDIA'nın donanımına oldukça özeldi. NVIDIA'nın donanımını soyutlamak için hiçbir girişimde bulunulmadı; SM 1.0, GeForce 3'ün yaptığı her şeydi.
ATI, Radeon 8500 ile performans grafik kartı yarışına atlamaya başladığında bir sorun vardı. 8500'ün piksel işleme hattı NVIDIA'nın eşyalarından daha güçlüydü. Microsoft, temelde "8500 ne yaparsa yap" olan Shader Model 1.1'i yayınladı.
Bu D3D'nin parçası bir başarısızlık gibi gelebilir. Fakat başarısızlık ve başarı derecedir. Ve epik başarısızlık OpenGL-arazi oluyordu.
NVIDIA OpenGL'yi çok severdi, bu yüzden GeForce 3 hit olduğunda bir miktar OpenGL eklentisi yayınladılar. Özel OpenGL uzantıları: yalnızca NVIDIA. Doğal olarak, 8500 ortaya çıktığında, hiçbirini kullanamadı.
En azından D3D 8 ülkesinde, SM 1.0 gölgelendiricinizi ATI donanımında çalıştırabilirsiniz. Elbette, 8500’ün soğukluğundan yararlanmak için yeni gölgelendiriciler yazmanız gerekiyordu, ama en azından kodunuz çalıştı .
OpenGL’de Radeon 8500’de her türlü gölgelendiricinin bulunması için ATI’nin bir dizi OpenGL eklentisi yazması gerekiyordu. Özel OpenGL uzantıları: yalnızca ATI. Yani sadece sahip olmak, bir NVIDIA codepath ve ATI codepath gerekli shaderları hiç.
Şimdi, “OpenGL'in güncel kalmasını sağlayan OpenGL ARB neredeydi?” Diye sorabilirsiniz. Pek çok komitenin sıklıkla son bulduğu yer: aptal olmak.
Bakın, yukarıdaki ARB_multitexture'dan bahsettim, çünkü tüm bunları derinden etkiliyor. ARB (dışarıdan gelenlerin bakış açısından) gölgelendirici fikrinden tamamen uzak durmak istiyor gibiydi. Sabit fonksiyonlu boru hattına yeterince konfigüre edilebilirlik tokatlarsa, gölgelendirici boru hattının kabiliyetine eşit olabileceklerini belirlediler.
Böylece ARB, uzantının ardından uzantıyı yayınladı. İçinde "texture_env" kelimeleri bulunan her bir uzantı, bu yaşlanma tasarımını yama etmeye yönelik bir başka girişimdi. Kayıt defterini kontrol edin: ARB ve EXT uzantıları arasında , bu uzantıların sekiz tanesi vardı . Birçoğu OpenGL çekirdek versiyonlarına yükseltildi.
Microsoft, şu anda ARB'nin bir parçasıydı; D3D 9 isabetinde kaldıkları yerden ayrıldılar. Böylece OpenGL'yi bir şekilde sabote etmek için çalıştıkları tamamen mümkün. Şahsen bu teoriden iki nedenden şüpheliyim. Birincisi, bunu yapmak için diğer ARB üyelerinden yardım almak zorunda kalacaklardı, çünkü her üye yalnızca bir oy alacak. Ve en önemlisi iki, ARB'nin işleri düzeltmek için Microsoft'un yardımına ihtiyacı yoktu. Bunun hakkında daha fazla kanıt göreceğiz.
Sonunda, hem ATI hem de NVIDIA (her iki aktif üye) tarafından tehdit altında olan ARB, sonunda gerçek montaj tarzı gölgelendiriciler sağlayacak kadar başlarını çekti.
Daha aptalca bir şey ister misin?
Donanım T&L Önce OpenGL'nin sahip olduğu bir şey . Bu ilginç. Donanım T&L’den mümkün olan maksimum performansı elde etmek için vertex verilerinizi GPU’da saklamanız gerekir. Sonuçta, aslında vertex verilerinizi kullanmak isteyen GPU'dur.
D3D v7'de Microsoft, Vertex Tamponları kavramını ortaya koydu. Bunlar, köşe verilerini depolamak için GPU belleği alanlarına ayrılır.
OpenGL’nin buna ne zaman denk geldiğini bilmek ister misiniz? Oh, NVIDIA, OpenGL’nin (özel NVIDIA uzantıları olduğu sürece) her şeyin aşığı olması, GeForce 256’nın ilk vuruşunda vertex dizi aralığı uzantısını yayınladı. Fakat ARB ne zaman benzer işlevsellik sağlamaya karar verdi?
İki yıl sonra . Bu, köşe ve parça gölgelendiricileri (D3D dilinde piksel) onayladıktan sonraydı . ARB'nin verteks verilerini GPU hafızasında saklamak için çapraz platform çözümü geliştirmesi bu kadar uzun sürdü. Yine, donanım T&L’nin maksimum performans elde etmek için ihtiyaç duyduğu bir şey .
Hepsini mahvetmek için bir dil
Böylece, OpenGL geliştirme ortamı bir süre kırıldı. Donanımlar arası gölgelendiriciler, donanımlar arası GPU vertex depolaması yokken, D3D kullanıcıları her ikisinden de keyif aldılar. Kötüleşebilir mi?
Sen ... bunu söyleyebilirdin. 3D Labs'a girin .
Kim onlar, sorabilirsiniz? OpenGL'nin asıl katili olduğumu düşündüğüm bir şirketti. Elbette, ARB'nin genel yetersizliği, OpenGL'yi D3D'ye sahip olması gerektiği zaman savunmasız bıraktı. Fakat 3D Labs belki de OpenGL'nin şu andaki piyasa durumu için aklımdaki en büyük sebep. Buna neden olmak için ne yapmış olabilirler?
OpenGL Gölgelendirme Dilini tasarladılar.
Bakın, 3D Labs ölmekte olan bir şirketti. Pahalı GPU'ları, NVIDIA'nın iş istasyonu pazarındaki artan baskısıyla marjinalleştirildi. NVIDIA'nın aksine, 3D Labs ana pazarda herhangi bir varlığa sahip değildi; NVIDIA kazandıysa, öldüler.
Onlar yaptı.
Bu nedenle, ürünlerini istemeyen bir dünyada alakalı kalmak için, 3D Labs, "OpenGL 2.0" olarak adlandırdıkları bir şey için sunumlar düzenleyen bir Oyun Geliştirici Konferansı'na geldi. Bu OpenGL API'sinin eksiksiz, sıfırdan bir yeniden yazımı olacaktır. Ve bu mantıklı; OpenGL’nin API’sinde o sırada çok fazla sıkıntı yaşandı (not: o kıtlık hala var). Sadece doku yükleme ve ciltlemenin nasıl çalıştığına bakın; bu yarı kemerli.
Tekliflerinin bir kısmı gölgelendirme diliydi. Doğal olarak. Ancak, mevcut platformlar arası ARB uzantılarının aksine, gölgelendirme dili "üst düzey" idi (C, gölgelendirme dili için üst düzeydir. Evet, gerçekten).
Şimdi, Microsoft kendi yüksek seviyeli gölgeleme dili üzerinde çalışıyordu. Bunlar, Microsoft’un tüm kolektif hayallerinde, “Üst Düzey Gölgelendirme Dili” (HLSL) olarak adlandırıldı. Fakat onların dilleri temelde farklı bir yaklaşımdı.
3D Laboratuarlarının gölgelendirici diliyle ilgili en büyük sorun, yerleşik olmasıydı. Bakın, HLSL Microsoft'un tanımladığı bir dildi. Bunun için bir derleyici yayınladılar ve D3D'ye besleyeceğiniz Shader Model 2.0 (veya daha yeni shader modelleri) montaj kodunu oluşturdular. D3D v9 günlerinde, HLSL hiçbir zaman doğrudan D3D'ye dokunmamıştır. Güzel bir soyutlama oldu, ama tamamen isteğe bağlıydı. Ve bir geliştirici her zaman derleyicinin arkasına geçme ve çıktıyı maksimum performans için ince ayar yapma fırsatını buldu.
3D Labs dilinin hiçbiri yoktu . Sürücüye C benzeri bir dil verdin ve gölgelendiriciyi üretti. Hikayenin sonu. Bir montaj gölgelendiricisi değil, başka bir şeyi beslediğiniz bir şey değil. Bir gölgelendiriciyi temsil eden gerçek OpenGL nesnesi.
Bunun anlamı, OpenGL kullanıcılarının derleme benzeri dilleri derlemeye başlayan geliştiricilere açıktır. Derleyici hataları yeni vaftiz OpenGL Gölgelendirme Dili'nde (GLSL) yaygınlaştı . Daha da kötüsü, birden fazla platformda doğru şekilde derlemek için bir gölgelendirici bulmayı başardıysanız (ortalama bir başarı yok), yine de günün en iyi duruma getiricilerine maruz kaldınız . Olabildiğince optimal değildi.
Bu GLSL'deki en büyük kusur olsa da, tek kusur değildi. Çok uzak .
D3D’de ve OpenGL’deki eski montaj dillerinde, tepe ve parça (piksel) gölgelendiricileri karıştırıp eşleştirebilirsiniz. Aynı arabirimle iletişim kurdukları sürece, herhangi bir uyumlu gölgelendirici ile herhangi bir köşe gölgelendiriciyi kullanabilirsiniz. Üstelik kabul edebilecekleri uyumsuzluk seviyeleri bile vardı; Köşe gölgelendiricisi, parça gölgelendiricinin okumadığı bir çıktı yazabilir. Ve bunun gibi.
GLSL hiçbirinde yoktu. Vertex ve fragman gölgelendiricileri, 3D Labs'ın "program nesnesi" olarak adlandırdığı şeye birleştirildi. Dolayısıyla, köşe ve parça programlarını paylaşmak istiyorsanız, birden fazla program nesnesi oluşturmanız gerekiyordu. Bu da ikinci en büyük soruna neden oldu.
Bakın, 3D Labs zeki olduklarını düşünüyordu. GLSL'nin derleme modelini C / C ++ 'a dayandırdılar. Bir .c veya .cpp alıp bir nesne dosyasına derleyin. Sonra bir veya daha fazla nesne dosyasını alıp bir programa bağlayın. Demek GLSL böyle işler: gölgelendiricinizi (tepe noktası veya parçası) gölgelendirici nesnesine derlersiniz. Sonra bu gölgelendirici nesnelerini bir program nesnesine koyar ve gerçek programınızı oluşturmak için bunları birbirine bağlarsınız.
Bu, ana gölgelendiricilerin çağırabileceği fazladan kod içeren “kütüphane” gölgelendiricileri gibi potansiyel fikirlerin olmasına izin verirken, uygulamada kastedilen, gölgelendiricilerin iki kez derlenmesiydi . Derleme aşamasında bir kez ve bir kez bağlama aşamasında. Özellikle NVIDIA'nın derleyicisinin, derlemeyi iki kez çalıştırmasıyla biliniyordu. Bir çeşit nesne kodu aracı üretmedi; sadece bir kez derledi ve cevabı attı, sonra bağlantı anında tekrar derledi.
Köşe gölgelendiricinizi iki farklı parça gölgelendiriciye bağlamak isteseniz bile, D3D'den çok daha fazla derleme yapmanız gerekir. Özellikle C benzeri bir dilin derlenmesi programın yürütülmesinin başlangıcında değil, tamamen çevrimdışı yapıldığı için.
GLSL ile ilgili başka sorunlar da vardı. ARB nihayetinde dili onayladığı ve birleştirdiği için suçlamayı 3D Labs'a koymak belki de yanlış gözüküyor (ancak "OpenGL 2.0" girişiminin başka hiçbir şeyi yoktu). Ama bu onların fikriydi.
Ve işte gerçekten üzücü olan kısım: 3D Labs haklıydı (çoğunlukla). GLSL, HLSL'nin olduğu gibi vektör tabanlı bir gölgeleme dili değildir. Bunun nedeni, 3D Laboratuarların donanımının skaler donanım (modern NVIDIA donanımına benzer) olmasına rağmen, pek çok donanım üreticisinin donanımlarıyla birlikte gittiği yöndeydi.
"Yüksek seviye" bir dil için derleme çevrimiçi bir modelle gitmeye haklıydılar. D3D buna nihayetinde bile geçti.
Sorun, 3D Laboratuarlarının yanlış zamanda doğru olmasıydı . Ve geleceğe dönük olarak çalışırken, çok erken geleceğini çağırmak çalışırken, onlar kenara hediye . OpenGL'nin her zaman T&L işlevselliği olasılığına sahip olduğuna benziyor. Bunun dışında OpenGL'nin T&L boru hattı donanım T&L'den önce hala faydalıyken , GLSL dünyayı yakalamadan önce bir sorumluluktu.
GLSL şimdi iyi bir dil . Ama şimdilik? O korkunçtu. Ve OpenGL bunun için acı çekti.
Apotheosis'e Doğru Düşmek
3D Laboratuarlarının ölümcül darbeye çarptığını iddia ederken, tabutun içindeki son çiviyi süren ARB'nin kendisidir.
Bu duymuş olabileceğiniz bir hikaye. OpenGL 2.1, OpenGL bir sorunla karşılaştı. Çok fazla eski mirası vardı . API artık kullanımı kolay değildi. Her şeyi yapmanın 5 yolu vardı ve en hızlısı olan hiçbir fikir yoktu. Basit öğreticilerle OpenGL'yi "öğrenebilirsiniz", ancak size gerçek performans ve grafiksel güç sağlayan OpenGL API'sini gerçekten öğrenmediniz.
Böylece ARB, OpenGL’nin bir başka icatını tekrar denemeye karar verdi. Bu, 3D Labs'in "OpenGL 2.0" ına benziyordu, ancak daha iyiydi çünkü ARB onun arkasındaydı. Buna "Uzun Peak" dediler.
API'yi geliştirmek için biraz zaman ayırmanın nesi kötü? Bu kötüydü çünkü Microsoft kendilerini savunmasız bırakmıştı. Bakın, bu Vista geçiş zamanındaydı.
Vista ile Microsoft, ekran sürücülerinde ihtiyaç duyulan bazı değişiklikleri yapmaya karar verdi. Sürücüleri, grafik belleği sanallaştırması ve diğer birçok şey için işletim sistemine göndermeye zorladılar.
Biri bunun aslını ya da gerçekten mümkün olup olmadığını tartışabilirken, gerçek şu ki: Microsoft, D3D 10'un yalnızca Vista (ve üstü) olduğunu kabul etti. D3D 10 yeteneğine sahip bir donanıma sahip olsanız bile , Vista kullanmadan D3D 10 uygulamalarını çalıştıramazsınız.
Ayrıca Vista'yı da hatırlayabilirsiniz ... um, sadece işe yaramadığını söyleyelim. Bu yüzden düşük performans gösteren bir işletim sisteminiz, yalnızca bu işletim sistemiyle çalışan yeni bir API'niz ve bu API ve işletim sisteminin önceki nesilden daha hızlı bir şey yapması için gereken yeni bir donanım nesliniz vardı .
Ancak, geliştiriciler olabilir OpenGL aracılığıyla D3D 10 sınıf özelliklerine erişmek. Eğer ARB Longs Zirvesi'nde çalışmakla meşgul olmasaydı yapabilirlerdi.
Temel olarak, ARB API'yi daha iyi hale getirmek için iyi bir buçuk yıl süren bir buçuk yıl çalıştı. OpenGL 3.0 gerçekten ortaya çıktığında, Vista'nın kullanımı benimsendi, Win7 Vista'yı geride bırakmak için köşe başındaydı ve oyun geliştiricilerin çoğu D3D-10 sınıfı özellikleri zaten umursamadılar. Sonuçta, D3D 10 donanımı D3D 9 uygulamalarını iyi idare etti. Bilgisayardan konsola bağlantı noktalarının yükselmesiyle (veya gemiyi konsol geliştirmeye atlayan PC geliştiricileri. Seçiminizi yapın) geliştiricilerin D3D 10 sınıfı özelliklere ihtiyaçları yoktu.
Şimdi, eğer geliştiriciler WinXP makinelerinde OpenGL aracılığıyla daha önce bu özelliklere erişebilseydi, o zaman OpenGL geliştirmesi kolda çok ihtiyaç duyulan bir çekimi almış olabilir. Ancak ARB fırsatlarını kaçırdı. Ve en kötüsünü bilmek ister misin?
İki kıymetli yıl boyunca API'yi sıfırdan yeniden kurmaya çalışırken harcamalarına rağmen ... yine de başarısız oldular ve statükoya geri döndüler (değer kaybı mekanizması hariç).
Dolayısıyla, ARB sadece önemli bir fırsat penceresini kaçırmakla kalmadı, aynı zamanda onları bu şansı kaçıran görevi bile yapmadılar. Her yerde epik destansı bir başarısızlık var.
Ve bu OpenGL ve Direct3D'nin hikayesi. Kaçırılmış fırsatların, kaba aptallığın, kasıtlı körlüğün ve basit aptallığın öyküsü.