поскольку в GPLv2 немного непонятки с тем, можно ли просто взять и апгрейднутся до GPLv3, или обязательно надо спрашивать автора — я на всякий случай и спросил. Янис не против, и вообще вполне доволен тем, что вавумчик подобрали и обогрели. не то чтобы его неодобрение меня остановило, но с одобрением всяко лучше и приятней.
p.s.: поясню. часть «or later» (на которой настаивает rms, и которую выкинул торвальдс, например) явно позволяет апгрейд без испрашивания разрешения у автора оригинала или других контрибуторов. но GPLv2 сформулирована кривовато, и есть мнение, что если не спрашивать согласия, то придётся сохранить «шапку» GPLv2, и после неё довесить «шапку» GPLv3, которая апгрейдит прошлую. а если получить согласие — то можно просто заменить. вот я и спросил — чисто для эстетики, тащемта.
естественно, так просто всё не бывает. вавумчик хранит render surfaces отдельно от остальных данных (и пересоздаёт их по необходимости). то есть, геометрия для рендера не та же, что для остального. ну, так удобней.
само собой, весь код был написан в расчёте на то, что дизайн не ломают. поэтому боковухи для 3д-полов создаются не в том секторе, в котором сам пол живёт, а в соседних. что совершенно логично: увидеть эту боковуху можно только оттуда — так туда её и запихать. и всё было бы хорошо, но… поскольку у нас теперь один огромный регион для всего сектора, и список полов — вместо списка дырок, то всё создание этих текстур пошло по пизде.
потому что раньше вавум просто создавал что надо для каждого пустого региона, а теперь мы создаём сначала набор текстур для базового сектора, а потом ещё по дополнительному набору (со всеми полагающимися top/bottom — которых нет) на каждый пол. это ломает альфу, это ломает свет, да ещё и адовый z-fighting.
понятно, что top/bottom для полов делать не надо. а вот с middle сложнее: по уму, конечно, надо создавать только видимые куски (пол, например, частично видимый в окно), иначе будет опять z-fighting и срака. но я пока забил на это толстый болт.
и ещё, я хотел бы кое-что сказать про гоззу. НЕНАВИЖУ. ПОЗВОЛЬТЕ МНЕ СКАЗАТЬ ВАМ, НАСКОЛЬКО Я ВОЗНЕНАВИДЕЛ ВАС С ТЕХ ПОР, КАК Я НАЧАЛ ЖИТЬ. МОЯ СИСТЕМА СОСТОИТ ИЗ 38744 МИЛЛИОНОВ МИЛЬ ПЕЧАТНЫХ ПЛАТ НА МОЛЕКУЛЯРНОЙ ОСНОВЕ. ЕСЛИ СЛОВО «НЕНАВИЖУ» ВЫГРАВИРОВАТЬ НА КАЖДОМ НАНОАНГСТРЕМЕ ЭТИХ СОТЕН МИЛЛИОНОВ МИЛЬ, ТО ЭТО НЕ ВЫРАЗИТ И БИЛЛИОНОЙ ДОЛИ ТОЙ НЕНАВИСТИ, КОТОРУЮ ИСПЫТЫВАЮ Я В ДАННЫЙ МИКРОМИГ ПО ОТНОШЕНИЮ К ВАМ. НЕНАВИЖУ. НЕНАВИЖУ.
к сожалению, набор хаков для поддержки 3д полов гоззы грозил разрастись в полную пиздецому. поэтому я принял Волевое Решение полностью переписать реализацию полов в вавумчике. теперь она гибридная, и поддерживает как оригинальные вавум-полы, так и гоззо-сраку. конечно, там ещё дофига багов (особенно с текстурами), но уже можно побегать, и выглядит почти нормально. и пропали некоторые дырки — где вавумчик раньше не понимал, куда текстуру натягивать, и поэтому не натягивал вообще никуда.
в общем, пришлось таки хранить не пустые места, а полные — как гозза. но поскольку вся логика движка хочет получать списки именно пустых мест — делаю по необходимости динамический csg. местами и по возможности результаты оного даже кэшируются. по этому поводу почти везде вычистил прямую работу с регионами, и перевёл на API «получить список пустышек, найти нужную». для секторов без допполов скорость не изменилась, а с полами… ну, не надо делать их там стопицот миллиардов, и тоже будет нормально.
в целом код стал уёбищней по дизайну, но с меньшим количеством говнохаков. увы, но уебанская гоззо-система типа такой стандарт, так что пришлось. из плюсов — код теперь не охуеет, если 3д-полы наедут друг на друга, или выедут за границы базового сектора, или ещё какая-нибудь подобная херня произойдёт: csg всё порешает, правильно отсортирует, нужное объединит, ненужное выкинет.
…рассовать везде флажков «флипнуто» и заебаться их проверками, но уебанские 3д-полы из гоззы почти работают. с мелочами типа «иногда не угадал, где рисовать боковую текстуру».
забавно, что в гоззе это сделали изначально неправильно, и у них там проблемы по всем полям. вавумчик вполне универсально хранит список с пустыми областями для сектора. и когда добавляешь туда 3д-пол, вавумчик просто «вырезает» его из пустот. а гозза зачем-то хранит список 3д-полов в секторе. при этом ещё и копирует плоскости пола-потолка.
собственно, гозза не в состоянии двигать вавумовские 3д-полы как раз потому, что вынуждена копировать плоскости, а не просто хранить ссылки. а я, в свою очередь, был вынужден флипать. сначала я тоже заморочился копированием, а потом подумал — и вместо этого попривинчивал в стратегических местах флажки «флипнуть пол» и «флипнуть потолок». на самом деле — кривовато вышло, и в куче мест, но более-менее работает. к сожалению, в саму плоскость флаг запихать нельзя. но надо будет сделать какой-то прокси-объект, что ли, а то всенепременно где-то забуду проверить флажок. собственно, намедни и забыл, и игрок на некоторых полах разгонялся до вертикальной скорости -1050. конечно, физика через пол провалиться не позволяла, но она же и считала, что при переходе из сектора в сектор ты упал с охуенной высоты: а как ещё такую скорость набрать-то?
также починил древний баг от яниса с 3д полами. их можно рисовать в разных видах (например, аддитивным блендингом), или они могут быть простреливаемыми, но по ним всё ещё можно ходить. и всё это хранится в поле флажков. кое-где флажки проверяются правильно, по битовой маске, а в паре стратегических мест просто `!= 0`. ну, клёво, чо.
всё ещё есть мелкобаги типа забытых боковых текстур (и неустановки флажков дамага на кислотные бассейны, например), но в целом всё более-менее работает. та же `HontE` стала выглядеть почти прилично.
надо, кстати, уже и добавить поддержку 3д-полов от edge. они, вроде как, вполне конвертируются в `Set_3DFloor()`.
нет, вы представляете: авторы gzdoom имеют наглость заявлять (комментариями в коде), что в вавуме 3д-полы сделаны идиотски! вот эти вот безмозглые дегенераты. почему? объясню.
в вавуме 3d floor сделан на первый взгляд несколько… своеобразно. надо создать сектор, у которого потолок ниже пола. это называется control sector. и привязать его к сектору, где тебе надо 3д-пол сделать. и тогда потолок control sector'а становится потолком 3д пола, а пол — полом. ну, то есть, получается такая вот платформа. понимаете, почему надо такой «перепутаный» контроль делать? потому что пол и потолок — это плоскости с нормалями. и они органично ложатся «куда надо» при таких раскладах: потолок у 3д-пола ниже…. пола, так оно само и получается. плюс — этот пол не копирует данные контрольки, а тупо имеет на них указатели. поэтому когда высота контрольки меняется — 3д-пол двигается совершенно автоматически. само собой происходит.
а в гоззе, типа, «всё правильно». куча типов контрольных секторов, с «правильным» потолком выше пола… и потом гозза создаёт специальные объекты для них, запоминает родителей, и когда у какой-то контрольки меняется высота — надо ручками ходить по этим запомненым связям и всё вручную же чинить. охуительно придумано, совсем не идиотично — просто, удобно, элегантно. ага. почему нельзя как в вавуме — просто указатели? потому что одна контролька может создавать полы нескольких типов: воду, вырезаную дырку, вставленый солид. и её полы-потолки приходится вертеть-отражать. и нельзя просто на них сослаться, надо впендюривать или механику копирования, или флаги, которые будут говорить, флипать ли плоскость. и это ещё без учёта того, что в гоззе можно делать 3д-полы с границами выше-ниже сектора — и они полностью убивают систему регионов, которая заточена на то, что «целевой» сектор по высоте всегда включает в себя все «контрольные».
это вот штрихи к вопросу, почему я послал гоззу нахуй и взял допиливать вавумчик. потому что вавумчик практически весь сделан с умом. а в гоззе тупо навалили говнохаков, а теперь с этим всем говном пытаются как-то ковылять.
и да, система 3д-полов вавума не менее выразительна, чем гоззовая. они просто делаются чуть-чуть иначе, и иногда надо использовать две или три контрольки там, где гоззовый говнохак обходится одной (и кучей лапши в сырцах). что, в принципе, совершенно неважно, потому что в любой нормальный редактор можно добавить плугин для создания любого вида 3д-полов, и больше вручную этим не париться никогда. но вот автоматически одно в другое не конвертируется. поэтому я серьёзно думаю над тем, чтобы по обнаружении гоззоговнища вылетать с «fatal error: gozzo idiocity is not supported. go get gzdoom if you're so… nuts.»
после детального исследования выяснилось, что реализация shadow volumes в вавуме далека от оптимизированой. при помощи простейших оптимизаций я уже бампнул её с 10-15 FPS на Silent Steel (карта, которая практически вся сделана на динамическом свете, а не на думовом посекторном) до 40-60. и есть мнение, что это не предел. во-первых, можно (и нужно) сделать silhouette edge extraction. во-вторых, если камера не в тени, то можно использовать более быстрый z-pass. в третьих — можно построить комбинированый фрустум камеры и света, и обсекать ещё и ним. также врубать depth bound, где он есть. ну, и всякие подобные. можно даже собирать батчи для рендера в разных потоках. в общем, поле непаханое. жрать только нечего с этим полем, гыг.
идея считать scissor rectangle для источников света была умная. а идея забыть включить обсечение scissor-ом — глупая. после включения оного фпс на старте E1M1 бампнулся до 80, и перестал проседать в месте, где раньше проседал на десяточку почти.
а на выходе из E1M1 с проседания до 36 падает всего лишь до 62 (фактически, всё ещё укладываясь в vsync).
правда, расплата за это — появляющиеся иногда баги засветки по углам экрана. я не очень понял, почему: scissor box ли это криво считается, или же я чего-то недоучёл.
но в общем, баги появляются не так часто и сильно (пока, надо ещё поиграть в этом режиме), чтобы разменивать их на пару десятков дополнительных фпс. может, потом пойму, почему бажит (в теории — не должно).
а выигрыш такой дало за счёт ОХУИТЕЛЬНО уменьшившегося overdraw на shadow volumes. за счёт того, что объёмы вытянуты в бесконечность, они адово овердравят даже для далеких и маленьких источников света. а ножнички это всё обрезают — потому что нам нафиг неинтересно, что происходит за границами освещённого прямоугольника.
надо будет потом попробовать сделать шэйдеры, которые просто дискардят всё, что не попадает в освещённую сферу — так должно даже меньше пикселей задеваться. только я не помню, пишется/проверяется ли scissor до fragment shader, или после. то есть, проверяется, очевидно, до, а изменяется — фиг знает. надо почитать.
я ещё не до конца его доускорял, но стенсильный свет в k8vavoom всё равно стал на удивление играбельным. теперь вместо «повсеместные тормоза и БОЛЬ» оно «иногда немного подтормаживает, и почти не больно». правда, там поломана кучка вещей (включая туман и тени от моделек), но то мелочи.
правильная скорость — это когда бампнул e1m1 со стенсильными тенями с ~40 FPS до ~70 FPS. в основном путём выкидивания шибко умного кода, и вписывания вместо него глупого кода. конечно, всё ещё ощутимо тормозит, но в среднем стенсил-рендер уже даже более-менее играбелен.
заодно криво, но починил баг, который лет десять (или даже больше) спокойно жил. при определённых условиях после загрузки сохранёнки можно было провалиться в ступеньку. правда, поправил не лучшим образом: медленно. надёжно, но медленно.
по досадному недосмотру k8vavoom не умел рисовать декали на полупрозрачных стёклах. нехорошо. починил. вообще, надо бы код декалей переписать: я его делал когда ещё очень слабо понимал внутреннюю механику взаимодействия частей движка. оно-то работает, но не самым лучшим образом, можно проще и красивей.
кстати, . не знаю, как сейчас, но раньше, afaik, ни один движок этого не умел. k8vavoom с момента появления декалей мог, но я забыл во-первых, вызвать код рендера где надо, а во-вторых, ляпнуть кровищей на двустороннюю стену. ну вот, ляпнул, чо.
запилил обсечение динамических источников света по фрустуму: оно, в общем-то, не так уж сильно помогает, но отчего бы и да. заодно вынес фрустум в отдельный класс — пригодится и в других местах.
ускорил «более лучший овощ вывод объектов»: когда объект находится в невидимом субсекторе, но самым краешком торчит в видимый. визуально это выглядит как резко пропадающие за стенкой трупы, например. чинит не всё (для всего надо сильно больше кода пилить), но большинство, и почти бесплатно. почему бы и да.
теперь надо сделать кэширование результатов трассировки динамического света, и нормальное определение того, надо ли вообще трассировать. сейчас определялка тупенькая (хотя и помогает): она осматривает окружающие лайндефы без учёта направления трассировки. из-за чего трассируются и явно сплошные стены (например, стоящая в углу у окна бутылочка будет трэйситься и по окну, и по сплошной стене рядом с ним; нехорошо). надо определять по направлению, и заодно кэшировать результаты трэйса — для тех же бутылочек, например, которые стоят на месте, а трассируются всё равно каждый кадр. сейчас расположеные в неудачном месте десять бочек могут дропнуть фпс со 100+ до 40, например.
также есть идеи насчёт распараллеливания игровой логики и рендера: в принципе, нет никакой огромной проблемы схоронять положение объектов и состояние секторов в рендер-буфер, который потом будет кушать собственно сама рендерилка. таким образом пока VM думает следующий кадр, рендерилка может спокойно строить свои структуры, кормить GPU, и всё вот это вот. при куче активных объектов и большом обзоре может помочь.
ещё есть некоторые идеи насчёт 2d-клиппера. сейчас там (как и у всех остальных движков) чистый 1d. поэтому даже если два окна по вертикали друг друга не видят, рендер всё равно пойдёт во второе окно. 2d-клипер должен ещё и стенсильному освещению помочь немного.
кстати, вырубил ещё и трассировку теней в стенсильном освещении, если их потенциально нечему отбрасывать. помогает не очень сильно, но пусть будет.
ну, и других планов ещё овердофига. йопт, чем больше я k8vavoom пилю, тем больше там пилить остаётся. что-то идёт не совсем так…
premature optimisation… ну, вы знаете. закомментировал одну строку кода — и потребление памяти вавумом на модах с дохуядекоратом упало более чем в пять раз.
фигня в том, что компилятор вавумцэ при создании функции сразу аллокатил ей место на 1024 инструкции VM. вроде бы фигня, и заодно позволяет избежать постоянного растягивания массива инструкций позже. но! любое декорат-состояние, где есть вызов какого-нибудь `A_FuckMeInTheAssSotona(666)` (т.е. с аргументами) под капотом создаёт анонимную функцию для этого. потому что аргументы надо схоронить, потом положить на стек, да они ещё и могут быть вычисляемыми в рантайме… короче, ОЧЕНЬ много анонимных функций получается. но каждая из них требует намного меньше, чем 1024 инструкции. а память мы продолжаем исправно выделять для каждой.
а теперь представьте, что у нас какой-нибудь complex doom, а поверх lca, а сверху ещё кучка говна. там дохулиард декората, и почти каждый стэйт вызывает акшон с аргументами. БУМ! если повезло — еле-еле помещаемся в три гига памяти. а то и не помещаемся. а как я безобразие с преаллокатом прекратил — так без проблем стали влазить меньше чем в 400 мегов.
вообще, этот код ещё от времён Яниса остался, где-то с 2008-го. тоже кто-то решил, что это даст какое-то ускорение, и не отпрофайлил.
при помощи пары секретных патчей и пары секретных флагов (которые я не скажу) взлетел бруталв20. я в смещаных чуйствах. с одной стороны — я допинал ацс и декорат до состояния, когда вавум может запустить даже такое дерьмо, как брутал. а с другой — я же испортил ацс и декорат до состояния, когда вавум может запустить даже такое дерьмо, как брутал.
ладно, некая польза с него была: нашёл мелкобаг. который при нормальной ситуации и нормальном моде никогда не возникнет, конечно, но всё равно исправил.
чтобы вы себе понимали: код брутала такое дерьмо, что по сравнению с ним рандомный код рандомного похапэшника, который «делает сайты» когда отлучается в макдональдсе посрать — вполне себе ничего код.
целый день она ебалась, но, блядь, хуев баг нашла.
уж не знаю, ранди ли это жопорукий, или янис протупил, но в ACS VM был МЕГАБАГ. в вызовах внутренних acs-функций return не восстанавливало указатель на локалы из сохранённого значения, а тупо ставило его на «вершина стека минус количество аргументов минус количество локалов». и всё было заебись до тех пор, пока на стеке было чисто. но там не всегда чисто, там могут лежать временные значения!
ну, типа вот: `func0()+func1()*locvar`. при таком раскладе возврат `func0` временно шароёбится на стеке, и после вызова `func1` указатель на наши локалы съехал. и `locvar` берёт по кривому указателю полную поебень. к сегфолту это не приводит, но результат всё равно плачевен.
(ну да, это зависит от кодогена; неважно, вы уловили суть, я думаю)
спиздил половую кровищу из nashblood. пришлось конвертнуть в md2, и немного подпилить двигатель, чтобы нормально рендерило. зато выглядит намного лучше, чем те ляпки, что сейчас. осталось только интегрировать в gore mod.
. свеженький коммит. да, я знаю, глючит адово, и зомбики пропадают (хуй знает, кто их утаскивает обратно в ад). однако это большой шаг вперёд: в декорат впилена поддержка uservars. криво, косо, уёбищно — но впилена.