it-swarm.asia

Oyun geliştiricileri neden Windows'u tercih ediyor?

OpenGL çapraz platform olsa bile DirectX'in OpenGL'den daha kolay mı yoksa daha mı iyi olduğu? Neden Windows için olduğu gibi Linux için gerçek güçlü oyunlar görmüyoruz?

396
M.Sameer

Buradaki cevapların çoğu gerçekten, gerçekten çok iyi. Ancak OpenGL ve Direct3D (D3D) sorunu muhtemelen ele alınmalıdır. Ve bu ... bir tarih dersi gerektirir.

Ve başlamadan önce OpenGL hakkında benden çok daha fazla şey biliyorum Direct3D . Hayatımda hiç bir D3D kodu satırı yazmadım ve OpenGL hakkında öğreticiler yazdım. Söylemek istediğim bir yanlılık sorunu değil. Bu sadece bir tarih meselesidir.

Çatışmanın Doğuşu

Bir gün, 90'ların başında, Microsoft etrafına baktı. SNES ve Sega Genesis 'nin harika olduğunu, çok sayıda aksiyon oyunu ve benzeri çalıştığını gördüler. Ve gördüler DOS . Geliştiriciler konsol oyunları gibi DOS oyunlarını kodladılar: doğrudan metale. Bununla birlikte, SNES oyunu yapan bir geliştiricinin kullanıcının hangi donanıma sahip olacağını bildiği konsolların aksine, DOS geliştiricileri olası birden çok yapılandırma için yazmak zorunda kalmıştır. Ve bu göründüğünden çok daha zor.

Ve Microsoft'un daha büyük bir sorunu vardı: Windows. Bakın, Windows, geliştiricilerin ne isterse yapmasına izin veren DOS'un aksine, donanıma sahip olmak istedi. Uygulamalar arasında işbirliği yapabilmek için donanıma sahip olmak gereklidir. İşbirliği tam olarak oyun geliştiricilerin nefret çünkü müthiş olmak için kullanabilecekleri değerli donanım kaynaklarını kaplıyor.

Windows'ta oyun geliştirmeyi teşvik etmek için Microsoft, düşük seviyeli, yavaşlamadan Windows üzerinde çalışan ve hepsinden önemlisi çapraz donanım olan tek tip bir API'ya ihtiyaç duyuyordu. Tüm grafik, 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ı. Bkz. DirectX'in grafik bileşeni olan DirectDraw, yalnızca 2D grafiklerle ilgiliydi: grafik belleğinin tahsisi ve belleğin farklı tahsisli bölümleri arasında bit blidleri yapılması.

Bu yüzden Microsoft biraz ara katman yazılımı satın aldı ve Direct3D Sürüm 3'e dönüştürdü. evrensel olarak iptal edildi. Ve iyi bir sebeple; D3D v3 koduna bakmak, Antlaşma Gemisi'ne bakmak gibidir.

Id Software'deki eski John Carmack, o çöp kutusuna bir göz attı ve "Lanet olsun!" Dedi. ve başka bir API'ye yazmaya karar verdik: OpenGL.

Microsoft'un çok başlı canavarın başka bir kısmı, Windows için bir OpenGL uygulaması üzerinde SGI ile çalışmakla meşguldü. Buradaki fikir, tipik GL uygulamalar: iş istasyonu uygulamaları. CAD araçlar, modelleme, bu tür şeyler) mahkemeleri geliştiricilerdi. Bu öncelikle bir Windows NT şeydi, ancak Microsoft bunu Win95'e de eklemeye karar verdi.

İş istasyonu geliştiricilerini Windows'a ikna etmenin bir yolu olarak Microsoft, bu yeni çıkmış 3D grafik kartlarına erişerek onlara rüşvet vermeye karar verdi. Microsoft, Yüklenebilir İstemci Sürücüsü protokolünü uygulamıştır: grafik kartı üreticisi, Microsoft'un yazılım OpenGL uygulamasını donanım tabanlı bir kodla geçersiz kılabilir. Kod, varsa otomatik olarak bir donanım OpenGL uygulaması kullanabilir.

İ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 benioku dosyasından okuyabileceğ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 oynama kabul edilemez. Herhangi bir yazılım öykünme yolundan geçmesi gerekiyorsa, performans muhtemelen saniyede bir karenin altında olur.

Şu anda (mart '97), makul bir şekilde glquake oynayabilen tek standart opengl donanımı, ÇOK pahalı bir kart olan bir intergraph realizmidir. 3dlabs performanslarını önemli ölçüde artırıyor, ancak mevcut sürücülerle hala oynamak için yeterince iyi değil. Glint ve permedia panoları için mevcut 3dlabs sürücülerinden bazıları, tam ekran çalışmasından çıkarken NT'yi kilitleyebilir, bu nedenle 3dlabs donanımında glquake çalıştırılmasını önermiyorum.

3dfx, glquake'in ihtiyaç duyduğu her şeyi uygulayan bir opengl32.dll sağlamıştır, ancak tam bir opengl uygulaması değildir. Diğer opengl uygulamalarının onunla çalışması pek olası değildir, bu yüzden temelde bir "glquake sürücüsü" olarak düşünün.

Bu miniGL sürücülerinin doğuşuydu. Donanım, çoğu OpenGL işlevselliğini donanımda uygulamak için yeterince güçlü hale geldiğinden, bunlar sonunda tam OpenGL uygulamalarına dönüştü. nVidia, tam bir OpenGL uygulaması sunan ilk kişi oldu. Diğer birçok satıcı mücadele etti, bu da geliştiricilerin Direct3D'yi tercih etmelerinin bir nedeni: daha geniş bir donanım yelpazesinde uyumluydılar. Sonunda sadece nVidia ve ATI (şimdi AMD) kaldı ve her ikisinin de iyi bir OpenGL uygulaması vardı.

OpenGL Yükselişi

Böylece sahne ayarlanır: Direct3D ve OpenGL. D3D v3'ün ne kadar kötü olduğunu göz önünde bulundurarak gerçekten inanılmaz bir hikaye.

OpenGL Mimari İnceleme Kurulu (ARB), OpenGL'nin bakımından sorumlu kuruluştur. Bazı uzantılar yayınlar, uzantı deposunu korurlar ve API'nın yeni sürümlerini oluştururlar. ARB, grafik endüstrisi oyuncularının çoğunun yanı sıra bazı işletim sistemi üreticilerinden oluşan bir komitedir. Apple ve Microsoft çeşitli zamanlarda ARB'ye üye oldular.

3Dfx, Voodoo2 ile çıkıyor. Bu, OpenGL'nin daha önce yapamadığı bir şey olan çoklu enjeksiyon yapabilen ilk donanımdır. 3Dfx, OpenGL'ye karşı güçlüyken, bir sonraki çok çekirdekli grafik yongasının (TNT1) yapımcıları NVIDIA onu sevdi. Böylece ARB, çoklu kurgulamaya erişime izin verecek bir GL_ARB_multitexture uzantısını yayınladı.

Bu arada Direct3D v5 çıkıyor. Şimdi, D3D bir kedinin kusabileceği bir şey yerine, gerçek bir [~ # ~] api [~ # ~] haline geldi. Sorun? Çoklu çekim yok.

Hata.

Şimdi, kişi olması gerektiği kadar acıtmayacaktı, çünkü insanlar çoklu-çok-resimleme kullanmadılar. Dolaylı. Çoklu kurgulama performansı biraz zarar verir ve birçok durumda çoklu geçişe kıyasla buna değmezdi. Ve elbette, oyun geliştiricileri, oyunlarının çok katlı olmayan eski bir donanımda çalışmasını sağlamayı severler, bu yüzden birçok oyun onsuz gönderilir.

Böylece D3D'ye bir reprieve verildi.

Zaman geçiyor ve NVIDIA, GeForce 256'yı (GeForce GT-250 değil; ilk GeForce değil) dağıtıyor ve önümüzdeki iki yıl için grafik kartlarında neredeyse biten bir rekabet. 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ı etkili bir şekilde öyleydi OpenGL. Kelimenin tam anlamıyla; anladığım kadarıyla, bazı kayıtları aslında OpenGL sayımcıları doğrudan değer olarak aldı.

Direct3D v6 çıkıyor. Sonunda çoklu doku ama donanım yok T&L. OpenGL, yazılımda uygulanmadan 256'dan önce olmasına rağmen her zaman bir T&L boru hattına sahipti. Bu nedenle NVIDIA'nın yazılım uygulamalarını bir donanım çözümüne dönüştürmesi çok kolay oldu. D3D sonunda donanım T&L desteğine sahip oluncaya kadar D3D v7'ye kadar olmazdı.

Gölgelendiricilerin Şafağı, Alacakaranlık OpenGL

Sonra GeForce 3 çıktı. Ve aynı anda birçok şey oldu.

Microsoft, tekrar geç kalmayacaklarına karar vermişti. Bu yüzden NVIDIA'nın ne yaptığını görmek ve daha sonra kopyalamak yerine, onlara gitmenin ve onlarla konuşmanın şaşırtıcı pozisyonunu aldılar. Ve sonra aşık oldular ve birlikte küçük bir konsolları vardı.

Daha sonra dağınık bir boşanma meydana geldi. Ama bu başka bir zaman için.

Bunun PC için anlamı, GeForce 3'ün D3D v8 ile aynı anda çıkmasıydı. GeForce 3'ün D3D 8'in gölgelendiricilerini nasıl etkilediğini görmek zor değil. Shader Model 1.0'ın piksel gölgelendiricileri son derece NVIDIA donanımına özeldi. NVIDIA'nın donanımını soyutlama girişimi olmadı; SM 1.0, GeForce 3'ün yaptığı şeydi.

ATI, Radeon 8500 ile performans grafik kartı yarışına atlamaya başladığında, bir sorun vardı. 8500'ün piksel işleme boru hattı NVIDIA'nınkinden daha güçlüydü. Böylece Microsoft, temel olarak "8500 ne yaparsa yapsın" olan Shader Model 1.1'i yayınladı.

Bu D3D'nin bir parçası gibi görünebilir. Ancak başarısızlık ve başarı derece meselesidir. Ve epik OpenGL ülkesinde başarısızlık yaşanıyordu.

NVIDIA OpenGL'yi sevdi, bu yüzden GeForce 3 vurulduğunda bir dizi OpenGL uzantısı yayınladılar. Tescilli OpenGL uzantıları: yalnızca NVIDIA. Doğal olarak, 8500 ortaya çıktığında hiçbirini kullanamadı.

En azından D3D 8 arazisinde SM 1.0 gölgelendiricilerinizi ATI donanımında çalıştırabilirsiniz. Tabii, 8500 serinlik yararlanmak için yeni gölgelendiriciler yazmak zorunda, ama en azından kodu çalıştı.

OpenGL'de Radeon 8500'de any tür gölgelendiricilere sahip olmak için ATI'nın bir dizi OpenGL uzantısı yazması gerekiyordu. Tescilli OpenGL uzantıları: yalnızca ATI. Bu yüzden, sadece gölgelendiriciler bir NVIDIA kodyoluna ve bir ATI kodyoluna ihtiyacınız vardı.

Şimdi, "İşi OpenGL'yi güncel tutmak olan OpenGL ARB neredeydi?" Birçok komitenin sıklıkla sonuçlandığı yerlerde: aptal olmak.

Bakın, yukarıda ARB_multitexture'dan bahsettim çünkü tüm bunları derinden etkiliyor. ARB (dışarıdan bir bakış açısından) gölgelendiriciler fikrinden tamamen kaçınmak istiyor gibiydi. Sabit işlevli boru hattına yeterli yapılandırılabilirliği tokatlarlarsa, bir gölgelendirici boru hattının yeteneğine eşit olabileceklerini anladılar.

Böylece ARB, uzantıdan sonra uzantı yayınladı. İçinde "texture_env" kelimesi bulunan her uzantı, bu yaşlanma tasarımını düzeltmek için başka bir girişimdi. Kayıt defterini kontrol edin: ARB ve EXT uzantıları arasında sekiz bu uzantılar yapıldı. Birçoğu OpenGL çekirdek sürümlerine yükseltildi.

Microsoft şu anda ARB'nin bir parçasıydı; D3D 9 isabet ettikleri zaman ayrıldılar. Bu nedenle, bir şekilde Sabotaj OpenGL için çalışıyor olmaları tamamen mümkündür. Ben şahsen bu teoriden iki nedenden dolayı şüpheliyim. Birincisi, her üye sadece bir oy aldığı için diğer ARB üyelerinden yardım almak zorunda kalacaklardı. Ve en önemlisi, ARB'nin işleri mahvetmek 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'nın (her iki aktif üye) tehdidi altında olan ARB, sonunda gerçek Meclis tarzı gölgelendiriciler sağlayacak kadar uzun süre dışarı çıktı.

Daha aptalca bir şey ister misin?

Donanım T&L. OpenGL'de bir şey önce. İlginç. Donanımsal T & L'den mümkün olan en yüksek performansı elde etmek için tepe verilerinizi GPU'da depolamanız gerekir. Sonuçta, köşe verilerinizi kullanmak isteyen GPU'dur.

D3D v7'de Microsoft, Vertex Buffers kavramını tanıttı. Bunlar, köşe verilerinin depolanması için GPU belleğinin ayrılmış alanlarıdır.

OpenGL bunun eşdeğerlerini ne zaman aldığını bilmek ister misiniz? Oh, NVIDIA, OpenGL (tescilli NVIDIA uzantıları oldukları sürece) her şeyin sevgilisi olan GeForce 256 ilk kez vurulduğunda köşe dizisi aralığı uzantısını yayınladı. Ancak ARB benzer işlevleri sunmaya ne zaman karar verdi?

İki yıl sonra. Bu after köşe ve parça gölgelendiricileri (D3D dilinde piksel) onayladılar. Köşe verilerinin GPU belleğinde depolanması için bir platformlar arası çözüm geliştirmesi ARB'nin bu kadar sürdü. Yine, maksimum performans elde etmek için donanım T&L ihtiyaç duyuyor bir şey.

Hepsini Mahvedecek Bir Dil

Bu nedenle, OpenGL geliştirme ortamı bir süre kırıldı. Çapraz donanım gölgelendiricileri, çapraz donanım GPU köşe depolama alanı yokken, D3D kullanıcıları her ikisinden de keyif aldılar. Daha kötüye gidebilir mi?

Sen ... bunu söyleyebilirsin. D Labs girin.

Kim bunlar, sorabilirsiniz? Onlar, OpenGL'nin gerçek katilleri olduğunu düşündüğüm geçersiz bir şirket. Elbette, ARB'nin genel beceriksizliği, OpenGL'yi D3D'ye sahip olması gerektiğinde savunmasız hale getirdi. Ancak 3D Labs, OpenGL'nin mevcut piyasa durumu için belki de aklıma gelen en büyük neden. Buna sebep olmak için ne yapabilirlerdi?

OpenGL Gölgelendirme Dilini tasarladılar.

3D Labs ölmekte olan bir şirketti. Pahalı GPU'ları, NVIDIA'nın iş istasyonu piyasası üzerindeki artan baskısıyla marjinalleştiriliyordu. Ve NVIDIA'nın aksine, 3D Labs'ın genel pazarda herhangi bir varlığı yoktu; NVIDIA kazanırsa öldüler.

Hangi yaptılar.

Bu yüzden, 3D Labs, ürünlerini istemeyen bir dünyada alakalı kalmak amacıyla, "OpenGL 2.0" adını verdikleri bir şey için sunumlar içeren bir Oyun Geliştirici Konferansı'na katıldı. Bu, OpenGL API'sının tamamen sıfırdan yeniden yazılması olacaktır. Ve bu mantıklı; o sırada OpenGL API'sinde bir lot hamilelik vardı (not: bu hamilelik hala var). Sadece doku yükleme ve bağlama işlemlerinin nasıl yapıldığına bakın; yarı gizlidir.

Tekliflerinin bir kısmı gölgelendirme diliydi. Doğal olarak. Ancak, mevcut platformlar arası ARB uzantılarının aksine, gölgelendirme dili "yüksek düzey" idi (C, gölgelendirme dili için üst düzeydir. Evet, gerçekten).

Microsoft artık kendi üst düzey gölgelendirme dillerinde çalışıyordu. Bunlar, Microsoft'un tüm kolektif hayal gücünde, ... Üst Düzey Gölgelendirme Dili (HLSL) olarak adlandırdılar. Ancak bu diller dillere temelden farklı bir yaklaşımdı.

3D Labs'ın gölgelendirici dili ile ilgili en büyük sorun, yerleşik olmasıydı. Bkz. 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 gölgelendirici modelleri) Montaj kodunu oluşturdular. D3D v9 günlerinde, HLSL'ye asla doğrudan D3D dokunmadı. Güzel bir soyutlama idi, ama tamamen isteğe bağlıydı. Ve bir geliştirici her zaman derleyicinin arkasına gitme ve maksimum performans için çıktıyı değiştirme fırsatı buldu.

3D Labs dili bunun yok diline sahipti. Sürücüye C benzeri bir dil verdiniz ve bir gölgelendirici üretti. Hikayenin sonu. Montaj gölgelendirici değil, başka bir şey beslediğiniz bir şey değil. Gölgelendiriciyi temsil eden gerçek OpenGL nesnesi.

Bunun anlamı, OpenGL kullanıcılarının Meclis benzeri dillerin derlenmesini sağlayan geliştiricilerin kaprislerine açık olmasıydı. Derleyici hataları yeni varolan OpenGL Gölgeleme Dili'nde (GLSL) yaygın koştu. Daha da kötüsü, bir gölgelendiriciyi birden çok platformda doğru bir şekilde derlemeyi başardıysanız (ortalama bir başarı yok), günün optimizers gününe maruz kaldınız. Bunlar olabildiğince optimal değildi.

Bu GLSL'deki en büyük kusur olsa da, tek kusur değildi. uzak.

D3D'de ve OpenGL'deki eski Montaj dillerinde köşe ve parça (piksel) gölgelendiricileri karıştırabilir ve eşleştirebilirsiniz. Aynı arayüzle iletişim kurdukları sürece, herhangi bir uyumlu gölgelendiriciyle herhangi bir tepe gölgelendiricisini kullanabilirsiniz. Ve kabul edebilecekleri uyumsuzluk seviyeleri bile vardı; köşe gölgelendirici, parça gölgelendiricinin okumadığı bir çıktı yazabilir. Ve böylece.

GLSL bunlardan hiçbirine sahip değildi. Köşe ve parça gölgelendiriciler, 3D Labs'in "program nesnesi" olarak adlandırdığı şeye birleştirildi. Köşe ve parça programlarını paylaşmak istiyorsanız, birden fazla program nesnesi oluşturmanız gerekiyordu. Bu da ikinci büyük soruna neden oldu.

3D Labs akıllı olduklarını düşündü. GLSL'nin derleme modelini C/C++ üzerine dayandırdılar. Bir .c veya .cpp dosyası alıp bir nesne dosyasına derlersiniz. Sonra bir veya daha fazla nesne dosyası alıp bunları bir programa bağlarsınız. GLSL bu şekilde derlenir: gölgelendiricinizi (tepe noktası veya parça) gölgelendirici nesnesine derlersiniz. Sonra bu gölgelendirici nesnelerini bir program nesnesine koyarsınız ve gerçek programınızı oluşturmak için bunları birbirine bağlarsınız.

Bu, ana gölgelendiricilerin arayabileceği ekstra kod içeren "kütüphane" gölgelendiricilerine sahip olma gibi potansiyel harika fikirlere izin verirken, uygulamada kastedilen, gölgelendiricilerin derlendiğidir iki kez. Bir kez derleme aşamasında ve bir kez bağlama aşamasında. Özellikle NVIDIA derleyicisinin temel olarak derlemeyi iki kez çalıştırdığı biliniyordu. Bir tür nesne kodu aracısı üretmedi; sadece bir kez derledi ve cevabı attı, sonra bağlantı zamanında tekrar derledi.

Köşe gölgelendiricinizi iki farklı fragman gölgelendiricisine 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 çevrimdışı yapıldığından.

GLSL ile ilgili başka sorunlar vardı. Belki de 3D Labs'ı suçlamak yanlış görünüyor, çünkü ARB sonunda dili onayladı ve dahil etti (ancak "OpenGL 2.0" inisiyatifinden başka bir şey yok). Ama bu onların fikriydi.

Ve işte gerçekten üzücü kısım: 3D Labs right (çoğunlukla). GLSL, HLSL'nin o zamanki gibi vektör tabanlı bir gölgeleme dili değildir. Bunun nedeni, 3D Labs'in donanımının skaler donanım olması (modern NVIDIA donanımına benzer), ancak sonuçta birçok donanım üreticisinin donanımlarıyla gittiği yönde haklıydı.

"Üst düzey" bir dil için çevrimiçi derleme modeliyle gitmeye haklıydılar. D3D sonunda buna geçti.

Sorun, 3D Laboratuarlarının yanlış zaman olmasıydı. Ve geleceği çok erken çağırmaya çalışırken, geleceğe dönük olmaya çalışırken, şimdiki bir kenara bırakırlar. OpenGL'nin her zaman T&L işlevselliği olasılığına sahip olduğuna benzer. OpenGL'nin T&L boru hattının donanım T&L'sinden önce hala yararlı olması, GLSL ise dünyayı yakalamadan önce bir sorumluluktu.

GLSL iyi bir dildir şimdi. Ama şimdilik? O korkunçtu. Ve OpenGL bunun için acı çekti.

Apotheosis'e Düşmek

3D Labs'ın ölümcül darbeyi vurduğunu iddia ederken, tabuttaki son çiviyi süren ARB'nin kendisiydi.

Bu duymuş olabileceğiniz bir hikaye. OpenGL 2.1'e gelindiğinde, OpenGL bir sorunla karşılaşıyordu. Bir lot miras bıraktı. API'nın kullanımı artık kolay değildi. Bir şeyler yapmanın 5 yolu vardı ve hangisinin en hızlı olduğunu bilmiyordum. OpenGL'yi basit öğreticilerle "öğrenebilirsiniz", ancak size gerçek performans ve grafik gücü veren OpenGL API'sini gerçekten öğrenmediniz.

Böylece ARB, OpenGL'nin yeniden icat edilmesine karar verdi. Bu, 3D Labs'in "OpenGL 2.0" sürümüne benziyordu, ancak ARB'nin arkasında olduğu için daha iyiydi. "Longs Peak" dediler.

API'yı geliştirmek için biraz zaman ayırmanın ne kadar kötü yanı? Bu kötüydü çünkü Microsoft kendilerini savunmasız bırakmıştı. Bkz., this Vista geçişi sırasındaydı.

Vista ile Microsoft, ekran sürücülerinde çok gerekli bazı değişiklikler yapmaya karar verdi. Sürücüleri, grafik belleği sanallaştırma ve diğer çeşitli şeyler için işletim sistemine göndermeye zorladılar.

Biri bunun esasını veya bunun gerçekten mümkün olup olmadığını tartışabilirken, gerçek şu ki kalır: Microsoft, D3D 10'u yalnızca Vista (ve üstü) olarak kabul etti. D3D 10'un yetenekli donanımına sahip olsanız bile, Vista'yı çalıştırmadan da D3D 10 uygulamalarını çalıştıramazsınız.

Vista'yı da hatırlayabilirsiniz ... hmm, diyelim ki iyi sonuç vermedi. Böylece, düşük performanslı bir işletim sisteminiz, yalnızca bu işletim sisteminde çalışan yeni bir API ve gerekli bir önceki nesilden daha hızlı bir şey yapmak için API ve işletim sisteminin yeni bir donanımı vardı.

Ancak, geliştiriciler olabilir D3D 10 sınıfı özelliklere OpenGL aracılığıyla erişin. ARB, Longs Peak üzerinde çalışmakla meşgul olmasaydı yapabilirlerdi.

Temel olarak, ARB, API'yi daha iyi hale getirmek için iyi bir buçuk ila iki yıl değerinde çalışma yaptı. OpenGL 3.0 gerçekten ortaya çıktığında, Vista'nın benimsenmesi başladı, Win7 Vista'yı arkalarına koymak için köşede idi ve oyun geliştiricilerinin çoğu yine de D3D-10 sınıfı özelliklerini umursamadı. Sonuçta, D3D 10 donanımı D3D 9 uygulamalarını gayet iyi çalıştırdı. Ve PC'den 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ı özelliklerine ihtiyacı yoktu.

Şimdi, geliştiriciler WinXP makinelerinde OpenGL aracılığıyla daha önce bu özelliklere erişebildiyse, OpenGL geliştirme kolda çok ihtiyaç duyulan bir çekim almış olabilir. Ancak ARB fırsatlarını kaçırdı. Ve en kötü yanı bilmek ister misin?

API'yi sıfırdan yeniden oluşturmaya çalışan iki değerli yıl geçirmesine rağmen ... hala başarısız oldu ve sadece statükoya geri döndü (kullanımdan kaldırma mekanizması hariç).

Bu yüzden ARB sadece bir önemli fırsat penceresini kaçırmakla kalmadı, aynı zamanda bu şansı kaçırmasına neden olan görevi bile yapmadılar. Her yerde epik bir başarısızlık.

Ve bu OpenGL ve Direct3D'nin hikayesi. Kaçırılmış fırsatlar, iğrenç aptallık, kasıtlı körlük ve basit aptallık hikayesi.

1154
Nicol Bolas

Soru, 'oyun editörleri' değil 'oyun geliştiricileri' olduğunda, herkesin kullanıcı tabanına odaklanmasını garip buldum.

Benim için, bir geliştirici olarak, Linux kanlı bir karmaşa. Çok sayıda sürüm, masaüstü yöneticisi, UI kitleri, vb ... Çalışmamı açık kaynak olarak dağıtmak istemezsem, kullanıcının yeniden derlemeye (denemeye) izin verir, böylece benzersiz paketler, kütüphaneler ve ayarları, bu bir kabus!

Öte yandan, Microsoft (çoğu zaman) inanılmaz bir geriye dönük uyumluluk ve platform kararlılığı sağlar. Windows XP, Vista ve 7, 32 ve 64 bit lezzetlerini çalıştıran bilgisayarlar, uygun DX veya VC yeniden dağıtılabilirler kurulmadan), örneğin bir kapalı kaynak yükleyicili tüm makineleri hedeflemek mümkündür. vb...

Son bir şey, İNTERNET DURDURMASINDA HERKES LÜTFEN OPENGL VE DIRECTX'I KARŞILAŞTIRIN! Ya Direct3D ile OpenGL'yi karşılaştırın ya da bunu yapmayın . DirectX, OpenGL'nin girmediği giriş desteği, ses desteği, film oynatma vb. Sağlar.

133
jv42

Çünkü gezegende Linux ve Mac'ten daha fazla Windows kullanıcısı var. Gerçek şu ki, insanlar en büyük pazara sahip olanlar için bir şeyler yaparlar.
Aynı şey cep telefonları için de geçerli: Android ve iPhone'un harika oyunları var ama Windows Mobile ve Symbian ...

88
Arjun Bajaj

Çünkü Windows% 90'ın üzerinde pazar payına sahiptir ve Linux (özellikle Linux'u sorduğunuzdan beri), yazılım için ödeme yapmak istemeyen çok sayıda kullanıcıya sahip olduğu için bir üne sahiptir. Bunun doğru olup olmadığı veya ne kadar doğru olduğu önemsizdir; algı oradadır ve insanların kararlarını etkiler.

50
Mason Wheeler

Windows büyük bir organizasyon tarafından desteklendiğinden, on yıldan uzun bir süre önce karar verdi oyun geliştirmenin platformlarında olmasını istiyorlar .

Bu Mac için geçerli değildi ve şimdi doğru değil. İOS için bile değil. Apple iOS oyun geliştirme için araç sağlamıyor. Ancak, nispeten küçük bir rekabetle büyük bir pazar (1995'te PC'lerden daha fazla iPhone var), bu yüzden insanlar yine de yapıyor.

Linux'a gelince, herhangi bir öncelik belirleyebilecek bir tür merkezi kurum bile yoktur. Linux'un gittiği yön, çok iyi, ancak biraz dünya dışı programcılar tarafından daha az belirleniyor.

Bugün bir PC oyunu oluşturmak için 2d/3d sanatçılara, oyun tasarımcılarına, senaryo yazarlarına, aktörlere, test kullanıcılarına ve neye ihtiyacınız yok. Gerçek programlama ile ilgili olarak, gerçek bir oyun motoru (CryEngine, Unreal Engine, Quake Engine, Source Engine) kullanabilirsiniz. Böylece her şeyi gerçek bir programcı olmadan yapabilirsiniz.

Bu nedenle ve işletmelerin doğası nedeniyle, programcılar hangi platformun seçildiğini çok az söylerler. Ve genellikle yöneticiler, Microsoft'un sunduğu iddia edilen bir şey olan ve açık kaynak olmayan, düşünce kalıplarına bir şekilde el konabilecek şeylerle uğraşmak için destek ararlar.

Bu nedenle, çoğu ticari son kullanıcı yazılım geliştirme Windows üzerinde yapılır.
Flash oyunlar yaratan ve dolayısıyla belirli bir platforma bağlı olmayan bir şirkette çalışıyorum. Ancak, hepimiz pencerelerde gelişiyoruz, çünkü kullandığımız araçların çoğu Linux için mevcut değil.

11
back2dos

Bazılarının söylediği gibi, en önemli kısım kullanıcı tabanlıdır. PC kullanıcılarının% 95'i Windows kullanıyor. PC oyuncuları neredeyse sadece Windows kullanıyor. Mac veya Linux kullanan kişiler bile çoğu zaman Windows oyunlarını bazı sanallaştırma veya öykünme yoluyla (çok, çok az istisna hariç) çalıştırırlar.

Ancak demografik her şey değildir. Microsoft'un platformu oyun geliştiricileri için daha çekici hale getirmek için yaptığı kısmı küçümsemem. Temel olarak tam özellikli ücretsiz araç seti , en önemlisi XNA Game Studio . Bu sadece Windows için değil, aynı zamanda Xbox360 için de geliştirmeye izin verir. Ve WP7 telefonlar için bile en son sürümle. Açıkçası Microsoft aracı olduğu için OpenGL değil DirectX kullanıyor.

10
vartec

Ewwww, bilmiyorum. Linux'u neredeyse tamamen kullanıyorum. Windows derlemeleri yapmak için Windows'a çift önyükleme yapıyorum ve Mac derlemeleri için Mac'i kullanıyorum, ama hepsi bu.

Hile, yıllar içinde geliştirdiğimiz platformlar arası bir çerçevedir. Oyunlarımız bunun üzerine inşa edilmiştir ve Linux/OpenGL, Mac/OpenGL ve Windows/Direct3D'de (ve yakında iOS/OpenGL'de) aynı şekilde davranır.

Kuşkusuz şirketim AAA başlıkları yapmıyor, bu yüzden bunlar için geçerli olmayabilir, ancak en iyi gündelik oyunları yapıyoruz (bkz. web sitesi - CSI: NY, Murder She Wrote ve önümüzdeki iki 2011 örneklerdir önemli lisansları kullanan başlıklar, Sherlock Holmes 1 ve 2'nin Kayıp Durumları da oldukça başarılıydı)

Başka bir şey için gedit + gcc + gdb + valgrind'den vazgeçmezdim.

6
ggambett

Araçlar, araçlar, araçlar.

İşte böyle geliyor. Windows üzerinde geliştirin ve gezegendeki en iyi geliştirme araçlarından bazılarına erişin. Visual Studio'nun hata ayıklayıcısına uzaktan bile hiçbir şey gelmez, DirectX Hata Ayıklama Çalışma Zamanları harika, PIX harika ve karşılaştırılabilir eşdeğerler sadece diğer platformlarda/API'larda yok. Tabii, orada bazı iyi şeyler var; Diğer platformlardaki araçların kötü olduğunu söylemiyorum, ancak MS'in sağladığı araçlar, paketin çok ötesinde (şerefli istisna: Valgrind) bile komik değil.

Sonuç olarak, bu araçlar size yardımcı olur. İşlerinizi halletmenize yardımcı olurlar, üretken olmanıza yardımcı olurlar, belgelendiği gibi asla davranmayan bir API ile güreşmek yerine kendi kodunuzdaki hatalara odaklanmanıza yardımcı olurlar.

4
Maximus Minimus

Bu yüzden tüm bu cevapları aştım ve Walmart raflarında bulunan konsol oyunlarında kodu olan bir oyun geliştiricisi olarak çok farklı bir cevabım var.

Dağıtım.

Bir Nintendo konsolunda olmak istiyorsanız, Nintendo'nun iznini almanız, Nintendo'nun fabrikalarından satın almanız, Nintendo'nun genel masraflarını ödemeniz, Walmart ile müzakere etmeniz, depolamayla uğraşmanız, üretim yapmak, kutuları yazdırmak, gemi için önden paraya ihtiyacınız var. , tüm sigortayı yapmak, vb.

XBox'a istiyorsanız, XBLA olduğundan emin olun, ancak hala Microsoft'un nimetine ihtiyacınız var, sıranızı beklemek zorundasınız, sadece bir yama yayınlamak için on binlerce dolar.

İOS'ta hala Apple'ın iyi olmasına ihtiyacınız var ve sizi kaprisli bir şekilde çekebilirler (ve yapabilirler).

Steam'de hala Valve'ın iznine veya yeşil ışığa ve çok paraya ihtiyacınız var.

.

Windows üzerinde mi? Bir web sitesi ve bir indirme düğmesi ayarladınız.

.

Diğer platformların değerli olmadığını söylemiyorum. Ama bir oyun geliştirmeye çalıştığınızda yani * çok * korkunç şeyler oluyor, bana göre, bir sitede bir ikiliyi tokatlayıp işe odaklanabilme sözü - en azından başlamak için - gerçekten çok sayıda potansiyel arıza engelini azaltır.

"Daha sonra XBLA portunu işler istikrarlı olduğunda yapabiliriz" zihniyeti.

Ve daha az bir ölçüde bunun Linux için de iyi olduğundan emin olun ve yedi müşteri iyiyse, buradan başlayabilirsiniz.

Ancak Windows'un üç büyük avantajı vardır: gerçekten açık geliştirme, gerçekten açık dağıtım ve ilginç şeylerle ilgilenen çok büyük, çok aktif bir müşteri tabanı.

Başka nereden başlayacağımı hayal etmek zor.

4
John Haugeland

Cevap açıktır. Oyun yazmanın amacı para kazanmaktır. Daha fazla son kullanıcı Windows'u çalıştırır, bu nedenle daha büyük bir pazar vardır ve bir Windows oyunundan Linux oyunundan daha fazla para kazanmayı beklersiniz. Bu kadar basit.

Kendinize 'Neden biri yapar ...' sorusunu sorarsanız, paranın dünyayı dolaştıracağını unutmayın.

4
Russell Horwood
  1. Eylemsizlik. Geçmişte Windows'u kullandıysanız, başka bir şeye geçmek bir güçlüktür. Windows DirectX kullanıyorsanız, OpenGL'den daha kolay ve daha iyi çalışma olasılığı daha yüksektir.
  2. Pazar payı. Windows'un masaüstündeki pazar payı OS X'in pazar payından daha büyük ve bu da Linux pazar payından daha büyük. Para konuşur.
  3. Marka. DirectX, SDL gibi şeylerden daha iyi bilinir (bu, DirectX'in OpenGL'nin ötesine geçen bazı özelliklerini çoğaltmanız gereken bir şeydir).
  4. Daha az karışıklık. Kullanıcının Linux'u yalnızca OpenGL 1.4 veya OpenGL 2+ sürümlerini destekleyecek mi? Linux sürümünüzde Modern OpenGL'e giriş gibi OpenGL 2.0 öğreticisini kullanabilirsiniz. Bölüm 1: Grafik Hattı ?

Bu günlerde Linux, oyun geliştirme söz konusu olduğunda daha çok bir eğridir ve çoğu geliştirici, bir Linux sürümünden önce OS X bağlantı noktası sürümünü mali olarak yapmaktan daha iyi olacaktır (Steam gibi şeylere bakın). O zaman bile konsol pazarı oyunlar için bu iki platformdan daha değerli ...

Eğer mono platform istiyorsanız DirectX iyi. Çapraz platform olmak istiyorsanız, diğer platformlardan en azından bazılarında OpenGL ile gitmek zorunda kalacaksınız.

4
Anon

Bence DirectX ve Bu Makale Tarihi hakkında daha fazla bilgi edinmelisiniz.

Bence MS, OpenGL yerine DX'i seçti çünkü insanları kendi işletim sistemlerini kullanmaya kilitlemek istiyorlar.

3
Mahmoud Hossam

Politika ve kontrol ile ilgili çok şey var. 90'lı yılların sonlarında, SGI ve MS aslında çabaları birleştirmeyi kabul ettiler:

http://en.wikipedia.org/wiki/Fahrenheit_graphics_API

SGI projeye büyük yatırım yaptı, MS vermedi. SGI, MS'e ihtiyaç duyduğundan, MS SGI'ya ihtiyaç duymuştur. Gerisi tarih.

D3D ve OpenGL çok farklı iki API'dır, ihtiyaçlarınıza en uygun olanı seçmek geliştiriciye bağlıdır.

1
quellish

Çünkü Linux bir masaüstü sistemi olarak korkunç bir şekilde başarısız oldu. Birinin daha önce işaret ettiği gibi Linux geliştiriciler için bir karmaşa (farklı kütüphaneler, ui araç setleri, vb.)

Başka bir sorun, freetardizm ve tescilli yazılım için destek eksikliğidir. Nvidia, Linux için her zaman iyi (tescilli) sürücüler sağlar, ancak Ubuntu ve diğer dağıtımlar bunu göndermez. Windows için olduğu gibi Linux için de ikili sürücü arabirimi yoktur. (BinaryApiNonsense.txt adlı bir metin dosyası veya Çekirdek kaynaklarında bir şey var.) Linux altında yalnızca Nvidia donanımının düzgün bir şekilde desteklendiğini söylemiştik. ID yazılımlarının çoğunu Linux altında Nvidia donanımını kullanarak oynayabilirsiniz.

Sonraki şey geliştirme araçları. MSFT mükemmel C++ desteği sağlar ve Visual Studio hata ayıklayıcı C++ ile ilgili olarak gdb'den daha iyidir. Son olarak, Photoshop gibi başka araçlar da eksik. Ayrıca .net hızlı bir şekilde gui araçları oluşturmanızı sağlar. Birçok oyun stüdyosu, .net çerçevesini kullanarak araçlarını dahili kullanım için kodlar.

Neredeyse unuttum: Grafik sistemi korkunç, X11'i taşıdıkları günlerde işe yarayan en kolay şeydi. OSx ve Win'in sahip olduğu modern bir grafik sistemini düzgün bir şekilde tasarlayamadılar ve uygulayamadılar.

0
Nils