👆🏻 🖕🏽 👨🏾‍⚕️ Direct3D vs OpenGL: تاريخ المواجهة 🤚🏿 🤞 ☝🏽

حتى يومنا هذا ، هناك جدل على الإنترنت حول واجهة برمجة تطبيقات الرسومات الأفضل: Direct3D أو OpenGL؟ على الرغم من طبيعتها الدينية ، فإن هذه المعارك الكلامية تجلب نتائج مفيدة في شكل مراجعات تاريخية جيدة لتطوير الرسومات المعجلة للأجهزة.

الصورة

الغرض من هذا المنشور هو ترجمة إحدى هذه الرحلات إلى التاريخ.كتبه Jason L. McKesson رداً على السؤال "لماذا يفضل مطورو الألعاب Windows." من غير المرجح أن يجيب هذا النص على السؤال المطروح ، لكنه يصف تاريخ التطور والمواجهة بين أكثر واجهات برمجة التطبيقات الرسومية شيوعًا بطريقة ملونة للغاية ومفصلة إلى حد ما ، لذلك احتفظت بترميز المؤلف في الترجمة. تمت كتابة النص في منتصف عام 2011 ويغطي فترة زمنية تبدأ قبل وقت قصير من ظهور Direct3D وحتى وقت الكتابة. مؤلف النص الأصلي هو مطور ألعاب ذو خبرة ، ومشارك نشط في StackOverflow ، ومبتكر كتاب مدرسي واسع حول برمجة الرسومات ثلاثية الأبعاد الحديثة. لنعطي الكلمة لجيسون.

مقدمة

قبل أن نبدأ ، أود أن أقول إنني أعرف المزيد عن OpenGL أكثر من Direct3D. في حياتي لم أكتب سطرًا واحدًا من التعليمات البرمجية في D3D ، لكني كتبت أدلة OpenGL. لكن ما أريد أن أتحدث عنه ليس مسألة تحيز ، بل مسألة تاريخ.

ولادة الصراع

ذات مرة ، في بداية التسعينات ، نظرت Microsoft حولها. لقد رأوا أن SNES و Sega Genesis رائعان للغاية ، يمكنك لعب الكثير من ألعاب الحركة وكل ذلك. ورأوا دوس. كتب المطورون ألعاب dosovskie كوحدة تحكم: بالقرب من المكواة. ومع ذلك ، على عكس وحدات التحكم ، حيث يعرف المطور نوع الأجهزة التي سيحصل عليها المستخدم ، اضطر مطورو دوس للكتابة تحت العديد من التكوينات. وهذا أكثر تعقيدًا مما يبدو.

لكن لدى مايكروسوفت مشكلة أكبر: ويندوز. كما ترى ، أراد Windows امتلاك الجهاز بالكامل ، على عكس DOS ، مما سمح للمطورين بفعل أي شيء. حيازة الحديد ضروري للتفاعل بين التطبيقات. لكن هذا النوع من التفاعل هو بالضبط ما يكرهونه.مطوري الألعاب لأنه يستهلك موارد ثمينة يمكنهم استخدامها لجميع أنواع الأشياء الرائعة.

لتعزيز تطوير الألعاب على Windows ، احتاجت Microsoft إلى واجهة برمجة تطبيقات موحدة ذات مستوى منخفض ، وستعمل على Windows دون فقدان الأداء ، وستكون متوافقة مع الأجهزة المختلفة . واجهة برمجة تطبيقات واحدة لأجهزة الرسومات والصوت والإدخال.

لذلك ولدت دايركت.

ظهرت مسرعات 3D بعد بضعة أشهر. ووقعت مايكروسوفت في مشكلة. والحقيقة هي أن DirectDraw ، وهو مكون رسومي من DirectX ، عمل فقط مع رسومات ثنائية الأبعاد: فقد خصص ذاكرة رسومات وقام بعمليات بت سريعة بين قطاعات مختلفة من الذاكرة.

لذلك ، اشترت Microsoft بعض برامج الجهات الخارجية وحولتها إلى Direct3D الإصدار 3. تم توبيخهكل شيء على الإطلاق . وكان هناك سبب: قراءة الكود على D3D v3 بدا وكأنه فك تشفير اللغة المكتوبة لحضارة قديمة منقرضة.

نظر الرجل العجوز جون كارماك في Id Software إلى هذا الخزي ، وقال "نعم ذهب ..." ، وقرر الكتابة باستخدام واجهة برمجة تطبيقات أخرى: OpenGL.

ومع ذلك ، كان الجانب الآخر من هذه القصة المربكة هو أن Microsoft عملت مع SGI لتطبيق OpenGL لنظام التشغيل Windows. كانت الفكرة هي جذب مطوري تطبيقات GL النموذجية لمحطات العمل: CAD وأنظمة النمذجة وما شابه ذلك. كانت الألعاب هي آخر شيء اعتقدوا. يتعلق هذا بشكل أساسي بنظام التشغيل Windows NT ، ولكن Microsoft قررت إضافة برنامج OpenGL إلى نظام التشغيل Windows 95 أيضًا.

لجذب مطوري البرامج لمحطات العمل على Windows ، قررت Microsoft رشوتهم بالوصول إلى المسرعات ثلاثية الأبعاد الجديدة. لقد قاموا بتطبيق بروتوكول لبرامج تشغيل العميل المثبتة: يمكن لبطاقة الرسوميات استبدال برنامج Microsoft OpenGL بتطبيق الأجهزة الخاصة بهم. استخدم الرمز تلقائيًا برنامج OpenGL للأجهزة ، إذا كان متاحًا.

ومع ذلك ، في تلك الأيام لم يكن لبطاقات الرسومات الاستهلاكية دعم OpenGL. هذا لم يمنع Carmack من نقل Quake إلى OpenGL على محطة عمل SGI. في الملف التمهيدي لـ GLQuake ، يمكنك قراءة ما يلي:

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

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

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

كان هذا ولادة سائقي miniGL. لقد تطوروا في النهاية إلى تطبيقات OpenGL كاملة بمجرد أن يصبح الجهاز قويًا بما يكفي لدعم هذه الوظيفة في الأجهزة. كانت nVidia أول من قدم تطبيقًا كاملاً لبرنامج OpenGL. كان الباعة الآخرون لا يزالون بطيئين ، وهو أحد أسباب الانتقال إلى Direct3D ، مدعومًا بمجموعة واسعة من المعدات. في النهاية ، بقي فقط nVidia و ATI (وهو الآن AMD) ، وكان لكل منهما تطبيقات OpenGL جيدة.

فجر OpenGL

لذلك ، يتم تعريف المشاركين: Direct3D ضد OpenGL. هذه حقا قصة مدهشة ، بالنظر إلى مدى سوء D3D v3.

إن مجلس المراجعة المعمارية OpenGL (ARB) هو المنظمة المسؤولة عن صيانة وتطوير OpenGL. يطلقون العديد من الإضافات ، ويحتوي على مستودع بالامتدادات ، وينشئون إصدارات جديدة من API. ARB هي لجنة مكونة من عدد كبير من اللاعبين في صناعة رسومات الكمبيوتر وبعض الشركات المصنعة لأنظمة التشغيل. كانت Apple و Microsoft عضوين في ARB في أوقات مختلفة.

3Dfx يدخل المشهد مع Voodoo2. هذه هي أول بطاقة فيديو تسمح لك بالقيام بتعدد العناصر ، والتي لم تكن متوفرة مسبقًا في OpenGL. بينما كانت 3Dfx تعارض بشدة OpenGL ، فإن nVidia ، الشركة المصنعة التالية لشريحة multitexturing (TNT1) ، كانت مجنونة حول OpenGL. ثم أطلق ARB امتداد GL_ARB_multitexture ، والذي وفر الوصول إلى مواد متعددة.

وفي الوقت نفسه ، يظهر Direct3D v5. الآن أصبحت D3D بالفعل واجهة برمجة تطبيقات ، وليس نوعًا من الهراء. ما هي المشكلة؟ في غياب التعدد.

عفوًا

لكن هذا لم يتسبب في أي إزعاج يمكن أن يحققه ، لأنه لم يستخدم أحد تقريبًا التركيب المتعدد. لا يضر التعدد المتعدد بالأداء تقريبًا ، وفي كثير من الحالات يكون الفرق غير مرئي على خلفية التمريرات المتعددة. وبالطبع ، فإن مطوري الألعاب مغرمون جدًا بألعابهم التي تعمل بثقة على الأجهزة القديمة ، والتي لم يكن لديها دعم لأنماط متعددة ، لذلك تم إصدار العديد من الألعاب بدونها.

تنفس D3D الصعداء.

مر الوقت ، وطرح nVidia GeForce 256 (لا ينبغي الخلط بينه وبين أول GeForce GT-250) ، مما أدى إلى إيقاف الصراع في سوق بطاقات الرسومات للسنتين القادمتين. كانت الميزة التنافسية الرئيسية لهذه اللوحة هي القدرة على إجراء تحويلات للقمم والإضاءة (التحويل والإضاءة ، T & L) في الأجهزة. ولكن هذا ليس كل شيء: أحب نفيديا برنامج OpenGL لدرجة أن من T & L محرك فعلا كان برنامج OpenGL. تقريبا حرفيا! كما أفهمها ، تلقت بعض سجلاتهم قيمًا رقمية مباشرة لمتغيرات من نوع GLenum.

يخرج Direct3D v6. أخيرًا ، وصل التركيب المتعدد في الوقت المناسب ... ولكن بدون أجهزة T&L. برنامج OpenGL دائمًاكان هناك خط أنابيب T & L ، على الرغم من أنه قبل GeForce 256 تم تنفيذه في البرنامج. لذلك ، بالنسبة لـ nVidia ، اتضح أنه من السهل جدًا إعادة تطبيق البرنامج في حل الأجهزة. في D3D ، ظهرت الأجهزة T&L في الإصدار السابع فقط.

فجر عصر شادر ، OpenGL في الظلام

ثم جاءت GeForce 3. في نفس الوقت ، حدثت العديد من الأشياء المثيرة للاهتمام.

قررت مايكروسوفت أنها لن تكون متأخرة. لذلك ، بدلاً من النظر إلى ما ستفعله nVidia ونسخ تطورها بالفعل بعد انتهاء العملية ، اتخذت Microsoft قرارًا مذهلاً: اذهب وتحدث. ووقعوا في الحب ، وحصلوا على وحدة تحكم صغيرة مشتركة.

حدث الطلاق الصاخب لاحقًا ، لكن هذه قصة مختلفة تمامًا.

بالنسبة لسوق الكمبيوتر الشخصي ، هذا يعني أن GeForce 3 خرج في وقت واحد مع D3D v8 ، ومن السهل أن نرى كيف أثرت GeForce 3 على تظليل D3D v8. كانت تظليل بكسل نموذج Shader 1.0 جداًشحذ بشكل كبير لمعدات nVidia. لم يتم القيام بمحاولة واحدة لفعل أي شيء لاستخراج nVidia من الحديد. Shader Model 1.0 هو ما تم تصميمه لـ GeForce 3.

عندما اخترقت ATI سباق أداء الرسومات مع Radeon 8500 ، كانت هناك مشكلة واحدة. تبين أن خط الأنابيب Radeon 8500 بكسل أقوى من nVidia. لذلك ، أصدرت Microsoft نموذج Shader 1.1 ، والذي كان في الأساس هدف 8500.

يبدو وكأنه هزيمة D3D ، لكن النجاح والفشل عبارة عن مصطلحات نسبية. في الواقع ، ينتظر فشل ملحمي OpenGL.

كانت NVidia مغرمة جدًا بـ OpenGL ، لذلك بعد إصدار GeForce 3 ، أصدرت مجموعة كاملة من الامتدادات لـ OpenGL. ملكيةملحقات عملت فقط على نفيديا. بطبيعة الحال ، عندما ظهر مجلس 8500 ، لم يتمكن من استخدام أي منها.

لذا ، في D3D 8 ، يمكنك تشغيل SM 1.0 shaders على الأقل. بالطبع ، من أجل استخدام كل برودة 8500 ، اضطررت إلى كتابة تظليل جديد ، ولكن الرمز يعمل على الأقل .

للحصول على أي تظليل على Radeon 8500 في OpenGL ، كان على ATI تطوير العديد من الامتدادات لـ OpenGL. ملحقات الملكية التي عملت فقط على ATI. ونتيجة لذلك ، حتى يتمكن المطورون من التصريح بأنهم قاموا بربط التظليل بمحركهم ، كان عليهم كتابة رمز منفصل لـ nVidia ورمز منفصل لـ ATI.

قد تسأل: "وأين كانت لجنة ARB التي يجب أن تدعم OpenGL طافية؟" وحيث انتهى الأمر بالكثير من اللجان: جلست وغباء.

يرجى ملاحظة ، لقد ذكرت ARB_multitexture أعلاه لأن هذا التمديد متورط بعمق في الوضع برمته. بدا للمراقب الخارجي أن ARB يريد عمومًا تجنب فكرة التظليل. قرروا أنه إذا قاموا بحقن ما يكفي من التكوين في خط أنابيب ثابت ، فإنه سيعادل قدراته مع خط أنابيب تظليل قابل للبرمجة.

صدر ARB ملحقات واحدة تلو الأخرى. كان كل امتداد يحتوي على الكلمات "نسيج_إرسال" في الاسم محاولة لإصلاح هذا التصميم القديم. انظر إلى قائمة الملحقات: تم إصدار ثمانية ملحقات من هذا القبيلوقد تم ترجمة العديد منها إلى وظائف OpenGL الأساسية.

في ذلك الوقت ، كانت Microsoft جزءًا من ARB ، وتركتها فقط لإصدار D3D 9 ، لذلك ربما قامت Microsoft بتخريب OpenGL بطريقة ما. أنا شخصياً أشك في هذه النظرية لسببين. أولاً ، سيتعين عليهم تأمين دعم أعضاء اللجنة الآخرين ، لأن لكل عضو صوت واحد فقط. ثانيًا ، والأهم من ذلك ، لم تكن اللجنة بحاجة إلى مساعدة Microsoft لإفساد كل شيء ، وهو دليل سنراه لاحقًا.

ونتيجة لذلك ، استيقظ ARB ، على الأرجح تحت ضغط من ATI و nVidia (كلاهما مشاركان نشطان) ، وأخيرًا أدخل تظليل المجمع في المعيار.

تريد قصة أكثر غرابة؟

الأجهزة T&L. هذا ما كان OpenGL في الأصل.. للحصول على أعلى أداء ممكن للأجهزة T&L ، تحتاج إلى تخزين بيانات الرأس على وحدة معالجة الرسومات. ومع ذلك ، فإن GPU هي المستهلك الرئيسي لبيانات القمة.

في الإصدار D3D v7 ، قدمت شركة Microsoft مفهوم المخازن المؤقتة للرأس ، والتي تخصص قطعًا كبيرة من الذاكرة في وحدة معالجة الرسومات وتضع بيانات الرأس الأعلى هناك.

هل تريد أن تعرف متى ظهرت الوظائف المكافئة في OpenGL؟ نعم ، أصدرت nVidia ، بصفتها أكبر معجبين لـ OpenGL ، امتدادها لتخزين صفائف الذروة على وحدة معالجة الرسومات في وقت إصدار GeForce 256. ولكن متى قدم ARB مثل هذه الوظيفة؟

بعد ذلك بعامين. كان بعد ذلكحول كيفية اعتمادها للظلال الرأسية والجزء (بكسل من حيث D3D). لقد استغرق ARB الكثير من الوقت لتطوير حل عبر الأنظمة الأساسية لتخزين بيانات الرأس في ذاكرة GPU. وهذا ما تحتاجه الأجهزة T&L لتحقيق أقصى أداء.

لغة واحدة لقتلهم جميعا

لذلك ، تم كسر برنامج OpenGL لبعض الوقت. لم يكن هناك تظليل عبر الأنظمة الأساسية وتخزين قمة مستقل للأجهزة في وحدة معالجة الرسومات ، بينما استمتع مستخدمو D3D بكليهما. هل يمكن أن تسوء؟

يمكنك القول أنه يمكن. Meet: 3D Labs .

تسأل: من هم؟ إنها شركة ميتة أعتبرها القاتل الحقيقي لـ OpenGL. بالطبع ، جعل الفشل العام للجنة برنامج OpenGL ضعيفًا ، في حين كان من المفترض أن يمزق D3D إلى أشلاء. ولكن في رأيي ، ربما تكون مختبرات 3D هي السبب الوحيد لموقف OpenGL الحالي في السوق. ماذا فعلوا لهذا؟

طوروا لغة تظليل لـ OpenGL.

كانت 3D Labs شركة تحتضر. تم طرد وحدات معالجة الرسومات الخاصة بهم باهظة الثمن من سوق محطات العمل بسبب الضغط المتزايد من nVidia. وعلى عكس nVidia ، لم يتم تقديم مختبرات 3D إلى سوق المستهلك ؛ فوز nVidia سيعني الموت لـ 3D Labs.

ما حدث في النهاية.

في محاولة لتكون طافية في عالم لا يحتاج إلى منتجاتها ، ظهرت 3D Labs في مؤتمر مطوري الألعاب مع عرض تقديمي لما أطلقوا عليه "OpenGL 2.0". لقد تم إعادة كتابة OpenGL API من البداية. وهذا منطقي ، لأنه في تلك الأيام كانت واجهة برمجة تطبيقات OpenGL مليئة بالقمامة (والتي ، مع ذلك ، لا تزال موجودة حتى يومنا هذا). انظر على الأقل إلى الكيفية التي يتم بها تحميل القوام وربطه بشكل خفي.

جزء من اقتراحهم كان لغة شادر. نعم هو كذلك. ومع ذلك ، على عكس الامتدادات الحالية عبر الأنظمة الأساسية ، كانت لغة التظليل الخاصة بهم "مستوى عال" (C مستوى عالٍ للغة التظليل).

في الوقت نفسه ، كانت Microsoft تعمل على لغة تظليل خاصة بها. التي أطلقوا عليها ، بما في ذلك جميع خيالهم الجماعي ، ... High Shader Language (HLSL). لكن نهجهم في اللغة كان مختلفًا بشكل أساسي.

كانت أكبر مشكلة في 3D Labs هي أنه يمكن تضمينها. حددت Microsoft لغتها الخاصة تمامًا. لقد أصدروا مترجمًا أنشأ رمز التجميع لـ SM 2.0 shader (أو أعلى) ، والذي بدوره يمكن تغذيته إلى D3D. في أيام D3D v9 ، لم تلمس HLSL D3D مباشرة. لقد كان تجريدًا جيدًا ولكنه اختياري. كان لدى المطور دائمًا فرصة لأخذ عادم المترجم وتعديله للحصول على أقصى أداء. لم يكن لدى

3D Labs أيًا من هذا. أنت تعطي السائق لغة تشبه لغة C ، ويخلق تظليلًا. هذا كل شيء. لا تظليل المجمع ، لا شيء يمكن إطعامه لشيء آخر. فقط كائن OpenGL يمثل تظليل.

بالنسبة لمستخدمي OpenGL ، هذا يعني أنهم كانوا عرضة لأهواء مطوري OpenGL الذين تعلموا للتو كيفية تجميع اللغات الشبيهة بالمجمع. كان مترجمو لغة تظليل OpenGL (GLSL) مستعدين حول الأخطاء. لجعل الأمور أسوأ ، إذا كنت قادرًا على جعل التظليل يجمع بشكل صحيح على منصات مختلفة (وهو في حد ذاته كان إنجازًا رائعًا) ، فقد كان لا يزال خاضعًا للمحسنين في تلك الأوقات التي لم تكن على النحو الأمثل.

كان هذا عيبًا كبيرًا ولكن ليس العيب الوحيد لـ GLSL. بعيد عن الوحيد.

في D3D ، كما هو الحال في لغات التجميع OpenGL القديمة ، يمكنك مزج وتطابق قمة الرأس وتظليل الأجزاء بكل طريقة ممكنة. يمكنك استخدام أي تظليل قمة الرأس مع أي تظليل جزء متوافق إذا تفاعلوا من خلال نفس الواجهة. علاوة على ذلك ، تم السماح ببعض عدم التوافق: على سبيل المثال ، يمكن أن ينتج جهاز تظليل الرأس قيمة لم يتم استخدامها بواسطة جهاز تظليل الجزء.

لم يكن هناك شيء من هذا القبيل في GLSL. اندمج تظليل الرأس والجزء معًا ، مشكلين شيئًا يسمى 3D Objects "كائن برنامج". لذلك ، من أجل الاستخدام المشترك للعديد من تظليل الرأس والجزء في مجموعات مختلفة ، كان من الضروري إنشاء العديد من كائنات البرنامج. تسبب هذا في ثاني أكبر مشكلة.

اعتقدت 3D Labs أنها الأذكى. أخذوا C / C ++ كأساس لنموذج تجميع GLSL. يحدث ذلك عند أخذ ملف c واحد وتجميعه في ملف كائن ، ثم أخذ العديد من ملفات الكائنات وتكوينها في برنامج. هذه هي الطريقة التي يجمع بها GLSL: أولاً تقوم بتجميع الرأس أو التظليل الجزئي في كائن تظليل ، ثم تضع هذه الكائنات في كائن برنامج وتجميعها معًا لتشكيل برنامج في النهاية.

من الناحية النظرية ، سمح هذا لأشياء باردة مثل تظليل "المكتبة" بالظهور التي تحتوي على رمز يسمى التظليل الرئيسي. من الناحية العملية ، أدى هذا إلى تجميع تظليل مرتين: مرة واحدة في مرحلة التجميع ومرة ثانية في مرحلة التجميع. على وجه الخصوص ، كان المترجم من nVidia مشهورًا بذلك. لم يتم إنشاء أي رمز كائن متوسط؛ قام بالتجميع في البداية ، ورمي النتيجة وجمع مرة أخرى في مرحلة التجميع.

وبالتالي ، من أجل إرفاق تظليل الرأس إلى اثنين من تظليل الشظايا المختلفة ، كان من الضروري تجميع أكثر بكثير من D3D. خاصة بالنظر إلى أن التجميع بأكمله يتم دون اتصال بالإنترنت ، وليس قبل تنفيذ البرنامج مباشرة.

واجهت GLSL مشاكل أخرى. ربما سيكون من الخطأ إلقاء اللوم على كل خطأ في 3D Labs ، لأنه في النهاية وافق ARB على لغة التظليل في OpenGL وتضمينها (ولكن لا شيء آخر من اقتراحات 3DLabs). ومع ذلك ، كانت الفكرة الأصلية لا تزال مختبرات ثلاثية الأبعاد.

والآن الشيء الأكثر حزنًا: مختبرات 3D كانت على حق (في الغالب). GLSL ليست لغة متجهة مثل HLSL في ذلك الوقت. حدث هذا لأن أجهزة 3D Labs كانت قياسية (مثل الأجهزة الحديثة من nVidia) ، وكانوا على حق تمامًا في اختيار الاتجاه الذي اتبعته العديد من الشركات المصنعة للمعدات في وقت لاحق.

كانوا على حق في اختيار نموذج التجميع للغة "عالية المستوى". حتى D3D جاء أخيرًا إلى هذا.

تكمن المشكلة في أن مختبرات 3D كانت صحيحة في الوقت الخطأ . وفي محاولات الدخول إلى المستقبل قبل الأوان ، في محاولات الاستعداد للمستقبل ، وضعوا الحاضر جانباً. يبدو أن وظيفة T & L في OpenGL ، كانت دائمًا موجودة فيها. باستثناء خط أنابيب OpenGL T&L كان مفيدًاوقبل ظهور T&L للأجهزة ، كان GLSL عبئًا قبل أن يلتحق به بقية العالم.

GLSL هي لغة جيدة الآن . لكن ماذا كان في ذلك الوقت؟ لقد كان فظيعًا. وعانى برنامج OpenGL من هذا.

في الطريق الى التأليه

أنا أؤيد الرأي القائل بأن 3D Labs وجهت ضربة قاتلة لـ OpenGL ، ولكن آخر مسمار في التابوت سجله ARB نفسه.

ربما سمعت هذه القصة. في أيام OpenGL 2.1 ، كان لـ OpenGL مشاكل كبيرة. وجره وراء ضخمة البضائع التوافق. لم يعد API سهل الاستخدام. يمكن القيام بشيء واحد بخمس طرق مختلفة وليس من الواضح أيهما أسرع. يمكنك "تعلم" برنامج OpenGL من خلال برامج تعليمية بسيطة ، ولكنك لم تتعلم برنامج OpenGL الذي يوفر قوة وأداء رسومات حقيقية.

قرر ARB لإجراء محاولة أخرى لاختراع OpenGL. كان مثل "OpenGL 2.0" من 3D Labs ، ولكن الأفضل لأن ARB كان وراء هذه المحاولة. أطلقوا عليه اسم "Longs Peak".

ما هو السيء في قضاء بعض الوقت في تحسين واجهة برمجة التطبيقات؟ الأخبار السيئة هي أن Microsoft في وضع غير مستقر إلى حد ما. كان هذا هو الوقت المناسب للترقية إلى Vista.

في Vista ، قررت Microsoft إجراء تغييرات طال انتظارها على برامج تشغيل الرسومات. أجبروا السائقين على اللجوء إلى نظام التشغيل لمحاكاة الذاكرة الرسومية وغيرها الكثير.

يمكنك أن تجادل لفترة طويلة حول مزايا هذا النهج ، وما إذا كان ذلك ممكنًا ، ولكن الحقيقة تبقى: جعلت Microsoft D3D 10 فقط لنظام التشغيل Vista والإصدارات الأحدث. حتى على الأجهزة المتوافقة مع D3D ، كان من المستحيل تشغيل تطبيق D3D بدون Vista.

قد تتذكر أن Vista ... لنفترض أنه لم يعمل جيدًا. لذلك ، كان لدينا نظام تشغيل مريح ، وواجهة برمجة تطبيقات جديدة تعمل فقط على نظام التشغيل هذا ، وجيل جديد من الأجهزة التي تحتاج إلى واجهة برمجة التطبيقات ونظام التشغيل هذا للقيام بأكثر من مجرد تجاوز الجيل السابق في الأداء.

ومع ذلك ، يمكن للمطورين استخدام وظائف مستوى D3D 10 من خلال OpenGL. أي أنها يمكن أن تكون إذا لم تكن ARB مشغولة في العمل على Long Peaks.

أمضى ARB سنة ونصف جيدة إلى عامين في العمل على تحسين API. بحلول الوقت الذي تم فيه إصدار OpenGL 3.0 ، كان الانتقال إلى Vista قد انتهى ، وكان Windows 7 في الطريق ، ولم يعد مطورو الألعاب يهتمون بوظيفة D3D 10. في النهاية ، عملت معدات D3D 10 بشكل مثالي مع التطبيقات على D3D 9. مع زيادة وتيرة النقل من الكمبيوتر إلى وحدة التحكم (أو مع انتقال مطوري أجهزة الكمبيوتر إلى سوق وحدة التحكم) ، كان المطورون بحاجة إلى وظائف D3D 10. ويحتاجون إلى وظائف أقل حتى

إذا تمكن المطورون من الوصول إلى هذه الوظيفة حتى على نظام التشغيل Windows XP ، فإن تطوير OpenGL يمكن أن يحصل على حيوية من الحياة. لكن ARB أضاع هذه الفرصة. هل تريد أن تعرف ما هو الأسوأ؟ فشل

ARBاختراع واجهة برمجة التطبيقات من الصفر على الرغم من قضاء عامين ثمين في محاولة القيام بذلك. لذلك ، أعادوا الوضع الراهن ، مضيفين فقط آلية لإعلان الوظيفة عفا عليها الزمن.

ونتيجة لذلك ، لم تضيع ARB الفرص الرئيسية فحسب ، بل فشلت أيضًا في القيام بالعمل الذي أدى بهم إلى هذا الإغفال. لقد كان فشلًا ملحميًا في جميع الاتجاهات.

هذه هي قصة المواجهة بين OpenGL و Direct3D. قصة الفرص الضائعة ، الغباء الأكبر ، التهور المتعمد والسخافات البالية.