HLFX.Ru Forum (https://hlfx.ru/forum/index.php)
- Half-Life SDK (https://hlfx.ru/forum/forumdisplay.php?forumid=8)
-- Глобальное изменение масштаба (https://hlfx.ru/forum/showthread.php?threadid=4593)
Отправлено Дядя Миша 17-03-2017 в 17:04:
Цитата:
Ku2zoff писал:
Во втором случае кэш вообще в какой-то внешней структуре сохраняется
Это например в какой?
Цитата:
Ku2zoff писал:
ты получается заюзал неиспользованную переменную в структуре model_s, чтобы движок знал, что данная модель уже загружена, и не дублировал её в памяти
Ты про указатель на мемпул чтоли? Это для удобства, можно и без него было.
Цитата:
Ku2zoff писал:
Мне, неграмотному, неясно, какой способ удобнее и надёжнее
В кваке очень сложный менеджер памяти, это связано с тем, что он умеет работать в режиме чистого DOS. То есть никакой надежды на встроенный сборщик мусора. Поэтом там сразу три варианта - ханки, кэш и маленькие аллокации. Для приложений под современные OS вся эта порнография не нужна уже.
Цитата:
Ku2zoff писал:
Ну и по поводу организации самой памяти под загруженные модели: как она выделяется, чистится, как из неё выбирается нужная модель (особенно интересует работа с дубликатами).
Ты не знаешь какой функцией выделяется память? 
А дубликатов в списке моделей нет.
Цитата:
Ku2zoff писал:
Ну и по поводу содержимого zone.c/zone.cpp: а нужно ли всё это тащить в дллку
мемпулы - это вопрос удобства. Умеешь работать с памятью - делай всё вручную. Не умеешь - юзай менеджеры памяти.
Цитата:
Ku2zoff писал:
или можно каким-то более доступным способом управлять кэшем?
А что ты понимаешь под доступностью?__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 18-03-2017 в 03:57:
Цитата:
Дядя Миша писал:
Ты не знаешь какой функцией выделяется память? А дубликатов в списке моделей нет.
Ну почему же? Немного по этой теме я знаю. Даже читал твою статью по работе с памятью. Я пока не разобрался, как это устроено в ксаше/rehlds. Эти мемпулы и ханки меня запутали, я ведь ни разу не работал с памятью так плотно, как нужно для кэширования моделей, например.
Я знаю, что дубликатов нет. Я спрашивал про то, как они отсеиваются, чтобы не грузиться повторно. Кажется, я сам уже понял:
При первой загрузке модели выделяется память для неё. При попытке загрузить дубликат (в ксаше), движок проверяет указатель на мемпул. Если память уже выделена, значит, модель загружена, ещё раз грузить не нужно, иначе будет дубликат. В rehlds нет указателя на мемпул, который храниться в самой структуре model_s, поэтому там проверяется кэш.
Цитата:
Дядя Миша писал:
А что ты понимаешь под доступностью?
Ну, например, может есть какие-то экспортные функции движка для этих целей. Хотя нет, это опасно. Можно ведь весь движок уронить одной кривой строчкой. Его и так конечно можно легко уронить.
Цитата:
Дядя Миша писал:
Для приложений под современные OS вся эта порнография не нужна уже.
Но в халфе оно конечно осталось по наследству от кваки, хоть уже и не нужно 
Отправлено Дядя Миша 18-03-2017 в 08:48:
Цитата:
Ku2zoff писал:
Эти мемпулы и ханки меня запутали
ханки они поименованые. Видишь там имя модели даётся ханку.__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 18-03-2017 в 10:29:
Научил дллку грузить студиомодельки. С менеджером памяти (ксашевским) более-менее разобрался. Пока ещё не сделал выгрузку моделей из памяти при выходе из игры, и выгрузку неиспользованных при чейнджлевеле. Думаю, допилю за пару дней физику для студиомоделек, и сразу проверю будут ли проваливаться в пол уч0ные на тестовой карте. Если всё получится, займусь брашами. Если нет, возможно заброшу на какое-то время и буду делать карты.
Цитата:
Дядя Миша писал:
ханки они поименованые. Видишь там имя модели даётся ханку.
Я справился с вариантом из ксаша. А вариант из rehlds больно запутанный, там ещё интерфейс для хуков сбивает с толку при чтении кода. Ну и вообще, там код более хаотичный местами.
Добавлено 18-03-2017 в 17:29:
Блин, а браши всё равно придётся сделать сразу со студимодельками... Модель мира тоже нужно грузить 
Текстуры для студиомоделек не нужно же грузить на сервере? Они ж не рендерятся там. А текстуры для брашей? Надо поглядеть серверную трассу и код физики, нужна ли там часть из того, что грузит Mod_LoadBrushModel. А спрайты я вообще планирую не грузить. Если это не повлияет на физику проджектайлов.
Отправлено Дядя Миша 18-03-2017 в 14:01:
Цитата:
Ku2zoff писал:
А вариант из rehlds больно запутанный
Там линейная модель памяти. Ну представь себе стакан, который ты наполняешь водой. И вот у тебя вода-память всё необходимое заняла, настало время грузить модели. Ты делаешь на стакане условную дырку на уровне ватерлинии (вызываешь Hunk_LowMark и запоминаешь значение) и тут же затыкаешь её затычкой, чёб не вытикло. Потом грузишь все модели, играешь на уровне, выходишь с него и вызываешь Hunk_ClearToLowMark, типо вытаскиваешь затычку и вся вода сливается до уровня дырки. И тебе не надо париться с указателями и утечками. Ты точно знаешь что вся память высвобождена. Из плюсов подобного подхода - практически нулевой уровень дефрагментации, а из минусов - неудобство работы. Мемпул работает немного не так. Он выделяет пул, на котором сохраняются указатели для всей памяти, выделенной на этом пуле. А дальше ты можешь с ней либо работать как с самой обычной памятью - выделять, освобождать, но если надо - можешь разом высвободить весь пул. В этом и удобство. Не надо помечать никакие верхние-нижние точки.__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 19-03-2017 в 14:10:
Добрался до загрузки текстур брашевых моделей. Там туева хуча вещей связанных с загрузкой вадов тащится за функцией Mod_LoadTextures. А что если просто выделить память для loadmodel->textures[i] и определить её имя (и размеры, если надо), а мипы не грузить? Кажется, для правильной работы Mod_LoadTexInfo и последующей правильной работы Mod_LoadSurfaces одних имён будет достаточно. Ну то есть чтобы трасса работала. Все другие проверки заранее сделает сам движок. Если вада нет, то карта не загрузится.
Кажется, visdata вообще не нужна в моём случае, её грузить точно не буду. lightdata тоже не нужна, если не захочется оверрайдить функцию GET_ENTITY_ILLUM. Если она действительно не работает в халфе, то может быть сделаю загрузку освещения.
Дядя Миша подскажи пожалуйста, что конкретно делает каждая из следующих функций (и какая из последующих не будет работать без выполнения предыдущей):
C++ Source Code:
1 | 1 Mod_LoadEntities( &header->lumps[LUMP_ENTITIES] ); |
2 | 2 Mod_LoadPlanes( &header->lumps[LUMP_PLANES] ); |
3 | 3 Mod_LoadSubmodels( &header->lumps[LUMP_MODELS] ); |
4 | 4 Mod_LoadVertexes( &header->lumps[LUMP_VERTEXES] ); |
5 | 5 Mod_LoadEdges( &header->lumps[LUMP_EDGES] ); |
6 | 6 Mod_LoadSurfEdges( &header->lumps[LUMP_SURFEDGES] ); |
7 | 7 Mod_LoadTextures( &header->lumps[LUMP_TEXTURES] ); |
8 | 8 Mod_LoadLighting( &header->lumps[LUMP_LIGHTING], extrahdr ); |
9 | 9 Mod_LoadVisibility( &header->lumps[LUMP_VISIBILITY] ); |
10 | 10 Mod_LoadTexInfo( &header->lumps[LUMP_TEXINFO], extrahdr ); |
11 | 11 Mod_LoadSurfaces( &header->lumps[LUMP_FACES] ); |
12 | 12 Mod_LoadMarkSurfaces( &header->lumps[LUMP_MARKSURFACES] ); |
13 | 13 Mod_LoadLeafs( &header->lumps[LUMP_LEAFS] ); |
14 | 14 Mod_LoadNodes( &header->lumps[LUMP_NODES] ); |
15 | 15 Mod_LoadClipnodes( &header->lumps[LUMP_CLIPNODES] ); |
Первая грузит энтити с карты, чтобы потом их можно было заспавнить. Мне кажется, её можно выкинуть за ненадобностью, т.к. доступ к энтитям у нас и так есть в дллке, и повторно спавнить нам ничего не надо.
Вторая грузит плоскости, которые нужны хуллам, её нельзя выкидывать.
Третья грузит субмодели, её выкидывать нельзя.
Четвёртая, пятая, шестая не могут быть выкинуты из-за зависимости от них функции Mod_LoadSurfaces.
Седьмая грузит текстуры. Тут всё понятно, на именах текстур куча всего держится.
Восьмая - освещение, девятая - видимость. Я выше писал свои умозаключения по их нужности.
Десятая - зависит от седьмой, а от неё самой зависит Mod_LoadSurfaces.
Одиннадцатая, двенадцатая - на них строятся свойства поверхностей, да и самих моделей. Думаю, для трассы это необходимо.
Тринадцатая, четырнадцатая и пятнадцатая - то, без чего невозможна физика.
Это мои соображения, может быть где-то я не прав.
Короче, получается, можно выкинуть Mod_LoadEntities, Mod_LoadLighting, и Mod_LoadVisibility ничего не изломав. Надеюсь, нигде сильно не ошибся.
Отправлено Дядя Миша 19-03-2017 в 14:52:
Цитата:
Ku2zoff писал:
А что если просто выделить память для loadmodel->textures и определить её имя (и размеры, если надо), а мипы не грузить?
Не грузи.
Цитата:
Ku2zoff писал:
Если она действительно не работает в халфе, то может быть сделаю загрузку освещения.
Ну тараканы же на свет реагируют. забыл?
Цитата:
Ku2zoff писал:
Вторая грузит плоскости, которые нужны хуллам, её нельзя выкидывать.
Там шареные плоскости, для всего.
Цитата:
Ku2zoff писал:
Четвёртая, пятая, шестая не могут быть выкинуты из-за зависимости от них функции Mod_LoadSurfaces.
Нахрен не нужны.
Цитата:
Ku2zoff писал:
Десятая - зависит от седьмой
десятая нужна если соберёшься трейсить текстуры. Собсно, как одиннадцатая.
Цитата:
Ku2zoff писал:
Одиннадцатая, двенадцатая - на них строятся свойства поверхностей, да и самих моделей
Хрена се подробнсти
Цитата:
Ku2zoff писал:
Тринадцатая, четырнадцатая и пятнадцатая - то, без чего невозможна физика.
13-я и 14-я нужны только для точечной трассы.
Цитата:
Ku2zoff писал:
Надеюсь, нигде сильно не ошибся.
Добавлено 19-03-2017 в 17:52:
ЗЫ. для точечной трассы хотя и не нужны вертексы, но на этапе загрузки фейсов необходимо рассчитать faceextents и texturemins. Впрочем вертексы для этого вовсе необязательно держать в памяти.__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 19-03-2017 в 16:17:
Цитата:
Дядя Миша писал:
Ну тараканы же на свет реагируют. забыл?
А, ну точно. Хотя когда-то давно, ещё на хлру кто-то жаловался, что GET_ENTITY_ILLUM возвращает некорректное значение.
Цитата:
Дядя Миша писал:
Нахрен не нужны.
Цитата:
Дядя Миша писал:
для точечной трассы хотя и не нужны вертексы, но на этапе загрузки фейсов необходимо рассчитать faceextents и texturemins.
Значит нужны. Пусть вертексы будут в памяти. Мне лениво вычислять что-то налету. Даже не столько лениво, сколько опыта не хватает, чтобы грамотно написать код.
Цитата:
Дядя Миша писал:
Хрена се подробнсти
Может быть я неправильно выразился. Речь про флаги сурфейсов и моделей.
Цитата:
Дядя Миша писал:
десятая нужна если соберёшься трейсить текстуры. Собсно, как одиннадцатая.
Цитата:
Дядя Миша писал:
13-я и 14-я нужны только для точечной трассы.
Ага, ну вот, узнал кое-что полезное. Точечная трасса вроде правильно работает при изменённых хуллах. Ну попадания от выстрелов точно получаются правильные, и текстуры трейсятся правильно. Гранаты и оружия правильно падают на пол. А вот item_suit проваливается в пол. Интересно, в чём разница? Наверное в размерах. У итемов бокс со стороной в 16 юнитов, а у оружий нулевой. Вот тут-то и показывает себя во всей красе HullForBsp, из-за которого я изучил так много кода в ксаше и rehlds.
Добавлено 19-03-2017 в 22:51:
Mod_LoadSurfaces тоже можно выкинуть, если не использовать TraceSurface? Поискал по дллкам - что-то нигде не юзается. А если выкинуть её, то не получится трейсить текстуры c помощью TraceTexture. Ну то есть получится, но средствами движка. Я выше писал, что оно корректно работает. Значит, можно выбросить функции 4,5,6,7,8,9,10,11,12,13,14. Про все теперь понятно, кроме Mod_LoadNodes, которая №14. worldmodel->nodes нужны в функции SV_LinkEdict при вызове SV_FindTouchedLeafs. Для чего это? Там есть комментарий "// link to PVS leafs", но я не понял, что значит эта линковка к листьям, которые в PVS.
Добавлено 19-03-2017 в 23:00:
И ещё одно, чуть не забыл спросить про энтити с MOVETYPE_PUSH, ну то есть двери, кнопки, поезда и проч. У них только точечная трасса? Их физику можно оставить движку?
Добавлено 19-03-2017 в 23:06:
По моим прикидкам, в кастомной физике при уменьшении хуллов нуждаются только энтити с такими мувтипами:
MOVETYPE_STEP
MOVETYPE_PUSHSTEP
MOVETYPE_FLY
MOVETYPE_TOSS
MOVETYPE_BOUNCE
И то, если они имеют ненулевой размер.
Добавлено 19-03-2017 в 23:17:
Цитата:
Ku2zoff писал:
И то, если они имеют ненулевой размер.
Сейчас ради эксперимента задал учёному нулевой размер - модель не проваливается в пол, но коллизии колоизации с ним нет.
Отправлено Дядя Миша 19-03-2017 в 16:36:
Цитата:
Ku2zoff писал:
Мне лениво вычислять что-то налету.
рж0т. А как ты собрался, в файлег их чтоли записывать? Блин янемогу 
Цитата:
Ku2zoff писал:
Речь про флаги сурфейсов и моделей.
клипноды никак не связаны с сурфейсами
Цитата:
Ku2zoff писал:
А если выкинуть её, то не получится трейсить текстуры c помощью TraceTexture. Ну то есть получится, но средствами движка.
Так точечный хулл при любом масштабе остаётся точечным. TRACE_TEXTURE и GET_ENTITY_ILLUM в любом случае будут правильно работать.
Так что тебе только клипноды нужны и планесы.
Цитата:
Ku2zoff писал:
worldmodel->nodes нужны в функции SV_LinkEdict при вызове SV_FindTouchedLeafs
Цитата:
Ku2zoff писал:
Для чего это? Там есть комментарий "// link to PVS leafs", но я не понял, что значит эта линковка к листьям, которые в PVS.
Это для быстрой проверки PVS на сервере. Я же писал об этом в своём туторе. Там хранятся номера лифов, которые можно по бырому проверить на видимость в FatPVS. Если виден хотя бы один лиф - видна вся энтить целиком.
Цитата:
Ku2zoff писал:
И ещё одно, чуть не забыл спросить про энтити с MOVETYPE_PUSH, ну то есть двери, кнопки, поезда и проч. У них только точечная трасса? Их физику можно оставить движку?
Иди читай все мои туторы с самого начала.__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 19-03-2017 в 16:52:
Цитата:
Дядя Миша писал:
Это для быстрой проверки PVS на сервере.
Так, это понятно. PVS проверять будет движок, значит листья не нужны.
Цитата:
Дядя Миша писал:
Иди читай все мои туторы с самого начала.
В туторе по физике не сказано, какая трасса у энтить с MOVETYPE_PUSH. Но судя по словам "Основная его особенность заключается в том, что он не только позволяет осуществить полноценную колоизацию" можно сделать вывод, что трасса точечная. И физику можно оставить движку.
Добавлено 19-03-2017 в 23:52:
Цитата:
Дядя Миша писал:
Так что тебе только клипноды нужны и планесы.
Это сильно уменьшает объём кода. Здорово. Хотя я уже успел скопипастить и адаптировать всё, кроме видимости, освещения и текстур, я начал сомневаться в нужности некоторых вычислений. И небезосновательно.
Отправлено Дядя Миша 19-03-2017 в 19:20:
Цитата:
Ku2zoff писал:
PVS проверять будет движок, значит листья не нужны.
Ну если ты будешь вызывать движковый LinkEdict, то да. А так нет.
Цитата:
Ku2zoff писал:
"Основная его особенность заключается в том, что он не только позволяет осуществить полноценную колоизацию" можно сделать вывод, что трасса точечная.
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 30-03-2017 в 15:02:
Я доделал загрузку всех видов моделей, разобрался с эдиктами (svgame.edicts. В дллке этот список не нужен, можно обойтись каллбэками INDEXENT и ENTINDEX). Скопипастил функции физики SV_Physics и SV_Physics_Toss + всё сопустсвующее (для проверки работоспособности на гранатах). Не движутся. Точно не знаю, в чём проблема. Возможно в gpGlobals->frametime. Нужна подсказка: при вызове StartFrame gpGlobals->frametime случайно не равно нулю? У меня такое впечатление, что во всех местах, где эта переменная используется, идёт умножение на ноль, вместо значения frametime. То есть, ни гравитация, ни скорость на энтити не действуют. А может быть энтитя не тчинкает когда надо, а тчинкает позже.
Отправлено Дядя Миша 30-03-2017 в 15:48:
Цитата:
Ku2zoff писал:
Нужна подсказка: при вызове StartFrame gpGlobals->frametime случайно не равно нулю?
а пихнуть алерт, да посмотреть? Не, слишком сложно %)__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
Отправлено Ku2zoff 30-03-2017 в 16:18:
Дядя Миша пока я вот что выяснил:
Точно вызывается SV_ClipMoveToEntity(INDEXENT(0)... из SV_Move. Последующие вызовы SV_ClipMoveToEntity, которые идут из SV_ClipToLinks, не вызываются. Я конечно ещё понатыкаю алертов, попробую выяснить, в чём причина.
Отправлено Дядя Миша 30-03-2017 в 17:23:
Я полагаю проблема банально в том, что ты не понимаешь что делаешь, в надежде, что если всё скопировать точно как в движке, то оно и заработает точно как в движке.
__________________
My Projects: download page
F.A.Q по XashNT
Блог разработчика в телеграме
Цитата:
C:\DOCUME~1\C4C5~1\LOCALS~1\Temp\a33328if(72) : see declaration of 'size_t'
