Анатомія ігрових двигунів
Ефективне використання пам'яті
Не слід забувати, що більшість пам'яті карти відводиться під зберігання текстур. Кожен 3D прискорювач несе обмежену кількість пам'яті, частина якої має бути відведена під "передній" та "задній" буфери, z-буфер, і, звичайно, текстури. Якщо першій карті Voodoo1 було 2 Мб пам'яті, то Riva TNT кількість було збільшено до 16 Мб. Потім GeForce2 та ATi Rage отримали 32 Мб, а тепер ми стали свідками переходу від 64 Мб до 128 Мб. Чому великий обсяг пам'яті такий важливий? Що ж, давайте трохи порахуємо.
Припустимо, ваша гра працюватиме в 32-бітному кольорі при роздільній здатності 1280x1024 з 32-бітним Z-буфером, оскільки ви бажаєте отримати максимальну візуальну якість. Добре, тоді у нас виходить 4 байти на піксель для екрану плюс 4 байти на піксель для Z-буфера, оскільки і там і там розмір пікселя становить 32 біти. При роздільній здатності 1280x1024 ми маємо 1310720 пікселів. Помножимо на 8 (сумарне число байт для кожного пікселя "переднього" буфера та Z-буфера) і отримаємо 10485760 байт. Додамо "задній" буфер і ми отримуємо 1280x1024x12 байт, або 15728640 байт, що дорівнює 15 Мбайт. Якби на нашому прискорювачі було 16 Мб пам'яті, то під текстури у нас залишився б жалюгідний 1 Мб. Якщо самі текстури теж 32-бітові, що сьогодні є загальноприйнятою практикою, то в 1 Мб ми можемо зберігати 1 Мб/4 байти = 262144 пікселя. Це приблизно 4 текстури розміром 256×256.
Наведений приклад ясно показує, що старі 16 Мб карти не відповідають вимогам сьогоднішніх ігор. Нам просто доведеться перезавантажувати текстури для кожного кадру на карту. Саме для цього і була призначена AGP шина, проте AGP все-таки повільніша за кадровий буфер 3D карти, тому ви отримаєте відчутне падіння продуктивності. Очевидно, якщо визнизите роздільну здатність текстур до 16-ти біт, то ви зможете передавати їх вдвічі швидше по AGP шині. Також якщо ви зменшите і екранну роздільну здатність, то на вашій карті звільниться додаткове місце для кешування текстур. Але ви ніколи не зможете визначити, як користувач настроїв свою систему. Якщо їхня карта може працювати на високій роздільній здатності та глибині кольору, то, швидше за все, саме вони і виставлені.
Наведемо туман
При розмові про туман непогано б згадати про альфа-тестування та альфа-сполучення (alpha blending) текстур. Коли візуалізатор відображає якийсь піксель на екрані, за умови проходження пікселем тесту Z-буфера (описано нижче), ми маємо здійснити альфа-тестування. При цьому ми можемо виявити, що піксель має бути прозорим, щоб показати, що за ним ховається. Тоді ми повинні знати значення пікселя, що знаходиться за поточним, і далі нам слід обробити кольори двох пікселів і вивести на екран піксель, що вже результує. Така операція проходить за сценарієм "читання-модифікація-запис", і вона споживає набагато більше часу, ніж звичайний запис пікселя.
Існує кілька алгоритмів сполучення (змішування) пікселів. Пряме альфа-сполучення додає деякий відсоток "тіньового" пікселя до відсотків, що залишилися від нового пікселя. Додаткове альфа-сполучення бере відсоток "старого" пікселя і просто додає його до нового пікселя (не враховуючи відсоткове співвідношення). Останній спосіб дає яскравіші ефекти (наприклад, ефект світлового меча Кайла в Jedi Knight II).
З кожним новим поколінням 3D прискорювачів, ми отримуємо нові та більш складні види альфа-сполучення, які дозволяють створювати дивовижні ефекти. Ну і звісно, з урахуванням піксельних програм (шейдерів)у GF3+4 та останніх платах Radeon, межею тут може стати лише ваша фантазія.
Трафаретне затінення та перевірка глибини
Перевірка глибини
Достатньо просто пояснити, чому перевірка глибини збільшує частоту кадрів. Уявіть собі детальну сцену, де є безліч полігонів (або пікселів) один за одним, і нехай до передачі сцени візуалізатору не існує швидкого способу відкидання перекритих полігонів. При сортуванні непрозорих полігонів по осі Z, коли ближні до екрану полігони будуть відображені першими, ви заповнюєте сцену найближчими до вас пікселями. Коли ви починаєте відображати пікселі за існуючими (як визначає перевірка глибини), їх можна легко відкинути, заощаджуючи час та ресурси. Якби ви відображали об'єкти на екрані навпаки, від найдальших до ближніх, то всі перекриті об'єкти повністю б відмальовувалися, після чого їх перекривали б інші об'єкти. Чим складніша сцена, тим гіршою була б ситуація. Тож від перевірки глибини є реальна користь.
Згладжування
Вершинні та піксельні програми (шейдери)
На жаль, механізм доступу до вершинних програм вони однакові. Ви не можете просто написати код вершинної програми та запускати її на будь-якій карті, як це здійснювалося з кодом OpenGL та DirectX. Однак, оскільки програма працює безпосередньо із "залізом", ви можете розраховувати на швидкий рендеринг усіляких ефектів. (Рівно як і створення нових приголомшливих ефектів - ви можете робити те, що не дозволяє API). Фактично вершинні програми переносять 3D карти назад у світ приставок, де використовується прямий доступ до обладнання, і розробники вичавлюють максимум із системи, а не просто сподіваються на API. Деяких програмістів такий підхідшокує, але такий прогрес. Взагалі, вершинні програми – це процедури, що використовуються для прорахунку та реалізації вершинних ефектів перед передачею їх на картку для рендерингу. Ви маєте вибір - ви можете виконати такі ж процедури програмно на центральному процесорі або використовувати вершинні програми на карті. Трансформація скелета анімованої моделі – це основне завдання для вершинних програм.
Піксельні програми (шейдери) - це процедури, які застосовуються до кожного пікселя під час рендерингу текстури. Ви можете відмовитися використовувати вбудовані режими пару пікселів і змусити карту застосовувати для цього вашу програму. Завдяки цьому ви можете отримати нові цікаві піксельні ефекти, такі як розфокусування текстур при видаленні, додаванні теплового марева або внутрішнього відображення води.
Оскільки ATi та nVidia дійшли згоди за версіями піксельних програм (і DX9 вводить нову мову програмування), буде не дивно, якщо DirectX і OpenGL підуть шляхом Glide - з нього просто починати, але він аж ніяк не є найкращим способом вичавлювати максимум ресурсів з карти. У будь-якому випадку буде цікаво простежити за розвитком ситуації.
На завершення.
Перший Unreal спирався на повністю програмний рендеринг, далі він був розширений до апаратного рендерингу. .
API: погано це чи добре?
Що стосується ПК, то ви можете створити свій власний програмний розтеризатор, який використовуватиме центральний процесор для відтворення спрайтів, полігонів і частинок - і люди досі так і роблять. Ageof Empires II: Age of Kings - це приклад хорошого програмного розтеризатора, так само, як і Unreal. Потім можна використовувати один з двох можливих графічних API, OpenGL або DirectX. OpenGL - це крос-платформний API (програми, написані під нього, працюватимуть під Linux, Windows і MacOS), він існує вже досить великий період часу, його добре знають і розуміють, але його вік теж починає ставити свої бар'єри. Ще кілька років тому над функціональністю OpenGL драйвера працювали усі виробники карток. Однак, як тільки функціональність була досягнута, перед розробниками далі не було чіткого шляху для розвитку, тому кожен став доповнювати драйвер своєю функціональністю, використовуючи розширення OpenGL.
3dfx створила T-буфер. nVidia спантеличилася апаратною трансформацією та освітленням. Matrox пішла у напрямку накладання карт нерівностей. І так далі. Як бачимо, за кілька років у 3D графіку відбулися суттєві зміни.
У будь-якому разі, другим можливим вибором є DirectX. Він повністю контролюється Microsoft, і зі зрозумілих причин існує тільки на ПК з Windows і Xbox. Жодних версій під Apple або Linux. Оскільки Microsoft контролює DirectX, він убудований у всі сучасні версії Windows.
Основна відмінність між DirectX та OpenGL полягає в тому, що останній є власністю "спільноти", а перший - Microsoft. Якщо ви хочете, щоб DirectX підтримував нові функції вашої 3D карти, вам потрібно звертатися до Microsoft, сподіватися, що компанія до вас прислухається і чекати нової версії DirectX. Що стосується OpenGL, то оскільки виробник карти постачає OpenGL драйвер у комплекті, ви можете відразу ж отримати доступ до функцій картки через OpenGL розширення. Все, звичайно, добре, але зпогляду розробника гри, ви можете сподіватися поширеність розширень під час написання коду. І хоча розширення можуть збільшити швидкість на 50%, ви не можете вимагати від кожного користувача встановити GeForce3 на свій комп'ютер. Ні, звичайно, можете, але наступного року ви сушитимете сухарі.
Ми пропустили різні деталі, але суть ситуації ви повинні уявляти досить чітко. З DirectX ви завжди знаєте, чого ви отримаєте від карти в даний момент часу, тому що якщо функція апаратно на карті не реалізована, DirectX програмно її емулюватиме (не завжди ефективно, оскільки в ряді випадків такий підхід сильно сповільнює гру, але ми зараз говоримо не про це). З OpenGL ви можете почекати з карти більше, проте ви не будете впевнені, чи присутні на машині потрібні вам функції.
У наступній частині ми поговоримо про моделювання персонажів, анімацію та рівень деталізації.