Вибір основного мови програмування і графічної бібліотеки для реалізації програм

Історія створення основних графічних бібліотек

Щоб краще зрозуміти, чого можна чекати від реалізації обох API, звернемося до витоків їх створення. Огляд історії проливає світло на те, чи є якісь принципові відмінності між початковою реалізацією даних бібліотек.

Відкрита Графічна Бібліотека знайшла своє застосування в багатьох областях (не тільки ігрової індустрії), і вже 18 років залишається затребуваною.

Основні принципи роботи графічних бібліотек

Малюнок 2. Загальна схема роботи графічної бібліотеки OpenGL.

На малюнку 1 показані основні компоненти графічної бібліотеки OpenGL і їх взаємодія. Для роботи з бібліотекою програма спочатку повинна відкрити вікно у framebuffer (де буде відбуватися всі операції), і потім вже контекст бібліотеки зв'язується з цим вікном. Таку операцію потрібно виконати один раз, а далі все дії визначаються через параметри обробки (малювання простих геометричних об'єктів: лінії, точки, полігони; рендеринг примітивів, включаючи їх положення і колір).

Сама ж бібліотека реалізована у вигляді інформації про структуру, яка визначає, як об'єкти будуть намальовані у framebuffer, причому деякі з структур доступні користувачеві, який може створювати різні виклики процедур для зміни параметрів.

Трохи вище були розглянуті основні принципи роботи бібліотеки, далі буде розглянуто простий приклад - малювання текстурированной піраміди засобами OpenGL. Для цього потрібно базові поняття, що вимагаються для виконання цього завдання:

Vertex (вершини) - утворюються після вказівки координат в 2-х, 3-х або 4-вимірному просторі. У разі даного прикладу задаються чотири координати в 3D просторі, які позначають вершини фігури.

Vertex Arrays (масив вершин) - для роботи з безліччю вершин потрібно обробляти велику кількість команд (для утворення простих геометричних фігур), щоб уникнути непотрібної обчислювального навантаження існує об'єднання вершин. В даному випадку з них утворюється масив, який міститься в пам'яті. Для роботи з пірамідою в цілому вершини об'єднуються під єдиним ім'ям.

Evaluators - кошти для множинних перетворення координат і кольору. Після створення чотирьох вершин визначаються команди для обробки (які записуються в Display List) і проводяться усереднення і прорахунок геометричній поверхні (на цьому кроці вже з'являється каркас об'єкта).

Coordinate Transformation (трансформація координат) - всі об'єкти перед виведенням у framebuffer зазнають зміна своїх координат (з їх програмного уявлення в «віконне» для framebuffer), схема такого перетворення представлена ​​на малюнку 2. Причому в цей момент відбувається підготовка до растеризації (обрізаються зайві частини фігури, які вилазять за екран).

Малюнок 3. Виконання растеризации і інтерполяції графічною бібліотекою OpenGL.

Даний API є комплексною бібліотекою, яка містить в собі програмні інтерфейси з обробки не тільки графіки. В рамках даної роботи розглядається тільки графічну частину бібліотеки.

Щоб почати працювати з графічною бібліотекою, потрібно відкрити вікно програми, але далі потрібно також створити пристрій відтворення і тим самим зробити ініціалізацію Direct3D. Після виконання цього кроку йде процес прорахунку і відображення сцени. Ланцюжок перетворень, необхідних для відображення деякого об'єкту, показана на малюнку 3.

Малюнок 3. Покрокове виконання відображення об'єкта в графічній бібліотеці DirectX.

Для створення сцени потрібно форматувати D3D об'єкт для малювання, включаючи створення об'єкта, вказівку параметрів відображення, створення D3D пристрою, причому в параметрах пристрою можна вказати спосіб обробки вершин - апаратний або програмний. Далі виробляються схожі з OpenGL перетворення, але з урахуванням того, що всі операції працюють над об'єктами. При завершенні програми потрібно закрити пристрій, але на ділі цей процес все ж виглядає трохи складніше. В рамках даної роботи не будуть розглянуті такі детальні подробиці, оскільки завершення програми не впливає на враження користувача від швидкості і динаміки відображення моделі. Виходячи їх цього факту, можна досить ліберально поставитися до коректності і швидкості завершення програми, тим більше що в рамках managed-мов програмування це не так актуально.

Малюнок 4. Відображення фігури по її вершин і з'єднанням між ними в графічній бібліотеці DirectX.

У нових версіях DirectX з'явилися додаткові можливості, які збільшують реалістичність графіки:

HLSL (High-Level Shader Language - Високорівнева Мова шейдера) - дозволяє управляти потоком команд;

Контроль над виконанням шейдеров;

Взаємодія з GDI (Graphics Device Interface);

Підтримка заміщають карт (Displacement mapping) - зміна координат полігону;

Підтримка 40-бітного кольору (більше 1.0 млрд. Кольорів).

Pixel Shaders - це невеликі підпрограми (виконуються на графічному процесорі), які працюють з кожним пікселем при створенні текстури і застосовуються для прорахунку світла, створення різних ефектів. У самій бібліотеці OpenGL вони відсутні через те, що, коли створювалася специфікація, шейдери ще не були придумані, і тому вони були включені в вигляді розширень.

Architectural Review Board (ARB - Комітет Перегляду Архітектури), куди входять такі відомі компанії як 3D Labs, SGI, Apple, nVIDIA, ATi, Intel, id Software, Microsoft.
Влаштували манаполію відкрили б архітектуру карти навіщо нам їхнє «обстрагірованніе» Графіка розвивається зі швидкістю цих Біблеотекі чтоли

змінено: прибрана нецензурна лексика

Вже шукаю самовчитель ДіректХ
Хочеться створити на екрані щось своє
Респект за компетентний огляд

Спасибі, ось тільки огляд робився досить давно (і я навіть не впевнений, що він робився мною 🙂), ситуація дещо змінилася.
Хоча я, в будь-якому випадку, вважаю за краще DirectX.