Ради уточнения скажу что речь идёт о загрузке HD текстур.
Прохожусь по всех текстуркам уровня, ищу их dds/tga вариант в папке, гружу, попутно сохраняя индексы новых HD текстур в мапу типа <НазваниеТекстуры, индекс>. Потом подменяю индексы текстур на HD. При загрузке/смене уровня снова смотрю в мапу, догружаю новые HD по надобности
Уровень - тот где 3 тентакли под двигателем. Это был первый левел где началась эта проблема. Решилась она проставление usehunk = 2, и оттуда я дошёл до монорельса который после гарга без проблем. Как я понимаю usehunk = 2 опасно, поэтому надо мне исправить проблемы с загрузкой файлов
Посмотри для начала в менеджере задач сколько памяти потребляет твой мод в среднем. Ну, вся халфа вместе с ним.
Добавлено 31-03-2021 в 14:32:
И еще. Есть ли проверка, что COM_LoadFile вернул валидный указатель или оно прямо внутри движка крэшится?
Добавлено 31-03-2021 в 14:34:
Текстуру удолять вот так
C++ Source Code:
glDeleteTextures( 1, &texnum );
Я вот не помню, обнуляет ли драйвер номер бинда, потому что на VBO он этого к примеру не делает, но теоретически может. Если так, то надо скопировать этот номер в отдельную переменную и высвобождать как бы уже его. glGenTextures вызывать при этом не требуется, т.к. халфа не использует этот механизм, хотя такое поведение и deprecated.
if (!file)
{
Log("CreateTexture failed to load file: %s\n", filename);
...
Крашится где то внутри, что удивляет
Добавлено 31-03-2021 в 14:35:
Цитата:
Дядя Миша писал: Я вот не помню, обнуляет ли драйвер номер бинда, потому что на VBO он этого к примеру не делает, но теоретически может. Если так, то надо скопировать этот номер в отдельную переменную и высвобождать как бы уже его. glGenTextures вызывать при этом не требуется, т.к. халфа не использует этот механизм, хотя такое поведение и deprecated.
Имеешь ввиду переиспользовать эти индексы потом?
Добавлено 31-03-2021 в 14:43:
Всё пересмотрел, нашёл в одной ветке ошибку в плане отсутствия COM_FreeFile
Вероятно это оно, буду проверять
Спасибо за инфу.
Shapirlic писал: Крашится где то внутри, что удивляет
Внутри движка? Там нечему крашиться, там malloc и всё. Ни разу не видел чтобы крашился malloc.
Цитата:
Shapirlic писал: Имеешь ввиду переиспользовать эти индексы потом?
Проверить какое там число до вызова glDeleteTextures и какое после.
Если после вызова там 0, значит драйвер его таки обнулил. Надо завести отдельную переменную и держать там копию этого числа, т.к. оно тебе нужно.
Хотя может быть достаточно вызова glLoadImage и старое изображение автоматически будет отправлено в утиль. Не помню я вот этот момент.
А может быть это еще от драйвера зависит.
Крашится у тебя скорее всего что-то совершенно другое, последний раз, когда я видел твой мод, там постоянно что-то вылетало, индексы путались, итд. Т.е. он нестабильный.
Дядя Миша писал: Крашится у тебя скорее всего что-то совершенно другое, последний раз, когда я видел твой мод, там постоянно что-то вылетало, индексы путались, итд. Т.е. он нестабильный.
Вполне вероятно)
По текстуркам вроде ушло, спасибо что навёл на посмотреть COM_FreeFile.
Копаю дальше в мод, решил его покрутить под ксашем, чтобы увидеть ошибки с другой перспективы. Пришлось ксаш3Д собрать Visual Studio 2017, ибо мод на ней делаю. Первое что выпало -
Добавлено 31-03-2021 в 21:29:
Это даст мне хотя бы какой то манёвр, надеюсь, с помощью твоего двигла наконец допилю хоть до уровня чтобы не выкидывало )
Ну да, голдсорс молча валится, в ксаше можно хотя бы отловить ошибку.
Да и он частенько информативно ругается в консоль там, где голдсорс просто падает.
В общем на том месте где Халфа падает ксаш не падал, поэтому я подсунул ему сейв с халвы с проблемного места, ксаш его грузанул раз, а на вторую загрузку выдал это. Есть идеи?
Добавлено 31-03-2021 в 21:44:
Понятно, что порча памяти. Хотя бы куда смотреть есть идеи?
Это карта с2а3 и бьётся сейв после того как ломаешь замок, который удерживает пушаблы-бочки что должны всплыть.
Добавлено 31-03-2021 в 22:09:
Есть ли какой нить способ отследить все события произошедшие на карте к определенному моменту? Чтобы хотябы знать что проверять, потому что предидущее заявление про брекаблу замок неверно, там какой то рандом
Shapirlic писал: Понятно, что порча памяти. Хотя бы куда смотреть есть идеи?
Так он же тебе открытым текстом расписал строчки в исходниках куда смотреть. Открываем сорцы ксаша server\sv_game.c:2942 и смотрим.
А там у нас pfnPvAllocEntPrivateData
проще говоря - деномически выделяемая память для эдиктов, содержимое их классов. Как их можно испортить? Проще всего - если одна энтить указывает на другую и мы начинаем её модифицировать через этот указатель. Если не ошибаюсь (почему я всё за всех должен помнить?)
у тебя в моде пули сделаны энтитями. Значит у каждой пули есть свой овнер.
ну или что-то вроде этого. Вообщем наиболее частая ошибка касается именно прожектайлов, которые связаны с своими родителями.
Проблема в том, что почти никто не учитывает факт их удаления с карты или к примеру тот факт, что игрока разобрало на гибсы, а пуля еще летит.
Вообщем идёт попытка модификации связанного эдикта и она может даже оказаться довольно успешной. Вот только на месте этой энтити может оказаться любая другая. У которой размер класса меньше, а мы к ней обращаемся как к другой и вылезаем за границы отведённой памяти.
Порча и вылет. В первой кваке, к слову, такие фокусы были абсолютно безопасными из-за виртуальной машины, которая интерпретировала все указатели, как номера эдиктов (а других указателей там и вовсе не было).
Поэтому любая попытка что-либо прочесть по нулевому указателю автоматически приводило код к чтению полей ворлдспавна. А вот при попытке туда что-то записать уже крашился сервер с ошибкой "assignment to world entity" или что-то вроде этого.
Потом, для халфы и ку2 соответственно виртуалку переписали на компилируемый язык и доставили много радости моддерам.
Добавлено 31-03-2021 в 22:33:
Цитата:
Shapirlic писал: предидущее заявление про брекаблу замок неверно, там какой то рандом
Когда память портишь - всегда рандом получается. Ты же не знаешь в каком порядке блоки расположаться при следующем запуске.
Добавлено 31-03-2021 в 22:34:
А что означает сообщение "Waterlevel is out" ? Нет ли в этом антисемитизма?
По колстеку было видно что там с памятью эдиктов, да, но как именно её можно было поломать я представить не мог. Спасибо за наводки, буду глядеть в оба.
Забыл добавить. В кваке был константный размер для всех эдиктов, равный максимальному. Поэтому там ни с какой точки зрения нельзя было промахнуться и испортить память. В халфе конечно экономия, эдикт занимает ровно столько места, сколько требуется его классу.