естественно, так просто всё не бывает. вавумчик хранит 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.»
ну расскажите уже графу кто-нибудь, что такое «-w» в gcc! или хотя бы поясните, как сделать «-wnone». да, я знаю, что уже об этом говорил; но есть на свете вечные ценности — например, рукожоп граф.
и чтобы два раза не вставать: нахуя было делать в zscript `let` вместо `auto`? при том, что `auto` — всё равно зарезервированое слово. или запрещать зяпятую после последнего элемента в инициализаторе массива.
сделал уже прилично, как полагается: добавил настройку хэдшотов в меню опций gzdoom'а. а то там куча опций внутре, но надо было усердно читать исходник, чтобы о них узнать. да, и полностью отключить тоже можно, конечно.
в связи с аннигиляцией ACS-кода из моих модов — убрал и остатки acs-related патчей из gzdoom. заодно убрал и добавленый мной `GetGameTick()`, потому что нашёл глобальную переменную с этой же хуйнёй.
надо узнать ещё, если ли возможность получить список всех классов некоего типа, и можно ли в них поменять default'ы. если да — можно будет убрать хак с ActorAmmoPatchN. тогда brutal weapons должен стать совместим с ваниллой, например.
мне, в общем, не особо интересно этим заниматься, но хочется уже сделать если не красиво, то хотя бы терпимо. и, конечно, чем меньше патчей — тем меньше вероятность, что они сломаются при очередном rebase.
убрал из моего форка кетчупа acs-код. теперь ничего не надо канпелировать, просто скрутил архив — и мод готов. по-идее, он даже совместим с ванильным gzdoom. заодно попереименовывал всё нафиг, чтобы точно не конфликтовать ни с бруталом, ни с оригинальным кетчупом.
я не знаю (и мне лень смотреть), что они там сделали, но рендер стал медленней почти в два раза. риальне, pinnacle of darkness стала неиграбельной из‐за тормозов. а в gzdoom 2 вполне себе нормально работала.
поздравляю, граф, achievement unlocked: мы умудрились сделать тормозной рендер в игре прошлого века, при этом не изменив картинку. да, обычные уровни тоже иногда лагают, особенно если на пол накидать декалей (кетчуп мод, например).
ну, может мне и кажется. но что‐то испортили, это точно!
нет, я понимаю, что оригинальный декорат — редкостное уебанство. но «решать» это добавлением ещё одного скриптового языка… ну, граф, хуле.
долбоёбы, туда отлично ложился ACS. вот зачем надо было ещё один язык пердолить? к тому же хуёво подсмотреный в VaVoom?
actor replace, кстати, до сих пор нет. это, если что, фича, которую я давно себе добавил: жестокая замена одной хуйни на другую. обычный декорат позволяет создавать новые объекты, но не заменять те, что уже существуют. таким образом, невозможно заменить оригинальную пушку или патроны на свою так, чтобы моды считали, что это всё ещё оригинал (ну, если не патчить стандартные дефы gzdoom'а). что дико неудобно, если я хочу, например, иметь вместо стандартных пушек рипнутые из брутала шотган и штурмовуху, но не хочу вшивать их в базовые файлы.
(если кто не понял, почему это удобно: с таким типом замены можно сделать оверрайд оружия, и дроп будет магически дропать новые пушки. не надо ебли со скриптами, не надо замен айтемов — один replace, и всё работает)
колбэков в ACS по попаданию тоже нет, хотя делается это тривиально. зачем? а потому что без них хэдшоты реализуются исключительно путём: «а теперь пишем новый decorate для каждого, сука, актёра. совсем новый.» вместо: «пишем простенький acs-скрипт, и получаем хэдшоты для любых монстров (в том числе и любых новых из модов)». естественно, дегенераты на предложение сделать такой колбэк ответили: «нэ трэба. у нас есть хуёво работающие хаки, которые кое-как позволяют сделать хуёво работающие хэдшоты. иногда.»
мне всё ещё лениво портировать мои патчи в говнокод с zscipt, да и в самом zscipt я нихуя не вижу практической пользы, поэтому я сижу на до-zscript ветке. а на новую посматриваю иногда, чтобы вести счёт пробитым днищам.