А зачем вообще было её там записывать? Вот из-за таких вот шуточек люди потом годами в заблуждении находятся. Именно поэтому я склонен больше доверять лурке, нежели педивикии.
Ku2zoff писал: Именно поэтому я склонен больше доверять лурке, нежели педивикии.
Лурка - это площадка для выяснения личных отношений ещё почище википедии, имхо. Полностью честный и непредвзятый взгляд на вещи - на официальных сайтах проектов, которые обновляются исключительно авторами.
Поднимаю тему, простите за некропостинг. Вот что нашёл. Ну нашёл ещё в прошлом году, когда изучал код ксаш-движка, а потом забил на рескейл. Сейчас решил вернуться к этому делу, вдруг получится.
Если проследить цепочку от SV_HullForBsp до движковых функций, экспортируемых наружу, то последняя "инстанция" - это SV_LinkEdict, который много откуда вызывается. Многое из физики нужно тащить в дллку. Это и pfnWalkMove, и pfnMoveToOrigin, и pfnTraceTexture, и pfnSetSize, и pfnDropToFloor, и pfnSetOrigin. Короче очень много.
Ну не страшно, всё это можно вытащить в дллку. У меня вопрос к Дяде Мише. А нет ли внутри движка каких-либо вызовов функций, которые вызывают движковый SV_HullForBsp, а в итоге наружу ничего не торчит? А то, допустим, я сделаю трассу в дллке, подменю движковые функции на свои, где хуллы исправлены, а внутри движка в одном месте будет вызов с неизменёнными хуллами. И всё нафиг изломается.
Хотя, вроде бы всё торчит наружу, в g_engfuncs. Если это действительно так, то можно начинать переносить код.
Добавлено 19-01-2017 в 22:13:
По моим прикидкам, придётся перенести в дллку почти 10 движковых функций.
Вот ещё добавка. Ну и естественно, SV_LinkEdict вызывается из SV_RunCmd. Всё торчит наружу, заменить можно. Есть пара мест, которые не получится засунуть на сервер:
SV_ExecuteClientMessage и ReapplyDecal. Да и не нужно наверное, вроде бы декали у меня не глючили. А про мессаджи я не знаю. Там уже сеть, туда вообще не стоит лезть.
Ku2zoff писал: Многое из физики нужно тащить в дллку. Это и pfnWalkMove, и pfnMoveToOrigin, и pfnTraceTexture, и pfnSetSize, и pfnDropToFloor, и pfnSetOrigin. Короче очень много.
Так в ксаш-моде давным-давно уже вытащено )
Только я не догоняю каким местом это связано с изменением скейла.
Я тебя научу как визуально увеличить скейл за 3 минуты бесплатно и без смс - опусти камеру к полу. Сразу покажется что всё вокруг огромное.
Цитата:
Ku2zoff писал: А нет ли внутри движка каких-либо вызовов функций, которые вызывают движковый SV_HullForBsp, а в итоге наружу ничего не торчит?
На данный момент нет, но это не значит, что в будущем они не появятся к примеру. Логичнее наоборот вынести SV_HullForBsp в дллку, чем тащить всю трассу. Я к слову сказать его скоро туда выведу, пригодится.
Цитата:
Ku2zoff писал: Ну и естественно, SV_LinkEdict вызывается из SV_RunCmd. Всё торчит наружу, заменить можно.
LinkEdict не надо тащить в дллку. Имеет смысл только те вызовы, где touch_triggers установлен в true, т.к. получается два независимых листа триггеров, из-за этого бага в ксаш-моде правильно работают двусторонние порталы (хотя на самом деле работать не должны). Вы небось полагаете, ох какой хороший баг, если из-за него что-то работает? Да хрен бы там. Из-за него же рекурсивный вылет на картах тхамбса, где он мини-игру с мониторами делал. Но в новых версиях я это исправлю.
Ну допустим. А размеры объектов как поменять? Хуллы-то всё равно останутся прежними.
Цитата:
Дядя Миша писал: Имеет смысл только те вызовы, где touch_triggers установлен в true
То есть, это ограничивает список функцией SV_Move и содержимым sv_phys.c? А как же pfnSetOrigin хотя бы? Выносить в дллку кажется надо всё, что отвечает за движение и расположение моделей.
Ku2zoff писал: А размеры объектов как поменять? Хуллы-то всё равно останутся прежними.
Если совсем без заморочек - проще рескейлить саму карту.
Цитата:
Ku2zoff писал: То есть, это ограничивает список функцией SV_Move и содержимым sv_phys.c? А как же pfnSetOrigin хотя бы? Выносить в дллку кажется надо всё, что отвечает за движение и расположение моделей.
Я в ксашевском физикс-интерфейсе вынес практически всё необходимое.
Остался только HullForBSP.
Дядя Миша писал: Если совсем без заморочек - проще рескейлить саму карту.
Таким макаром проще применить тутор БУзера по увеличению размера карты. Дело в том, что лучше уменьшить объекты, а мир оставить прежних размеров, чтобы всё, зависимое от координат работало. Если уж не будет хватать места для поездов и огромных башен, тогда можно увеличить карту.
Цитата:
Дядя Миша писал: Я в ксашевском физикс-интерфейсе вынес практически всё необходимое.
Ну будем посмотреть.
А загвоздка действительно в SV_HullForBsp. Под ксашем с кваром sv_quakehulls 2 всё прекрасно.
Буду задавать вопросы. Перечитал ещё раз статью по физике в кваке. В общих чертах всё понял. Теперь очередь конкретно за кодом ксаша.
Что за массивы такие:
C++ Source Code:
static model_t *com_models[MAX_MODELS];
static model_t cm_models[MAX_MODELS];
Каким образом они заполняются? Почитал код, не могу понять. Ясно, что они содержат в себе все модели, которые обрабатывает физический движок (может и спрайты тоже, но вроде бы нет).
Массивы создаются пустыми, а потом в момент загрузки моделей игрой, заполняются этими моделями, и каждая модель получает индекс? Пока что я только до этого додумался. Возможно, я не прав.
Добавлено 22-01-2017 в 00:16:
На вход SV_HullForBsp нужно всунуть модель. Можно ли как-то получить её на сервере из эдикта или энтварсов? В энтварсах есть имя модели и её индекс. А вот саму модель можно получить только на клиенте из entity_state_t.
Ku2zoff писал: Каким образом они заполняются? Почитал код, не могу понять.
Это взаимоисключающие утверждения. Если не понял, значит не прочитал код. com_models это index replacement table, поскольку набивка моделей на сервере далеко не всегда совпадает с заполнением массива реально загруженных моделей, ну например после смены карты, кое-какие модели остаются загруженными. А сетевой индекс обнуляется с рестартом и плотно привязан к расположению энтить на карте, порядку прэкеша в дллке итд.
Цитата:
Ku2zoff писал: Ясно, что они содержат в себе все модели, которые обрабатывает физический движок (может и спрайты тоже, но вроде бы нет).
Почему только физический движок? Почему спрайты нет? Как ты читал код?
Цитата:
Ku2zoff писал: На вход SV_HullForBsp нужно всунуть модель. Можно ли как-то получить её на сервере из эдикта или энтварсов?
выдернуть Mod_Handle на сервер. Собственно это уже сделано в ксаше.
Цитата:
Ku2zoff писал: по модельиндексу находит модель. Из массива.
Он не находит. Поиск это - перебор чего-либо. Хэш или бинарная сортировка просто уменьшают сложность перебора, но не избавляют от него совсем. А здесь доступ по индексу
C++ Source Code:
1
model_t *Mod_Handle( int handle )
2
{
3
if( handle < 0 || handle >= MAX_MODELS )
4
{
5
MsgDev( D_NOTE, "Mod_Handle: bad handle #%i\n", handle );
6
return NULL;
7
}
8
return com_models[handle];
9
}
А указатель берётся с com_models вот имено потому, что порядок загрузки моделей и порядок их кэширования на сервере может не совпадать и даже скорее всего не совпадает. Теоретически с подобной системой можно давать клиенту задание грузить модельки на своей стороне, но у меня пока что не возникало такой необходимости.
Добавлено 21-01-2017 в 23:17:
ЗЫ. Насчёт спрайтов. Я так понимаю тебя ввела в заблуждение загрузка спрайтов в отдельный массив на стороне клиента, CL_LoadHudSprite.
Но эти спрайты не имеют ничего общего со спрайтами, которые ставятся на сервере через энтити. Эти спрайты скорее следует рассматривать как HUD-текстуры, а поскольку спрайты бывают анимированные - то как анимированные текстуры. С их помощью худ рисуется и всякие пост-эффекты, типа прицелов. Но к спрайтам-моделям они отношения не имеют и дублируются в памяти. На то есть свои причины.
Дядя Миша писал: выдернуть Mod_Handle на сервер. Собственно это уже сделано в ксаше.
Посредством физического интерфейса, да. pfnGetModel. И оно получает доступ по индексу к уже загруженной движком модели.
Понемногу в голове начинает проясняться. В халфе как эти модели получить? Перебрать энтити при загрузке уровня, и загрузить модели для собственного массива с помощью Mod_RegisterModel?
А почему в халфе невозможен прекэш налету, уже после спауна энтить? Именно из-за вот этих вот дел с моделями и их индексами?
| IP: 
27-08-2016 09:29
