HLFX.Ru Forum Страницы (2): [1] 2 »
Показать все 3764 сообщений этой темы на одной странице

HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Наши проекты (https://hlfx.ru/forum/forumdisplay.php?forumid=1)
-- XashNT: блог разработчика (https://hlfx.ru/forum/showthread.php?threadid=5297)


Отправлено Дядя Миша 03-07-2019 в 11:44:

XashNT: блог разработчика

Разработка движка так или иначе носит характер ключевых звеньев, цепляющихся одно за другое. Одна из фундаментальнейших вещей это организация уровня. Всё остальное так или иначе строится вокруг нее. И от этого естественно вплотную зависит конечный результат. Посмотрим. У меня уже был неудачный опыт в 2015-м году, но ведь на тот момент я во всём этом разбирался гораздо хуже. Это вторая итерация, задача имеет следующий вид:
1. построить формат уровня, отвечающий современным требованиям. То есть как минимум он должен спокойно переваривать детализацию уровня Metro Exodus, ну или что-то в этом духе. Но при этом уметь компилировать и старые-добрые карты, типа ad_sepulcher. Вообщем необходимо достигнуть баланса между брашами и моделями, чтобы каждый для себя мог выбрать оптимальный способ построения левелов. Кому-то нравится делать уровни моделями? Пожалуйста, из брашей будут использоваться только триггеры и водичка. Ну и скайбокс конечно. Нравится кубать брашами - аналогично нет проблем. То есть вот такое на первый взгляд противоречивое требование. Это задел на потенциальное расширение аудитории движка в будущем.
2. Компиляция должна проходить быстро. Чтобы как минимум избежать справедливых упрёков в том, что иные движки вообще начисто её лишены. Сами понимаете если у нас будут уровни, где 5-6 миллионов полигонов в кадре, тут уже старые методы не конают. И уж конечно ни в коем случае не ждать пока лайтмаппер неделю освещает уровни как в Сталкере, я почему-то подозреваю, что в Метро от лайтмап отказались именно из-за калечной запекалки. Никому не охота ждать неделю, например. И кстати это одна из причин, по которой сталкера так долго делали. Ну не единственная конечно. Но компиляция здорово крадёт время у разработчиков.
Ну для начала я полагаю достаточно, поскольку это довольно сложные требования. Посмотрим что из этого получится, в этой теме я буду писать о проделанной работе, а вы будете говорить "автор молодец за нее".

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 04-07-2019 в 13:30:

Поскольку ожидается большая порция экспериментов связанных с изменением формата карт, моделей и прочего, я решил написать универсальный базовый класс-абстракцию, от которого будут наследоваться все типы моделей. В теории это позволит иметь зоопарк форматов, но у меня несколько иная цель. Кстати говоря этот же механизм может быть использован для бесшовной подгрузки новых уровней.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 04-07-2019 в 14:31:

Цитата:
Дядя Миша писал:
я решил написать универсальный базовый класс-абстракцию, от которого будут наследоваться все типы моделей

Движок будет на Java, как Майнкрафт?


Отправлено XaeroX 04-07-2019 в 16:23:

Crystallize
Ты действительно этого хочешь?

__________________

xaerox on Vivino


Отправлено FiEctro 04-07-2019 в 16:31:

Ну вот, а говорите я ваши движки обсираю. Сразу видно прогресс, а то так бы до пенсии на кубсп и сидели.

Цитата:
Дядя Миша писал:
2. Компиляция должна проходить быстро. Чтобы как минимум избежать справедливых упрёков в том, что иные движки вообще начисто её лишены.


Не лишены, и далеко не быстрая, но фишка в том что во время разработки можно загрузить голую модель без компиляции. Вообще в современных движках под компиляцией подразумевается уже финальная обработка локации когда всё готово, а не пересобирать карту каждый раз чтобы передвинуть какой нибудь патч трек.

Цитата:
Дядя Миша писал:
Кстати говоря этот же механизм может быть использован для бесшовной подгрузки новых уровней.


Могу немного подкинуть идей. В том же унити есть такая фигня как сцена, это просто описание где и какие игровые объекты находятся в 3д пространстве, и с каким настройками. Их можно загружать/выгружать как тебе удобно.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 04-07-2019 в 17:17:

Цитата:
FiEctro писал:
а не пересобирать карту каждый раз чтобы передвинуть какой нибудь патч трек.

но для этого и не надо пересобирать карту...

Цитата:
FiEctro писал:
это просто описание где и какие игровые объекты находятся в 3д пространстве, и с каким настройками

уровень можно делать незамкнутой моделькой, но тогда не будет виза. Это основная проблема. Я могу нагенерить лод-брашей, основываясь на контурах моделей (невидимых), и эти брашы решат две задачи - коллизию и виз.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 04-07-2019 в 18:21:

Цитата:
FiEctro писал:
Сразу видно прогресс, а то так бы до пенсии на кубсп и сидели

Ты сильно не переживай, в Волатиле такого "прогресса" не будет. Убивать Юнити и уеч придётся кому-то другому.
Цитата:
Дядя Миша писал:
но для этого и не надо пересобирать карту...

Только не рассказывай ему про -onlyents.

__________________

xaerox on Vivino


Отправлено FiEctro 05-07-2019 в 05:50:

Цитата:
XaeroX писал:
Только не рассказывай ему про -onlyents.


Как бы это тоже компилятор делает

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено nemyax 05-07-2019 в 21:28:

Цитата:
Дядя Миша писал:
я решил написать универсальный базовый класс-абстракцию, от которого будут наследоваться все типы моделей. В теории это позволит иметь зоопарк форматов, но у меня несколько иная цель

Какая же?


Отправлено FiEctro 06-07-2019 в 07:54:

nemyax
Наши цели ясны, задачи определены, за работу, товарищи!

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 20-07-2019 в 08:18:

В какой-то мере вышеозвученная идея реализована в том же даркплейсе, но поскольку он на чистом Си, там конечно нет никаких виртуальных методов, там указатели на функции. Идея в том, чтобы не просто сделать такие загрузчики, а чтобы разместить в наследуемых классах абсолютно все методы взаимодействия с загруженными ресурсами, выведя за скобки лишь описания текстур и материалов. То есть вот у нас стандартные методы, LoadModel, DrawModel, CollideModel и через них осуществляется взаимодействие. А внутри может быть как BSP, там и студиомоделька. Што немаловажно, подобный подход, позволит, например иметь в качестве мира эту студиомодель. Или загружать одновременно следующий уровень, не выгружая преведущего, а в момент чейджлевела, просто поменять местами указатели. Ну и разумеется зоопарк форматов. Но повторюсь, зоопарк мне больше нужен для изолированного тестирования новых фичей, чтобы не вносить изменения в уже отлаженную ветку одного формата, а сделать рядом аналогичный и спокойно сравнивать регрессии. Есть у подхода и два минуса, точнее даже не совсем минусы, а потенциальные UB. Во первых как это подружить с кэшированной информацией для каждого эдикта, во вторых - отрисовка полупрозрачных объектов, которая как известно требует сортировки. Впрочем эти две проблемы остаются в любом случае, независимо от архитектуры.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено SNMetamorph 20-07-2019 в 09:35:

На данный момент я так понимаю, XashNT еще только в стадии проектирования?


Отправлено Дядя Миша 20-07-2019 в 09:43:

На данный момент XashNT под угрозой срыва. Буквально час назад выяснилось, что на умирающем винте всё-таки повредились бэкапы и часть текущих исходников. Бэкапы повреждены с начала февраля, а в исходниках client.h и cl_frame.cpp. Не знаю удастся ли это восстановить. Все три резервные копии повреждены, архивы не восстанавливаются.

Добавлено 20-07-2019 в 12:43:

Но покрайней мере остальные части движка компилируются, только ядро не собирается.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 20-07-2019 в 11:42:

Дядя Миша
Понятно, что поздняк и советы постороннего, но попробовал бы бакапиться на bitbucket-е. Там есть приватные репозитории забесплатно. Я пользуюсь, нравится.


Отправлено Дядя Миша 20-07-2019 в 13:32:

проблема в том, что бэкапов минимум шесть источников и абсолютно повезде битые архивы. И как битые - наглухо. Они солидные и без информации для восстановления, когда-то очень давно, в 2007-м году, я поленился прописать этот ключик. Я пытаюсь спасти эти архивы с абсолютно любого диска и абсолютно везде они битые. Одному богу известно когда это вообще началось, ведь диск умирает достаточно давно. Но есть и хорошая новость - client.h и cl_frame.cpp всё таки удалось спасти в целости со старого диска с рабочего компьютера с отформатированного раздела. Таким образом я восстановил работоспособность актуальной копии исходников. А плохая новость заключается в том, что потеряны абсолютно все бэкапы новый ветки, начиная с февраля этого года.

Добавлено 20-07-2019 в 16:32:

Ура. Удалось спасти еще два бэкапа за 24-е и 25-е марта этого года. Если учесть, что апрель-май были отданы работе над параноей, то это почти-что средняя точка, для отладки пригодится. Ну хотя бы не пустое место.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 20-07-2019 в 14:05:

Напомнило вот эту душераздирающую историю: http://www.anim8or.com/smf/index.php/topic,5743.0.html
Там всё кончилось хорошо, он переписал свои потеряшки.


Отправлено Дядя Миша 20-07-2019 в 14:32:

Проблема заключалась в том, что все мои архивы-бэкапы оказлись битыми. И вот это конечно было совсем уму нерастяжимо. Они как NAN расползлись по всем хранилищам. А ведь я был уверен что у меня есть актуальные бэкапы на фрэшке, но увы. Впрочем спасённого достаточно для полноценного продолжения работы. В промежуточных бэкапах не было ничерта интересного.

Добавлено 20-07-2019 в 17:26:

Если я немного туманно написал: текущий прогресс полностью сохранён. Утеряна только б0льшая часть бэкапов в промежутке между февралём-апрелем.

Добавлено 20-07-2019 в 17:28:

Мне это напомнило начало разработки Xash3D. Тогда я точно так же потерял стартовые бэкапы с февраля по июнь. Правда там у меня ничего не полетело. Я их сам удалил, подумал что не пригодятся. Так и оказалось.

Добавлено 20-07-2019 в 17:32:

Ну чтож, выводы из случившегося сделаны. Написан скрипт для тестирования всех бэкапов на валидность, а к скрипту создания бэкапа добавлен параметр сохранения информации для восстановления.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 21-07-2019 в 14:54:

Ну чтож. Не всё так просто, как казалось бы. Испорчены еще cl_view.cpp и cl_gameui.cpp.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Lev 21-07-2019 в 16:24:

Дядя Миша gui? Может оно и к лучшему, и в NT не будет дурацкоко won меню? Или я не о том подумал?)


Отправлено Дядя Миша 21-07-2019 в 17:28:

Я уже всё восстановил, иначе бы ядро не скомпилилось.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 25-07-2019 в 08:44:

Потихоньку переписываю вообще всё. Заворачиваю в синглтоны и атд по смыслу. В движке накопилось очень много мест для шареного кода, эти места лучше всего реализовать в виде закрытых классов. Конечно будь я помоложе, я бы всё это разломал на отдельные дллки, но прав был тот чувак с геймдева, который когда-то сказал мне, пока ты молод и неопытен, тебе хочется всё разделить на модули. А когда ты уже искушенный, для тебя оптимальмым является единый экзешник и никакого DLL Hell. Сейчас, спустя 13 лет, я понимаю, насколько же он был прав.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 25-07-2019 в 08:50:

Цитата:
Дядя Миша писал:
Сейчас, спустя 13 лет, я понимаю, насколько же он был прав.

Он был совершенно не прав. Возможно, он это уже понял. А может быть, и нет, кто его знает.
Цитата:
Дядя Миша писал:
оптимальмым является единый экзешник и никакого DLL Hell

Модули могут быть статически линкуемыми, это не существенно.
Но у статических модулей есть серьёзная проблема - не срабатывает автоматическая инициализация глобальных объектов, из-за чего, как пример, не работает авторегистрация компонентов фабрики. Опытные и искушённые, конечно же, будут регистрировать вручную (они же опытные) или предложат какую-нибудь фичу из Boost (они же искушённые), но что мы говорим таким способам решения простых задач? НЕ СЕГОДНЯ. И переводим lib в dll.

__________________

xaerox on Vivino


Отправлено Дядя Миша 25-07-2019 в 09:37:

Цитата:
XaeroX писал:
Но у статических модулей есть серьёзная проблема - не срабатывает автоматическая инициализация глобальных объектов

да я помню. Поэтому я не использую статические либы. Ну не считая third_party конечно жы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено a1batross 27-07-2019 в 21:50:

Lev +1.

Дядя Миша переноси гуй движка на mainui_cpp. Раз уж и так всё на плюыс переводишь.

А дллки это всё же удобно. Конечно, когда есть цель сделать какой-то модуль опциональным или заменяемым.

__________________
Xash3D FWGS форк


Отправлено Дядя Миша 28-07-2019 в 15:44:

Переписываю загрузчик и менеджер текстур. Фактически - полдвижка. Где-то на этой точке необратимо дропнется потдержка восьмибитных текстур и прочей экзотики, типа впечатывания номера билда в массив пикселей.
Останется только три базовых формата - bmp, tga и dds. Причём, как водится, первые два - для разработки, а последний уже для финальной сборки. Впрочем, в том же крайэнджине в качестве формата источника юзают TIFF, но насколько я помню TIFF это вообще мета-контейнер, а не формат.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 29-07-2019 в 11:15:

Дядя Миша
На каком контенте тестируешь?

Цитата:
Дядя Миша писал:
необратимо дропнется потдержка восьмибитных текстур и прочей экзотики

Халфовских вадов?


Отправлено XaeroX 29-07-2019 в 11:23:

Цитата:
Дядя Миша писал:
типа впечатывания номера билда в массив пикселей.

Только сейчас заметил. Но ведь это же была одна из ключевых фич движка...

__________________

xaerox on Vivino


Отправлено Дядя Миша 29-07-2019 в 12:11:

Цитата:
nemyax писал:
Халфовских вадов?

ну да и их тожы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 08-08-2019 в 18:16:

В процессе перекраивания API и отрезания ненужного в рамках новой парадигмы, после очередного тестового запуска вдруг выскочила давно забытая надпись.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено a1batross 08-08-2019 в 19:42:

>You use is too old version

Ты использовать слишком старая версия!

Добавлено 08-08-2019 в 22:42:

Не мучай трубы.

__________________
Xash3D FWGS форк


Отправлено nemyax 09-08-2019 в 06:40:

Иисус, ваш терапевт имеет лот, чтобы ответить для!
Английский язык через канпелятор не прогонишь


Отправлено Дядя Миша 09-08-2019 в 08:09:

Если вы хотите мой совет - дайте это дерьмо вверх!

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 09-08-2019 в 21:30:

Пришло время избавиться от структурки entvars_t. Ну это которая pev->
Эта зараза пронизывает всю серверную часть движка, поэтому процесс будет непростым.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 09-08-2019 в 21:34:

>https://hlfx.ru/forum/attachment.ph...=&postid=182326
там блуум от неба или?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 09-08-2019 в 21:38:

годреи это. Да они есть в финальной версии XashXT, сюда по наследству попали.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Ku2zoff 10-08-2019 в 12:54:

Цитата:
Дядя Миша писал:
Пришло время избавиться от структурки entvars_t.

А что будет взамен? Чтобы и на клиенте и на сервере была одна и та же структура для синхронизации?


Отправлено a1batross 10-08-2019 в 14:34:

Ku2zoff но на клиенте нет entvars_t. Да и энтварсы не для синхронизации. Для этого entity_state_t, а вот что с ним Дядя Миша решит делать...

Добавлено 10-08-2019 в 17:34:

string_t я надеюсь тоже под нож?

__________________
Xash3D FWGS форк


Отправлено XaeroX 10-08-2019 в 14:39:

Цитата:
a1batross писал:
string_t я надеюсь тоже под нож?

Ага, заменить на std::string!

__________________

xaerox on Vivino


Отправлено thambs 10-08-2019 в 14:46:

XaeroX
А чем он плох? (без троллинга, действительно любопытно).

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено a1batross 10-08-2019 в 14:53:

XaeroX как вариант. Хотя что-то мне подсказывает, что Дядя Миша наврядли что-то использует из STL.

Добавлено 10-08-2019 в 17:53:

thambs string_t-то? Ну, в первую очередь, это рудимент от кваки, где виртуальная машина работала со строками довольно бедно и фактически лишь давала идентифактор. Может я тут где-то ошибаюсь.

Valve запихнули проблему ещё дальше, сделав из string_t просто разницу указателей. В итоге литералы у нас идут в MAKE_STRING, а генерируемые строки в ALLOC_STRING.

__________________
Xash3D FWGS форк


Отправлено XaeroX 10-08-2019 в 15:00:

Цитата:
thambs писал:
А чем он плох?

Навскидку: динамическая реаллокация, оверхед по памяти, лёгкость пессимизации при замене string_t, который привычно передаётся по значению, потенциальная непредсказуемость поведения из-за мути в стандарте (SOO, COW).

Добавлено 10-08-2019 в 22:00:

Цитата:
a1batross писал:
Ну, в первую очередь, это рудимент от кваки

Один дурак сказал, и все начали повторять про рудимент...
Цитата:
a1batross писал:
В итоге литералы у нас идут в MAKE_STRING, а генерируемые строки в ALLOC_STRING.

Тут пожалуй единственная проблема - неудачное название MAKE_STRING, оно нелогичное и запутывающее.
Кстати, ку3шный аллокатор строк умеет детектировать самые популярные литералы, например, и не аллокать для них память.

__________________

xaerox on Vivino


Отправлено Дядя Миша 10-08-2019 в 16:26:

Цитата:
Ku2zoff писал:
Чтобы и на клиенте и на сервере была одна и та же структура для синхронизации?

Можно сделать чтобы клиент и сервер были в одной дллке, точнее говоря, описание энтить.

Цитата:
a1batross писал:
string_t я надеюсь тоже под нож?

Нет, там теперь сетевая таблица уникальных строк. И туда же до кучи пути к моделям, звукам, чтоб не хранить в отдельных массивах.

Цитата:
a1batross писал:
Valve запихнули проблему ещё дальше, сделав из string_t просто разницу указателей

оно и в кваке так было.

Добавлено 10-08-2019 в 19:26:

Цитата:
a1batross писал:
Для этого entity_state_t, а вот что с ним Дядя Миша решит делать...

Эту пакость обязательно надо убрать, она весь движок на себе держит и ограничивает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено a1batross 10-08-2019 в 18:54:

XaeroX ну черт его знает. В условиях отсутствия ВМ я не вижу смысла так работать со строками.

Я на самом деле и не против. Просто string_t должен быть явно помечен как платформозависимый и вообще не давать возможности разработчику записывать его в файл(о_О), передавать по сети(что только в воспаленное сознание не придёт), сравнивать его численное значение с другими, помимо равенства наверное, да и вообще не иметь доступа к нему именно как идентификатору.

Именно он был и есть самой большой проблемой при порте на 64-битные указатели.

__________________
Xash3D FWGS форк


Отправлено Дядя Миша 10-08-2019 в 19:08:

Цитата:
a1batross писал:
В условиях отсутствия ВМ я не вижу смысла так работать со строками.

Вообще-то стрингтабля идеально для игровых движков подходит, независимо от наличия в них какой-то пользовательской виртуальной машины. Потому что мы имеем дело с кучей константных строк, которые очень часто сравниваются друг с другом и имеют множество дубликатов. Т.е. идея поместить их в единый уникальный массив напрашивается сама-собой. Энтити постоянно запрашивают поиск по таргетнейму, класснейму, да мало ли почему. И всегда выгоднее сравнивать идентификатор строки, чем каждый раз запускать strcmp. И соответственно этот же массив передаётся на клиент, в том же порядке, чтобы строки были доступны и там. Аналогично, когда мы передаём пользовательскую мессагу, нам необязательно каждый раз слать настоящую строку - достаточно послать её идентификатор, а движок автоматически синхронизирует строки на клиентской части (если строка новая и уникальная).

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 12-08-2019 в 20:45:

Потихоньку переношу из entvars_t в CBaseEntity. Их там более ста штук, вот такая тупая работа и отымает чёртову уйму времени. Попутно жы еще пишу разные новые механизмы, типа парсера новых кейвалуев, поиска по строкам в DATAMAP и прочего. Ну и стараюсь убрать эту порочную практику, когда для новых энтить вовсю использовались переменные из entvars_t подходящие по типу, чтобы не возится с описанием IMPLEMENT_SAVERESTORE и прочей гадости. Помоему это Лаури первым придумал, этот фантазёр.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 12-08-2019 в 20:55:

Дядя Миша
это из-за этого всякие полезные параметры называются неочевидными ключами вроде netname и подобного?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 12-08-2019 в 21:25:

Именно так, да. В халфе довольно сложная возня с объявлением сейв-рестора, чтобы в новой энтите сохранить хотя бы одну переменную, надо скопипастить довольно большой кусок кода и там поперименовывать всё. А потом еще и в KeyValue добавить лишнее условие, народ (и я в том числе), предпочитали брать уже готовые переменные. Вот в кваке там с этим было хорошо, объявил переменную с точкой и она у тебя уже и из настроек сразу читается и в сейв пишется.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 12-08-2019 в 21:32:

Дядя Миша
А ты как теперь делаешь эту систему, там какая-то сериализация или?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 12-08-2019 в 21:54:

Там с 12-го года другая сериализация, похожая на ту что в сорсе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FreeSlave 13-08-2019 в 01:15:

Цитата:
Дядя Миша писал:
Ну и стараюсь убрать эту порочную практику, когда для новых энтить вовсю использовались переменные из entvars_t подходящие по типу, чтобы не возится с описанием IMPLEMENT_SAVERESTORE и прочей гадости. Помоему это Лаури первым придумал, этот фантазёр.


Этим занимались сами Valve. body у gibshooter в качестве количества сабмоделей, netname у монстров в качестве названия сквада, message в самых разных смыслах и т.д.

__________________
I'm on github
I'm on opendesktop.org


Отправлено XaeroX 13-08-2019 в 06:17:

Мне кажется, энтварсы очень удобная штука. Они позволяют шарить основные параметры энтитей между разными библиотеками, и в том числе с ботами и скриптовой системой (в волатиле это например Lua). А переиспользуются они в целях экономии памяти, и в этом с точки дизайна нет ничего плохого. Единственное что я делаю - добавляю в класс простенькие геттеры/сеттеры, чтобы по ходу кода потом не гадать, что же тут значит pev->body.

__________________

xaerox on Vivino


Отправлено Дядя Миша 13-08-2019 в 06:37:

энтварсы для разработчика это UB в первую очередь, потому что нет никакого соглашения какие переменные смотрит движок, какие он меняет, на какие реагирует, на какие возможно будет реагировать в дальнейшем.
В квейке была виртуальная машинка и там было совсем другое дело.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 13-08-2019 в 06:53:

Дядя Миша
Движок реагирует на очень небольшое число энтварсов, и как правило, они имеют вполне чёткое предназначение, типа classname или origin. Но я согласен, работу движка с энтварсами надо минимизировать, они нужны пользовательским дллкам, и конечно же скриптовой системе, которая ничего не знает про pvPrivateData.

__________________

xaerox on Vivino


Отправлено Дядя Миша 13-08-2019 в 07:30:

Цитата:
XaeroX писал:
Движок реагирует на очень небольшое число энтварсов, и как правило, они имеют вполне чёткое предназначение, типа classname или origin.

я тебе про то, что в халфе получилось. Там как минимум половина энтварсов просматривается движком без чёткой логики со пользовательской стороны. Скажем pev->flags используется частично. Некоторые флаги движок не смотрит, причём они даже по диапазонам не разделены. Ну как повизёт.
Удачный интерфейс - это явный каллбэк, а не вот такой вот просмотр приватдаты по тихому. А в той же кваке движок мог даже пользовательские переменные искать из вирт.машины, она же как решето в этом смысле. И менять он их тоже мог. Нет в таком подходе ничего хорошего.

C++ Source Code:
1
struct edict_s
2
{
3
  int		flags;		// edict->flags
4
  float		freetime;		// sv.time when the object was freed
5
  int		serialnumber;	// increment each time when entity was freed
6
  link_t		area;		// linked to a division node or leaf
7
  void*		pvPrivateData;	// alloced, freed and used by DLLs
8
};

мой эдикт вот так выглядит сейчас. Единственное поле, которое смотрит движок - это flags. В остальные он не лезет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 13-08-2019 в 07:45:

Дядя Миша
А если ты потом захочешь скрипты прикрутить, ну или блупринты какие-нибудь, как ты туда инфу о классах протащишь?
Не знаю, как в новом УЕ, а в старом классы были на UnrealScript и к ним был доступ через специальный экспорт, где перечислялись "внешние" поля. Но на плюсах ты так легко не сделаешь, по идее.

__________________

xaerox on Vivino


Отправлено Дядя Миша 13-08-2019 в 07:58:

Цитата:
XaeroX писал:
как ты туда инфу о классах протащишь?

ну посмотри как в третьем дууме сделано. Там скрипт является продолжением класса, объявленного в движке и наследует его поля. Очень оригинально, я такого больше нигде не видел.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 13-08-2019 в 08:11:

Цитата:
Дядя Миша писал:
Очень оригинально, я такого больше нигде не видел.

Емнип, классы UnrealScript тоже наследовались от базовых движковых.

__________________

xaerox on Vivino


Отправлено Дядя Миша 13-08-2019 в 11:41:

Я Unreal никогда толком не ковырял, так ничего сказать не могу.

Добавлено 13-08-2019 в 14:41:

Думаю настала пора полностью отказаться от лайтмапы, в NT будет только динамическое освещение.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 13-08-2019 в 11:44:

Дядя Миша
А на каком варианте для индиректа ты решил остановиться? А вообще жаль, лайтмэпы дюже православны.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено XaeroX 13-08-2019 в 12:07:

Цитата:
Дядя Миша писал:
в NT будет только динамическое освещение.

Главное, чтобы оно не выглядело хуже лайтмапового.

__________________

xaerox on Vivino


Отправлено nemyax 13-08-2019 в 12:12:

Вместо рада будет расчёт каких-то специфических данных для динамики?


Отправлено Дядя Миша 13-08-2019 в 12:59:

Цитата:
thambs писал:
А на каком варианте для индиректа ты решил остановиться?

Здесь остаётся простор для экспериментов. Пока еще не определился.

Цитата:
thambs писал:
А вообще жаль, лайтмэпы дюже православны.

Для халфовских простых уровней - несомненно. А когда начинаешь делать уровни модельками - это такая головная боль получается. В моделях полно мелких деталей, как их освещать? повертексно? Пол-модели повертексно, пол-модели лайтмапой? и рисовать тоже по маленьким кусочкам? Потом надо будешь еще заново придумать как освещать персов. Затыкать весь уровень лайтпробами или что-то типа того. И сверху один хрен еще написать слой динамического освещения, для всяких фонариков и спышек. И компилятор, который запекает лайтмапы без швов. Еще и каждый раз ждать, пока оно там запечётся часами. Вот так вот посмотришь на всё это и никакого желания опять связываться. Лайтмапа хороша когда требования игроков не выходят за рамки графона от ку3. То есть такие условности повезде. Ну там двери тени не отбрасывают, от игрока пятнышко. Мне Элбер уже весь мозг выел - надо говорит тень от игрока. Я вот думаю тень от того, тень от этого, а нахрена там тогда вообще лайтмапа, если вам нужны деномические тени?

Добавлено 13-08-2019 в 15:58:

Цитата:
nemyax писал:
Вместо рада будет расчёт каких-то специфических данных для динамики?

Посмотрим. До этого относительно долико еще.

Добавлено 13-08-2019 в 15:59:

Цитата:
XaeroX писал:
Главное, чтобы оно не выглядело хуже лайтмапового.

Да вот смотрел вчера видос про UE4 и не мог понять лайтмапа это или фуллдинамика. Оказалось всё-таки второе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 13-08-2019 в 13:30:

Цитата:
Дядя Миша писал:
Да вот смотрел вчера видос про UE4 и не мог понять лайтмапа это или фуллдинамика. Оказалось всё-таки второе.

Ну так то ли UE4, то ли расеюшка, где щи лаптем хлебают.
Лайтмапа, как ни крути, отработана десятилетиями, и с ней нужно постараться сделать некрасиво. А с динамикой - в два счёта. Ну или красиво, но с тормозами, как в униджине.

__________________

xaerox on Vivino


Отправлено Дядя Миша 13-08-2019 в 13:47:

Так я ж наоборот говорю, в наше время фуллдинамик быстрее лайтмапы будет. Если конечно пытаться сделать нечто похожее на динамику.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 13-08-2019 в 13:58:

Цитата:
Дядя Миша писал:
Лайтмапа хороша когда требования игроков не выходят за рамки графона от ку3.

И тем не менее лайтмапа использовалась в the last of us, uncharted 4, doom 2016


Отправлено XaeroX 13-08-2019 в 14:17:

Цитата:
Дядя Миша писал:
в наше время фуллдинамик быстрее лайтмапы будет

Это с учётом времени компиляции или без?

__________________

xaerox on Vivino


Отправлено FiEctro 13-08-2019 в 14:27:

На риватнт ни то ни другое точно не запустится, особенно если ДДС в несжатые текстуры распаковывать

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено XaeroX 13-08-2019 в 14:54:

FiEctro
Ну вот опять ты ложные слухи распускаешь. А потом жалуешься, что тебя в аське в игнор добавляют.

__________________

xaerox on Vivino


Отправлено Дядя Миша 13-08-2019 в 14:58:

ncuxonaT ну про дуум это ты уже сам придумал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 13-08-2019 в 15:21:

Дядя Миша http://advances.realtimerendering.c...016_idTech6.pdf
слайд 20
Diffuse indirect lighting: Lightmap for static geometry, irradiance volumes for dynamics


Отправлено Дядя Миша 13-08-2019 в 15:27:

ncuxonaT ты помоему еще вчера жаловался, что времени нет ни на что, а сегодня оно уже есть

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 13-08-2019 в 21:24:

Дядя Миша может, я последовал совету


Отправлено Дядя Миша 14-08-2019 в 07:38:

Я выше уже написал почему не хочу связываться с лайтмапами.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 14-08-2019 в 07:43:

Дядя Миша
Потому что не можешь сделать нормальные лайтмапы для моделей?

__________________

xaerox on Vivino


Отправлено Дядя Миша 14-08-2019 в 08:19:

XaeroX нормальная лайтмапа - это которая в реалтайме считается каждый кадр

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 14-08-2019 в 08:34:

Дядя Миша
The fastest way to compute is to precompute.

__________________

xaerox on Vivino


Отправлено Дядя Миша 16-08-2019 в 11:40:

Я вот чем больше изучаю другие движки тем больше склоняюсь к тому, что вот это разделение на клиентские и серверные энтити - это невероятная дурь и она не нужна абсолютно. Ничего кроме неудобства, дублирования кода и повышенного потребления памяти она не создает.
Движок никогда не работает в таком режиме, когда бы его два набора энтить оказались разделены реальным сетевым соединением, это всегда две разные копии игры на удалённых машинах, ну или хотя бы на одной, но через микрософтовский лупбэк. То есть нет никакого резона держать в рамках одной сессии два набора энтить. Это очень порочная практика, которая порождает массу проблем на самом деле, но мы уже настолько к ним привыкли, что даже не можем себе представить, что может быть как-то иначе. Ну например чисто серверная энтить по дефолту не имеет предиктинга. В лучшем случае он достается только игроку, хотя по идее должен быть у всех энтить абсолютно. То есть у нас либо один и тот же файл компилируется дважды, на клиенте и на сервере, либо вообще для клиента приходится городить какой-то отдельный урезаный огород, который бы выполнял функцию предиктинга. Если функционал серверной энтити поменяется - значит клиентскую тоже надо пересобрать как минимум. Наиболее отвратный пример такого подхода - голдсорсовский предиктинг оружия. Насколько я знаю его так никто и не освоил, в лучшем случае копипастой с похожего оружия. Народ просто не понимает что там и куда копировать, чтобы это работало. При том что наилучшие результаты предиктинга вообще-то достигаются при полной идентичности клиент-серверного кода, а единственное что меняется - это время с серверного на клиентское. Второй негативный момент - два набора энтить потребляют в несколько раз больше памяти. Зависит от организации этого набора. Может и в два, а может и в полтора. И на клиенте у нас всегда несовпадающий функционал, из-за чего даже трассу приходится дублировать. Причём это справедливо, даже если ты не просто пишешь новые энтити, а что-то делаешь в движке. Если ты что-то сделал на серверной части, у тебя сразу головная боль - надо чтобы на клиенте это тоже работало. Но два набора это не предел. Теперь когда мы передали энтити на клиент нам еще надо их нарисовать. Для чего выделяется очередной список либо из клиентских, либо из особых рендер_энтить. Что в свою очередь порождает проблему слабой контролируемости рендерера из сервера. Ну вы помните как скорость движения конвейера в рендерколор запихнули. И соответственно в движке ответный хак. Хотя оптимальным выходом была был виртуальная функция в классе энтити, ну что-то типа ChangeRendererParams и там для этой энтити бы применялись какие-то настройки. Аналогично и с отрисовкой. Иметь в классе энтити еще один виртуальный метод типа DrawModel. И там уже прекрасно себе настраивать кости или еще что-то специфичное выполнять. И всё это в рамках одной библиотеки. Зачем дизайнеру игрового кода вообще забивать себе голову клиент-серверной архитектурой, особенно если разрабатывается сингл?
А для сетевой модели в класс добавляются пара виртуальных же функций, типа ReadFromSnapshot и WriteToSnapshot, по аналогии с сейв-рестором. И оно там себе само прекрасно пишет и читает, минуя промежуточные стадии вроде entity_state_t. baseline при таком подходе создаётся вообще автоматически - клиент точно так же спавнит карту и читает на ней все энтити и к моменту прихода первой дельты у него уже есть с чем её сравнивать. То есть baseline вообще не надо никуда передавать. Чисто клиентские энтити в эту систему укладываются даже лучше чем в классическую. Нам достаточно будет добавить что-то типа настроечного флага FCAP_CLIENT_ENTITY и всё. В сингле её проспавнит сервер, в мультике - клиент, и в обоих случаях у нас будет с ней нормальная коллизия с предиктингом. Да, её нельзя удалять с карты, она будет занимать слот, но она будет его занимать в любом случае, если мы хотим её сохранить в сейв например. Просто она будет занимать какой-то отдельный массив, а при записи демки, к примеру. нам всё равно придется заново переслать эти энтити на клиент. То есть все вот эти уловки с отдельными массивами для специфических энтить, они только усложняют и запутывают всё дело, из-за неудачно выбранной архитектуры однажды.
Еще момент - двойной набор энтить предполагает и двойную её обработку, как на клиенте, так и на сервере. Причём фпс при таком подходе будет падать экспоненциально с ростом кол-ва энтить, как вы понимаете, при условии что на клиенте присутствует тот же предиктинг с коллизиями. Вообщем нет положительных сторон. Но мы уже привыкли что их два набора и не можем себе представить что возможно как-то иначе. Стереотип короче говоря.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 16-08-2019 в 12:34:

Цитата:
Дядя Миша писал:
Причём фпс при таком подходе будет падать экспоненциально с ростом кол-ва энтить

Почему не линейно?

__________________

xaerox on Vivino


Отправлено Дядя Миша 16-08-2019 в 13:20:

XaeroX ну хотя бы потому что фпс всегда падает экспоненциально 1/х - это экспонента.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 17-08-2019 в 09:50:

Чтобы не было недопонимания: я любую нелинейную функцию называю экспонентой, а уж парабола там или гипербола в данном случае непринципиально.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 17-08-2019 в 10:55:

Дядя Миша
А зачем? Вот почитает тебя какой ни будь Гуль, например, — и у него окончательно крышу сорвёт, уже не только в плоскую землю уверует, а число pi опровергать начнёт. Спросят, а кто же виноват, кто его так с ума свёл? А вот он! Это всё Дядя Миша, сидит в кустах с хитрой ухмылкой.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено XaeroX 17-08-2019 в 11:14:

Цитата:
thambs писал:
Вот почитает тебя какой ни будь Гуль

А ты - для чего?

__________________

xaerox on Vivino


Отправлено Дядя Миша 17-08-2019 в 16:39:

Цитата:
thambs писал:
А зачем?

в данном контексте речь шла о линейности\нелинейности. А уж как правильно называется та или иная загогулина я навскидку вспомнить не смог. Вы так возмутились как будто я переодическую функцию назвал экспонентой. И вообще. Если кто-то чем-то недоволен, он может выразить своё возмущение прямо мне на яндекс.кошелёк в денежном эквиваленте.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено a1batross 18-08-2019 в 16:45:

Дядя Миша а исходит ли это в принципе из клиент-серверной архитектуры?

Всегда на что-то отдается больше предпочтение и соответственно проектируется. Хорошо, у нас единые энтити и на клиенте, и на сервере. Это будет работать в сингле, но что делать с мультиплеером? Делаем под мультиплеер и в итоге получаем все предиктинги и прочие лагокомпенсации, потому что игровой мир клиента не равен миру сервера.

__________________
Xash3D FWGS форк


Отправлено Дядя Миша 18-08-2019 в 16:48:

Это для мультиплеера даже более оптимально, чем традиционная модель, я бы сказал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 18-08-2019 в 20:25:

Дядя Миша Код станет меньше и понятней?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 18-08-2019 в 20:44:

я вот склоняюсь к тому, чтобы наружу вынести только скрипты, ну типо прогс.дат как в квейке или что-то вроде этого. А остальное всё в движок упрятать и пусть оно там уже будет. Никому это неинтересно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено SNMetamorph 19-08-2019 в 14:26:

Цитата:
Дядя Миша писал:
Наиболее отвратный пример такого подхода - голдсорсовский предиктинг оружия. Насколько я знаю его так никто и не освоил, в лучшем случае копипастой с похожего оружия. Народ просто не понимает что там и куда копировать, чтобы это работало.

Дико плюсую, это как раз одна из самый геморойных частей кода HLSDK, очень долго с ней ковырялся.
А, ещё дико бесит прописывание "заглушек" на клиенте для методов серверных базовых классов. Думаю, потом просто неиспользуемые на клиенте методы изолирую от компиляции через #ifndef CLIENT_DLL, не знаю что еще с этим ужасом делать.


Отправлено Дядя Миша 19-08-2019 в 14:36:

Я напомню, что обновлённый голдсорс делался на базе QW, который был физически разделён на клиент и сервер. Вот оттуда все ушы и растут.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 20-08-2019 в 12:30:

Цитата:
Дядя Миша писал:
склоняюсь к тому, чтобы наружу вынести только скрипты

На чём скрипты?


Отправлено Дядя Миша 20-08-2019 в 15:36:

Пока что всё под вопросом. Остановил разработку, надо подумать как лучше сделать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 20-08-2019 в 15:48:

Дядя Миша
Но скрипты это очень хорошая и правильная идея, в любом формате, хоть на хацкеле.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено XaeroX 20-08-2019 в 15:52:

На хаскеле, это было бы очень круто!

__________________

xaerox on Vivino


Отправлено nemyax 20-08-2019 в 16:00:

Как говорится, Maybe. Кстати, почему нет, для скриптинга-то. Только вряд ли найдётся компактный интерпретатор.


Отправлено Дядя Миша 03-09-2019 в 08:24:

Халфовская игровая дллка, это эталонный пример анти-паттерна конечно.
Это надо всем начинающим пограмистам показывать как не надо делать.
В кваке был целостный эдикт и непрерывный массив, что хотя и увеличивало потребление памяти с одной стороны, но с другой гарантировало нам, что мы никогда не промахнёмся по адресу, можем ссылаться на мёртвые эдикты и так далее. В халфе, мало того что разрушили эту концепцию, казалось бы с благой целью, так еще и долгое время не могли определиться что послужит базовым указателем на сущность. entvars_t? edict_t? CBaseEntity?
В итоге мы имеем три сущности и три преобразования-апкаста туда и сюда, которые вообще не несут абсолютно никакого смысла, только запутывают.
Плюс еще те переменные, что входят в состав entvars_t неявно модифицируются\читаются движком и об этом нигде ничего не написано. Отдельного упоминания заслуживают флаги, часть флагов явно задаёт поведение движка, а часть существует только в игровом коде.
В сорсе на первый взгляд попытались это привести в порядок, но на деле только осложнили ситуацию. Там теперь всё в каллбэках, чтобы сделать типичный вызов движковой функции надо писать класс-заглушку с каллбэком и от нее наследовать какую-то чертовщину. То есть вот мы к примеру хотим отправить сетевое сообщение всем клиентам. Мы уже не можем написть MSG_ALL, нам надо городить специальный класс, который пропускает сообщение для всех клиентов в каллбэке. Пример избыточной гибкости, которая может пригодится примерно никогда.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 03-09-2019 в 08:35:

Цитата:
Дядя Миша писал:
долгое время не могли определиться что послужит базовым указателем на сущность. entvars_t? edict_t? CBaseEntity?

В халфе чётко определились. Базовая сущность это edict_t. У него есть "скриптовые" поля entvars_t, которые (в теории) могут быть доступны виртуальной машинке. Да, в халфе ВМ не реализовали, но я в HLFX0.7 упражнялся и оценил это разделение в полной мере. Что касается CBaseEntity, то это класс, целиком инкапсулированный в дллке и невидимый извне. Это логическая обвёртка, которая движку не нужна. Важный плюс такой архитектуры - движок может быть скомпилен MSVC, а дллки, скажем, GCC. И она - после ряда неархитектурных фиксов - будет загружаться и работать. В Волатиле оно так и происходит: мы хоть и заставляем пользователя что-то там компилировать, но по крайней мере не требуем строгую "модель" и версию компилятора.
Цитата:
Дядя Миша писал:
и об этом нигде ничего не написано.

Это не пример антипаттерна, это пример плохой документации.
Цитата:
Дядя Миша писал:
В сорсе на первый взгляд попытались это привести в порядок, но на деле только осложнили ситуацию.

Ну код-то по факту стал читабельнее? Не надо лезть в код движка и/или документацию и смотреть, что делает магическая константа MSG_ALL?
Чем больше людей работают над кодом, тем важнее такая избыточность, и тем дольше этот самый код пишется в принципе. Поэтому зависимость "число человек - число реализованных фич" не линейная.

__________________

xaerox on Vivino


Отправлено Дядя Миша 03-09-2019 в 15:44:

Цитата:
XaeroX писал:
Базовая сущность это edict_t. У него есть "скриптовые" поля entvars_t, которые (в теории) могут быть доступны виртуальной машинке.

Это если бы они так планировали сделать изначально. А им entvars достались в наследство. И edict_t ни разу не базовая сущность. Она была таковой в кваке, где виртуальная машинка управлялась именно с эдиктами.
В халфе эдикт нужен только для того, чтобы движок примерно понимал с чем ему иметь дело, ему даже не столько сам эдикт нужен, сколько его номер в массиве.

Цитата:
XaeroX писал:
Ну код-то по факту стал читабельнее?

я бы так не сказал. Проще написать MSG_ALL, чем каждый раз копипастить этот класс с каллбэком. Кстати говоря, как такие вещи по научному называются? Когда весь класс создаётся только ради одной виртуальной функции.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 04-09-2019 в 10:26:

Замутил АТД для string_t для удобства. Теперь не надо писать каждый раз эти идиотские ALLOC_STRING, STRING, теперь как в виртуальной машинке

pev->targetname = "player";

и была же охота вальвовцам копипастить одно и тоже сотни раз.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 04-09-2019 в 11:00:

std::string, надеюсь, а не велосипед?

__________________

xaerox on Vivino


Отправлено Дядя Миша 04-09-2019 в 11:11:

я не пользую STL

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 04-09-2019 в 11:43:

Дядя Миша
Какой смысл писать на С++ и не пользовать STL?
STL уже давно часть языка.

__________________

xaerox on Vivino


Отправлено Дядя Миша 04-09-2019 в 12:03:

XaeroX вывези ваську

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 05-09-2019 в 20:14:

Долбанные энтварсы, когда же они уже закончатся. Этот рефакторинг я навсегда запомню как самое бессмыссленное и в то же время необходимое действие.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 06-09-2019 в 12:30:

Цитата:
Дядя Миша писал:
Долбанные энтварсы, когда же они уже закончатся. Этот рефакторинг я навсегда запомню как самое бессмыссленное и в то же время необходимое действие.


Ничего! Мастера это не остановило когда он сортировал delta.lst. Ты теперь достойный продолжатель его великого деда дела!

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 06-09-2019 в 12:58:

Мастер от своей сортировки ничего не получил. А у меня рефакторинг архитектуры. Потом еще от entity_state_t избавляццо.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 06-09-2019 в 13:10:

Дядя Миша
Ну зачем ты так. Мастер получил красивый и отрефакторенный delta.lst.

__________________

xaerox on Vivino


Отправлено Дядя Миша 07-09-2019 в 14:09:

C++ Source Code:
1
typedef struct entvars_s
2
{
3
  int		rendermode;
4
  float		renderamt;
5
  vec3		rendercolor;
6
  int		renderfx;
7
} entvars_t;

Вообщем всё что осталось на текущий момент. Планирую сегодня избавиться полностью, а дальше самое интересное начнётся.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 07-09-2019 в 14:21:

Дядя Миша
Неправильно! Должно быть вот так отсортировано:

C++ Source Code:
1
typedef struct entvars_s
2
{
3
  float		renderamt;
4
  vec3		rendercolor;
5
  int		renderfx;
6
  int		rendermode;
7
} entvars_t;

__________________

xaerox on Vivino


Отправлено Дядя Миша 07-09-2019 в 14:38:

Сам говорит дела, времени нет, сам строчки сортирует, уму нерастяжымо

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 07-09-2019 в 14:46:

Дядя Миша
Я ему помочь стараюсь - а он недоволен.

__________________

xaerox on Vivino


Отправлено Дядя Миша 07-09-2019 в 15:59:

XaeroX если бы ты еще пинговался, так тебе бы цены не было

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 08-09-2019 в 10:03:

Определился. Будет две "пользовательские" библиотеки, в кавычках, потому что я пока еще не решил, буду ли раскрывать их сорцы всем желающим.
Progs.dll и GameUI.dll. В первой будут находится все энтити единый клиент-серверный массив, он же используется для рендеринга и в самих энтитях будет метод Draw ну или что-то вроде этого. И GameUI.dll где клиентский худ и главное меню. Их нет смысла разделять, это по сути один хрен.
а в ядре остаётся абстрактный бакэнд, работа с файловой, сетью, форматами моделей и звуков.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 08-09-2019 в 10:07:

Дядя Миша
А с vm что решил?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено XaeroX 08-09-2019 в 10:26:

Цитата:
Дядя Миша писал:
В первой будут находится все энтити единый клиент-серверный массив, он же используется для рендеринга и в самих энтитях будет метод Draw ну или что-то вроде этого

Вот этот подход, он очень развращает. Человек перестаёт мыслить клиент-серверно, постепенно деградирует, в его модах половина эффектов начинает работать исключительно у локального игрока, а заканчивается всё поиском класса камеры в чужих сорцах.

__________________

xaerox on Vivino


Отправлено Дядя Миша 08-09-2019 в 11:36:

Цитата:
thambs писал:
А с vm что решил?

VM попозжы. Но скорее всего она будет. Потому что очень многие вещи энтитями делать невдобно, хотя и реально. Это какой-то артхаус получается, вот мне правильно Ксер подсказал.
У нас мульти_ватчер это кондиция, а мульти_свитчер это свитч-кейсы. И вот мы на этом пытаемся собрать логический код. Там где хватило бы нескольких строчек в скрипте.

Цитата:
XaeroX писал:
Человек перестаёт мыслить клиент-серверно, постепенно деградирует

У нас клиент-серверно даже Мастер мыслить не мог, всё удивлялся, почему он на сервере квары настроит, а нелокальный игрок их невидит.
Надо наоборот, чтобы это было прозрачно для пользователя. Чтобы он не гадал почему у него что-то не передалось, а он забыл в дельте строчку прописать. Меня самого это всегда бесило. Там скопируй, тут скопируй, в дельте пропиши, найди свободную переменную, да идите вы нафиг с такими приколами. Почему юзер должен таким бакэндом заниматься?
В сорсе не лучше, там еще хуже. Сперва объяви перемменную как CNetworkVar, потом из этих переменных создай табличку отправки на клиент, потом на клиенте построй точно такую же таблику, потом вручную прими все переменные, проинтерполируй по вкусу. На кого это рассчитано?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 08-09-2019 в 12:40:

Цитата:
XaeroX писал:
Человек перестаёт мыслить клиент-серверно, постепенно деградирует, в его модах половина эффектов начинает работать исключительно у локального игрока

Разве при аццуцтвии клиент-серверного разделения оно не будет работать у всех одинаково?


Отправлено XaeroX 08-09-2019 в 12:47:

nemyax
Оно будет работать там, где оно имеется. Создали объект на сервере - имеем его на сервере. Создали на клиенте - имеем его на клиенте. А для синхронизации уже нужны приседания. Дядя Миша, видимо, хочет эти приседания заранее предусмотреть и всё-всё синхронизировать автоматически, при этом максимально экономя трафик. Пока звучит как утопия. Но будем посмотреть.

__________________

xaerox on Vivino


Отправлено Дядя Миша 08-09-2019 в 13:09:

Насчёт экономии трафика я ничего не говорил. Я исхожу из того очевидного, но упорно игнорируемого соображения, что ситуации, в которой нам может понадобиться два комплекта энтить попросту не существует. Если сервер в режиме дедика - это один комплект энтить. Если клиент подключился к удалённому серверу - это один комплект энтить.
Таким образом для любого сетевого подключения нам требуется один комплект энтить. Чтобы это понять необязательно даже глубоко разбираться в теме. И два комплекта нам почему-то требуются в случае локальной игры, т.е. там где они точно так же не нужны. А поскольку локальная игра, это еще и синглплеер, мы имеем бесполезный перерасход памяти на два набора энтить. Какой в этом смысл? Да никакого абсолютно.
Это такая же пакость, навроде SQB, однажды сделали неоптимально и потом тащили аж до третьей кваки. Но там еще дальше пошли - там и карту зачем-то два раза начали загружать, отдельно для коллизии и для рендеринга. Опять таки смысла никакого.
Я вам так скажу это основная беда движкописателей - взять какой-то форк за основу и на этой основе просто наворачивать тени мягкие, физику и так далее. Осознать, что архитектура требует пересмотра никто не может и не хочет. Даже Ксерокс.

Добавлено 08-09-2019 в 16:09:

ЗЫ. конечно если в игре предполагается 600-900 эдиктов, то как бы и пофигу. А вот 20-30 тысяч уже не получится при таком раскладе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 08-09-2019 в 13:12:

Дядя Миша

Цитата:
И вот мы на этом пытаемся собрать логический код. Там где хватило бы нескольких строчек в скрипте.

Именно так и получается. Причём если делать в джеке, то из этих связок энтить получается write only каша, на которую если через неделю взглянешь, то вспомнить что там куда и кого активирует становится решительно невозможно. Я из-за этого всё это в отдельные .ent-файлы оформлял, но и там опять же то что на DSLе выразилось бы в пару строчек разрастается на пару десятков. А казалось бы, столько возни ради простой конструкции вроде префаба лифта с защитой от дурака. А с поездами ещё замороченней, особенно если их несколько на линии.

Добавлено 08-09-2019 в 16:12:

Цитата:
Дядя Миша писал:
Progs.dll ... GameUI.dll ... Draw

В CamelCase ?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 08-09-2019 в 13:15:

Да надо просто как в том же Doom3 сделать глобальные скрипты, локальные скрипты, ну что-то вроде этого. Ну то потом всё, это архитектуру не затрагивает никоим образом, скорее приятное дополнение.

Цитата:
thambs писал:
В CamelCase?

А! Безотносительно!

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 09-09-2019 в 16:41:

Ну штож, новый механизм уже вполне себе вырисовывается. Для простоты и удобства я сделал его частью механизма сейв-рестора. Точнее говоря от сейв-рестора там только табличка глобальных деклараций, ну которая DECLARE_DATA_DESC(); Но дело в том, что эта табличка сама-по себе не обязывает хранить в ней непременно данные для сериализации. Это просто такая универсальная табличка, где можно хранить всё что угодно, а различать по выставленным флагам.

Сейчас, для примера, чтобы передать на клиент оригин и углы, не надо больше ничего копировать в AddToFullPack, не надо сортировать строчки в delta.lst и не надо писать ответный код на клиенте (для entity_state_t разумеется, а для кастомной дельты, как в Сорсе - надо). Достаточно просто добавить в DATADESC вот такие штуки:

DEFINE_DELTA( m_vecAbsOrigin, FIELD_POSITION_VECTOR ),
DEFINE_DELTA( m_vecAbsAngles, FIELD_ANGLES ),

и всё. Не надо по особому помечать переменные, создавать новые таблицы, подключать какие-то каллбэки для прокси и прочую чертовщинку. Я полагаю это самый оптимальный вариант. Разумеется это автоматически учитывает наследие классов и посылает для каждого класса всё объявленное, ну собсно, как и с сейвами.

Добавлено 09-09-2019 в 19:41:

Больше скажу. Этот механизм позволяет даже передавать указатели на функции по сети.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 09-09-2019 в 16:43:

Цитата:
Дядя Миша писал:
Этот механизм позволяет даже передавать указатели на функции по сети.

Ну што ж, несмотря на утрату delta.lst и возможности сортировать в ней строчки, нашему Мастеру будет чем заняться!

__________________

xaerox on Vivino


Отправлено Дядя Миша 09-09-2019 в 17:00:

Вот вам для примера как тот же оригин посылается в сорсе:

Сперва он объявляется хитрым образом:

C++ Source Code:
CNetworkVector( m_vecOrigin );

Причём для разных типов данных - свои названия. Для углов к примеру CNetworkQAngle, есть еще какие-то CNetworkVectorForDerived, CNetworkVar, CNetworkHandle (для EHANDLE). Затем нам надо создать новую таблицу, специально для передаваемых переменных.
C++ Source Code:
1
// This table encodes the CBaseEntity data.
2
IMPLEMENT_SERVERCLASS_ST_NOBASE( CBaseEntity, DT_BaseEntity )
3
SendPropDataTable( "AnimTimeMustBeFirst", 0, &REFERENCE_SEND_TABLE(DT_AnimTimeMustBeFirst), SendProxy_ClientSideAnimation ),
4
SendPropInt			(SENDINFO(m_flSimulationTime),	SIMULATION_TIME_WINDOW_BITS, SPROP_UNSIGNED|SPROP_CHANGES_OFTEN|SPROP_ENCODED_AGAINST_TICKCOUNT, SendProxy_SimulationTime),
5
 
6
SendPropVector	(SENDINFO(m_vecOrigin), -1,  SPROP_NOSCALE|SPROP_CHANGES_OFTEN, 0.0f, HIGH_DEFAULT, SendProxy_Origin ),

Вот это вот DT_BaseEntity тоже надо объявить, чёб движок мог его к себе утянуть и проанализировать. Дальше тут как видите еще и куча флажков-подсказок, типа меняется часто, не скейлить. Как будет всего этого мало, есть еще каллбэк SendProxy_Origin. Ну впрочем можно и без него.
Дальше интереснее. На клиенте m_vecOrigin объявлен как самый обычный Vector. А рядом -
C++ Source Code:
CInterpolatedVar< Vector >		m_iv_vecOrigin;

Но не всё так просто. Вот на клиенте ответная табличка:
C++ Source Code:
1
BEGIN_RECV_TABLE_NOBASE(C_BaseEntity, DT_BaseEntity)
2
RecvPropDataTable( "AnimTimeMustBeFirst", 0, 0, &REFERENCE_RECV_TABLE(DT_AnimTimeMustBeFirst) ),
3
RecvPropInt( RECVINFO(m_flSimulationTime), 0, RecvProxy_SimulationTime ),
4
 
5
RecvPropVector( RECVINFO_NAME( m_vecNetworkOrigin, m_vecOrigin ) ),

Дальше нам надо в конструкторе связать интерполятор с переменной:
C++ Source Code:
AddVar( &m_vecOrigin, &m_iv_vecOrigin, LATCH_SIMULATION_VAR );

То есть еще и интерполяцией надо вручную заниматься. Это всё хорошо, пока большинство переменных уже заранее прописано и голова вроде не болит. Вообщем на порядок сложнее чем в голдсорсе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 09-09-2019 в 19:09:

Зачем кому-то в сети указатель на функцию в чужой памяти?


Отправлено Дядя Миша 09-09-2019 в 19:51:

Для предихтинга жеж. Хотя хз. Может и не понадобится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 09-09-2019 в 22:14:

Дядя Миша

Цитата:
указатель на функцию в чужой памяти

Это вообще законно? Вплане, не потенциальное UB?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено nemyax 10-09-2019 в 05:00:

thambs
Разыменуешь — бида. Но сравнивать-то с адресами из той же памяти можно без последствий.


Отправлено Дядя Миша 10-09-2019 в 06:03:

А кто сказал, что я буду посылать по сети именно указатель? Это вы сами придумали. Указатель сперва превращается в уникальное имя Class::Function, потом это имя добавляется в общий пул строк, который автоматически синхронизируется по сети, потом я посылаю идентификатор этой строки два байта, принимаю на клиенте, превращаю обратно в строку и по строке ищу указатель на функцию.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 10-09-2019 в 06:05:

Цитата:
Дядя Миша писал:
А кто сказал, что я буду посылать по сети именно указатель?

Потому что это очень свежая и оригинальная идея. До такого никто в мире не додумался, а ты бы реализовал!

__________________

xaerox on Vivino


Отправлено SNMetamorph 10-09-2019 в 08:20:

Цитата:
Дядя Миша писал:
Больше скажу. Этот механизм позволяет даже передавать указатели на функции по сети.


Отправлено Дядя Миша 10-09-2019 в 08:44:

Сейв-рестор вынесу целиком в игровую часть, движку он не нужен.
Собсно, смысл в том, чтобы движок не знал ни о каких эдиктах, это вообще не его дело. Не тот уровень абстракции.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 10-09-2019 в 08:47:

Цитата:
Дядя Миша писал:
движку он не нужен.

Клиентская часть? Всякие хардкодед-мессаги для восстановления всяких разных скринфейдов?

__________________

xaerox on Vivino


Отправлено nemyax 10-09-2019 в 08:57:

Дядя Миша
Ну прям микродвижок, навроде микроядра ОС.


Отправлено FiEctro 10-09-2019 в 08:59:

nemyax
При том не кроссплатформенный

Я так понимаю, Дядя Миша из Ксаша решил сделать первый квейк.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено nemyax 10-09-2019 в 09:02:

FiEctro
Первый квейк кокрастоке клиент-серверный монолитный.


Отправлено XaeroX 10-09-2019 в 09:58:

Цитата:
FiEctro писал:
Я так понимаю, Дядя Миша из Ксаша решил сделать первый квейк.

Скорее, Юнити. Движок будет уметь самое основное, а все утехи навроде сейврестора и дельта-компрессии будут вынесены в дллки, которые, возможно, будут продаваться в xash-store за тридцать рублей.

__________________

xaerox on Vivino


Отправлено FiEctro 10-09-2019 в 10:27:

XaeroX
Тогда это неплохо.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 10-09-2019 в 11:15:

Цитата:
XaeroX писал:
Клиентская часть? Всякие хардкодед-мессаги для восстановления всяких разных скринфейдов?

Насчёт клиента я пока не думал. Да в сущности какая разница. После чтения из .sav файла оно всё равно так же по сети общим порядком идёт на клиент.

Цитата:
nemyax писал:
Ну прям микродвижок

Сущности к движку никакого отношения не имеют на самом-то деле. Сущности это конкретика, а ядро оно про абстракцию.

Цитата:
FiEctro писал:
Дядя Миша из Ксаша решил сделать первый квейк.

ну разве что по названию пользовательской дллки. Я долго думал как её лучше назвать, ничего не придумал и плюнул.

Добавлено 10-09-2019 в 14:15:

Цитата:
XaeroX писал:
Движок будет уметь самое основное

Я бы сказал базовое:
Консоль, сетевая подсистема, звуковая подсистема, менеджер ресурсов, докачка ресурсов, рендеринг моделей с заданными параметрами, менеджер декалей, система материалов, механизм смены уровней, менеджер текстур и лайтмап, файловая подсистема, поддержка модов, сетевая таблица строк.

Ну вообщем всё, что и положено иметь в ядре. Ну и да, разумеется ядро оперирует клиентскими сущностями в плане установления сетевой коммуникации. Но и только.
Примерно так я всё это вижу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 10-09-2019 в 11:24:

Цитата:
Дядя Миша писал:
Я долго думал как её лучше назвать, ничего не придумал и плюнул.

Tier1.dll же ради сам знаешь чего


Отправлено XaeroX 10-09-2019 в 11:29:

Цитата:
Дядя Миша писал:
механизм смены уровней

Это тот же самый сейврестор с парой дополнительных фишек, разве нет?

__________________

xaerox on Vivino


Отправлено Ku2zoff 10-09-2019 в 13:57:

Цитата:
Дядя Миша писал:
После чтения из .sav файла оно всё равно так же по сети общим порядком идёт на клиент.

Главное, чтобы был полноценный "клиентский" сейв. То есть все звуки, партикли, декали и всякое всякое чтоб сохранялось и восстанавливалось. Мне, например, очень понравилась демонстрация сейв/рестора темпэнтить для обычной халфы, хотя в ней, как таковой нет смыла. На то они и темп энтити. А вот что из этого в итоге получилось у меня: сохраняемые треки с позицией воспроизведения во фмоде, сохраняемые спрайтовые декали из инвазиона... Да, какая это была в своё время боль, что они исчезали после загрузки. Осталось это всё использовать в моём проекте, который я никак не могу закончить.


Отправлено Дядя Миша 10-09-2019 в 14:32:

Цитата:
nemyax писал:
Tier1.dll же ради сам знаешь чего

эту хрень логичнее вынести в паблик и собирать вместе с каждой библиотекой. Попытка выстроить из них какие-то уровни только портит архитектуру. Я уже когда-то так делал, ничерта хорошего не вышло. Больше не хочу. Вот например есть у меня виртальная файловая система. Раньше бы я её действительно зопехал в какой-нибудь tier1.dll. А сейчас я её оформил как АТД одним хидером и воще не парюсь. Так намного удобнее. Если что-то близкое к CRT не тянет за собой специфичных движковых функций, то и нет никакого смысла оформлять это как очередной интерфейс.

Цитата:
XaeroX писал:
Это тот же самый сейврестор с парой дополнительных фишек, разве нет?

Нет, механизм смены уровней ортогонален сейв-рестору. Я имею в виду механизм очереди команд, когда мы ставим задачу загрузить уровень или загрузить сейв, она добавляется в очередь, потом сама вызывает завершение текущей сессии, со следующего кадра, пропускает его и еще на следующем собсно идёт загрузка нового уровня или там сейва. Потому что вызывать такие вещи из Cbuf_Execute стрёмно.

Цитата:
Ku2zoff писал:
Главное, чтобы был полноценный "клиентский" сейв.

Ну в ксаше и так декали-звуки сохранялись. А темп-энтитей не будет, я ж объяснял уже. Они не нужны просто. В халфе темп-энтити были такая калечная замена нормальным партиклям. А там где они представляли собой что-то более существенное, тем более нет смысла делать их клиентскими. Ну например те же обломки от ящика. Ну впрочем я этот механизм еще не до конца продумал, там несколько вариантов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Chyvachok 10-09-2019 в 14:44:

Кстати интересно как с лимитами будет здесь? А то а халве если честно с ними совсем туго, и на количество оружия и на кол во моделей и вылезти за них очень легко чтобы половина энтитей стала не видимой или игра вообще вылетела. В других движках оно не так жестко, взять хотя бы тот же Unreal Engine к примеру помню проходил сингл моды на анрил торнамент вроде Operation Na Pali и других там в настройках можно отключить к примеру исчезновение кусков мяса, вон в брутал думе тоже не только кровищя но и магазины с гильзами остаются, и ничего, работает и не лагает даже на старом железе, а в халве чуть что и можно вылет словить.

Да и на кол во моделей и спрайтов лимит тоже не удобно, если всего много добавлено как к примеру взять ХЛВЕ то приходится кучу моделей соединять в одну с кучей бодигруп, со спрайтами тоже самое.


Отправлено Дядя Миша 10-09-2019 в 15:14:

Ну вот всё это как раз и делается для того (в том числе), чтобы наращивать лимиты из игровой дллки, не затрагивая ядро.

Добавлено 10-09-2019 в 18:14:

Если вам хочется порассуждать за тиеричность, то самый нижний уровень - это собсно ядро, бакэнд всякий, туда пользователю соваться вообще нет смысла. Средний уровень - это игровая дллка с энтитями, логикой, монстрами. И верхний уровень - скрипты.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 10-09-2019 в 15:31:

Дядя Миша
А партиклы вообще-то не мешало бы. Довольно некрасиво выглядит ситуация когда сохранился, например, под дышалкой с паром. Загрузился, а пар снуля начинает идти, будто только включили его.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 10-09-2019 в 17:34:

ну их для этого сохранять необязательно. Время промотать вперёд, чёб они вышли на готовность и всё. Я уже когда-то такое делал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 11-09-2019 в 09:33:

Дядя Миша
Вершинную анимацию поддержишь на модельках?


Отправлено thambs 11-09-2019 в 13:46:

Дядя Миша
А так что бы сетевая игра могла работать через пару десятков НАТов без выделенного сервера с белым ip, оно возможно?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Ku2zoff 11-09-2019 в 13:51:

thambs видимо да, т.к. ребяты из FWGS замутили возможность запускать сервер на ведроиде через ви-фи. Не знаю, работает ли оно через сотовую связь, т.к. там по-умолчанию все исходящие порты закрыты самим ОпСоСом.


Отправлено Дядя Миша 11-09-2019 в 17:32:

Завершил перенос сейв-рестора в игровую дллку. Движок, соответственно, вызывает только сами методы LoadGame, SaveGame и ChangeLevel, с передачей имён уровня или .sav файла. В этом действии, как вы понимаете заключён глубокий смысл. Можно будет сделать несколько вариантов progs.dll в зависимости от лицензии и цены на покупку. То есть совсем без сейва и без чейнджлевела - это одна цена, с сейвом и чейнджлевелом, по типу кушного - другая цена и со сглаженным чейнджлевелом - максимальная.
Так же можно будет приложить исходник пустой игровой библиотеки, ну сделать там класс камеры и пару энтить. В дефолте. Или скажем физика будет различаться в разных ценовых категориях. Так что тут большое поле для возможностей.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 12-09-2019 в 03:30:

Цитата:
Дядя Миша писал:
со сглаженным чейнджлевелом - максимальная.

Да нет в нём давно неко кова смысла. Уровни сейчас делают настолько большими, что ченжлевел теперь актуален только между миссиями/юнитами. А там можно и на загрузочную картинку полюбоваться.

__________________

xaerox on Vivino


Отправлено Дядя Миша 12-09-2019 в 08:25:

Цитата:
XaeroX писал:
Уровни сейчас делают настолько большими

Я имею в виду не столько загрузочную картинку, сколько сохранение состояния между уровнями. Ушёл-вернулся, всё на месте. А это и для сталкера актуально.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 12-09-2019 в 08:37:

XaeroX

Цитата:
на загрузочную картинку

А как-же иллюзия бесшовности? Локации-то да большие, но если их соединяет обычный колидор или тоннель, то стоит-ли показывать картинку?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено XaeroX 12-09-2019 в 08:52:

Цитата:
thambs писал:
Локации-то да большие, но если их соединяет обычный колидор или тоннель

Я имел в виду, что всё это зачастую можно сделать на одной карте. А вот если телепортация в другой сектор базы - тогда картинка вполне ок. Ну вот в PW мы так решили делать.

__________________

xaerox on Vivino


Отправлено nemyax 12-09-2019 в 09:08:

Цитата:
thambs писал:
если их соединяет обычный колидор или тоннель, то стоит-ли показывать картинку?

Можно показать анимашку преодоления препятствия, как в бетманах.


Отправлено FiEctro 12-09-2019 в 09:26:

Цитата:
Дядя Миша писал:
Можно будет сделать несколько вариантов progs.dll в зависимости от лицензии и цены на покупку. То есть совсем без сейва и без чейнджлевела - это одна цена, с сейвом и чейнджлевелом, по типу кушного - другая цена и со сглаженным чейнджлевелом - максимальная.


А отсортированный delta.lst будет дороже неотсортированного?

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено XaeroX 12-09-2019 в 10:30:

Цитата:
FiEctro писал:
А отсортированный delta.lst будет дороже неотсортированного?

Наоборот, неотсортированный будет дороже. Ведь его ещё только предстоит отсортировать и получить массу удовольствия от процесса!

__________________

xaerox on Vivino


Отправлено Дядя Миша 12-09-2019 в 10:41:

Цитата:
thambs писал:
А как-же иллюзия бесшовности?

да эта картинка на выбор девелопера, можно показывать, можно нет.

Цитата:
FiEctro писал:
А отсортированный delta.lst будет дороже неотсортированного?

не будет у меня дельты.лст.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 12-09-2019 в 10:55:

Дядя Миша
Ну так DEFINE_DELTA в коде всё равно сортировать можно! Или там от порядка зависеть не будет?

__________________

xaerox on Vivino


Отправлено Дядя Миша 12-09-2019 в 13:23:

Цитата:
XaeroX писал:
Или там от порядка зависеть не будет?

ну изначально да, порядок конечно влияет. А как будет дальше я не знаю, мож дельта-калькулятор сделаю, который сам их отсортирует от ближних к дальним.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 12-09-2019 в 14:00:

Цитата:
Дядя Миша писал:
не будет у меня дельты.лст.


А за донат ?

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 12-09-2019 в 15:40:

FiEctro ну положишь в папку с игрой, ктож тебе запретит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Ku2zoff 13-09-2019 в 13:27:

Цитата:
XaeroX писал:
всё это зачастую можно сделать на одной карте

Я вот сейчас играю в Гопнику 2, потому что ничего толком на старой видюхе не работает. И думаю, а возможно ли на ксаше воссоздать одну из локаций этой игры? Уровень детализации примерно одинаковый с халфой, Готику в своё время ругали за устаревшую графику.


Отправлено Дядя Миша 13-09-2019 в 15:13:

Апробовал новый алгоритм дельта-компрессии. Ну что, хорошая штука, удобная. Если ничего не менялось, то ничего и не обновляется. Лимита Max Visibile Entities тут тоже не будет, принудительное обновление каждые 64 секвенции не требуются. Из чего отпадает надобность в клиентских энтитях. Если такая энтить не модифицируется, то и на размер пакета она никак не влияет. А вот с темп-энтитями сложнее. Эти вещи как правило используются для раскидывания мелкого короткоживущего мусора, который нет смысла сохранять в сейв. Если мусор живёт долго, под него логичнее выделить нормальный эдикт. А хрень типа гильз от патронов не попадает ни туда ни сюда. Потому что с одной стороны это не партикля, а с другой эдикты под такое отдавать жалко. Но эту задачку можно разрешить, если научить систему партиклов рендерить не только спрайты, но и модельки.
Думаю это самый оптимальный вариант.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено KiQ 13-09-2019 в 15:29:

Дядя Миша так вроде логично, что эмиттеру должно быть пофиг, что раскидывать - или один полигон спрайта или несколько для модельки

__________________
-Brain is dead-


Отправлено Дядя Миша 13-09-2019 в 15:46:

Да вот не скажи. В том же сталкере гильзы спрайтовые сделали. Кто-то решил не заморачиваться.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 13-09-2019 в 16:50:

Да любая развитая RenderSystem система частиц умеет в модельки.


Отправлено thambs 16-09-2019 в 16:52:

Дядя Миша
Ну если гильзы будут пропадать между сэйвами и ченджлевелами это не очень красиво. В хл, те же пропадающие гибсы смотрятся мерзко.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Chyvachok 16-09-2019 в 19:14:

Кстати интересно, "размер камеры" будет зашит в движке, или в игровой длл-ке? Этот z_linear или как его там, а то в халве он маловат если честно, как пример если модель оружия от 1 лица соответствует размерам мира то она может в экран иногда залазить, особенно если позиция оружия находится близко к экрану.


Отправлено Дядя Миша 16-09-2019 в 19:32:

Z_NEAR ты наверное имел в виду.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено KiQ 16-09-2019 в 19:35:

Цитата:
Chyvachok писал:
если модель оружия от 1 лица соответствует размерам мира то она может в экран иногда залазить

Это настраивается weapon_fov

__________________
-Brain is dead-


Отправлено Дядя Миша 18-09-2019 в 19:27:

Вот и дошла очередь до Pmove. Теперь его можно вернуть в класс игрока.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 18-09-2019 в 19:36:

А что такое пмове?


Отправлено Дядя Миша 19-09-2019 в 06:05:

Player Movement

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 19-09-2019 в 08:46:

Раньше игрока двигали только обстоятельства, а теперь он сам вызывает своё движение?


Отправлено thambs 19-09-2019 в 12:22:

Дядя Миша
А там тоже будут фиксированные хуллы, или как-то ещё решил сделать?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 19-09-2019 в 15:22:

thambs ну пока что формат остается близким к HLBSP из практических соображений - когда я закончу формирование игровой либы, я наверное пройду под ней разные там халф-лайфы, моды рейда, надо убедиться что ничего не испортилось. А так формат карт будет новый, что-то такое симбиотическое из сталкера\метро\ку3\хл. Еще не определился.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 21-09-2019 в 06:28:

Перенёс движение игрока и лагкомпенсатор в дллку. API должно быть как можно тоньше и использовать по возможности только атомарные типы.
Это гарантия от того, что в будущем его придётся расширять.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 21-09-2019 в 06:32:

Дядя Миша
А что мешает перенести движок целиком в дллку, как в халфе, открыть его сорцы и загружать из папки dlls мода? Это, имхо, решает абсолютно все вопросы с апи.

__________________

xaerox on Vivino


Отправлено Дядя Миша 21-09-2019 в 09:17:

Цитата:
XaeroX писал:
А что мешает перенести движок целиком в дллку

Так это обсалютно два разных уровня абстракции, я же писал выше.
Энтити и то как они перемещаются по миру движок абсолютно не касается.
Задача движка - отрисовать все модельки из точки зрения камеры.
Вот загрузить эти модельки и расставить по местам - это уже задача игрового кода. Ну и сетью тоже движок ведает, пакеты посылает, принимает, следит за надёжностью доставки, сжимает их.
Что тут непонятного?

ЗЫ. наконец-то доделал старую фишку - рекурсивный поиск граунд-энтитей для пушабли. Теперь если двигается нижняя пушабля (ну там на поезде или игроком), то весь стак передвигается вместе с ней. Ну разумеется будут и нормальные физические тела. Я просто обратил внимание что в некоторых случаях народ предпочитает использовать именно тупую физику, чтобы уменьшить кол-во непредсказуемых действий игрока.

Добавлено 21-09-2019 в 12:17:

ЗЗЫ. Идея в том, что мы не можем заранее предугадать организацию объектов, т.к. они целиком и полностью зависят от игры. А если у нас к примеру тетрис? Движок ведает такой абстракцией как подключённый клиент, но для движка это просто уникальный ID, к которому привязан. ну допустим стим-профиль. А что он там делает в игре - это всё на совести игрового кода. Есть вещи которые для всех игр одинаковы - это модели, звуки, вообщем ресурсы. И естественно это нижний слой абстракции.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено KiQ 21-09-2019 в 12:07:

Цитата:
Дядя Миша писал:
Задача движка - отрисовать все модельки из точки зрения камеры.

Разве это не задача рендера о_О и для этого же в XT был заведен кастомный рендер-интерфейс. Теперь его не будеть чтоль?

Про pmove хоррошая новость, помню как я задолбался скакать из файла в файл, когда делал кушную физику для игрока

__________________
-Brain is dead-


Отправлено XaeroX 21-09-2019 в 12:32:

Цитата:
Дядя Миша писал:
Задача движка - отрисовать все модельки из точки зрения камеры.

А если я хочу сам решать, как мне рисовать модельки и из какой точки зрения? Тут выйдет облом?

__________________

xaerox on Vivino


Отправлено Дядя Миша 21-09-2019 в 13:51:

Цитата:
KiQ писал:
Разве это не задача рендера о_О

Ну так рендер ведь тоже в движке.

Цитата:
KiQ писал:
для этого же в XT был заведен кастомный рендер-интерфейс. Теперь его не будеть чтоль?

Он там был заведён исходя из того что оригинальная графика немножко устарела. Да и то, можно подумать хоть кто-то им воспользовался кроме меня. Нет, не будет конечно.

Цитата:
XaeroX писал:
А если я хочу сам решать, как мне рисовать модельки и из какой точки зрения?

ну так точка зрения и задается в игровой библиотеке, равно как и положение моделей в пространстве. А если речь про кастомный рендеринг, то это всё равно никто и никогда не использует. Если уж делать подобные вещи - это нужна система плагинов и каждый плагин под каждый формат моделей, соответственно. Ну как в Джеке

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено KiQ 21-09-2019 в 14:27:

Дядя Миша как никто не воспользовался? Был же custom build от товарища) Тут дело такое, есть например базовые вещи, скажем нормал-мэппинг, тени, отражения там. А есть специфические вещи, например я для мультиплеерного билда, который мы с купахтомасом гоняли, кодил на клиенте эффект реальной линзы для вьюмоделек с прицелом (ну там арбалет, револьвер). У меня это было привязано к имени текстуры в модельке (модельки я перекомпилировал, соответсвенно). И вот в отрисовке вьюмодельки я проверял на наличие этой текстуры и рендерил в нее фреймбуфер мира, понимаешь, да) Может и не самый правильный подход, но без кастомного рендера такого в принципе не сделаешь. Если, например, такое будет можно тонко провернуть с помощью шейдеров и скриптов - то будет замечательно или тот же моушен-блюр, хотя я знаю, ты его не любишь)

Добавлено 21-09-2019 в 17:27:

То, что в новом XT шейдеры были переведены на glsl это огромный шаг, кстати, я их понемногу ковырял, пока в жизни не начались проблемы и времени на это перестало быть)

__________________
-Brain is dead-


Отправлено Дядя Миша 21-09-2019 в 17:41:

Ну такие вещи быстрее всего будут доступны через систему материалов.
Рендеринг вообще дело мало кому нужное. Это в первую очередь загрузка треугольников и вертексов в VBO. Вам это всё точно не нужно. Вам надо чёб можно было кастомные шейдеры и свои параметры в них.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 21-09-2019 в 17:43:

Цитата:
Дядя Миша писал:
Вам надо чёб можно было кастомные шейдеры и свои параметры в них.

Ещё OIT важная штука.

__________________

xaerox on Vivino


Отправлено Дядя Миша 21-09-2019 в 18:01:

OIT в продакшене не юзают - тормозно

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 21-09-2019 в 18:37:

Дядя Миша
Ну хотя бы сортировка, с возможностью гибкой настройки.

__________________

xaerox on Vivino


Отправлено nemyax 21-09-2019 в 19:33:

Дядя Миша
Уровни-то как надо будет делать? Моделить?


Отправлено Дядя Миша 21-09-2019 в 19:59:

ну конечно надо, чтож за игра без уровней

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 21-09-2019 в 20:00:

Ну так моделить или кубать?


Отправлено KiQ 22-09-2019 в 06:25:

Я за то, чтобы кубать)) ну по крайней мере основную геометрию. Вот честно, нигде не видел более удобной работы с текстурированием, именно в плане маппинга, чем в VHE/Джеке. Ну знаете это, когда референсный плэйн выделяешь и потом правой кнопкой мацаешь, и текстура с такими же параметрами вставляется, скейл там, UV и прочее. Там какой-то шаманизм с текстурной матрицей видимо, я так до конца и не разобрался, но удобно прям вообще)

__________________
-Brain is dead-


Отправлено Дядя Миша 22-09-2019 в 06:47:

nemyax на усмотрение разработчика

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 22-09-2019 в 08:07:

Цитата:
KiQ писал:
Вот честно, нигде не видел более удобной работы с текстурированием, именно в плане маппинга, чем в VHE/Джеке.

Ты пробовал текстурировать скалы?

__________________

xaerox on Vivino


Отправлено KiQ 22-09-2019 в 09:38:

XaeroX сложный ландшафт логично делать моделью) я говорил про основную геометрию. Да и в любом случае, лоу-поли скалы удобнее текстурить в джеке, чем долбаться с разверткой в том же блендере. Просто для того, чтобы по-быстрому накидать уровень любой 3d-моделлер слишком избыточен

__________________
-Brain is dead-


Отправлено Дядя Миша 22-09-2019 в 13:55:

Ну чтоже. Вот мы вплотную и подобрались к самой главной, так сказать фундаментальной проблеме всего движка. К формату его уровней. Это краеугольный камень всего. От этого зависит как на уровне взаимодействуют монстры, как отсекается видимость, насколько надёжна физика и насколько быстро всё это рендерится. Ни один из существующих форматов, близких по духу к кушным движкам не отвечает поставленным требованиям. Возможно кто-то просто не задавался таким вопросом или наоборот считает, что там всё в порядке. Я на это отвечу следующим образом: если сознательно ограничить свою фантазию колидорами из кваки - то конечно жы проблем нет.

Перечислю здесь основные проблемы, применительно к форматам уровней Quake1 и Quake3 (я их выбрал как базовые, которые знаменовали смену поколений). Но сперва обозначу общие проблемы, которые нас подстерегают в 2019-м году, если мы решили строить наши уровни вокруг BSP-дерева:

1. Очевидно, что BSP-деревом можно описать любую солидную структуру. Для ускорения поиска и пересечения. Но есть проблема. Чем больше полигонов в структуре - тем больше дерево. В какой-то момент возникает ситуация, когда нережущие алгоритмы управляются на порядок лучше режущих. К тому же BSP существует в варианте, который ничего не разрезает и там оно не сказать что блещет производительностью. К тому же само его построение с уникальными полигонами на ноде может занять чертовски много времени. Ну с этим можно бороться сделав какие-то изначальные допущения. Сам алгоритм особо не покрутишь.

2. Из преведущего пункта очевидно вытекает, что наилучшим образом с BSP дружат браши - замкнутные конвексные структуры, которые по своей сути обладают одним интересным свойством - их легко редактировать, легко текстурировать и они хорошо держат точность, чтобы на базе такой геометрии можно было строить абсолютно замкнутые уровни и генерировать порталы видимости в автоматическом режиме, а не заниматься расстановкой функ_окклюдеров. Но есть у брашей и серъезные минусы. В силу специфики их текстурирования, из брашей практически нереально построить tri-strip объекты для ускорения отрисовки. Невозможно склеить вертексы, когда на каждой стороне браша какая-то своя отдельная текстура. В моделях такое практически не встречается, хотя разумеется и возможно. Ну просто там изначально другой подход к текстурированию. Из чего вытекает следующее правило - много брашевой детализированной геометрии будет тормозить независимо от того как мы её оптимизируем. Невозможность использования стрипов снижает конечную производительность от 1/3 до 1/2 от возможной скорости. Из чего сам собой напрашивается вывод - использовать брашевую геометрию только для грубых набросков, не увлекаться.

3. BSP обладает приятной возможностью создать офлайн-массив видимости, т.е. заранее знать из какого сектора уровня какой будет виден. Не в последнюю очередь благодаря автоматической генерации порталов. Собственно это вообще единственный способ иметь такую видимость. Все остальные способы базируются на уже отрендеренных полигонах и на PC имеют лаг, связанный с получением данных непосредственно из видеокарты (на приставках ЧСХ лага нет, там другая архитектура). Это обходится либо созданием упрощённого софт-рендера, который работает в отдельном потоке, либо забиванием на оптимизацию, как в юнитях разных. Но всё это имеет смысл только коридорной геометрии. На открытых пространствах толку никакого, как вы понимаете.
Очевидно что полагаться на один PVS нельзя, требуются дополнительные способы.

4. Возможность трассировки полигонов без построения каких-то дополнительных ускоряющих структур. Очень сильно завязано на детализацию, как вы понимаете. Плюс сам факт разрезания полигонов не полезен для рендеринга. Но можно решить построением нескольких деревьев и разных наборов видимых сурфейсов, хотя это и приводит к увеличению размера карты. Можно построить чисто аксиальное дерево, однако в плане увеличения производительности от него немного толку.

5. Надо так же отметить, что вышеописанные проблемы при отказе от BSP, вообщем-то никуда не деваются, а некоторые становятся вообще принципиально неразрешимы, типа рассчёта PVS. Отказ от брашей нецелесообразен, поскольку дизайнеру часто требуется создавать какие-то зоны, водные пространства, триггеры, навмешы. Брашы для этих целей подходят идеально. Как там народ делает триггеры в движках без брашей остается только догадываться.

Добавлено 22-09-2019 в 16:55:

Теперь по списку проблем в уже известных форматах.
Применительно к Quake1:

1. Слишком подробное дерево. Это хорошо для реализации сверхбыстрой точечной трассы, но плохо для визуализации, если мы собираемся использовать дерево. Впрочем для рендеринга можно использовать другие собирательные структуры, ну скажем нечто вроде суперлифов, которые включают в себя основные лифы с видимостью и детальные лифы с такой же видимостью.
2. Фиксированные хуллы. На основе информации, имеющейся в карте возможно построить коллизию для произвольных фигур, но есть одна проблемка - туда не попадут клипбрашы. Восстановление клипбрашей из соответствующих деревьев тоже не будет точным, поскольку для разных хуллов деформированная геометрия уже выглядит не так как для точечного (ну вы это могли видеть, включив визуализацию хуллов).
3. Raw-лайтмапы. Ну это легко исправить, немного доработав формат. Минус таких лайтмап в том, что они провоцируют появление швов на сложной геометрии, состоящей из треугольников. Если кубать строго квадратными брашами, то никакой проблемы нет. Но брашевый ландшафт из треугольников провоцирует появление швов на лайтмапах, несмотря на все метды противодействия им.
4. Нету ареапорталов. Ну здесь я даже не знаю, так ли уж они актуальны в наше время. Мне кажется этот подход уже устарел и не нужен. Он только усложняет получение информации видимости в различных частях рендерера, т.к. необходима синхронизация состояний, плюс лишняя нагрузка на сеть.

Применительно к Quake3:
1. Брашы вместо клипнодов. Может показаться странным, но по некоторым причинам код трассировки брашей неоднозначен. Есть там такая проблемка, при которой с одной стороны браша игрок проникает в него на эпсилон, а с другой наоборот - не достает. Решается через параметр overbounce, который отталкивает игрока в PM_FlyMove. Как в ку2, так и в ку3. Я не знаю, может вальва в сорсе и решила эту проблему (там не юзается овербаунс), но в Doom3, Кармак от греха вообще не использует коллизию по брашам, они там только для определения контентсов.

2. Упрощённое дерево. Баланс между избыточностью и скоростью. Для рассчёта PVS и рендеринга дерево оптимально, для трассировки производительностью не блещет, из-за чего возможно лайтмапы считаются достаточно медленно. Впрочем это можно решить, построив в лайтмаппере какую-то кастомную трассу.

3. Типы поверхностей. Нет юниформности, мы должны с каждым видом действовать по своему. С брашами так,с патчами эдак, с фларесами иначе. В качестве эксперимента может это было и неплохо, но вообще это очень неудобно. После компиляции мы не должны знать что это было раньше патч или модель, для нас это должен быть просто полигон. Впрочем допустимы некоторые хинты, которые позволят загружать группы полигонов в VBO единым целым, например, если из них реально построить стрипы (для патчей или моделей). Ну вообщем достаточно неоднозначная вещь.

4. карта не содержит в себе информацию о рёбрах, которая могла бы нам пригодится, ну например для физики, или Ксероксу для создания теневых объемов

Подводя итоги, хочется обратить ваше внимание, что ни тот ни другой из форматов в чистом виде нам не подходит. И модификация в любом случае будет достаточно серъезным делом. Основной вопрос заключается в том, какой из форматов взять за исходную точку для дальнейших доработок.
Собственно оба подходят в равной степени, надо решить нелёгкий вопрос, что будет быстрее в плане имплементации, что займет меньше времени.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 22-09-2019 в 14:16:

Да неко кой!


Отправлено Дядя Миша 22-09-2019 в 14:24:

ncuxonaT ответ неверный. Имплементация любого другого формата займет еще больше времени.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 22-09-2019 в 14:37:

Помню, в серьёзном сэме были огромные пространства и при этом отличная производительность. Или это только за счёт того, что на тех пространствах нихренашеньки кроме монстров не было?


Отправлено Дядя Миша 22-09-2019 в 15:09:

Пространства сами по себе значения не имеют. Имеет значение только поликаунт. Вон в первом дууме ставят на карту сто тысяч монстров и это всего-навсего 200 тысяч треугольников, монстры-то спрайтовые!
Вот и не тормозит. Вспомнил забавную штуку, вот как раз связанную с пространствами. Есть такая единственная игра для Unigine - называется Cradle. При старте мы спавнимся в своей хижине. Хижина жутко интерактивная. Там все предметы настоящие. Это значит что в любом комоде, мало того, что можно выдвинуть любой ящик, так еще и в этих ящиках лежат настоящие итемы, которые можно брать. Ну вообщем внутри хижины поликаунт зашкаливает просто. А я тогда рассуждал в точности как ты - уж если в индоре такие тормоза, то в аутдор вообще соваться без резона. Но я набрался храбрости, выглянул и офигел. Потому что гигантский аутдор (5-7 кв.км) ВООБЩЕ не тормозил, а чему тормозить, если это был пустой ландшафт?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 22-09-2019 в 16:33:

Цитата:
Quake1

Дикие разрезы, выпадающие полигоны и дыры в клипбрашах. Настоящий комшмар мэппинга — уйма времени уходит на то что бы не было видимых щелей и косяков, и невидимых препятствий и дыр. И, естественно, чем геометрия детальней и чем сильнее отличается от аксиальной, тем больше вылезает проблем. Даже p2st хоть и дают результат лучше всего, но всё равно требуют повышенной внимательности к таким деталям.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено XaeroX 22-09-2019 в 17:44:

Цитата:
Дядя Миша писал:
если сознательно ограничить свою фантазию колидорами из кваки - то конечно жы проблем нет.

Ничем не ограниченная фантазия во все времена приводила к эпичным провалам.
Цитата:
Дядя Миша писал:
Чем больше полигонов в структуре - тем больше дерево.

Это не совсем верно. Ку3шное дерево зависит только от структурных полигонов, но не детальных.
Цитата:
Дядя Миша писал:
из брашей практически нереально построить tri-strip объекты для ускорения отрисовки.

Никогда не понимал этой фанатичной сакрализации три-стрипов, по крайней мере со времён первого GeForce, т.е. появления TnL-кэша.
Цитата:
Дядя Миша писал:
На открытых пространствах толку никакого, как вы понимаете.
Очевидно что полагаться на один PVS нельзя, требуются дополнительные способы.

Поиграй в те же TES4, TES4 или Фоллауты. Там мухи отдельно, котлеты отдельно. В смысле, есть ландшафт с чем-то вроде ROAM и лодами, а есть калидоры с PVS, а между ними - загрузки с прогрессбаром. И людей это уже 10 лет как вполне устраивает.
Цитата:
Дядя Миша писал:
Как там народ делает триггеры в движках без брашей остается только догадываться.

Я в 2001 году делал триггеры под первый UE без брашей. Как-нибудь напишу мемуары об этом.
Цитата:
Дядя Миша писал:
Нету ареапорталов. Ну здесь я даже не знаю, так ли уж они актуальны в наше время. Мне кажется этот подход уже устарел и не нужен. Он только усложняет получение информации видимости в различных частях рендерера, т.к. необходима синхронизация состояний, плюс лишняя нагрузка на сеть.

Вот здесь - долго смеялся.
Цитата:
Дядя Миша писал:
карта не содержит в себе информацию о рёбрах, которая могла бы нам пригодится, ну например для физики, или Ксероксу для создания теневых объемов

Пригодиться они могут примерно как ворона эстонцу из анекдота.
А всерьёз писать про теневые объёмы в 2019 году просто неприлично.
Цитата:
nemyax писал:
в серьёзном сэме были огромные пространства и при этом отличная производительность.

Там полигонов было, по ощущениям, меньше чем в первой халфе, на все эти огромные пространства.
Цитата:
Дядя Миша писал:
Вон в первом дууме ставят на карту сто тысяч монстров и это всего-навсего 200 тысяч треугольников, монстры-то спрайтовые!

Там ИИ примитивный, вот и не тормозит. Сделай в халфе 100 тысяч монстров ВООБЩЕ без модельки - и офигеешь от тормозов сервера.

__________________

xaerox on Vivino


Отправлено thambs 22-09-2019 в 18:18:

Цитата:
ИИ примитивный

Ну зато бегают хотя-бы, а не стоят на месте притопывая ножкой.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено XaeroX 22-09-2019 в 18:25:

thambs
Там и pathfinding примитивный, чего бы им не бегать? Это вам не CheckLocalMove с триангуляцией плюс нодеграф.

__________________

xaerox on Vivino


Отправлено Дядя Миша 22-09-2019 в 18:58:

Цитата:
XaeroX писал:
Ку3шное дерево зависит только от структурных полигонов, но не детальных.

это и так подразумевается.

Цитата:
XaeroX писал:
Никогда не понимал этой фанатичной сакрализации три-стрипов

Да вон ЧАЭС без стрипов с лайтмапой - ФПС вдвое упал.

Цитата:
XaeroX писал:
Там ИИ примитивный, вот и не тормозит

Да понятно что ИИ. Но я про полигоны.

Добавлено 22-09-2019 в 21:46:

ИИ там кстати как в квейке. Но в 2Д.

Добавлено 22-09-2019 в 21:58:

Я тут пытаюсь решить задачку с материалами. Кутришные шейдеры очевидно устарели и не конают. К тому же там все типы встроенные.
Можно просто скопипастить материалы из паранои, но встанет вопрос - а как подключать кастомные glsl. И передавать в них параметры.
В параное без вариантов. Но в NT надо сделать подгрузку кастомных GLSL шейдеров. И тогда уже мутить что угодно со спокойной душой.
Была у меня такая любопытная имплементация кажется в 2015-м году. Для NT как раз и делалась.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 23-09-2019 в 07:49:

Расскажу немного о новой концепции материалов. Она не совсем новая, я её придумал еще в 2015-м году, но тогда посчитал излишним к реализации, поскольку разработка NT застопорилась, а для паранои она бы была черезчур сложной. В чём основная идея?
Материалы у нас, как вы знаете основываются в первую очередь на возможностях рендерера. До появления программируемого конвейера вполне логичным было бы просто охватить все возможные комбинации и стадии фиксированного конвейера и задавать рендеринг довольно простым языком, который Кармак реализовал еще в Quake3. Впоследствии, когда появился бамп и Cg, эта система была пересмотрена в сторону упрощения, но всё равно не избавилась от духа FFP. В настоящее время её использование носит негативный характер. Там где требуется создать простой материал она избыточна, а там где материал кастомный что либо реализовать затруднительно. Собственно, этот момент отразился уже в Wolfenstein 2009, там дуумтришную систему материалов полностью перепахали в сторону гибкости и использования шейдеров. В чём заключается моя идея?
Нам не надо пытаться описать в материале принципы рендеринга, это реализуется в GLSL, в стандартных или пользовательских шейдерах.
Всё что нам надо - это настроить переменные и юниформы, однако как вы понимаете, прописывать каждый раз пачку переменных для каждого материала каждой текстуры - сомнительное удовольствие. На помощь приходят шаблоны с предустановленными дефолтными параметрами.
Однако и тут возникает вопрос - надо ли нам каждый раз прописывать пути к каждой текстуре, ведь мы не сможем указать эти пути явным образом в шаблоне? Явным образом нет, но мы можем построить наш путь из переменных значений, таких как <wadname>, <modelname>, <mapname>. Приведу пример шаблона и материала, построенного с его использованием. Это ни в коем случае не окончательный вариант синтаксиса, один из текущих:

C++ Source Code:
1
template<world>
2
{
3
  image u_ColorMap = "textures/<wadname>/<mipname>.tga";
4
  image u_NormalMap = "textures/<wadname>/<mipname>_norm.tga";
5
  image u_GlossMap = "textures/<wadname>/<mipname>_gloss.tga";
6
  image u_DetailMap = "$matdesc/detailMap";
7
  image u_DepthMap = "$screendepth";
8
  image u_DeluxeMap = "$deluxemap";
9
  image u_LightMap = "$lightmap";
10
  image u_GlowMap;
11
  matdef material = "metal";
12
  float u_Smoothness = 0.35f;
13
  float u_ReflectScale;
14
  float u_RefractScale;
15
  float u_AberrationScale;
16
  float u_ReliefScale;
17
  vec2 u_detailScale = "$matdesc/detailScale";
18
}
19
 
20
shader<world>
21
{
22
  vertex = "glsl/<progname>_vp.glsl";
23
  fragment = "glsl/<progname>_fp.glsl";
24
  template = world;
25
}
26
 
27
"ps_metal00"
28
{
29
  template	world;
30
}

Здесь image создаёт юниформ-сэмплер для GLSL и грузит текстуру в случае наличия дефолтного пути, который формируется из переменных, заключённых в треугольные скобки. Текстуры со знаком доллара - это внутренние, которые движок подставляет по смыслу. ну разумеется, каждому полигону достанется именно своя лайтмапа, а не какая-то абстрактная. $screendepth будет содержать копию экрана глубины, полученную перед рендерингом меша, содержащего в себе именно этот материал. vec2 u_detailScale = "$matdesc/detailScale"; возьмёт дефолтные значения из materials.def. Сам materials.def не расширяемый, его параметры определеные заранее, ну вы его видели в параное. Там всякие звуки-партиклы при попадании пули в стенку, звуки шагов, декали, физические свойства материала. Ну и возможность задавать некоторые физичные параметры разом для всего шаблона, ну скажем smoothness или detailScale, хотя можно и просто прописать константу. Впрочем, еще раз скажу - это ни в коем случае не окончательный вариант, это просто для понимания как будет выглядеть система.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 23-09-2019 в 08:31:

Дядя Миша
Допустим чувак захочет реализовать подсветку досягаемого объекта под кросс-хером. Как ему поможет такая система материалов? Ведь для конкретного объекта не выставишь униформ.

Добавлено 23-09-2019 в 11:31:

Хотя по идее в униформ можно толкнуть ID объекта.


Отправлено Дядя Миша 23-09-2019 в 09:16:

nemyax всё зависит от тех переменных, которые мы передаём в шейдер. Я же не сказал, что можно будет прописать только константы.
Будет привязка как к глобальным, так и к локальным переменным.
Но синтаксис я пока еще не продумал.
Опять же, можно наделать много шаблонов на все случаи жизни и использовать их в разных материалах, на ходу перегружая те или иные параметры. В основе системы лежат два простых соображения:
1. чтобы не надо было каждый раз прописывать одно и тоже для кучи материалов или в крайнем случае это был минимальный набор данных.
2. чтобы любой из заданных параметров было возможно перегрузить. В том числе - создать новый параметр, который в шаблоне вообще отсутствует.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 23-09-2019 в 09:56:

Я бы вместо треугольных скобок сделал квадратные, а то и вообще без всяких скобок, просто писать в верхнем регистре: WADNAME, MIPNAME.


Отправлено Дядя Миша 23-09-2019 в 10:01:

ни в коем случае квадратные. Шаблоны вот именно так и обозначают через треугольные.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 23-09-2019 в 10:02:

Crystallize
Угловые скобки — признак того, что перед тобой шаблон. Капсят по традиции, когда определили макрос. А квадратные скобки используются для доступа по индексу.


Отправлено Дядя Миша 23-09-2019 в 10:11:

Я вообще когда пишу очередную скриптовую систему стараюсь всегда придерживаться синтаксиса С\С++, чтобы было интуитивно понятно при первом же изучении. Тех, кто изобретает свой синтаксис ждёт аддельный котёл в аду, например авторов петона.

Добавлено 23-09-2019 в 13:11:

Ну вот что это за дрянь к примеру:

C++ Source Code:
def b2midcp(p0, m, p2):
"cp to get b2 line from p0 to p2 passing thru m"
return 2.0*m-0.5*(p0+p2)

все глаза вытикли

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 23-09-2019 в 10:14:

Цитата:
Дядя Миша писал:
Тех, кто изобретает свой синтаксис ждёт аддельный котёл в аду, например авторов петона.

Главный порок синтаксиса петона — индентация без вариантов, а не то, что он не сишный. Петон в конце концов не преподносится как производный от си, так что тут взятки гладки.


Отправлено Дядя Миша 23-09-2019 в 10:21:

В моём представлении любой скриптовой язык это в первую очередь песочница и безопасная работа с памятью. Зачем там изобретать новый синтаксис мне вообще непонятно. Я могу понять какие-то небольшие отличия, обусловленные возможностями языка. Но всё переиначивать это маразм.

Добавлено 23-09-2019 в 13:21:

Народ живёт стереотипами, ему почему-то кажется, что это его святой долг - выдумать совершенно новый непохожий синтаксис. В связи с этим вспоминается, как Лебедев устроил конкурс на самую лучшую панель кнопок для лифта и куча идиотов прислала ему совершенно дикие варианты. Вот тоже самое абсолютно. Сишный синтаксис в первую очередь ценен своей максимальной наглядностью и удобочитаемостью. Первый признак мудака - это когда начинают заменять фигурные скбоки, то вообще их выкинут как в петоне, то пропишут словами begin\end или на квадратные заменят. Вот зачем спрашивается? А низачем, чтобы люди страдали. Thambs например. Он жы любит страдать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 23-09-2019 в 10:22:

Цитата:
Дядя Миша писал:
Зачем там изобретать новый синтаксис мне вообще непонятно

Потому что набор идей в основе языка другой и сишный синтаксис (который вообще говоря не прописан в уголовном кодексе как обязательный) не подходил. Хорошо ли или плохо реализован этот набор, это другой вопрос =)


Отправлено Дядя Миша 23-09-2019 в 10:26:

Я вам больше скажу - никто и никогда не проводил психовизуальное тестирование восприятия разного синтаксиса человеческим глазом. А если бы провели, то очень быстро убедились, что отличные от С\С++ варианты максимально затрудняют восприятие, особенно в тепичном блокноте без подсветки.

Добавлено 23-09-2019 в 13:25:

Цитата:
nemyax писал:
Потому что набор идей в основе языка другой

Другой набор идей был в старом васике, который исполнял код, прыгая по нему при помощи goto и там еще строки надо было вручную нумеровать, да.
У меня на спектруме такой был.

Добавлено 23-09-2019 в 13:26:

Есть всего два варианта: со стеком или без. Остальное - косметика.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 23-09-2019 в 11:33:

Дядя Миша
Ну смотри.
- Типы расслабленные, значит половина сишного синтаксиса уже отпадает, в том числе способ объявления функций.
- Встроенные составные типы: кортежы, списки, словареги. Нужен синтаксис.
- Присутствуют всякие фишки из функциональщины типа анализаторов списка, лямда-функций и зайчатошного паттерн-матчинга. Раньше, чем Страус начал скотчем приматывать их к плюсам.
И так далее. Так что по-любому от сей мало что осталось бы. Ну если бы занимались именно художественной резьбой по сям.


Отправлено Дядя Миша 23-09-2019 в 11:46:

nemyax объясни мне пожалуйста каким образом наличие кортежей запрещает использовать фигурные скобки.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 23-09-2019 в 12:04:

Никаким. Конкретно это — обычная щепотка маразма. Фигурные скобки действительно не помешали бы. А инициализировать словарики можно было бы и по-другому.

Добавлено 23-09-2019 в 15:04:

Вообще говоря, ну если нужен сиподобный скриптовой язык, вон же Squirrel.


Отправлено Crystallize 23-09-2019 в 12:35:

Цитата:
Дядя Миша писал:
ни в коем случае квадратные. Шаблоны вот именно так и обозначают через треугольные.

Люди которые будут в конечном счёте использовать эту систему, скорее всего не будут программистами и не будут иметь привычки к сишному синтаксису. Мапперам и художникам тоже нужно будет задавать какие-то материалы. Мне просто кажется что для обычного человека идея задавания некоего поля с типом сущности где можно уже перебирать конкретные сущности - эта идее более наглядно выражается квадратными скобками, астерисками по обоим краям, или верхним регистром. Треугольные скобки - они в чём-то на кавычки похожи.
Может ты и прав, впрочем.

Ты тут затронул две крупные темы, это очевидность сишного синтаксиса и про дизайн тоже.

Те "идиоты" которые Лебедеву слали всякие странные эскизы, они поняли дизайн как что-то что должно быть оригинально, интересно, круто, и зрелищно. Я могу их понять, потому что если дизайнить всё как айфон то от скуки выть захочется.


Отправлено nemyax 23-09-2019 в 12:49:

Цитата:
Crystallize писал:
Люди которые будут в конечном счёте использовать эту систему, скорее всего не будут программистами и не будут иметь привычки к сишному синтаксису

Раз уж они полезли в код, то пусть будут готовы встретить смыслы там, где не ожидали, или не такие, как ожидали. Где они были, когда создавался си? А щас уже поздняк метаться.


Отправлено KiQ 23-09-2019 в 13:42:

Crystallize ну лебедев вообще заново пирдумал букву "М" за сто лярмов, чо уж там

Добавлено 23-09-2019 в 16:35:

Цитата:
Дядя Миша писал:
таких как <wadname>

Here we go again

Добавлено 23-09-2019 в 16:35:

Цитата:
KiQ писал:
Где они были, когда создавался си?

В планах)

Добавлено 23-09-2019 в 16:42:

Если брать систему материалов в таком варианте, то логично завести файлик типа mats.def, где и делать все привязки, а сами материалы соответственно прописывать в каждый файл отдельно. Но вообще это имхо уже ненужное нагромождение. Просто сканировать папку materials и загружать все материалы. Тут ведь проблема скорее не в том, как в движке это реализовать, а как на этапе маппинга задать материал геометрии. Ну, скажем, если мы делаем что-то моделькой, то ID материала указывается в блендере/максе или где там кто моделлит. Если мы кубаем - то тут уже сложнее. Идет привязка к имени текстуры, ну это все знают, разные там префиксы и прочее. А вот унифицировать это все пока что по идее никаг

__________________
-Brain is dead-


Отправлено Дядя Миша 23-09-2019 в 13:58:

Цитата:
Crystallize писал:
эта идее более наглядно выражается квадратными скобками

вот как раз наоборот квадратные скобки меньше бросаются в глаза их легко перепутать, вспоминайте чортовы FGD, где постоянно забывали на этот счёт.

Добавлено 23-09-2019 в 16:58:

Вообще очень тяжело писать код, когда в голове еще не выстроилась система. Я когда так пишу у меня код страдает чудовищной избыточностью, потом лишнее удалять приходится.

Цитата:
KiQ писал:
то логично завести файлик типа mats.def, где и делать все привязки,

шаблонов может быть сколько угодно, я их придумал объявлять в хидерах. Ну конечно это необязательно, можно и в mat-файле.
Определённое имя имеет только materials.def, но это совсем другие данные.
То что находится там используется в основном физикой.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено KiQ 23-09-2019 в 14:35:

Цитата:
Дядя Миша писал:
Вообще очень тяжело писать код

Вы хотите поговорить об этом?

А вообще говорю, тут основная проблема с точки зрения потенциального разработчика игры - не в движке, а в инструментарии. Ну то есть, если например вы с Ксероксом наладите диалог, и в джеке появится плагин ориентированнный именно на NT - то это будет прям бум-круто. А если пользоваться тем инструментарием, что пока доступен, то многих это отпугнет в принципе (порог вхождения и все такое), для остальных создаст определенные неудопства в разработке. То есть, ту дело в чем. Как я понял из озвученных задумок, планируется основательно перелопатить движок и либы. Но это закономерно приводит вот к чему, у каждого движка есть определенная сформированная экосистема. Скажем, кто-то до сих делает уровни под дуум, или кубает под халфу и т.д. В случае с NT получается так, что люди, еще вчера кубавшие под халфу, получают по сути движок на две головы выше, но со схожими принципами. И очень важно, чтобы инструментарий соответствовал. Есть уже компиляторы карт, моделей, и другие Xash Tools, но вот в плане маппинга, учитывая общую идею и общее направление мысли, как движок будет развиваиться, тут нужно думать в этом плане. Потому что как бы движок не был хорош, для игроделов все в итоге решает инструментарий, понимаешь да?

__________________
-Brain is dead-


Отправлено nemyax 23-09-2019 в 14:40:

KiQ
Но ЧАЭС-то из модельки сделался уровнем. Значит и для NT, наверное, можно будет так же. А уж для создания моделек инструментария хоть объешься.


Отправлено Дядя Миша 23-09-2019 в 14:43:

Цитата:
KiQ писал:
А вообще говорю, тут основная проблема с точки зрения потенциального разработчика игры - не в движке, а в инструментарии

Ну я надеюсь, что к моменту окончания работ над NT Ксер откроет SDK Джека. А если нет, то будем принимать меры.

Цитата:
nemyax писал:
Но ЧАЭС-то из модельки сделался уровнем

Вообще это неправильно. Сталкер так не делает. Он эту ЧАЭС на куски режет повсякому.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено KiQ 23-09-2019 в 14:45:

nemyax ну я вот моделить не умею от словасовсем. И опять же, ты не уловил видимо. Я говорил про экосистему вокруг движка и инструментарий, который для него специально сделан, понимаешь да. Те ксаш-тулзы и т.д. А вот для маппинга с учетом новой концепции по сути ничего из существующих решений толком не подходит

Добавлено 23-09-2019 в 17:45:

Цитата:
Дядя Миша писал:
Ну я надеюсь, что к моменту окончания работ над NT Ксер откроет SDK Джека. А если нет, то будем принимать меры.

Ну я про это собственно и говорил

__________________
-Brain is dead-


Отправлено Дядя Миша 23-09-2019 в 15:03:

Да ну какая там может быть новая концепция? Статичные модели по прежнему расставляются через точечные энтити, а вокруг уровня - всё тот же скайбокс. Я совершенно нехочу это менять. Если кому-то это не нравится, для них всегда юнити там разные, унреалы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 23-09-2019 в 15:09:

Цитата:
Дядя Миша писал:
Статичные модели по прежнему расставляются через точечные энтити

Но динамически тенят и анимируются на месте, правильно?


Отправлено Crystallize 23-09-2019 в 15:41:

Цитата:
nemyax писал:
Раз уж они полезли в код, то пусть будут готовы встретить смыслы там, где не ожидали, или не такие, как ожидали. Где они были, когда создавался си? А щас уже поздняк метаться.

А это код? Я думал это как VMT в сорсе.


Отправлено Дядя Миша 23-09-2019 в 17:37:

Пока что сделал так:

Тимплейт в хидере template.h:

C++ Source Code:
1
template <worldSolidMaterial>
2
{
3
  image u_ColorMap = "textures/<wadname>/<mipname>.tga";
4
  image u_DetailMap = "materials.def::detailmap";
5
  vec2 u_DetailScale = "materials.def::detailScale";
6
  float u_Smoothness = "0.35";
7
}


Описание материала:
C++ Source Code:
1
#include "scripts\template.h"
2
 
3
"fifties_wall1y" worldSolidMaterial
4
{
5
 
6
}

Синтаксис тимплейтов вопросов не вызывает, т.к. их немного, их писать нетрудно. Но для каждого материала предполагается вот так и писать пару: имя текстуры - имя шаблона. В визуальном редакторе проблем не будет, но меня интерисует насколько это ненапряжно при ручном редактировании. Еще предположим вариант, когда материал полностью наследует свои свойства от шаблона. Тогда вероятно надо предусмотреть короткую запись, ну что-то типа
C++ Source Code:
"fifties_wall1y" worldSolidMaterial;

Что думаете? Как вариант можно усложнить синтаксис и добавить явные слова, ну скажем
C++ Source Code:
"fifties_wall1y" using worldSolidMaterial

но навряд ли в этом есть смысл. Подобные вещи делаются в первую очередь для юзера, а не для парсера. Парсер-то разберётся.

Добавлено 23-09-2019 в 20:35:

Полез ради интереса в Wolfenstein 2009, а там такое
C++ Source Code:
1
textures/decals/floating_trash
2
{
3
  TextureTransform
4
  {
5
    Translate { Global::Time.x * .018 Global::Time.x * 0 }
6
  }
7
  NoShadows
8
  NoOverlays
9
  NoFragment
10
  NoTFix
11
  MaterialType NoImpact
12
  Contents NonSolid
13
  Technique DSAddGBuffer%r_gBufferMode%_AlphaTest_TextureTransform_Depth
14
  Image NormalMap textures\decals\trash_decal_street_local
15
  Image DiffuseMap textures\decals\trash_decal_street_d
16
  Image SpecularMap textures\decals\trash_decal_street_s
17
  Image MaskMap textures\decals\trash_decal_street_d
18
  AlphaTest 0.40
19
  Vector Specular 64 .1 1 0
20
  vertexcolor
21
}
22
textures/decals/pebbles_01
23
{
24
  EditorImage textures/decals/pebbles_01_d
25
  Image DiffuseMap textures/decals/pebbles_01_d
26
  Image NormalMap textures/decals/pebbles_01_local
27
  Image SpecularMap textures/decals/pebbles_01_s
28
  Vector Specular 16 0 1 0
29
  AlphaTest .1
30
  noOverlays
31
  VertexColor
32
  PolygonOffset 1 1
33
  NoTFix
34
  Contents Nonsolid
35
  NoShadows
36
  nofragment
37
  Vector DetailNormalControls 3 3 2 0
38
}

ЧСХ, я ведь тоже сделал похожий механизм для доступа к глобальным переменным - через globals::
У дураков мысли действительно сходятся.

Добавлено 23-09-2019 в 20:37:

Но до шаблонов они не додумались
Это ожидаемо. Программистам же не надо забивать сотни тысяч материалов, а художники итак всё стерпят.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 23-09-2019 в 18:08:

Цитата:
Дядя Миша писал:
Но до шаблонов они не додумались

Те конфиги вполне могут оказаться выводом какого-нибудь генератора.


Отправлено KiQ 23-09-2019 в 20:34:

Цитата:
Дядя Миша писал:
Пока что сделал так:

Впрочем, ничего нового, и это хорошо!)

__________________
-Brain is dead-


Отправлено XaeroX 24-09-2019 в 07:05:

Цитата:
Дядя Миша писал:
worldSolidMaterial

Правильнее - lightmappedGeneric.
Цитата:
Дядя Миша писал:
А если нет, то будем принимать меры.

Конечно, будете. Перейдёте на Volatile, вот и весь сказ.

__________________

xaerox on Vivino


Отправлено Дядя Миша 24-09-2019 в 12:45:

Цитата:
XaeroX писал:
Перейдёте на Volatile, вот и весь сказ.

Хужы. Заставлю тебя пить пиго, пока падстул неупадъож!

Работы продвигаются медленно не в посл. очередь из-за старой архитектуры, которую нельзя просто ломать разом, чёб было легче следить за регрессиями. Ну вот скажем взять материалы. Я написал их парсинг, но подключить я их не могу - для этого надо писать новый рендерер в движке, а рендерер я написать не могу, потому что для этого надо финализировать новый менеджер моделей, а менеджер моделей я не могу финализировать, потому что старый торчит в игровой код и его там активно используют, ну это только полдела, вторая часть используется в самом движке, например пмувом, то есть надо пмув вынести в игровую дллку. Я вроде бы вынес, но его еще надо тестировать на предмет регрессий. Вот казалось бы, какое отношение физика игрока имеет к системе рендер-материалов?
Так и работаем. Хорошо хоть от энтварсов избавился.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 24-09-2019 в 13:51:

Так падажите, материал от шейдера не будет зависеть? Просто прибит гвоздями к движку?

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 24-09-2019 в 15:03:

FiEctro эм, наоборот. В материале указывается шейдер для использования совместно с ним. Ну или указывается в шаблоне, чтоб каждый раз не писать его заново.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 25-09-2019 в 06:16:

Не помню, говорил я вам или нет, но в расширенном формате студиомоделей (который с развесовкой), есть одна очень любопытная штука - он способен сохранять KeyValue. Entity string если хотите. А новая архитектура пишется в том числе и с таким рассчётом, чтобы на месте мира могла бы любая модель, не только bsp. Так что потенциально вполне возможно будет делать мир моделькой, а кубать в блендере.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 25-09-2019 в 06:53:

Дядя Миша
К чему привязаны ключзначения? К целой модельке или к костям? Могут ли кости в модельковом мире играть роль энтитей?


Отправлено Дядя Миша 25-09-2019 в 07:29:

nemyax один к секвенциям, другой глобальный. Впрочем это не так уж и важно, когда мы имеем дело с кей-валуями, привязать можно всё что угодно.

Добавлено 25-09-2019 в 10:29:

А кости в роли энтитей - такое уже было в третьем дууме. Только смысла в нём немного. Разве что расчленёнка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 25-09-2019 в 07:46:

Цитата:
Дядя Миша писал:
Только смысла в нём немного. Разве что расчленёнка.

Если мы говорим за мир, то при чём тут расчленёнка. Я подумал про кость как генеричный объект. Ведь так называемая кость — по сути своей координатное пространство с некоторыми свойствами (и при необходимости с какой-нибудь приписанной геометрией). Если свойства можно задавать произвольно, то вот тебе и энтить. С геометрией — что-то типа брашевой, без — точечная.


Отправлено Дядя Миша 25-09-2019 в 08:51:

Ну вообще-то во первых в модельке существует лимит на 128 костей, а во вторых у брашевого мира никаких костей и вовсе нет. Да я думаю, если написать такой плагин к блендеру, который бы умел парсить стандартные кей-валуи, то никаких проблем бы не было. Он бы просто расставлял по миру-модельке различные энтити, в том числе и брашевые конечно. Поскольку возможность подгружать маленькие брашевые модельки тоже сохраняется.
Ну как в кваке аптечки были, к примеру. Так оно и здесь будет. Эта принципиальная возможность иметь в качестве модели мир открывает множество интересных комбинаций на самом деле.

Добавлено 25-09-2019 в 11:51:

Собственно при разработки второй паранои я уделил большое внимание тому, чтобы уравнять в правах модели и брашы. На статические модели декали ложаться как браши, один в один. Прикрутил к ним коллизию не хуже чем у брашей. Наконец дал им лайтмапу, правда пока с оговоркой - отражённый свет в индоре не учитывается. Но это я исправлю в NT. Таким образом у нас осталась только одна проблема - определение видимости.
Возможно я использую какой-то иной подход как для брашей, так и для моделей, т.к. методов всяких придумали очень много, надо будет подробно изучить этот вопрос.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 25-09-2019 в 13:36:

Дядя Миша
А для ворлдмодели(ей) есть такое понятие, как снаружи и внутри, или она(и) не обазательна(ы) быть замкнутой(ами)?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 25-09-2019 в 17:00:

thambs снаружи\внутри используется только для генерации порталов в BSP. Ну еще можно проверять что игрок в нулевом лифе и выполнять всякие оптимизации, например отключать зеркала на карте.
Больше оно нигде не используется.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 26-09-2019 в 10:07:

Рендеринг скорее всего тоже будет в игровой дллке. Не полностью конечно, а та часть, которая отвечает за отрисовку энтить. Так что поидее у каждой энтити будет виртуальный метод Render из которого и будет производится отрисовка с нормальным доступом ко всем членам класса. Как минимум это будет работать в сингле, даже если кто-то забудет прописать строчки в дельту. Правда надо будет еще придумать как подружить отложку с зеркалами-порталами. Если бы все объекты были непрозрачные, это не представляло бы никакого труда.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 26-09-2019 в 10:31:

Цитата:
Дядя Миша писал:
FiEctro эм, наоборот. В материале указывается шейдер для использования совместно с ним. Ну или указывается в шаблоне, чтоб каждый раз не писать его заново.


Свои шейдеры писать можно будет?

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 26-09-2019 в 12:44:

FiEctro да, в этом и задумка.

Добавлено 26-09-2019 в 14:25:

И еще. Я попробую восстановить функционал Quake3 на своей системе. Ну конечно не так, как там сделано, у меня не будет этих настроек, жестко прописанных. Но сами эффекты вполне реально будет замутить. Это будет тест на гибкость.

Добавлено 26-09-2019 в 14:26:

Можно будет даже скреатить такой специальный шаблон quake3shader и в нём намутить всё

Добавлено 26-09-2019 в 15:44:

ума не приложу что с мультипроходностью делать. Или полностью отказываться. Ну для водички-то отражения сделать будет можно, это ладно.
А вот насчёт мониторов-порталов-камер, это прямо таки под вопросом.

Отложка сама по себе не мешает организовывать мультипроходность, хотя конечно и жрёт видеопамяти очень много, кратно числу проходов, если мы хотим иметь рекурсивные отражения, например. Но, это как вы понимаете, легко отрегулировать в настройках, много видеопамяти - используем.
А вот как быть с прозрачными объектами, это прямо трогедия. Точнее если мы не будем их освещать. то половина трагедии, а вот если будем, это вообще кошмар какой-то. Я даже хз что делать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 26-09-2019 в 12:50:

Дядя Миша пили форвард+


Отправлено XaeroX 26-09-2019 в 13:00:

ncuxonaT
Чем форвард+ отличается от форвард-?

__________________

xaerox on Vivino


Отправлено thambs 26-09-2019 в 13:08:

Дядя Миша
Порталы может-то и не нужны, а вот без мониторов и камер плохо будет.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено ncuxonaT 26-09-2019 в 13:13:

XaeroX разбиением на тайлы со списками лайтов, декалей, лайтпроб и прочего в скрин спейсе или, еще лучше, в клип спейсе.


Отправлено Дядя Миша 26-09-2019 в 13:45:

ncuxonaT опять какие-то сетки. Хотя это может оказаться полезным, скажем на этапе расположения лайтпроб.

Добавлено 26-09-2019 в 16:45:

Цитата:
thambs писал:
Порталы может-то и не нужны, а вот без мониторов и камер плохо будет.

зеркала в скринспейсе еще худо-бедно можно нарисовать. А вот с камерами вообще швах. Ну да ладно, изучаю проблему. Проблема классическая про два стула, в перекладке на компьютерную термнологию память vs время.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 26-09-2019 в 15:14:

Дядя Миша то есть это тот самый прикол из-за которого в современных играх перестали делать зеркала, даже наподобие Спирита? Не говоря уже об отражении в них игрока.


Отправлено XaeroX 26-09-2019 в 15:53:

Crystallize
Честные зеркала перестали делать, потому что они удваивают работу рендерера и в общем случае в 2 раза снижают фпс. На абсолютно ровном месте. Не все готовы это терпеть.

__________________

xaerox on Vivino


Отправлено Дядя Миша 26-09-2019 в 17:02:

Цитата:
Crystallize писал:
то есть это тот самый прикол из-за которого в современных играх перестали делать зеркала

Ну не то чтобы прям совсем поэтому. Вон в новом метро сделали.
Эффективные менеджеры теперь всем рулят. В основном.

Цитата:
XaeroX писал:
Не все готовы это терпеть.

так квар на это дело. Для тех кто готов - on, для тех кто неготов off.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 26-09-2019 в 17:17:

Цитата:
Дядя Миша писал:
Вон в новом метро сделали.

где это там зеркала?


Отправлено Дядя Миша 26-09-2019 в 17:51:

Я тут вот еще думаю, может быть есть смысл изобрести какую-то новую технику. Раз существующие меня не устраивают.

Добавлено 26-09-2019 в 20:51:

ncuxonaT на речке

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 26-09-2019 в 18:09:

Дядя Миша так то скрин спейс


Отправлено Дядя Миша 26-09-2019 в 18:18:

ncuxonaT нме Элбер скидывал новые интервью с разрабами. И они там говорят - да, настоящие зеркала. Может надо настройки намаксимум поставить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 26-09-2019 в 18:19:

Цитата:
Дядя Миша писал:
И они там говорят - да, настоящие зеркала.

Так и ты всем говори!

__________________

xaerox on Vivino


Отправлено ncuxonaT 26-09-2019 в 18:49:

Дядя Миша они поди про RTX говорили


Отправлено Дядя Миша 27-09-2019 в 15:54:

В халфе вот эта гадость в input.cpp, ну где куча кнопок InKeyUp, InKeyDown.
Ну в халфе понятно оно из кваки, а там не заморачивались. Но в сорсе-то наверное переписали? Хрен там плавал! Так и тянут код из первокваки.
Уму нерастяжимо. Ну ладно написал менеджер для всего этого дела.
Теперь хоть выглядит семпотично.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 28-09-2019 в 11:51:

Сделал авто-регистрацию статически объявленных кваров. Больше не надо каждый раз писать CVAR_REGISTER (&some_variable);

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 28-09-2019 в 18:02:

Цитата:
Дядя Миша писал:
В халфе вот эта гадость в input.cpp, ну где куча кнопок InKeyUp, InKeyDown.

Ты можешь подготовить движок к тому чтобы хождение по стенам можно было сделать? Как я понимаю это уже сейчас надо закладывать.
И ещё я помню кто-то на форуме срашивал как заставить учёных гуфнуться с обрыва.


Отправлено Дядя Миша 28-09-2019 в 19:16:

Цитата:
Crystallize писал:
Ты можешь подготовить движок к тому чтобы хождение по стенам можно было сделать?

это всегда можно было сделать. Никому не было нужно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 29-09-2019 в 12:55:

Ну что жы, потихонечку начинает вырисовываться новая архитектура.
Конечно сейчас она в какой-то степени повторяет оригинальный код, т.к. перенос с одновременным переосмыслением это вообще невозможное дело, в плане тестирования. Но чуть позже, когда всё устаканится, там уже явным образом будет видно, как можно упростить код. Причём это касается всех частей движка. Сейчас такое интересное время, когда старый код трудится параллельно с новым и каждый работает примерно на половину своего функционала. Ну это как новый дом строят поверх старого.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Ghoul [BB] 29-09-2019 в 17:34:

Цитата:
Crystallize писал:
Ты можешь подготовить движок к тому чтобы хождение по стенам можно было сделать?

Зачем тебе ходить по стенам?
На потолке спать стало неудобно?

__________________
Ты топчешь мир своими ботинками,
Не замечая куда наступаешь,
А время от тебя уходит цветными картинками,
Но ты даже этого не понимаешь.

Компрометирую данные своей учётной записи.
ЛОГИН: Ghoul [BB]
ПАРОЛЬ: paladin_solo


Отправлено thambs 29-09-2019 в 17:41:

Ghoul [BB]
Например, вот эту станцию из одиссеи замутить:

Дядя Миша

Цитата:
Никому не было нужно.

Ты в timeline2 не играл? Глянь этот мод, уж очень он захватывает, даже несмотря на примитивное исполнение. Они там этот цилиндр имитировали очень короткими секциями с ченджлевелами, на зато в окошках вращающийся небосвод нарисовали.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 29-09-2019 в 18:00:

Цитата:
thambs писал:
Ты в timeline2 не играл?

неа.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Ghoul [BB] 30-09-2019 в 01:41:

thambs ты бы лучше mq доделал...

__________________
Ты топчешь мир своими ботинками,
Не замечая куда наступаешь,
А время от тебя уходит цветными картинками,
Но ты даже этого не понимаешь.

Компрометирую данные своей учётной записи.
ЛОГИН: Ghoul [BB]
ПАРОЛЬ: paladin_solo


Отправлено Crystallize 30-09-2019 в 05:13:

ну либо магические паззлы делать:
https://youtu.be/Thu0hZrgofk?t=203
thambs а я когда подростком играл этого не заметил как и невидимого монстра. Там видимо нужно умнее быть.
Кстати по всей видимости Timeline 2 вдохновлён вот этим:
https://www.youtube.com/watch?v=xPpXHX-Tu5U


Отправлено XaeroX 30-09-2019 в 05:45:

Цитата:
Дядя Миша писал:
это всегда можно было сделать. Никому не было нужно.

Подтверждаю. Единственное интересное применение я видел в Serious Sam: The Second Encounter, да и то - там это использовали буквально в паре мест, чтобы показать "смотрите, чё умеет наш движок!"

А так.. Не хочу уподобляться Мастеру, но в старой Волатиле (которая OIFD/Wolfram) уже был произвольный вектор гравитации, и у trigger_gravity было соответствующее поле. Кто ковырял SDK - тот заметил. Да только никому это нафиг не нужно было. И в новой я эту фичу делать уже не стал.

Добавлено 30-09-2019 в 12:45:

Цитата:
thambs писал:
Например, вот эту станцию из одиссеи замутить

Она орбитальная? Там же невесомость вроде должна быть? Или она крутится, создавая центростремительное ускорение?

__________________

xaerox on Vivino


Отправлено Crystallize 30-09-2019 в 05:49:

...и кстати игрок игроком, а для "космической станции" нужно будет и про энтити не забыть, чтобы та же дверь ездила в нужную сторону. Указать им всем источник откуда они будут брать корректный вектор.

Цитата:
XaeroX писал:
Да только никому это нафиг не нужно было.

Оно нужно либо в демках либо в мегапроектах. Если проект маленький то там обычно фантазия не доходит до космических станций.


Отправлено nemyax 30-09-2019 в 07:52:

Цитата:
XaeroX писал:
Единственное интересное применение я видел в Serious Sam: The Second Encounter

Кстати, отличная находка была. Ещё вспоминается The Nameless Mod для деуса, где такое замутили в метафизической лавке. Но там реализация топорнее.

Цитата:
XaeroX писал:
Или она крутится, создавая центростремительное ускорение?

Ага, по внешнему радиусу ходили-бегали.


Отправлено thambs 30-09-2019 в 10:59:

Ghoul [BB]
Увы, это уже только если команда будет — мне нужен ещё один мэппер и моделлер пропсов. В одиночку уже точно ниасилю — сам же видел сколько сил уходит на одну локацию (особенно если затупишь с чем-то).

XaeroX
Крутится да. Ну, конечно, это фича редкая и не то что бы востребованная, но отдельным работам придать изюминку может, ящитаю. В порядке "а что если", думаю, что будь у автора hazardous course 2 такая возможность — он бы станцию замутил, благо, даже с обычной гравитацией сделал локацию из "фонтанов рая", да и отсылок к "одиссее" там вагон и маленькая тележка (да и в приложенных сырцах есть эскиз станции). Кстати, если у вас в PW кроме беготни по колидорам и пустыне будет что ни будь орбитальное (предпоследний уровень, например, типа цель куда всю игру идёшь), то оно придаст игре дополнительных плюсов.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено XaeroX 30-09-2019 в 11:16:

Цитата:
thambs писал:
Кстати, если у вас в PW кроме беготни по колидорам и пустыне будет что ни будь орбитальное (предпоследний уровень, например, типа цель куда всю игру идёшь), то оно придаст игре дополнительных плюсов.

Ну это будет уже совсем наглое цитирование Quake 2

__________________

xaerox on Vivino


Отправлено thambs 30-09-2019 в 11:45:

XaeroX
Ну в ку2-то оно и на станцию мало похоже. Там, по моему, даже окон небыло, т.е. весьма абстрактная консткукция (ну и конечно, никакой кривизны). Да и потом, в ку2 небо рыжее с камнями, а у вас серое в тучах, как во втором фильме про чужих (активное терраформирование идёт?).

Добавлено 30-09-2019 в 14:45:

Цитата:
хождение по стенам

Вот кстати, ещё подумалось, что это весьма полезый вариант движений для тех же таракашек и хэдкрабов, например, ну и аналогичных монстров.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Ghoul [BB] 30-09-2019 в 11:57:

Цитата:
thambs писал:
Увы, это уже только если команда будет


Не будет. Уж если даже таким известным людям, как Ghoul [BB] и XWider в своё время никто не захотел помогать (а у них куча зарелиженых мощных проектов) то... сам понимаешь...

__________________
Ты топчешь мир своими ботинками,
Не замечая куда наступаешь,
А время от тебя уходит цветными картинками,
Но ты даже этого не понимаешь.

Компрометирую данные своей учётной записи.
ЛОГИН: Ghoul [BB]
ПАРОЛЬ: paladin_solo


Отправлено nemyax 30-09-2019 в 12:16:

Цитата:
thambs писал:
весьма полезый вариант движений для тех же таракашек и хэдкрабов

В AvP и вовсе можно было за чужова самому по стенам ползать.

Цитата:
Ghoul [BB] писал:
Уж если даже таким известным людям, как Ghoul [BB] и XWider в своё время никто не захотел помогать

Может, известные люди слишком много обзывались анальными словами?


Отправлено thambs 30-09-2019 в 12:27:

nemyax
Вот, кстати, ещё вспомнил, в серии dead space вполне себе было много локаций, где на магнитных ботниках нужно было ходить по стенам и потолку. Т.е. не такая уж это прямо таки никому ненужная фича, но редкая, да.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено AntiPlayer 30-09-2019 в 12:44:

В mirrors edge можно было по стенам немношко бегать

__________________
I tell you to enjoy life


Отправлено FiEctro 30-09-2019 в 14:08:

Цитата:
Дядя Миша писал:
это всегда можно было сделать. Никому не было нужно.


А как тогда к неработающему барнаклу забраться ?

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Chyvachok 30-09-2019 в 16:07:

Беготня по стенам конечно очень специфичная фишка, реально годной темой были бы разрушаемые браши в стиле Ред Фекшон.

Вообще разрушаемости особенно детальной мало в играх удаляют внимания, а в современных ее почти и нет, вспоминается только онлайн шутер где ломать стены можно, а в остальных играх весь мир абсолютно статичный, даже у мебели и прочих пропсов просто физики нету, а зря разрушаемость это очень веселая часть игры, вспомнить те же автоматы с напитками из 1 халвы, вспомнить можно ещё и первый кризис с ломаемыми пальмами и халабудами, мне лично всегда было забавно орощить все в играх.


Отправлено Дядя Миша 30-09-2019 в 16:29:

Цитата:
Chyvachok писал:
мне лично всегда было забавно орощить все в играх.

есть такие товарищи, у них подсознательная тяга к разрушениям.

Добавлено 30-09-2019 в 19:29:

А вообще я вам скажу. Всё что я сейчас делаю - это даже не работа над новой архитектурой. Это всего лишь подготовка к работе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 02-10-2019 в 10:04:

Так, теперь самое интересное. Надо придумать метод при помощи которого рендерер будет получать новые энтити для отрисовки. Тут две проблемы, которые к тому же противоречат друг-другу. Сам рендер энтити брать не должен, т.к. ничего про них не знает, но если игровая дллка будет ему сама их давать, возникает вопрос, как тогда быть с мультипроходностью. Зеркала, вот это всё.

Добавлено 02-10-2019 в 13:04:

Там надо составлять какие-то листы видимости для каждого прохода, но в них нельзя ничего копировать, это будет слишком тормозно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 02-10-2019 в 10:10:

Вот очём я и говорил, "красивый код" не всегда самый эффективный

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 02-10-2019 в 14:48:

Задачка имеет решение, надо лишь подумать как грамотно сделать.

Добавлено 02-10-2019 в 16:55:

Придумал. Перед началом основного кадра дллка добавляет список всех энтить для отрисовки в произвольном порядке, причём сами эти энтити могут быть вообще чем угодно, необязательно эдиктами. Могут и темп-энтити быть, например. Но при условии что эти объекты наследуются от абстрактного класса IRenderEntity. Примерно такого:

C++ Source Code:
1
class IRenderEntity
2
{
3
public:
4
  ~IRenderEntity() {}
5
  virtual bool CheckVisibility( const ref_viewpass_t *view ) const = 0;	// entity is present for this viewpass
6
  virtual const vec3 &GetRenderOrigin( void ) const = 0;		// actual entity origin
7
  virtual const vec3 &GetRenderAngles( void ) const = 0;		// actual entity angles
8
  virtual const matrix3x4 &GetRenderTransform( void ) const = 0;	// actual entity matrix
9
  virtual const matrix3x4 *&GetRenderBones( int &num_bones ) const = 0;	// get bones for studiomodels
10
  virtual const float GetBlendFactor( void ) const = 0;		// opacity value 0-1
11
  virtual const IModelBase *GetRenderModel( void ) const = 0;		// get model for rendering
12
};

А дальше рендерер уже сам их сортирует в плане прозрачности или для мультипроходности, вызывая вот эти каллбэки. Рендеру для успешной отрисовки в сущности нужно не так уж и много информации от энтить - вышеперечисленное и несколько локальных параметров, типа рендерколора, номера кадра (спрайты/брашы). Ну чот типа такого.
Это набросок. не окончательный вариант конечно.
Плюс в том, что все интеракции останутся в описании самих энтить, не придётся на клиенте городить огород, мучительно угадывая, кто это был на сервере и в какие поля у него какие номера эдиктов и флагов сохранены.

Добавлено 02-10-2019 в 17:43:

Вообщем с точки зрения пользователя клиентская часть (конструктивно объединённая с серверной в единой дллке) выглядит следующим образом:

CreateMove - тут обрабатываем нажатия клавиш
ClientReadSnapshot - получаем обновления с сервера
ClientRunFrame - предиктинг всех энтить (у которых это настроено)
AddRenderEntities - здесь считаем видимую позицию в мире (с учётом предиктинга, интерполяции, сетапим все кости и прочее).

дальше движок всё это сортирует и рендерит не обращаясь в пользовательскую юиблиотеку, но вызывая виртуальные методы в классах самих объектов. Методы все константные, т.е. в них не производится никаких рассчётов, это всё должно быть сделано в AddRenderEntities.
Таким образом пользователь получает возможность полноценно управлять процессом рендеринга и в то же время не вклинивается своими вызовами в отрисовку кадра, что потенциально небезопасно, т.к. может сломать мультипроходной рендеринг. Смысл еще и в том, что сам пользователь ничего не знает об организации рендеринга, что там вообще происходит, отложка, форвард, это для него полностью прозрачно. Единственное что пока под вопросом - это возможность кастомного рендеринга в определённых случаях. Ну например отрисовка лучей. Но и тут достаточно просто выйти из положения - завести еще один метод в классе IRenderEntity, типа bool CustomRenderEntity();
и в нём производить отрисовку, но из самой отрисовки оставить только генерацию вертексов. То есть никаких шейдеров-материалов в этом методе использовано не будет. Это позволит иметь и кастомный рендеринг и в то же время сохранить абстрагирование на прежнем уровне. По похожей схеме можно будет организовать и рендеринг пост-процессов, где пользовательская сторона, сообразуясь с миром сможет спокойно забивать всю необходимую инфу для доф-прицела, а в кастомной функции отрисовки рендерить FSQ
А очерёдность отрисовки задавать через очередной каллбэк явно или неявно.
То есть мы решаем сразу две задачки - во первых оставляем за пользователем возможность нарисовать всякую фигню, а во вторых не заставляем его заботится о бакэнде. В принципе можно и HUD рисовать таким образом, почему нет.

Добавлено 02-10-2019 в 17:48:

ЗЫ. Если из вышесказанного непонятно - сетап костей у моделей целиком и полностью на совести пользователя. То есть всякие там джигглы, рагноллы, кастомные веровки, мерж-бонесы, инверсная кинематика - ну словом абсолютно всё находится в пользовательской части. Рендер просто запрашивает массив уже посчитанных костей.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 02-10-2019 в 15:38:

Цитата:
Дядя Миша писал:
всякие там джигглы, рагноллы, кастомные веровки, мерж-бонесы, инверсная кинематика - ну словом абсолютно всё находится в пользовательской части

Какими средствами в пользовательской части можно будет палить игровое время и коллизию, чтобы трансформировать кости правильно?


Отправлено Дядя Миша 02-10-2019 в 17:10:

nemyax собсно все средства именно в пользовательской части и сосредоточены.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 04-10-2019 в 11:22:

Ладно, вам наверное текст читать не слишком интересно. Вот картинки.


Это AABB-Tree из первого квейка, в узлы линкуются энтити когда мы вызываем UTIL_SetOrigin.


А это такое же дерево, но из Doom3

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено AntiPlayer 04-10-2019 в 12:04:

Дядя Миша Больше лучше?

__________________
I tell you to enjoy life


Отправлено Дядя Миша 04-10-2019 в 12:18:

AntiPlayer под разные задачи просто.
Для Doom3 регулярная сетка по всем измерениям. Для квейков - только по XY.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 04-10-2019 в 12:49:

Зачем сетку за картой строить?

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено XaeroX 04-10-2019 в 12:51:

Цитата:
Дядя Миша писал:
А это такое же дерево, но из Doom3

Почему такое плотное? В чём подвох?

__________________

xaerox on Vivino


Отправлено Дядя Миша 04-10-2019 в 15:34:

Цитата:
FiEctro писал:
Зачем сетку за картой строить?

регулярное AABB Tree.

Цитата:
XaeroX писал:
Почему такое плотное?

карта мелкая. Там же глубина константная.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 04-10-2019 в 16:14:

Для чего используются такие дерева?


Отправлено ncuxonaT 04-10-2019 в 16:34:

Почему для квейков регулярная по XY, а не по XZ? Y же вертикальная ось?


Отправлено Дядя Миша 04-10-2019 в 16:51:

ncuxonaT в квейках Z вертикальная ось, порабы уже запомнить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 04-10-2019 в 17:02:

Дядя Миша а на твоём скрине где вертикальная ось, если регулярная сетка по XY?


Отправлено Дядя Миша 05-10-2019 в 14:06:

Ну чтожы пришло время вплотную заняться модель-менеджером. В игровом коде кстати вот это тяжкое бредовое наследие из кваки, оно ведь не нужно совершенно. Я имею в виду эти магические пары PRECACHE_MODEL\SET_MODEL. Это имело смысл только для виртуальной машинки первокваки, поскольку она не могла обращаться со структурой model_t и там ввели модельиндексы для этого дела. Но на практике постоянно возникает необходимость считать какую-то информацию из модели. В халфовском сервере с этим очень грустно дела обстояли, на клиенте чуть полутьшы.
То есть там даже со всеми функциями, которые я ввёл, надо было сперва получить модельиндекс, потом по нему взять модель и только потом к ней обратиться. Всё это не нужно совершенно. Одной функции SetModel более чем достаточно. Прекэш можно оставить только для клиентских моделей, причём на клиент посылать не загадочный модельиндекс, а номер строки, который соответствует имени модели, чтобы потом на клиенте найти её по этому номеру. А модельиндексы соответственно вообще упразднить, они не нужны, как таковые. Точнее говоря в них был смысл, пока не было системы уникальных строк, идентификаторы которых куда как лучше справляются с заменой этих модельиндексов. Потому что эти таблицы репласемнтов по сути излишняя абстракция, которая была нужна только для сохранения совместимости.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 07-10-2019 в 09:04:

Так же мне хотелось бы заложить поддержку на уровне движка деформируемого и разрушаемого окружения. Ну тут достаточно просто, это лишь часть задачи. Очевидно, что берётся исходная модель, к которой применяются некоторые действия. Причём эти действия необязательно связаны деформацией, главное отличие - это изменение какой-либо информации в модели. Например модели с лайтмапами. В исходной модели информации о лайтмапах нет, всё необходимое записано в карту. Но вертексы там уже иные, либо как в случае последних экспериментов, он развернуты в фан-вертексы. либо если делать по уму, то остаются стрипами, но всё равно добавляется информация о развёртке лайтмапы. То есть вертексы уже не оригинальные. В случае с деформацией, они дополнительно еще и сдвинуты согласно физическим законам. Как это реализовать? В нужный момент, во время игры или на старте делается копия модели, но не полная, а только та часть, которая поменялась, ну в данном случае это вертексы. Т.е. создаётся некая мета-модель со ссылкой на референс. А чтобы не путаться и держать всё в юниформе - она просто помещается в тотже единый массив из всех моделей. Конечно её можно будет сохранить в сейв, если понадобится. Аналогичным образом происходит и разрушение - модель делится на свои обломки, которые гененрируют целую пачку новых мета-моделей, на каждую назначается своя энтить с физикой твёрдого тела. Конечно с BSP такую штуку не проделаешь, но вот со студиомоделями - вполне себе.
точнее говоря, с BSP тоже можно, но бессмысленно, там ведь основной смысл в PVS, видимость. Такое на лету не пересчитаешь.

Добавлено 07-10-2019 в 12:04:

Еще один важный шаг к генеричности надо сделать - убрать из движка любую информацию про worldmodel. Ему не надо знать, что какая-то модель это мир. Для движка все модели должны быть равноправны. Что в свою очередь позволяет потенциально иметь несколько миров, загруженных одновременно и быстро переключаться между ними. И всё это можно реализовать в рамках пользовательской библиотеки.
В сущности у движка привязка к миру сводится лишь к построению overview, но это я уберу, сделаю членом класса модели.
А ну и естественно при таких параметрах нам понадобится хороший такой лимит на эти модели. Тысяч на 16 я думаю. А энтить на 65к. Но лимит на энтити всё равно в игровой части, там их можно будет сколько угодно замутить. Вот только с кол-вом клиентов пока не определился. Их по прежнему остается 32 штуки. Ну да ладно, клиентами я займусь, когда буду сетевую модель переделывать, до этого еще долико.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 07-10-2019 в 13:27:

Так товарищи. Все необходимые подготовительные работы выполнены, я уже избавился от client.dll и подготовил базу для рендерера, частичную, но основные уточнения уже будут непосредственно по ходу разработки, т.к. у меня еще мысль не оформилась, такое только на практике делается, особенно если учесть что для меня это совершенно новый тип рендерера, и поскольку я сам его придумал, то подсмотреть реализацию негде. По остальным саб-системам решение принято, там ничего особо интересного нет, да и движок выбирают за картинку. Так что наступает самая ответственная часть проекта - собственно рендеринг. Посмотрим что у меня получится, ну и в процессе постараюсь вас радовать скриншотами.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 07-10-2019 в 13:40:

Цитата:
Дядя Миша писал:
в процессе постараюсь вас радовать скриншотами

Может ведосики начнёшь записывать?


Отправлено Дядя Миша 07-10-2019 в 13:41:

nemyax ну неисключено.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 07-10-2019 в 13:53:

Цитата:
nemyax писал:
Может ведосики начнёшь записывать?

А есть ли разница?
Я например в канале пробовал и так, и так - результат одинаковый. А если нет разницы, но видосики при этом требуют больше времени для обработки - то может ну его?

__________________

xaerox on Vivino


Отправлено Crystallize 07-10-2019 в 14:03:

Цитата:
Дядя Миша писал:
Это AABB-Tree из первого квейка, в узлы линкуются энтити когда мы вызываем UTIL_SetOrigin.

Где у него АА и где BB? Если это противоположные углы кубика, тогда почему не АААBBB?


Отправлено nemyax 07-10-2019 в 14:07:

Crystallize
Axis-aligned bounding box.


Отправлено Дядя Миша 07-10-2019 в 15:27:

Crystallize что ты нисёжъ?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 10-10-2019 в 15:59:

Ну что же написал загрузчик вертексов в видеопамять. Там такая тема, что каждый вертекс должен точно соответствовать кол-ву своих переменных. Нельзя просто завести вертекс, в котором будут все атрибуты на все случаи жизни и использовать его для разных типов данных - будет ощутимо тормозить. Поэтому неплохо бы формировать эти вертексы исходя из данных, которые реально будут использоваться. Но проблема в том, что этих вариантов у меня уже накопилось достаточно немало и прописывать каждый вертекс отдельно во первых трудоёмко, во вторых очень легко запутаться, а в третьих мне еще и две версии надо иметь для старого железа и для нового.
Поэтому я разработал универсальный загрузчик. Здесь кстати, наглядно проявилось то, во что превращается крестовый код, если активно использовать все возможности. Понять что там происходит стороннему человеку уже практически невозможно, это взрыв мозга.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 11-10-2019 в 11:38:

Продолжаю имплементацию материалов. Сейчас именно тот самый момент, от которого зависит насколько будет удобно прописывать материалы по умолчанию. Надо подумать как лучшы сделать. Неявные хинты, дефолтный материал, или еще что-нибудь.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 11-10-2019 в 12:06:

Дядя Миша
Добавь в свой модельвьювер сразу возможность создавать и просматривать эти самые материалы в реальном времени, и дефолтные меши кроме самих моделей, кубик, сфера, цилиндр, конус, плоскость.

В блокноте врядли кто то будет ковыряться.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено thambs 11-10-2019 в 12:34:

Дядя Миша
А с отказом от ворлда, возможны ли будут "компилируемые префабы", ну или что-то вроде независимых кусков карты, которые можно вставить в другие карты и обращаться как к единому целому, так и к её составляющим?

Цитата:
Понять что там происходит стороннему человеку уже практически невозможно, это взрыв мозга.

А сам сможешь понять что писал, если, например, через год взглянешь на код?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 11-10-2019 в 13:00:

Цитата:
FiEctro писал:
Добавь в свой модельвьювер сразу возможность создавать и просматривать

да почему же именно в модельвьювер?
Тогда уж в материал-эдитор?

Цитата:
thambs писал:
А с отказом от ворлда, возможны ли будут "компилируемые префабы", ну или что-то вроде независимых кусков карты, которые можно вставить в другие карты и обращаться как к единому целому, так и к её составляющим?

Отказ от мира не означает, что его не будет. Это означает следующее:
1. явной мировой модели может и не быть и рендерер для этого не надо вводить явным образом в особое состояние, типа установки флажка RF_DRAW_WORLD. Как это реализовано сейчас: перед рендерингом вью-кэш ищет модельку с валидным PVS. Далее он проверяет что текущая позиция камеры попадает в ббокс этой модели и использует её для отсечения видимости.
2. мировых моделей может быть несколько штук, но их конечно надо будет разнести в пространстве. Ну или в игровом коде включать-отключать. Это уже на усмотрение мод-мейкера. Трасса по модели - это часть имплементации самой модели. Правда в классической трассе есть понятие мира, но трасса находится полностью в игровом коде, так что это легко поправить при необходимости.
То есть как это можно использовать: ну компилируемые префабы, да, бесшовная подгрузка уровней, обход каких-то лимитов или скажем просто лепить мир из повторяющихся кусочков. То есть тут масса вариантов может быть.

Цитата:
thambs писал:
А сам сможешь понять что писал, если, например, через год взглянешь на код?

Смогу, но мне для этого потребуется какое-то время.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 11-10-2019 в 13:34:

Цитата:
Дядя Миша писал:
да почему же именно в модельвьювер?
Тогда уж в материал-эдитор?


Это дополнительный софт писать, да и к тому же можно будет сразу на моделях посмотреть как выглядит тот или иной материал.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 11-10-2019 в 13:55:

Всё что было написано заранее, подготовлено, зачищено, так или иначе свелось к логическому упору, к самому главному моменту - настала пора заменить старый модельменеджер, который оперирует model_t на новый, который CModelBase. Это самая фундаментальная часть движка, на которой базируется абсолютно всё. Так что эта замена потребует порядочно времени, плюс у нового еще не все патчи дописаны, к примеру он умеет грузить только брашевые модели и ничего более. Так что в ближайшие недели новостей не будет. Но когда замена осуществиться - будет уже гораздо веселее, т.к. это самая масштабная часть операции по работе над ядром. Там уже глядишь и скриншоты пойдут, а может и демки.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 12-10-2019 в 13:36:

Если кому-то интересно - проект готов примерно на треть.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 12-10-2019 в 15:19:

Дядя Миша
А как ты измеряешь готовность проекта?

__________________

xaerox on Vivino


Отправлено Дядя Миша 12-10-2019 в 20:35:

XaeroX по соотношению намеченного и реализованного.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 16-10-2019 в 14:59:

Дядя Миша
Помню, ты экспериментировал с фиксированным серверным пингом для более стабильной физики. Что получилось в итоге, войдёт ли оно в NT?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 16-10-2019 в 15:18:

Не пингом. Фиксированным серверным фпс. да, войдет, но не в том виде.
Теперь клиент-сервер тикают синхронно, а рендер уже сколько задашь.

Добавлено 16-10-2019 в 18:18:

И да, кстати, интерполяцию надо делать не между клиентскими кадрами, а между кадрами рендерера. Клиенту по большому счёту пофиг на интерполяцию. В халфе с этим как раз и была мешанина. Часть интерполяций делалась между рендер-кадрами, часть между серверными, в итоге возникало рассогласование. Ничего удивительного.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 16-10-2019 в 15:22:

>пингом
Опечатка.
Дядя Миша
А как оно с управлением игроком / поворотами камерой работает, сохранится ли отзывчивость, присущая высоким fps?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 16-10-2019 в 15:57:

Сохранится

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 17-10-2019 в 19:07:

Я вот размышляю над тем, что модифицированные модели полезно сохранять в сейв. Вспомним опыт первого дуума.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено a1batross 17-10-2019 в 19:38:

Дядя Миша а как же мультиплеер? Это я про интерполяцию в рендерере.

Интерполировать движение объектов нужно и не только для рендерера. Халфа игроков интерполирует и получается, что на клиенте мы можем бросить трейс и быть уверенными что он попадёт в игрока как на клиенте, так и на сервере(на самом деле нет, ну оно просто само такое неидеальное). А когда сервер отмотает кадры в процессе анлага, то трейсы действительно придут куда надо.

__________________
Xash3D FWGS форк


Отправлено Дядя Миша 17-10-2019 в 20:35:

a1batross так на клиенте фраги не считаются всё равно. А за визуальную часть попадания отвечает именно рендерер.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено a1batross 18-10-2019 в 18:38:

Дядя Миша ну это да, а как же интерполированные энтити сделать солидными? Ну то, есть их рендерер будет солидными для себя?

__________________
Xash3D FWGS форк


Отправлено Дядя Миша 18-10-2019 в 18:48:

a1batross не забивай преждевременно голову

Вообщем получился у меня такой типичный крестовый код. В максимальном приближении всё очень красиво, но только Аллах ведает как это всё взаимодействует и работает.

Навскидку, ну вот такая хрень

C++ Source Code:
1
CVBOCache *CVBOManager :: CreateBuffer( const char *pszName, const CMeshBuilder &src )
2
{
3
  CVBOCache *pVBO = AllocBuffer();
4
  Q_strncpy( pVBO->m_name, pszName, sizeof( pVBO->m_name ));
5
 
6
  if( pVBO->Construct( src ))
7
    return pVBO;
8
 
9
  // for some reasons we failed
10
    FreeBuffer( pVBO );
11
  return NULL;
12
}

А за ней прячутся десятки килобайт шаблонов, которые строятся из других шаблонов, которые строятся из исходных структур.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено a1batross 18-10-2019 в 19:06:

Дядя Миша а чего не new CVBOCache/delete pVBO?

__________________
Xash3D FWGS форк


Отправлено Дядя Миша 18-10-2019 в 20:29:

a1batross такого тожы хватает.

По материалам я принял следующее решение: подсказки. Вот как это будет выглядеть:

C++ Source Code:
1
template <worldSolidMaterial>
2
{
3
  image u_ColorMap = "textures/<wadname>/<mipname>.tga";
4
  image u_DetailMap = "materials.def::detailmap";
5
  vec2 u_DetailScale = "materials.def::detailScale";
6
  float u_Smoothness = "0.35";
7
  frag u_ShaderFrag = "glsl/bmodelSolid_vp.glsl";
8
  vert u_ShaderVert = "glsl/bmodelSolid_fp.glsl";
9
#define APPLY_PBS
10
#usage mod_brush	// hint for template to implicit apply them for all brush model materials
11
}

вот строчка #usage это подсказка использовать шаблон, когда грузим модель определённого типа. По крайней мере не придётся прописывать миллион однотипных строчек как в том же сталкере.

Добавлено 18-10-2019 в 23:29:

Но тут опять же встаёт вопрос - допустимы ли множественные шаблоны с такой подсказкой и как определить подходящий? Скорее всего придется запретить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 18-10-2019 в 20:32:

#usage

Дядя Миша
Это директива препроцессору, или? Первый раз вижу, где почитать можно что это такое?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 18-10-2019 в 21:14:

thambs это мои материалы такие. К С++ это отношения не имеет.

Добавлено 19-10-2019 в 00:14:

Скажем вот в том же ку3, если шейдер не был прописан явным образом, он генерировался в коде из каких-то дефолтных настроек. Но пользователь не мог на это повлиять, он и не знал точно какие там настройки применяется, к тому же это зависело от типа модели. Моя идея в том, чтобы эти шаблоны по умолчанию создавал сам пользователь, так как ему нужно. То есть допускается иметь шаблоны с подсказкой - эти будут применяться автоматически к материалам, для которых вообще нет описания и шаблоны без подсказок - эти пользователь сам сможет применять к материалам, указывая их явным образом и перегружая нужные ему настройки.
В принципе для отдельно взятого материала можно перегрузить все настройки или вообще не использовать шаблон для его построения.
Кол-во настроек материала тоже задаётся пользователем. То есть к примеру можно не указывать шейдер, если материалу он по смыслу не требуется, будет осуществлён рендеринг на фиксированном функционале.
Теоретически на подобной системе легко эмулировать функционал как кутришных шейдеров, так и дуумтришных материалов, причём пользователь сам это создаёт скриптами и шейдерами. Аналогично, если не хочется ничего прописывать, можно обустроить тепичные шаблоны для всех материалов, прописать их один раз и не париться. Вообщем под разные задачи.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 19-10-2019 в 07:06:

Цитата:
Дядя Миша писал:
Скажем вот в том же ку3, если шейдер не был прописан явным образом, он генерировался в коде из каких-то дефолтных настроек.

Кажется, настал Великий день, когда Дядя Миша наконец-то разобрался, что в ку3 (и в Волатиле) вовсе не обязательно "прописывать для каждой текстуры шейдер". И перестанет пугать этим выдуманным фактом потенциальных пользователей Волатилы до полусмерти.
Ура, товарищи! Свершилось!!!

__________________

xaerox on Vivino


Отправлено Дядя Миша 19-10-2019 в 08:46:

Цитата:
XaeroX писал:
наконец-то разобрался, что в ку3 (и в Волатиле) вовсе не обязательно "прописывать для каждой текстуры шейдер"

Всегда знал, но хорошего в этом мало. Дефолты не перегрузишь, не переопределишь никак.

Добавлено 19-10-2019 в 11:13:

К тому же сам язык кутришных шейдеров устарел, это язык для FFP-фунционала, он просто не нужен в таком виде. Ну хотя Волатила и так неявно использует FFP-модель.

Добавлено 19-10-2019 в 11:22:

Вот вам кстати наглядный пример как программы усложняются со временем на ровном месте. В квейке для парсинга текстовых файлов использовалась простейшая функция COM_ParseFile и этого хватало для всех случаев. А теперь в новомодных движках все скрипты пытаются сделать на базе XML.
Уже не говоря о том, что лично мне представляется небесспорной сама идя XML, так его пытаются использовать для простейших вещей, типа сохранения тех же конфигов. На мой взгляд смысла в подобных скриптах нет никакого, интерпретаторы тех же крестов спокойно разбирают вполне человеческий код, без всяких идиотских тэгов. То есть оно по сути не нужно никому, ни человеку, который в блокноте XML уже не отредактирует, ни парсеру, который справится с любым форматом текста. Очевидно что под эти скрипты надо еще и свой редактор писать. Из вики мне особенно понравилась вот эта строчка:
Цитата:
− Примитивная библиотека может делать неоптимальный XML (например, <tag></tag> вместо <tag /> ). Работающая оптимально намного сложнее в программировании.

То есть у XML появилось еще и понятие оптимальности, хотя скрипты вообще должны быть лишены такого качества. А ведь есть люди, которые на XML сейв-рестор делают, ну чёб не париться. И так - в любой области. Просто сейчас аппаратный прогресс остановился и народ начал замечать, что их процессоры по большей части заняты непонятно чем.

Добавлено 19-10-2019 в 11:46:

Кстати вот к вопросу парсинга. Я учёт приходов\расходов веду в обычных .txt файлах. Пробовал когда-то программы для учёта финансов, но эти прогаммы все устроены по идиотски, там какие-то поля надо заполнять, причём именно так, как того хочет сам автор программы, т.е. надо как минимум разбираться, что он там имел в виду. Я в своё время выработал свой формат записи, не предназначенный для парсинга вообще, просто обычные записи в блокноте, примерно такого плана:

C++ Source Code:
1
Месяц Год
2
 
3
Доходы:
4
 
5
дата
6
источник     - сумма
7
 
8
дата
9
источник     - сумма
10
 
11
...
12
 
13
дата
14
источник     - сумма
15
 
16
Расходы:
17
 
18
дата
19
цель     - сумма
20
 
21
дата
22
цель     - сумма
23
 
24
...
25
 
26
дата
27
цель     - сумма
28
 
29
Итого:

Должно быть понятно, что основную сложность представляло подведение баланса, считал вручную на калькуляторе, но это отнимало порядочно времени. В какой-то момент мне это надоело, я сел и написал маленькую консольную утилитку, которая не только парсит такой формат файлов, но еще и находит в них некоторые ошибки (например, если месяц с годом в шапке указан один, а в списке дата неверная), подбивает баланс и выводит итоговый отчёт, причём баланс за месяц она пишет в тот же самый файлик, сверяясь с текущей датой и убедившись, что месяц завершен, аналогично формируется промежуточный и годовой отчёт.
У нее нет никаких параметров, очередная кнопка сделать круто. Запустил и через полсекунды всё готово. Писал я её где-то часа четыре, весит 20 килобайт, отвечает всем поставленным задачам, прекрасно разбирает обычный человеческий текст, который вообще не предназначался для парсинга никогда. Так вот и какой смысл городить все огороды, спрашивается. Очевидный ответ - несолидно, надо больше всего, надо чтоб место занимало, надо чтоб интерфейс красивый, надо чтоб кнопок всяких и побольше. Главная цель за всем этим куда-то исчезла.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 19-10-2019 в 08:50:

Цитата:
Дядя Миша писал:
А теперь в новомодных движках все скрипты пытаются сделать на базе XML.

Я в старой волатиле тоже повёлся на это, и сделал XML-конфиги (для HUD). Даже tinyxml-парсер прикрутил. И всё время меня что-то беспокоило, но я не мог понять, что именно. Вроде и модно, и молодёжно, и современно - но кошки на душе скребут.
А потом я разобрался. Удалил в новой волатиле все эти xml-ы нафиг и сделал обычные парсеры на основе COM_Parse. И тут же стало легко и приятно на душе. И конфиги стали выглядеть прилично, а не как говно, пестрящее угловыми скобками.
Цитата:
Дядя Миша писал:
Ну хотя Волатила и так неявно использует FFP-модель.

Я больше скажу - абсолютно все движки неявно используют FFP-модель. Просто раньше они напрямую использовали функции OpenGL (типа glTexGen и TNT combiners), а теперь пытаются всё это эмулировать через шейдеры. А по сути это тот же набор fixed-функций, ну разве что чуть более расширенный - например, не одна, а три модели освещения на выбор.

Добавлено 19-10-2019 в 15:50:

Цитата:
Дядя Миша писал:
Пробовал когда-то программы для учёта финансов, но эти прогаммы все устроены по идиотски, там какие-то поля надо заполнять, причём именно так, как того хочет сам автор программы, т.е. надо как минимум разбираться, что он там имел в виду.

Открой для себя Microsoft Excel...

__________________

xaerox on Vivino


Отправлено Дядя Миша 19-10-2019 в 10:11:

Цитата:
XaeroX писал:
И конфиги стали выглядеть прилично, а не как говно, пестрящее угловыми скобками.

С этими тэгами вообще вопрос очень интересный. Если их надо закрывать ровно в той же последовательности, в которой открывал, то чем это лучше фигурных скобок? Очевидно здесь выполняется бессмысленная работа, к тому же еще и увеличивающая размер файлов. Кому это надо? Да никому.
Зачем это сделано? А хрен его знает. Мне больше всего нравится, что эти тэги пользователь еще и вручную определяет, то есть вместо именованного блока, типа:
C++ Source Code:
blockname
{
}

нас заставляют писать
C++ Source Code:
<blockname></blockname>

И сразу же появляется вопрос оптимальности, оказывается можно еще писать
C++ Source Code:
<blockname />

я так понимаю на тот случай, если у нас всё умещается в одну строку. С фигурными скобками этой проблемы не возникает вообще. Я понимаю, что оно от SVG кажется наследуется, а тот в свою очередь был сделан гораздо раньше, но зачем было вообще плодить эти сущности?

Цитата:
XaeroX писал:
Я больше скажу - абсолютно все движки неявно используют FFP-модель

Фиксированный функционал = мультипроходный рендеринг, он в первую очередь завязан на расположении текстурных юнитов. Потом добавили мультитекстурность и стало чуть попроще, но всё равно ты должен располагать эти юниты в определённом порядке, чтобы они правильно смешались между собой. В шейдерах это теряет всякий смысл, нам больше не надо городить блоки
{
map
}
в строго определённой последовательности в описании шейдера. Ну разве что мы будем эмулировать кутришный функционал.

Цитата:
XaeroX писал:
Открой для себя Microsoft Excel...

Ну Эксель как минимум надо поставить, а то еще и купить, мы же чесные программисты и против пиратства? А блокнот изкаропки есть.

Добавлено 19-10-2019 в 12:41:

Материалы-материалами, но походу возникла потребность сделать еще какое-то описание для шейдеров.

C++ Source Code:
frag u_ShaderFrag = "glsl/<rendertype>/bmodelSolid_vp.glsl";
vert u_ShaderVert = "glsl/<rendertype>/bmodelSolid_fp.glsl";

Вот так писать каждый раз в шаблоне еще нормально, а скажем в описании материала уже будет напрягать. К тому же этот объект скорее всего сможет переиспользовать одни и те же шейдеры множество раз, но с разными настройками #define, которые неплохо бы указать общими для такой сущности. То есть сделать для шейдерного объекта генеричное описание, с собственным именем. К тому же мне вероятно понадобится собрать в такой объект не один, а несколько шейдеров, понятно почему - для форварда основной проход, для форварда - освещение, для отложки построение G_BUffer, финальный рендеринг. Т.е. некая сущность над описанием шейдеров. И назвать её, ну скажем shaders.def, навряд ли их там будет слишком много, чтобы городить множество файликов.

Добавлено 19-10-2019 в 12:43:

Причём, я так полагаю формат описания логично унаследовать от описания материалов и шаблонов, чтобы получился настоящий полиморфизм. Это даст возможность конструировать любые типы объектов и перегружать любой параметр для отдельно взятого материала.

Добавлено 19-10-2019 в 13:09:

Посмотрел как в последнем крае это устроено. Ну там все техники, объявленные в шейдерах, жестко привязаны к вызовам этих имён из кода.
Это не то, что мне нужно.

Добавлено 19-10-2019 в 13:11:

То есть вот для примера technique SunShaftsDisplay - она жёстко объявлена в коде в движка, её нельзя переопределить или создать новую технику.
Можно только отредактировать сам шейдер.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено a1batross 19-10-2019 в 10:15:

Дядя Миша а что если как раз дать переопределять дефолты? А то и разрешать наследование материалов:

default { /* default materials opts */ }

material1 { ... }

material2 : material1 { ... }

Это я так, про экономию строчек и удобство работы с материалами.

XaeroX нынче модно молодёжно это JSON.
Который кстати тем же COM_ParseFile в теории можно распарсить.

__________________
Xash3D FWGS форк


Отправлено nemyax 19-10-2019 в 10:30:

Цитата:
Дядя Миша писал:
Эксель как минимум надо поставить, а то еще и купить

LibreOffice Calc, да и всё.


Отправлено thambs 19-10-2019 в 10:35:

a1batross
Ну джонсон-то человекочитаем и человекоредактируем в отличие от.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено a1batross 19-10-2019 в 10:36:

thambs да, так и есть.

__________________
Xash3D FWGS форк


Отправлено thambs 19-10-2019 в 10:37:

Дядя Миша
А материал можно будет автоматически вывести из имени используемой текстуры? Например есть шаблон *wood*, и все текстуры содержащие *wood*, что отдельно не описаны, наследуют этот шаблон?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 19-10-2019 в 11:26:

Цитата:
a1batross писал:
а что если как раз дать переопределять дефолты?

ну я про это и говорю. Система наполовину существует в моём воображении, поэтому что-то будет скорее всего меняться, но пока концепция следующая:
1. мы можем создавать шаблоны для определённого типа моделей, типично это спрайты, студиомодели и брашы. Если придумаете по каким еще критериям можно отсортировать объекты на группы, то я могу включить и другие варианты в качестве хинтов, но пока что мне этот кажется наиболее логичным.

2. если у материала не прописан никакой тип и нет дефолтного шаблона, то скорее всего он будет рендериться как wireframe, чтобы наглядно это продемонстировать пользователю.

3. шаблон материалу можно указывать явным образом или не указывать совсем, если присутствуют шаблоны с подсказкой.

4. всё что указано в шаблоне можно переопределить в самом материале, но в большинстве случаев это просто не нужно.

5. наследование материала от материала сделать возможно, но я пожалуй воздержусь, т.к. это запутает юзера. К тому же, поскольку это всё же не язык программирования и здесь не требуется forward-declaration, то первое что сделает находчивый юзер, это унследует пару материалов друг от друга. чтобы посмотреть что из этого получится. Так что нет, это не слишком хорошая идея.

Цитата:
thambs писал:
А материал можно будет автоматически вывести из имени используемой текстуры?

нет, такого нет. Мне не нравится эта идея, эти фильтры принципиально неконтролируемы юзером, как поиск по маске почти никогда не находит точно то, что требуется. Он всегда находит либо больше либо меньше, а остальное человек уже должен сам вычленить из списка.

Для описания шейдеров навскидку сделал вот такой формат. Это ни в коем случае не окончательный вариант, это первое приближение.

Добавлено 19-10-2019 в 14:05:

Я не знаю как люди пишут скриптовые языки или вообще какие-то стандарты скриптов, но я сперва пишу сам скрипт, как бы мне хотелось чтобы это выглядело, а потом под него уже пишу парсер. Наоборот у меня не получается.

Добавлено 19-10-2019 в 14:26:

Вообще я планирую сперва воссоздать forward-патч на основе шейдеров из паранои, т.е. таким образом, чтобы мне не пришлось их подключать в коде.
А потом уже можно будет задуматься насчёт остальных патчей и их кол-ве.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 19-10-2019 в 11:49:

Цитата:
a1batross писал:
нынче модно молодёжно это JSON.
Который кстати тем же COM_ParseFile в теории можно распарсить.

Вот-вот. Поумнел народ с годами. Это радует.
Зато теперь появилось новое ругательство - "парсить джейсоны". Например, сделал человеку плохо, а он тебе - "шоб ты на работе парсил джейсоны!"

__________________

xaerox on Vivino


Отправлено Дядя Миша 19-10-2019 в 12:15:

Цитата:
За счёт своей лаконичности по сравнению с XML, формат JSON может быть более подходящим для сериализации сложных структур

МБУГОГА. Изобрели новый формат и тут же облили грязью старый, да мол XML этот ваш - гавно. Слышали?

Цитата:
Запись — это неупорядоченное множество пар ключ:значение, заключённое в фигурные скобки «{ }»

Ребята взяли описание энтити от кваки, но чтобы у них всё было "совершенно по другому", добавили еще двоеточие. Впрочем для "сериализации сложных структур" это всё равно не годится. Помните ad_sepulcher для ArcaneDimensions? Ну где 8 тысяч энтить? А в кваке сейвы устроены что твой JSON, ну только без двоеточия. Корочи на этой карте сейв грузится секунд 20. Надо ли говорить что в кувраппере на этой же карте сейв грузится пару секунд? Скрипты для сериализации не годятся абсолютно. Суть скрипта именно вот в том, чтобы их человек мог писать и редактировать. А сохранять в них что-то дурацкая затея. Скажем в той же кваке можно было открыть скрипт в блокноте и написать себе сколько угодно здоровья и пушек. Или там шаблера удолить из сейва, если вы его пройти не можете.

Добавлено 19-10-2019 в 15:15:

Вообще самая быстрая парсилка это fgets + sscanf, я када был молодой и неопытный, то переделал studiomdl со sscanf на COM_ParseFile, ну типо так красивше. И очень удивился, что у меня время на чтение .smd выросло, ну так раз в 10.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 19-10-2019 в 12:34:

XaeroX
А зачем их "на работе парсить", когда этим библиотека занимается?

Добавлено 19-10-2019 в 15:34:

Цитата:
Дядя Миша писал:
scripts.rar

А в shaders.def в одни строки заканчиваются на ";\r\n", другие — просто "\r\n". Как оно будет в финале?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 19-10-2019 в 13:02:

Мне стало интересно что вообще творится со скриптами в остальных движках, ибо, как известно, современный движок этими самыми скриптами и силён. В этом его главное отличие от кваки, где наоборот всё захардкодено и крутись как хочешь. Ну вот открыл UnrealScript:

Вот к примеру структурки:

C++ Source Code:
1
struct {DOUBLE} double
2
{
3
  var native const int		A;
4
  var native const int		B;
5
};
6
 
7
struct BitArray_Mirror
8
{
9
  var native const pointer IndirectData;
10
  var native const int InlineData[4];
11
  var native const int NumBits;
12
  var native const int MaxBits;
13
};

Ну это то ладно. Вот АТД Vector
C++ Source Code:
1
struct immutable Vector
2
{
3
  var() float X, Y, Z;
4
};

Что такое var я не знаю. А вот насчёт immulatble тоже непонятно. Разве это не тоже самое что final?
А вот наследование:
C++ Source Code:
1
struct immutable Plane extends Vector
2
{
3
  var() float W;
4
};

Константы
C++ Source Code:
const MaxInt = 0x7fffffff;
const Pi = 3.1415926535897932;

Здесь другая крайность - у констант почему-то не указан тип.
Но самая жэсть начинается далее:

C++ Source Code:
1
native(133) static final operator(34) byte *= ( out byte A, byte B );
2
native(198) static final operator(34) byte *= ( out byte A, float B );
3
native(134) static final operator(34) byte /= ( out byte A, byte B );
4
native(135) static final operator(34) byte += ( out byte A, byte B );
5
native(136) static final operator(34) byte -= ( out byte A, byte B );
6
native(137) static final preoperator  byte ++ ( out byte A );
7
native(138) static final preoperator  byte -- ( out byte A );
8
native(139) static final postoperator byte ++ ( out byte A );
9
native(140) static final postoperator byte -- ( out byte A );
10
native(129) static final preoperator  bool  !  ( bool A );
11
native(242) static final k2pure operator(24) bool  == ( bool A, bool B );
12
native(243) static final operator(26) bool  != ( bool A, bool B );
13
native(130) static final operator(30) bool  && ( bool A, skip bool B );
14
native(131) static final operator(30) bool  ^^ ( bool A, bool B );
15
native(132) static final operator(32) bool  || ( bool A, skip bool B );

Вот что это за хрень? Я плохо знаю С++, я даже не знаю, можно ли там перегружать постинскрмент, ну просто не возникало такой надобности, а проверять лениво. Ну здесь как мы видим можно. Но вот эти нативные номера смущают. Это типо как буллетины в первокваке штоли?
И что такое k2pure наконец?

Но вот мы добрались и до функций:
C++ Source Code:
1
static final function float FInterpEaseIn(float A, float B, float Alpha, float Exp)
2
{
3
  return Lerp(A, B, Alpha**Exp);
4
}
5
 
6
static final simulated function k2pure float RandRange( float InMin, float InMax )
7
{
8
  return InMin + (InMax - InMin) * FRand();
9
}

Опять загадочный k2pure. Обратите внимание, что интерпретатор даже не в состоянии догадаться что перед ним функция, ему надо прямо словами написать function. К тому же есть еще загадочный модификатор simulated. Ну вероятно есть и emulated. И вон там двойное умножение, не то взятие адреса, хотя из самой функции вообще непонятно зачем там брать адрес. Ну в принципе достаточно. А теперь ответьте мне на простой вопрос - неужели ВОТ ЭТО легче в освоении, чем кресты?
Мне кажется это тепичная подмена понятий по Конфуцию. Низкоуровневые языки сложны в освоении в первую очередь из-за необходимости "прямой" работы с памятью, в кавычках, потому что там минмум два слоя абстракции - защищеный режим процессора и ядро самой винды. Этож не 286-й, где можно было биосу тень херачить из паскаля. Ну не суть. Народ вообщем не любит когда исключения бросаются. Ну на то и песочница, чтобы разрулить проблемы с памятью. А вот зачем так усложнять синтаксис? Причём этих модификаторов там гораздо больше чем я показал, есть еще interface, event, cpptext, virtual кстати есть, transient, inherits. На кого это вообще рассчитано?
на дезигнеров? Не, ну серъезно.
Как бы на таком фоне неудивительно что они UC дропнули и замутили блупринты. Я их правда не видел, но они вероятно проще, раз с ними даже наш Жэка освоился.

Добавлено 19-10-2019 в 15:51:

Цитата:
thambs писал:
А в shaders.def в одни строки заканчиваются на ";\r\n", другие — просто "\r\n". Как оно будет в финале?

ну щас парсер напишу и посмотрим.

Добавлено 19-10-2019 в 16:02:

C++ Source Code:
1
/** @return the name of the package this object resides in */
2
final function name GetPackageName()
3
{
4
  local Object O;
5
 
6
  O = self;
7
  while (O.Outer != None)
8
  {
9
    O = O.Outer;
10
  }
11
  return O.Name;
12
}
13
 

А тут прямо квакой дыхнуло. local, self

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 19-10-2019 в 13:09:

Цитата:
И вон там двойное умножение, не то взятие адреса

Возведение в степень же, даже название у переменной соответствующее — во всех клиентских языках так. Это ведь только C, когда придумывали, то, видимо, на клавиатурах не было символов @, ни $, вот они и повесили по 4 действия на один литерал специально что бы текст как можно более нечитаемым сделать.
Цитата:
ВОТ ЭТО легче в освоении, чем кресты?

Ну так потому что если что-то основывается на "идеях С", то в результате становится монстрообразным кошмаром, кресты тут не исключение, и новые стандарты его не сильно спасают.
Цитата:
На кого это вообще рассчитано?

Потому что придумывают это погромисты, а не лингвисты.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 19-10-2019 в 13:30:

Цитата:
thambs писал:
Возведение в степень же, даже название у переменной соответствующее — во всех клиентских языках так.

А если три звёздочки?

Цитата:
thambs писал:
Ну так потому что если что-то основывается на "идеях С", то в результате становится монстрообразным кошмаром

GLSL стал кошмаром? Да и потом, что вообще считать "идеями Си". Придумать как можно больше всяких модификаторов, это кто такое предлагал? А перед каждой функцией писать function это вообще зачем?
парсеру очевидно это не нужно. Значит для тупых юзеров. Юзер настолько туп, что даже не в состоянии осознать что перед ним функция?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 19-10-2019 в 14:00:

Дядя Миша

Цитата:
А если три звёздочки?

Не встречал такого, может гиперстепень? Правда не видел кейсов где оно в реальных вычислениях используется.
Цитата:
GLSL стал кошмаром?

Так он его не расширяет а сужает же. А кошмар начинается, когда С-шными приёмами описывают высокие абстракции. Вот плюсы наиболее характерный такой пример, они ведь стали настолько запустанными и переусложнёнными, что никто уже не понимает что там происходит. Уже и метапрограммирование есть, а такие полезные вещи как строгая типизация и иерархия типов (которые в том числе могли бы на этапе компиляции отловить сотни ошибок) — их не будет никогда, т.к. невозможно в С-шную парадигму впихнуть её не изломав всё.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено FiEctro 19-10-2019 в 15:24:

Походу, один только я пишу код сплошными ифами и кейсами в не зависимости от языка.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 19-10-2019 в 15:35:

Цитата:
thambs писал:
Вот плюсы наиболее характерный такой пример

Там не в языке проблема, а в выборе объектной модели. Причём, как я понимаю, тот же STL навязывает свою объектную модель, а boost - свою.
Потому что у каждого свое виденье, как это должно выглядеть.

Ну да ладно, оставим лингвистические споры. В процессе реализации парсера техники пришло понимание, что её в некоторой степени надо сделать похожей на DX-технику, точнее говоря включить в нее те настройки, которые недоступны из шейдера. Это блендфунк, альфа-функ, куллинг, дептчмаск, ну понятно. Не в том конечно виде, в котором они представлены в кутришных шейдерах, в максимально приближенном к обычному гл-вызову. Рассчёт в этом (да и аналогичных случаях), такой:
те, кто будут это ковырять, уже наверняка знают GLAPI. А тем, кто не знает не придётся учиться новой абстракции. Ну потихоньку уже что-то вырисовывается. Я тут текстом попытался изобразить, но помоему не очень понятно получилось

code:
VBOMesh |->material0 |->textures |->texture0 |->texture1 |->systemTexture0 (e.g. lightmap) |->systemTexture1 (e.g. screencopy) |->shaderObject |->techique0 (shader, glstate, defines) // ambient pass |->techique1 (shader, glstate, defines) // spotlight pass |->techique1 (shader, glstate, defines) // omnilight pass |->material1 |->material2


Добавлено 19-10-2019 в 18:35:

Млять! И всё съехало нахер! Ксераааааакс

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 19-10-2019 в 17:10:

Цитата:
Дядя Миша писал:
Млять! И всё съехало нахер! Ксераааааакс

Ну ты как будто вчера на нашем форуме зарегался.

__________________

xaerox on Vivino


Отправлено Дядя Миша 19-10-2019 в 21:14:

Пересмотрел концепцию (я научился этому у покойного бумки), текущий вариант выглядит вот так, он уже парсится. Вариант не окончательный, но уже близкий к тому. Декларация псевдокодом по моей задумке должна подчёркивать, что всё написанное это не просто переменные, которые либо будут использоваться, либо нет, а то, что гарантированно будет выполнено в коде. Техника таким образом это готовый шейдерный проход, позволяющий что-то нарисовать с заданными параметрами. Там список неполный, надо еще подключить технику для теней и отложки, но это позже.

Добавлено 20-10-2019 в 00:14:

Ну чтожы, потихоньку система собирается из тысячи кусочков в единый механизм

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено a1batross 20-10-2019 в 01:55:

Дядя Миша эка у меня сразу текстовый редактор сказал -- это исходный код на C.
Наверное из-за .def расширения.

code:
depthMask( GL_FALSE ); blendFunc( GL_ONE, GL_ONE );


А в чём смысл от приставки GL_ тут?

__________________
Xash3D FWGS форк


Отправлено XaeroX 20-10-2019 в 06:49:

Цитата:
a1batross писал:
А в чём смысл от приставки GL_ тут?

Как в ку3.

__________________

xaerox on Vivino


Отправлено Дядя Миша 20-10-2019 в 11:41:

Цитата:
a1batross писал:
А в чём смысл от приставки GL_ тут?

есть алиасы без нее. Кому што нравится.

Добавлено 20-10-2019 в 12:45:

Да, с юниформами надо в корне пересмотреть концепцию, то что я нагородил мне сейчас решительно не нравится.

Добавлено 20-10-2019 в 14:41:

Моя ошибка была в том, что я использовал старую концепцию юниформов, когда один тип содержал в себе все варианты использования. Это просто избыточно и неудобно. Разделил на три типа: макросы для препроцессинга, собсно сами юниформы со значениями и текстурные юниты.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 20-10-2019 в 21:41:

Так, ну судя по всему от первоначального варианта вообще мало что останется. Не выдержал он столкновения с реальностью. А реальность нам дана в ощущениях в виде шейдеров из паранои.

Добавлено 21-10-2019 в 00:41:

Тимплейты под нож пойдут скорее всего, они не нужны.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено AntiPlayer 21-10-2019 в 07:16:

Цитата:
Дядя Миша писал:
XML

XML это формат разметки документов. Довольно странная идея хранить в них конфиги.
JSON тоже избыточен как по мне, это формат созданный для передачи данных по сети. Хотя, для хранения сейвов сам по себе подошел бы, наверное.

Чем плох обычный .ini для конфигов?

Цитата:
XaeroX писал:
Зато теперь появилось новое ругательство - "парсить джейсоны"

Мое любимое занятие

__________________
I tell you to enjoy life


Отправлено XaeroX 21-10-2019 в 07:23:

Цитата:
AntiPlayer писал:
Мое любимое занятие

В нашем возрасте пора заставлять делать это подрастающее поколение джуниоров!

__________________

xaerox on Vivino


Отправлено Дядя Миша 21-10-2019 в 13:58:

Ну чтоже. После всех поправок и корректировок моих фантазий сообразно с реальностью и внутренней организацией конвейера, получилось вот такое вот. Это уже не абстрактный пример, оно парсится и генерит шейдеры.

Поясню что здесь к чему.
Каждый материал содержит ссылку на т.н. ShaderObject, который содержит в себе Techinques - техники. Назначение техник жестко определено в движке, это фиксированный набор, который нельзя изменить. На данный момент в наборе есть следующие типы:
base (ambient) - проход для рендеринга в паре с лайтмапами, статичный свет. Что рендерить в этом проходе выбирает конечно сам юзер, ему никто не навязывает непременно рисовать лайтмапы.
spot - освещение объекта для спот-лайтов
omni, sun - аналогично для всенаправленных и солнца.
shadow (depth) - для прохода теней.
в дальнейшем так же планируется проход для г-буффера, возможно для пост-процессинга, ну вообщем понятно. Все техники указывать необязательно, если вы например хотите чтобы какой-то конкретный материал (ну например полупрозрачный) не давал тени - просто не прописываете её технику в описание шейдер объекта. Или наоборот хотите, чтобы объект было видно только в лучах фонаря - для base строите пустой шейдер, который записывает только в буффер глубины, и для спот-лайта еще один. Ну это просто как пример использования.

В самих техниках можно настроить gl-state, практически весь набор, используемый в паре с шейдерами (который невозможно эмулировать из шейдера) - куллинг, запись в буффер глубины, полигоноффсет, ваерфрейм, итд. gl-state нельзя переопределить ниоткуда, он всегда существует только в самой технике. Если вам нужно непременно его переопределить для какого-то материала, то заведите отдельный шейдеробъект. Разные шейдер-объекты могут ссылаться на одни и те же техники. В техниках, как вы видите прописаны юниформы, которые используются в шейдерах, путь до которых задаётся там же. Кроме самих юниформов им назначаются дефолтные значения, как явные, так и относительные, в виде ссылок на какую-то информацию из движка.
Всего доступно несколько больших групп с переменными:
globals - глобальные параметры
light - для текущего источника света
entity - параметры энтити
render - позиция камеры, вьюматрица, ну понятно
lightProbe - типа R_LightForPoint
cvar - взять переменную, имя текстуры или индекс текстуры из квара.
materials.def - взять из описания материалов.
либо задать константу. Константы можно задавать и для vec2-vec3-vec4.
смешанные данные для векторов не поддерживаются, это всё же не язык программирования, а просто скрипты.

аналогично прописываются и текстурные юниты с относительными путями, конечно никто не мешает влепить туда константный путь.ъ

юниформы и текстурные юниты можно перегружать из любого материала в любом кол-ве. Хоть вообще все, но есть одна тонкость - всё что вы пропишете в материале будет применено ко всем техникам из шейдерного объекта. Разумеется для конкретного прохода будут использоваться только те юниформы, которые реально существуют в конкретном шейдере, т.е. объявлять лайтмапу для спотлайта имеет смысл, если сам шейдер обращается к ней.

С макро-подстановками немного по-другому. Они доступны сразу из трёх мест - из шейдер объекта, из материала и из техники. В случае использования в материале и в шейдер объекте, макросы будут применены сразу ко всем техникам в группе.

Единственное что я еще планирую сделать на этом фоне - возможность постановки тех или иных макросов в шейдеробъекте в зависимости от условий. Т.е. ввести кондиции в шейдеробъект.

Задавайте вопросы, что непонятно, предлагайте что поменять. Вам же потом с этим работать.

Добавлено 21-10-2019 в 16:58:

Можете так же приводить примеры из других движков, если вам там что-то понравилось, какие-то идеи.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 21-10-2019 в 18:33:

Ладно, раз молчите, расскажу немного о концепции всего этого дела.
Эта система возникла не на пустом места, а явилась итогом многолетних рассуждений на тему организации материалов в рендерере. Я изучал как это реализовано в других движках, как к этому относятся непосредственные пользователи и выяснил несколько любопытных вещей:

1. Если движок базируется на идеях Кармака или просто частичный форк - там непременно будут либо кутришные шейдеры, либо дуумтришные материалы, либо их симбиоз в самых разнообразных вариациях. Причём не имеет особого значения, был ли это движок куплен у Кармака в далёкие времена или это народная модификация на GPL-сорсах. Тут еще что любопытно, те, кто эти системы модифицирует, как правило сам никаких материалов не пишет.

2. Если движок принципиально отвергает идеи Кармака, то материалы представляют собой две крайности: или это полная минималка, как в сталкерах-метро, где можно настроить несколько параметров и указать путь к детальной текстуре, либо чуть ли не свой собственный язык с визуальным конструктором, как во всяких Unity\Unreal.

3. Пользователи так же делятся на два типа. Одним просто нравится играться с настройками материалов, но ихние игры почти никогда не идёт в продакшен, это просто хобби такое, ну максимум ассет выпустят когда-никогда. Причём они в этом ассете все настройки пару лет подбирали. Второй тип, это которые делают реальную игру и у них голова болит сразу за миллион вещей и им эти материалы как серпом об асфальт.

4. То есть со стороны реального пользователя имеем на первый взгляд такие взаимоисключающие требования - с одной стороны чтобы система была мощной, с другой, чтобы по дефолту не надо было ничего крутить.

Вот на четвертом пункте, я и строил свою систему. Какое-то время у меня безусловно крутились мысли насчёт того, чтобы использовать все эти кутришные и дуумтришные материалы. Но в них есть одна очевидная проблема: эти материалы создавались в первую очередь для фиксированного конвейера и пытались собою подменить его функционал. Очевидно, если бы это имело практический смысл, то производители видеокарт не стали бы делать программируемый конвейер и все бы радостно юзали материалы из д3. Но в настоящее время, когда мы имеем возможность программировать конвейер видеокарты, все эти устаревшие концепции только мешают эффективному рендерингу. И кстати очень сильно ограничивают возможности редактирования визуальной части со стороны пользователя (через материалы), но по большей части это довольно сложно понять, т.к. обилие настроек в этих кутришны-дуумтришных материалах по большей части сбивает с толку, кажется что там есть абсолютно всё. На практике куда ни ткнись, кастомизировать не возможно ничего. Ну вот взять простейший пример - интеракция с динамическим светом. Что можно сделать из кутришного шейдера? А ничего. Максимум что можно - это запретить освещение совсем. Поменять модель освещения, сделать какие-то вариации на тему Subsurface Scattering или в случае, если у нас там волосы, глаза, зубы, всё приехали - это только лезть в код и не факт, что это получится сделать красиво, потому что придется эти настройки еще и выводить в эти шейдеры.

В этом плане моя система является полной противоположностью такому подходу. Это Data-Driven концепция, когда пользователь сам полностью формирует этапы рендеринга, а движок лишь выполняет то, что ему задали, не внося никакой отсебятины, не имея дефолтных параметров.
В идеале бы конечно построить такой механизм, когда вся кастомная часть рендера окажется в пользовательских скриптах и шейдерах. Ну и второй момент - это, как выразился thambs - вменяемые дефолты.
Здесь активно используются относительные пути, если мы имеем дело с текстурами и ссылки на другие источники. Большинство материалов уложится в стандартные параметры, описать придётся лишь всякие специальные вещи, типа зеркал, мониторов, но я полагаю это небольшая проблема

Добавлено 21-10-2019 в 21:33:

ЗЫ. Как я уже говорил, лучше всего на этих кутришных шейдерах получается сделать всякие мигалки и бегущие текстуры. Ну собсно, именно их все и делали.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 21-10-2019 в 18:36:

просто в материале прописываешь шейдер, вот и всё

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено XaeroX 21-10-2019 в 19:03:

Цитата:
Дядя Миша писал:
лучше всего на этих кутришных шейдерах получается сделать всякие мигалки и бегущие текстуры.

Можно подумать, от шойдеров ждут что-то ещё?

__________________

xaerox on Vivino


Отправлено Дядя Миша 21-10-2019 в 20:19:

вот в том-то и дело, что не ждут. Привыкли и смерились!

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 21-10-2019 в 20:24:

Цитата:
Дядя Миша писал:
раз молчите

Всё равно пока не попробуешь поработать с живым движком, всё останется набором слов. А меня и вовсе устроил бы простейший шейдер только с диффузкой, но с демоническими тенями.


Отправлено Дядя Миша 21-10-2019 в 21:31:

С новой системой поидее можно будет иметь разные рендереры в разных модах, просто заменяя шейдеры.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 23-10-2019 в 07:28:

Вчера был осуществлён успешный пуск рендерера, который базируется на новых идеях. Data-Driven, как следует из названия потребляет очень много этой самой даты. Надо придумать как бы её ужать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 23-10-2019 в 07:32:

Типа дудосит жесткий диск?

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено XaeroX 23-10-2019 в 13:51:

Цитата:
Дядя Миша писал:
Data-Driven, как следует из названия потребляет очень много этой самой даты.

А Test-Driven потребляет много тестов?

__________________

xaerox on Vivino


Отправлено Дядя Миша 23-10-2019 в 15:04:

Цитата:
FiEctro писал:
Типа дудосит жесткий диск?

Рендер где, всё жестко определено, может использовать условия, как и что ему рендерить. Data-Driven очевидно должен иметь уникальные описания на каждую поверхность. Ну пусть не прям на каждую, но вариантов там немало.

Цитата:
XaeroX писал:
А Test-Driven потребляет много тестов?

Хтоита?

Добавлено 23-10-2019 в 18:04:

Вообще у моего подхода есть один минус - не могу придумать как в материале задавать анимацию текстур. В архитектуру рендерера это не укладывается в любом случае, да еще и с описанием проблемы.
Разумный вариант, это сделать мультислойную текстуру с нужными кадрами, но КМК это не слишком удобно для пользователя.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 23-10-2019 в 15:06:

Цитата:
Дядя Миша писал:
Разумный вариант, это сделать мультислойную текстуру с нужными кадрами

Они будут в динамике генериться? Потому что иначе в слоумо будет треш.


Отправлено Дядя Миша 23-10-2019 в 16:21:

Юзер сам создаст, поидее.

Добавлено 23-10-2019 в 19:21:

Хотя можно и налиту, конечно. Разницы особо нет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 23-10-2019 в 17:15:

Цитата:
Дядя Миша писал:
Юзер сам создаст, поидее.

Рисовать отдельные кадры в фш, вручную скроля картинку?


Отправлено nemyax 23-10-2019 в 17:27:

Дядя Миша
Ты про трансформируемые картинки или про секвенции кадров?


Отправлено Дядя Миша 23-10-2019 в 17:52:

Про секвенции конечно жы. А вы что подумали?

Добавлено 23-10-2019 в 20:52:

А что такое трансформируемая картинка?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 23-10-2019 в 17:57:

Цитата:
Дядя Миша писал:
А что такое трансформируемая картинка?

Ну када крутишь-масштабируешь-скроллишь, как в кутрёх.


Отправлено Дядя Миша 23-10-2019 в 19:43:

А, тю. Ну в моей система это элементарно реализуется прямо в шейдерах.
Все эти крутилки. Единственное что - задавать их придётся конечно не так, как в кутрёх, иной синтаксис. Но тут как бы тоже не всё печально. В моей системе ведь есть макросы! так что можно очень даже близко переопределить всё. Я конечно потом проверю, аж самому интересно стало.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 23-10-2019 в 20:03:

Дядя Миша
Ну матричку наверняка можно скормить. Но ведь её ещё домножать надо до нужного спейса. Хотя смотря как там у тебя.


Отправлено Дядя Миша 23-10-2019 в 21:11:

nemyax ты имеешь в виду задать константную? Да можно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 24-10-2019 в 10:01:

Я тут принял решение отказаться от всех этих кастомных аллокаторов памяти, в настоящее время они практически неактуальны. Простенький лик-детектор еще можно оставить, но не более того. Я тут проанализировал код и понял, что мемпулы у меня используются только при загрузке моделей, а всё остальное прекрасно в деструкторах высвобождается. Ну то есть городить огород нет смысла. Для моделей я мемпулы завернул в класс, там это всегда полезно - посмотреть сколько памяти занимает та или иная модель, а остальное интереса не представляет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 24-10-2019 в 10:30:

Цитата:
Дядя Миша писал:
в настоящее время они практически неактуальны

Для каждой мелочи будешь VirtualAlloc звать из ядра?

__________________

xaerox on Vivino


Отправлено Дядя Миша 24-10-2019 в 10:52:

XaeroX маллок обычный. Вообще-то в CRT есть своя куча. Вот пусть и разбираются там. Я же говорю, после того как все рассчёты переместились на GPU, единственное что неплохо бы кастомизировать это модели.
Кармака понять можно, он для теневых объемов временные буфферы на кадре аллокал постоянно. Конечно ему кастомная куча была нужна.
Сейчас память аллокается только при загрузке, во время работы - нет.
Ну так и смысл городить аггарот?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 24-10-2019 в 11:26:

Цитата:
Дядя Миша писал:
Вот пусть и разбираются там.

Тебе приятно работать с чёрными ящиками? А если там завтра что-то сломают, то ты гордо пожмёшь плечами и скажешь "я ничо не знаю, пишите в суппорт майкрософт"?
Так оно и бывает. Сначала переходят на malloc, потом - на сторонние библиотеки, а там уже и до юнити рукой подать.
Цитата:
Дядя Миша писал:
маллок обычный. Вообще-то в CRT есть своя куча.

Это понятно, но в конечном итоге под виндой всё сводится к системному вызову в VirtualAlloc.

Добавлено 24-10-2019 в 18:26:

Цитата:
Дядя Миша писал:
во время работы - нет.

Во время работы можно кешировать разные промежуточные результаты. Когда куча кастомная - ты всегда знаешь, сколько у тебя свободной памяти, и можешь занимать её под кеш. А потом - если она кому-то понадобилась в обычном аллоке - этот кеш грохать по принципу FIFO.

__________________

xaerox on Vivino


Отправлено Дядя Миша 24-10-2019 в 13:22:

Цитата:
XaeroX писал:
А если там завтра что-то сломают,

Подскажи пожалуйста, ты может знаешь какой-то способ вообще обойтись без маллока? Ну там объявить гигантский статичный массив и черпать память из него, пока не кончится?

Цитата:
XaeroX писал:
Сначала переходят на malloc, потом - на сторонние библиотеки, а там уже и до юнити рукой подать.

ну не надо. Ты имплементацию ZIP сам писал или всё же zlib используешь? Совсем без сторонних библиотек не получится. Вот когда PVS в сторонней библиотеке, это конешно трогедия.

Цитата:
XaeroX писал:
ы всегда знаешь, сколько у тебя свободной памяти, и можешь занимать её под кеш

Твой хитрый план определённо имеет значение, если мы активно выделяем память во время рендеринга. Но если мы этого не делаем, то и смысла нет.

Цитата:
XaeroX писал:
всё сводится к системному вызову в VirtualAlloc

Я к слову почти не видел менеджеров, построенных на вызовах VirtualAlloc, видимо для портабельности. malloc то везде есть.
Ну даже если таковые и существуют, мне неизвестно чтобы они прям хорошо-хорошо работали, пуще прежнего. Конечно мне несложно эту кучу из Doom3 опробовать в деле и я вероятно это сделаю. Но навряд ли будет толк в 2019-м году.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 24-10-2019 в 13:35:

Цитата:
Дядя Миша писал:
Подскажи пожалуйста, ты может знаешь какой-то способ вообще обойтись без маллока?

Нет, вообще без маллока конечно же обойтись нельзя, но можно выделить сразу много страниц, а потом самим ими управлять, а не доверять это библиотеке, в исходниках которой чёрт ногу сломит.
Да не в исходниках дело. Эти маллоки сделаны универсальными, подходящими под любые задачи. Вот пример: multithreaded-CRT содержит примитивы синхронизации, в том числе - при выделении памяти. Зачем нужна синхронизация, если ты точно знаешь, что память у тебя выделяется только в главном потоке?
Цитата:
Дядя Миша писал:
Ты имплементацию ZIP сам писал или всё же zlib используешь?

Я использую её в виде исходного кода, а не либы.
Цитата:
Дядя Миша писал:
Совсем без сторонних библиотек не получится.

Я понимаю - zlib, ogg-vorbis, даже lua какая-нибудь, тут нет смысла изобретать велосипед.
Но есть вещи, над которыми лучше иметь максимальный контроль. Вот память это как раз одна из таких.

__________________

xaerox on Vivino


Отправлено Дядя Миша 24-10-2019 в 13:43:

Цитата:
XaeroX писал:
Вот пример: multithreaded-CRT содержит примитивы синхронизации, в том числе - при выделении памяти. Зачем нужна синхронизация, если ты точно знаешь, что память у тебя выделяется только в главном потоке?

Будет просто замечательно если ты, используя это знание, расскажешь, как ускорить, например rad.

Цитата:
XaeroX писал:
Зачем нужна синхронизация, если ты точно знаешь, что память у тебя выделяется только в главном потоке?

Так я ж и говорю, основная идея втом, чтобы вообще не выделять память во время работы. А если и выделять, то самый минимум, под списки там какие-нибудь.

Цитата:
XaeroX писал:
Но есть вещи, над которыми лучше иметь максимальный контроль. Вот память это как раз одна из таких.

Вы сегодня прямо все расшутились как не знаю кто. В процессоре контролерр памяти и защищенный режим, который тебя никогда не пустит в реальную ячейку физической памяти, а сверху слой абстракции от операционки, которая следит, что ты там навыделял и если что-то не так - кидается исключение, а не виснет весь комп нахрен. И вот в таких вот условиях ты что-то там за максимальный контроль агитируешь?
Ты мне вот скажи навскидку, что ты там такое выделять собрался, что тебе это надо непременно контролировать? Ну скажем, на примере Волатилы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 24-10-2019 в 13:47:

Цитата:
Дядя Миша писал:

Будет просто замечательно если ты, используя это знание, расскажешь, как ускорить, например rad.

Я, признаться, бесконечно был бы RAD
Лечь под этот электронный агрегат,
Чтобы капал самогон мне в VIS
Днём и ночью BSP!
Цитата:
Дядя Миша писал:
Так я ж и говорю, основная идея втом, чтобы вообще не выделять память во время работы.

Ну ты не будешь выделять, а потом придёт Мастер и прикрутит асинхронную загрузку моделей...
Цитата:
Дядя Миша писал:
Ты мне вот скажи навскидку, что ты там такое выделять собрался, что тебе это надо непременно контролировать?

Я уже привёл пример с кэшем. Приведу другой: в том же аллокаторе строк ку3 есть встроенная оптимизация, возвращать пустую строку и строки-цифры из статической памяти, не аллокая их. Т.к. у кваров значения обычно либо пустые, либо 0/1/2, то это позволяет избежать от 20% до 30% аллокаций на куче.

__________________

xaerox on Vivino


Отправлено Дядя Миша 24-10-2019 в 13:53:

Цитата:
XaeroX писал:
а потом придёт Мастер и прикрутит асинхронную загрузку моделей...

для моделей я оставил мемпулы, говорю жеж. Для остального считаю излишним.

Цитата:
XaeroX писал:
в том же аллокаторе строк ку3 есть встроенная оптимизация, возвращать пустую строку и строки-цифры из статической памяти, не аллокая их.

Эта оптимизация порождает очень серъезную проблему в тех же крестах, когда у нас АТД строки и вот представь, что на деструкторе там высвобождается память, а указатель ведёт на эту константную цифру.
И получим Unknown software exception или что-то в этом роде. Но для чистого Си с кучей, вполне норм вариант.

Цитата:
XaeroX писал:
Я уже привёл пример с кэшем

У меня стойкое подозрение, что твои знания по кэшу больше относятся к 90-м и нулевым годам. Но скажем, уже для коры дуба они неактуальны, а для айкора тем более.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 24-10-2019 в 13:59:

Цитата:
Дядя Миша писал:

Эта оптимизация порождает очень серъезную проблему в тех же крестах, когда у нас АТД строки и вот представь, что на деструкторе там высвобождается память, а указатель ведёт на эту константную цифру.

Нет тут неко кой проблемы, кастомный FreeString, который работает в паре с AllocString, эту ситуацию разруливает.
Цитата:
Дядя Миша писал:
Но скажем, уже для коры дуба они неактуальны, а для айкора тем более.

Ну понятно, когда есть гигантский L3, то это не то же самое, как фетчинг из оперативки. Но тем не менее.

__________________

xaerox on Vivino


Отправлено Дядя Миша 24-10-2019 в 14:01:

Я где-то на хабре видел статью вот как раз по архитектуре коры дуба и она полностью мои представления перевернула. Ну точнее привела в соответствие с современным железом.

Добавлено 24-10-2019 в 17:01:

Цитата:
XaeroX писал:
Нет тут неко кой проблемы, кастомный FreeString, который работает в паре с AllocString

ага, это если мы городим фабрику. Ну или как эта херь правильно называется. Но это именно Сишное мышление. Кресты навязывают маленькие локальные АТД.

Добавлено 24-10-2019 в 17:01:

Цитата:
XaeroX писал:
Ну понятно, когда есть гигантский L3

щас вообще существуют процы с L3 менее 16 метров? Мне кажется там уже за сотню перевалило.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 24-10-2019 в 14:02:

Цитата:
Дядя Миша писал:
Кресты навязывают маленькие локальные АТД.

Никто не мешает перегрузить для любого АТД new и delete.

__________________

xaerox on Vivino


Отправлено Дядя Миша 24-10-2019 в 15:23:

Цитата:
XaeroX писал:
Никто не мешает перегрузить для любого АТД new и delete.

Это да, но мне не даёт покоя мысль, почему Кармак это отключил для д3. Сделал и выключил.

Добавлено 24-10-2019 в 18:23:

Вот кстати, говоря возвращясь к той статье на Хабре про устройство современного процессора, там прямо в начале были такие занимательные строчки, что мол опытные программисты, до сих пор имеют о процессорах представление, застывшее на уровне суперскалярной архитектуры первого пня, а то что сейчас стоит у всех в компьютерах, даже С++ на дух не переносит, оно вообще точилось под виртуальные машинки.
Есть над чем задуматься.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 24-10-2019 в 15:30:

Цитата:
Дядя Миша писал:
что мол опытные программисты, до сих пор имеют о процессорах представление, застывшее на уровне суперскалярной архитектуры первого пня

Типичный хабр - "все вокруг дураки, один я умный в белом пальто стою красивый".

__________________

xaerox on Vivino


Отправлено Дядя Миша 24-10-2019 в 15:31:

XaeroX обижаешь. Это был перевод с английского, на Хабре только их и можно читать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 25-10-2019 в 03:43:

Дядя Миша

Цитата:
Для остального считаю излишним.

Звуки?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено XaeroX 25-10-2019 в 05:25:

А где асинхронные модели, там и асинхронные текстуры, так-то.

__________________

xaerox on Vivino


Отправлено Дядя Миша 27-10-2019 в 09:06:

С декалями я придумал вот какую концепцию - декаль будет тоже модель. Ну разумеется не для пользователя, а с точки зрения движка. Мой менеджер моделей в своей концепции позвоялет ссылаться на другую модель, как на родителя. Таким образом парент для модели декалей будет например мир или бмодель. Причём эта модель будет линковаться не к самой модели, а к энтити, чтобы не получилось ситуации, например, когда дубликат одной и той же встроенной модели заодно дублирует и свои декали на ней. Сохранение таких декалей будет происходить через методы, встроенные в саму модель (не только для модели декалей, а вообще для любой модели).
И пользователь сам сможет определить для какой модели надо сохранять декали, а для какой нет. Аналогично для такой модели будет строится и область видимости, как и для брашевой. Это позволит держать рендеринг в юниформе. И для травы будет точно такая же модель со ссылкой на родителя. а шейдеры будут линковаться через хинты mod_decal, mod_grass.
Сам рендеринг при этом принимает максимально однотипный вид - промаркировали видимость для списка и отрисовали всё.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 27-10-2019 в 20:28:

Текущий вариант организации скриптов. Здесь всё рабочее, все условия, параметры. всё рулит процессом. Работать становится всё удобнее, я к примеру добавил освещение на брашы, дописав несколько строчек в shaders.def

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 27-10-2019 в 20:57:

Дядя Миша
А как порядок наложения декаль-моделей будет рулиться?

code:
"duct_flr02a" { #material vent }

А такие штуки можно будет в одну строчку писать?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 27-10-2019 в 21:36:

thambs не, нельзя.

Этож не просто key-value. Если бы ты дальше промотал. то увидел бы вот например такое:

C++ Source Code:
1
"{gratestep3"
2
{
3
#material grate
4
 
5
  AlphaFunc( GL_GREATER, 0.25f );
6
}

Можно вообще всё полностью перегрузить, из того что объявлено в технике\шейдер объекте. Оно нечасто нужно, ну вот скажем зеркала или там видеотекстуры. Вот для таких случаев.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 27-10-2019 в 21:41:

Дядя Миша
Это да, понимаю. Я имел ввиду синтаксический сахар для тривиальных текстур.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 27-10-2019 в 22:51:

thambs когда я закончу препроцессор, ты сможешь использовать макроподстановки для этих целей.

вот типа такого:
#define MATERIAL( tex, mat ) \
tex
{ \
#material mat\
}

ЗЫ, дополнил немного технику бмоделей

C++ Source Code:
1
technique "bmodelSolidLightmapPass"
2
{
3
  vertShader( "glsl/forward/scene_bmodel_vp.glsl" );
4
  fragShader( "glsl/forward/scene_bmodel_fp.glsl" );
5
 
6
  image u_LightMap = "entity->$LightmapTexture";
7
  float u_LightStyleValues[64] = "globals->lightStyles";
8
 
9
#if r_fullbright || !MODEL_HAS_LIGHTMAP
10
#define LIGHTING_FULLBRIGHT
11
#endif
12
 
13
#if r_lightmap == 1
14
#define LIGHTMAP_DEBUG
15
#endif
16
 
17
#if r_lightmap == 2 && MODEL_HAS_DELUXMAP
18
#define LIGHTVEC_DEBUG
19
#endif
20
 
21
  depthMask( GL_TRUE );
22
}

то есть все квары теперь рулят дефайнами именно отсюда. Движок ничего не знает про эти шейдеры, он вообще про них ничего не знает. Всё здесь.

Добавлено 28-10-2019 в 01:42:

Вот примерчег чуть посложнее

C++ Source Code:
#if r_detailtextures && u_DetailMap
#define HAS_DETAIL
#endif

Что проверяется здесь? Во первых, чтобы квар r_detailtextures был установлен в состояние, отличное от нуля. Во вторых юнит u_DetailMap проверяется на заданный путь (причём неважно где вы его задали, в технике, в шейдеробъекте или в самом материале) и только если текстура действительно существует - применяется #define HAS_DETAIL. Т.е. система способна выполнять реальные проверки на валидность пользовательских данных. Ну и с бампом аналогично.

Добавлено 28-10-2019 в 01:46:

Может у кого-то вопрос возникнет, почему это именно препроцессинг. Отвечу, потому что эти условия выполняются только перед компиляцией шейдера. А квары, типа r_lightmap имеют теперь особый флажок FCVAR_RELOAD_SHADERS, который провоцирует ребилд шейдеров у всех моделей. Т.е. проверка идёт именно на этапе сборки. Условия, которые выполняются всё время, очевидно находятся в самих GLSL-шейдерах.
Ну впрочем, функции gl-state тоже часть реального кода, но условий там нету.

Добавлено 28-10-2019 в 01:51:

Кстати говоря, заведомо статичные условия выполняются еще на стадии парсинга всех этих скриптов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 28-10-2019 в 08:53:

Дядя Миша
Я правильно понимаю, что к моделькам уже можно вязать ключ-значения и что они могут передаваться как параметры в шейдер? И для каждой модельки эффект будет зависеть от значений параметров?


Отправлено Дядя Миша 28-10-2019 в 09:40:

nemyax через скрипты да. Вкомпиливать это внутрь модели смысла не вижу. Как тогда редактировать?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 28-10-2019 в 10:29:

А в какой момент изменения значений на модельке прорастают в шейдер?


Отправлено Crystallize 28-10-2019 в 10:38:

Цитата:
Дядя Миша писал:
Может у кого-то вопрос возникнет, почему это именно препроцессинг. Отвечу, потому что эти условия выполняются только перед компиляцией шейдера. А квары, типа r_lightmap имеют теперь особый флажок FCVAR_RELOAD_SHADERS, который провоцирует ребилд шейдеров у всех моделей. Т.е. проверка идёт именно на этапе сборки. Условия, которые выполняются всё время, очевидно находятся в самих GLSL-шейдерах.
Ну впрочем, функции gl-state тоже часть реального кода, но условий там нету.

По-моему ты с ума сойдёшь всё это документировать.
GL_GREATER это научное название альфатеста?


Отправлено Дядя Миша 28-10-2019 в 10:46:

Это операторы словами:
GL_EQUAL ==
GL_NOTEQUAL !=
GL_GREATER >
GL_LESS <
GL_GEQUAL >=
GL_LEQUAL <=

Добавлено 28-10-2019 в 13:46:

Цитата:
Crystallize писал:
По-моему ты с ума сойдёшь всё это документировать.

наоборот. Достаточно понять общие принципы, а дальше сработает экстраполяция.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 30-10-2019 в 15:51:

Ну што, работа идёт потихоньку. С новой скриптовой системой фичи добавлять одно удовольствие. Бамп подключил со спекуляром, за час.
Собсно, справился бы за пять минут, но ведь новые части системы написаны, а еще толком не отлажены. Плюс некоторые уточнения концепции.
Конечно нельзя сказать, что всё гладко. К примеру самая главная проблема отрисовки брашей - она никуда не делась. Надо придумать как оптимизировать это дело. А дело тут вот в чём:
Модель - понятно, загрузил меш, загрузил его индексы и рисуй себе.
С брашами не так. Там конечно можно весь мир засунуть в один вбо, но рисовать-то придётся по видимым фейсам, накапливая их в промежуточном буффере. Это первая проблема, то что нужен такой массив. Вторая проблема, что для того, чтобы сказать драйверу, какие именно сурфейсы рисовать, нам очевидно надо проталкивать индексы по шине каждый кадр.
Их не надо хранить, они всегда производное от surf->firstvertex (можете в ксаш-моде посмотреть), но положение это не спасает. Во первых их надо накопить в массиве. Во вторых их надо загрузить в видеопамять. Хреново вообщем. Пока карты стандартные халфовские это ни на что не влияет. Но взять ту же спонзу или карты рейда, и выходит что мы за кадр проталкиваем порядка 40 тысяч индексов. Конечно не вертексов, конечно это быстрее.
Но всё равно. Там где могло бы быть 2000 фпс, остаётся всего 300-400.
А с лайт-проходами и прочим, падение будет еще сильнее. Плюс это только рендерер. Вообщем имеет место быть мультипликационный эффект падения производительности. Надо придумать что с этим сделать.
Самое очевидное решение - вообще не использовать сложную брашевую архитектуру оставим на усмотрение дизайнерам. Если бы таких карт в природе не было, я бы может и не парился. Но они есть. И с этим надо что-то делать.

Добавлено 30-10-2019 в 18:51:

Из влобных решений - можно попробовать завести VBO для каждого фейса, но чёт мне кажется это плохая идея.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 30-10-2019 в 16:18:

Забить на отсечение брашевых фейсов и рисовать единый вбо? С з препассом, например. Медленно получится?


Отправлено XaeroX 30-10-2019 в 16:37:

ncuxonaT
У меня тут одна знакомая дочь офицера говорила по поводу з-препасса, что... ну ты понял.

__________________

xaerox on Vivino


Отправлено Crystallize 30-10-2019 в 16:49:

BSP геометрию при загрузке конвертить в модель


Отправлено Дядя Миша 30-10-2019 в 17:09:

Цитата:
ncuxonaT писал:
Забить на отсечение брашевых фейсов и рисовать единый вбо? С з препассом, например. Медленно получится?

Забивать не с руки, для колидоров весь смысл именно в отсечении, а для ландшафта проще поставить гигантскую модель. Если бы я хотел забить, я бы сделал движок вообще без брашей. Но так неинтересно.

Цитата:
Crystallize писал:
BSP геометрию при загрузке конвертить в модель

Модели фундаментально отличаются от брашей, если ты еще не понял.
Способом их редактирования. В модели ты берёшь один меш в котором миллионы вертексов и натягиваешь на это ЕДИНУЮ текстуру. Для брашей всё строго наоборот, там ты нарисовал кубек и каждую грань покрасил в свою текстуру. Текстура поменялась - стоп конвейер, перезапуск отрисовки.
Текстуры нельзя склеить в атлас, т.к. они с тайлингом. Текстуры нельзя склеить в 2Д массив, т.к. во первых они все разного размера, во вторых 2д массивы довольно таки тормозны, на удивление, на старом железе. А где то их нет вообще.

Добавлено 30-10-2019 в 20:07:

ЗЫ, биндлесс текстур на старом железе нет тем более.

Добавлено 30-10-2019 в 20:09:

Кстати говоря, насчёт отсечения. Возьмем пресловутый сипульчер. Там примерно триста тысяч фанов. С визом и куллингом, средняя видимость - ну тысяч 18, а то и меньшы. Конечно ежели бы этот сипульчер покрыть одной текстурой, будет очень быстро

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено KiQ 30-10-2019 в 17:17:

Дядя Миша текстуры можно собрать в атлас с GL_NEAR, а фильтрацию делать в шейдере, но это, конечно извращение немножк

__________________
-Brain is dead-


Отправлено nemyax 30-10-2019 в 17:24:

Цитата:
Дядя Миша писал:
В модели ты берёшь один меш в котором миллионы вертексов и натягиваешь на это ЕДИНУЮ текстуру

Никто не заставляет в единую. Хочешь натягиваешь несколько по вкусу. Толку-то объединять, если моделек всё равно много и текстуры на них разные.


Отправлено Crystallize 30-10-2019 в 17:24:

Цитата:
Дядя Миша писал:
Текстуры нельзя склеить в атлас, т.к. они с тайлингом.

нифкурил


Отправлено nemyax 30-10-2019 в 17:29:

Crystallize
Если текстурные координаты за пределами единичного квадратика, то на атласе они бы брали чужие текстуры.


Отправлено Crystallize 30-10-2019 в 17:36:

nemyax А, ну это понятно. Ну при тайлинге отдельно хранимой текстуры рендер же доходит до конца массива пикселей и потом сбрасывает координаты на начало и начинает рисовать следующий тайл той же текстуры. Ну а в атласе значит надо для каждой текстуры хранить границы в которых она находится в атласе, и так же циклиться между ними. Это по идее, в атласах наверное есть заморочка почему это невозможно, или ещёченить.
Это в общем такая фундаментальная проблема что не ждёшь что она ещё где-то не решена.


Отправлено KiQ 30-10-2019 в 17:41:

Crystallize для каждого атласа заводить texture region по количеству изначальных текстур, которые будут клампить оффсет?

__________________
-Brain is dead-


Отправлено Дядя Миша 30-10-2019 в 17:53:

Crystallize это всё было бы хорошо в теории, если бы не существовало пирамидальной фильтрации, анизотропной фильтрации и других страшных слов.

Добавлено 30-10-2019 в 20:53:

Цитата:
KiQ писал:
а фильтрацию делать в шейдере

пирмаидалку вручную делать? нафиг-нафиг. Сам бы попробовал штоли.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено KiQ 30-10-2019 в 18:14:

Ну так а это, сортировать видимые фейсы в текстурные списки?

__________________
-Brain is dead-


Отправлено Дядя Миша 30-10-2019 в 20:42:

Первые эксперименты по оптимизации.
Чёт какой-то COF получился.

Добавлено 30-10-2019 в 22:01:

Цитата:
KiQ писал:
видимые фейсы в текстурные списки?

что такое текстурные списки?

Добавлено 30-10-2019 в 23:34:

Вообще я подозреваю, мне просто нужно что-то из функционала GL посвежее. Я попробовал так же через glDrawArrays рисовать, ему индексов вообще не нужно. Но это deprecated по идее. Да и не всегда оно быстрее.

Добавлено 30-10-2019 в 23:42:

Гм. Похоже всё еще хуже. glDrawArrays просто экономит время, которое я трачу на генерацию индексов на CPU. И при сравнении оказалось, что это весьма незначительная часть процесса. Настолько незначительная, что разница даже в дебаге минимальна. Ну она есть конечно, скажем в релизе там 1100 фпс, а в дебаге 1030 фпс. Но и только.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено KiQ 30-10-2019 в 20:54:

Вообще по сути с текущим пайплайном, как я его понял, проблема не только в текстурах, ведь одна текстура может шариться на несколько материалов, например, а значит конвейер будет тормозиться уже не на смене текстуры, а на переключении шейдера

__________________
-Brain is dead-


Отправлено Дядя Миша 30-10-2019 в 22:55:

ну текстура, материал, неважно. Понятно же что речь идёт об уникальном объекте. Пока не было шейдеров, в их роли выступали текстуры.
Список фейсов хитро отсортирован, чтобы минимизировать все переключения, так что этот фактор не влияет.
Вообщем я опробовал сравнительно свежий glMultiDrawElementsBaseVertex
и древний glMultiDrawArrays. И вот последний в моём случае дал наилучший результат. В принципе, когда у тебя вот такие вот три-фаны, их наверное и правда лучше рисовать совсем без индексов - быстрее будет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено KiQ 30-10-2019 в 23:52:

Дядя Миша вайрфрейм бы интересно глянуть, как оно разбивается

__________________
-Brain is dead-


Отправлено Дядя Миша 31-10-2019 в 14:18:

Поскольку текстура потенциально может грузиться из разных мест, добавил в скрипт функцию addImageLocation. Конечно при нормальной разработке игры, это ненужно, но для моей отладки, когда у меня тут зоопарк из разных карт, в том числе и кутришных, это может оказаться полезным.
Через этот же механизм реализуется и дефолтная текстура, которую можно задать, если ничего не нашлось. Для бампа, например можно сделать чёб он поискал текстуры с разными суффиксами, ну там _gloss, _spec понятно.
Для диффузки - в ваде, в папке textures и так далее. Эти пути конечно тожы можно перегружать раздельно для шейдер объекта, для материала и для техники и заключать в условия.

Добавлено 31-10-2019 в 17:18:

Вчера ради интереса поглядел как это устроено в старом Unigine - там очень похожая схема, ну просто очень. Точнее не схема, а концепция, там тоже есть обозначенные типы проходов - амбиент, разные типы лайтов, отложка, постпроцесс. Но там довольно много встроенных параметров, у меня нет вообще. Полностью настраиваемый конвейер.
Для полного щастья осталось добавить команду cvar, которая будет регистрировать квары, например из game.rc и можно создавать различные рендереры, вообще не затрагивая код.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 31-10-2019 в 15:15:

Цитата:
Дядя Миша писал:
например из game.rc и можно создавать различные рендереры, вообще не затрагивая код.

DX11-рендерер можно будет добавить через game.rc?

__________________

xaerox on Vivino


Отправлено Дядя Миша 31-10-2019 в 15:18:

XaeroX DX не нужен

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 31-10-2019 в 22:35:

С китайскими детайлами одна беда - они сделаны для сохранения совместимости, поэтому кол-во производимых лифов просто зашкаливает.
Сами понимаете, проверять десятки тысяч лифов на каком-нибудь сепульчере дорогостоящее удовольствие. Можно конечно пойти простым путём как Ксерокс, прикрутить кутришные карты. Но так неинтересно.
Тут всё дело в том, что у нас есть необходимая информация, чтобы из общей кучи лифов и нодов восстановить дерево без детайлов. Ну точнее говоря, смержить все детайл-лифы обратно в один, и ноды подсократить. Насколько их меньше? ну скажем на Edge Of Forever 145 тысяч лифов, а реальных, которые отвечают за видимость около двух тысяч (кстати даже меньше чем в ку3). Лифы, первый в списке это основной, остальные с таким же оффсетом виздаты - детальные. Ну и руководствуясь этой информацией, как вы понимаете, идя, обратно по родителю лифа, можно найти детальные ноды и построить новое дерево. Правда оно не годится для трассировки например, только для видимости. так что старое тоже останется.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 31-10-2019 в 22:38:

Дядя Миша
А от разрезаний всего и вся и щелей это поможет?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 01-11-2019 в 09:10:

Ну кто о чём

Добавлено 01-11-2019 в 12:10:

Мне это напоминает, как какой-то чувак увидел в хидерах vgui какой-то класс SurfaceGL и тут же решил что это мониторы из третьего дуума. Ну ему просто очень хотелось, чтобы они там оказались.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 01-11-2019 в 14:47:

Дядя Миша Та не о чём, а о том что больше всего беспокоит в истории с дизайном карт.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 01-11-2019 в 16:54:

Цитата:
thambs писал:
а о том что больше всего беспокоит

В итоге все сошлись на том, что Черноморск в ближайшее время непременно будет объявлен вольным городом!

Када на карте 15 фпс, при 4 тысячах полигонах в кадре, щели отходят на второй план.

Добавлено 01-11-2019 в 19:54:

Первые результаты уже кстати есть. Но я помоему где-то налажал. Ну неудивительно, такого дерева еще никто не строил.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 01-11-2019 в 17:14:

Так всё-таки 4 тысячи полигонов а не 4 миллиона, правильно?


Отправлено Дядя Миша 01-11-2019 в 21:04:

Crystallize да. Построил новое дерево. Ну неплохо, на сипульчере 200 фпс, на Edge Of Forever 300. Теперь надо выкинуть лишние ноды из дерева.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено SNMetamorph 02-11-2019 в 03:33:

Цитата:
Дядя Миша писал:
Ну што, работа идёт потихоньку. С новой скриптовой системой фичи добавлять одно удовольствие. Бамп подключил со спекуляром, за час.
Собсно, справился бы за пять минут, но ведь новые части системы написаны, а еще толком не отлажены. Плюс некоторые уточнения концепции.
Конечно нельзя сказать, что всё гладко. К примеру самая главная проблема отрисовки брашей - она никуда не делась. Надо придумать как оптимизировать это дело. А дело тут вот в чём:
Модель - понятно, загрузил меш, загрузил его индексы и рисуй себе.
С брашами не так. Там конечно можно весь мир засунуть в один вбо, но рисовать-то придётся по видимым фейсам, накапливая их в промежуточном буффере. Это первая проблема, то что нужен такой массив. Вторая проблема, что для того, чтобы сказать драйверу, какие именно сурфейсы рисовать, нам очевидно надо проталкивать индексы по шине каждый кадр.
Их не надо хранить, они всегда производное от surf->firstvertex (можете в ксаш-моде посмотреть), но положение это не спасает. Во первых их надо накопить в массиве. Во вторых их надо загрузить в видеопамять. Хреново вообщем. Пока карты стандартные халфовские это ни на что не влияет. Но взять ту же спонзу или карты рейда, и выходит что мы за кадр проталкиваем порядка 40 тысяч индексов. Конечно не вертексов, конечно это быстрее.
Но всё равно. Там где могло бы быть 2000 фпс, остаётся всего 300-400.
А с лайт-проходами и прочим, падение будет еще сильнее. Плюс это только рендерер. Вообщем имеет место быть мультипликационный эффект падения производительности. Надо придумать что с этим сделать.
Самое очевидное решение - вообще не использовать сложную брашевую архитектуру оставим на усмотрение дизайнерам. Если бы таких карт в природе не было, я бы может и не парился. Но они есть. И с этим надо что-то делать.

Добавлено 30-10-2019 в 18:51:

Из влобных решений - можно попробовать завести VBO для каждого фейса, но чёт мне кажется это плохая идея.


О, круто. Это решение потом можно будет и в ксашмод перетянуть.
З.Ы: Не эту идею с кучкой VBO, конечно же.


Отправлено Дядя Миша 02-11-2019 в 07:57:

Там от оптимальности дерева куда больше зависит, чем от остального.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 02-11-2019 в 13:05:

Цитата:
Дядя Миша писал:
на сипульчере 200 фпс

сколько раньше было?


Отправлено Дядя Миша 02-11-2019 в 14:38:

Ну собсно, первые валидные результаты, для Edge Of Forever

Цитата:

LoadLeafs: time: 2.430553 secs
node tree optimized by 3 iterations
source 162224 nodes, optimized tree 3757 nodes
source 145323 leafs, optimized tree 2235 leafs
LoadNodes: time: 0.302457 secs

Оптимизед три - это вот как раз виз три. Карту с таким кол-вом нодов и лифов найти практически нереально, даже на сипульчере меньше.

Цитата:
Crystallize писал:
сколько раньше было?

15.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 02-11-2019 в 15:18:

Цитата:
Дядя Миша писал:
15.

Я имею в виду, если сепульчер запустить под Xash3D.


Отправлено Дядя Миша 02-11-2019 в 17:56:

Vis Tree, что это и для чего нужно

Ну чтожы, давайте немного расскажу о том, что это вообще такое, откуда взялось, почему не было раньшы. Бинарные деревья (хотя навряд ли только они), имеют следующую особенность - их построение привязывается к конкретной задаче. То есть нельзя построить идеальное дерево для всего сразу, но можно для одних и тех же данных построить несколько деревьев и каждое будет оптимально для своих задач. Собственно, поэтому и клипноды - оптимизированное дерево для коллизии. С видимостью всё не так однозначно. После первой кваки, Кармак решил не хранить более одного дерева на модель. В ку2 это привело к проблемам - на ноды пришлось класть брашы, дерево получилось неоптимальным, переусложнённым. Настолько неоптимальным, что для рассчёта видимости, компилятор создаёт новое дерево, игнорируя детальные и мелкие лифы. Но в ку2 нет явной привязки виздаты к лифам - там промежуточные индексы, которые называются кластерами. В ку3 дерево еще более общее. Если быть точным, оно ни для чего. Для коллизии оно слишком поверхностное, кмк регулярная сетка была бы куда более оптимальна. Для точечной трассы - аналогично, оно не включает в себя например плоскости патчей, трисурф-моделей, это надо трейсить отдельно. Еще и проверяя, что в этом лифе мы уже трейсили (это особенно интересно выполнять при мультипоточных рассчётах). Единственное для чего кутришное дерево оптимально - это для видимости. В моду уже входили графические ускорители, риваТНТ опять же. И вот с их учётом дерево и было построено. А для первой кваки остался самый неоптимальный вариант на текущий момент. Рассмотрим это подробнее.

В первой кваке\первой халфе, как известно нет функ_детайла, нет ареапорталов и прочего. Дерево там в первую очередь устроено для максимальной оптимизации коллизии. А небольшой размер дерева получался автоматически - квака не блистала детализаций в 95-м году, сами понимаете. Но время шло, карты становились всё навороченней и вот то самое дерево, которое идеально подходило для колоизации, выступило ключевым тормозом перестройки для проверки видимости.
По очень простой причине - чем больше детализация, тем больше лифов и нодов, чем больше лифов и нодов, там дольше обходить дерево. Возникала ситуация, когда проверка на видимость в десятки раз дольше, чем, собственно отрисовка. Вот кстати, что касается, сипульчера, спонзы и прочих подобных карт. Китаец и автор TyrUtils, понимали проблему, поэтому попытались ввести детайл-брашы для первого квейка\халфы. Но проблему это решило только наполовину и вот почему: оптимальное дерево существовало только для виза и здорово сокращало время его рассчётов, вплоть до того, что карта, которая могбы считаться часов 30, теперь считалась пару минут. Но для сохранения совместимости с форматом халфы\кваки, им в любом случае пришлось нагенерить дополнительных нодов-лифов для того чтобы описать все эти детальные брашы, чтобы движок смог их отрисовать. Причём нельзя даже сказать, что они вообще не нужны - ведь они же еще и для коллизии используются. Тот же рад, например тени по ним считает. Но считать видимость по такому дереву нельзя категорически. Вот у того же Edge Of Forever, скомпиленного в формат условной первохалфы, получается 136 тысяч лифов. Даже если просто пробежать их в цикле - ну можете подсчитать сколько времени это займет. Далее, видимые лифы копятся для энтить для быстрой проверки видимости. Ну кто движок ковырял тот знает. А если лифов через чур много, то вместо них делается проверка видимости по хеадноде. Вы никогда не задумывались сколько времени занимает такая вот проверка? Я не считал точно сколько там энтить каждый кадр её запрашивают, но всего на карте 386 энтить. Ну пусть половина. Этот запрос на проверку видимости, отнимает по времени 0.07 секунд!!!!! Рендер, к примеру управляется на два порядка быстрее. То есть получается идиотизм. Вроде бы и детайлы есть и виз оптимизированный. А фпс всё хуже и хуже. К слову говоря старый Кармаковский код с поиском лифов через родителя ноды в данной ситуации чувствует себя чуть получше. Но и только. Конечно это всё неюзабельно, как вы понимаете. Как же поступить в данной ситуации? Какие варианты у меня были?

Добавлено 02-11-2019 в 20:56:

самый "простой" метод, который у меня был, как вы понимаете - это взять формат карт из Quake3. После всего что я сделал для халфовского формата, научил его считать лайтмапы на моделях, повертексное и еще массу других интересных вещей, взять дропуть и прикрутить кутришный формат, как в Волатиле. Ну не скрою, текущая архитектура XashNT позволяет его прикрутитьЮ не затрагивая другие подсистемы. Но сами особенности формата могут доставить немало весёлых минут мапперам, если я им потенциально предложу на него перейти. Напомню, что я даже патчи и трисурфы имплементировал в халфовский формат. Как говорится - последний довод за кутришный, который мне всегда приводили в пример.
Ну вообщем с учётом вышесказанного я решил, что мне нужно не маяться дурью прикручивая к движку разные там форматы карт, этим хорошо заниматься, когда ты учишься, и попытаться решить проблему более элегантным способом. Например построить такое специальное дерево для видимости. Как это сделать? Компиляторы, учитывющие детайлы в картах делают одну оптимизацию - для детальных лифов пишется тот же самый оффсет виздаты, что и для главного лифа, из которого они наследуются. Второй момент - они обычно не раскиданы по карте вперемежку, а идут группой подряд. Собсно это второе больше влияет на возможности оптимизации по скорости построения нового дерева, а не на какую-то принципиальную невозможность. Главное же условие, я назвал - совпадающие оффсеты у виздаты. Итак, по этим оффсетам мы находим настоящие визлифы, их кол-во и создаём новый массив с визлифами, аккумулируя в один лиф всё из детальных. Аналогично из обычных нодов создаётся массив визнодов. Здесь над подстерегает одна нехорошая проблема - во первых эти ноды раньше ссылались на детальные лифы, а теперь на одни и те же номера обычных лифов, которыми мы их подменили. Это не фатально, но провоцирует дубликат в BoxLeafnums, что в свою очередь быстро приводит к их переполнению в массивах энтить и снова здравствуй поиск по хеадноде, а поскольку визнодов столько же, сколько было в исходном массиве, никакой оптимизации считайте и не было - только память зря израсходовали. То есть моя основная задача, которую я решал последние два дня - как эффективно выкинуть эти лишние ноды и при этом не поломать дерево и чтобы это было быстро (поскольку делается во время загрузки уровня). Ну собно, немного статистики я привёл выше. Edge Of Forever с виздеревом теперь выдаёт вместо 15 фпс, около 500. У спонзы тоже фпс очень вырос.
ну и разумеется в моде рейда произойдут аналогичные позитивные улучшения.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 02-11-2019 в 18:45:

Цитата:
Дядя Миша писал:
После всего что я сделал для халфовского формата, научил его считать лайтмапы на моделях, повертексное и еще массу других интересных вещей, взять дропуть и прикрутить кутришный формат, как в Волатиле.

А что тебя смущает, это самое логичное решение. Я эту иррунду с лифами и нодами, в которых непременно должны лежать все сурфасы, быстро просёк и даже не стал пытаться использовать. Оно полезно разве что для софтварного рендера.
Что касается "после всего что сделал" - ну я тоже когда-то сделал в волатиле кучу всяких интересных оптимизаций для шадов-волюмов, а ты говорил - не жалей, выбрасывай, ну неактуальны уже эти волюмы. И вот однажды я выбросил и не жалею.

__________________

xaerox on Vivino


Отправлено Дядя Миша 02-11-2019 в 20:13:

Цитата:
XaeroX писал:
Оно полезно разве что для софтварного рендера.

Оно полезно для точечной трассы в первую очередь.

Цитата:
XaeroX писал:
ну я тоже когда-то сделал в волатиле кучу всяких интересных оптимизаций для шадов-волюмов

Вот ежели бы ты научил волюмы кастовать тени от альфа-текстур - их реально было бы жалко выбрасывать.

Добавлено 02-11-2019 в 22:09:

Вообще я планирую кутришный формат прикрутить, в рамках теста. Ну интересно жеж. Ну то потом когда-нибудь.

Добавлено 02-11-2019 в 23:13:

Хым. Оказывается я случайно нашёл возможность оптимизировать любое дерево, не только содержащее детайл-ноды. Можно выкинуть из дерева ссылку на общий нулевой лиф и за счёт этого сократить его размер. Ссылка на этот лиф всё равно нахрен не нужна для визтри. А для наружки достаточно сделать PointInLeaf увидеть что кластер == -1 и включить полную видимость.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 02-11-2019 в 20:17:

Дядя Миша
Ничего не понял, но как всё таки с т.з. левел-дизайнера результирующие полигоны будут выглядеть на неаксиальной геометрии?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 02-11-2019 в 21:01:

Цитата:
thambs писал:
результирующие полигоны будут выглядеть на неаксиальной геометрии

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 03-11-2019 в 07:11:

Компилятор уровней в формат XashNT всё так же будет резать браши через определённые промежутки, пусть и не такие большие?


Отправлено Дядя Миша 03-11-2019 в 07:26:

Crystallize лайтмапы-то большие, можно практически не резать.
Во всяком случае это лучше, чем пытаться уменьшить лайтмапу, как ку3 делает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 03-11-2019 в 07:29:

Дядя Миша
В ку3 ты можешь сам порезать большие браши в Джеке, где надо.

__________________

xaerox on Vivino


Отправлено Дядя Миша 03-11-2019 в 07:36:

Очевидно в джеке можно порезать брашы для любой карты

Я кстати понял, откуда взялась внезапная оптимизация дерева даже для тех карт, где нет никаких детайлов.

C++ Source Code:
1
for( i = 0, data = g_uncompressed; i < leafnum; i++, data += g_bitbytes )
2
{
3
  if( !memcmp( data, outbuffer2, g_bitbytes ))
4
  {
5
    g_dleafs[g_leafstarts[leafnum]+1].visofs = g_dleafs[i+1].visofs;
6
    c_reused++;
7
    return;
8
  }
9
}

От оно. У меня же виз по возможности идентичные векторы выбрасывает для экономии места. Хотя это и не совсем корректно по идее - использовать это как условие для идентичных лифов, придётся пересмотреть немного этот механизм.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 03-11-2019 в 07:40:

Цитата:
Дядя Миша писал:
Очевидно в джеке можно порезать брашы для любой карты

Угу, но халфовские компиляторы всё склеят обратно и порежут так, как им нравится. А ку3шные - уважают право маппера решать, как и что должно быть порезано.
Цитата:
Дядя Миша писал:
У меня же виз по возможности идентичные векторы выбрасывает для экономии места.

Это ещё одна умная оптимизация, от которой мало толку на ку3шном дереве с малым числом кластеров?

__________________

xaerox on Vivino


Отправлено Дядя Миша 03-11-2019 в 11:02:

Цитата:
XaeroX писал:
Угу, но халфовские компиляторы всё склеят обратно и порежут так, как им нравится

Халфовские порежут, а мои не порежут.

С этим виздеревом всё не так однозначно вообщем. Можно использовать один накопительный проход, это очень быстро, практически незаметно.
А можно использовать поиск по лифам NxN, но с прямым продвижением, я чёрт его знает как это правильно называется, не силён в терминологии.
Ну вообщем цикл вида
C++ Source Code:
1
for( int i = 0; i < numleafs; i++ )
2
{
3
  for( int j = i + 1; j < numleafs; j++ )
4
  {
5
  }
6
}

Это дешевле чем настоящий NxN. Но и дерево для первого случая получается менее оптимальным, результаты для быстрого построения
Цитата:

LoadLeafs: time: 0.100575 secs
node tree optimized by 3 iterations
source 162224 nodes, optimized tree 3757 nodes
source 138415 leafs, optimized tree 2235 leafs
LoadNodes: time: 0.291052 secs

Результаты для глубокой аналитики от Ozzy
Цитата:

LoadLeafs: time: 2.419452 secs
node tree optimized by 3 iterations
source 162224 nodes, optimized tree 3757 nodes
source 138415 leafs, optimized tree 2235 leafs
LoadNodes: time: 0.291097 secs

На первый взгляд кажется, что один хрен. Но в игре, быстрое построение даёт 400 фпс, а медленное - 470 фпс. Так же на некоторых картах кол-во лифов для визтри может увеличиться при быстром построении, что тоже может сказаться на итоговом фпс. Здесь есть еще одна проблема - дублирующиеся лифы. Для поиска по дереву это не играет никакой роли, т.к. найденные сурфейсы всё равно помечаются единожды. Но это имеет значение для BoxLeafnums, куда попадают одинаковые лифы. Само по себе это не проблема тоже. Проблема в том, что этих лифов, как вы помните на энтитю не может быть более 48. А потом начинается тежолый поиск по головной ноде, хотя он теперь и происходит по визтри, это всё равно нежелательный кейс. Ну собсно, я пока что сделал проверку при сохранении лифов в энтить, чёб добавляло лишь уникальные. А потом надо подумать, возможно заменить фиксированный массив на деномический. Но гораздо важнее разобраться насколько вообще допустимы эти дублирующиеся лифы. На первый взгляд всё отлично, фпс сильно вырос, видимость корректно считается. Но тут необходимо провести серию юнит-тестов.

Цитата:
XaeroX писал:
Это ещё одна умная оптимизация, от которой мало толку на ку3шном дереве с малым числом кластеров?

Дерево само-по себе не самоцель. Оптимальнее иметь несколько деревьев для своих задач. Так вот кутришное толком не годится ни для чего. Оно только для видимости. Физика по нему настолько неоптимально считается, что я вот просто уверен, что если его заменить на AABB, станет быстрее. Кстати попробуй.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 03-11-2019 в 12:05:

Цитата:
Дядя Миша писал:
Физика по нему настолько неоптимально считается, что я вот просто уверен, что если его заменить на AABB, станет быстрее.

Быстрее на 0.00001 сек? Колоизация это последнее, что может тормозить на ку3шном дереве. Куда важнее дерево, которое использует физдвиг для динамической симуляции. Но там своё.

__________________

xaerox on Vivino


Отправлено Дядя Миша 03-11-2019 в 14:06:

Вот вам для понимания картинка виздерева, циферками обозначены номера лифов. Красной циферкой - аутсайд лиф, общий. Как видите тут очень много ссылок на второй номер лифа виздерева. В реальном дереве там конечно был какой-то свой уникальный лиф, но это неважно, потому что у всех этих уникальных лифов была ссылка на один и тот же указатель виздаты. Мой оптимизатор дерева исходит из очевидных предпосылок - если у ноды ссылки на детей оканчиваются одним и тем же лифом - такую ноду можно выкинуть. Если у ноды дальше по дереву всего два уникальных лифа, причём один из них общий, то такую ноду тоже можно безболезненно выкинуть, оставив только ссылку на ненулевой лиф. Почему - понятно, этож дерево видимости, за пределами уровня, оно всё равно значения не имеет, так что на его целостность это не влияет. Но вот иногда бывают такие мерзкие случаи как накартинке. С которыми я решительно не знаю чего делать. Да и нужно ли с ними что-то делать вообще. Время покажет.

Добавлено 03-11-2019 в 15:18:

Результаты для быстрого построения визтри и для медленного.

Конечно далеко не на каждой карте такая разница большая.

Добавлено 03-11-2019 в 17:06:

У меня тут еще появилось вот какое соображение. Дубликаты проявились только на картах, собранных промежуточной версией p2st. Возможно там что-то неоптимальное было. Надо будет пересобрать и проверить заново.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 03-11-2019 в 14:11:

А почему для всех задач деревья, то такие то сякие? Не может ли статься, что где-то больше подойдёт какая-нибудь хеш-табличка ну или там я не знаю?


Отправлено thambs 03-11-2019 в 14:15:

Дядя Миша

Цитата:

Ну плане, какие фэйсы получаются из брашей, сформированных из не-аксиально ориентированных плоскостей. Помнишь вот те гнутые тоннели у меня на карте и сколько с ними проблем было (а часть до сих пор осталась), как оно с новым подходом? Мне ведь чому кутришный формат симпатичен -- в силу его предсказуемости: как в джеке браши порежу, так и буду уверен что в игре оно будет идентично (а если уж алгоритм всё таки слажает, то детайл спасёт). А в случае с хлбсп -- половина времени уходит на поиск компромисного варианта, на котором не будет микрофэйсов и дырявых клипнод.
Цитата:
https://hlfx.ru/forum/attachment.php?action=preview&s=&postid=185759

А что циморки значат?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 03-11-2019 в 14:54:

Цитата:
nemyax писал:
А почему для всех задач деревья, то такие то сякие?

там где деревья не нужны, там обычно и апсуждать-то нечего. А дерево, его же можно повсякому построить.

Цитата:
nemyax писал:
где-то больше подойдёт какая-нибудь хеш-табличка

Полным-полно таких мест, но чо там аспуждать-то?

Цитата:
thambs писал:
Мне ведь чому кутришный формат симпатичен -- в силу его предсказуемости

Так ить режет-то CSG, а его можно выключить. Отправил проблемное место в func_group и выставил там zhlt_nocsg 1, всё.

Цитата:
thambs писал:
А что циморки значат?

Цитата:
Дядя Миша писал:
Вот вам для понимания картинка виздерева, циферками обозначены номера лифов. Красной циферкой - аутсайд лиф, общий

вы и с Гулем так же дискуссию ведете?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 03-11-2019 в 15:11:

Цитата:
Дядя Миша писал:
выставил там zhlt_nocsg 1, всё.

Та бсп-ж её корёжит. Вот тут nocsg=1, а тем не менее всё равно микрофэйсы есть, и чем геометрия сложнее, тем эта проблема острее вылезает*. В результате, в джеке всё выглядит ок, а в игре потом приходится эти места запоминать, переделывать, проверять, снова переделывать и пр. Ты-ж не представляешь даже насколько это отнимает время и силы при создании карты. Не говоря уже о времени компиляции**.


*гротто2 так вообще проще снуля будет сделать, видимо -- моделью.
**гротто2, если память не отшибло, минут 40 собирается (бсп+виз), на кутришном -- 2-4 минуты вместе с освещением.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 03-11-2019 в 16:20:

Цитата:
thambs писал:
Ты-ж не представляешь даже насколько это отнимает время и силы при создании карты

ну почему это не представляю? очень даже хорошо представляю.

Цитата:
thambs писал:
Та бсп-ж её корёжит

бсп может ну максимум некоторые микрофейсы выбросить поидее. Ну что еще?

Добавлено 03-11-2019 в 19:20:

Цитата:
thambs писал:
на кутришном -- 2-4 минуты вместе с освещением

да там такое асвищенее, лучшеб его не было.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 03-11-2019 в 18:50:

Цитата:
ну почему это не представляю? очень даже хорошо представляю.

Это ведь ещё на самом деле приводит к тому, что приходится очень заморачиваться над неаксиальными конструкциями, задумываться как бы так изловчиться, сколько граней делать, с хинтбрашами эксперементировать. Т.е. создаёт огромное количество совершенно бестолковой экспериментальной активности призванной как-то скомпенсировать принципиальные недостатки алгоритма с помощью ручного тюнинга, вместо, собственно художественного процесса.

Цитата:
бсп может ну максимум некоторые микрофейсы выбросить поидее. Ну что еще?

Ну разрезы же делает он? Выкидывание да, это ещё одна головная боль -- приходится осматривать карту, а потом долго и упорно пытаться найти такую конфигурацию, где их не будет. p2st выкидывает меньше конечно, но там тоже проблема бывает, когда все эти микробраши оказываются очень тонкими, то на них лайтмэпа плохо ложиться, ну и клипноды лажают -- то дыра, то застревание. Ну и опять же, чем сложнее конструкция -- тем всё это сильнее вылезать начинает.

Цитата:
да там такое асвищенее, лучшеб его не было.

Ну не настолько прямо что совсем плохое, хотя грязи немного есть, да. А с чем вот эта плохость, кстати, связана? Я помню, что там дело, вроде, в трассе, но это какое-то принципиальное ограничение, или возможно ли это качество улучшить пусть даже если время расчёта финального освещения возрастёт раз в 10?

Но вот то что подбор оптимальной геометрии и bsp+vis компиляция растягиваются -- это очень нехорошо, на самом деле, особенно, с увеличением размера карты. Если для черновой компиляции можно было-бы посчитать освещение уровня даже хуже чем ку3, а для финальной оставить компилироваться на пару-тройку часов -- это было бы удобней, по моему.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 03-11-2019 в 20:23:

Цитата:
thambs писал:
А с чем вот эта плохость, кстати, связана?

там вообще нет индиректа. Констант амбиент + директ.

Цитата:
thambs писал:
возможно ли это качество улучшить

ну надо новый компилятор написать. Я еще в прошлом году его начал делать. Лежит пока. Ждёт своего часа.

Цитата:
thambs писал:
Ну разрезы же делает он?

Ну дык понятно, это ж потом дерево для точечной трассы используется. Конечно рубит. В кутри, там просто в лиф натолкал и всё.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 04-11-2019 в 08:17:

Я вот что понять-то не могу. Вот взять сипульчер. Ну хорошо может там не прямо сложная геометрия. Но всё компилится, микродырок нет. Что родными компиляторами, что моими. Далее. Не скажу за p2st, но XashNT Tools прекрасно собирают родные кутришные карты - q3dm1, q3dm7. Со светом. Опять таки - некоких дырок, выпадающих полигонов там нет и близко. Достаточно простые карты? Ну хорошо Edge Of Forever достаточно сложная? А там снова идеальный результат. Но почему-то у Тхамбса проблемы на простейших скруглённых тоннелях вылезают, я этого решительно не могу понять. Гротто - там да, неисключено, такое вообще никто не рисковал компилировать в BSP. Но чтобы тоннели?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 04-11-2019 в 11:20:

Цитата:
Дядя Миша писал:
Гротто - там да, неисключено, такое вообще никто не рисковал компилировать в BSP. Но чтобы тоннели?

Ты говорил что и Сепульчер, и карты в Ку3 все держатся в рамках кубика +-8192 юнита, и что q3map2 за этими пределами начинает дивным образом плющить. Может в этом проблем и thambs где-то на границе сетки мапает?


Отправлено Дядя Миша 04-11-2019 в 12:34:

Ну точность флоата как бы никто не отменял, это правда. Но во первых в компиляторе даблы, а во вторых точность сохраняется до диапазона +\- 16384 примерно. Если гротто выходит за рамки, там возможны какие-то проблемы с генерацией порталов, да собсно всё упирается в эти долбаные порталы, там ОЧЕНЬ важна точность. Альтернатива вам хорошо известна - вручную расставлять окклюдеры у каждого дверного проёма.

Так, ну штож. С брашами подразобрались, настала очередь моделей. Может показаться, что я просто беру и копироваю код из паранои, но параноя писалась с учётом особенностей Xash3D, многие вещи нуждаются в переработке, можно сделать гораздо оптимальнее. Да и вообще в халфе эта дурь с сетапом костей в рендерере очень сильно вставляет палки в колёса. Вот зачем рендереру заниматься сетапом костей? Зачем ему вообще это нужно? Ему это никак не нужно. Ему просто надо получить кости из энтити и всё.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 04-11-2019 в 13:07:

Я правильно понял из вашей беседы, что в ку3 компилятор на нарезает геометрию на куски как, например, на скриншоте Тхамбса (обратите внимание на тоненькую полосочку, отрезанную от прямоугольного фейса на стене)? При этом там нормально строится и работает бсп-дерево и всё такое?


Отправлено Дядя Миша 04-11-2019 в 13:17:

Не нарезает, да. Но и использовать такое дерево для трассировки уже проблематично. Только для видимости.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 04-11-2019 в 13:28:

Выходит, вся эта канитель с кучей лишних треугольников, микрофейсами, корявой геометрией и швами нужна только чтобы трассу легко строить по дереву? При условии, что Кармак справился с этим 20 лет назад?


Отправлено Crystallize 04-11-2019 в 13:38:

Цитата:
Дядя Миша писал:
Но почему-то у Тхамбса проблемы на простейших скруглённых тоннелях вылезают, я этого решительно не могу понять.

Т.е. скруглённый тоннель из world-брашей как у thambs должен переезжать в игру 1-в-1 без всяких дополнительных разбиений типа тех что мы видим на картинке?


Отправлено Дядя Миша 04-11-2019 в 14:18:

Цитата:
ncuxonaT писал:
Выходит, вся эта канитель с кучей лишних треугольников, микрофейсами, корявой геометрией и швами нужна только чтобы трассу легко строить по дереву?

Ты на трассу не гони. Эта трасса быстрее любого специализированного рейтрейсера. Может даже вообще самая быстрая в мире.

Цитата:
ncuxonaT писал:
При условии, что Кармак справился с этим 20 лет назад?

Справился с чем именно? Построить такое дерево как в кутри напорядок легче чем такое как в ку1. А можно и вообще ничего не строить. А можно рисовать всю модельку разом. Прямо как в Юнити.

Добавлено 04-11-2019 в 17:18:

Цитата:
Crystallize писал:
Т.е. скруглённый тоннель из world-брашей как у thambs должен переезжать в игру 1-в-1 без всяких дополнительных разбиений типа тех что мы видим на картинке?

Я решительно не понимаю почему вас так волнуют эти разбиения. Надо наверное отключить ваерфрйем, чёб вы крепче спали.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 04-11-2019 в 14:35:

Цитата:
Дядя Миша писал:
Я решительно не понимаю почему вас так волнуют эти разбиения. Надо наверное отключить ваерфрйем, чёб вы крепче спали.

А ну я не знаю, наверное фпс падает? И лайтмапы корёжит.

Добавлено 04-11-2019 в 21:35:

А можно ли шарить одну лайтмапу на несколько соседних патчей произвольной формы?


Отправлено ncuxonaT 04-11-2019 в 14:51:

Цитата:
Дядя Миша писал:
Ты на трассу не гони. Эта трасса быстрее любого специализированного рейтрейсера. Может даже вообще самая быстрая в мире.

Ну а смысл-то какой в этой самой быстрой трассе? В ку3 трасса была не такая быстрая, но он же не тормозил.
Цитата:
Дядя Миша писал:
Справился с чем именно?

С трассой по ку3шному дереву.


Отправлено Дядя Миша 04-11-2019 в 14:59:

Цитата:
Crystallize писал:
А ну я не знаю, наверное фпс падает? И лайтмапы корёжит.

ну вот да, единственно что, если микрофейс, там с лайтмапой будут проблемы. Ну так на то и детайлы.

Цитата:
Crystallize писал:
А можно ли шарить одну лайтмапу на несколько соседних патчей произвольной формы?

в халфе там рав-массив, не текстурки. Или что ты имеешь в виду? Если дата совпадает, она оптимизируется, да.

Цитата:
ncuxonaT писал:
Ну а смысл-то какой в этой самой быстрой трассе?

дык лайтмапы считать же.

Цитата:
ncuxonaT писал:
С трассой по ку3шному дереву.

яж говорю, у меня сильные подозрения, что если взаместо этого дерева взять AABB tree, для трассы даже быстрее будет. Я доберусь и до кутри, у меня и для него масса оптимизаций накопилась, надо жы многое проверить на практике. По планам сейчас что:
1. подключить рендер моделей
2. написать загрузчик и рендер спрайтов
а потом можно и с кутри поразбираться.

Добавлено 04-11-2019 в 17:59:

Я вам навскидку скажу одну очень нехорошую особенность кутришного дерева. Поскольку там фейсы лежат не на ноде, то они прилинкованы к лифам. А в разных лифах могут быть одинаковые фейсы, ну собсно это на любом BSP так. Но если трейсить по ноде, там всегда уникальные фейсы.
Так вот, если мы нашли какие-то лифы, то нам надо как-то пометить, что мы эти сурфейсы трейсили, чтобы не выполнять двойную работу. А лайтмаппер-то мультипоточный! Или делать синхронизацию тредов, что убьёт весь профит или на стеке выделять массив этих временных лифов, как Кармак сделал или строить для лайтмаппера вообще новую трассу, лишённую этого недостатка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 04-11-2019 в 15:00:

Дядя Миша
Ты приглядись внимательнее к eof -- там большинство брашей или аксиальыне, или под 45, остальные с рациональным соотношением сторон. У симонока вообще большей частью там замки, а террайны с преимущественно с близкими к регулярным сеткам. А чем больше флоатов, треугольников, чем больше брашей с близкими (но не совпадающими) плоскостями и чем меньше углы между ними, и чем дальше они от центра карты и больше по размеру -- тем больше проблем вылезает. p2st очень многое исправило, но всё равно раз-на раз не приходится. Т.е. даже если щелей нет, то будут места, где тонкие чёрные полоски -- из-за того что лайтмэпа плохо легла на микрофэйс, будут места со странными застреваниями или наоборот проваливаниями. И никак это не спрогнозировать. В результате вырабатывается конечно некоторое эмпирическое умение как минимизировать проблемы, но это получается перекладывания с больной головы на здоровую, в том смысле, что компьютер должен работать а человек думать, а не наоборот.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 04-11-2019 в 15:02:

C++ Source Code:
1
void TraceLine( const vec3_t start, const vec3_t stop, trace_t *trace, qboolean testAll, traceWork_t *tw ) {
2
  int				r;
3
  int				i, j;
4
  dleaf_t			*leaf;
5
  float			oldHitFrac;
6
  surfaceTest_t	*test;
7
  int				surfaceNum;
8
  byte			surfaceTested[MAX_MAP_DRAW_SURFS/8];

Вот такой порнографией Кармак в кутри занимался.

Добавлено 04-11-2019 в 18:02:

Цитата:
thambs писал:
и чем дальше они от центра карты -- тем больше проблем вылезает

Ну это понятно, ктож спорит. Вопрос в том, насколько дальше?
Может имеет смысл этот гротто сделать моделькой, да залайтмаппить её?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 04-11-2019 в 15:36:

Цитата:
Дядя Миша писал:
Может имеет смысл этот гротто сделать моделькой, да залайтмаппить её?

Вот да. Делай уже детали модельками, ну.


Отправлено XaeroX 04-11-2019 в 15:38:

Цитата:
Дядя Миша писал:
Или делать синхронизацию тредов, что убьёт весь профит или на стеке выделять массив этих временных лифов, как Кармак сделал или строить для лайтмаппера вообще новую трассу, лишённую этого недостатка.

Пфф, тоже мне проблема. Заалокать на куче битовые массивы по количеству тредов. По 4 кб на массив выйдет.

Добавлено 04-11-2019 в 22:38:

Цитата:
Дядя Миша писал:
Может имеет смысл этот гротто сделать моделькой, да залайтмаппить её?

Завертекслайтить, и делов.

__________________

xaerox on Vivino


Отправлено Дядя Миша 04-11-2019 в 15:45:

Цитата:
XaeroX писал:
Заалокать на куче битовые массивы по количеству тредов

У меня тут две версии битстрингов, CBitVec и CByteVec соответственно.
Так вот второй всё же быстрее. Надо будет кстати и на компиляторах проверить, глядишь тожы прерост будет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 04-11-2019 в 15:52:

Цитата:
Дядя Миша писал:
дык лайтмапы считать же.

Ну считать их каким-то иным способом. Гадить геометрию, чтобы потом вроде как быстро посчитать лайтмапу - это очень странно.


Отправлено Дядя Миша 04-11-2019 в 15:58:

Не гадить, а подготавливать особенным образом. Тот же кутри лишён CSG, там вся внутренняя хрень, которая исчезает при препроцессинге, здесь радостно остаётся. И для нее тоже считается лайтмапа. На иных картах залетишь вот так в стенку, а внутри - еще одна стенка и на ней лайтмапа посчитана. Конечно это лучше. Щас во всех играх такое.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 04-11-2019 в 16:06:

Цитата:
Дядя Миша писал:
Тот же кутри лишён CSG, там вся внутренняя хрень, которая исчезает при препроцессинге, здесь радостно остаётся.

Ну добавишь CSG, как я в волатиле, делов-та.
Ку3 - это всего лишь формат, конь-цепция. Никто ж не заставляет брать оттуда абсолютно всё? Если бы я так рассуждал, не было бы неко кой волатилы, взял бы я ку3 и сидел давольный.

__________________

xaerox on Vivino


Отправлено Дядя Миша 04-11-2019 в 16:26:

Цитата:
XaeroX писал:
Ну добавишь CSG, как я в волатиле, делов-та.

Добавлю конечно. Но это только полдела. Я сильно подозреваю, что тот же сталкер первоначально и базировался на кутришных картах. Но потом в процессе оттуда повыкинули дерево и всё остальное. И произошло это в первый же год разработки.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 05-11-2019 в 12:35:

Подключил студиомодели.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 05-11-2019 в 13:15:

Дядя Миша
Совместимость с голдовскими будешь ломать?


Отправлено Дядя Миша 05-11-2019 в 13:44:

В дальнейшем буду. Я предусмотрю такой же конвертор из одного формата в другой, как и для уровней.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 07-11-2019 в 08:59:

Вот кстати говоря насчёт TBN на моделях. В параное сглаживание происходило только в рамках одного меша. Если кто-то не знает структуру студиомодели, поясню. Вся модель делится на Body Parts - это таблица индексов, к которой прилинкованы субмодели. Через параметр pev->body мы можем указывать рендереру какие именно части тела рендерить. Хитрость этой таблички в том, что мы уже при компиляции можем задать любые сочетания из имеющихся у нас субмоделей и привязать их к определённому номеру body. Допустим солдат-негр с дробовиков содержит в табличке 3 субмодели - тело солдата, голова негра и дробовик. Эти три меша будут отрисованы. Субмодели делятся на мешы, но при этом вертексы-нормали общие для всей субмодели. Один меш отличается от другого только текстурой. Так вот всё дело в том, что чаще всего нормали сглажены только для отдельно взятого меша, а не для всей субмодели. Проверить это утверждение очень легко - достаточно попробовать нарисовать Glow Shell, используя те нормали, которые уже есть в модели. Ну вы все знаете, как делается Glow Shell:

C++ Source Code:
vec3_t vertex = mesh->vertex + mesh->normal * shell_scale;

В квейках глоушеллы сделаны аналогично, но поскольку там всегда одна текстура на модель, то проблем не возникает. А тут приходится строить новую табличку. Надо сказать, что в Valve в целях ускорения, к этому отнеслись довольно наплевательски. Ну они просто пособирали все нормали с субмодели, которые попались первыми. Примерно в 70% случаев это конает. То что Glow Shell имеет разрывы - незаметно. Да я напомню, что это в основном использовалось на айтемах, ну и может на игроках. Ну как что сложнее - уже видны артефакты. Но в то же время есть еще один кейс где сглаженные нормали сквозь весь меш крайне критичны - это радионовская фича True Form, которая пыталась тесселировать модели в те далёкие времена, я помню её Ксерокс еще пытался заюзать в HLFX и у него бочки так смешно надувались
Тем не менее на ютубе есть ролики, где показано что это даже неплохо работало. А как строятся такие нормали? Там area weights для смежных треугольников субмодели. Я сделал аналогично и через dot сравнил нормали в модели с теми что у меня получились. И вот в 90% случаев dot выдал результат около 0.99, т.е. почти идентичные. Но кое-где было 0.1, а где-то даже -1. Это вот как раз те разрывные места между двумя мешами. У меня тут небольшой бардак с ресурсами, толком проверить пока не могу, но я оставлю эту фичу на будущее - пригодится.
По хорошему TBN надо сохранять в модель, но тогда придётся разработать новый формат, уже с нормальной индексацией треугольников, снять лимит на длину анимации в 64 килобайта, итд.

Добавлено 07-11-2019 в 11:59:

Модели худо-бедно рисуются, анимируются, теперь надо спрайтесы подключить. Старый вариант, где на каждый кадр грузилась отдельная текстурка никуда не годится. Я их сохраню в один большой атлас. А вертексы в VBO и спрайты теперь тоже будут рисоваться через шейдер.
Все равно их мягкими делать. Soft-Particles.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 07-11-2019 в 11:31:

Цитата:
Дядя Миша писал:
придётся разработать новый формат, уже с нормальной индексацией треугольников

В каком смысле с нормальной? Сейчас плохая? Или сейчас всё на стрипы завязано?


Отправлено Дядя Миша 07-11-2019 в 12:56:

Цитата:
nemyax писал:
В каком смысле с нормальной? Сейчас плохая?

Сейчас там raw-поток gl-комманд, к которому нет произвольного доступа, это дичайше неудобно, его приходится каждый раз весь проматывать.
Нормальная индексация, я имею в виду завести структурку triangle и там a,b,c индексы.

Подзагрузил спрайто-кадры в атласы, ну пока не очень плотно. Но для начала сойдет.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 07-11-2019 в 13:07:

Дядя Миша будешь делать обрезалку квадов спрайтов, как хумус завещал?
http://www.humus.name/index.php?ID=266


Отправлено Дядя Миша 07-11-2019 в 15:28:

Не знаю пока насчёт обрезалки. Я тут в коде упаковщика картинок от Кармака баг нашёл. Сначала понять не мог, да что за дерьмо такое, ну вот ситуация. Допустим у нас в спрайте всего 1 кадр 16х16. Размер атласа аналогично 16х16. У меня там перед загрузкой еще код пытается определить потенциальные размеры атласа, чтобы потуже упаковать кадры.
Вполне естественно что для одного кадра он покажет именно его размеры.
А упаковщик - посылает. А всё почему?

C++ Source Code:
1
for( i = 0; i < blockWidth - w; i++ )
2
{
3
  best2 = 0;
4
 
5
  for( j = 0; j < w; j++ )
6
  {
7
    if( allocated[i+j] >= best )
8
      break;
9
    if( allocated[i+j] > best2 )
10
      best2 = allocated[i+j];
11
  }
12
 
13
  if( j == w )
14
  {
15
    // this is a valid spot
16
    x = i;
17
    y = best = best2;
18
  }
19
}

Видите условие для цикла?
Если blockWidth == w, цикл ни разу не прогонится. Отсюда идиотская ситуация, что мы не можем поместить в атлас картинку, которая точно совпадает по его размерам, но это ладно, это только полдела. Оно из-за этого еще и пакует хуже процентов на 15. То есть я подбирал оптимальные размеры атласа, куда по моим прикидкам должны были влезать все кадры. А упаковщик - хрена. 2-3 последних кадра не влезало. Как повизёт. Да что такое? Увеличил высоту еще на один шаг - влезло.
Странно. Начал разбираться. И вот такое.
Правильнное условие выглядит так
C++ Source Code:
for( i = 0; i <= blockWidth - w; i++ )

вот так всё прекрасно влезает на заданный размер.

Добавлено 07-11-2019 в 18:25:

Поглядел насчёт обрезалки. Это филлрейт понижать? Наши мапперы как наставят один за другим 100 спрайтов, туманчег делают, навряд ли оно спасёт.

Добавлено 07-11-2019 в 18:28:

Particle Trimmer, хех. В принципе такую штуку несложно и самому написать, этож 2д обрезалка. Если парт-системы сделать через инстансинг, то смысл безусловно есть. Впрочем там и лучи надо через него же рисовать, но с лучами попроще - их и так не надо обрезать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 07-11-2019 в 15:41:

Цитата:
Дядя Миша писал:
Поглядел насчёт обрезалки. Это филлрейт понижать? Наши мапперы как наставят один за другим 100 спрайтов, туманчег делают, навряд ли оно спасёт.

Странная логика, казалось бы как раз поэтому и нужно делать.


Отправлено Дядя Миша 07-11-2019 в 16:19:

Да не, от еденичных спрайтов подряд оно не спасёт. Это для облака партиклей в первую очередь полезно. Вот там да, овердрав, который можно сильно уменьшить.

Добавлено 07-11-2019 в 19:19:

Кстати насчёт того исправления о котором я написал выше. Залез в код ку3 - а там уже исправлено Причём тем же способом.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 07-11-2019 в 17:08:

Цитата:
Дядя Миша писал:
код ку3

А в код Jedi Academy лазишь?


Отправлено Дядя Миша 07-11-2019 в 20:52:

Та я уже почти никуда не лажу. А если и лажу, то не за кодом, а посмотреть архитектурное решение.

Добавлено 07-11-2019 в 20:36:

Чтоб не мелочиться, загрузил вообще все спрайты, которые были. Прикольно выглядит.



Добавлено 07-11-2019 в 20:44:

Барон Ада из дуума занял текстуру 1024х768.

Добавлено 07-11-2019 в 20:46:

Вообще в NT я планирую сжать эти спрайты в DXT1\DXT5, это и будет "новый" формат.

Добавлено 07-11-2019 в 23:20:

Возвращаясь к теме убитых нормалей, то что я писал утром. Вспомнил, что у меня есть моделька, конверченная из ку3 с помощью этой японской программы, название которой я уже забыл. Ну вообщем нормали там вообще никакие. Я не знаю почему. Собсно слева - нормали в модели, а справа seamless normals by area weighting про которые я говорил.



Это конечно искуственный случай, ну просто чтобы было понятнее о чём речь.

Добавлено 07-11-2019 в 23:52:

Да, возвращаясь к вашей самой любимой теме, о том как можно текстуры с разных моделей совершенно не грузить, как дубликаты. В NT это вполне себе реализуемо. Правда с той оговоркой, что компиляторы пытаются подрезать текстуру на разных моделях ($cliptotexcoords), из-за чего одна и та же текстура может менять свой размер на разных моделях. Поэтому для таких текстур будет сделан дубликат. Но их не очень много.

Немного статистики для c1a0d.
Все текстуры уникальные - 653 штуки.
С дубликатами для одинаковых имён и разных размеров - 695 штук
Уникальные текстуры для каждой модели - 790 штук.
Для халфовских моделек вся экономия - 2 мегабайта памяти.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 07-11-2019 в 20:58:

Дядя Миша взвешенное сглаживание нормалей планируешь опциональным делать? Потому что если модель будет с запеченной нормалмапой, то из-за изменений нормалей нормалмапа пойдет по одному месту.

Crystallize ты как-то спрашивал на КСМе, почему в хлраде нет антиалиасинга у лайтмап, только блюр. А я ответил, что толку от антиалиасинга не будет, потому что при увеличении даже сглаженной текстуры всё равно полезут пиксели. Так вот, оказалось, что я был неправ, и можно заморочиться, чтоб лайтмапа была более-менее гладкая. Нужно пиксели интерполировать не билинейным фильтром, а, например, бикубическим. Но видеокарта в него не умеет, поэтому придётся городить огород в шейдере, и фпс немного упадёт, конечно.
Вот вроде бы самый быстрый способ:
http://www.java-gaming.org/index.php?topic=35123.0
Ожидаемый результат примерно такой:
https://ndotl.files.wordpress.com/2018/08/bilinearvsbicubic.jpg
Может, ДМа заинтересует.


Отправлено Дядя Миша 07-11-2019 в 21:57:

Цитата:
ncuxonaT писал:
взвешенное сглаживание нормалей планируешь опциональным делать?

пока вообще не знаю что с ним делать.

Цитата:
ncuxonaT писал:
Нужно пиксели интерполировать не билинейным фильтром, а, например, бикубическим.

бикубик зараза такая активно провоцирует швы. Нельзя просто взять и заменить фильтр. Надо что-то еще делать с лайтмапой.

Добавлено 08-11-2019 в 00:57:

Ну вот примерно так:

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 07-11-2019 в 22:06:

Дядя Миша добавлять бордюр в один пиксель вокруг каждого куска в атласе?


Отправлено thambs 08-11-2019 в 01:54:

>https://ndotl.files.wordpress.com/2...arvsbicubic.jpg
Красота какая.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Crystallize 08-11-2019 в 07:12:

Цитата:
ncuxonaT писал:
ты как-то спрашивал на КСМе, почему в хлраде нет антиалиасинга у лайтмап, только блюр.

Спасибо, красиво смотрится.

Цитата:
ncuxonaT писал:
Дядя Миша добавлять бордюр в один пиксель вокруг каждого куска в атласе?

Ну тогда уж смешать "до" и "после" по маске у которой крайние скажем 5 пикселей это градиент.

Добавлено 08-11-2019 в 14:12:

Я не понимаю почему билинейка такая, она же должна быть мутнее по идее.


Отправлено Дядя Миша 08-11-2019 в 07:48:


С бордюром\без бордюра. Если бы у меня что-то получилось с бикубиком, я бы его еще в параною добавил. Ему нужны сплошные непрерывные лайтмапы судя по всему, развертки.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 08-11-2019 в 10:02:

Дядя Миша
А возможно в принципе поглядеть как оно выглядит на самом атласе и как туда полигоны отображаются?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено nemyax 08-11-2019 в 10:08:

Цитата:
Дядя Миша писал:
С бордюром\без бордюра.

Вот эти косые фёгни на полу у стены — то, чего быть не должно?


Отправлено Дядя Миша 08-11-2019 в 10:54:

это швы

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 08-11-2019 в 10:56:

Откуда берутся эти тёмные швы? Там что в лайтмапе по краям тёмные пиксели которые не видны в обычной ситуации и с ними происходит блур?


Отправлено Дядя Миша 08-11-2019 в 11:00:

От бикубической фильтрации

Добавлено 08-11-2019 в 14:00:

Цитата:
thambs писал:
А возможно в принципе поглядеть как оно выглядит на самом атласе и как туда полигоны отображаются?

наверное можно, только смысл? Билинейка швов не делает, если сама лайтмапа впорядке.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 08-11-2019 в 11:02:

Цитата:
Дядя Миша писал:
От бикубической фильтрации

с чем же нужно сфильтровать белую лайтмапу чтобы она так потемнела?


Отправлено Дядя Миша 08-11-2019 в 11:49:

Ну вот так работает бикубик. Он мне в своё время еще на звуке не понравился, ощущение было такое, что исполнителю вставили в рот валенок.
У него довольно ограниченное применение, потому его и не спешат реализовывать в железе.

Добавлено 08-11-2019 в 14:49:

вот ежели у меня руки когда-нибудь дойдут до LCSM, вот тогда и можно будет вернуться к этой теме.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 08-11-2019 в 12:44:

Подразумевалось, что бордюр будет заполнен цветом из соседнего пикселя, а не останется черным


Отправлено thambs 08-11-2019 в 13:22:

ncuxonaT
А если шов идёт по диагонали?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено ncuxonaT 08-11-2019 в 13:35:

thambs то что?


Отправлено nemyax 08-11-2019 в 14:12:

Цитата:
Дядя Миша писал:
ежели у меня руки когда-нибудь дойдут до LCSM

Делать для лайтмапы UV-развёртку брашевых фейсов? Нуниплоха наверное.


Отправлено Дядя Миша 08-11-2019 в 16:40:

Хым. Это я бордюр неправильно строил. Надо же по два пикселя брать, а я брал один. Вообще эти бордюры строить нетривиальная задачка, оч. легко запутаться. Но с бордюром, темнименее, мне уже прямо нравится. Я его окрасил в красный цвет для дебага, так вот даже уже с таким цветом - швы практически незаметны. Продолжаю эксперимент.

Добавлено 08-11-2019 в 19:32:

Всё равно швы лезут от бикубика. Правда в данном случае - на тех местах где они были изначально. Слева билинейка, справа бикубик

Тут еще надо отметить что эта версия c1a0d была скомпилена еще оригинальными вальвовскими компилерами, т.е. там полюбому швы были.
Может быть, если бы швов не было, они бы и не вылезли?

Добавлено 08-11-2019 в 19:40:

Ну вообщем серавно фигня. Вот заведомо бесшовная карта, а вот что происходит:

Спровидливозти ради стоит отметить, что это происходит далеко не везде. Может ему недостаточно бордюра в 1 пиксель? Попробую два.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 08-11-2019 в 17:03:

Дядя Миша а как ты бордюр строишь?


Отправлено Дядя Миша 08-11-2019 в 17:28:

ncuxonaT в основном - вокруг лайтмайпы. Или вквадрат, если быть точным.

Добавлено 08-11-2019 в 20:23:

Корочи даже по три пикселя бордюр даёт точно такой же эффект со швом. Спровидлизвоти ради стоит заметить что со включённой диффузкой этот шов незаметен, да и сами швы появляются далеко не везде, с бордюром-то.

Добавлено 08-11-2019 в 20:28:

Ну что тут скажешь. Есть места, где всё становится только лутьшы. Вот к примеру:


А здесь наоборот - сплошное расстройство

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 08-11-2019 в 18:15:

Дядя Миша
Эй, это же ку3дм1 из волатилы!

__________________

xaerox on Vivino


Отправлено Дядя Миша 08-11-2019 в 18:33:

Цитата:
XaeroX писал:
Эй, это же ку3дм1 из волатилы!

Yesлибы!

Добавлено 08-11-2019 в 21:33:

Вообщем ладно, бордюр я конечно оставлю, но эксперимент по прежнему считаю неудовлетворительным. К тому же этот фильтр жрёт фпс довольно сильно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 08-11-2019 в 19:41:

Бордюр наверное должен браться с прилегающих поверхностей

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено nemyax 08-11-2019 в 19:45:

Дядя Миша
Ты ж писал, что будет одна динамика, и вдруг лайтмапы.


Отправлено Дядя Миша 08-11-2019 в 21:21:

nemyax ну выбросите лайтмапы, будет одна динамика

Добавлено 09-11-2019 в 00:21:

До сих пор разгребаю последствия полетевшего винта. Тут внезапно выяснилось, что все бэкапы паранои - тоже того, уже не являются архивами.
Ну есть конечно финальные актуальные сорцы. Но промежуточные все утеряны. Месяца за 4-5.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 08-11-2019 в 22:32:

Подтверждаю, у меня тоже швы вылазят. Теоретически я могу сделать, чтобы моя убиралка швов делала это с учетом бикубика, но тогда нужно будет хранить все куски с бордюром в 1 пиксель. Ну или сразу фикшенный атлас.


Отправлено Дядя Миша 09-11-2019 в 08:37:

Цитата:
ncuxonaT писал:
Теоретически я могу сделать, чтобы моя убиралка швов делала это с учетом бикубика

основная проблема в том, что лайтмапа это набор несвязанных кусочков. Вот и вылазит.

Добавлено 09-11-2019 в 11:34:

Заглянул в скрипты Wolf2009. По организации скриптов там смесь изд3-шных материалов и попыток сделать систему более гибкой.
Вот например так выглядит тепичный материал
Цитата:

textures/decals/pebbles_01
{
EditorImage textures/decals/pebbles_01_d
Image DiffuseMap textures/decals/pebbles_01_d
Image NormalMap textures/decals/pebbles_01_local
Image SpecularMap textures/decals/pebbles_01_s
Vector Specular 16 0 1 0
AlphaTest .1
noOverlays
VertexColor
PolygonOffset 1 1
NoTFix
Contents Nonsolid
NoShadows
nofragment
Vector DetailNormalControls 3 3 2 0
}

В ку3 было достаточно написать "map". Здесь еще требуется связать имя юнита в шейдере. Ну как бы уже не слишком наглядно.

А вот техника
Цитата:

Technique "AmbientDecalAdd"
{
Sort Depth
Pass
{
VertexShader "StandardDrawTexture"
{
Uniform vColorModulate Material::ColorModulate
Uniform vColorAdd Material::ColorAdd
Uniform vHPosBias BackEnd::HPosBias
}
FragmentShader "StandardDrawTexture"
{
Sampler ColorMap
{
Texture Material::ColorMap { _default }
MinFilter Linear
MipFilter Linear
MagFilter Linear
}
}
Blend Enable
BlendFunc One One
AlphaWrite Disable
DepthWrite Disable
}
}

Но как я понял, набор параметров везде свой. Тоже, как у меня доступ к общим переменным через :: Вообщем я видимо самостоятельно нащупал какую-то вполне общепринятую концепцию.

Добавлено 09-11-2019 в 11:37:

Для сравнения вот моя техника
C++ Source Code:
1
technique "studioSolidLightmapPass"
2
{
3
  vertShader( "glsl/forward/scene_studio_vp.glsl" );
4
  fragShader( "glsl/forward/scene_studio_fp.glsl" );
5
 
6
  image u_LightMap = "entity->$LightmapTexture";
7
  image u_DeluxeMap = "entity->$DeluxemapTexture";
8
  float u_LightStyleValues[64] = "globals->lightStyles";
9
  float u_AmbientFactor = "globals->ambientFactor";
10
  vec3 u_LightDiffuse = "lightProbe->color";
11
  vec3 u_LightDir = "lightProbe->direction";
12
  vec2 u_LightShade = "lightProbe->shadeAmbient";
13
  vec3 u_AmbientCube[6] = "lightProbe->ambientCube";
14
 
15
#if MODEL_HAS_LIGHTMAP
16
#define SURFACE_LIGHTING
17
#endif
18
 
19
#if MODEL_HAS_VERTEXLIGHT
20
#define VERTEX_LIGHTING
21
#endif
22
 
23
  // NOTE: TBN should be computed even bump texture is missed
24
#if MODEL_HAS_DELUXMAP
25
#define HAS_DELUXEMAP
26
#endif
27
 
28
#if r_fullbright
29
#define LIGHTING_FULLBRIGHT
30
#endif
31
 
32
#if r_lightmap == 1
33
#define LIGHTMAP_DEBUG
34
#endif
35
 
36
#if r_lightmap == 2 && MODEL_HAS_DELUXMAP
37
#define LIGHTVEC_DEBUG
38
#endif
39
#define NORMAL_RG_PARABOLOID
40
  depthMask( GL_TRUE );
41
}

Правда она более широкого употребления - это шаблон для всех солидных студиомоделей. А вот шейдеробъект
C++ Source Code:
1
shaderObject "StudioModel"
2
{
3
  setTechniquePass( "solid", studioSolidLightmapPass );
4
  //	setTechniquePass( "spot", studioSolidSpotLightPass );
5
  //	setTechniquePass( "omni", studioSolidOmniLightPass );
6
  //	setTechniquePass( "proj", studioSolidProjLightPass );
7
 
8
  // declare common uniforms
9
  image u_ColorMap = "globals->$WhiteTexture";	// fallback texture
10
  image u_DetailMap = "materials.def->detailMap";
11
  image u_NormalMap = "textures/<modelname>/<texname>_norm";
12
  image u_GlossMap = "textures/<modelname>/<texname>_gloss";
13
  //	image u_GlowMap = "textures/<texname>_luma";
14
 
15
  vec4 u_BonesArray[384] = "entity->bonesMatrix";
16
  vec4 u_BoneQuaternion[128] = "entity->bonesQuaternion";
17
  vec3 u_BonePosition[128] = "entity->bonesPosition";
18
  vec2 u_DetailScale = "materials.def->detailScale";
19
  vec2 u_TexOffset = "entity->conveyorMovement";
20
  float u_Smoothness = "materials.def->smoothness";
21
  vec4 u_RenderColor = "entity->renderColor";
22
  mat4 u_ModelMatrix = "entity->transform";
23
  vec3 u_ViewOrigin = "render->viewOrigin";
24
 
25
  addImageLocation( u_ColorMap, "*<texname>" ); // embedded model texture
26
  addImageLocation( u_ColorMap, "textures/<modelname>/<texname>" );
27
 
28
  // add image extra info to help engine
29
  setImageHint( u_ColorMap, "Albedo" );
30
  setImageHint( u_NormalMap, "Normal" );
31
 
32
  // add flags for image loader
33
  addImageFlags( u_ColorMap, TF_SILENT_LOADING|TF_KEEP_SRC_IF_ALPHA );
34
  addImageFlags( u_NormalMap, TF_SILENT_LOADING|TF_NORMALMAP );
35
 
36
  // FIXME
37
#if MODEL_NUM_BONES == 1
38
  //		#define MAXSTUDIOBONES	1
39
#endif
40
 
41
#if MODEL_HAS_BONEWEIGHTS
42
#define APPLY_BONE_WEIGHTING
43
#endif
44
 
45
#if r_physic_based_shading
46
#define APPLY_PBS
47
#endif
48
 
49
#if r_detailtextures && u_DetailMap
50
#define HAS_DETAIL
51
#endif
52
 
53
#if r_normal_mapping && u_NormalMap
54
#define HAS_NORMALMAP
55
#define COMPUTE_TBN
56
#endif
57
 
58
#if r_specular && u_GlossMap && u_Smoothness > 0
59
#define HAS_GLOSSMAP
60
#endif
61
 
62
#if u_GlowMap
63
#define HAS_LUMA
64
#endif
65
 
66
#if WORLD_HAS_GLOBALFOG
67
#define APPLY_FOG_EXP
68
#endif
69
 
70
#usage	mod_studio
71
}

всё ли понятно по синтаксису?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 09-11-2019 в 10:18:

ncuxonaT перенести бикубическую фильтрацию в лайтмаппер, перед дядьмишиной затиралкой швов попяченой с хл2


Отправлено Дядя Миша 09-11-2019 в 11:43:

Цитата:
Crystallize писал:
перед дядьмишиной затиралкой швов попяченой с хл2

В хл2 нет никакой затиралки швов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 09-11-2019 в 12:10:

ну в сорсовском лайтмаппере тогда.


Отправлено Дядя Миша 09-11-2019 в 12:30:

ну нету в сорсе никакой затиралки швов нигде. Включи mat_showlightmaps или как оно там называется и убедись сам.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 09-11-2019 в 13:20:

Crystallize у меня есть затиралка швов, но она работает исходя из того, что потом текстура будет фильтроваться билинейно. Можно переделать для бикубика, но нужно будет как-то хранить бордюры


Отправлено SNMetamorph 09-11-2019 в 14:12:

А по поводу размерностей в UI есть какие-то идеи для движка?
Я ковырялся с этой проблемой, в итоге решил что со всем многообразием дисплеев с разными разрешениями, размерами и DPI, проще просто добавить в настройки параметр для скейла всего UI целиком. Не получилось у меня найти какого-то универсального решения.


Отправлено Дядя Миша 09-11-2019 в 14:42:

Цитата:
ncuxonaT писал:
Можно переделать для бикубика

и на билинейке швы полезут?

Добавлено 09-11-2019 в 17:42:

Цитата:
SNMetamorph писал:
Не получилось у меня найти какого-то универсального решения.

а для UI и не существует такого решения. Скейлить нельзя, всё должно попадать пиксель в пиксель для каждого разрешения.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено SNMetamorph 09-11-2019 в 15:01:

Цитата:
Дядя Миша писал:
всё должно попадать пиксель в пиксель для каждого разрешения

А ещё и это ко всему прочему. Вообще жуть какая то.


Отправлено Crystallize 09-11-2019 в 15:21:

Цитата:
Дядя Миша писал:
а для UI и не существует такого решения. Скейлить нельзя, всё должно попадать пиксель в пиксель для каждого разрешения.

Оно не попадает. Я помню как обнаружил что на GL_NEAREST и в софтваре спрайты пушек в инвентаре явно чёччче.


Отправлено ncuxonaT 09-11-2019 в 19:50:

Цитата:
Дядя Миша писал:
и на билинейке швы полезут?

полезут, конечно. Есть более дикий вариант - убирать швы непосредственно при загрузке карты, если включен бикубик. Но алгоритм нужен другой, этот слишком медленный.


Отправлено a1batross 10-11-2019 в 04:42:

SNMetamorph как вариант -- запихать спрайты в вектор и при загиузке их рендерить в нужное разрешение.

Это будет точно лучше, чем набор 320hud, 640hud из халфы и где последний рисуется "пиксель-в-пиксель" на FullHD и в итоге ничего вообще не видно, мелко.

__________________
Xash3D FWGS форк


Отправлено ncuxonaT 10-11-2019 в 12:30:

a1batross а как быстро и красиво рисовать вектор в рилтайме? Я читал про разные методы рендера шрифтов, и в заключении одной из недавних статей по этой теме было написано "Мы представили новый метод рисования векторных шрифтов, он быстрее всех предыдущих реализаций. Но в 40 раз медленнее, чем просто рисовать квад с текстурой".
На самом деле даже вектор не гарантирует, что всё четко будет. Не просто так в линуксах векторные иконки рисуют в разных разрешениях.


Отправлено XaeroX 10-11-2019 в 12:35:

ncuxonaT
Растр под макосью в режиме HDPI очень чёткий, не хуже вектора.

__________________

xaerox on Vivino


Отправлено ncuxonaT 10-11-2019 в 12:54:

XaeroX растр без мазни не отмасштабируешь, кернинг не сделаешь. Иными словами, шрифты - говно.


Отправлено thambs 10-11-2019 в 13:09:

ncuxonaT
Зачем в реалтайме?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено ncuxonaT 10-11-2019 в 13:25:

thambs ну а как иначе, если текст может меняться, или, например, прокручивать его нужно


Отправлено thambs 10-11-2019 в 13:50:

ncuxonaT
Так вроде-то задача не рендерить postscript-страничку, а заменить растровый шрифт фиксированного размера. Сменил разрешение -- закешировал рендеры шрифтов/иконок. Тот же растр остался, только генеришь его по необходимости из векторного исходника.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено ncuxonaT 10-11-2019 в 14:12:

thambs если потом рендерить растр пиксель в пиксель, то не получится сделать кернинг, плюс из-за округления расстояние между буквами будет не таким, каким должно быть. Если рендерить растр не пиксель в пиксель, то получится мазня.


Отправлено a1batross 10-11-2019 в 18:29:

ncuxonaT а зачем? Отрисовал в атлас и вперёд. Ну, хочется играть с масштабом -- есть SDF. Неидеально, но наврядли кто-то заметит разницу.

Вон у меня в mainui_cpp шрифторендер в атлас рисует и никогда больше не трогает шрифты. Пока конечно юзер не ресайзнул окно, лол.

Цитата:
Не просто так в линуксах векторные иконки рисуют в разных разрешениях.


O_o ЩИТО

Ты точно уверен что это вектор?

__________________
Xash3D FWGS форк


Отправлено ncuxonaT 10-11-2019 в 18:59:

a1batross как с атласом делать кернинг?

В атласе ширина глифов целочисленная или с плавающей точкой?

Цитата:
a1batross писал:
Ты точно уверен что это вектор?

Йеп, svg же. Открой любую тему, там будут папки 16х16, 32х32 и так далее с иконками соответствующих размеров.


Отправлено FreeSlave 10-11-2019 в 22:01:

Цитата:
ncuxonaT писал:
Йеп, svg же. Открой любую тему, там будут папки 16х16, 32х32 и так далее с иконками соответствующих размеров.


В этих папках лежат png. Ими пользуются приложения, которые не поддерживают svg. Это часть спецификации http://standards.freedesktop.org/ic...pec-latest.html и к теме не имеет отношения.

__________________
I'm on github
I'm on opendesktop.org


Отправлено ncuxonaT 10-11-2019 в 22:22:

FreeSlave только вот в большинстве тем там лежат именно svg.
стандартные КДЕшные иконки:
https://github.com/KDE/breeze-icons...er/icons/places
бывшие стандартные убунтушные иконки:
https://git.launchpad.net/ubuntu/+s.../Humanity/mimes


Отправлено a1batross 10-11-2019 в 22:57:

ncuxonaT

Цитата:
В атласе ширина глифов целочисленная или с плавающей точкой?


А атлас тут ни при чём. ВООБЩЕ.

1
2

Атлас в формате L8A8, поэтому я могу просто рисовать глифы поверх друг друга, сдвигая на определенное количество пикселей.
На второй пикче видно сам атлас. Красные линии -- bbox, зелёные -- отступы для керинга. Естественно на самой текстуре они не присуствуют, просто довольно удобно смотреть что же мне там выдал FreeType, stb_truetype или WinAPI.

(а ещё на первой картинке баг с порядком отрисовки, букву g сожрало )

Цитата:
Открой любую тему, там будут папки 16х16, 32х32 и так далее с иконками соответствующих размеров.


Да, кстати, это вообще-то стандарт Freedesktop. Многое вообще симлинками, поэтому это фактически один и тот же файл.

Но я открыл случайный user-trash.svg и 16x16 и 64x64 -- это две разные картинки. Ну, они в разной детализации для разных задач. Одна в GUI на кнопке нарисуется, вторая в файл менеджере в качестве иконки папки.

__________________
Xash3D FWGS форк


Отправлено ncuxonaT 11-11-2019 в 00:15:

a1batross а неплохо. Но это атлас нужно рисовать в 2 раза больше, чем текст потом? То, что ты показываешь, - это не кернинг. Вот кернинг: https://ru.wikipedia.org/wiki/%D0%9...%B8%D0%BD%D0%B3

Цитата:
a1batross писал:
Но я открыл случайный user-trash.svg и 16x16 и 64x64

А ты открой 32х32 и 64х64 или 64х64 и 128х128. Картинки будут те же, но поправленные, чтобы всё попадало пиксель в пиксель. Да даже 16х16 и 22х22.


Отправлено a1batross 11-11-2019 в 01:55:

ncuxonaT
>Но это атлас нужно рисовать в 2 раза больше, чем текст потом?

Моя ошибка, на второй картинке -- атлас "большого" шрифта, он редко используется пока что. В основном используется "средний" или "мелкий". Их размеры высчитываются относительно высоты окна.

На самом деле конечно не нужно.

>То, что ты показываешь, - это не кернинг. Вот кернинг:

И в чём потенциальная разница? Ну, я не специалист в типографии, но по-моему мы говорим об одном и том же.
Видишь у меня буквы не разъезжаются, а вот ра-ааньше они разъезжались!

Конечно, всё это автоматически, ничего вручную я не расставлял, только по информации которая доступна в самом TTF файлике.

> А ты открой 32х32 и 64х64 или 64х64 и 128х128. Картинки будут те же, но поправленные, чтобы всё попадало пиксель в пиксель. Да даже 16х16 и 22х22.

Я открыл 128 и 512 иконку LibreOffice. Действительно, 512x512 выглядит лучше, чем 128x128 увеличенный до 512x512. Screenshot.
Но если приглядеться, видно, что в 128x128 убрана детализация, которую никто не увидит в таком разрешении.

В 256 уже, как ты и сказал, попадание пиксель-в-пиксель. Screenshot


Но как это соприксается с моим предложением вообще использовать вектора в HUD? Если у тебя векторная иконка пушки X в 4K будет выглядеть хуже, чем на HD, ты сделаешь отдельную версию для 4К, которая визуально будет приятнее. Но тем не менее, внутренний перфекционист игрока не будет ущемлён из-за того, что ты не подумал о, например, 1680x1050. А если в твою игру поиграет человек через 20 лет с монитором в 16K? Что ему делать, наслаждаться мылом или маленькими иконками?

У самого несколько месяцев назад был 1680x1050 и в некоторых случаях игры не догадывались брать 1080p HUD и брали 720p и была в основном просто мелкота. К счастью, никому мылить HUD в голову не приходит.

Особо богатые буратины на ютубах выкладывают записи игр в 8K, 16K разрешениях. Открыл случайное, GTA 4 в 8K выглядит хорошо. В Half-Life 2 он HUD не показал, но текст очень мелкий. Несмотря на то, что там TTF. Наверное правится в конфигах, не так критично если был бы битмапный.

__________________
Xash3D FWGS форк


Отправлено Crystallize 11-11-2019 в 02:21:

Цитата:
Дядя Миша писал:
ну нету в сорсе никакой затиралки швов нигде. Включи mat_showlightmaps или как оно там называется и убедись сам.

На КСМ ты говорил что затиралку китайца работающую в 3D ты не будешь брать как жрущую память и время но у тебя есть своя которая работает в 2D и она основана на аналогичных механизмах из Сорса. Это было или у меня Мандела?


Отправлено ncuxonaT 11-11-2019 в 21:47:

Можно наш трёп про шрифты и интерфейсы в отдельную тему перенести, чтобы тут на засорять? Спасибо.

a1batross ты шрифт из атласа рисуешь на экране 1:1 или масштабируешь тоже? Размер квадов и их координаты попадают в экранные пиксели? Отступы и размеры глифов в атласе в целых пикселях или как-то иначе?

Цитата:
a1batross писал:
И в чём потенциальная разница? Ну, я не специалист в типографии, но по-моему мы говорим об одном и том же.

Кернинг это вроде дополнения к твоим отступам. В силу внешнего вида некоторых символов, если ставить их подряд, будут образовываться дыры, слова будут разваливаться, нужна коррекция. Поэтому в шрифтах записаны кернинговые пары и значения, на сколько нужно сдвинуть второй символ в паре. Например, между Т и А будет большая дыра без кернинга, поэтому в шрифте записано что-то вроде ТА -120, соответственно, А сдвигается влево на 120 единиц.
Цитата:
a1batross писал:
Но как это соприксается с моим предложением вообще использовать вектора в HUD?

Просто хотел сказать, что это не серебряная пуля


Отправлено FiEctro 11-11-2019 в 22:14:

Вы не видите самого главного, всё это битмаповое гамно должен кто то рисовать. Для всех модов. А шрифтов хоть жопой жуй, качай нихачу. Зачем каждый раз возиться в фотошопе, если это можно реализовать программно вектором?

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено a1batross 11-11-2019 в 23:12:

ncuxonaT > Просто хотел сказать, что это не серебряная пуля

Серебрянных пуль вообще не существует. Разве что не делать HUD вообще.

Если задача сократить себе работу на поддержке разных разрешений, можно вообще сделать его трёхмерным и тогда никакой речи о pixel perfect идти не будет. Это кстати популярно нынче.

Но я предлагаю решение для классического двухмерного HUD, который обязан выглядеть хорошо.

>ты шрифт из атласа рисуешь на экране 1:1 или масштабируешь тоже

1:1.

Масштабируется он только там, где отрисовать шрифт заново -- слишком дорого. Например, на мобильниках. Но там и ресайз окна -- задача нетипичная, на Android законным методом это можно делать только в последних версиях и этим никто не пользуется, особенно в активных играх.

>Кернинг это вроде дополнения к твоим отступам

Нет, такой вещи у меня нет. Но может когда-нибудь будет. Сейчас в шрифторенедере мне сильно нехватает дорисовки новых символов в атлас, просто MenuAPI Ксаша это не учитывает. А так будет -- и можно по запросу объединять символы и вообще хоть на арабском писать, просто атлас-текстура будет деномически расширяться.

__________________
Xash3D FWGS форк


Отправлено Дядя Миша 12-11-2019 в 08:44:

Цитата:
Crystallize писал:
На КСМ ты говорил что затиралку китайца работающую в 3D ты не будешь брать как жрущую память и время но у тебя есть своя которая работает в 2D и она основана на аналогичных механизмах из Сорса.

Вообще всё напутал. У Китайца - не затиралка. У Китайца - наоборот, механизм не допускающий появления швов (по возможности), за счёт конвертирования текстурного пространства одного сурфейса в другое. Это делается при помощи расстановки маркеров-точек на границах полигона, что напоминает один из шагов алгоритма по затиранию швов, но таковым не является. То что в сорсе - это радиальный блур для индиректа, швы он не затирает, ну может немного замаскировать конечно, как и любой другой блур. Это можно посмотреть и в самом сорсе - там швы никуда не делись.
Я этот радиальный блур убрал впоследствии, т.к. толку от него немного. Но да, он быстрый.

Добавлено 12-11-2019 в 11:40:

Цитата:
FiEctro писал:
всё это битмаповое гамно должен кто то рисовать

Генератор фонтов из TTF.

Добавлено 12-11-2019 в 11:44:

Чтобы не было швов, надо использовать непрерывный атлас где смежные рёбра в 3д являются таковыми и в самом атласе, понятно, что это условие невозможно выполнить в 100% случае, но для углов свыше 50 градусов это и ненужно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 12-11-2019 в 08:48:

>> Генератор фонтов из TTF.

Ну найди для первокваки например такой.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 12-11-2019 в 20:31:

Ну вот, теперь и спрайты рисуются

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 12-11-2019 в 20:53:

Дядя Миша
Полноцветные?


Отправлено Crystallize 13-11-2019 в 03:08:

nemyax Ишь!


Отправлено Дядя Миша 13-11-2019 в 09:33:

nemyax обычные. Форматы менять - хаммер не поймет, как работать будете? Тут нужны предварительные договорённости.

Добавлено 13-11-2019 в 12:31:

Мне еще предстоить сделать mod_skybox, mod_grass и mod_particle.
Формировать какие-то списки отрисовки для каждого типа примитивов бессмысленно - их же рендерер в кадре сортирует. Поэтому абстракция должна выглядеть так. С лучами аналогично, но лучи станут частью mod_sprite.

Добавлено 13-11-2019 в 12:32:

А mod_skybox скорее всего будет отвечать за погоду, ну там дождь, снег, облака, время суток.

Добавлено 13-11-2019 в 12:33:

Самое сложное избавиться от долбаных рендермодов в движке.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 13-11-2019 в 09:35:

Цитата:
Дядя Миша писал:
как работать будете?

Будем вешать модельку-плашку на резвый танк =)


Отправлено Дядя Миша 13-11-2019 в 09:59:

Вообще говоря реальных рендермодов, если продолжать и дальше такое деление, существует две штуки на каждый из режимов рендеринга геометрии. А режимы рендеринга геометрии понятно какие - непрозрачные и прозрачные. Так вот вариации на тему - это соответственно с освещением и без. В эти четыре кейса укладывается абсолютно любой запрос, ну кроме может быть этих старых фейковых гларесов, которые светили сквозь геометрию, но они это делали скорее неотхорошей жизни, а из-за того что шейдеров не было.

Добавлено 13-11-2019 в 12:42:

Теперь что касается смены одного рендермода на другой. Хотя в халфе и подразумевается возможность поменять любой на любой, но в реальности это никто не пользует, просто нет смысла. Вся замена это - прозрачный на непрозрачный и наоборот. Ну и опционально - включение фуллбрайта, но для солидных мешей в халфе это нереализуемо попросту. Там делали два меша, один фуллбрайт, другой нормально освщённый и меняли один на другой с помощью прозрачности.

Добавлено 13-11-2019 в 12:52:

Здесь thambs неявно опять поднял проблему скриптового языка, для описания энтить, но у меня признаться нет каких-то особых идей на этот счёт. Понимаете, все эти скрипты отлично работают на картах квейк-стайл, когда ты уровень прошёл и всё, больше туда не возвращаешься. Но на халфовских сейв-ресторах, когда ты можешь бесконечно нарезать круги по одним и тем же локациям, это вызывает массу вопросов. Во первых эти сами скрипты, они запускаются как в hlfx из какой-то энтити типо script_lua или из файлика с именем карты?
А если они дают эффект на энтить, которая может перемещаться на другой уровень вслед за игроком? Я напоминю, НИГДЕ я не видел, чтобы можно было брать с собой энтити с одного уровня на другой явным образом. Нигде.
Только неявным, через инвентарь. Или по скрипту, что фейк. Но вот так, чтобы игрок какого-то перса тыкнул, мол пойдем со мной и провёл его через всю игру - этого нет нигде. И это очень осложняет подключение внешних скриптов. Если скрипты пишутся для конкретной карты, как понять, что их исполнение нужно забрать на следующую карту? Если скрипт написан для какой-то энтити, как корректно перенести его состояние вместе с этой энтитью? Это практически неразрешимая задача. Я собсно, потому и не спешу внедрять какие-то скрипты, а пытаюсь всё описать внутри самиъ энтить. Но если у вас есть какие-то идеи концепции, то я вас слушаю.

Добавлено 13-11-2019 в 12:55:

Когда логическая энтить образует какую-то скриптовую конструкцию, мы можем её просто пометить, что она должна переходить на другой уровень.
Но в рамках скриптового языка мы не можем, написать, что вот эти функции должны, например работать где-то еще причём с переменными с этой же карты, потому что возникнет неизбежный вопрос, откуда брать эти сами переменные? С энтить? Тогда в чём вообще смысл скрипта? Из какого-то глобального пространства? Тогда как определить что они не пойдут на следующий уровень?

Добавлено 13-11-2019 в 12:59:

У меня еще был вариант, в скриптах описать сами энтити, например реализующие сложные логические условия, но и тут не всё гладко. У скриптов не будет полноценного доступа к настоящим энтитям. И наоборот тоже не очень понятно. Скорее всего они смогут выполнять только простейшие действия, типо активации цели, сеторигин и так далее. Выход из положения напрашивается сам собой - надо как в ку1 сделать виртуальную машинку подо все энтити. Но и тут проблема - как прикажете рассчёт костей делать? Тоже в куси? А поиск навигации для монстров, шедули эти все? Неподъемно для виртуалки, слишком тяжело.
Не знаю вообщем.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 13-11-2019 в 10:01:

Дядя Миша
Соображения есть, но пока не готов расписать, нужно ещё продумать всё. Сначала вопросы:
1. Есть ли в игре возможность явного доступа на чтение к полям энтити, например к таргетнэйму, ориджину и пр.?
2. Если ли возможность явного доступа к полям на запись, если есть, то как они защищены/не защищены?
3. В каком виде сервер сохраняет состояние энтить, как она сериализуется?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 13-11-2019 в 10:06:

Плюс если делать виртуалку, там придётся учитывать наследование классов, для того чтобы, оно отвечало текущей иерархии дллки, которая оптимизирует эти классы под новую структуру движка. Ну скажем, студиомодельки теперь работают только из класса CBaseAnimating, потому что это единственный класс, который занимается сетапом костей.

Добавлено 13-11-2019 в 13:06:

Цитата:
thambs писал:
Соображения есть, но пока не готов расписать, нужно ещё продумать всё. Сначала вопросы:
1. Есть ли в игре возможность явного доступа на чтение к полям энтити, например к таргетнэйму, ориджину и пр.?
2. Если ли возможность явного доступа к полям на запись, если есть, то как они защищены/не защищены?
3. В каком виде сервер сохраняет состояние энтить, как она сериализуется?

1. Что значит в игре? Ну очевидно у игрового движка в целом (ядро+геймкод), если полномочия модицифировать абсолютно всё по своему усмотрению, я ж говорю, что даже новое бсп-дерево налету строю при загрузке. Таргетнеймы никто не модифицирует, просто потому что в этом нет смысла, а не потому что нет доступа.

2. опять не понял. Что значит "поля" ? Куда их записать? В энтпатч?

3. Хм. https://www.hlfx.ru/forum/showthrea...=&threadid=3394

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 13-11-2019 в 11:29:

Дядя Миша
Насколько я понимаю, скриптинг обычно реализуют именно в виртуальной машинке и на основе отправки-приёма ивентов между скриптованными сущностями.

Цитата:
Дядя Миша писал:
эти сами скрипты, они запускаются как в hlfx из какой-то энтити типо script_lua или из файлика с именем карты?

Например, имя скрипта может быть указано для энтити в поле script, а сам скрипт с этим именем быть определён в игровых файлах.

Цитата:
Дядя Миша писал:
Если скрипты пишутся для конкретной карты, как понять, что их исполнение нужно забрать на следующую карту?

При инициализации на карте скрипт может гетать своих действующих лиц по имени и дальше работать с ними, если всех нашёл.


Отправлено Дядя Миша 13-11-2019 в 11:38:

Цитата:
nemyax писал:
на основе отправки-приёма ивентов между скриптованными сущностями.

ивенты - это вызов целей на карте, это и так есть безо всякой скрипт-машины.

Цитата:
nemyax писал:
имя скрипта может быть указано для энтити в поле script

и сам скрипт в скомпилированном виде тоже перемещать между уровнями? Со всеми стейтами?

Добавлено 13-11-2019 в 14:38:

В D3 кстати так и сделано, там скрипты даже положение стека запоминают.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 13-11-2019 в 12:00:

Вызов цели это всего лишь одна разновидность ивента. Бывают и другие. Взять те же префиксы, которые через задницу реализуют кокрастоке разные типы ивентов.
И да, без скрипта ты не запрограммируешь обработку принятого ивента.


Отправлено Дядя Миша 13-11-2019 в 12:18:

Скриптовой язык, это ведь не только операции, это еще и переменные.
Переменные через энтити конечно тоже доступны - env_local, env_global, но пока их немного, и они в сущности практически булевы. В скриптах же так не получится, надо как-то придётся указать, что вот эти переменные относятся к той или иной энтите, которая потом потенциально уедет на новый уровень. То есть либо эти скрипты так задавить ограничениями, что они не будут особо отличаться от скриптования энтитями, либо одно из двух.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 13-11-2019 в 12:25:

Цитата:
Дядя Миша писал:
Переменные через энтити конечно тоже доступны - env_local, env_global, но пока их немного

Что за переменные? Их можно натолкать свойствами в отдельную энтить, переходящую между уровнями и доступную скриптам для чтения-записи?


Отправлено Дядя Миша 13-11-2019 в 12:26:

Кстати говоря, в халфе када лепили свою скрипт-систему это отлично понимали, поэтому она у них умеет только групповой вызов целей, скрин-фейд, ну и прогрывание сентенций. Никаких переменных там и близко нету.

Добавлено 13-11-2019 в 15:26:

Цитата:
nemyax писал:
Что за переменные?

да я почём знаю. Но язык без переменных, это уже и не язык вовсе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 13-11-2019 в 12:41:

Цитата:
Дядя Миша писал:
Но язык без переменных, это уже и не язык вовсе.

Пусть в скрипте и определяются. Ну там я не знаю:
code:
class mcguffin { entity target1; entity target2; void on_init(void); void on_kill(void); }; void mcguffin::on_init() { target1 = entities.get("entity14"); target2 = entities.get("entity88"); } void mcguffin::on_kill() { events.kill(target1); events.kill(target2); die(); }


Отправлено XaeroX 13-11-2019 в 12:56:

Я думаю, что скриптовым языком в ксаше просто обязан стать Haskell.
Представьте себе, какое удовольствие будут получать мапперы, когда смогут реализовать сложнейшую функциональную взаимосвязь всего несколькими строчками и без переменных.

__________________

xaerox on Vivino


Отправлено Дядя Миша 13-11-2019 в 13:01:

nemyax то что ты привёл - это скрипт над объектами.

Добавлено 13-11-2019 в 16:01:

Цитата:
XaeroX писал:
обязан стать Haskell

Да нет не ко-кова Хаскеля

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 13-11-2019 в 13:02:

Дядя Миша
Есть, есть.

__________________

xaerox on Vivino


Отправлено nemyax 13-11-2019 в 13:04:

Цитата:
Дядя Миша писал:
то что ты привёл - это скрипт над объектами

А над чем надо?


Отправлено Дядя Миша 13-11-2019 в 13:08:

nemyax ну, как продолжение самих объектов, например.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 13-11-2019 в 13:30:

Дядя Миша
Я имел в виду, что этот скрипт можно связать с любой энтитью, и у неё появится этот конкретный обработчик ивента kill. При kill-е любой такой энтити она поведёт себя так, как определено в скрипте. А например on_use здесь не определено, поэтому на use она реагировать не будет.

Добавлено 13-11-2019 в 16:30:

Либо пусть запускает дефолтную реакцию энтити на ивент, если обработчик не определён. А чтобы отключить реакцию, явно прописывать в классе void on_hurt(float) {} или void on_hide(void) {return;}.


Отправлено Дядя Миша 13-11-2019 в 14:25:

Если просто ограничить скрипты вызовом эвентов, ну просто разгрузить карту от нагромождения логических энтить, то какой-то смысл в этом есть. Ну, послушаем, что Тхамбс предложит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 13-11-2019 в 15:36:

Я не вкуриваю почему нельзя пропарсить все карты мода и отслеживать все инкарнации одной и той же энтити на разных картах и отслеживать все её исчезания и появления на картах которые происходят когда игрок утащил энтитю с карты через одну дверь и потом притащил с другой карты через другую дверь.


Отправлено Дядя Миша 13-11-2019 в 16:55:

Crystallize какое отношение твои слова имеют к скриптам?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 13-11-2019 в 16:56:

Crystallize
При чём тут карты мода? Они лежат себе и не меняются.


Отправлено Дядя Миша 13-11-2019 в 20:25:

Это всё хорошо, но вот и настала пора для моих любимых экспериментоф.
Как вы помните я уже много всего опробовал, оттестировал, но кое-что еще у меня осталось в запасе. Специально для NT оставил, т.к. на старом ксаше такое было затруднительно тестировать. Я конечно апробую еще некоторые технологии в графике, но навряд ли это займет много времени, сейчас механизмы рендеринга максимально благоприятствуют экспериментам. А вот из отложенных про запас у нас остался извечный спор с Камрадом Ксероксом - так ли уж плох или хорош BSP46, в народе известный как ку3бсп. Ксерокс считает что формат годится для современных задач, надо только добавить в него лайтстили и еще пару мелочей. Я в свою очередь наоборот полагаю, что с учётом всего, что я сделал для развития халфовского формата карт, актуальность кутришного бсп под большим вопросом. Под кутришным бсп я разумею принцип построения дерева и хранения данных, бинарная совместимость особой роли не играет.
Впрочем моё исследование предполагается достаточно обширным, в качестве побочного эффекта, я наверное даже напишу новые компиляторы уровней для ку3. Собсно, я их еще в прошлом году писать начал, но пока остановил процесс. Наверное заведу под них отдельную тему.

Добавлено 13-11-2019 в 23:25:

Тема про компиляторы тут: https://hlfx.ru/forum/showthread.php?s=&threadid=5398

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 13-11-2019 в 20:58:

По каким критериям будет оцениваться плохость или хорошесть BSP46?


Отправлено Дядя Миша 14-11-2019 в 07:54:

Скорее пригодность для моих задач. Тут и так не очень простая ситуация - я уже могу в халфовский формат скомпилить любую кутришную карту.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 14-11-2019 в 21:41:

Загрузил лайтмапы. В ку3 там уже и так страницы атласа, но мелкие 128х128. Неудобно. Я придумал оригинальную абстракцию - представил страницы лайтмап как будто сурфейсы с лайтмапами 128х128 и загрузил их как эти сурфейсы. Ну чтобы не переделывать лайтмаппер под новый принцип. Надо только придумать как на вертексах сдвинуть оффсет st. ну то решаемая задача, в куфужене чот такое делают. Как же давно я в посл. раз загружал кутришные карты. в 2009-м году.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 15-11-2019 в 08:52:

Сколько же дури в этом кутри. Вот скажем взять эти патчи. Вот зачем их налиту строить во время загрузки? Почему нельзя было просто сохранить в карту? Опять же непонятно, как считается лайтмапа для такой текучей конструкции с переменной детализацией. Патчи, это абстракция, которая вообще не должна покидать компиляторы. Её взяли и засунули в рендерер. Ради автолодов, понятно. Вы помните эти автолоды? Трубу сделаешь, отошёл на пять шагов, она восьмиугольной стала. Зашибись оптимизация.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 15-11-2019 в 09:50:

Цитата:
Дядя Миша писал:
Сколько же дури в этом кутри. Вот скажем взять эти патчи. Вот зачем их налиту строить во время загрузки? Почему нельзя было просто сохранить в карту?


А как пидорасы по трубам лазить будут?

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено XaeroX 15-11-2019 в 10:56:

Дядя Миша просто не умеет работать с патчами.
В PW, кстати, они активно используются, и не только для труб, но и для геометрии уровня. Вот и скажете потом, сильно ли смена лодов бросается в глаза на патчах. По-моему, на моделях - сильнее, если присматриваться.

__________________

xaerox on Vivino


Отправлено Дядя Миша 15-11-2019 в 11:22:

FiEctro ДА НЕ КАК

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 15-11-2019 в 15:26:

Цитата:
Дядя Миша писал:
Не гадить, а подготавливать особенным образом. Тот же кутри лишён CSG, там вся внутренняя хрень, которая исчезает при препроцессинге, здесь радостно остаётся. И для нее тоже считается лайтмапа. На иных картах залетишь вот так в стенку, а внутри - еще одна стенка и на ней лайтмапа посчитана. Конечно это лучше. Щас во всех играх такое.

А можно сохранить только ту часть механизма CSG которая про отрезание пересекающихся брашей, выкинув дальнейшее разбиение-склеивание?


Отправлено Дядя Миша 15-11-2019 в 16:00:

Цитата:
Crystallize писал:
только ту часть механизма CSG которая про отрезание пересекающихся брашей, выкинув дальнейшее разбиение-склеивание?

так это и есть одна операция. В q3map2 действительно попытались сделать, на полшышечки, ну вроде как ты себе нафантазировал, оно и не резало и не склеивало, так, только время отымало.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 18-11-2019 в 19:35:

Первые опыты. Чё, его так плющит, понять не могу. Наверное индексы где-то напутал.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 18-11-2019 в 19:54:

Вторые опыты. Теперь надо патчи нагенерить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 18-11-2019 в 23:45:

Мысли по поводу скриптовой системы #1: возможная структура и юзкейсы

Цитата:
послушаем, что Тхамбс предложит.


Буду исходить из того, что скриптовая система не должна заменять или ломать существующий набор сущностей, а призвана скорее её дополнить и расширить, сделав более гибкой. Вообще-то говоря, сущности — довольно удобная штука и в 90% (условно) игровых механик какие-то дополнительные движения не требуются. Проблемы же начинаются тогда, когда из этих сущностей приходится городить сложные цепочки, вводить "логические энтити" и пр чертовщину. По моему опыту, использование более чем 5 сущностей в одном механизме создаёт путанницу, и чем дальше тем хуже. Особенно неудобно бывает, когда одна и та же цепочка сущностей используется в разных местах карты — приходится вручную переименовывать ключи, что тоже приводит ошибкам. Отчасти, это решается с помощью пре-процессинга .map-файла, но это не то что бы сильно универсальное решение, да и к тому же не избавляет от необходимости писать эти цепочки в .ent-файле, который остаётся сильно многословным в сравнении с той же функциональностью, выраженной на любом императивном яп.

О зле. На мой взгляд, основной источник зла — это т.н. "логические энтити", а точнее черезмерное их использование. Игровая логика в doom или quake была довольно проста: расставил монстров, связал кнопку с дверью, а дверь с ключ-картой, триггер — с ловушкой, и готово. Более комплексные игровые механики привели к разрастанию и непомерному усложнению всей системы. И самая пакость связана с тем, что, помимо сложности, система стала фактически "write only" — из-за того что при редактировании работаешь с одной энтитей за раз, то отладка/изменение сценария напоминает работу с древним БАСИКом — тем самым, в котором строки нумеровались цифрами, и редактор позволял работать только с одной строкой. А ведь, зачастую, эти самые сущности на карте расположены в разных местах и совершенно не обязательно как-то логически упорядочены.

О команде fire. Кстати, ещё в sauerbraten видел интересную штуку, оно конечно только proof of concept, для реальных применений не годится, но тем не менее. Ведь там совсем небыло энтить, а для манипуляции игровой логики был внутренний скриптовый язык. Причём скрипты на нём могли быть как во внешних файлах, подключаемых к карте, так и вызываться непосредственно из консоли, с такими же результатами. Мне это напомнило команду fire из спирита/ксаша в связке с trigger_command и те совершенно невозможные штуки, которые с помощью них делал доктортресни. Одного fire, конечно маловато.

О интерфейсе.Команда fire и поле target, фактически, позволяют передать некоторые параметры/сигналы сущности, но с большими ограничениями. Ещё есть changetarget, changeparent, env_render и всё, собственно. Что бы наблюдать за состоянием энтить — multi_watcher, но ему тоже доступен весьма ограниченный набор параметров. Наверное, имело бы смысл некоторое универсальное API, позволяющее передавать и получать от энтить любые допустимые параметры и проводить с ними операции. Не ломая существующую систему, можно было бы, например, ввести вызовы:
C++ Source Code:
$set(*entity, key, value) -> status
$get(*entity, key) -> value
$find(*world, mask) -> [*entity]

Из названий понятно: $set — установить пару ключ-значение для сущности
*entity; вернуть статус или неудачу, $get — получить значение, $find — сформировать список указателей на сущности с именем/класснеймом таким-то маске или значению, а world -- указатель на текущую карту. Сами функции, естественно, не содержат внутренних состояний.
Предположим, теперь, что у нас есть какой-то механизм сохранения состояний и обычные языковые конструкции. Добавим функцию асинхронной задержки:
C++ Source Code:
$sleep(time)

Тогда эти 4-вызова, тогда позволяют полностью заменить мульти_манаджеры/вотчеры, реле, энв_рендеры и пр. Возможные примеры использования дам дальше, пока о памяти.

При работе с памятью видится несколько кейсов. Предполагается, что скрипт может быть или глобальным (в масштабах карты), или связанным с какой-либо сущностью. При этом, у последней получается свой локальный нэймспейс. Так-как хочется работать с чистыми функциями и использовать обычную систему сохранений, то хранить какие-то состояния наверное лучше всего было-бы в каком ни будь специальном поле внутри самой сущности. Но я, к сожалению, так и не разбирался как у тебя сериализация устроена, возможно-ли туда затолкать полиморфный, изменяемый объект? И, если в функции есть вызовы $sleep, то, видимо нужно будет сохранять весь её стек...

Что же касается низкоуровнего выделения/освобождения, то наверное, самым разумным было-бы использовать RAII: выделяем память под переменную в том случае, если она синтаксически связалась с литералом, освобождаем (по мере необходимости) как литерал вышел из поля видимости. Например, пустой вызов:
C++ Source Code:
$find(*world, "func_door:storage*")

Не делает ничего,
C++ Source Code:
lst = $find(*world, "func_door:storage*")

связывает литерал lst с результатом вызова и храним его пока он в области видимости, или пока не вызвали какой ни будь $del(lst). При этом, соответственно, синтаксис не должен позволять существование несвязанного литерала, а если литералу присвоено новое значение, то старое удаляется.

Вызовы. Есть ещё момент, когда нужно вызвать скрипт автоматически, по наступлении определённых условий. Наверное, тут было-бы удобно тогда добавить внешний обработчкик. Например, указать в корне скрипта
C++ Source Code:
1
//следим за условиями
2
watch(){
3
  if cond1 { ... }
4
    if cond2 { ... }
5
    }


Общая структура. Таким образом, вырисовывается какая-то такая структура скрипта:
C++ Source Code:
1
/* определяем сохраняемые поля */
2
@static var1 = ...
3
@static var2 = ...
4
/* определяем обработчики */
5
spawn(...)
6
watch(...)
7
call(...)
8
/* определяем всякие вспомогательные функции */
9
...


Юзкейс: поезд с колёсиками. Есть, например, префаб фанк_трейна, к нему приделаны колёсики, env_shake, фонарики, убивалки. Хочется, что бы колёсики синхронно вращались и частота тряски менялась в зависимости от скорости, фонарики красные зажигались на заднем ходу, дым там из трубы ну и всё такое. Пишем у поезда в строке скрипт имя скрипта а в самом нём что-то такое:
C++ Source Code:
1
@static wheels = $find(*world, $get(*this, "targetname")+"_wheels")
2
@const  radius = 6
3
watch(){
4
  v_old = $get(*this, "v_old");
5
  v_new = $get(*this, "v_new")
6
  if v_old neq v_new{
7
    for( wheel : wheels){
8
      $set(*wheel, "speed", v_new/radius)
9
    }
10
  }
11
}


Юзкейс: универсальная станция для поезда с дверкой. Поезд активирует скрипт станции, а станция узнаёт имя поезда, имя дверки, открывает её, закрывает e`, вносит поправки в расписание и пр.

Юзкейс: управление персоналом. Есть, например, некоторая зона, на которой расставлены scripted_sequence и бегают доктора. Хочется создать иллюзию жизни на этой локации. Каждая скриптед секвенция по завершению вызывает наш скрипт и передаёт локус доктора. Внутри выбираем что ему делать, куда идти и пр.

Юзкейс: диалоги. Цепочки из диалогов та ещё беда. По хорошему, всё это бы просто в команду $speak(*actor, *target, SENTENCE, time). Делаем какие угодно цепочки с каким угодно ветвлениями и рандомами, диалоговый скрипт можно привязать непосредственно к персонажу тем самым делая его уникальным.

Добавлено 19-11-2019 в 02:45:

Хм, да, сейчас понял, что семантика $find небезопасна, т.к. может возникнуть ситуация, когда в сохранении указатели на уже удалённые сущности. Значит этот момент надо по другому.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 19-11-2019 в 07:51:

Цитата:
thambs писал:
отладка/изменение сценария напоминает работу с древним БАСИКом

Да, это точное сравнение.

Цитата:
thambs писал:
когда в сохранении указатели на уже удалённые сущности.

ну это решено еще Вальвой. Нет такой проблемы.

Синтаксис конечно будет си-подобный, но основную мысль я понял - чтобы колёсики в такт тряслись поезду. Только вот поезд "перейдет" на другую карту, а как он там найдет этот скрипт?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 19-11-2019 в 09:29:

Дядя Миша
Ну основная идея что скрипт намертво привязывается к сущности. Т.е. у неё есть, например, поле script, в котором ссылка на текстовик, который читаем при загрузке карты, и есть какое-то скрытое поле, хранящее стек скрипта. Соответственно, паровозик переходит с карты на карту вместе со всей своей требухой что в скрипте насчиталась.

ps: я ещё обдумываю семантику и возможные варианты.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Crystallize 19-11-2019 в 10:17:

Цитата:
thambs писал:
Более комплексные игровые механики привели к разрастанию и непомерному усложнению всей системы.

И никто не смог её в полной мере заюзать кроме автора T.E.A. и нашего Доктора.

Цитата:
thambs писал:
то отладка/изменение сценария напоминает работу с древним БАСИКом

БАСИК должно быть даже удобнее чем энтити.

Цитата:
thambs писал:
$set(*entity, key, value) -> status
$get(*entity, key) -> value
$find(*world, mask) -> [*entity]

Тебе комфортно набивать все эти доллары и аст-ириски?


Отправлено thambs 19-11-2019 в 10:22:

Crystallize
Плевать на синтаксис, ДМ сделает как считает нужно. Давайте лучше семантику обсуждать.

Цитата:
кроме автора T.E.A. и нашего Доктора

Автор HC2 ещё, он правда совсем маньяк, но в основном использовал env_render -- следовал за авторами блю-шифта.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено XaeroX 19-11-2019 в 11:29:

Цитата:
Crystallize писал:
Тебе комфортно набивать все эти доллары и аст-ириски?

Всем похапешникам комфортно.

__________________

xaerox on Vivino


Отправлено FiEctro 19-11-2019 в 12:16:

>> $find(*world, "func_door:storage*")

Ну и дичь лютую вы удумали, писать скрипт под конкретную карту, для каждой сущности. Ещё и трахаться с ДЕБАЖИТЬ отладкой этих финдов.

Что мешает просто подгружать файл скрипта как отдельную сущность со своими полями? Написали какой нибудь trigger_butthurt.qc, если есть на карте он, то он подгрузился, если нет, то нет. Как во всех современных движках. А наследования в скриптах делать по классике, через объявление public/private и т.п.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено nemyax 19-11-2019 в 12:30:

Цитата:
FiEctro писал:
писать скрипт под конкретную карту, для каждой сущности

Где ты увидел "для каждой"?


Отправлено thambs 19-11-2019 в 13:05:

FiEctro
Ответь, почему ты так нагло ПЕРЕВИРАЕШЬ то что я писал?

Цитата:
Написали какой нибудь trigger_butthurt.qc

А ведь, я вообще не писал о том что бы создавать новые сущности, только о том как мог бы выглядеть механизм более тонкого и настраиваемого взаимодействия между существующими.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 19-11-2019 в 14:37:

Сгенерил патчи на кутришной карте, ну вроде норм - язык пропал (на q3dm1), как корова в реке утопила. Да что за бред, начал разбираться.
Оптимизатор отключаешь - язык на месте, остальное в порядке. Ну где я мог накосячить? Очевидно нигде. Расковырял функцию оптимизатора - там ошибка. Это походу уже становится традицией.

Добавлено 19-11-2019 в 17:37:

ЗЫ. Оптимизатор из OverDose если что. Не из ку3.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 19-11-2019 в 15:02:

Что оптимизирует оптимизатор?


Отправлено a1batross 19-11-2019 в 15:11:

Оптимизатор оптимизирует брашевые языки, вестимо.

__________________
Xash3D FWGS форк


Отправлено FiEctro 19-11-2019 в 15:39:

Цитата:
thambs писал:
FiEctro
Ответь, почему ты так нагло ПЕРЕВИРАЕШЬ то что я писал?


Да потому что это не интуитивно и запутанно. Что даже здесь я видимо не понял твоей полной задумки.

Цитата:
thambs писал:
FiEctro
А ведь, я вообще не писал о том что бы создавать новые сущности, только о том как мог бы выглядеть механизм более тонкого и настраиваемого взаимодействия между существующими.


Сущность это класс или скрипт, с одним единственным отличием - он прописан прямо в дллке. Ставя его на карту, мы лишь указываем ему значения переменных, абстрогируйся от этого. По мне очень здорово представлять сущность именно как отдельный скрипт, а не логические операции. Механизм каждый сможет подстроить под себя.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 19-11-2019 в 17:15:

Финальный результат.
Кутришные шейдеры прекрасно заменяются моей системой материалов, даже при отсутствии специализированных GLSL-шейдеров для кутришных заморочек. ну типа мигающих текстур, пидарасов, которые, как известно, ползут по трубам итак далее. Но всё это реализуется в пользовательской части, рендерер трогать не надо.
Для сравнения, тепичный кутришный шейдер, который ничего не делает, а просто заменяет путь к текстуре:

C++ Source Code:
1
textures/skin/surface8_trans
2
{
3
  qer_editorimage textures/skin/surface8.tga
4
  surfaceparm nonsolid
5
  {
6
    map $lightmap
7
    rgbGen identity
8
 
9
  }
10
  {
11
    map textures/skin/surface8.tga
12
    rgbGen identity
13
    blendFunc GL_DST_COLOR GL_ZERO
14
 
15
 
16
  }
17
}

И его аналог в моей системе материалов
C++ Source Code:
1
textures/skin/surface8_trans
2
{
3
  image u_ColorMap = "textures/skin/surface8.tga";
4
}

Если надо светящийся материал, то вот так
C++ Source Code:
1
textures/liquids/lavahellflat_400
2
{
3
  image u_ColorMap = "textures/liquids/lavahell.tga";
4
#define LIGHTING_FULLBRIGHT
5
}

причём сам этот дефайн - он тоже пользовательский. Движок про него не знает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 19-11-2019 в 17:22:

Дядя Миша
По трубам, я так понимаю, ползать никто под ксашем не будет? Или можно самому написать шейдер? Если да, то как это будет выглядеть?

__________________

xaerox on Vivino


Отправлено Дядя Миша 19-11-2019 в 17:28:

Хм, картинку забыл.

Добавлено 19-11-2019 в 20:28:

Цитата:
XaeroX писал:
По трубам, я так понимаю, ползать никто под ксашем не будет? Или можно самому написать шейдер? Если да, то как это будет выглядеть?

Да, надо GLSL-шйдер написать и всё заползает. Выглядеть будет идентично ктури. Единственная проблема моей системы - я до сих пор не придумал как задавать анимацию. Не поддерживается она у меня пока что.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 19-11-2019 в 17:37:

Цитата:
Дядя Миша писал:
Да, надо GLSL-шйдер написать и всё заползает. Выглядеть будет идентично ктури.

Разве они не про монстров ползучих по стенам, как в думтри и свене? И ку2?

Добавлено 20-11-2019 в 00:37:

Цитата:
Дядя Миша писал:
u_ColorMap

Как получился такой термин? Юниформ? Если бы я не знал то подумал бы что это кастомная палитра текстуры, яркая как в Анриле (u).


Отправлено Дядя Миша 19-11-2019 в 17:40:

Цитата:
Crystallize писал:
Как получился такой термин? Юниформ?

да. Можно назвать как угодно. Я придерживаюсь такой терминологии.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 19-11-2019 в 18:05:

Дядя Миша
А покежь Renderer: Dynamic.


Отправлено Дядя Миша 19-11-2019 в 18:23:

Нету ищо.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 20-11-2019 в 07:39:

Как история повторяется циклически, так и ДМ прикручивает ку3 формат циклически к ксашу.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 20-11-2019 в 09:44:

Вам возможно будет интересно, но в этот раз для кутришного формата я использовал все сабраутины от первой кваки. Кроме конечно разжатия PVS, поскольку в кутри PVS и так несжатый
Всё подходит.

Добавлено 20-11-2019 в 12:28:

Сделал вчера предварительный тест производительности. Там где эта же карта в халфовском формате выдаёт 400 фпс, кутришная выдаёт 700, но судить пока рано - я к примеру не подключил еще физику, она вполне может сбить итоговый фпс. Впрочем причины понятны - те же патчи рисуются как стрипы. Конечно это будет быстрее чем в халфовском формате, где всё отдельными трианглами. Плюс в кутри и сами секвенции гораздо длиннее. Продолжаю исследование.

Добавлено 20-11-2019 в 12:44:

Вообще у меня есть вот какая идейка. Если я ЧАЭС вкомпилю как встроенную модель со всеми стрипами, а дерево само её рассечёт на квадраты 1024х1024. Видимость это конечно посчитать не поможет, но как минимум куллиться будет эффективнее. Ну это позже.
Для меня есть одна загадка - я не понимаю как в движках организованы лайтстили без какой-либо привязки к лайтстилю. Вот вроде бы говорят, что в сталкере этих лайтмап можно насчитать сколько угодно, хоть для 12-и положений солнца. Судя по всему это не учитывает остальные источники, лайтмапы просто дублируются для них. И в унреале есть подобная замута.
Надо будет с этим разобраться.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 20-11-2019 в 21:20:

Ну что же. Пожалуй пришла пора реально реализовать функционал кутришных шейдеров, не затрагивая код рендерера - только через новую скриптовую систему. Посмотрим что у меня получится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 21-11-2019 в 08:01:

Цитата:
Дядя Миша писал:
надо GLSL-шйдер написать и всё заползает

Только фрагментник или вершинник тоже?


Отправлено XaeroX 21-11-2019 в 08:02:

И геометрический!

__________________

xaerox on Vivino


Отправлено Дядя Миша 21-11-2019 в 17:37:

Вот вам две занятные картинки: Там где фпс выше - это кутришная оригинальная карта. там где ниже - эта же карта, скомпиленная в халфовский бсп. Особо обращаю ваше внимание на кол-во DIP.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 21-11-2019 в 17:53:

Дядя Миша
Откуда такой дип? Ты не сортируешь что ли?

__________________

xaerox on Vivino


Отправлено Дядя Миша 21-11-2019 в 18:21:

XaeroX сортирую, но для кутри сортировку не оптимизировал. Но как видишь - всё равно быстрее.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 21-11-2019 в 18:40:

О чем это говорит?


Отправлено Дядя Миша 22-11-2019 в 08:54:

Вот какую штуку я придумал. Тот формат записи, который есть сейчас, позволяет максимально подробно описать юниформы и текстурные юниты для шейдеров, но я подозреваю, что самим пользователям будет очень неудобно каждый раз такое прописывать. Это слишком общий формат записи, это для тех, кто будет создавать новые типы рендереров.
То есть каждый раз обозначать путь к текстуре таким образом:

C++ Source Code:
image u_ColorMap = "<textures/<modelname>/<texname>";

или явным образом
C++ Source Code:
image u_ColorMap = "textures/common/black.tga";

довольно таки неудобно. С юниформами аналогичная ситуация, но в то же время это оптимальный формат записи с точки зрения самого механизма и менять я его не намерен. Как же упростить эту задачу для пользователя?
И я придумал встроить поверх этой системы дополнительно простенький макро-язык, который сможет заменять key-value pair (ну в действительности сколько угодно аргументов) на необходимую нам строку.
То есть мы пишем что-то вроде
C++ Source Code:
#keydef map <value>\
image u_ColorMap = "<value>";

а при парсинге оно находит наши строки
C++ Source Code:
map textures\common\black.tga

и автоматически их заменяет на то что мы указали. А для лайтмапы, скажем
C++ Source Code:
#keydef map $lightmap\
image u_LightMap = "entity->$LightmapTexture";

Ну это просто как пример, в реальности будет несколько сложнее. Плюс в том, что мы таким образом сможем описать практически любую из существующих систем материалов или создать свою собственную.
Достаточно описать все ключевые конструкции кутришных шейдеров и всё это распарсится в исходную систему налиту. Или аналогично указать не кутришные ключевые слова, а параноевские. Ну единственно надо будет хорошо продумать правила автозамены.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 22-11-2019 в 11:21:

Цитата:
сможем описать практически любую из существующих систем материалов или создать свою собственную

Прям мета-система какая-то.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 22-11-2019 в 11:44:

Можно провести аналогии с тем же С++. Там ведь тоже есть макросы.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 23-11-2019 в 16:01:

Дядя Миша
Скажи, а вот эту гадость с полупрозрачностью в новой системе удалось забороть?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 23-11-2019 в 16:57:

Эту "гадость" еще ни одному человеку на планете забороть не удалось и едва ли это вообще возможно. Впрочем, я еще не занимался стёклами.

Добавлено 23-11-2019 в 19:57:

В кутри это бороли повертексным освещением, но тогда прощай тени на стёклах. Дилемма.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 24-11-2019 в 13:55:

Трассировкой-то борют.


Отправлено Дядя Миша 24-11-2019 в 16:33:

Тут для солидных тел не могут толком трассировку наладить, а ты на полупрозрачные замахнулся, очуметь можно.

Добавлено 24-11-2019 в 19:23:

Довольно сложная штука этот макро-язык получается. Но по другому никак, ведь мы фактически задаём все юниформы и текстурные юниты из скрипта, тут не выйдет отделаться упрощённой формой записи - полезут разные нехорошие ограничения. А писать каждый раз полное выражение очень утомительно. Так что макро-замена тут идеальный выход. Это всё работает по принципу один раз настроил и больше не лазишь. Надо - еще добавил.

Добавлено 24-11-2019 в 19:26:

Сам макро-язык включает в себя три ключевых слова.
enum - это для макросчетчиков, которые можно инкременировать прямо во время макроподстановки, например для слоёв ландшафта или стадий в кутришном шейдере.
#keydef - заменяет одно регулярное выражение на другое. Пример:

C++ Source Code:
#keydef map <value>\
image u_ColorMap<unitNum> = "<value>";

второй аргумент - исходная переменная, путь к текстуре. А вот пример строгого соответствия
C++ Source Code:
#keydef map $lightmap\
image u_LightMap = "entity->$LightmapTexture";

Естественно, что у строгого соответствия приоритет выше.
ну и #define - заменяет одно слово на другое, без хитростей.
В принципе этого должно хватить, чтобы описать любую макроподстановку. Ну посмотрим.

Добавлено 24-11-2019 в 19:29:

А, да. <unitNum> в данном примере это как раз ссылка на счётчик, которая заменится на его текущее значение и получится строчка u_ColorMap0
Ну, разумеется к любой строке макро-подстановки это можно применять.
Сформированная финальная строка замены, просто подаётся на вход парсера, как будто бы она была в реальном файле и дальше парсинг происходит в обычном режиме.

Добавлено 24-11-2019 в 19:33:

И кстати это же правило действует на внутренние фигурные скобки, их тоже можно (и нужно) заменять.

У моей системы есть одно принципиальное ограничение - базовый формат, всегда должен иметь вид, типа

C++ Source Code:
materialName
{
}

Но для параноевских материалов и для кутришных шейдеров и для ку2-шных материалов из q2world и для дуумтришных материалов это требование соблюдается. Да и скорее всего еще много где, просто потому что это наиболее очевидный формат записи чего-либо. И вот эту конструкцию уже переопределить нельзя. Но не думаю, что это будет проблемой.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 25-11-2019 в 10:32:

Ну вот потихоньку ввожу в строй свои макросы. Вот текущие команды для замены в кутришных шейдерах:

C++ Source Code:
1
enum unitNum;
2
enum stageNumber;
3
enum texModCount;
4
enum deformCount;
5
 
6
// q3map keywords (just eliminate)
7
#keydef qer_editorimage <value>
8
#define q3map_noFog
9
#define q3map_globalTexture
10
#define q3map_nonplanar
11
#keydef q3map_shadeangle <a>
12
#keydef q3map_sunExt <a> <b> <c> <d> <e> <f> <g> <h>
13
#keydef q3map_skyLight <a> <b>
14
 
15
// surfaceparms, etc
16
#keydef surfaceparm <value>
17
#define nopicmip
18
 
19
// blendfunc replacements
20
#define GL_ZERO			0.0
21
#define GL_ONE			1.0
22
#define GL_SRC_COLOR		2.0
23
#define GL_DST_COLOR		3.0
24
#define GL_ONE_MINUS_SRC_COLOR	4.0
25
#define GL_ONE_MINUS_DST_COLOR	5.0
26
#define GL_SRC_ALPHA		6.0
27
#define GL_DST_ALPHA		7.0
28
#define GL_ONE_MINUS_SRC_ALPHA	8.0
29
#define GL_ONE_MINUS_DST_ALPHA	9.0
30
#define GL_ALPHA_SATURATE		10.0	// rare case
31
 
32
#keydef map <value>\
33
image u_ColorMap<unitNum> = "<value>";\
34
unitNum++;
35
 
36
#keydef map $lightmap\
37
image u_ColorMap<unitNum> = "entity->$LightmapTexture";\
38
unitNum++;
39
 
40
#keydef blendFunc <src> <dst>\
41
vec2 u_BlendFunc<unitNum> = vec2( <src>, <dst> );
42
 
43
#keydef {\
44
addShaderDefine( SHADER_STAGE<stageNumber> );
45
 
46
#keydef }\
47
stageNumber++;

#define в моём языке всегда задаёт строгое соответствие замены A на B или A на пустоту. Сишная фишка с функциями типа #define func(a,b,c) не поддерживается, поскольку в подавляющем большинстве материалов никаких функций просто нет, там именно keyvalue pair. И наоборот, у меня работает то, что нереализуемо на сишных макросах (но там это и не нужно).

Простой пример, для кутришного блендфунка. Шаблон автозамены
blendFunc <src> <dst>
превращается сперва в
vec2 u_BlendFunc<unitNum> = vec2( <src>, <dst> );
потом подставляется текущее значение энума <unitNum>, а потом система ищет переопределение GL_SRC_XXX, GL_DST_XXX и тоже их заменяет на цифры. То есть финальный результат автозамены будет выглядеть примерно так:
C++ Source Code:
vec2 u_BlendFunc2 = vec2( 6.0, 8.0 );

и уже этот результат снова подаётся на вход парсера, где и читается в обычном режиме, т.к. нативный формат записи. А в шейдере для blendFunc будут условия на выходные значения, соответствующие режимам смещевания (собсно так и переводят кутришные шейдеры на GLSL). Для каждого юнита, соответственно юниформ со своим номером.
А чтобы понять, какие юниты задействованы в шейдере, у нас есть команда addShaderDefine( SHADER_STAGE<stageNumber> );
где stageNumber точно так же превратится в текущее значение счётчика.
Ну разумеется, в шейдере эти #ifdef SHADER_STAGE0, #ifdef SHADER_STAGE1 придётся прописывать ручками, но нам понадобится один-единственный шейдер для описания абсолютно всех комбинаций кутришных материалов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 25-11-2019 в 12:40:

Дядя Миша
А это всё куда-то потом коптилируется, или каждый запуск налиту читается?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено nemyax 25-11-2019 в 13:08:

thambs
Заранее скомпиленные шейдеры вроде только в OpenGL 4.5 и новее поддерживаются. Обычно-то их компилят-линкуют-подключают при инициализации рендерера.


Отправлено XaeroX 25-11-2019 в 13:44:

nemyax
А вот в д3д всегда можно было бинарник с игрой распространять.

__________________

xaerox on Vivino


Отправлено Дядя Миша 25-11-2019 в 19:02:

Цитата:
thambs писал:
каждый запуск налиту читается?

каждый запуск читается налету, но это быстро. Это ж простая макро-подстановка и парсится она один раз при запуске движка.

Цитата:
nemyax писал:
Заранее скомпиленные шейдеры вроде только в OpenGL 4.5 и новее поддерживаются

так это вообще не шейдеры. Скомпиленные шейдеры у меня тоже поддерживаются.

Добавлено 25-11-2019 в 18:07:

Так, ну чтожы, я сделал макроподстановки для большинства случаев, ну покрайней мере чтобы материалы Edge Of Forever ни на что не ругались.
Теперь самое сложное - надо написать такой шейдер, который бы всё это корректно учитывал. То что я распарсил - это же просто параметры на вход шейдера, конвертация.

Добавлено 25-11-2019 в 18:09:

Для интерисующихся, пример тепичного шейдера. сконверченного в мою систему:
C++ Source Code:
1
textures/moteof/walltrim2
2
{
3
  <ShaderState>
4
  addShaderDefine( SHADER_STAGE0 )
5
  addShaderDefine( SHADER_STAGE1 )
6
  u_ColorMap0:-1 = *unused*;
7
  u_ColorMap1:-1 = *unused*;
8
  vec2 u_BlendFunc2;
9
}

диффузка + лайтмапа. Не пугайтесь странным значениям, это у меня дебаг-инфо недоделатый.

Добавлено 25-11-2019 в 18:10:

А вот шейдер с множеством стадий
C++ Source Code:
1
textures/moteof/water_healing
2
{
3
  <ShaderState>
4
  addShaderDefine( APPLY_DEFORM_VERTS0 )
5
  addShaderDefine( SHADER_STAGE0 )
6
  addShaderDefine( APPLY_VERTEXCOLOR0 )
7
  addShaderDefine( APPLY_COLORWAVE0 )
8
  addShaderDefine( APPLY_TEXMOD_TRANSFORM0_0 )
9
  addShaderDefine( APPLY_TEXMOD_TURB0_1 )
10
  addShaderDefine( SHADER_STAGE1 )
11
  addShaderDefine( APPLY_VERTEXCOLOR1 )
12
  addShaderDefine( APPLY_COLORWAVE1 )
13
  addShaderDefine( APPLY_TEXMOD_STRETCH1_0 )
14
  addShaderDefine( APPLY_TEXMOD_SCROLL1_1 )
15
  addShaderDefine( SHADER_STAGE2 )
16
  addShaderDefine( APPLY_VERTEXCOLOR2 )
17
  addShaderDefine( APPLY_COLORWAVE2 )
18
  addShaderDefine( APPLY_TEXMOD_TURB2_0 )
19
  addShaderDefine( SHADER_STAGE3 )
20
  addShaderDefine( APPLY_VERTEXCOLOR3 )
21
  addShaderDefine( APPLY_TEXMOD_STRETCH3_0 )
22
  addShaderDefine( APPLY_TEXMOD_TRANSFORM3_1 )
23
  addShaderDefine( APPLY_TEXMOD_ROTATE3_2 )
24
  u_ColorMap0:-1 = *unused*;
25
  u_ColorMap1:-1 = *unused*;
26
  u_ColorMap2:-1 = *unused*;
27
  u_ColorMap3:-1 = *unused*;
28
  vec2 u_WaveDeformFunc0;
29
  vec4 u_WaveDeformBase0;
30
  vec2 u_BlendFunc1;
31
  float u_rgbGenWaveFunc0;
32
  vec4 u_rgbGenWaveParams0;
33
  vec4 u_texModBase0_0;
34
  vec2 u_texModTrans0_0;
35
  vec4 u_texModTurb0_1;
36
  vec2 u_BlendFunc2;
37
  float u_rgbGenWaveFunc1;
38
  vec4 u_rgbGenWaveParams1;
39
  float u_texModWaveFunc1_0;
40
  vec4 u_texModWaveParams1_0;
41
  vec2 u_texModScroll1_1;
42
  vec2 u_BlendFunc3;
43
  float u_rgbGenWaveFunc2;
44
  vec4 u_rgbGenWaveParams2;
45
  vec4 u_texModTurb2_0;
46
  vec2 u_BlendFunc4;
47
  float u_texModWaveFunc3_0;
48
  vec4 u_texModWaveParams3_0;
49
  vec4 u_texModBase3_1;
50
  vec2 u_texModTrans3_1;
51
  float u_texModRotate3_2;
52
}

Впрочем старая проблема по прежнему остается - я так и не придумал как делать анимацию текстур. Но на этой карте её и нету.

Добавлено 25-11-2019 в 22:02:

Кстати, что касается времени такого парсинга с заменой. Оптимизировал функцию, теперь это занимает 0.3 секунды для полного пака кутришных шейдеров + еще шейдеров 500 от Сока для его карт и шейдеры для rustgrad.
Можно их еще хэшировать, но я думаю и так уже норм.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 26-11-2019 в 07:34:

Немного причесал дебаг, ну вот примерно так выглядят входные параметры распарсенного кутришного шейдера.

C++ Source Code:
1
textures/base_light/proto_lightred2
2
{
3
#define SHADER_STAGE0
4
#define SHADER_STAGE1
5
#define SHADER_STAGE2
6
#define APPLY_COLORWAVE2
7
  u_ColorMap0 = entity->$LightmapTexture;
8
  u_ColorMap1 = textures/base_light/proto_lightred.tga;
9
  u_ColorMap2 = textures/base_light/proto_lightred.tga;
10
  vec2 u_BlendFunc1 = vec2( 3, 0 );
11
  vec2 u_BlendFunc2 = vec2( 1, 1 );
12
  float u_rgbGenWaveFunc2 = 1;
13
  vec4 u_rgbGenWaveParams2 = vec4( 0.5, 0.5, 0, 1 );
14
}

Может я конечно буду менять организацию, но со скриптами это быстро.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 26-11-2019 в 07:47:

Выглядит очень переусложнённо в сравнении с самими ку3шными скриптами.
Да, возможностей больше - но они никому и не нужны. Сам же всем рассказывал, что мигающие лампочки нужны только Жэке в моде, а остальным достаточно статичных диффузки и нормалки.

__________________

xaerox on Vivino


Отправлено Дядя Миша 26-11-2019 в 07:53:

Цитата:
XaeroX писал:
Выглядит очень переусложнённо в сравнении с самими ку3шными скриптами.

то что я привёл - это скрытый промежуточный результат, который не виден пользователю. Это то, что подается на вход GLSL-шейдера. Ты правильно подметил, что это руками набивать - очуметь можно. А когда этим автозамена занимается - нормально.

Цитата:
XaeroX писал:
Да, возможностей больше - но они никому и не нужны

Смысл в том, что пользователь сможет создать свой мета-язык для описания материалов. Кутришные шейдеры в данном случае это стресс-тест для проверки возможностей системы. Так-то я планирую еще описать тепичные параноевские материалы, только теперь их значения будут не захардкодены, а тоже описаны в скрипте.

Добавлено 26-11-2019 в 10:53:

Кстати и волатиловские шейдеры я смогу описать точно так же
Т.е. это мета-язык для описания рендеринга, который вмещает в себя большинство форматов, когда-либо придуманных для этого дела.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 26-11-2019 в 07:58:

Цитата:
Дядя Миша писал:
Кстати и волатиловские шейдеры я смогу описать точно так же

Да вот хз. Есть у тебя аналог dynamicMap? Это когда на вход шейдера подаётся содержимое FBO от рендеринга экрана или зеркала?

__________________

xaerox on Vivino


Отправлено Дядя Миша 26-11-2019 в 09:33:

Цитата:
XaeroX писал:
Есть у тебя аналог dynamicMap?


image u_DynamicMap = "entity->$SubviewTexture";

Добавлено 26-11-2019 в 12:28:

Если интересно, вот полный список того, что можно подать на вход текстурного юнита:
C++ Source Code:
1
typedef enum
2
{
3
  // types below are applied during model loading
4
  LOC_MATDEF_DETAILMAP = 1,	// path to detail texture from materials.def
5
  LOC_GLOBAL_DEFAULT_IMAGE,
6
  LOC_GLOBAL_PARTICLE_IMAGE,
7
  LOC_GLOBAL_WHITE_IMAGE,
8
  LOC_GLOBAL_GRAY_IMAGE,
9
  LOC_GLOBAL_BLACK_IMAGE,
10
  LOC_GLOBAL_FITNORM_IMAGE,
11
  LOC_GLOBAL_WHITECUBE_IMAGE,
12
  LOC_VARIABLE_PATH,
13
  LOC_CONSTANT_PATH,
14
  // types below are applied during rendering
15
  LOC_GLOBAL_SKYBOX_IMAGE,
16
  LOC_GLOBAL_SCREEN_COLOR,
17
  LOC_GLOBAL_SCREEN_DEPTH,
18
  LOC_ENTITY_LIGHTMAP,
19
  LOC_ENTITY_DELUXMAP,
20
  LOC_ENTITY_CUBEMAP0,
21
  LOC_ENTITY_CUBEMAP1,
22
  LOC_ENTITY_CINEMATIC,	// cinematic texture
23
  LOC_ENTITY_SUBVIEW,		// reflection, portal, monitor etc
24
  LOC_ENTITY_LAYERMAP,	// terrain layers
25
  LOC_LIGHT_SPOTLIGHT,	// get spotlight texture from dlight
26
  LOC_LIGHT_OMNILIGHT,
27
  LOC_LIGHT_SHADOWMAP0,
28
  LOC_LIGHT_SHADOWMAP1,
29
  LOC_LIGHT_SHADOWMAP2,
30
  LOC_LIGHT_SHADOWMAP3,
31
  LOC_CONSOLE_TEXPATH		// string or texturenum
32
} unitloc_t;


Добавлено 26-11-2019 в 12:29:

Последняя локация для дебага - берёт путь или индекс текстуры из консольной переменной

Добавлено 26-11-2019 в 12:33:

А вот входные данные для юниформов
C++ Source Code:
1
typedef enum
2
{
3
  LOC_MATDEF_DETAILSCALE = 1,
4
  LOC_MATDEF_SMOOTHNESS,
5
  LOC_GLOBALS_GAMETIME,
6
  LOC_GLOBALS_REALTIME,
7
  LOC_GLOBALS_SCREENSIZE,
8
  LOC_GLOBALS_SCREENSIZEINV,
9
  LOC_GLOBALS_FARPLANE,
10
  LOC_GLOBALS_LIGHTSTYLES,
11
  LOC_GLOBALS_FOGPARAMS,
12
  LOC_GLOBALS_AMBIENTFACTOR,
13
  LOC_GLOBALS_DIFFUSEFACTOR,
14
  LOC_GLOBALS_SUNREFRACTION,
15
  LOC_GLOBALS_GAMMATABLE,
16
  LOC_ENTITY_TRANSFORM,
17
  LOC_ENTITY_BONEMATRIX,
18
  LOC_ENTITY_BONEQUATERNION,
19
  LOC_ENTITY_BONEPOSITION,
20
  LOC_ENTITY_LIGHTSTYLES,
21
  LOC_ENTITY_CONVEYOR,
22
  LOC_ENTITY_RENDERCOLOR,
23
  LOC_ENTITY_CUBELERPFACTOR,
24
  LOC_ENTITY_BOUNDSCUBEMAP0,
25
  LOC_ENTITY_BOUNDSCUBEMAP1,
26
  LOC_ENTITY_ORIGINCUBEMAP0,
27
  LOC_ENTITY_ORIGINCUBEMAP1,
28
  LOC_ENTITY_CUBENUMMIPS0,
29
  LOC_ENTITY_CUBENUMMIPS1,
30
  LOC_ENTITY_SUBVIEWMATRIX,
31
  LOC_ENTITY_VIEWFORWARD,
32
  LOC_ENTITY_VIEWRIGHT,
33
  LOC_ENTITY_VIEWUP,
34
  LOC_ENTITY_VIEWORIGIN,
35
  LOC_ENTITY_FRAMELERP,
36
  LOC_ENTITY_SCALE,
37
  LOC_LIGHT_SHADOWPARAMS,
38
  LOC_LIGHT_SHADOWMATRIX,
39
  LOC_LIGHT_DIRECTION,
40
  LOC_LIGHT_COLOR,
41
  LOC_LIGHT_ORIGIN,
42
  LOC_LIGHT_MATRIX,
43
  LOC_LPROBE_DIRECTION,
44
  LOC_LPROBE_COLOR,
45
  LOC_LPROBE_SHADEAMBIENT,
46
  LOC_LPROBE_AMBIENTCUBE,
47
  LOC_RENDER_VIEWORIGIN,
48
  LOC_RENDER_VIEWRIGHT,
49
  LOC_RENDER_CSMSPLITDIST,
50
  LOC_RENDER_CSMTEXELSIZE,
51
  LOC_CONSOLE_VARIABLE,
52
  LOC_CONSTANT_VARIABLE,
53
} utype_t;

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 26-11-2019 в 10:23:

Цитата:
Дядя Миша писал:
image u_DynamicMap = "entity->$SubviewTexture";

Так может не быть неко кой энтити, для тех же зеркал.

__________________

xaerox on Vivino


Отправлено Дядя Миша 26-11-2019 в 10:27:

Ну это просто название такое. Так-то оно хранится персонально для каждого сурфейса.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 26-11-2019 в 10:28:

LOC_LIGHT_OMNILIGHT - это кастомный attenuation image?
А фильтрующая кувемапа где?

Добавлено 26-11-2019 в 17:28:

Ну в принципе да, по функционалу похоже на Волатилу. Поздравляю!

__________________

xaerox on Vivino


Отправлено Дядя Миша 26-11-2019 в 11:13:

Цитата:
XaeroX писал:
это кастомный attenuation image?

не, это диффузная кубемапа для омнилайта. Аттенюатион-имаджей у меня вообще нет, они прекрасно заменяются функциями в шейдере, это быстрее и проще. Я от них отказался еще в 2015-м году.

Цитата:
XaeroX писал:
по функционалу похоже на Волатилу

я вообще-то показал процентов 5 от функционала.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 26-11-2019 в 11:18:

Цитата:
Дядя Миша писал:
они прекрасно заменяются функциями в шейдере, это быстрее и проще

Ты исходишь из того, что аттенуация всегда простая - квадратичная там или линейная. Но за счёт кастомных текстур аттенуации в волатиле можно проворачивать разные штуки, например, имитировать ареа-лайты. Собсно, я это показывал в 2016 году в той теме, с уровнями из халфы.

Добавлено 26-11-2019 в 18:18:

Цитата:
Дядя Миша писал:
я вообще-то показал процентов 5 от функционала.

Ну я и имел в виду - твои 5% похожи на 5% функционала волатилы.

__________________

xaerox on Vivino


Отправлено Дядя Миша 26-11-2019 в 11:53:

Цитата:
XaeroX писал:
Но за счёт кастомных текстур аттенуации в волатиле можно проворачивать разные штуки

долго ли добавить? Я до света вообще еще недобрался, это просто такой задел на будующее.

Приступил к написанию убер-шейдера, который должен в себя включить все возможные комбинации кутришных шейдеров. Посмотрим как это у меня получится. Самое неудобное - вот эти грёбаные тексмоды, которые можно навешивать по нескольку штук на юнит.
Кстати говоря, я достаточно долгое время имел дело с кастомными поделками и вариациями на тему кутри, из чего у меня сложилось неверное представление об их возможностях. В оригинальной кутри лимиты гораздо скромнее, чем в этих форках. Там я помню какие-то бандлы наворачивали, чтобы значит сколлапсировать стадию в мульти-текстуринг, какие-то cg-программы можно было подключать (ессно никто этого не делал).
А в кутри всего восемь стадий-юнитов. По лимитам прекрасно укладываемся.
Впрочем я бы мультипроходность при всём желании замутить не смог, мой рендерер её не поддерживает. Да и не нужна она в наше время. Всё в шейдере прекрасно суммируется, без этих ваших depthFunc( GL_EQUAL );

Добавлено 26-11-2019 в 14:53:

Цитата:
XaeroX писал:
Ну я и имел в виду - твои 5% похожи на 5% функционала волатилы.

у меня есть все основания полагать, что новая Волатила мало чем отличается от прежней, на которой был сделан Wolfram. Ну вот навскидку - тот же Quake3 like формат уровней, те же Quake3 like описания материалов.
Тот же Нутон. Ну тени заменили со стенсильных на шадовмапы. А что еще?
Вот ты бы сам описал какие отличия старого движка от нового, такой список.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 26-11-2019 в 12:32:

Цитата:
Дядя Миша писал:
у меня есть все основания полагать, что новая Волатила мало чем отличается от прежней, на которой был сделан Wolfram.

Сильно отличается, на самом деле.

__________________

xaerox on Vivino


Отправлено Дядя Миша 26-11-2019 в 13:37:

Первые опыты
Это уже нарисовано через новую систему. Пока еще не мигает и не ерзает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 26-11-2019 в 14:34:

Дядя Миша
А какие идеи про анимацию шейдеров? Юниформ про аптайм движка или ещё как-нибудь?


Отправлено Дядя Миша 26-11-2019 в 14:53:

та пока никаких идей, этож общая проблема.
Она в основном упирается в синтаксис скрипта, как красиво написать, что мы на этот юнит хотим навесить несколько текстур, которые будут сменяться через время? Ну вот для стандартного описания юнита

C++ Source Code:
image = u_ColorMap = "textures/common/black.tga";

как здесь указать что будет много меняющихся текстур?

Добавлено 26-11-2019 в 17:53:

ЗЫ. с мультислоёными текстурами аналогичная проблема, кстати.
Ну ладно, fps или еще какое правило их смены можно задать через отдельную команду и это непроблема.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 26-11-2019 в 15:03:

Цитата:
Дядя Миша писал:
упирается в синтаксис скрипта, как красиво написать

Маску/список в квадратных скобочках ala bash?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 27-11-2019 в 06:32:

thambs приведи пример.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено AntiPlayer 27-11-2019 в 06:36:

Дядя Миша

C++ Source Code:
image = u_ColorMap = ["textures/common/black.tga", "textures/common/white.tga"];

Так не красиво?

__________________
I tell you to enjoy life


Отправлено Дядя Миша 27-11-2019 в 07:25:

Ладно, попозже к этой теме вернёмся. Может и норм.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 27-11-2019 в 07:56:

AntiPlayer Питон какой-то


Отправлено Дядя Миша 27-11-2019 в 09:21:

Я наверное пойду по старому, проверенному пути, сделаю что-то типа функции addUnitLayer или addUnitFrame. Не люблю когда строка далеко уходит вправо, за границу экрана.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 27-11-2019 в 09:40:

Дядя Миша
А переводы строк на что?


Отправлено Дядя Миша 27-11-2019 в 10:36:

nemyax не каждую строку можно перевести.

Добавлено 27-11-2019 в 13:36:

А я тем временем без дела не сидел - подключил блендфунки, смешал текстуры со всех слоёв, реализовал деформацию вертексов, чтобы пидарасы ползали по трубам и сделал все виды генерации текстурных координат. И тут мне конечно пришлось столкнуться с ограничением моей системы. Нет, оно работает корректно, но пользователь там один момент уже не контролирует в полной мере. Впрочем я никогда не видел, чтобы это в ку3 хоть кто-то использовал, т.к. заведомо бессмыссленая операция.
Продолжаю работу.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 27-11-2019 в 11:00:

Дядя Миша
В петоне есть хорошее правило, что при открытой скобке переводы строк нещиток, пока не встретится закрытая.
То есть вот:

code:
image = u_ColorMap = [ "textures/common/black.tga", "textures/common/white.tga"];


Отправлено AntiPlayer 27-11-2019 в 12:08:

Цитата:
Crystallize писал:
Питон какой-то

Так массивы в половине ЯП определяются.
Цитата:
Дядя Миша писал:
сделаю что-то типа функции addUnitLayer или addUnitFrame

Дублирование кода может получиться, все дела. Хотя выглядит неплохо.

__________________
I tell you to enjoy life


Отправлено Дядя Миша 27-11-2019 в 13:18:

nemyax не нравится мне такой способ записи. Мне вообще петон не нравится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 27-11-2019 в 13:20:

Дядя Миша
Так юзеры-ж писать будут?

>приведи пример
Обычные звёздочки, знаки вопроса, [a-z] и [0-9] и на выходе список отсортированный в лексикографическом порядке. Мб вообще рэгэксп туда напрашивается?

>addUnitLayer или addUnitFrame
Главное чтоб не было нужно руками такое писать.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено XaeroX 27-11-2019 в 13:55:

Цитата:
thambs писал:
рэгэксп

Я предлагал дяде мише добавить поддержку pcre, он предсказуемо отказался.

__________________

xaerox on Vivino


Отправлено Дядя Миша 27-11-2019 в 14:08:

Цитата:
thambs писал:
>addUnitLayer или addUnitFrame
Главное чтоб не было нужно руками такое писать.

ну в макрос обвернешь со счётчиком.

Так, у меня тут с кутришными шейдерами конечно образовалась трогедия. Я не могу отличить полупрозрачные от непроразрачных, тому шо сам кутри это делает неявным образом, по значению первого бленд-функа. То есть мне бы там влепить условие и посмотреть чему равны значения из юниформа блендфунка для нулевого юнита, но я поленился сделать им доступ к отдельным значениям для всяких там векторов. Похоже что всё же придется сделать.

Добавлено 27-11-2019 в 17:08:

у меня GL-стейты вообще не подвержены действию условий, нехорошо получается, рано или поздно это могло понадобиться. Придётся переделывать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 27-11-2019 в 14:13:

XaeroX
Я вот вижу ещё для них юзкейсы внутри скриптового языка вплане работы со строками: найти энтити по маске, загрузить какие-то ресурсы по маске (например, звуки и рандомно между ними переключаться вместо хардкода).

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено XaeroX 27-11-2019 в 14:55:

Цитата:
Дядя Миша писал:
Я не могу отличить полупрозрачные от непроразрачных

surfaceparm trans?

__________________

xaerox on Vivino


Отправлено Дядя Миша 27-11-2019 в 15:00:

Цитата:
XaeroX писал:
surfaceparm trans?

ога, я так и сделал. Но есть две проблемы. Во первых он не везде прописан, а с т.з. компилятрра, это типо детайла, т.е. и без него тоже можно.
А во вторых мне надо еще поймать блендфунк нулевого юнита.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 27-11-2019 в 16:26:

А вот если брашевую геометрию триангулировать и сгенерить ей какую-то дерьмовую развёртку и атлас, это будет рисоваться заметно быстрее?


Отправлено Дядя Миша 27-11-2019 в 18:29:

Я придумал, второе условие прозрачности можно повесить на cull disable.

Добавлено 27-11-2019 в 21:29:

В принципе тут какое дело - в ку3 любая полупрозрачная поверхность непременно будет иметь cull disable. Правда это же справедливо и для решёток, поэтому там выполняется дополнительное условие - чтобы блендинг нулевого юнита не был равен GL_ONE, GL_ZERO.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 27-11-2019 в 18:43:

Бывает так, что рендерер все полигоны трактует как полупрозрачные, включая те, у которых opacity 1.0?


Отправлено Дядя Миша 28-11-2019 в 06:24:

Рендерер не смотрит на блендфунки и opacity. У него главный критерий - отключённая запись в буффер глубины.

Добавлено 28-11-2019 в 09:24:

Подключил тем временем текс-моды, всё заерзало и закрутилось. Ну уже похоже на кутри. Остались rgbGen и alphaGen.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 28-11-2019 в 19:01:

На самом деле в кутришных шейдерах есть один нехороший случай, когда нулевым юнитом идёт нечто полупрозрачные, а следующим - текстура с альфа-каналом, ну например стеклянная колба, поверх которой обрамление.
Просто включением альфа-канала такое не разруливается.

Добавлено 28-11-2019 в 16:22:

Вот же грёбанная задачка, из шейдера стейты не поменяешь, а рисовать всё с blendFunc( GL_ONE, GL_ONE ) - значит решётки будут полупрозрачными.

Добавлено 28-11-2019 в 18:57:

Практически завершил работу над шейдерами. Проблема с прозрачностью, увы, никуда не делась. Комбинированный материал со стадиями trans->solid навряд ли возможно нарисовать через стандартный блендфунк. Рази что через копию экрана.

Добавлено 28-11-2019 в 18:59:

А остальное всё работает, не хуже чем в ку3
Мигает, двигается, елозит, ползает по трубам и так далее.

Добавлено 28-11-2019 в 21:58:

Добавил анимацию текстур довольно оригинальным образом - каждый текс-юнит содержит в себе деномический массив путей к текстуре, по которым его можно будет поискать. Ну так я просто добавил классу каждого пути еще одну переменную - номер фрейма и всё. Теперь каждый кадр может искаться по разным путям, но суммарно их кол-во равно восьми, как в ку3.
В будущем слегка модифицируя этот механизм можно загружать и мультислойные текстуры, ну или что-то в этом духе. Просто они сольются в одну, а не останутся массивом. Так что в ку3 уже факелы заработали как надо
И всё это - на простом скрипте, движок про кутришные шейдеры даже не подозревает, единственное мне пришлось вывести дурацкое условие-проверку, что какого-то материала нет лайтмапы, а только повертексное, причём оно нужно для тех случаев, когда для материала с повертексным освещением поленились написать шейдер.
Осталась только эта грёбанная прозрачность, ну-да мне всё равно копирование экрана тестировать.

Добавлено 28-11-2019 в 22:01:

А, да, формат аним-кадров забыл показать

C++ Source Code:
1
image u_ColorMap<stageNum> = "<frame0>";\
2
addUnitFrame( u_ColorMap<stageNum>, <frame1>, 1 );\
3
addUnitFrame( u_ColorMap<stageNum>, <frame2>, 2 );\
4
addUnitFrame( u_ColorMap<stageNum>, <frame3>, 3 );\
5
addUnitFrame( u_ColorMap<stageNum>, <frame4>, 4 );\
6
addUnitFrame( u_ColorMap<stageNum>, <frame5>, 5 );\
7
addUnitFrame( u_ColorMap<stageNum>, <frame6>, 6 );\
8
addUnitFrame( u_ColorMap<stageNum>, <frame7>, 7 );\
9
setUnitFramerate( u_ColorMap<stageNum>, <fps> );

это кусок риплейса, не пугайтесь странным значениям.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 28-11-2019 в 19:17:

Дядя Миша
Ухтыж, скажи, а вот таким способом можно будет аддитивно наложить рендер с монитора на диффузный материал?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено nemyax 28-11-2019 в 19:38:

Цитата:
Дядя Миша писал:
Комбинированный материал со стадиями trans->solid навряд ли возможно нарисовать через стандартный блендфунк.

Пробовал через коммутативный, как тут?
http://www.openglsuperbible.com/201...ally-necessary/


Отправлено Дядя Миша 29-11-2019 в 06:42:

Цитата:
thambs писал:
а вот таким способом можно будет аддитивно наложить рендер с монитора на диффузный материал?

таким это каким?

Цитата:
nemyax писал:
Пробовал через коммутативный, как тут?

дело не в коммутации же. Нарушен порядок смешивания. Он там в статье верно говорит, если бы всё смешивалось через GL_ONE, GL_ONE то порядок был бы неважно.
Как есть сейчас:
C++ Source Code:
1
pass0 (GL_ONE, GL_ONE) +
2
pass1 (REPLACE) +
3
pass2 (GL_DST_COLOR, GL_ZERO) +
4
screen

как должно быть
C++ Source Code:
1
pass0 (GL_ONE, GL_ONE) +
2
screen +
3
pass1 (REPLACE) +
4
pass2 (GL_DST_COLOR, GL_ZERO)

Разница в том, что в первом случае для шейдера включён внешний бленд, т.е. мешается итоговый результат. Ессно получается вот такая ерунда.

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

Добавлено 29-11-2019 в 09:41:

Вообще, посмотрел я на свои скрипты для рендеринга и окончательно утвердился в мысли, что для игровой части нужна полноценная скрипт-машина. Вот это вот стремление вынести в игровую дллку побольше связанного кода в конечном итоге только отпугивает потенциальных пользователей. Тем кто рисует текстурки, даже просто студию поставить - как серпом об асфальт. В тоже время когда существует масса лёгких IDE с подсветкой и возможностью запустить по горячей кнопке какую-либо командную строку для компиляции. Так что я полагаю надо сделать нечто вроде progs.dat и перенести все энтити туда. В таких скриптах даже наш Жэка разобрался - сундук вон сделал.

Добавлено 29-11-2019 в 09:42:

Главное чтобы скриптовой язык не было похож на UnrealScript где миллион новых кейвордов. Дичь какая-то.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 29-11-2019 в 13:24:

Цитата:
Дядя Миша писал:
Нарушен порядок смешивания. Он там в статье верно говорит, если бы всё смешивалось через GL_ONE, GL_ONE то порядок был бы неважно.

Он разбирает ещё и glBlendFunc(GL_ZERO, GL_SRC_COLOR);

Цитата:
Дядя Миша писал:
Главное чтобы скриптовой язык не было похож на UnrealScript где миллион новых кейвордов.

Лишь бы укладывалось в какую-нибудь популярную подсветку, сишную там, плюсовую или шарповую.


Отправлено a1batross 29-11-2019 в 13:37:

nemyax как оказывается, ничего читабельнее Си-подобного синтаксиса нет.

__________________
Xash3D FWGS форк


Отправлено thambs 29-11-2019 в 13:38:

nemyax
Ну сишный и плюсовый синтаксисы довольно всратые, хотя если убрать вездесущие точки с запятой перед переводом на следующую строку, лишние скобки и определения типов длиной в строку, то будет вполне читабельно.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено nemyax 29-11-2019 в 13:44:

a1batross
Выше уже было упомянуто, что будет нечто сиподобное. Вопрос только в том, на что конкретно будет похоже.

Добавлено 29-11-2019 в 16:44:

Цитата:
thambs писал:
убрать вездесущие точки с запятой перед переводом на следующую строку

Нинада, вносит неоднозначность.

Цитата:
thambs писал:
определения типов длиной в строку

Ты про шаблоны штоле? Скрипты не решают задач, требующих подобных определений.


Отправлено thambs 29-11-2019 в 13:48:

Цитата:
Нинада, вносит неоднозначность.

Приведи пример.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено nemyax 29-11-2019 в 14:07:

thambs
Пример не пример, а в общем случае непонятно, считать перевод строки концом стейтмента или нет. В сях вот всё просто: не считать.


Отправлено Дядя Миша 30-11-2019 в 11:37:

Ну чтожы. Как я и говорил кастомный бленд через копию экрана решил проблемы шейдеров, где на второй-третьей стадии снова идёт запись в буффер глубины. Осталось только разрулить проблемки с полупрозрачными сурфейсами в тумане.

Добавлено 30-11-2019 в 14:37:

Собсно, я не стал делать абсолютно все бленды через скринкопи, это достаточно дорого. Только вот эти сложные случаи, которые иначе не разрулить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 30-11-2019 в 13:02:

Туманчег

Добавлено 30-11-2019 в 16:02:

Ну вообщем да, я тут провёл некоторые опыты, во всех случаях, когда у нас шейдер со сложным смешиванием (например все стадии имеют свой бленд-функ), то копия экрана прекрасно разруливает эту ситуацию и всё корректно блендится в один проход. Но таких случаев весьма мало, навскидку вспомнил только кольцо вокруг портала.

Так. Судя по всему старый механизм условий уже не удовлетворяет возросшим требованиям. Пора его обновить и расширить.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 30-11-2019 в 13:47:

Дядя Миша
Карты оригинальные кутрёвые или ты что-то с ними дополнительно делал?


Отправлено Дядя Миша 30-11-2019 в 15:09:

Цитата:
nemyax писал:
Карты оригинальные кутрёвые или ты что-то с ними дополнительно делал?

абсолютно оригинальные. Было сделано две вещи:
1. во все шейдерные скрипты добавлена строчка:
C++ Source Code:
#include "scripts\q3shaders.h"

в этой файлике у меня все макро-подстановки и авто-замены.
2. джипег текстуры сконверчены в tga, ксаш не умеет джипег.

Добавлено 30-11-2019 в 18:02:

Добавил скрытые ключевые слова
#beginsection и #endsection
ну это что-то вроде конструктора и деструктора для скриптов.
Вызываются, только если юзер добавил их в глобальный словар макроподстановок. Ну и там уже можно внутри проверять всякое, в конце скрипта, а в начале допустим писать отладочное сообщение.
Но надо еще что-то с кондициями сделать. Текущая система уже не удовлетворяет. Там фактически одно условие #if с кучей ограничений и непонятным для юзера поведением.

Добавлено 30-11-2019 в 18:08:

Нужен рефакторинг. Я еще задумывался насчё того, чтобы вообще отойти от жёсткой формы задания материала
C++ Source Code:
"name"
{
}

чтобы через автозамену можно было как угодно их описывать, но пока не знаю. Парсеру ведь тоже нужны какие-то реперные точки, в данном случае это скобки { и }. Но если я это сделаю - можно будет описывать вообще любую форму материала. В том числе и однострочные материалы, как в сталкерах каких-нибудь. Сейчас этому мешает то обстоятельство, что словарь автозамены действует только внутри секции скобок.

Добавлено 30-11-2019 в 18:09:

А накидайте мне, если вам нетрудно варианты описания разные материалов и шейдеров из разных игр. Посмотрим что бывает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 30-11-2019 в 16:20:

Цитата:
Дядя Миша писал:
Собсно, я не стал делать абсолютно все бленды через скринкопи, это достаточно дорого. Только вот эти сложные случаи, которые иначе не разрулить.

Сложные случаи-автодетект или вручную?


Отправлено Дядя Миша 30-11-2019 в 18:03:

Автодетект конечно. Ну он пока не все варианты отрабатывает, я решил пересмотреть немного концепцию материалов и условий. У меня тут уже накопилось достаточно информации для размышления.
Не в том смысле, что я в тупик куда-то зашёл и дальше не получается. Просто появились идеи, как сделать еще лучше. Пока размышляю.
В рамках будущей концепции я хочу представить материал, просто как набор параметров для шейдера и для движка (некоторые подсказки).
Сейчас оно так и есть, но жёстко ограничено формой записи материала

C++ Source Code:
"name"
{
}

плюс есть такие неявные вещи, как наследование, из шейдер-объекта, но оно появилось тогда, когда у меня еще не было некокой автозамены.
И вот в связи с этим я думаю, а зачем нужно неявное наследование, когда при помощи автозамены можно сделать явное и указать приоритеты.
Поглядим, вообщем.

Добавлено 30-11-2019 в 21:03:

Наконец-то доделал туман
Печально, но сами объемы правильно блендятся только через копию экрана, через стандартный бленд мне не удалось их заставить правильно рисоваться.
Впрочем фпс всё равно достаточный.

На небо внимания не обращайте, неба еще нет нигде. А это кутришные шейдеры сами размазали облака по скайбрашам.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 01-12-2019 в 06:55:

Минутка забавного. В ку3 клибрашам почему-то не дали параметр nodraw и ксаш их конечно жы нарисовал. Надо бы их спрятать, но как?
Я бы конечо мог ввести какой-нибудь хитрый параметр, типа #ignore, но я решил себя поставить на место пользователя, который не может ничего добавить в движок. Вот как бы я поступил на его месте? Решение нашлось

C++ Source Code:
#keydef surfaceparm clip\
alphaFunc( GL_NEVER, 0.0f );

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 01-12-2019 в 14:08:

Дядя Миша

Цитата:
туман

Он там линейный от камеры, не круговой как в ксашмоде, или мне кажется (смотрю на место где он с плоскостью неба "взаимодействует")?

Цитата:
таким это каким?

Ну этими шойдерными скриптами, слоями/смешиванием или как оно.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Crystallize 01-12-2019 в 15:07:

Цитата:
Дядя Миша писал:
surfaceparm

Почему кому-то захотелось сэкономить одну буквочку за счёт читаемости?


Отправлено Дядя Миша 01-12-2019 в 15:26:

Цитата:
thambs писал:
Ну этими шойдерными скриптами, слоями/смешиванием или как оно.

так оно в любом случае в GLSL смешивается.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 02-12-2019 в 08:46:

Цитата:
Дядя Миша писал:
GL_DST_COLOR

А на эти штуки можно сделать реплейсов с наглядными названиями?


Отправлено Дядя Миша 02-12-2019 в 08:57:

можно конечно, но помоему они и так наглядные.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 02-12-2019 в 14:55:

Делаю рефакторинг системы материалов, в первую очередь надо нормальные условия сделать, предсказуемые для юзера. Ну и сам механизм немного поменяется. Я думаю теперь дефолтные материалы задавать с именем типа модели, ну вот так:

C++ Source Code:
1
mod_brush
2
{
3
  // default params
4
  }

думаю так нагляднее будет.
а потом пользовательский материал склеится с дефолтным, или же будет использован только дефолтный, если пользовательский не задан.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 02-12-2019 в 18:18:

Пиши параллельно документацию по системе шейдеров и материалов.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 04-12-2019 в 08:04:

Переписал систему материалов, теперь все бленды и прочее под полным контролем. Сказал бы мне кто раньше, что можно кутришные шейдеры описать простой автозаменой, я бы удивился и неповерил.
Вот вам файлик, для примера, который это делает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 05-12-2019 в 18:42:

Дописал скрипты для кутришных шейдеров. звучит конечно забавно, скрипты для скриптов. Ну я там даже некоторые оптимизации замутил, например удаление лишних стадий. Теперь надо небо сделать модное, со сменой времени суток, ну и не только. Какая же игра без скайбокса.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 05-12-2019 в 22:23:

Дядя Миша так ты не скажешь, почему на кутришной карте фпс был в 3 раза выше, чем на хлбсп?


Отправлено Дядя Миша 06-12-2019 в 07:21:

ncuxonaT позже скажу. У меня сейчас пока другие задачи, лоадер так толком и не доделат.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 07-12-2019 в 18:27:

С небом вот какая штука. Раз уж мы рисуем его из как кубическую карту из шейдера, то все вот эти древние ухищрения с проекцией текстурных координат просто идут лесом. Нам не нужно строить какие-то грёбаные виртуальные кубы в пространстве чтобы нарисовать скайбокс, мы в состоянии спроецировать кубемапу вообще на любой полигон.
Это сильно упрощает дело. Надо только придумать с облаками еще.
Можно ли им налету сгенерить координаты по полусфере.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 07-12-2019 в 19:36:

Дядя Миша
Скажи, а система материалов позволяет/ит прописать gl_nearest заданному набору текстур?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено nemyax 07-12-2019 в 21:10:

thambs
Во фрагментном шейдере же ступенек намутишь.


Отправлено Дядя Миша 08-12-2019 в 11:02:

thambs на каждый юнит можно добавлять нужные текстурные флаги, в том числе и TF_NEAREST конечно. Можно эти флаги обвернуть в условие с кваром например. Т.е. в дополнение к gl_texture_nearest.

Добавлено 08-12-2019 в 14:00:

Прекрасно получилилось всё спроецировать на плоскость. Я вообще удивлён, что спустя столько лет, народ до сих пор копипастит эту херню с генерацией координат на кубе, сферы для облаков и прочее. Оно вообще не нужно, достаточно нарисовать просто полигон неба, как его поставил маппер и спроецировать туда скайбокс и облака. И помоему качество таких облаков даже выше, ведь полусфера имеет конечный шаг тесселяции, а тут у нас попиксельное совпадение. Второй несомненный плюс - небесная поверхность рисуется со включённой записью в буффер глубины, а значит сквозь нее не будет ничего просвечивать, значит плевать на порядок отрисовки.

Добавлено 08-12-2019 в 14:02:

Да и разумеется теперь задники грузятся в единую кубемапу, а не в отдельные шесть текстур. Фактически можно сказать, что я нарисовал небо, не модифицируя движок. Опять всё в скриптах и шейдере.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 08-12-2019 в 12:04:

Цитата:
Дядя Миша писал:
Фактически можно сказать, что я нарисовал небо, не модифицируя движок. Опять всё в скриптах и шейдере.

Ты ещё скажи что щас это обратно в Xash3D и XashXT подключишь)))


Отправлено Дядя Миша 08-12-2019 в 16:06:

Crystallize нет конечно.

Добавлено 08-12-2019 в 19:06:

Остался у меня только autoSprite2. Ух и вредная пакость, вроде ерунда, а на GPU хрен переложишь.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 09-12-2019 в 19:38:

Вот кстати еще хрень какая с автоспрайтами. В идеале предполагается, что автоспрайт будет иметь всегда четыре вертекса. Но есть вот карта XPac_Bt (Black Town), так вот там вертексов произвольное кол-во. Ну и чтобы вы думали? Ку3 надрывается, про odd vertex count, но тем не менее всё исправно рисует. Я долго не мог одуплить почему. А потом дошло. Я жы генерю ему секвенцию как набор трианглов. А надо как набор квадов.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 11-12-2019 в 19:02:

В ку3-шных шейдерах была одна очень серъезная архитектурная проблема - шейдер на вход принимал не только имя, собсно, шейдера, но и номер лайтмапы. Причём, как вы догадываетесь, использование лайтмапы могло быть попросту отключено из самого шейдера. Дело тут вот в чём - повертексное освещение считалось компилятором для всех поверхностей. А вот лайтмапа кое-где скипалась, ну скажем миск-модели. То есть с лайтмапы на вертекс можно было переключиться всегда, а вот наоборот - нет. Но это полдела. Как вы понимаете, если уж шейдер объявлен пользователем, то там такие фокусы не проходят - прописал лайтмапу, значит будет лайтмапа. Или вертекс. Или всё вместе. А вот если шейдер был имплиситным - там начинались чудеса. Покроет дизайнер одной и той же текстурой стенку и модель какую-то, и генерируются для одного и того же материала два шейдера - с повертексным и с лайтмапным. Вторая проблема еще и в том, что шейдеры генерировались не для материала, а для сурфейса. Что в общем случае дольше. У себя я решил эту проблему достаточно просто - передал в юниформ номер страницы атласа. Тесселятор все чекает номер лайтмапы и останавливается, если он не совпал, а мы просто таким образом смотрим, раз -1 - значит повертексное. -2 - фуллбрайт ну или что-то в этом роде. Условие статичное, на производительность не влияет.

Добавлено 11-12-2019 в 22:02:

Вообще там много было весёлого. Например q3map2 зачем-то линкует сурфейсы бмоделей к лифам. Вот этого вот я вообще не понял. Может это конечно такие специальные лифы в общей куче, которые в дереве не участвуют. Ну знаете как построить фейковое дерево? Аллокнуть аутсайд ноду и к ней прилинковать лиф или вообще просто один лиф аллокнуть. Когда мы используем обход дерева это и не влияет, но я давно уже линейно обхожу лифы, поскольку это гораздо быстрее для отрисовки. Ну и видимо вот эти тоже задел.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 12-12-2019 в 09:02:

Похоже мне удалось-таки преодолеть главный затык в написании нового движка. Если я засматривался в какой-то степени на кутришный формат уровней, меня преследовала мысль, что это придется тащить кутришные материалы, а мне бы этого совсем нехотелось. Теперь же, когда материалы описаны в скрипте, соответственно проблемы никакой нет, рендерер остался генеричным. Значит можно и дальше двигаться в этом направлении.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 13-12-2019 в 09:07:

В халфе с точки зрения современной системы материалов, самая великая мерзость - вот эти рендермоды. Мало того, их еще и налиту переключать можно, что совсем уже за гранью. Для простейших материалов из одной диффузки это не имеет никакого значения. Но уже в ку3 эту тему дропнули.
С одной стороны - это просто такой способ задать прозрачность. С другой - одни и те же диффузки могут быть как прозрачными так и непрозрачными, вот в чём штука. И заранее это определить невозможно. Хранить по две копии материала для непрозрачных и прозрачных случаев - тоже глупость какая-то. Разве что в шейдер протащить эти рендермоды.
Но мне эта затея представляется небесспорной в том плане, что я возможно вообще дропну все эти старые материалы и рендермоды в плане их поддержки. Прозрачность регулировать из объекта - это пожалуйста, тут никаких проблем, но переключателя солид\транс точно быть не должно налиту. Впрочем можно провести любопытный эксперимент: прописать пресеты материалам исходя из их предназначения и поглядеть сколько будет мест, где это зафейлится. Стёкла, решётки там.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 13-12-2019 в 09:13:

>переключателя солид\транс
А это вообще хоть где-то используется?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 13-12-2019 в 09:18:

Цитата:
thambs писал:
А это вообще хоть где-то используется?

думаю нет. env_render юзали, чёб спрятать объект в основном. Ставили прозрачность на ноль.

Я вот еще думаю, оставить в движке формат текстур только DDS, а остальные форматы вынести в утилитку для конвертации. Как у вас workflow устроен, не будет ли это неудобно? Мне Элбер как-то доказывал, что ему TGA просто необходим.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 13-12-2019 в 09:40:

Цитата:
Дядя Миша писал:
Мне Элбер как-то доказывал, что ему TGA просто необходим.

Из ХЛ2 текстуры тащить?


Отправлено Дядя Миша 13-12-2019 в 09:42:

ксаш-тулзы кстати умеют конвертировать VTF->DDS без дополнительных операций.

Добавлено 13-12-2019 в 12:42:

Нет, ну вот скажем взять сталкер, там DDS-only и ничо, никто не жалуется.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 13-12-2019 в 09:55:

Цитата:
Дядя Миша писал:
Я вот еще думаю, оставить в движке формат текстур только DDS, а остальные форматы вынести в утилитку для конвертации. Как у вас workflow устроен, не будет ли это неудобно? Мне Элбер как-то доказывал, что ему TGA просто необходим.


Если нормальный dds плагин для фотошопа найдешь

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено thambs 13-12-2019 в 10:53:

Дядя Миша
tga оставь, удобней с ним работать и его все вьюеры видят, а в dds уже финалку перегонять.

Цитата:
Как у вас workflow устроен, не будет ли это неудобно?

Сейчас у меня вадники с превьюхами (что совсем неудобно) + tga/dds фулсайзы, с q3 форматом будет удобней держать в tga превьюхи для джека аля вад, а в игре грузить ddsки (при их наличии).

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено FiEctro 13-12-2019 в 10:58:

Кстати да, а джек то dds держит?

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 13-12-2019 в 11:12:

Да должен поидее. Мне вот любопытно что никто BMP не любит, хотя он и в паинте открывается и превьюшки для него видны.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 13-12-2019 в 11:16:

Да, мне в любом случае из джека удобней работать с превьюхами, т.к. у них масштаб в основном 1тексель==1юнит.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено FiEctro 13-12-2019 в 12:31:

Цитата:
Дядя Миша писал:
Да должен поидее. Мне вот любопытно что никто BMP не любит, хотя он и в паинте открывается и превьюшки для него видны.


Да все его любят, вот только не весил бы он столько много. Твоя позиция то понятна, ты подгрузил и забыл. А разработчикам надо рисовать эти текстуры, параллельно просматривая как смотрятся они в игре, накладывать их в редакторе, а если ты получил пак текстур от другого человека или проекта, то имена тебе ничего не говорят. Приходится открывать вручную каждую, а в случае с dds ещё и конвертировать.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 13-12-2019 в 13:33:

Цитата:
FiEctro писал:
Да все его любят, вот только не весил бы он столько много

ровно столько же, сколько TGA, плюс\минус 100 байт. Но TGA все любят, а BMP отчего-то нет.

Добавлено 13-12-2019 в 16:33:

Цитата:
FiEctro писал:
Приходится открывать вручную каждую, а в случае с dds ещё и конвертировать.

ну я естественно дам пакетный умный конвертор, который будет не просто пережимать в DXT, но еще и смотреть даты, типа какой файлиг новее, надо ли обновлять, сам будет подбирать оптимальный режим сжатия, возиться и.т.д.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 13-12-2019 в 13:33:

Под аббревиатурой BMP же скрывается зоопарк форматов. Сложно такое надувательство любить.


Отправлено Дядя Миша 13-12-2019 в 13:35:

Цитата:
nemyax писал:
Под аббревиатурой BMP же скрывается зоопарк форматов

почему запарк-то? Три формата всего BM3, BM4 и BM5. Причём последние два юзает только линукс отчего-то. А Паинт хотя и умеет их открывать, но никогда в них не сохраняет, может в реестре где-то галка.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Government-Man 13-12-2019 в 13:50:

Вообще странно видеть как в наше время, когда любая программа, умеющая открывать картинки, наверняка умеет еще и конвертировать целую тучу форматов, люди мучаются выбором формата для импорта.

Понятно, что когда люди сами рисуют текстуры, они это делают в программе типа фотошопа, и им не составит труда сохранить их в формате удобном для движка. Вся эта поддержка кучи форматов нужна только текстуроворам, которые воруют картинки из других игр, программ и интернета.

Движок конечно должен хранить текстуры в своем формате, это будет гораздо гибче, если ты вдруг решишь хранить в файлах текстур какие-либо еще данные, помимо собственно изображения. А импортировать/конвертировать надо из нескольких самых распространенных форматов типа PNG, BMP, TGA, JPG... Хотя я хочу посмотреть в глаза тому человеку который импортирует текстуры из JPG

ЗЫ. Дядя Миша
Кстати очень интересня тема, спасибо что решил завести блог, очень интересно следить за ходом социалистической мысли так сказать в прямом эфире!

Меня только мучает один вопрос... Я несколько лет не следил за твоей деятельностью и хорошо помню времена, когда ты писал исключительно на чистом Си. И я был шокирован, когда прочитал твои рассуждения о шаблонах и классах (да еще и абстрактных!) что стряслось?..

Кстати ты не думал выложить проект на гитхаб? Там мы могли бы напрямую наблюдать развитие движка, а также запиливать баг-репорты и пул-реквесты


Отправлено Дядя Миша 13-12-2019 в 14:01:

Ладно, используя возможности новой системы (я её условно-абстрактно назвал словарь замен), накидал вот такую вот штуку:

C++ Source Code:
1
#keydef renderMode kRenderTransTexture\
2
blendFunc( GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA );\
3
depthMask( GL_FALSE );\
4
addShaderDefine( LIGHTING_FULLBRIGHT );\
5
addShaderDefine( ADDITIVE );

правда, как вы понимаете, я не смогу это переключать налиту, но смогу жёстко прописать в те материалы, которые по смыслу используют прозрачность. Примерно так:
C++ Source Code:
1
generic108
2
{
3
  renderMode kRenderTransTexture
4
}

Это дверца микроволновки. Фиаско будет, если эта же текстура использует где-то еще как часть геометрии уровня Ну да ладно, я не ставлю себе цели корректного рендеринга халфовских уровней, это так, баловство с целью отладки системы.

Цитата:
Government-Man писал:
и хорошо помню времена, когда ты писал исключительно на чистом Си. И я был шокирован, когда прочитал твои рассуждения о шаблонах и классах (да еще и абстрактных!) что стряслось?..

в каком смысле шокирован? Что ты там такое увидел?
Ничего не стряслось, очевидно мне надоело писать на чистом Си. Решил на крестах для разнообразия. На крестах же что в первую очередь получается хорошо? АТД? Вот я их и наделал как можно больше. Удобно.

Добавлено 13-12-2019 в 16:58:

Цитата:
Government-Man писал:
Кстати ты не думал выложить проект на гитхаб?

пока смысла в том не вижу. Может через год вернёмся к этой теме.

Добавлено 13-12-2019 в 17:01:

А насчёт жесткого прописывания материалов - моя попитка закончилась буквально в пределах одной карты c1a0d. Там жеж какие-то умники текстуру table2 заюзали как для стола, на котором стоит микроволновка, так и для защитных полос, закрывающих костюм Гордона.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено a1batross 13-12-2019 в 14:20:

Дядя Миша TGA, тем более его реализация в Ксаше, умеет RLE(или мы это сами запилили, я уже чот не помню) , а компрессию в BMP почти никто не реализует, хотя там есть соответствующий biCompression.

__________________
Xash3D FWGS форк


Отправлено Дядя Миша 13-12-2019 в 14:26:

Там точто такой же RLE, но мне не попадалось сжатых BMP, это редкость.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Government-Man 13-12-2019 в 14:47:

Цитата:
Дядя Миша писал:
Решил на крестах для разнообразия


Смотри, так еще на директикс перейдешь для разнообразия

По поводу текстур, мое мнение: игра которую юзверь запускает на своем компе (или другом устройстве) должна хранить текстуры в формате, который пригоден для того, чтобы напрямую скормить его графическому АПИ без всяких лишних телодвижений. Поскольку платформ и форматов в теории может быть великое множество, чаще всего удобнее именно свой формат, который все это поддерживает.


Отправлено Дядя Миша 13-12-2019 в 15:11:

Цитата:
Government-Man писал:
игра которую юзверь запускает на своем компе (или другом устройстве) должна хранить текстуры в формате, который пригоден для того, чтобы напрямую скормить его графическому АПИ без всяких лишних телодвижений

с этим никто и не спорит. Но юзвери вон жалуются, неудобно им.

Цитата:
Government-Man писал:
на директикс перейдешь для разнообразия

Ну для GL я могу на XP подключать любую версию, ну может не прям любую, но выше 3.30. А с DX - хрена. К тому же моё мнение насчёт DX было сильно подпорчено, когда я узнал, что там тоже есть расширения как в GL.
То есть, я когда-то рассуждал как Ксерокс, ну мол хорошо, в пределах версии он не гибкий, зато стабильный на любом железе. Да щас прямо.
Те же яйца абсолютно. Любую идею можно испохабить.

Добавлено 13-12-2019 в 18:11:

Так что там с шаблонами не так?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Government-Man 13-12-2019 в 15:13:

Цитата:
Дядя Миша писал:
Так что там с шаблонами не так?


Так я удивляюсь самому факту того, что ты начал их применять.


Отправлено nemyax 13-12-2019 в 15:14:

Плюсы на венде ещё и в более шустрые бинарники компилятся, чем сишечка.


Отправлено Crystallize 13-12-2019 в 16:14:

Цитата:
Дядя Миша писал:
Но TGA все любят, а BMP отчего-то нет.

Он многослойный. Многоканальный.


Отправлено Government-Man 13-12-2019 в 17:02:

Цитата:
Дядя Миша писал:
Но юзвери вон жалуются, неудобно им


Так сделай им конвертер или импортер.


Отправлено thambs 13-12-2019 в 17:02:

Цитата:
Но юзвери вон жалуются, неудобно им

Не, ну надо просто приоритет dds>tga. Tga удобно именно при разработке и lowres-превьюх в джеке что бы не прописывать шойдеры с масштабированием; тем более, не знаю как там сейчас, но когда я экспериментировал с ку3-форматом несколько лет назад, он текстуры с разрешениями 2048..4096 грузил как-то долго.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 13-12-2019 в 17:18:

Цитата:
Government-Man писал:
Так я удивляюсь самому факту того, что ты начал их применять.

Я их в одном месте по сути заюзал - в конструкторе вертекс-форматов для VBO. Ну и во всяких АТД, типа деномических массивов, но там итак понятно.

Добавлено 13-12-2019 в 20:16:

В шестёрке шаблоны это тихий ужос, к слову. Пока я писал на чистом Си, было вообще пофигу, а тут очень многие вещи повылазили.

Цитата:
Crystallize писал:
Он многослойный. Многоканальный.

Хто?

Цитата:
Government-Man писал:
Так сделай им конвертер или импортер.

Так об это же и речь, что они нехотят запускать конвентор каждый раз, когда отредактируют текстуру.

Добавлено 13-12-2019 в 20:18:

Government-Man между прочим очень правильную вещь сказал, насчёт нативного формата, я к примеру в DDS сохраняю reflectivity и еще кой-чего помелочи. Там всё равно дофига резервных полей. Причём DDS может быть и несжатый, если это нужно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 13-12-2019 в 17:26:

Цитата:
Дядя Миша писал:
В шестёрке шаблоны это тихий ужос, к слову.

Например?


Отправлено Дядя Миша 13-12-2019 в 17:58:

nemyax половина конструкций, валидных с точки зрения языка не работает. Я специально гуглил те или иные примеры, которые должны работать корректно, но в шестёрке оно либо не компилится, либо падает.
И typeof какие-то идиотские имена порой возвращает.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Government-Man 13-12-2019 в 18:05:

Цитата:
Дядя Миша писал:
Так об это же и речь, что они нехотят запускать конвентор каждый раз, когда отредактируют текстуру.


Тогда надо сделать кнопку "сконвертить все" чтобы она шерстила папку с сорцами, сравнивала даты и конвертила только те текстуры что изменились. Тогда после любого редактирования нужно будет только щелкнуть по экзешнику.


Отправлено thambs 13-12-2019 в 18:10:

Дядя Миша
А чому ты clang не хочешь использовать?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено nemyax 13-12-2019 в 18:15:

Дядя Миша
А я тебе говорил, возьми хотя бы дивятку =)
У меня в ей правда шаблонные методы не линковались, если определения были вынесены в .cpp. Если всё определяется при объявлении в заголовке, то ок. Не знаю, баг ли это или норма.


Отправлено Crystallize 13-12-2019 в 18:41:

Цитата:
Дядя Миша писал:
Хто?

формат TGA поддерживает альфу в отличие от BMP.


Отправлено Дядя Миша 13-12-2019 в 19:19:

Цитата:
Government-Man писал:
Тогда надо сделать кнопку "сконвертить все" чтобы она шерстила папку с сорцами, сравнивала даты и конвертила только те текстуры что изменились. Тогда после любого редактирования нужно будет только щелкнуть по экзешнику.

да я собсно, именно такую утилиту и сделал, и народ один хрен недоволен, что её надо лаунчить.

Цитата:
Crystallize писал:
формат TGA поддерживает альфу в отличие от BMP.



Цитата:
thambs писал:
А чому ты clang не хочешь использовать?

та я не знаю что это

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Government-Man 13-12-2019 в 19:35:

Цитата:
Дядя Миша писал:
народ один хрен недоволен, что её надо лаунчить


А как должно быть-то?


Отправлено Ku2zoff 13-12-2019 в 22:25:

Цитата:
Crystallize писал:
формат TGA поддерживает альфу в отличие от BMP.

32-битные BMP прекрасно поддерживают альфа-канал. Как, собсно, и 32-битные TGA.


Отправлено a1batross 14-12-2019 в 03:43:

Дядя Мишав том-то и дело, что сжатый BMP настолько редкость, что его никто не поддерживает. Чего не сказать о тарге.

А я думал ты с шестёрки всё же ушёл на современную студию. %)

Добавлено 14-12-2019 в 06:43:

nemyax это не баг. Так и должно быть, это плюсы такие.

__________________
Xash3D FWGS форк


Отправлено Ku2zoff 14-12-2019 в 07:20:

Цитата:
a1batross писал:
сжатый BMP настолько редкость, что его никто не поддерживает. Чего не сказать о тарге.

RLE сжатие, ИМХО, не очень хороший вариант для полноцветных текстур с плавными переходами. Лучше сжимать файлы непосредственно форматом игрового архива.


Отправлено Crystallize 14-12-2019 в 08:30:

Цитата:
Ku2zoff писал:
32-битные BMP прекрасно поддерживают альфа-канал. Как, собсно, и 32-битные TGA.

Так и знал что узнаю для себя что-то новое.


Отправлено Дядя Миша 14-12-2019 в 09:39:

Цитата:
Government-Man писал:
А как должно быть-то?

как мне говорил Элбер - запуск конвертора всё равно лишняя операция. Можно его добавить в батник на запуск движка, но он будет всё равно какое-то время провирять не изменились ли текстуры. Хоть полсекунды, а лаг.

Цитата:
a1batross писал:
А я думал ты с шестёрки всё же ушёл на современную студию.

пока не вижу смысла. Это опять всё перенастраивать.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 14-12-2019 в 11:27:

Цитата:
Ku2zoff писал:
RLE сжатие, ИМХО, не очень хороший вариант для полноцветных текстур с плавными переходами. Лучше сжимать файлы непосредственно форматом игрового архива.


Не вижу смысла, всеравно оно потом разжимается и жрёт оперативку и видеопамять.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Government-Man 14-12-2019 в 11:45:

Цитата:
Дядя Миша писал:
запуск конвертора всё равно лишняя операция. Можно его добавить в батник на запуск движка, но он будет всё равно какое-то время провирять не изменились ли текстуры. Хоть полсекунды, а лаг.


А ничего, что железо не понимает ни пнг ни жпг, и при загрузке их по любому придется разжимать, читай: выполнять ту же конверсию на лету каждый раз при запуске.

Видимо юзеров бесит что между запуском экзешника и появлением окна проходит время. Запили тогда конверсию в движок и отложи до времени загрузки - когда текстура грузится, она проверяет есть ли в сорцах более свежая версия, если есть конвертит ее и грузит.


Отправлено Дядя Миша 14-12-2019 в 12:17:

Цитата:
Government-Man писал:
А ничего, что железо не понимает ни пнг ни жпг, и при загрузке их по любому придется разжимать

Всё равно вопрос времени, что быстрее - разжать только те текстуры, которые использует конкретный уровень, либо сравнить даты абсолютно всех текстур в игровой папке + загрузить DXT.

Цитата:
Government-Man писал:
когда текстура грузится, она проверяет есть ли в сорцах более свежая версия, если есть конвертит ее и грузит.

так тоже можно, но идея же была в том, чтобы выбросить из движка лишние форматы и вынести их в отдельную утилитку

Добавлено 14-12-2019 в 15:15:

Впрочем полностью избавиться всё равно не получится. Движок, он же не только грузит, он и создаёт картинки: кубемапы, скайбоксы, скриншоты наконец. И если кубические можно сразу сжимать в DXT, то скриншоты наоборот лутьшы в jpg сохранять. Хотя, в тех же сталкерах-метро никто не парится - так и пишут в DXT. Левелшоты так точно, а вот про скриншоты я не помню.

Добавлено 14-12-2019 в 15:17:

Заглянул в xray16-xd там вот такое
C++ Source Code:
1
pcstr extension = "jpg";
2
FREE_IMAGE_FORMAT format = FIF_JPEG;
3
if (strstr(Core.Params, "-ss_png"))
4
{
5
  extension = "png";
6
  format = FIF_PNG;
7
}

ну наверное это юзвери сами сделали. Я в упор не помню во что их сохранял оригинальный сталкер.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Government-Man 14-12-2019 в 13:02:

Дядя Миша
По мне так в любом случае удобнее, когда есть отдельная либа, которая умеет работать с картинками, и все кому нужно загрузить или сохранить картинку к ней обращаются.


Отправлено Дядя Миша 14-12-2019 в 13:25:

Ладно. Щас форматы уровней\моделей в приоритете, точнее их разработка. К картинкам всегда можно вернуться. Кстати говоря, я удивлён, что ты мою тему обнаружил только сейчас.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 14-12-2019 в 20:21:

Подключил колоизацию к кутришным картам и моментально столкнулся с залипанием возле чётных сторон брашей. Как в 2008-й год вернулся.
Только тогда я вообще не понимал что происходит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 14-12-2019 в 21:06:

Дядя Миша
А что происходит?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 15-12-2019 в 10:37:

Починил кутришную колоизацию, добавил там эти оффсеты. А проверить очень просто - если коллизия лажает, то расстревалка пишет в консоль Unstick by <offset number>. Для игрока так-то почти незаметно.
Это без овербаунса.

Добавлено 15-12-2019 в 13:37:

Я же TraceWork из паранои заюзал, так что у меня изкаропки будет нормальная коллизия с ротатаблями
А вот с капсулой, к слову, так и не получилось. Уж не знаю, то ли у меня капсула слишком жирная, но игрок имеет тенденцию застревать в некоторых уголках, там где не застревает ббокс.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 15-12-2019 в 12:22:

Дядя Миша
Хулл игрока стало можно менять?


Отправлено Дядя Миша 15-12-2019 в 18:51:

nemyax можно-можно.

Приступил к разработке компилятора уровней. Ну я там естественно тоже хочу все режимы описать функциями, а к привычному виду привести через словарик автозамен. Вообще я так прикинул, если выкинуть оттуда лишние флаги и контентсы, то может получиться вполне неплохой генеричный формат уровней. То есть скажем таких вещей как CONTENTS_WATER|CONTENTS_LAVA быть вообще не должно, подобные вещи пользователь должен в материале описывать. А в компиляторе просто подсказка, что этот браш ликвидный. Ну и всё в таком же духе.
Основная задача на текущий момент - научить его собирать халфовские карты, вы будете смеяться, но кутришные компиляторы дико фейлят от того, что прекрасно собиралось даже ZHLT, порою. Там планесы куда-то корёжит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 15-12-2019 в 20:08:

Дядя Миша
А лайтмэпы по-хэлфовскому или по-кутришному будешь организовывать? Расскажи, плз, про овербаунсы и вообще как вся эта система работает.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Crystallize 16-12-2019 в 07:20:

Дядя Миша Расскажи про чётные стороны брашей.


Отправлено Дядя Миша 16-12-2019 в 08:16:

Цитата:
thambs писал:
А лайтмэпы по-хэлфовскому или по-кутришному будешь организовывать?

не понял. Лайтмапа, она и есть лайтмапа. Вот ежели бы ты спросил, буду ли я делать обычные лайтмапы или сферические гауссовы.

Цитата:
thambs писал:
Расскажи, плз, про овербаунсы

Да нечего особо расказывать, есть в коде игрока вот такая функция.
C++ Source Code:
1
int CBasePlayer :: ClipVelocity( const vec3 &in, const vec3 &normal, vec3 &out, float overbounce )
2
{
3
  float angle = normal.z;
4
 
5
  int blocked = 0x00;	// Assume unblocked.
6
 
7
  if( angle > 0 ) SetBits( blocked, 0x01 );	// If the plane that is blocking us has a positive z component, then assume it's a floor.
8
    if( angle == 0.0f ) SetBits( blocked, 0x02 );	// If the plane has no Z, it is vertical (wall/step)
9
 
10
  // Determine how far along plane to slide based on incoming direction.
11
  // Scale by overbounce factor.
12
  float backoff = DotProduct( in, normal ) * overbounce;
13
 
14
  for( int i = 0; i < 3; i++ )
15
  {
16
    float change = normal[i] * backoff;
17
    out[i] = in[i] - change;
18
 
19
    // If out velocity is too small, zero it out.
20
    if( out[i] > -STOP_EPSILON && out[i] < STOP_EPSILON )
21
      out[i] = 0.0f;
22
  }
23
 
24
  // Return blocking flags.
25
  return blocked;
26
}

ну она вообщем-то не только для игрока используется. Во всех кваках она есть. Она хотя и называется ClipVelocity, но мне кажется её уместнее было бы назвать ReflectVelocity. Вообщем она отвечает за скольжение вдоль плоскости стены. Параметр овербаунс равен еденичке, если поставить его немного больше, скажем 1.1, то игрока будет слегка отталкивать от плоскости. Поэтому в ку3 прыжки на стенку такие "деномичные". Ну и плюс он после каждого прыжка немного приседает, это тоже вносит свой вклад, хотя к физике отношения не имеет.
Цитата:
Crystallize писал:
Расскажи про чётные стороны брашей.

В ку3 планесы хранятся в определённом порядке, цитата из qfiles.h
Цитата:
// planes x^1 is allways the opposite of plane x

а первые шесть плоскостей любого браша - всегда аксиальные и из них можно вывести bbox этого браша.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 16-12-2019 в 18:56:

Приступил к написанию компилятора уровней. Название придумал хорошее - makebsp. Надо его сперва перевести на нормальные вектора, матрицы и виндинги, устал уже везде писать VectorCopy; Я сперва планировал для него создать отдельную тему, но потом подумал, а что я собственно вам такого смогу про них рассказать? Это у халфы была на компиляторы достаточно богатая история. Для кутри всего две штуки их - q3map и q3map2. Не о чем писать особо.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 17-12-2019 в 06:58:

Цитата:
Дядя Миша писал:
а первые шесть плоскостей любого браша - всегда аксиальные и из них можно вывести bbox этого браша.

А как это приводит к застреванию у чётных сторон?


Отправлено Дядя Миша 17-12-2019 в 20:05:

Вообще q3map2 занимается удивительной глупостью. Вместо того чтобы в своё время имплементировать нормальный инклуд .map файлов в основную карту, юзерам предложили такое корявое решение: делаем карту-префаб, "компилируем" её в ase (по сути просто выкидываем структурные фейсы), затем этот ase вставляем в новый префаб, затем в новый и так у нас в итоге получается конечный префаб, сложно-составной. Минус подхода очевиден - если понадобится внести изменения в самую базовую частичку такого префаба - придётся перекомпиливать вообще всё заново, значит создавать какие-то кучи батников и что немаловажно - всё время следить за порядком их компиляции, иначе ерунда получится. Я еще в 18-м году рассудил, что это полная ерунда и в параноевские компиляторы замутил полноценный инклуд map-файлов. А теперь значит настала пора это и в сам ку3 внедрить

Добавлено 17-12-2019 в 22:32:

Хотя я кажется догадываюсь, почему этого не было сделано. У автора q3map2 были какие-то сложности с матрицами, он сам там писал в каментах благодарности, типа спасибо, что матрицы помогли настроить.
Ну а о том, чтобы корректно трансформировать брашы, видимо даже и речи не шло.

Добавлено 17-12-2019 в 23:05:

В q3map2 так и не порезали триангл-модели плоскостью тумана, ох жэсть какая. 19 лет прошло, а конь так и не валялся.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 18-12-2019 в 09:58:

Засела мне тут одна мысль в башку. Ведь турбулентность-завихрения, по идее можно реализовать в пиксельном шейдере безо всякого там субдивайда. Ну в софтварной кваке же его не было.

Добавлено 18-12-2019 в 12:58:

вообще конечно так посмотришь эти фантазии на тему форков - какой жы лютый мрак, они все тащут эту копипасту из первого-второго-третьего квейка, и конечно жы кутришные шейдеры. И всё это практически в неизменном виде, никаких попыток переосмыслить. В лучшем случае это будет копипаста из третьего дуум как в овердозе. Я ведь собственно, почему так долго раскочегаривался с XashNT - не хотел идти их путём. Зачем это нужно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 18-12-2019 в 10:11:

Цитата:
Дядя Миша писал:
вообще конечно так посмотришь эти фантазии на тему форков - какой жы лютый мрак, они все тащут эту копипасту из первого-второго-третьего квейка, и конечно жы кутришные шейдеры. И всё это практически в неизменном виде, никаких попыток переосмыслить.


Наверное для совместимости

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 18-12-2019 в 18:48:

Предсказания плюшевого пророка

Тогда еще, когда я только начинал строить свой движок, году примерно в 2007-м, как вы помните, я тогда задался целью всё построить на Dll Hell.
Ну чтобы значит эти дллки с унифицированными интерфейсами, чтобы всё грузилось так и эдак, в зависимости от того, какая часть движка их использует. И на геймдеве советовался с тогдашними опытными участниками, как мне лучше поступить. И вот один из них мне сказал, рано или поздно ты придёшь к тому, чтобы поместить всё в единый экзешник и не маяться этой дурью с библиотеками. Но я ему тогда конечно не очень поверил.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 18-12-2019 в 19:01:

Ага, особенно моды и VGUI

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Ku2zoff 18-12-2019 в 21:08:

Цитата:
Дядя Миша писал:
дллки с унифицированными интерфейсами, чтобы всё грузилось так и эдак, в зависимости от того, какая часть движка их использует

Всё зависит от того, что конкретно должно быть доступно стороннему разработчику. При желании, можно не только игровую логику и худ, как изначально было в халфе, но и рендерер с частью физики (как в сделано в новых версиях хлсдк) вынести. Ну то есть, что на данный момент имеется? Логика, худ, рендерер частично и физика частично (pm_shared). По-хорошему, это всё должно быть вынесено в пользовательские длл, чтобы без хаков делать разные плюшки. А всякая низкоуровневая бяка, типа файловой системы, сети, всякой жудкой математики, да даже звуковой движок, пусть будут в дллке движка, или даже в экзешнике.


Отправлено nemyax 18-12-2019 в 21:11:

Если с другой стороны поглядеть, один разработчик — одна исполняшка. Идеальный баланс.


Отправлено FiEctro 19-12-2019 в 09:54:

Цитата:
nemyax писал:
Если с другой стороны поглядеть, один разработчик — одна исполняшка. Идеальный баланс.


И многочасовая компиляция.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено nemyax 19-12-2019 в 11:11:

FiEctro
Не в случае ксаша. Ты собирал ксаш и ксашмод?


Отправлено Дядя Миша 19-12-2019 в 11:27:

Я почему-то считаю, что юзеры вообще не хотят ничего кодить, абсолютно. Максимум скриптов понаписать. То есть вот взять даже монстров. Никто не хочет писать нового монстра. Нет, вы мне дайте такой скрипт, чтобы там можно было кастомизировать поведение базового и этого обычно достаточно. В этом конечно плане самые разнообразные монстры были пожалуй в первой кваке, одни кусают, другие мечом лупят, третие через пропасти прыгают, зомбей вообще убить невозможно. В халфе из всех монстров только барнакль так выделялся. Ну и может быть еще тентакли, но они скриптовые.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 19-12-2019 в 11:32:

Дядя Миша

Цитата:
Дядя Миша писал:
Я почему-то считаю, что юзеры вообще не хотят ничего кодить, абсолютно.


На юнити хотят, на геймейкере хотят, а вот на ксаше не хотят. Вот гады, да?

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 19-12-2019 в 11:44:

Цитата:
FiEctro писал:
На юнити хотят, на геймейкере хотят

Не лжы. На юнити все покупают ассеты. В том числе и скриптовые.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 19-12-2019 в 12:24:

Цитата:
Дядя Миша писал:
Не лжы. На юнити все покупают ассеты. В том числе и скриптовые.


А ассеты по твоему кто пишет? Корова которая в рике утонула?

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 19-12-2019 в 12:36:

Ассеты пишут в рассчёте на множественные продажы, хех.
Не для себя в основном. Этоже гораздо проще чем сделать целую игру и гадать выстрелит она или нет. А так сделал ассет и продавай себе.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 19-12-2019 в 16:33:

Цитата:
Дядя Миша писал:
Ассеты пишут в рассчёте на множественные продажы, хех.
Не для себя в основном. Этоже гораздо проще чем сделать целую игру и гадать выстрелит она или нет. А так сделал ассет и продавай себе.


Есть не меньше бесплатных ассетов

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 19-12-2019 в 17:20:

Цитата:
FiEctro писал:
Есть не меньше бесплатных ассетов

помогли они тебе сделать игру на Юнити?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 19-12-2019 в 17:51:

Дядя Миша
Отчасти

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено KiQ 22-12-2019 в 18:06:

Ну я бы с удовольствием вернулся к кодингу на ксаше, особенно с учётом последних изменений, когда будет стабильный билд. Я вообще всегда больше любил поковыряться в коде, чем рисовать текстурки и прочие ресурсы, поэтому много моих проектов так и загнулись - какая-никакая кодовая база была, а ресурсов нет. Вспомнить хотя бы сколько я тем запостил с различными фишками, типа аптечки с собой, фикс модельки в GUI, куфантомасу вот кваковскую физику приделали с распрыгом и дабл-джампом, тулово от первого лица, да и много чего

__________________
-Brain is dead-


Отправлено Дядя Миша 22-12-2019 в 18:38:

KiQ в этом-то и проблема, что твое творчество не найдет выхода без ресурсов. Надо наоборот, пусть лучше не кодят, но чтобы игра получилась.
Хоть какая-нибудь. Я согласен даже на самую лучшую игру всех времён и народов. Даже на игру, которую мы заслужили вместе с тобой.

Добавлено 22-12-2019 в 21:38:

Вспомнил про X-Real, дай думаю скачаю, посмотрю, как оно. Я еще смутно припоминаю, что они там слегка модифицировали кутришный формат карт, но щас глянул - ничего подобного, всё родное. Но материалы - из Doom3.
Так что будет мне еще дополнительный стресс-тест для словарика - подключить дуумтришные материалы простой автозаменой терминов и регулярных выражений

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 24-12-2019 в 11:27:

Как выяснилось, в XreaL уже присутствуют guide, такие однострочные выражения, которые потом распахиваются во вполне полноценные описания.
Ну особой проблемы они не составили - я просто слегка доработал парсер, чтобы он мог учитывать не только автозамену внутри секции, но и снаружи её. Правда это получается как бы две стадии - на первой стадии материалы парсятся в память и происходит частичная автозамена, на случай вот таких вот гайдов. А уже полноценная делается когда материал реально запрошен из загрузчика моделей.
Впрочем у меня еще тут таблицы и регулярные выражения, надо подумать как бы это красиво оформить. Есть небольшая проблемка - в таблицах может быть сколько угодно элементов, а мой парсер регулярных выражений базируется на строгом соответствии кол-ва аргументов. Возможно надо ввести что-то типа VA, три точки или типа тово.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 26-12-2019 в 15:16:

Разбираюсь с этой мешаниной, которую в XreaL натворили, скрестив кутришные шейдеры и дуумтришные материалы, обратил внимание вот на какой любопытный аспект. В ку3 шейдеры были генеричные - ты сам управлял какую стадию с какой смешать - парсер в это дело не вмешивался.
А здесь, ну начнём с того, что можно писать diffusemap, bumpmap и specularmap в любом порядке - пофиг, всё равно смешается правильно, лайтмапа вообще не указывается явно, она всегда подразумевается в режиме статичного освещения. Т.е. таким образом, несмотря на кажущуюся сложность этой системы, она даже более проста в переложении, поскольку оставляет куда меньше пространства для манёвра с точки зрения пользователя. Основная свобода там в задании этих условий динамических и регулярных выражений. Всё остальное нацелено на то, чтобы писать как можно короче.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено a1batross 27-12-2019 в 08:47:

Дядя Миша

Цитата:
Возможно надо ввести что-то типа VA, три точки или типа тово.


В Си есть есть #define foo(...) bar(__VA_ARGS__). Вполне подойдёт думаю для твоей макросовой автоподмены, да.

__________________
Xash3D FWGS форк


Отправлено Дядя Миша 27-12-2019 в 12:46:

Я уже отказался от этой идеи поправде говоря. Мой парсер в состоянии заменять только целые строки, а таблицы зачастую идут с переносом, фактически мне надо будет детектировать блок текста с очень нечёткими условиями, плюнул и распарсил эти таблички как есть, в дуумтришном формате, к тому же, насколько я в курсе больше никто и никогда ничем подобным не занимался, так что их не бывает разных видов.
Но. Эти же va могут пригодится например для переноса регулярных выражений в юниформы, там-то всё на одной строчке.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 27-12-2019 в 20:22:

Добавил дуумтришные регулярные выражения для записи в юниформы.
Ну там если честно, отличие от обычных регулярных выражений - это доступ к таблицам этим. Тут вот какое дело - несмотря на все успехи и достижения GPU-ускорителей, подобные таблицы хранить в них действительно накладно, потому, что как я понимаю, они куда-то там пытаются на стек поместится, и всё начинает дико тормозить на определённом железе. А иногда эти таблички очень даже нужны, да вот хотя бы лайтстили прописать.
Так что я их добавил. Теперь можно их значения в качестве константы пропускать в юниформ, причём писать практически как в GLSL.
Ну например:

C++ Source Code:
vec2 u_MyScrollTexture = vec2( time * 0.03, sinTable[time * 0.6] + 0.5 );

то есть вот даже такое теперь потдерживается, эти значения обновляются каждый кадр и посылаются в шейдер. Но разумеется никто не мешает и в самом шейдере всё это объявлять.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 27-12-2019 в 20:26:

Цитата:
sinTable[time * 0.6]

А это что, там оператор интерполяции внутри какой-та, или?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено nemyax 27-12-2019 в 20:51:

Похоже на доступ по индексу с неявным приведением. Тогда time это счётчик этих ваших тчинков штоле?


Отправлено Дядя Миша 28-12-2019 в 08:10:

Кармак, когда эти таблички для doom3 делал, явно или неявно руководствовался поведением OpenGL. Интерполятор - часть настроек таблицы, а не модификатор доступа.

Добавлено 28-12-2019 в 11:10:

Цитата:
nemyax писал:
Тогда time это счётчик этих ваших тчинков штоле?

просто игровое время.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 28-12-2019 в 08:46:

Цитата:
Дядя Миша писал:
просто игровое время

Оно у тебя целочисленное? И что тогда означает [time * 0.6]?


Отправлено Дядя Миша 28-12-2019 в 09:16:

nemyax ну что означает? Тоже самое что и в дуум3.

C++ Source Code:
int tableIndex = (int)(cl.time * 0.6);

в подобных скриптах никогда нет явного приведения типов, чтобы не путать пользователей.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 28-12-2019 в 10:03:

Дядя Миша
Так путает же, наоборот. Я вот как взглянул, так о-жид-ал, что квадратные скобки от флоата между двумя точками линейно интерполируют.

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 28-12-2019 в 10:30:

Ну по умолчанию оно действительно интерполирует, но вовсе не потому что там float. Это в свойствах самой таблицы задается - интерполировать или нет. Если таблица интерполируемая, там достаточно задать просто 0 и 1 и этого достаточно.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 28-12-2019 в 16:18:

Идея с тремя точками отпадает и вот почему. Мой риплейсер позволяет один и тот же входной аргумент размножать на выход сколько угодно раз, если это потребуется. А когда мы задаем входные аргументы вот так

C++ Source Code:
#keydef scroll ... , ...\
vec3 u_texMod<stageNum>_<texModCount> = vec3( <scroll>, <...>, <...> );\
texModCount++;

мы уже сами не можем отличить где первый набор, а где второй. Эта конструкция работает, но я не могу размножить первый набор вар-аргов, например. Нужен другой подход. Например аргумент VA должен начинаться с какого-то особого символа, ну скажем с собаки. Типа такого <@va1>, <@va2>

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено KiQ 28-12-2019 в 18:22:

Помню в Fenyx Engine у меня тчинки лежали в long, а когда нужно было что-то типа time + 0.6 я флоат переводил в миллисекунды

__________________
-Brain is dead-


Отправлено Дядя Миша 29-12-2019 в 16:41:

Ну чтожы закончил работу над поддержкой особенностей дуумтришных материалов. Теперь каждому юниформу можно задавать регулярное выражение вместо константы. Ну и однострочные материалы, по типу как в сталкере и метро теперь автоматически разворачиваются в нужный вид. А так же внедрена поддержка этих таблиц из дуум3. Ну кстати с табличками можно много чего интересного придумать, в том же XreaL например грозовое небо сделали, которое озаряют отсветы молний. Прикольно смотрится.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 29-12-2019 в 16:43:

Цитата:
Дядя Миша писал:
Ну кстати с табличками можно много чего интересного придумать, в том же XreaL например грозовое небо сделали, которое озаряют отсветы молний. Прикольно смотрится.

Кто-то мне годами рассказывал, что все эти эффекты нужны только для мерцающих лампочек и только в моде Жэки. Кто бы это мог быть, не помнишь?

__________________

xaerox on Vivino


Отправлено Дядя Миша 05-01-2020 в 10:48:

Собрал bsp, компилю карты, геометрия в порядке, а туман превращает полигоны в кашу. Ну что такое! Опять эта хрень с разной точностью флоата у msvcrt\libc. Как жы мне всё это надоело...

Добавлено 05-01-2020 в 13:48:

Самая пакость начинается, когда приходится подключать сторонние либы, которые уже скомпилены в какой-то таргет и вот он не совпадает с основным приложением.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 05-01-2020 в 12:16:

дай скрин с туманом))
свой компилятор никогда не думал писать?


Отправлено Дядя Миша 05-01-2020 в 14:44:

Цитата:
Crystallize писал:
свой компилятор никогда не думал писать?

я по твоему чем сейчас занимаюсь?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено nemyax 05-01-2020 в 21:26:

Туман не такой, при котором бочком лучше видно?


Отправлено Дядя Миша 05-01-2020 в 21:42:

nemyax это линейный

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 06-01-2020 в 10:23:

Дядя Миша я имею в виду, компилятор для С\++


Отправлено Дядя Миша 06-01-2020 в 13:22:

Новая напасть. Вот эта карта.
Все стены почему-то з-файтят, даже если к ним применить дефолтный материал лайтмапа+диффузка. Взрыв мозга. Самое смешное, что если я своим текущим компилятором (который в разработке), собираю эту же карту из исходников - ничего не зфайтит. Но и под ванильной кутри ничего не зфайтит. Ну что за бред, вперые в жизни с таким сталкиваюсь.
Как будто там двойная геометрия. Но это еще не самое смешное.

Я сравнил статистику для свежеизготовленной и для оригинальной карты.
И вот по статистике выходит, что на моей, только что собранной в 2 раза больше сурфейсов чем на оригинале. Но з-файтит именно оригинал.
Ничего не понимаю.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 06-01-2020 в 13:57:

Дядя Миша там на самом деле двойная геометрия, поверх обычной геометрии еще такие же патчи


Отправлено Дядя Миша 06-01-2020 в 14:22:

ncuxonaT а чем ты это смотришь? Я в упор не вижу этого ни в исходнике, ни в ваерфрейме.

Добавлено 06-01-2020 в 17:22:

Думал-думал, как же это дерьмо проверить и придумал.
Всё очень просто. Все эти стены на самом деле сделаны кривыми безье.
То есть, если собирать оригинал-исходник с ключом -nocurves, то стенки просто исчезнут. Я так и поступил - действительно исчезли. Но патчи я не могу посмотреть проволокой, почему, потому что блин код удаляет коллинеарные строки, превращая патч в точто такой же полигон, как и в оригинале, у них же края совпадают. То есть я не увижу вот эту сетку у себя, и в ку3 не увижу - лишние вертексы удалены. Тогда я просто проигнорил патчи при загрузке - не стал их добавлять в VBO. Ну и что? Действительно стены остались на месте, а з-файтинг исчез. Теперь к вопросу откуда взялось это дерьмо. Это очень просто:

C++ Source Code:
q3map_forceMeta

превращает любые поверхности в трианглы. Осталось только понять, а почему собственно, в ку3 не зфайтит.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено ncuxonaT 06-01-2020 в 14:33:

Дядя Миша я сделал конвертер q3bsp в obj, он патчи бьёт с заданным шагом.

Цитата:
Дядя Миша писал:
Осталось только понять, а почему собственно, в ку3 не зфайтит.

Может, там какой материал невидимый на патчах? Или в ку3 для патчей всегда есть оффсет глубины?

Добавлено 06-01-2020 в 17:33:

Ты вот говорил, что в ку3 компиляторы пакуют лайтмапу, просто укладывая прямоугольники. В то же время на этой карте лайтмапа выглядит вот так.


Отправлено Дядя Миша 06-01-2020 в 15:04:

Цитата:
ncuxonaT писал:
Ты вот говорил, что в ку3 компиляторы пакуют лайтмапу, просто укладывая прямоугольники.

прямоугольники укладывает q3map оригинальный. То что ты привёл - это уже q3map2 колдует. Мне нравится. Там походу вплоть до того, что может быть две пересекающиеся лайтмапы, если в месте пересечения цвет идентичный. Хитрая штука.

Цитата:
ncuxonaT писал:
Может, там какой материал невидимый на патчах?

да нет же, патчи это исходные, маппер стенки ими делал. А q3map2 превратил патчи в треугольники, но при этом оригинальные патчи почему-то не удалил

Цитата:
ncuxonaT писал:
Или в ку3 для патчей всегда есть оффсет глубины?

единственное что я знаю - для них там лоддирование есть, они как-то деномически достраиваются.

Добавлено 06-01-2020 в 17:58:

Жованный крот!
C++ Source Code:
1
// we may have a nodraw surface, because they might still need to
2
// be around for movement clipping
3
if(s_worldData.shaders[LittleLong(ds->shaderNum)].surfaceFlags & SURF_NODRAW)
4
{
5
  surf->data = &skipData;
6
  return;
7
}

это условие именно для патчей. Больше нигде этот флаг не используется.
Ну теперь понятно всё.

Добавлено 06-01-2020 в 18:04:

Это типа хака. Ку3 же не умеет в коллизию по треугольникам, вот и оставили невидимые патчи на всякий случай. Не ожидал такой засады, поправде говоря.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 07-01-2020 в 10:35:

Приступил к разработке собственного формата BSP.
Здесь у нас некоторые взаимоисключающие требования, но я полагаю, что мне удасться их успешно разрешить. Халфовский формат я дропну, т.к. из-за большого кол-ва лифов и отсутствия стрипификации он на данный момент выступает ключевым тормозом в отрисовке мира. Даже не смотря на мою оптимизацию, о которой я упоминал - построить из видимого хулла визтри, сколлапсировав ноды. Да, непосредственно для BSP29\BSP30 это ОЧЕНЬ хорошая оптимизация, до которой не догадался абсолютно никто, кроме меня, она даёт бууст производительности от 10% до 500%. Но в сравнении с нативным q3bsp скорость отрисовки всё равно в пару раз меньше чем могла бы быть. Далее, если я планирую вставлять модельками куски уровня, ну тот же ЧАЭС из сталкера, очевидно было бы неплохо, если бы BSP посёк эту модельку ну хотя бы на аксиальные сектора 1024\1024, тогда появится возможность отсекать большие площади по фрустуму лифа, даже при условии, что никакой виздаты у нас нет. И разумеется тристрипы для подобных поверхностей. Теперь, собственно, что позитивного у нас осталось в халфовском формате, с чем не хотелось бы расставаться. Ну во первых, конечно жы, как я неоднократно говорил - это сверхбыстрая трасса. К счастью её можно построить прямо в компиляторе света, так что можно не хранить её в карте. Второй момент - вот эти вашы лайтстили. В ку3, как вы помните их не было, но Raven или кто там делал солдат у дачи их добавил в формат максимально неоптимальным образом. Не говоря уже о том, что значительно вырос размер файла, лайтстилей так и осталось ровно четыре штуки. Я хочу сделать систему без лимита на лайтстили. Если уж их реально добавлять.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 07-01-2020 в 10:45:

Дядя Миша
Стрипификация не особенно актуальна на современном железе с жирным TnL кэшем. Если важно гонять индексы по шине - тогда лучше сделать их 16-битными, как в старые-добрые времена.

__________________

xaerox on Vivino


Отправлено SNMetamorph 07-01-2020 в 10:48:

А в чем вообще фишка лайтстилей, зачем они нужны?

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord


Отправлено XaeroX 07-01-2020 в 10:57:

SNMetamorph
Чтобы лампочки мигали и выключались.

__________________

xaerox on Vivino


Отправлено Дядя Миша 07-01-2020 в 10:58:

А, пока не забыл. В качестве контейнера для карт я возьму WAD-файл, поэтому все лумпы будут поименованные, отпадает проблема с нумерацией версий, расположением лумпов и их кол-вом. Ну и бонусом можно будет из любого редактора вадов экспортить куски карты для дальнейшего изучения, а лайтмапы прям сразу в картинки сохранять, например.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 07-01-2020 в 11:04:

Дядя Миша
Но тогда у тебя все будут спрашивать - where is all the data?

__________________

xaerox on Vivino


Отправлено SNMetamorph 07-01-2020 в 11:08:

Цитата:
XaeroX писал:
Чтобы лампочки мигали и выключались.

А т.е. эта такая альтернатива динамическим лампочкам, только для статического освещения?

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord


Отправлено nemyax 07-01-2020 в 11:08:

XaeroX
Можно будет отвечать: I'll tell you for a WAD of cash.


Отправлено Дядя Миша 07-01-2020 в 11:10:

Цитата:
XaeroX писал:
Стрипификация не особенно актуальна на современном железе с жирным TnL кэшем

та-да-да-да. То-то когда я ЧАЭС дестипифицировал, фпс упал почти что вдвое.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Crystallize 07-01-2020 в 12:45:

Цитата:
SNMetamorph писал:
А т.е. эта такая альтернатива динамическим лампочкам, только для статического освещения?

Это как тот мем "Lol they made X into a real thing"

Добавлено 07-01-2020 в 19:45:

Цитата:
Дядя Миша писал:
Raven или кто там делал солдат у дачи их добавил в формат максимально неоптимальным образом. Не говоря уже о том, что значительно вырос размер файла

Разработчики порта SoF под Дримкаст жаловались что после всех оптимизаций уровни не влазили в память приставки целиком и их пришлось резать на 2-3 части.


Отправлено Дядя Миша 07-01-2020 в 16:06:

Цитата:
Crystallize писал:
Разработчики порта SoF под Дримкаст

то первая часть, она кажется на ку2 была.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 07-01-2020 в 22:50:

Подключил CSG к компилятору. Первый случай, когда у кутришного компилятора появился CSG
Ну правда на кутришных картах толку от него практически нет. На q3dm1 он смержил мне два каких-то браша, а на q3dm7 - три.
Его истинное предназначение - это конечно карты от халфы и кваки.
Между прочим мне здорово пригодились старые наработки. Я жы когда-то планировал заюзать кудвашный формат уровней для нового ксаша. Ну так дело было за малым - научить его жрать карты от халфы. Да не абы какие, а от Монорейл Квеста, чтобы быть точно уверенным, что оно соберётся.
И соответственно я там уделил большое внимание функции SplitBrush.
А она, что в ку2 что ку3 одинаковая. Ну вот и пригодилось
Теперь надо научить его парсить халфовский и кушный формат карт.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено Дядя Миша 10-01-2020 в 16:11:

Ну что жы, реализовал рекурсивное вложение карт-префабов для моего нового кутришного компилятора, по аналогии с параноевскими тулзами.
Плюс в том, что можно выбирать поведение - вставлять либо оригинальные модельки, в формате .ase, либо исходники .map если они конечно есть.
С префабами в формате .map есть еще и тот плюс, что для них можно наладить пространство имён и вставлять не просто куски геометрии, а целые отлаженные системы скриптов, например. Эх, научить бы Джек показывать эти префабы
Ксероксу такое nepozubam, а у меня сорцев нету.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено thambs 10-01-2020 в 16:12:

Дядя Миша
Круть, а bsp-шки так можно будет?

__________________
http://www.moddb.com/mods/monorail-quest


Отправлено Дядя Миша 10-01-2020 в 16:51:

если определиться с пространством имён, то разницы никакой, что .map при компиляции, что .bsp при загрузке.
Но это очень важный вопрос, представить префаб как набор инпутов-аутпутов. Чтобы если их было много, нигде не пересекались имена, чтобы если часть префаба поехала на другой уровень это не вызвало там проблем, и так далее. Тут нужна целая концепция.

Добавлено 10-01-2020 в 19:51:

ЗЫ, сорс тоже может вкладывать эти префабы нерекурсивно ( 1 уровень вложения), вот надо посмотреть как там пространство имён разрулили.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 10-01-2020 в 17:12:

Дядя Миша
Джек в основном на волатилу нацелен, там нет map-префабов, вот и nepozubam.
По-хорошему надо в Джеке сделать собственную систему префабов, но это пожжы.

Добавлено 11-01-2020 в 00:12:

Цитата:
Дядя Миша писал:
вот надо посмотреть как там пространство имён разрулили.

Вероятно, так же, как в хаммере? Хаммер умеет вкладывать префабы со скриптами, сохраняя связи (см. префаб взрывающегося ящика).

__________________

xaerox on Vivino


Отправлено Дядя Миша 10-01-2020 в 18:41:

Неисключено. Надо будет посмотреть как там сделано.

Добавлено 10-01-2020 в 21:38:

Надо еще вот какую штуку сделать. В разных компиляторах существуют разные виртуальные энтити, которые удаляются на этапе компиляции.
Ну самый известный пример это func_group наверное. Ну так вот надо вынести описание этих виртуальных энтить в текстовый файлик и там же простые операции, которые к ним следует применить.
Например - мувнуть брашы в мировую энтить, поставить всем контент-флаг DETAIL, и так далее. Там не так уж и много вариантов. В компиляторе это держать неудобно.

Добавлено 10-01-2020 в 21:41:

В идеале бы вообще сделать, чтобы компилятор читал FGD и там из него брал энтити. Но проблема в том, что во первых у меня нет своего редактора, а во вторых мне активно не нравится сам FGD-формат и я не хочу внедрять его поддержку.
Здесь конечно должна быть реплика с мест "пиши свой редактор". А у меня основная сложность в написании собственного редактора, в том, что я не могу освоить ни хаммер ни радиант. Вот и спрашивается, на что он будет похож?

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 10-01-2020 в 18:59:

Цитата:
Дядя Миша писал:
на что он будет похож?

На кварк, разумеется.

__________________

xaerox on Vivino


Отправлено nemyax 10-01-2020 в 21:11:

А должен быть на что-то похож? Так и получится очередная кубалка.


Отправлено Crystallize 11-01-2020 в 05:00:

Не думал форкнуть кварк и переделать?


Отправлено Дядя Миша 11-01-2020 в 09:52:

Crystallize я думал о многом, я думал о разном, смоля папироской во мгле!

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено FiEctro 11-01-2020 в 12:59:

Цитата:
Дядя Миша писал:
А у меня основная сложность в написании собственного редактора, в том, что я не могу освоить ни хаммер ни радиант. Вот и спрашивается, на что он будет похож?


Избавься вообще от брашей, оставь разве что BSP модели. Тупо чтобы подгрузить модели расставить их на карте с энтитиями, посчитать VIS и запечь лайтмапу.

__________________
У котёнка мокрый нос и гладенькая шерсть, у него забавный хвост и быстрых лапок шесть. Две задних, две средних и две передних лапы, такая многоножка получилася у папы.
Он ученый — папа мой — зверушек изучает, гуляет по помойкам, ловит крыс и чаек. Две крысы белокрылые и чайки две унылые покрытые пупырчатою кожей лягушат без пёрышек тоскуют и ускакать спешат.
А ещё есть муравей большой размером с гуся он пугает всех зверей, и я его боюся, когда он ковыляет на лапках на своих.
И в двери ударяет, и начинает стих: Я — муравей, воды налей! Не меньше ведра, напиться мне пора!


Отправлено Дядя Миша 11-01-2020 в 13:12:

Цитата:
FiEctro писал:
Тупо чтобы подгрузить модели расставить их на карте с энтитиями, посчитать VIS и запечь лайтмапу.

да нельзя посчитать виз без брашей, когда же до вас уже это дойдет?
Аксиальная геометрия генерит порталы на своих плоскостях и то возникают сложности с конечной точностью вещественных. Да и потом брашы, всё равно дело хорошее, например для обозначения зон или воды. Вот как ты сделаешь воду без брашей? Подумай хорошенько, это не такой уж и простой вопрос.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'


Отправлено XaeroX 11-01-2020 в 13:28:

Цитата:
Дядя Миша писал:
Вот как ты сделаешь воду без брашей? Подумай хорошенько, это не такой уж и простой вопрос.

В первом Унреале вода делалась без брашей. Не веришь - спроси Скааржа.

__________________

xaerox on Vivino


Отправлено SNMetamorph 11-01-2020 в 14:37:

А почему при компиляции получается так много разбиений на открытых пространствах?
Это слабое место BSP подхода, или дело в компиляторах?

__________________
PrimeXT
GoldSrc Monitor
SMD Splitter
mdl-flip (gFlip analog)
Xash3D Modding Discord


Отправлено Дядя Миша 11-01-2020 в 14:47:

Цитата:
XaeroX писал:
В первом Унреале вода делалась без брашей.

В первом унреале был применён подход выгрызания пространства в солидной структуре. Как при таком подходе сделать воду брашами, я не очень понимаю. Вычитательная геометрия не создаёт, а удаляет.

Цитата:
SNMetamorph писал:
А почему при компиляции получается так много разбиений на открытых пространствах?

Разбиений на самом деле немного, то что считаешь разбиением, это субдивайд для лайтмапы. Если сделать геганцкий куб и растянуть текстуру по его размерам, то останутся только аксиальные разбиения с шагом 1024 по дефолту, ну или сколько сам задашь в -maxnodesize.
Т.е. хоть кубик 128х128, хотя 32768х32768, там будет одинаково 6 нодов.

Добавлено 11-01-2020 в 17:47:

SNMetamorph
Скрытый текст:
Этот текст скрытый. Вы должны оставить хотя бы одно сообщение в теме, чтобы его увидеть.

__________________
My Projects: download page

F.A.Q по XashNT
Блог разработчика в телеграме

Цитата:

C:\DOCUME~1\C4C5~1\L