HLFX.Ru Forum - XashNT: блог разработчика

Страницы (242): « Первая ... « 2 3 4 5 [6] 7 8 9 10 » ... Последняя »
Показать все 3621 сообщений этой темы на одной странице

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)

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

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

__________________

Отправлено Дядя Миша 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:

Цитата:

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

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

__________________

Отправлено Дядя Миша 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 писал:
Вот почитает тебя какой ни будь Гуль

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

__________________

Отправлено Дядя Миша 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:

Цитата:

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

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

Временная зона GMT. Текущее время 21:13.

Страницы (242): « Первая ... « 2 3 4 5 [6] 7 8 9 10 » ... Последняя »
Показать все 3621 сообщений этой темы на одной странице

На основе vBulletin версии 2.3.0
Авторское право © Jelsoft Enterprises Limited 2000 - 2002.
Дизайн и программирование: Crystice Softworks © 2005 - 2024