Предисловие
В прошлой статье, с которой мы настоятельно рекомендуем ознакомиться перед прочтением этой, мы рассмотрели:
Программирования в Mindustry
Карту
Луч и основные принципы псевдо-3D
Рисование текстур.
Сегодня же мы углубимся в детали того, как работает эффект рыбьего глаза и немного перестроим псевдо-3D, а так же создадим физику для движка и спрайты.
Мелочи
В прошлой статье мы забыли упомянуть FOV
(Field of view). По сути это угол обзора, в котором все лучи лежат равномерно с разницей, допустим, в ~1⁰.
К текущей статье мы успели заменить мелкую ячейку памяти настроек cell1
, на банк настроек памяти bank12
, bank2
, bank1
(в зависимости от процессора).
Также мы решили убрать редактор карты, ведь он только запутывал людей, хотевших пользоваться нашим псевдо-3D движком, и теперь она создается автоматически.
Ещё изменился внешний вид нашего псевдо-3D движка, теперь он более аккуратный.
Эффект рыбьего глаза, что и почему
В прошлой статье мы частично решили проблему эффекта рыбьего глаза, умножив длину луча на косинус угла между этим лучом и направлением взгляда игрока. Но почему оно возникло, почему мы его решили этим способом, и почему не полностью? В данной главе мы постараемся ответить на эти вопросы.
Эффект рыбьего глаза возникает из-за того, что длинна луча от игрока до стены не равномерна. На примере картинки вы поймёте про что я говорю:
![L1, L2 - длины линий L1, L2 - длины линий](https://habrastorage.org/getpro/habr/upload_files/772/cb4/a55/772cb4a5527720c17b0f71354bed4b18.png)
L1
, L2
- длины линийУмножив на косинус мы сделали L1
и L2
равными:
![l - длинна луча l - длинна луча](https://habrastorage.org/getpro/habr/upload_files/664/766/48d/66476648d3d5df156cd29cca78d64423.png)
Но вот незадача, псевдо-3D всё ещё выглядит странным:
![](https://habrastorage.org/getpro/habr/upload_files/1a7/e53/9fb/1a7e539fb4d01873a4a06649b3b9e584.jpg)
Это происходит из-за того, что углы между лучами равны, от чего лучей в центре становится больше, чем по бокам:
![](https://habrastorage.org/getpro/habr/upload_files/e27/bb0/d62/e27bb0d62f805287195c8a9aee125986.jpg)
А вот так оно должно выглядеть:
![](https://habrastorage.org/getpro/habr/upload_files/dc3/1ac/e91/dc31ace91f3a5ac3d09b0624af49c7ba.jpg)
Один из способов максимально уменьшить влияние этого эффекта — уменьшить угол обзора FOV
. Его оптимальное значение 70⁰.
В нашем же псевдо-3D движке мы решили эту проблему другим способом - переписали небольшую его часть, но об этом я расскажу в следующей главе.
Перестройка движка
Мы решили перестроить небольшую часть движка, отвечающую за распределение лучей, а она потащила за собой другие части. Но всё же переписывали мы не много.
Мы решили отказаться от FOV
в пользу plane
(о нем ниже), чтобы полностью убрать эффект рыбьего глаза. В данной версии будут важны 4 переменные: dirX
, dirY
(направление взгляда игрока) и plane_X
, plane_Y
(поверхность экрана по x и y).
Взгляните на картинку:
![](https://habrastorage.org/getpro/habr/upload_files/c4a/fe7/40c/c4afe740c64bf711c46909d50a5fd6f3.png)
Так выглядела абстракция движка (то, как мы это представляли в голове): был FOV
, лучи распределены в нём равномерно, и также был угол направления взгляда игрока player_angle
.
Мы решили заменить это на другую абстракцию:
![dirX = player_dir_x, dirY = player_dir_y; dirX = player_dir_x, dirY = player_dir_y;](https://habrastorage.org/getpro/habr/upload_files/050/4df/d58/0504dfd58e48927d3f23b3964a29a850.png)
dirX = player_dir_x
, dirY = player_dir_y;
По сути ничего не изменилось, мы лишь подошли к тому же, но с другой стороны.
Переменная plane
, отвечающая за длину экрана, не является вектором, потому что нам не нужны переменные, содержащие одни и те же значения. Ведь plane
всегда перпендикулярна направлению взгляда игрока, так что для описания вектора экрана можно использовать направление взгляда игрока повёрнутое на 90⁰ и умноженное на длину экрана. Но ниже мы будем в некоторых местах для удобства вставлять переменные по типу plane_x
, plane_y
. Для удобства считайте, что plane
является вектором, а эти переменные - его направление.
В данной версии луч вместо переменной угла направления имеет 2 координаты ray_dir_x
и ray_dir_y
, которые задают направление луча вектором. В прошлой версии движка не было равномерного распределения лучей по плоскому экрану из-за того, что все лучи отличались друг от друга на строго заданный угол, а с ним не получится полностью избежать эффекта рыбьего глаза (вспоминаем написанное выше). Поэтому вместо угла мы решили использовать вектор направления луча. Его нужно просчитать для каждого луча отдельно, а просчитывается он так: ray_dir_x = player_dir_x + plane_x * (ray_number - number_of_rays/2)
ray_dir_y = player_dir_y + plane_y * (ray_number - number_of_rays/2)
![](https://habrastorage.org/getpro/habr/upload_files/9ed/1c2/73a/9ed1c273a39aaf2d40e339029b9ba1d7.png)
Вектор направления игрока легко просчитывается от угла направления взгляда игрока: player_dir_x = cos(player_angle)
player_dir_y = sin(player_angle)
Вектор экрана plane
просчитывается чуть сложней, ведь он на 90⁰ отличается от вектора направления игрока:plane_x = -sin(player_angle)
plane_y = cos(player_angle)
Чтоб не просчитывать синус и косинус по несколько раз, мы упростили формулу до этого:ray_dir_x = player_dir_x - player_dir_y * k
ray_dir_y = player_dir_y + player_dir_x * k
Вот часть псевдокода:
k = (number_of_ray - 88)/176
read dirX at 6 in bank12
read dirY at 7 in bank12
ray_dir_x = dirX - dirY*k
ray_dir_y = dirY + dirX*k
Алгоритм луча из за этого изменения не сильно поменялся, разве что тангенс теперь просчитывается так:tan_of_ray_angle = ray_dir_y/ray_dir_x
Ведь тангенс это противолежащий катет делённый на прилежащий, в роли противолежащего выступает ray_dir_y
, а в роли прилежащего ray_dir_x
Ещё изменилась проверка того, в какую плоскость пускается луч. Например, для проверки по вертикальным линиям процессор теперь смотрит больше ли нуля ray_dir_x
, если да, то луч пускается вправо, если нет - луч пускается влево.
Также изменилось просчитывание косинуса между направлением взгляда и лучом: cos = 1/sqrt(k² + 1²)
Косинус — это прилежащий катет делить на гипотенузу, гипотенуза просчитывается по теореме Пифагора sqrt(k² + 1²)
, а катет равен 1.
И вуаля:
![](https://habrastorage.org/getpro/habr/upload_files/404/113/7ba/4041137bab75e164d69167001ecf4fb5.jpg)
Эффекта не видно.
Спрайты
Спрайты — это те самые противники в Woolfenstein 3d или в Doom, которых вы все видели. По сути они являются текстурками, постоянно смотрящими в нашу сторону, из-за чего они всегда прямоугольные, что упростит их отрисовку.
Их добавление увеличит разнообразие того, что можно создать в данном псевдо-3D движке. Например, с помощью спрайтов можно создавать врагов, колоны, предметы и т.д.
Как это выглядит:
![](https://habrastorage.org/getpro/habr/upload_files/0e6/5f0/cb5/0e65f0cb5ca03cab19d43ab207df1568.jpg)
А теперь сложная часть — как это устроено?
Спрайт — это лишь координаты спрайта с номером изображения. Изображение мы тут упустим, нас интересует то, как они рисуются.
Представьте карту, на которой нет ничего, кроме игрока и спрайта, игрок смотрит в 0⁰ (то есть вправо).
Нам дана задача: отрисовать на экране спрайт. Для этого надо найти координаты спрайта на экране:
![screen_sprite_x — то, что нужно найти screen_sprite_x — то, что нужно найти](https://habrastorage.org/getpro/habr/upload_files/201/441/0bc/2014410bc9bb6aa5890e3bbb3bc30611.png)
screen_sprite_x
— то, что нужно найтиИщутся они так:diff_x = sprite_x - player_x
diff_y = sprite_y - player_y
screen_sprite_x = half_display_weight - display_weight*diff_y/diff_x
screen_sprite_y = 88 //откуда взялось 88 мы писали в прошлой статье
diff_x
, diff_y
— расстояние от игрока до спрайта по x и y.
Тут display_weight*diff_y/diff_x
минусуется от half_display_weight
, а не наоборот из-за того, что координатная ось дисплея отзеркалена относительно display_weight*diff_y/diff_x
.
Отлично, но что делать, если игрок не всегда смотрит ровно вправо (в 0⁰)? Нужно повернуть экран, но тогда спрайты не будет адекватно на нём показываться:
![A — то, каким должен быть screen_sprite_x A — то, каким должен быть screen_sprite_x](https://habrastorage.org/getpro/habr/upload_files/d35/85f/a69/d3585fa69d4f0ed4cc9b94f845219ffd.png)
screen_sprite_x
Поэтому надо повернуть спрайт относительно своего прошлого положения:
![](https://habrastorage.org/getpro/habr/upload_files/f28/97d/ab0/f2897dab06eb0a11b78d729c5c8b5419.png)
Для поворота воспользуемся матрицей поворота:
[cos(player_angle), -sin(player_angle)]
[sin(player_angle), cos(player_angle)]
Так как спрайты должны поворачиваться в противоположную сторону от того, куда поворачивается игрок, надо изменить матрицу так:
[cos(player_angle), sin(player_angle)]
[sin(player_angle), -cos(player_angle)]
По сути мы отзеркалили матрицу по y.
Упростим её до этого:
[dirX, dirY]
[dirY, -dirX]
Ведь dirX
равен cos(player\_angle)
, а dirY
равен sin(player\_angle)
Вот как оно будет выглядеть в псевдокоде:
read dirX
read dirY
read player_x
read player_y
diff_x = sprite_x - player_x
diff_y = sprite_y - player_y
sx = diff_x*dirX + diff_y*dirY
sy = diff_y*dirX - diff_x*dirY
screen_sprite_x = half_display_weight - display_weight*sy/sx
Теперь рисуем желтый квадрат на координатах спрайта (его координаты на экране X:screen_sprite_x, Y:88
), и вот что видим:
![](https://habrastorage.org/getpro/habr/upload_files/806/7f7/3ec/8067f73ecc77eabbbd7e3707e5b11285.jpg)
Поворачиваемся на 180⁰ и снова видим спрайт:
![](https://habrastorage.org/getpro/habr/upload_files/40f/ef1/807/40fef18077b88ab6edaf3ca325f03155.jpg)
Так быть не должно. Это происходит из за того, что когда спрайт позади экрана, он не перестаёт рисоваться:
![](https://habrastorage.org/getpro/habr/upload_files/581/494/916/581494916d3fb334dcf77920684418a2.png)
Он рисуется сзади игрока как будто на втором отзеркаленном вдоль экране. Решить это не трудно: нам нужно узнать, когда спрайт сзади игрока. Спрайт сзади игрока, если sx < 0
, так что делаем эту проверку, и если sx < 0
, то мы просто приравниваем screen_sprite_x
к значению -500
.
На карте возможен только 1 спрайт, но хочется же больше.
Чтобы сделать больше спрайтов, процессор сортирует спрайты по расстоянию до игрока, а потом поочередно рисует стену, спрайт1, спрайт2 и т.д.
Как это было реализовано в mindustry
Для начала расскажу о том, как у нас хранятся спрайты. Есть два банка памяти, обозначим их как bank9
и bank10
, первый хранит ссылки на все спрайты (тут ссылка — это просто номер ячейки другого банка памяти, где хранится спрайт), а второй хранит спрайты. Второй банк памяти хранит каждый спрайт на трёх ячейках сразу:
Расстояние до спрайта
screen_sprite_x
Номер текстурки
Спрайты сортируются быстрой сортировкой Хоара. Ну, как спрайты, сортируются ссылки на спрайты. Значение, по которому они сортируются — расстояние от игрока до спрайта.
Спрайты просчитываются в семи процессорах, каждый читает значение из мелкой ячейки памяти, где записаны координаты спрайтов и номер текстурки. Далее он вычисляет расстояние до спрайта и sprite_x
, после записывает в bank10
то, что просчитал и номер текстурки.
Процессоры, что отрисовывают псевдо-3D, изменились: теперь в цикле рисуются спрайты от самого дальнего до самого ближнего, а перед этим рисуется стена. Такой порядок нужен для того, чтобы у спрайтов нормально отрисовывались прозрачные пиксели.
Физика
Физика — это относительно важная часть псевдо-3D движка. Будет не приятно, если игрок сможет проходить сквозь стены, и именно для этого и нужна физика.
В нашем псевдо-3D движке мы решили физику способом с багами, но «И так сойдет!»
Способ такой: проверяем, если в следующем местоположении игрока по x и текущем по y есть стена, то мы не делаем этот шаг по x. Тоже самое и для y.
Вот часть псевдокода:
xperson1 = xperson
yperson1 = yperson
// Тут код передвижения. Тоесть координаты xperson и yperson изменятся в сторону движения. Мы решили его не показывать для удобства
if map[xperson][yperson1] == 0 {
xperson = xperson1
}
if map[xperson1[yperson] == 0 {
yperson = yperson1
}
Для удобства тут мы jump заменили на if.
Финал
Для красоты финала изменим текстурки, добавим ИИ спрайтам и готово:
В этот раз мы уже имеем что-то, чем можно похвастаться!
Доп. материалы
https://lodev.org/cgtutor/raycasting.html
https://github.com/xdettlaff/mindustry-3d-engine/blob/main/3d_v0.2.2