Banyak jawaban di sini benar-benar bagus. Tetapi masalah OpenGL dan Direct3D (D3D) mungkin harus diatasi. Dan itu membutuhkan ... pelajaran sejarah.
Dan sebelum kita mulai, saya tahu lebih banyak tentang OpenGL daripada yang saya lakukan tentang Direct3D . Saya tidak pernah menulis sederet kode D3D dalam hidup saya, dan saya telah menulis tutorial tentang OpenGL. Jadi apa yang akan saya katakan bukanlah masalah bias. Ini hanyalah masalah sejarah.
Kelahiran Konflik
Suatu hari, sekitar awal 90-an, Microsoft melihat sekeliling. Mereka melihat SNES dan Sega Genesis menjadi luar biasa, menjalankan banyak game aksi dan semacamnya. Dan mereka melihat DOS . Pengembang mengkodekan game DOS seperti game konsol: langsung ke logam. Namun tidak seperti konsol, di mana pengembang yang membuat permainan SNES tahu perangkat keras apa yang akan dimiliki pengguna, pengembang DOS harus menulis untuk beberapa kemungkinan konfigurasi. Dan ini agak sulit daripada kedengarannya.
Dan Microsoft memiliki masalah yang lebih besar: Windows. Lihat, Windows ingin memiliki perangkat keras, tidak seperti DOS yang memungkinkan pengembang melakukan apa saja. Memiliki perangkat keras diperlukan untuk memiliki kerjasama antar aplikasi. Kerja sama persis seperti yang dibenci pengembang game karena membutuhkan sumber daya perangkat keras berharga yang bisa mereka gunakan untuk menjadi luar biasa.
Untuk mempromosikan pengembangan game di Windows, Microsoft membutuhkan API yang seragam yang tingkatannya rendah, dijalankan pada Windows tanpa diperlambat, dan sebagian besar dari semua lintas-perangkat keras . API tunggal untuk semua perangkat keras grafis, suara, dan input.
Dengan demikian, DirectX lahir.
Akselerator 3D lahir beberapa bulan kemudian. Dan Microsoft mengalami masalah. Lihat, DirectDraw, komponen grafis dari DirectX, hanya berurusan dengan grafik 2D: mengalokasikan memori grafis dan melakukan bit-blits antara berbagai bagian memori yang dialokasikan.
Jadi Microsoft membeli sedikit middleware dan mengubahnya menjadi Direct3D Versi 3. Secara universal dicerca. Dan dengan alasan yang bagus; melihat kode D3D v3 seperti menatap ke Tabut Perjanjian.
John Carmack yang lama di Id Software memandang sampah itu dan berkata, "Persetan!" dan memutuskan untuk menulis ke API lain: OpenGL.
Lihat, bagian lain dari beast berkepala banyak yaitu Microsoft telah sibuk bekerja dengan SGI pada implementasi OpenGL untuk Windows. Idenya di sini adalah untuk pengadilan pengembang aplikasi GL khas: aplikasi workstation. Alat CAD, pemodelan, hal semacam itu. Game adalah hal terjauh di pikiran mereka. Ini terutama Windows NT, tetapi Microsoft memutuskan untuk menambahkannya ke Win95 juga.
Sebagai cara untuk menarik pengembang workstation ke Windows, Microsoft memutuskan untuk mencoba menyuap mereka dengan akses ke kartu grafis 3D bermodel baru ini. Microsoft menerapkan protokol Driver Klien yang Dapat Diinstal: pembuat kartu grafis dapat mengesampingkan implementasi OpenGL perangkat lunak Microsoft dengan yang berbasis perangkat keras. Kode dapat secara otomatis hanya menggunakan implementasi OpenGL perangkat keras jika ada.
Pada hari-hari awal, kartu video tingkat konsumen tidak memiliki dukungan untuk OpenGL. Itu tidak menghentikan Carmack dari hanya porting Quake ke OpenGL (GLQuake) di workstation SGI-nya. Seperti yang bisa kita baca dari readme GLQuake:
Secara teoritis, glquake akan berjalan pada OpenGL apa pun yang mendukung yang mendukung ekstensi objek tekstur, tetapi kecuali perangkat keras yang sangat kuat yang mempercepat semua yang dibutuhkan, permainan game tidak akan dapat diterima. Jika harus melalui jalur emulasi perangkat lunak apa pun, kinerjanya kemungkinan besar akan di bawah satu frame per detik.
Pada saat ini (Maret '97), satu-satunya perangkat keras pembuka standar yang dapat memainkan glquake secara wajar adalah intergraph realizm, yang merupakan kartu yang SANGAT mahal. 3dlabs telah meningkatkan kinerja mereka secara signifikan, tetapi dengan driver yang tersedia masih belum cukup baik untuk dimainkan. Beberapa driver 3dlabs saat ini untuk papan kilat dan permedia juga dapat crash NT ketika keluar dari menjalankan layar penuh, jadi saya tidak merekomendasikan menjalankan glquake pada perangkat keras 3dlabs.
3dfx telah menyediakan opengl32.dll yang mengimplementasikan semua kebutuhan glquake, tetapi ini bukan implementasi opengl penuh. Aplikasi opengl lain sangat tidak mungkin untuk bekerja dengannya, jadi anggap itu pada dasarnya "driver glquake".
Ini adalah kelahiran driver miniGL. Ini berkembang menjadi implementasi OpenGL penuh pada akhirnya, karena perangkat keras menjadi cukup kuat untuk mengimplementasikan sebagian besar fungsi OpenGL dalam perangkat keras. nVidia adalah yang pertama menawarkan implementasi OpenGL penuh. Banyak vendor lain yang berjuang, yang merupakan salah satu alasan mengapa pengembang lebih menyukai Direct3D: mereka kompatibel pada perangkat keras yang lebih luas. Akhirnya hanya nVidia dan ATI (sekarang AMD) yang tersisa, dan keduanya memiliki implementasi OpenGL yang baik.
Ascendant OpenGL
Jadi panggungnya diatur: Direct3D vs OpenGL. Ini benar-benar cerita yang luar biasa, mengingat betapa buruknya D3D v3.
OpenGL Architectural Review Board (ARB) adalah organisasi yang bertanggung jawab untuk memelihara OpenGL. Mereka mengeluarkan sejumlah ekstensi, mempertahankan repositori ekstensi, dan membuat versi baru API. ARB adalah komite yang dibuat oleh banyak pemain industri grafis, serta beberapa pembuat OS. Apple dan Microsoft pada berbagai waktu menjadi anggota ARB.
3Dfx keluar dengan Voodoo2. Ini adalah perangkat keras pertama yang dapat melakukan multitexturing, yang merupakan sesuatu yang tidak bisa dilakukan OpenGL sebelumnya. Sementara 3Dfx sangat menentang OpenGL, NVIDIA, pembuat chip grafis multitexturing berikutnya (TNT1), menyukainya. Jadi ARB mengeluarkan ekstensi: GL_ARB_multitexture, yang akan memungkinkan akses ke multitexturing.
Sementara itu, Direct3D v5 keluar. Sekarang, D3D telah menjadi API yang sebenarnya , dan bukannya sesuatu yang mungkin dimuntahkan kucing. Masalah? Tidak ada multitexturing.
Ups.
Sekarang, yang satu tidak akan sakit sebanyak yang seharusnya, karena orang tidak menggunakan multitexturing banyak. Tidak secara langsung. Multitexturing sedikit melukai kinerja, dan dalam banyak kasus tidak sepadan dengan multi-passing. Dan tentu saja, pengembang gim senang memastikan bahwa gim mereka bekerja pada peranti keras yang lebih lama, yang tidak memiliki multitekstur, sehingga banyak gim yang dikirimkan tanpa itu.
D3D dengan demikian diberi penangguhan hukuman.
Waktu berlalu dan NVIDIA menyebarkan GeForce 256 (bukan GeForce GT-250; GeForce pertama), cukup banyak kompetisi kartu grafis yang berakhir untuk dua tahun ke depan. Titik penjualan utama adalah kemampuan untuk melakukan transformasi vertex dan pencahayaan (T&L) dalam perangkat keras. Tidak hanya itu, NVIDIA sangat mencintai OpenGL sehingga mesin T&L mereka secara efektif adalah OpenGL. Hampir secara harfiah; seperti yang saya mengerti, beberapa register mereka benar-benar mengambil enumerator OpenGL secara langsung sebagai nilai.
Direct3D v6 keluar. Multitexture akhirnya tetapi ... tidak ada perangkat keras T&L. OpenGL selalu memiliki pipa T&L, meskipun sebelum 256 itu diterapkan dalam perangkat lunak. Jadi sangat mudah bagi NVIDIA untuk hanya mengubah implementasi perangkat lunak mereka menjadi solusi perangkat keras. Tidak akan sampai D3D v7 sampai D3D akhirnya memiliki dukungan T&L perangkat keras.
Dawn of Shaders, Twilight of OpenGL
Kemudian, GeForce 3 keluar. Dan banyak hal terjadi pada saat yang bersamaan.
Microsoft telah memutuskan bahwa mereka tidak akan terlambat lagi. Jadi, alih-alih melihat apa yang dilakukan NVIDIA dan kemudian menyalinnya setelah fakta, mereka mengambil posisi menakjubkan untuk pergi ke mereka dan berbicara dengan mereka. Dan kemudian mereka jatuh cinta dan memiliki konsol kecil bersama.
Perceraian berantakan terjadi kemudian. Tapi itu untuk lain waktu.
Apa artinya ini untuk PC adalah bahwa GeForce 3 keluar bersamaan dengan D3D v8. Dan tidak sulit untuk melihat bagaimana GeForce 3 memengaruhi shader D3D 8. Pixel shader Shader Model 1.0 sangat spesifik untuk perangkat keras NVIDIA. Tidak ada upaya apa pun yang dilakukan pada abstrak perangkat keras NVIDIA; SM 1.0 adalah apa pun yang dilakukan GeForce 3.
Ketika ATI mulai terjun ke perlombaan kartu grafis dengan Radeon 8500, ada masalah. Pipa pemrosesan piksel 8500 lebih kuat dari pada barang-barang NVIDIA. Jadi Microsoft mengeluarkan Shader Model 1.1, yang pada dasarnya adalah "Apapun yang dilakukan 8500."
Itu mungkin terdengar seperti kegagalan pada bagian D3D. Tetapi kegagalan dan kesuksesan adalah masalah derajat. Dan kegagalan epik terjadi di OpenGL-land.
NVIDIA menyukai OpenGL, jadi ketika GeForce 3 hit, mereka merilis sejumlah ekstensi OpenGL. Ekstensi OpenGL eksklusif : Khusus NVIDIA. Tentu, ketika 8500 muncul, itu tidak bisa menggunakan salah satu dari mereka.
Lihat, setidaknya di tanah D3D 8, Anda bisa menjalankan shader SM 1.0 pada perangkat keras ATI. Tentu, Anda harus menulis shader baru untuk memanfaatkan kesejukan 8500, tetapi setidaknya kode Anda berfungsi .
Untuk mendapatkan shaders dalam bentuk apa pun pada Radeon 8500 di OpenGL, ATI harus menulis sejumlah ekstensi OpenGL. Ekstensi OpenGL eksklusif : Hanya ATI. Jadi Anda membutuhkan NVIDIA codepath dan ATI codepath, hanya untuk mendapatkan shader sama sekali.
Sekarang, Anda mungkin bertanya, "Di mana OpenGL ARB, yang tugasnya menjaga OpenGL sekarang?" Di mana banyak komite sering berakhir: menjadi bodoh.
Lihat, saya sebutkan ARB_multitexture di atas karena sangat mempengaruhi semua ini. ARB tampaknya (dari sudut pandang orang luar) ingin menghindari gagasan tentang shader sama sekali. Mereka berpikir bahwa jika mereka menampar konfigurabilitas yang cukup ke pipeline fungsi-tetap, mereka dapat menyamai kemampuan pipa shader.
Jadi ARB merilis ekstensi demi ekstensi. Setiap ekstensi dengan kata-kata "tekstur_env" di dalamnya adalah upaya lain untuk menambal desain penuaan ini. Periksa registri: antara ekstensi ARB dan EXT, ada delapan ekstensi yang dibuat. Banyak yang dipromosikan ke versi inti OpenGL.
Microsoft adalah bagian dari ARB saat ini; mereka pergi sekitar waktu D3D 9 melanda. Jadi sangat mungkin bahwa mereka bekerja untuk menyabot OpenGL dalam beberapa cara. Saya pribadi meragukan teori ini karena dua alasan. Satu, mereka harus mendapatkan bantuan dari anggota ARB lain untuk melakukan itu, karena setiap anggota hanya mendapat satu suara. Dan yang paling penting dua, ARB tidak membutuhkan bantuan Microsoft untuk mengacaukan segalanya. Kami akan melihat bukti lebih lanjut tentang itu.
Akhirnya ARB, kemungkinan di bawah ancaman baik dari ATI dan NVIDIA (keduanya anggota aktif) akhirnya menarik kepala mereka cukup lama untuk memberikan shader gaya perakitan yang sebenarnya.
Ingin sesuatu yang lebih bodoh?
T&L perangkat keras. Sesuatu yang dimiliki OpenGL terlebih dahulu . Yah, ini menarik. Untuk mendapatkan kinerja semaksimal mungkin dari perangkat keras T&L, Anda perlu menyimpan data vertex Anda di GPU. Bagaimanapun, itu adalah GPU yang benar-benar ingin menggunakan data vertex Anda.
Di D3D v7, Microsoft memperkenalkan konsep Vertex Buffer. Ini adalah petak memori GPU yang dialokasikan untuk menyimpan data titik.
Ingin tahu kapan OpenGL mendapatkan yang setara dengan ini? Oh, NVIDIA, sebagai pencinta segala hal OpenGL (selama itu adalah ekstensi NVIDIA yang dipatenkan), merilis ekstensi rentang array vertex ketika GeForce 256 hit pertama kali. Tetapi kapan ARB memutuskan untuk menyediakan fungsionalitas serupa?
Dua tahun kemudian . Ini setelah mereka menyetujui vertex dan fragmen shaders (pixel dalam bahasa D3D). Untuk itu diperlukan waktu berapa lama ARB mengembangkan solusi lintas platform untuk menyimpan data verteks dalam memori GPU. Sekali lagi, sesuatu yang hardware T & L perlu untuk mencapai performa maksimal.
Satu Bahasa untuk Merusak Mereka Semua
Jadi, lingkungan pengembangan OpenGL retak untuk sementara waktu. Tidak ada shader lintas-perangkat keras, tidak ada penyimpanan simpul GPU lintas-perangkat keras, sementara pengguna D3D menikmati keduanya. Bisakah ini menjadi lebih buruk?
Anda ... Anda bisa mengatakan itu. Masukkan Labs 3D .
Siapa mereka, Anda mungkin bertanya? Mereka adalah perusahaan mati yang saya anggap sebagai pembunuh OpenGL yang sebenarnya. Tentu, ketidakmampuan umum ARB membuat OpenGL rentan ketika seharusnya memiliki D3D. Tapi 3D Labs mungkin satu-satunya alasan terbesar dalam pikiran saya untuk keadaan pasar OpenGL saat ini. Apa yang bisa mereka lakukan untuk menyebabkan itu?
Mereka merancang Bahasa Shading OpenGL.
Lihat, 3D Labs adalah perusahaan yang sedang sekarat. GPU mahal mereka sedang dipinggirkan oleh meningkatnya tekanan NVIDIA di pasar workstation. Dan tidak seperti NVIDIA, 3D Labs tidak memiliki kehadiran di pasar utama; jika NVIDIA menang, mereka mati.
Yang mereka lakukan.
Jadi, dalam upaya untuk tetap relevan di dunia yang tidak menginginkan produk mereka, 3D Labs muncul ke Konferensi Pengembang Game yang mengadakan presentasi untuk sesuatu yang mereka sebut "OpenGL 2.0". Ini akan menjadi penulisan ulang lengkap dari awal dari OpenGL API. Dan itu masuk akal; ada banyak cruft di API OpenGL pada saat itu (catatan: cruft itu masih ada). Lihat saja bagaimana pemuatan tekstur dan pengikatan bekerja; itu semi-misterius.
Bagian dari proposal mereka adalah bahasa yang teduh. Tentu saja. Namun, tidak seperti ekstensi ARB lintas-platform saat ini, bahasa shading mereka adalah "tingkat tinggi" (C adalah tingkat tinggi untuk bahasa bayangan. Ya, sungguh).
Sekarang, Microsoft sedang mengerjakan bahasa shading tingkat tinggi mereka sendiri. Yang mereka, dalam semua imajinasi kolektif Microsoft, disebut ... High Level Shading Language (HLSL). Namun, pendekatan mereka berbeda secara mendasar terhadap bahasa.
Masalah terbesar dengan bahasa shader 3D Labs adalah built-in. Lihat, HLSL adalah bahasa yang didefinisikan oleh Microsoft. Mereka merilis kompiler untuk itu, dan menghasilkan kode perakitan Shader Model 2.0 (atau yang lebih baru model shader), yang akan Anda masukkan ke D3D. Pada hari-hari D3D v9, HLSL tidak pernah disentuh oleh D3D secara langsung. Itu abstraksi yang bagus, tapi itu murni opsional. Dan seorang pengembang selalu memiliki kesempatan untuk pergi di belakang kompiler dan men-tweak output untuk kinerja maksimum.
Bahasa Lab 3D tidak memiliki itu. Anda memberi pengemudi bahasa seperti-C, dan menghasilkan shader. Akhir dari cerita. Bukan perakitan shader, bukan sesuatu yang Anda beri makan sesuatu yang lain. Objek OpenGL yang sebenarnya mewakili shader.
Apa ini artinya adalah bahwa pengguna OpenGL terbuka untuk keanehan pengembang yang baru saja terbiasa mengompilasi bahasa seperti perakitan. Bug kompiler merajalela di OpenGL Shading Language (GLSL) yang baru saja dibaptis. Yang lebih buruk, jika Anda berhasil mendapatkan shader untuk dikompilasi di beberapa platform dengan benar (tidak ada prestasi berarti), Anda masih mengalami pengoptimal hari ini. Yang tidak seoptimal mungkin.
Meskipun itu adalah kelemahan terbesar di GLSL, itu bukan satu-satunya kelemahan. Oleh jauh .
Dalam D3D, dan dalam bahasa assembly yang lebih lama di OpenGL, Anda bisa mencampur dan mencocokkan shader vertex dan fragmen (piksel). Selama mereka berkomunikasi dengan antarmuka yang sama, Anda bisa menggunakan vertex shader dengan shader fragmen yang kompatibel. Dan bahkan ada tingkat ketidakcocokan yang bisa mereka terima; vertex shader dapat menulis output yang tidak dibaca oleh shader fragmen. Dan seterusnya.
GLSL tidak memilikinya. Vertex dan fragmen shader digabungkan bersama menjadi apa yang disebut Lab 3D "objek program". Jadi jika Anda ingin berbagi program vertex dan fragmen, Anda harus membangun beberapa objek program. Dan ini menyebabkan masalah terbesar kedua.
Lihat, Labs 3D mengira mereka pintar. Mereka mendasarkan model kompilasi GLSL pada C / C ++. Anda mengambil .c atau .cpp dan mengkompilasinya ke file objek. Kemudian Anda mengambil satu atau lebih file objek dan menautkannya ke dalam suatu program. Jadi begitulah cara GLSL mengkompilasi: Anda mengkompilasi shader Anda (vertex atau fragmen) menjadi objek shader. Lalu Anda meletakkan objek shader tersebut di objek program, dan menautkannya bersama untuk membentuk program Anda yang sebenarnya.
Meskipun hal ini memungkinkan ide-ide keren yang potensial seperti memiliki shader "perpustakaan" yang berisi kode tambahan yang bisa disebut oleh shader utama, yang dimaksud dalam praktiknya adalah bahwa shader dikompilasi dua kali . Sekali dalam tahap kompilasi dan sekali dalam tahap menghubungkan. Kompiler NVIDIA khususnya dikenal pada dasarnya menjalankan kompilasi dua kali. Itu tidak menghasilkan semacam perantara kode objek; itu hanya mengkompilasinya sekali dan membuang jawabannya, lalu mengkompilasinya lagi pada waktu tautan.
Jadi, bahkan jika Anda ingin menautkan vertex shader Anda ke dua shader fragmen yang berbeda, Anda harus melakukan kompilasi lebih banyak daripada di D3D. Terutama karena kompilasi bahasa seperti C semua dilakukan secara offline , bukan pada awal pelaksanaan program.
Ada masalah lain dengan GLSL. Mungkin tampaknya salah untuk menyalahkan Labs 3D, karena ARB akhirnya menyetujui dan memasukkan bahasa (tapi tidak ada yang lain dari inisiatif "OpenGL 2.0" mereka). Tapi itu ide mereka.
Dan inilah bagian yang sangat menyedihkan: Labs 3D benar (kebanyakan). GLSL bukan bahasa shading berbasis vektor seperti HLSL pada saat itu. Ini karena perangkat keras 3D Labs adalah perangkat keras skalar (mirip dengan perangkat keras NVIDIA modern), tetapi mereka pada akhirnya tepat ke arah banyak pembuat perangkat keras menggunakan perangkat keras mereka.
Mereka benar untuk menggunakan model kompilasi-online untuk bahasa "tingkat tinggi". D3D bahkan akhirnya beralih ke itu.
Masalahnya adalah bahwa Lab 3D benar pada waktu yang salah . Dan dalam mencoba memanggil masa depan terlalu dini, dalam mencoba menjadi bukti masa depan, mereka mengesampingkan masa kini . Kedengarannya mirip dengan bagaimana OpenGL selalu memiliki kemungkinan untuk fungsi T&L. Kecuali bahwa pipa T&L OpenGL masih berguna sebelum T&L perangkat keras, sementara GLSL adalah kewajiban sebelum dunia menyadarinya.
GLSL adalah bahasa yang baik sekarang . Tetapi untuk saat ini? Itu mengerikan. Dan OpenGL menderita karenanya.
Jatuh Menuju Apotheosis
Sementara saya berpendapat bahwa Labs 3D menghantam pukulan fatal, itu adalah ARB sendiri yang akan mendorong paku terakhir di peti mati.
Ini adalah kisah yang mungkin pernah Anda dengar. Pada saat OpenGL 2.1, OpenGL mengalami masalah. Itu memiliki banyak peninggalan warisan. API tidak mudah digunakan lagi. Ada 5 cara untuk melakukan hal-hal, dan tidak tahu mana yang tercepat. Anda bisa "mempelajari" OpenGL dengan tutorial sederhana, tetapi Anda tidak benar-benar mempelajari OpenGL API yang memberi Anda kinerja nyata dan kekuatan grafis.
Jadi ARB memutuskan untuk mencoba penemuan ulang OpenGL lainnya. Ini mirip dengan 3D Labs "OpenGL 2.0", tetapi lebih baik karena ARB ada di belakangnya. Mereka menyebutnya "Longs Peak."
Apa yang sangat buruk tentang meluangkan waktu untuk meningkatkan API? Ini buruk karena Microsoft telah membiarkan diri mereka sendiri rentan. Lihat, ini pada saat peralihan Vista.
Dengan Vista, Microsoft memutuskan untuk melembagakan beberapa perubahan yang sangat dibutuhkan pada driver layar. Mereka memaksa pengemudi untuk tunduk pada OS untuk virtualisasi memori grafis dan berbagai hal lainnya.
Sementara orang dapat memperdebatkan manfaat dari ini atau apakah itu benar-benar mungkin, faktanya tetap ini: Microsoft menganggap D3D 10 sebagai Vista (dan di atas) saja. Bahkan jika Anda memiliki perangkat keras yang mampu D3D 10, Anda tidak bisa menjalankan aplikasi D3D 10 tanpa juga menjalankan Vista.
Anda mungkin juga ingat bahwa Vista ... um, katakan saja itu tidak bekerja dengan baik. Jadi Anda memiliki OS yang berkinerja buruk, API baru yang hanya berjalan pada OS itu, dan generasi baru perangkat keras yang membutuhkan API dan OS untuk melakukan sesuatu yang lebih cepat daripada generasi sebelumnya.
Namun, pengembang dapat mengakses fitur D3D 10-kelas melalui OpenGL. Yah, mereka bisa jika ARB tidak sibuk bekerja di Longs Peak.
Pada dasarnya, ARB menghabiskan waktu satu setengah tahun hingga dua tahun untuk membuat API lebih baik. Pada saat OpenGL 3.0 benar-benar keluar, adopsi Vista naik, Win7 sudah dekat untuk menempatkan Vista di belakang mereka, dan sebagian besar pengembang game tidak peduli dengan fitur kelas D3D-10. Bagaimanapun, perangkat keras D3D 10 menjalankan aplikasi D3D 9 dengan baik. Dan dengan meningkatnya port PC-ke-konsol (atau pengembang PC yang melompat ke pengembangan konsol. Pilihlah), pengembang tidak memerlukan fitur kelas D3D 10.
Sekarang, jika pengembang memiliki akses ke fitur-fitur itu sebelumnya melalui OpenGL pada mesin WinXP, maka pengembangan OpenGL mungkin telah menerima suntikan yang sangat dibutuhkan di lengan. Tetapi ARB melewatkan kesempatan mereka. Dan apakah Anda ingin tahu bagian terburuknya?
Meskipun menghabiskan dua tahun berharga untuk membangun kembali API dari awal ... mereka masih gagal dan baru saja kembali ke status quo (kecuali untuk mekanisme penghentian).
Jadi, ARB tidak hanya melewatkan kesempatan penting , mereka bahkan tidak menyelesaikan tugas yang membuat mereka kehilangan kesempatan itu. Cukup banyak epik yang gagal di sekitar.
Dan itulah kisah OpenGL vs Direct3D. Kisah tentang peluang yang terlewatkan, kebodohan besar, kebutaan yang disengaja, dan kebodohan sederhana.