Народная 2010 разработка

[Malandrinus 615]

magnit,

Если не трудно выложи правленные файлы

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

 

Shadowman,

когда, где

Я это стал делать тогда, когда словил несколько вылетов подряд. Тогда просто поставил вывод в биндер и понял, что он останавливается, что само по себе вылет объясняло, но непонятно было в какой момент начинается подвисание. Тогда и сделал сигнализацию. Если писк начнётся после определённого действия - взятия/сдачи квеста, убийства монстра и т.п., то хотя бы станет ясно, где копать. Дальше надо ставить отладочный вывод на это место и ловить вылет ещё раз, но уже с подробной трассировкой проблемного места. Как-то так.

[Malandrinus 615]

Shadowman,

Как думаешь, постоянно такая штука, навешенная в апдейте, не сильно напряжна будет для движка?

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

 

правильно ли я понимаю конструкцию

Да, всё так.

 

А на чем основана уверенность, что если этот counter > 5, то это значит, что биндер повисший

На самом деле при том, что сторожевой таймер работает синхронно с апдейтом, вообще нет необходимости в счётчике. Достаточно просто сравнить. Я ввёл счётчик потому, что был уверен, что апдейт актора идёт с частотой 40 мс, т.е. раза в два-три медленнее, чем fastcall. Но оказалось, что это не так. Число 5 взято с потолка. В расчёте на ситуацию с несинхронной работой апдейта и сторожевого таймера этого хватило бы с запасом, и начало срабатывания будет практически сразу (через 1-2 десятых секунды).

 

 

работает быстрее, ...или просто более лаконично ?

почти неотличимо одинаково, я измерил.Но мне так больше нравится =)

 

Добавлено через 114 мин.:

sapsan,

1. Сирена в начале должна просто проиграться один раз?

Да.

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

Так был реализован звук обратного отсчета. ...

По ЧУ у меня одни вопросы. Реализация там откровенно мутноватая. Но вот это самый большой вопрос. Я хотел бы ещё раз уточнить, что именно мне не нравится. Там в течении двух игровых минут непрерывно запускается звук сирены. Это означает, что он начинает играть с каждым очередным апдейтом. Это в свою очередь должно означать, что за минуту будет запущено несколько тысяч звуков. Столько звуков одновременно слышать невозможно, и они превратились бы в простой шум. Однако, насколько я понял, есть некий лимит на количество одновременно играющих звуков и этот лимит довольно быстро исчерпывается. В итоге от начала проигрывания первого звука до исчерпания очереди проходит что-то в районе секунды или меньше. Далее мы слышим все эти звуки (которые влезли в лимит) одновременно. Поскольку они смещены по фазе не очень сильно, то сирена всё-таки различима, хоть и весьма искажена.

Это так задумано? На мой погляд - как-то это неправильно.

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

Но проблемы с сохранением во время начала ЧУ я больше подозреваю в начальном "пугании" неписей. Пока не могу заняться ЧУ... sapsan

Изменено 1 Июня 2010 пользователем sapsan

[Malandrinus 615]

после того как вычистил нычки наполовину ... писк прекратился

Хм. Писк не должен прекращаться, если уж начался (исключая переходов между уровнями) Попробуй, если не влом, увеличить порог счётчика с 5-и до скажем 20-и. У меня есть подозрение, что частота апдейтов и соотношение с частотой fastcall-а связано с производительностью.

[Malandrinus 615]

Заборол ложный писк при паузе игры. В функции function watch_condition() надо заменить

if db.actor and then

на

if db.actor and not device():is_paused() then

Кроме того, имеет смысл ставить порог счётчика не пять, а 10 (см. ниже).

 

Похоже, что период апдейта зависит от:

- типа рендера

- общей производительности компьютера

- производительности видеокарты (может даже больше, чем от процессора)

 

Также похоже, что частота апдейта и fastcall-ов могут не совпадать на слабых конфигурациях. От патча это не зависит. Я перепроверил. На моём текущем компьютере период совпадает на всех патчах. А первые эксперименты по замеру тайминга я делал на другом компьютере и отчётливо помню, что на четвертом патче период был чётко 40 мс, а fastcall шёл раза в 2-3 быстрее. В общем, стабильности никакой. Рассчитывать на какие-то постоянные цифры нельзя. Ну и значит алгоритм проверки имеет смысл оставить так, как есть сейчас (со счётчиком) и не упрощать.

 

P.S.: можно и не предотвращать ложный писк. Его наличие показывает, что механизм жив. Но скорее всего скоро надоесть слушать =)

Изменено 2 Июня 2010 пользователем malandrinus

[Malandrinus 615]

Kolmogor,

Странно, что никто не вспомнил, что в АМК давным давно уже есть детектор зависания биндера актора

Метода у меня появилась как побочный результат моих изысканий. Я выяснил природу функций level.set_call и захотелось применить на практике. Интересно, кстати, что природа этих функций та же, что и fastcall-ов. И, как мне кажется, они ставят колбек на шаг решателя физики. Это вероятно для более точного управления физическими объектами, но можно использовать для организации независимых от апдейта актора периодических событий. Вот здесь на этом сделан сторожевой таймер, что на мой взгляд удобнее, чем делать это на апдейтах монстров.

[Malandrinus 615]

Dennis_Chikin,

 

Я как-то проводил замеры и выяснил, что выгода в применении таблицы в этом случае начинается при количестве ветвлений где-то в районе 7-8 (точной цифры не помню). Если всего два варианта, как в твоём примере, то смысла использовать таблицу нет, посколку время выборки (с использованием хеш-таблицы, помните?) хоть и почти постоянное, но больше, чем просто ветвление по условию.

 

Но надо не попасть в ловушку. Используя цепочку if-else плюс незатейливый копипаст можно запросто написать что-то в этом роде:

 

if <вычисление длинного выражения> then
elseif <вычисление того-же длинного выражения> then
и т.д.

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

 

Добавил:

ожидаю 1 на пару сотен позиций, или штуки 4-6 до полусотни

Признаться, не понял, что имеется в виду.

 

Добавил 2:

 

Думал сначала, что понимаю о чём ты, но теперь запутался окончательно. Вот расстреляй меня, но не понимаю твой вопрос. Какой-то запутанный пример, и мысль про "одну большую таблицу", и что имеется в виду под "делить её"... Не въезжаю =(

Изменено 21 Июня 2010 пользователем malandrinus

[Malandrinus 615]

Dennis_Chikin,

Это - развитие упаковщика предметов в инвентаре. Я попробовал с боеприпасами - мне понравилось. Лаги от "патронных" нычек исчезли. Хочу запихать туда остальное.

Опять меня запутал. Разве в упаковщике патронов лишние пачки не удаляются? Но ведь с остальными предметами так не выйдет. И при чём здесь таблицы?

 

sapsan,

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

 

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

 

Ну и естественно, доступ по ключу-строке на порядок медленнее.

 

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

Изменено 22 Июня 2010 пользователем sapsan

[Malandrinus 615]

Возникает ощущение, что пол игры держится на принципе "четного количества ошибок в знаке".

Приходит сын к папе программисту. Тот в мыле сидит, аврально дорабатывает что-то.

- папа-папа, а знаешь, что нам сегодня на уроке рассказали? Оказывается, Земля вращается вокруг Солнца!

Тот подымает на сына мутный взор.

- Что, правда?

- Ну да..

- Вот так сама вертится и не останавливается?

- Так нам училка сказала.

- ВОТ И НЕ ТРОГАЙ!

 

[Malandrinus 615]

sapsan,

подобное поведение table.remove, table.getn и # похоже на баг старой версии Lua. В новой я такого не наблюдаю, и всё работает достаточно предсказуемо.

 

Однако, я бы сделал оргвыводы. table.remove использовать нельзя вовсе. Никакие манипуляции, изменяющие таблицу в цикле по этой же таблице, совершенно недопустимы.

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

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

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

 

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

 

 

[Malandrinus 615]

sapsan,

а смысл? Время в игре всё равно зацикленное. Как 2^32 игровых миллисекунд проходит - отматывается на стартовое значение.

 

Добавлено через 128 мин.:

sapsan,

я переделал всюду время на 64-разрядный формат (используется game.get_game_time()). Поэтому и нужно хранить 64-разрядное значение.

Так а толку, что там 64 бита?! Это время всё равно заворачивается на стартовое после переполнения счётчика. Я проверял.

Но если переделал, то сохраняй по компонентам:

год сохранять не нужно, так как он никогда не изменится.

месяц, день месяца, час, минута, секунда - по одному байту, всего 5

миллисекунды - два байта

итого 7 байт

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

 

 

[Malandrinus 615]

deadmoroz,

особенно нервно движок реагирует на текстуры в формате 32bit-A8R8G8B8

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

 

Вообще, ни в движке ни в DirectX нет запрета на текстуры со стороной, не равной степени двойки. Это просто оптимальный размер для обработки. Нет также жёсткой привязки к формату DXT5. Это опять же просто наиболее приемлемый формат для большинства случаев. Разницы с DXT3 почти никакой нет. Иногда можно сократить размер текстур, используя DXT1. В этом случае слой прозрачности будет однобитный, т.е. просто маска. Вполне кстати подходит для большинства текстур худа. При этом двукратная выгода по размеру.

 

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

 

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

[Malandrinus 615]

Shadowman,

А вот теперь самое интересное - как проверить, протестить; ну, короче, можно как-то увидеть, "пощупать руками", какой эффект от этого, измерить как-то?

Когда исправляли текстуры для солянки ЧН, то эффект был заметен сразу: подрос fps и перестала переливаться трава. Но там всё было совсем запущено.

 

И еще вопрос: ведь после проделанной процедуры формально размер самого файла текстуры и её размер в пикселях увеличивается - откуда же будет выигрыш? Ведь движку подгружать файл текстуры бОльшего размера (размер файла текстуры примерно на 30% больше, а в пикселях - в два раза размер по горизонтали- от 1024х1024 до 1024х2047 при добавлении мипмапов).

И ещё: понятно, что на дальних расстояниях будет натянута текстура из меньшего уровня (соответствие между расстояниями и уровнем мипмапа, наверное, в движке зашито?),

Это зашито в Direct3D. В этом и суть mipmap слоёв. Выгода двойная. Кроме существенного ускорения отрисовки это ещё и лучше выглядит, поскольку текстура 512х512 смасштабированная заранее до 16х16 отрисовывается лучше, нежели она-же, но умятая на лету движком. Лучше потому, что в общем случае алгоритм масштабирования довольно затратный. Можете проверить, сколько уходит у того-же фотошопа на пакетную обработку пары сотен текстур. А движку это надо делать в реальном времени, посему используются самые примитивные алгоритмы, типа использовать только каждый второй/четвёртый/восьмой и т.д. ряд пикселей. (это для примера, точного алгоритма я не знаю)

 

а как будет с ползунками в настройках видео? Это будет как-то влиять на используемую текстуру, или это "из другой оперы"?

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

 

но как потом понять, что мы получили в итоге?

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

 

1. Есть ли какая-то разница, сколько уровней добавлять? (в некоторых текстурах/бампах стоит 9, в некоторых 10, есть какие-то мелкие текстурки каких-то там глушителей и еще какой-то мелочи, где их 5-7).

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

 

1а. Будет ли какая-то беда, если в текстуре будет к примеру 10 уровней, а в бампе 9 или наоборот

По идее такой разницы быть не должно, поскольку эти текстуры как правило имеют одинаковые размеры (т.е. см. п.1)

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

 

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

Лучше сделать на все, которые используются для обшкуривания. Тех, которые постоянно под носом у ГГ - буквально единицы.

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

 

Из текстур интерфейса и плоского худа надо разумеется слои убирать.

 

 

 

_Призрак_,

А влияют ли неиспользуемые функции на производительность игры? По идее они все кешируются что занимает время при загрузки.

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

 

А различные спейс_рестрикторы без логики(Кстати не могу въехать зачем рестриктор без логики)? смарт_трейны?

Вообще что в теории можно удалить в Солянке что бы она заработала быстрее?

рестрикторы без логики часто используются как рестрикторы =)

 

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

 

Дополнил

Shadowman,

возник естественный вопрос - так в чём же собственно ошибочка? В рассуждениях? Ведь по-любому при сохранении плагин не даст сделать ошибку. Даже если я укажу, что уровней надо 9, а на самом деле нужно 10, то плагин сам разберётся, сколько их нужно - и столько сделает

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

 

=======

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

Если это так, то тогда имеет смысл и худовые текстуры приводить к такому стандарту.

Изменено 24 Сентября 2010 пользователем C2D

[Malandrinus 615]

deadmoroz,

PaintNET, о котором упоминал chorik, поддерживает DDS, но не поддерживает мип-мапы. Поэтому если сохранить текстуру в PaintNET, то мип-мапы будут ампутированы. Подозреваю, что именно таким образом они пропали у многих cоляночных текстур.

Справедливости ради замечу, что таки поддерживает.

При сохранении открывается диалог с настройками. Там есть галка для генерации уровней.

 

[Malandrinus 615]

Насчёт порчи текстур при пережатии. На мой взгляд, есть только одна-единственная текстура, для которой это актуально - файл инвентарных иконок ui_icon_equipment.dds. Его-то уж до дыр затёрли. А все остальные... Ну не знаю. Пробовал я раз пять перепаковать текстуру - никакой визуальной разницы не заметил. Тоже самое, когда несколько раз перегнал из DXT5 в DTX3 и обратно.

Может быть, народ просто не обращает внимание на настройки качества при сохранении.

[Malandrinus 615]

Arhara,

вот здесь есть разъяснение про разницу между DXT1,3,5. Если кратко:

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

- Цвет во всех трёх форматах хранится одинаково и разницы в качестве нет. Разница есть только в хранении канала прозрачности.

- Между DXT3 и DXT5 разница весьма незначительна, а размер одинаков. Вроде как DXT5 чуть-чуть лучше (для канала прозрачности только, помните?).

- в DXT1 канал прозрачности однобитный, т.е. просто маска. При этом размер этих текстур в два раза меньше.

 

Выводы. Для самого общего случая предпочтительный формат - DXT5, как все и рекомендуют.

По поводу DXT1. Я специально изучал слои прозрачности иконочных текстур. Очень-очень редко когда видел, чтобы в канале прозрачности были полутона. Чаще всего принцип примитивный: есть цвет - непрозрачная, нет цвета (чёрный фон) - прозрачная. И в оригинале чаще всего так.

Так что в целом можно использовать DXT1 для текстур худа (плоского) и всяких иконок. Их ведь не так уж и мало. Можно сэкономить некое количество памяти.

 

Ничто не мешает посмотреть сперва на слой прозрачности. Если он выглядит "чёрно-белым" без всяких полутонов, то можно смело сохранить как DXT1. Если вдруг там есть "серые" пятна, то нужно думать. Канал прозрачности часто генерируют на основе канала RGB и серые участки получаются просто автоматически. При этом ничуть не хуже было-бы, если бы там просто была однобитная маска.

 

По поводу mipmap слоёв. Они всё-таки совершенно лишние для иконок, окошек и текстур плоского худа. Хуже с ними не отрисовывается, но они просто занимают память и при этом никак не используются.

Изменено 27 Сентября 2010 пользователем malandrinus

[Malandrinus 615]

Shadows,

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