Створення гри типу DOOM, Wolf 3 D.(курсова)

КУРСОВА РОБОТА

Створення гри типу DOOM, Wolf 3D

План

Створення простого тривимірного зображення кадру гри. Основи.

Метод визначення швидкості роботи гри.

Додаткові можливості.

Система розробки: Pentium 150Mhz, 32M RAM, 1G HDD, S3 SVGA, Borland C++
3.1

Мета: Створити гру, що зовнішньо схожа на Wolfenstein 3D

Методы: Гра створена за методом, що зветься Ray Casting (проведення
променя) — процес зображення тривимірного світу за двовимірною
інформацією. Ось основні принципи цього методу:

1. На основі двовимірної карти, що схожа на папір в клітинку, будується
лабіринт, що складається з замальованих та чистих клітинок.

2. Мапа створена з квадратів фіксованого розміру (в нашому випадку —
64 x 64), що дозволяє кожному об’єкту (гравцю) пересуватися на 64
одиниці в будь-якому напрямі до переходу на інший квадрат. Весь лабіринт
складається з таких квадратів, що утворюють двовимірний масив.

3. Гравець визначається як місце на цій мапі, що має три характеристики:

координату X

координату Y

кут зору

Так як ми знаємо, де знаходиться гравець та те, в який бік він дивиться,
ми можемо взнати, що він бачить в цей момент. Для початку нам треба
вирішити яке поле зору має гравець. Нехай це буде 60(, для того щоб
зображення було найбільш реалістичним. Це значить, що гравець буде
бачити всі предмети та стіни на 30( ліворуч та на 30( праворуч.

0 1 2 3 4 5 6 7 8 9
10 11 12 13 14 15

5. Тепер ми отримали поле зору, що включає в себе стіни попереду гравця
при данному куті зору.

6. Ось що має бачити гравець в цьому випадку.

7. Так як же все ж таки отримати таке тривимірне зображення з
двовимірної мапи? Просто вираховуючи висоту стін як функцію від
відстані. Маючи поточні координати гравця, координати стіни та,
використовуючи тригонометрію, ми можемо визначити відстань між гравцем
та стіною. Проблема в тому, щоб виконати всі ці розрахунки настільки
швидко, щоб гра виглядала реалістично. Але цим ми займемося пізніше.
Зараз нехай спрацює простий метод визначення відстані до стіни. При
цьому потрібно пам’ятати, що ми проводимо промінь для кожного стовпчика
пікселей екрану, що для режиму VGA 13h (320x200x256) дає нам 320
стовпчиків по 200 пікселів. Тобто, 320 променів буде проведено щоб
намалювати 1 кадр.

8. Почнемо з заповнення початкових значень для гравця. Як ми вже
сказали, кожний квадрат має розміри 64×64 одиниці. Нехай гравець стоїть
в клітинці (1, 1) десь на 3/4 клітинки згори та на 1/4 клітинки зліва.
Значить координати гравця десь приблизно (80, 112) (64 + 64 * 1/4, 64 +
64 * 3/4). Початковий кут зору буде 0(. Так як ми будемо використовувати
тригонометричні функції з бібліотеки мови C, ми будемо
використовувати координатну систему, де кут збільшується за годинниковою
стрілкою.

9. Тому, як було сказано в пункті 4, ми починаємо проводити промені від
30( зліва від нашого кута зору (=0() (або з 330() до 30( справа від
нашого кута зору (або до 30(). Можна побачити правильний трикутник від
того місця де стоїть гравець до точки з кутом 330(.

;

, що дорівнює 819.5999 або 820 одиниць. Що ж, 820 це максимальна
відстань, на яку ми можемо пустити промінь, переглядаючи по дорозі чи не
натрапили ми на стіну або чи не вийшли ми за межі лабіринту. Ми звели
проведення променя до малювання лінії. А для малювання лінії у нас є
алгоритм Брезенхама. Нам треба тільки визначити координати кінцевих
точок лінії. Якщо ми маємо початкові координати гравця (X, Y), тоді
використаємо вирази для точок кола щоб взнати кінцеві координати.

Використавши числа з пунктів 8 та 10 отримуємо:

. Передавши параметри (80, 112, 790, -298) в процедуру проведення
лінії, що перевіряє зіткнення з стінами. Для кожної точки вздовж лінії
ми визнячаємо координати на нашій карті так:

$

?

?

?

?

»

$

нашого поля зору.

Таблиця висот будується так: для кожної з можливих відстаней
висота=відстань/С, де С — коефіцієнт, що вибирається пробним шляхом.

Так ми малюємо один кадр нашої гри. Він залежить від двох параметрів —
координат гравця та його кута зору. Змінюючи ці параметри та
перемальовуючи екран знову можна отримати те що бачить гравець з новими
координатами та/або кутом зору. А самі зміни координат та кута
відбуваються в залежності від тих клавіш, що їх натиснув гракець на
клавіатурі, або від перевування мишки. Чим більше кадрів малювати за
одиницю часу, тим більш плавною і реалістичною буде гра.

Коротше кажучи, ось основні кроки:

Візьміть кут зору гравця і відніміть 30( від нього щоб отримати напрям
першого променя.

Вирахуйте координати кінцевої точки використовуючи початкові координати
гравця, напрям променя та максимальну відстань, на яку проводиться
промінь.

Використовуючи алгоритм лінії Брезенхама, в кожній точці лінії
перевіряти, чи не втикнулися ми зі стіною і чи не вийшли ми за межі
лабіринту. Якщо знайшли стіну, повернути координати (Wx, Wy) точки
перетину.

Використувуючи координати грвця та координати перетину з стіною
визначити відстань до стіни.

Використувуючи відстань, визначити з таблиці висот висоту стіни яку
треба намалювати.

Додати 0,1875 до кута проведення променя і знову пройти пункти 1-6 доки
не намалюємо всі 320 ліній екрану.

11. Описаний вище алгоритм дає більш-менш нормальний результат, але має
декілька недоліків:

Швидкість. Проведення 320 ліній для кожного кадру просто дуже повільно.
На екрані може бути видно як перемальовується кожен кадр зліва направо.

Перетини. Немає простого способу визначити з якою саме чистиною стіни
перетнувся наш промінь, а тому важко на стіни накласти текстуру.

Для точнішого визначення швидкості роботи описаного алгоритму (в кадрах
за секунду), були написані відповідні процедури. Ось основна схема
визначення кількості кадрів за секунду.

long getTime() {

return peek(0, 0x46E)*65535+peek(0, 0x46C);

}

int TimeCounter=0;

void main(void) {

long RememberTheTime=getTime();

int FramesPerSecond=0;

while (TRUE) {

TimeCounter++;

if (getTime()-RememberTheTime>=18) {

FramesPerSecond=TimeCounter;

TimeCounter=0;

RememberTheTime=getTime();

}

}

}

Функція getTime() повертає поточний час у вигладі довгого цілого. Це
число збільшується на одиницю приблизно 18 разів на секунду. TimeCounter
показує скільки разів виконався цикл. У функції main() організован
основний цикл програми, що збільшує TimeCounter на одиницю. На початку
роботи програми час, що повертається функцією GetTime запам’ятовується у
змінній RememberTheTime. Але якщо в ході роботи циклу пройшла 1 секунда,
то FramesPerSecond буде мати значення кількості проходів циклу за
секунду. При умові що за один цикл програми малюється один кадр, то
FramesPerSecond можна вважати кількістю кадрів за секунду.

А ось що можна зробити для покращення та прискорення цієї гри.

В першу чергу потрібно звільнитися від чисел з точкою, що плаває.
Використавши числа з фіксованою точкою ми прискоримо весь алгоритм.
Число з фіксованою точкою приблизно дорівнює числу з плаваючою точкою
побітово зсунутим дещо вліво, щоб зберігати дробову частину. a = long(
(float)b << 8). Такі числа можна складати та віднімати без перетворень. Щоб ділити та множити потрібно виконати побітові зсуви — (a >> 8) * (b
>>8).

По-друге, потрібно всі значення, які можна, вирахувати заздалегідь і
помістити в змінні та масиви. Наприклад значення сінусів та косінусів
можна занести в таблицю з 360 елементів, що відповідають кожному з 360(.

Накладання текстури відбувається за методом інтерполяції. Знаючи верхню
та нижню точки, можна пройти в циклі по всім точкам від верхньої до
нижньої і взнати відповідні точки в текстурі. Але більш докладне
пояснення виходить за рамки даного документу.

Робота з монстрами майже нічим не відрізняється від роботи з самим
гравцем. Він має координати свого положення і кут зору. Переміщується до
гравця якщо має досить енергії і стріляє через рандомізований проміжок
часу. Якщо енергії недостатньо, втікає.

Список літератури

1. Lary Myers. Animation Construction Kit 3D

2. Sebastien Loisel. Zed3D. A compact reference for 3D computer
graphics.

Дейв Робертс. Программирование игрушек. Основы.

Mark Feldman. Brezenham’s Line and Circle Algorithms.

Sebastien Loisel. A tutorial for 2D and 3D vector and texture mapped
graphics. Version 0.60

Chris. Egerter. Texture mapped polygons.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *