🏡 ✌🏾 🍗 Direct3D vs OpenGL: sejarah konfrontasi 🥕 🌛 👌🏾

Sampai hari ini, ada perdebatan di Internet tentang API grafik mana yang lebih baik: Direct3D atau OpenGL? Terlepas dari sifat religius mereka, pertempuran verbal semacam itu membawa hasil yang bermanfaat dalam bentuk ulasan sejarah yang baik tentang pengembangan grafis yang dipercepat perangkat keras.

Tujuan dari posting ini adalah untuk menerjemahkan salah satu dari kunjungan ini ke dalam sejarah.ditulis oleh Jason L. McKesson dalam menanggapi pertanyaan "Mengapa pengembang game lebih memilih Windows." Teks ini tidak mungkin menjawab pertanyaan yang diajukan, tetapi ia menggambarkan sejarah perkembangan dan konfrontasi dari dua API grafik paling populer dengan cara yang sangat penuh warna dan cukup detail, jadi saya mempertahankan markup penulis dalam terjemahan. Teks ini ditulis pada pertengahan 2011 dan mencakup periode waktu yang dimulai tak lama sebelum kedatangan Direct3D dan sampai saat penulisan. Penulis teks asli adalah pengembang game berpengalaman, peserta aktif di StackOverflow, dan pencipta buku teks yang luas tentang pemrograman grafis 3D modern. Jadi mari kita beri dasar pada Jason.

Kata Pengantar

Sebelum kita mulai, saya ingin mengatakan bahwa saya tahu lebih banyak tentang OpenGL daripada tentang Direct3D. Dalam hidup saya, saya belum menulis satu baris kode dalam D3D, tetapi saya telah menulis manual OpenGL. Tapi yang ingin saya bicarakan bukanlah masalah prasangka, tetapi tentang sejarah.

Kelahiran konflik

Suatu ketika, sekitar awal tahun 90-an, Microsoft melihat sekeliling. Mereka melihat bahwa SNES dan Sega Genesis sangat keren, Anda dapat memainkan banyak game aksi dan semua itu. Dan mereka melihat dos. Para pengembang menulis game dosovskie sebagai konsol: dekat dengan besi. Namun, tidak seperti konsol, di mana pengembang tahu apa jenis perangkat keras yang akan dimiliki pengguna, pengembang dos dipaksa untuk menulis di bawah banyak konfigurasi. Dan ini jauh lebih rumit daripada yang terlihat.

Tetapi Microsoft memiliki masalah yang lebih besar: Windows. Soalnya, Windows ingin memiliki perangkat keras sepenuhnya, tidak seperti DOS, yang memungkinkan pengembang untuk melakukan apa saja. Kepemilikan besi diperlukan untuk interaksi antar aplikasi. Tetapi interaksi semacam ini adalah persis apa yang mereka benci.pengembang game karena menghabiskan sumber daya berharga yang dapat mereka gunakan untuk semua hal keren.

Untuk mempromosikan pengembangan game di Windows, Microsoft membutuhkan API yang seragam yang akan tingkat rendah, akan bekerja di Windows tanpa kehilangan kinerja, dan akan kompatibel dengan berbagai perangkat keras . Satu API untuk perangkat grafik, suara dan input.

Jadi DirectX lahir.

Akselerator 3D muncul beberapa bulan kemudian. Dan Microsoft mendapat masalah. Faktanya adalah bahwa DirectDraw, komponen grafis dari DirectX, hanya bekerja dengan grafis 2D: itu mengalokasikan memori grafis dan melakukan operasi bit cepat antara berbagai sektor memori.

Oleh karena itu, Microsoft membeli beberapa perangkat lunak pihak ketiga dan mengubahnya menjadi Direct3D versi 3. Dia dimarahibenar-benar segalanya. Dan ada alasannya: membaca kode pada D3D v3 tampak seperti decoding dari bahasa tertulis dari peradaban kuno yang punah.

Orang tua John Carmack di Id Software memandangi aib ini, berkata, “Ya itu pergi ...”, dan memutuskan untuk menulis menggunakan API lain: OpenGL.

Namun, sisi lain dari kisah yang membingungkan ini adalah bahwa Microsoft bekerja dengan SGI untuk mengimplementasikan OpenGL untuk Windows. Idenya adalah untuk menarik pengembang aplikasi GL khas untuk workstation: CAD, sistem pemodelan dan sejenisnya. Permainan adalah hal terakhir yang mereka pikirkan. Ini terutama menyangkut Windows NT, tetapi Microsoft memutuskan untuk menambahkan OpenGL ke Windows 95 juga.

Untuk memikat pengembang perangkat lunak untuk workstation di Windows, Microsoft memutuskan untuk menyuap mereka dengan akses ke akselerator 3D bermodel baru. Mereka menerapkan protokol untuk driver klien yang diinstal: kartu grafis dapat menggantikan perangkat lunak OpenGL Microsoft dengan implementasi perangkat keras mereka. Kode secara otomatis menggunakan perangkat keras OpenGL, jika ada.

Namun, pada masa itu kartu grafis konsumen tidak memiliki dukungan OpenGL. Ini tidak menghentikan Carmack dari porting Quake ke OpenGL di workstation SGI. Di file readme dari GLQuake, Anda dapat membaca yang berikut:

, glquake OpenGL, texture objects. , , , . - , .

( 1997), opengl , glquake , intergraph realizm. 3dlabs , . 3dlabs glint permedia NT , glquake 3dlabs.

3dfx opengl32.dll, glquake, opengl. opengl- , « glquake».

Ini adalah kelahiran driver miniGL. Mereka akhirnya berkembang menjadi implementasi OpenGL yang lengkap segera setelah perangkat keras menjadi cukup kuat untuk mendukung fungsi ini dalam perangkat keras. nVidia adalah yang pertama menawarkan implementasi penuh OpenGL. Vendor lain masih lambat, yang merupakan salah satu alasan untuk transisi ke Direct3D, didukung oleh berbagai peralatan yang lebih luas. Pada akhirnya, hanya nVidia dan ATI (yang sekarang AMD) tetap, dan keduanya memiliki implementasi OpenGL yang baik.

Dawn of OpenGL

Jadi, para peserta didefinisikan: Direct3D terhadap OpenGL. Ini benar-benar kisah yang luar biasa, mengingat betapa buruknya D3D v3.

OpenGL Architectural Review Board (ARB) adalah organisasi yang bertanggung jawab untuk memelihara dan mengembangkan OpenGL. Mereka merilis banyak ekstensi, berisi repositori dengan ekstensi, dan membuat versi baru API. ARB adalah komite yang terdiri dari sejumlah besar pemain di industri grafis komputer dan beberapa produsen OS. Apple dan Microsoft juga anggota ARB pada waktu yang berbeda.

3Dfx memasuki adegan dengan Voodoo2-nya. Ini adalah kartu video pertama yang memungkinkan Anda melakukan multitekstur, yang sebelumnya tidak disediakan di OpenGL. Sementara 3Dfx sangat menentang OpenGL, nVidia, pembuat chip multitexturing (TNT1) selanjutnya, tergila-gila dengan OpenGL. Kemudian ARB merilis ekstensi GL_ARB_multitexture, yang menyediakan akses ke beberapa tekstur.

Sementara itu, Direct3D v5 muncul. Sekarang D3D benar-benar menjadi API , bukan semacam omong kosong. Apa masalahnya? Dengan tidak adanya multitexturing.

Ups

Tetapi ini tidak menyebabkan ketidaknyamanan yang bisa terjadi, karena hampir tidak ada yang menggunakan banyak texturing. Multitexturing hampir tidak merusak kinerja, dan dalam banyak kasus perbedaannya tidak terlihat dengan latar belakang multi-pass. Dan tentu saja, para pengembang game sangat menyukai permainan mereka yang bekerja dengan percaya diri pada perangkat keras lama yang tidak memiliki dukungan untuk banyak tekstur, sehingga banyak game yang dirilis tanpa itu.

D3D menghela nafas lega.

Waktu berlalu, dan nVidia meluncurkan GeForce 256 (jangan bingung dengan GeForce GT-250 pertama), menghentikan perjuangan di pasar kartu grafis untuk dua tahun ke depan. Keunggulan kompetitif utama dari board ini adalah kemampuan untuk melakukan transformasi dan transformasi vertex & pencahayaan (T&L) dalam perangkat keras. Tapi itu tidak semua: nVidia OpenGL mencintai begitu banyak bahwa T & L-engine mereka benar-benar telah OpenGL. Hampir secara harfiah! Seperti yang saya pahami, beberapa register mereka menerima langsung nilai numerik variabel dari tipe GLenum.

Direct3D v6 keluar. Akhirnya, beberapa texturing tiba pada waktunya ... tetapi tanpa T&L perangkat keras. OpenGL selaluada pipa T&L, meskipun sebelum GeForce 256 itu diterapkan dalam perangkat lunak. Oleh karena itu, untuk nVidia, ternyata cukup sederhana untuk membuat kembali implementasi perangkat lunak menjadi solusi perangkat keras. Di D3D, perangkat keras T&L hanya muncul di versi ketujuh.

Dawn of the Shader Age, OpenGL in the Dark

Kemudian datang GeForce 3. Pada saat yang sama, banyak hal menarik terjadi.

Microsoft memutuskan bahwa mereka tidak lagi akan terlambat. Oleh karena itu, alih-alih melihat apa yang akan dilakukan nVidia dan menyalin perkembangan mereka yang sudah post-factum, Microsoft membuat keputusan luar biasa: pergi dan bicara. Dan mereka jatuh cinta, dan mereka mendapat konsol kecil bersama.

Perceraian yang berisik terjadi kemudian, tetapi ini adalah kisah yang sama sekali berbeda.

Untuk pasar PC, ini berarti bahwa GeForce 3 keluar bersamaan dengan D3D v8, dan mudah untuk melihat bagaimana GeForce 3 memengaruhi D3D v8 shader. Pixel shaders dari Shader Model 1.0 sangatsangat tajam untuk peralatan nVidia. Tidak ada satu upaya pun dilakukan untuk melakukan apa pun untuk abstrak nVidia dari besi. Shader Model 1.0 dirancang untuk GeForce 3.

Ketika ATI memasuki balapan kinerja grafis dengan Radeon 8500, ada satu masalah. Pipa Radeon 8500 pixel ternyata lebih kuat daripada nVidia. Oleh karena itu, Microsoft merilis Shader Model 1.1, yang pada dasarnya digunakan untuk 8500.

Kedengarannya seperti kekalahan D3D, tetapi keberhasilan dan kegagalan adalah istilah yang relatif. Bahkan, kegagalan epik menunggu OpenGL.

NVidia sangat menyukai OpenGL, jadi setelah rilis GeForce 3 mereka merilis sejumlah ekstensi untuk OpenGL. Hak Milikekstensi yang hanya berfungsi pada nVidia. Tentu saja, ketika papan 8500 muncul, ia tidak dapat menggunakan satupun dari mereka.

Jadi, pada D3D 8, Anda setidaknya bisa menjalankan shader SM 1.0. Tentu saja, untuk menggunakan semua kesejukan 8500, saya harus menulis shader baru, tetapi kode setidaknya berhasil .

Untuk mendapatkan setiap shader pada Radeon 8500 OpenGL, ATI harus mengembangkan beberapa ekstensi untuk OpenGL. Ekstensi eksklusif yang hanya berfungsi pada ATI. Akibatnya, agar pengembang dapat menyatakan bahwa mereka mengacaukan shader ke mesin mereka, mereka harus menulis kode terpisah untuk nVidia dan kode terpisah untuk ATI.

Anda mungkin bertanya: "Dan di mana komite ARB yang seharusnya mendukung OpenGL bertahan?" Dan mereka adalah tempat banyak komite berakhir: mereka duduk dan bodoh.

Harap dicatat, saya menyebutkan ARB_multitexture di atas karena ekstensi ini sangat terlibat dalam seluruh situasi. Tampaknya bagi pengamat luar bahwa ARB umumnya ingin menghindari gagasan tentang shader. Mereka memutuskan bahwa jika mereka menyuntikkan konfigurasi yang cukup ke dalam pipa tetap, maka itu akan sama dalam kemampuannya dengan pipa shader yang dapat diprogram.

ARB merilis ekstensi satu per satu. Setiap ekstensi dengan kata "tekstur_env" dalam nama adalah upaya untuk memperbaiki desain penuaan ini. Lihatlah daftar ekstensi: delapan ekstensi tersebut telah dirilispotongan, dan banyak dari mereka telah diterjemahkan ke dalam fungsionalitas inti OpenGL.

Pada saat itu, Microsoft adalah bagian dari ARB, dan hanya tersisa untuk rilis D3D 9, jadi mungkin Microsoft menyabotase OpenGL dalam beberapa cara. Secara pribadi, saya meragukan teori ini karena dua alasan. Pertama, mereka harus mendapatkan dukungan dari anggota Komite lainnya, karena masing-masing anggota hanya memiliki satu suara. Kedua, dan yang lebih penting, Komite tidak membutuhkan bantuan Microsoft untuk mengacaukan semuanya, bukti yang akan kita lihat nanti.

Akibatnya, ARB, kemungkinan besar di bawah tekanan dari ATI dan nVidia (keduanya adalah peserta aktif), akhirnya terbangun dan memperkenalkan shader assembler ke dalam standar.

Ingin cerita yang lebih aneh?

T&L perangkat keras. Inilah yang awalnya dimiliki OpenGL .. Untuk mendapatkan kinerja T&L perangkat keras setinggi mungkin, Anda perlu menyimpan data vertex pada GPU. Meski demikian, GPU adalah konsumen utama data titik.

Dalam D3D v7, Microsoft memperkenalkan konsep vertex buffer, yang mengalokasikan potongan memori dalam GPU dan menempatkan data vertex di sana.

Ingin tahu kapan fungsionalitas yang setara muncul di OpenGL? Ya, nVidia, sebagai penggemar OpenGL terbesar, merilis ekstensi untuk menyimpan array vertex pada GPU pada saat rilis GeForce 256. Tetapi kapan ARB memperkenalkan fungsi seperti itu?

Dua tahun kemudian. Itu setelahtentang bagaimana ia menyetujui vertex dan fragmen (pixel dalam hal D3D) shader. Butuh begitu banyak waktu bagi ARB untuk mengembangkan solusi lintas platform untuk menyimpan data verteks dalam memori GPU. Dan itulah yang dibutuhkan T&L perangkat keras untuk mencapai kinerja maksimal.

Satu bahasa untuk membunuh mereka semua

Jadi, OpenGL telah rusak selama beberapa waktu. Tidak ada shader cross-platform dan penyimpanan vertex perangkat keras-independen di GPU, sementara pengguna D3D menikmati keduanya. Bisakah ini menjadi lebih buruk?

Bisa dibilang bisa. Bertemu: 3D Labs .

Anda bertanya: siapa mereka? Mereka adalah perusahaan mati yang saya anggap sebagai pembunuh OpenGL yang sebenarnya. Tentu saja, kegagalan umum Komite membuat OpenGL rentan, sementara itu seharusnya merobek D3D menjadi rusak. Tetapi menurut saya, 3D Labs mungkin satu-satunya alasan posisi pasar OpenGL saat ini. Apa yang telah mereka lakukan untuk ini?

Mereka mengembangkan bahasa shader untuk OpenGL.

3D Labs adalah perusahaan yang sedang sekarat. GPU mahal mereka telah keluar dari pasar workstation oleh tekanan nVidia yang terus meningkat. Dan tidak seperti nVidia, 3D Labs tidak diperkenalkan ke pasar konsumen; Kemenangan nVidia akan berarti kematian untuk Labs 3D.

Apa yang akhirnya terjadi.

Dalam upaya untuk mengapung di dunia yang tidak membutuhkan produk mereka, 3D Labs muncul di Game Developer Conference dengan presentasi tentang apa yang mereka sebut "OpenGL 2.0." Itu adalah OpenGL API yang ditulis ulang dari awal. Dan itu masuk akal, karena pada masa itu OpenGL API penuh dengan sampah (yang, bagaimanapun, tetap ada sampai hari ini). Lihatlah setidaknya seberapa esoterik pemuatan dan pengikatan tekstur dilakukan.

Bagian dari proposal mereka adalah bahasa shader. Ya, benar. Namun, tidak seperti ekstensi lintas-platform yang ada, bahasa shader mereka adalah "tingkat tinggi" (C adalah tingkat tinggi untuk bahasa shader).

Pada saat yang sama, Microsoft sedang mengerjakan bahasa shadernya sendiri. Yang mereka, termasuk semua imajinasi kolektif mereka, disebut ... High Level Shader Language (HLSL). Tetapi pendekatan mereka terhadap bahasa pada dasarnya berbeda.

Masalah terbesar dengan 3D Labs adalah itu bisa disematkan. Microsoft sepenuhnya menentukan bahasanya sendiri. Mereka merilis kompiler yang menghasilkan kode perakitan untuk shader SM 2.0 (atau lebih tinggi), yang, pada gilirannya, dapat dimasukkan ke D3D. Pada zaman D3D v9, HLSL tidak pernah menyentuh D3D secara langsung. Dia adalah abstraksi yang baik tetapi opsional. Pengembang selalu memiliki kesempatan untuk mengambil knalpot kompiler dan mengubahnya untuk kinerja maksimum.

Lab 3D tidak memiliki semua ini. Anda memberi driver bahasa seperti-C, dan itu menciptakan shader. Itu saja. Tidak ada assembler shader, tidak ada yang bisa dimasukkan ke sesuatu yang lain. Hanya objek OpenGL yang mewakili shader.

Untuk pengguna OpenGL, ini berarti mereka rentan terhadap keinginan pengembang OpenGL yang baru saja belajar cara mengkompilasi bahasa seperti assembler. OpenGL shader language compiler (GLSL) telah mengamuk tentang bug. Lebih buruk lagi, jika Anda bisa membuat shader mengkompilasi dengan benar pada platform yang berbeda (yang dengan sendirinya merupakan pencapaian yang hebat), maka itu masih tunduk pada pengoptimal waktu yang tidak seoptimal mungkin.

Ini adalah kelemahan besar tapi bukan satu-satunya dari GLSL. Jauh dari satu-satunya.

Dalam D3D, seperti dalam bahasa assembler OpenGL lama, Anda bisa mencampur dan mencocokkan vertex dan shader fragmen dengan setiap cara yang memungkinkan. Anda bisa menggunakan vertex shader dengan shader fragmen yang kompatibel jika mereka berinteraksi melalui antarmuka yang sama. Selain itu, bahkan beberapa ketidakcocokan diizinkan: misalnya, vertex shader dapat menampilkan nilai yang tidak digunakan oleh fragmen shader.

Tidak ada yang seperti itu di GLSL. Vertikal dan fragmen shader menyatu bersama, membentuk sesuatu yang disebut Labs 3D "objek perangkat lunak". Oleh karena itu, untuk penggunaan bersama beberapa vertex dan shader fragmen dalam berbagai kombinasi, perlu untuk membuat beberapa objek program. Ini menyebabkan masalah terbesar kedua.

3D Labs mengira mereka yang paling pintar. Mereka mengambil C / C ++ sebagai dasar untuk model kompilasi GLSL. Ini adalah ketika Anda mengambil satu file-c dan mengompilasinya menjadi file objek, dan kemudian mengambil beberapa file objek dan menyusunnya menjadi sebuah program. Ini adalah bagaimana GLSL mengkompilasi: pertama Anda mengkompilasi shader vertex atau fragmen menjadi objek shader, kemudian menempatkan objek-objek ini dalam objek program dan menempatkan mereka bersama-sama untuk akhirnya membentuk sebuah program.

Secara teori, ini memungkinkan hal-hal keren seperti "perpustakaan" muncul shaders yang berisi kode yang disebut oleh shader utama. Dalam praktiknya, ini menghasilkan shader dikompilasi dua kali: Sekali pada tahap kompilasi dan kedua pada tahap kompilasi. Khususnya, kompiler dari nVidia terkenal akan hal ini. Itu tidak menghasilkan kode objek perantara; dia menyusun di awal, membuang hasilnya dan menyusun lagi pada tahap kompilasi.

Dengan demikian, untuk melampirkan vertex shader ke dua shader fragmen yang berbeda, perlu untuk mengkompilasi lebih banyak daripada di D3D. Terutama mengingat bahwa seluruh kompilasi dilakukan secara offline , dan tidak sebelum program dijalankan secara langsung.

GLSL memiliki masalah lain. Mungkin salah untuk menyalahkan semua kesalahan pada Lab 3D, karena pada akhirnya ARB menyetujui dan memasukkan bahasa shader di OpenGL (tapi tidak ada yang lain dari saran 3DLabs). Namun, ide awalnya masih untuk Labs 3D.

Dan sekarang yang paling menyedihkan: Labs 3D benar (kebanyakan). GLSL bukan bahasa vektor seperti HLSL pada waktu itu. Ini terjadi karena perangkat keras Lab 3D adalah skalar (seperti perangkat keras modern dari nVidia), dan mereka sepenuhnya benar dalam memilih arah yang diikuti oleh banyak produsen peralatan.

Mereka benar dengan pilihan model kompilasi untuk bahasa "tingkat tinggi". Bahkan D3D akhirnya sampai pada ini.

Masalahnya adalah bahwa Lab 3D benar pada waktu yang salah . Dan dalam upaya untuk masuk ke masa depan sebelum waktunya, dalam upaya untuk siap menghadapi masa depan, mereka mengesampingkan masa kini. Sepertinya fungsi T&L di OpenGL, yang selalu ada di dalamnya. Kecuali pipa T&L OpenGL bermanfaatdan sebelum munculnya perangkat keras T&L, GLSL menjadi beban sebelum seluruh dunia menyusulnya.

GLSL adalah bahasa yang baik sekarang . Tetapi apa yang pada waktu itu? Dia mengerikan. Dan OpenGL menderita karenanya.

Dalam perjalanan ke pendewaan

Saya mendukung pandangan bahwa Labs 3D memberikan pukulan mematikan bagi OpenGL, tetapi paku terakhir di peti mati itu dicetak oleh ARB sendiri.

Anda mungkin pernah mendengar cerita ini. Pada zaman OpenGL 2.1, OpenGL memiliki masalah besar. Dia membawa banyak kompatibilitas. API tidak lagi mudah digunakan. Satu hal dapat dilakukan dengan lima cara berbeda dan tidak jelas mana yang lebih cepat. Anda dapat "mempelajari" OpenGL dengan tutorial sederhana, tetapi Anda tidak mempelajari OpenGL yang memberikan kekuatan dan kinerja grafis yang sebenarnya.

ARB memutuskan untuk membuat upaya lain untuk menciptakan OpenGL. Itu seperti "OpenGL 2.0" dari 3D Labs, tetapi lebih baik karena ARB berada di balik upaya ini. Mereka menyebutnya "Longs Peak."

Apa yang buruk tentang menghabiskan sedikit waktu memperbaiki API? Berita buruknya adalah Microsoft berada dalam posisi yang agak genting. Ini adalah waktu untuk meningkatkan ke Vista.

Di Vista, Microsoft memutuskan untuk membuat perubahan yang lama tertunda untuk driver grafis. Mereka memaksa para pengemudi untuk beralih ke OS untuk virtualisasi memori grafis dan banyak lainnya.

Anda dapat berdebat lama tentang manfaat pendekatan ini, dan apakah itu mungkin, tetapi faktanya tetap: Microsoft membuat D3D 10 hanya untuk Vista dan lebih tinggi. Bahkan pada perangkat keras yang kompatibel dengan D3D, tidak mungkin menjalankan aplikasi D3D tanpa Vista.

Anda mungkin ingat bahwa Vista ... katakanlah itu tidak bekerja dengan baik. Jadi, kami memiliki OS yang santai, API baru yang hanya berfungsi pada OS ini, dan generasi perangkat keras baru yang membutuhkan API dan OS ini untuk melakukan sesuatu yang lebih dari sekadar melampaui kinerja generasi sebelumnya.

Namun, pengembang dapat menggunakan fungsionalitas D3D 10 level melalui OpenGL. Yaitu, mereka bisa jika ARB tidak sibuk mengerjakan Long Peaks.

ARB menghabiskan waktu satu setengah hingga dua tahun untuk memperbaiki API. Pada saat OpenGL 3.0 dirilis, transisi ke Vista telah berakhir, Windows 7 sedang dalam perjalanan, dan pengembang game tidak lagi peduli dengan fungsi D3D 10. Pada akhirnya, peralatan untuk D3D 10 bekerja dengan baik dengan aplikasi pada D3D 9. Dengan peningkatan kecepatan porting dari PC ke PC konsol (atau dengan transisi pengembang PC ke pasar konsol), semakin sedikit pengembang yang membutuhkan fungsionalitas D3D 10.

Jika pengembang bisa mendapatkan akses ke fungsi ini bahkan pada Windows XP, pengembangan OpenGL bisa mendapatkan biaya vivacity seumur hidup. Tetapi ARB melewatkan kesempatan ini. Apakah Anda ingin tahu apa yang terburuk?

ARB gagalciptakan API dari awal meskipun menghabiskan dua tahun yang berharga untuk mencoba melakukannya. Oleh karena itu, mereka mengembalikan status quo, hanya menambahkan mekanisme untuk menyatakan fungsionalitas usang.

Akibatnya, ARB tidak hanya melewatkan peluang utama , tetapi juga gagal melakukan pekerjaan yang menyebabkan mereka kehilangan ini. Itu adalah kegagalan epik ke segala arah.

Ini adalah kisah konfrontasi antara OpenGL dan Direct3D. Kisah tentang peluang yang terlewatkan, kebodohan terbesar, kesembronoan yang disengaja dan absurditas yang dangkal.