Code - 3D движок для Elite

  Высадка на планету в 3D
  3D-движок, опубликованный в прошлом но─ 
мере, существенно улучшен, и к нему сделан 
совершенно  фантастический (по  меркам  8- 
битных  машин) пример! Предоставляем слово 
автору этого примера - Dragons' Lord'у: 

         1. Исходный 3D Engine

   Чтобы  не запутаться во множестве моди─
фикаций движка, с некоторых пор я стал да─
вать  условные  цифровые значения версиям.
Моя классификация:
  - 3D engine 0.01 - изначальный  прототип 
2016 года 
  - 3D engine 0.02 - введение кренов
  - 3D engine 0.03 - исправлены  некоторые 
глюки переполнения 
  - 3D engine 0.04 - введены автоопределе─ 
ние мыши и прыжок 
  - 3D engine 0.05  -  промежуточная  "no─ 
interlace1к", как её назвал сам автор 
  - 3D engine 0.06 - "fixinterlace", заве─ 
ршена  дописка режима "solid state screen" 
без интерлейса 
  - 3D engine 0.07  -  введена возможность 
цветного видеовывода на компьютере АТМ 
  - 3D engine 0.08 - написана функция "pa─ 
norama 360°", печатающая растровую графику 
на задник 
  - 3D engine 0.09 - добавлена окраска не─ 
ба, продолжающая рисунок панорамы. 
   Версией "3D engine 1.00" я буду считать
полностью 3-мерный вариант, подходящий для
реализации "Elite". Сейчас движок обсчиты─
вает пространство по упрощённым формулам,и
реализация полноценного 3D не представляе─
тся возможной. Текущая версия отлично под─
ходит для шутеров от первого лица и реали─
зации  maze  а-ля Wolfenstein 3D или Doom. 
То есть 2-мерные уровни.Хотя имитация кре─
на и прыжки присутствуют.

           2. Моя модификация

   Отмечу,  что  модификации  подвергалась
версия  оригинального  движка  "3D  engine 
0.06", но потом  результат был объединён с 
версией 0.09. Крены для данной задачи вык─
лючены.
   Во первых, нужно понять,зачем модифика─
ция вообще нужна.Исходный движок имеет ряд
моментов, путающих юзера.
   Формат осей,используемых при проектиро─
вании  самих объектов (вертексов): ось X -
от нас,ось Y - вправо,ось Z - вниз. Формат
пространства, в  которое  вы помещаете эти
объекты в основном модуле кода: ось X - на
нас, ось  Y - влево, ось  Z - вниз. Формат
пространства, в  котором  перемещается сам
персонаж  (т. е. камера): ось  X - от нас,
ось Y - вправо, ось Z - вверх. Как заметит
внимательный читатель,пространства не бью─
тся никак. И если инверсию первого логично
объяснить, так  всегда  бывает, что  после
преобразования  камеры объекты инвертируют
свои  оси, то  несовпадение последних двух
мерностей  приводит к полной невозможности
программировать   адекватные   перемещения
объектов  в мерности перемещений камеры. В
исходном движке этот момент не решён.
   Второе серьёзное ограничение применимо─
сти  движка заключается в размерностях его
сцены. Хотя  для  координат и используются
регистровые пары, т.е. 16 битные значения,
но  движок  способен адекватно обсчитывать
только мерность -1023...0...+1023  по всем
осям. Далее  идёт повторение объектов сце─
ны. То  есть  если  вы поставите столбик в
координаты 0,0,0 и побежите в любую сторо─
ну, то через 2048 внутренних единиц прост─
ранства вы снова прибежите к данному стол─
бику, но уже  с другой стороны, и так мно─
гократно  через  каждые 2048. Причём ввиду
упрощёнки  обсчёта  положения  объектов, о
которой  я уже упоминал, вы уже не сможете
взаимодействовать с этим объектом адекват─
но - при  любом повороте камеры объект бу─
дет  хаотично скакать по сцене. Адекватная
работа  с  углами  будет только в пределах
нулевого квадранта.
   Модификация  логики  отображения объек─
тов  в мерности сцены  призвана решить обе
проблемы разом.
   Как  это  сделано: в  модуле управления 
"script.asm"  вывод  рассчитанных значений 
mcamx и mcamy перехватываются,и вывод идёт
не  в  них, а  в новые ячейки памяти camX, 
camY, оставляя mcamx и mcamy в нулях.Таким 
образом, камера завешивается в нулевых ко─
ординатах мерности сцены и висит там всег─
да.Теперь если нажимать на кнопки - ничего
не  будет происходить, мы никуда не бежим.
Логика отображения мира меняется на инвер─
сную: раньше объекты были неподвижны,а пе─
ремещали мы камеру, теперь камера неподви─
жна, и  мы перемещаем вокруг неё весь мир.
Все объекты в основном коде имеют в начале
блока  приращение на разницу между их "из─
начальными  координатами" и мнимым положе─
нием камеры,т.е.координатами, размещаемыми
в camX, camY.
   Всё, теперь  и  камера всегда в нулевом
квадранте, и оси перемещений объектов про─
инвертировались, войдя  в  синергию с теми
осями, которые показывает камера ( Z ось в
данном релизе не затрагивается, потому что
это не имеет смысла). Теперь можно объекты
адекватно  перемещать динамически: если вы
дали  приращение  +100 по оси X, то именно
это и произойдёт визуально.
   Также  введён  модификатор рэйнджа. Все
объекты  предлагаемого  уровня поделены на
условные конгломераты (пространство приме─
рно 128х128х128 внутренних единиц),у кото─
рых проверяется дальность от мнимой камеры
до координат ключевого объекта этого конг─
ломерата. Если дальность больше заданной -
конгломерат обходится по jp и не исполняе─
тся, а  объекты  конгломерата  исчезают со
сцены.
   Данный механизм (аналог стриминг конте─
йнеров,который несколько лет разрабатывали
разработчики "Star Citizen" и которым без─
условно  гордятся) позволяет  решить одно─
временно три проблемы.
   Во-первых, рэйндж  можно  настраивать и
таким  образом разгружать сцену под машину
с  любыми тактами процессора. Меньше даль─
ность, меньше  объектов в кадре, выше fps.
Настройка    в    самом    начале   модуля 
"my_lunohod.asm" и выглядит так: 
  - dalnost=%11111111: 256 единиц простра─ 
нства - для  машин  с  частотой процессора 
3.5 МГц; 
  - dalnost=%11111110: 512 единиц простра─ 
нства - для режима турбо 7.0 МГц; 
  - dalnost=%11111100: 1024  единиц прост─ 
ранства - для  режима Evolution 14 МГц, но 
не рекомендуется к использованию,либо нуж─ 
но  переключить range самого движка с 4 на 
3 (дело в том,что максимально большой воз─ 
можный  объект диаметром 64 исчезает визу─ 
ально  с установленным range=4 примерно на 
дистанции  1040, то есть его будет видно у 
самой  кромки горизонта как хаотично репи─ 
тующая копия). 
   Во-вторых, новый встроенный рэйндж поз─
воляет  превозмочь главное ограничение ис─
ходного  движка и набирать сцену  из сколь
угодно большого количества объектов, кото─
рые размещаются  в  сцено-образующем  коде
все  одновременно (сейчас на сцене 200 не─
зависимых объектов).
   И в-третих, что очевидно,вам становится
доступной  для застройки и путеществий вся
16-битная  мерность  пространства  по всем
осям. Причём  без страха встретить повтор─
ное появление объектов из другого квадран─
та.Теперь вы можете строить город на карте 
0..65535 размера. На экран  выводятся ваши 
координаты в формате XXXXX_YYYYY_ZZZZZ - и
вы можете наблюдать своё положение на кар─
те  (можете отключить, 9000 тактов лишними
не будут).

               3. Уровень

   Когда  основные технические моменты ре─
шены,можно перейти непосредственно к твор─
честву - к  застройке. В  качестве образца
для  оценки  возможностей  движка я выбрал
модуль  посадки  на планету из игры "Elite
Dangerous". Строить  будем  руины стражей, 
общий  план  застройки  приведён на скрине 
"elite_0_05_alpha_Исходные  руины  стражей 
из  игры  Elite  Dangerous.jpg".  Застроил 
только  всю центральную  часть  -  внешние
маленькие застройки по углам доделывать не
стал. Почему? Потому что совокупность фай─
лов уровня сейчас как раз в пределах одной
страницы памяти Спектрума, т. е. вмещается
в  16384 и может при необходимости успешно
храниться в банке верхней памяти 128K, как
один из уровней игры. Файлы моего уровня -
это конкретно:

"rotmodel.asm" 
"3dmodel.asm" 
"my_lunohod.asm" 

   Сейчас они размещаются в памяти следую─
щим образом:

> >>> ORG - start my level 33831 
> ---------- rotmodel vertex --- size 6180 
> ---------- model poly -------- size 881 
> ---------- lunohod code ------ size 8416 
> -----------RESULT (all my level): 15477 
> >>> ORG - end my level 49308 

   Достроить уровень при необходимости,ко─
нечно,можно - для этого нужно убрать рису─
нок  панорамы и задать в настройках движка 
endfree=#10000, что даст 8K дополнительной 
памяти в верхней странице.
   Пару слов касательно формфактора реали─
зованных  построек. В  уровне присутствует
симуляция правильного освещения,хотя в ис─
ходном движке освещения нет. Все постройки
окрашены  так, как будто свет падает с од─
ной  стороны. Для этого пришлось хранить в
памяти  копии некоторых осе-несимметричных
объектов  с разной окраской. Это, конечно,
плохо. Память  у  Спектрума  не резиновая.
Если  убрать эти объекты и забить на свет,
высвободится  примерно 1,5 .. 2 килобайта.
Но  будет  не  так фотореалистично. Также,
кроме  шейдеров вращения и синусоидального
перемещения  динамических объектов на вра─
щающиеся объекты накинут шейдер,симулирую─
щий динамическое правильное освещение,а-ля
Flat. Делается подмена цветов на гранях (в
модуле  POLY ) при определённых диапазонах
угла вращения объекта.

               4. Выводы

   Проект делался с целью получить компле─
ксное правдивое представление о:
  - Какова  будет скорость отрисовки сцены 
а-ля "город". Можно отметить, что скорости 
на   машинах   со   стандартными   тактами 
(70000)  действительно не хватает. Получен 
результат  на  грани критического значения 
min fps=8. И это в режиме интерлейса, т.е. 
с  черезстрочным  выводом.  Заключаем, что 
демонстрируемый  уровень - это максимально 
возможная  плотная  застройка.  Необходимо 
увеличивать дистанцию между отдельными ко─ 
нгломератами  (по сути "домами" на будущих 
картах).Также на предложенном примере вид─ 
но, что  в "близоруком" режиме  с рэйнджем 
256 затруднено ориентирование в пространс─ 
тве, особенно  у человека, который никогда 
ранее не видел этот уровень. Введение кар─ 
ты  в  любом  виде, с обозначение игрока и 
строений, - обязательное условие. 
  - Каково будет визуальное восприятие ра─ 
зличных объектов. Можно отметить одну, как 
ни  странно, но техническую проблему. Мак─ 
симально  возможный размер одного элемента 
= 64. Чтобы изобразить  что-то фундамента─ 
льно большое, необходимо уменьшить "рост", 
а   по  сути  приращение  по  +z  в  файле 
"script.asm" с дефолтного  #020  до  #010. 
Тогда  двухуровневые  строения  "с крышей" 
воспринимаются  максимально  адекватно. Но 
при этом обратной стороной медали, вступа─ 
ющей в противоречие с первой, является от─ 
рисовка плоской плитки под ногами, которой 
кое-где   рекомендуется  мостить  мостовую 
(значительно  облегчает  ориентирование  в 
"сферическом  вакууме"). Плитка  не  может 
адекватно  отрисовываться  с высоты такого 
малого  роста  из  за фейковости отрисовки 
объектов  в  движке,- плитку начинает бить 
в неадекватных конвульсиях. Приходится вы─ 
бирать некий компромис, ухудшающий указан─ 
ные  параметры  на  некоторое  значение. А 
увеличивать  этажность застройки вы не мо─ 
жете, потому  что не хватит быстродействия 
для отрисовки столь многокомпонентных кон─ 
гломератов. Если  вернуться  к  восприятию 
объектов, то  показано, что сложные много─ 
компонентные "дома" из нестандартных ароч─ 
ных конструкций уменьшеной толшины смотря─ 
тся  отлично. В то же время отдельно стоя─ 
щие  простые геометрические формы выглядят 
отвратительно  и не воспринимаются мозгом, 
как некие "постройки". Даже в случаях, ко─ 
гда таких мелких отдельно стоящих объектов 
много  в  кадре. При  строительстве  стоит 
придерживаться  правила "редко, но метко". 
Мозг  хочет, чтобы  строение  было с "кры─ 
шей", под которую можно зайти. 
  - Каковы  будут размеры занимаемой памя─ 
ти. Память расходуется быстрее, чем ожида─ 
лось.Я уже описывал структуру уровня выше, 
здесь  можно отметить, что создание подоб─ 
ных  уровней вполне возможно, если держать 
свои хотелки в некоторых рамках. Демка по─ 
казывает строго статическую картину строе─ 
ний. Геймплея  нет. Динамических  объектов 
(дронов  стражей)  нет.  Взаимодействия  с 
объектами  нет.  Интерактивного  изменения 
построек  нет. Процедурной генерации высо─ 
топеременной  почвы и случайных RND объек─ 
тов  вне зоны руин нет. Всё это планирова─ 
лось  и  может  быть написано без проблем. 
Нет  этого  по причине желания не засорять 
код  демо  уровня. Для  новичка необходимо 
постепенное  знакомство  с  3d engine. Вот 
чего  наверняка не будет никогда - это фи─ 
зики. Я  говорю  о  запрете  игроку ходить 
сквозь  стены. Для  уровня  с произвольной 
застройкой в рамках 3.5 МГц это нерешаемая 
задача, и предлагается оставить, как есть. 
Полагаясь  на  фантазию игрока. В проектах 
аля  "Вольфенштейн", с  регулярной картой, 
физика реализуется весьма просто. 

             5. Заключение

   Я  не нашёл предела количеству одновре─
менно отрисовываемым объектам, хотя прове─
рял  где-то до количества 60 штук. Это оз─
начает, что  у вас скорее fps устремится к
нулю,чем вы сможете навыводить кучу объек─
тов в попытках завесить систему.Это прият─
но. Никакой буфер не будет переполнен.Осо─
бенно  это  греет  душу, когда вспоминаешь
ограничения   в  стандартной  Спектрумской
"Elite" - не более 6 динамических объектов 
одновременно + станция. Здесь же можно вы─
водить сколько угодно,если это вписывается
в выделенную память: 52016..52992(_tables) 
free for object list  976  (один выводимый 
объект занимает 16 байт).
   По скорости отрисовки: если представить
стандартную "Elite" и взять нормальные вы─
пуклые  объёмные  объекты, то  можно смело
отрисовывать 4 таких объекта в кадре одно─
временно ( ~60  полигонов). fps  не упадёт
ниже 10 при любых приближениях. Это вполне
юзабельно. 5  объектов  одновременно ( ~75
полигонов) - fps  не  упадёт  ниже  8. Это
критически, но  допустимо.  Естественно, я
имею  в  виду  режим  интерлейса. Так  что
"Элиту" с залитыми гранями реализовать те─
хнически  возможно, если  допилить расчёты
внутри движка до полноценного 3D.
   Очень  понравился  выдеовывод. Скорость
заливки  и вывода видеобуфера на экран за─
предельная. Это единственный движок,где вы
практически ничего не теряете, задавая об─
ласть  отрисовки  на весь экран Спектрума.
Отрисовка занимает лишь малую часть общего
времени  расчётов.  Максимально  нагружает
систему обсчёт  вертексов, поэтому примите
правило  не плодить лишних вершин без кри─
тической на то необходимости.

   Благодарю Alone Coder'а за великолепную
работу и надеюсь на полную 3D реализацию.

   С уважением, Dragons' Lord.