[0.5.4.х] Производительность и стабильность

Santcoder:   Нам бы тоже хотелось, чтобы памяти поменьше жрал клиент. Но проблема в том, что вопрос быстродействия или занимаемой памяти считается краеугольным вопросом разработки, как в теории так и в практике. Привожу пример из этой статьи:   Память или время
Многие алгоритмы предлагают выбор между объёмом памяти и скоростью. Задачу можно решить быстро, использую большой объём памяти, или медленнее, занимая меньший объём.
Типичным примером в данном случае служит алгоритм поиска кратчайшего пути. Представив карту города в виде сети, можно написать алгоритм для определения кратчайшего расстояния между двумя любыми точками этой сети. Чтобы не вычислять эти расстояния всякий раз, когда они нам нужны, мы можем вывести кратчайшие расстояния между всеми точками и сохранить результаты в таблице. Когда нам понадобится узнать кратчайшее расстояние между двумя заданными точками, мы можем просто взять готовое расстояние из таблицы.
Результат будет получен мгновенно, но это потребует огромного объёма памяти. Карта большого города может содержать десятки тысяч точек. Тогда, описанная выше таблица, должна содержать более 10 млрд. ячеек. Т.е. для того, чтобы повысить быстродействие алгоритма, необходимо использовать дополнительные 10 Гб памяти.
Из этой зависимости проистекает идея объёмно-временной сложности. При таком подходе алгоритм оценивается, как с точки зрении скорости выполнения, так и с точки зрения потреблённой памяти.
Мы будем уделять основное внимание временной сложности, но, тем не менее, обязательно будем оговаривать и объём потребляемой памяти.  В силу того, что в игре необходима в первую очередь скорость, для нас этот вопрос встает особенно остро. Возьмем для примера, всем знакомую метрику FPS - Frame Per Second, которая показывает, сколько кадров в секунду выдает игра. В разработке мы используем обратную от FPS метрику - Frame Time, которая показывает, сколько времени занимает отрисовка одного кадра. Для достижения в принципе комфортных 30 FPS, каждый кадр должен отрисоваться за 33 миллисекунды. Или за 16 мс для 60 FPS. То есть 16 мс для того чтобы получить данные от сервера (или спрогнозировать в случае лага или задержки), построить модели с текстурами, острова, солнце, падения света, тени, блики, волны - 16 миллисекунд на все. При этом отрисовка происходит одновременно и на GPU и на CPU параллельно. Если на CPU кадр отрисовывается за 40 ms, а на GPU за 20 ms, то мы получим 25 FPS, а наша игра получит гордое название CPU-bound игры. Если же наоборот, ты мы получим те же самые 25 FPS, но уже GPU-bound. При этом чтобы не затормаживать рендер и вовремя отправлять данные на GPU на приходится держать данные для GPU в оперативной памяти и отправлять их из нее в видеокарту в нужные моменты времени. С этим связана, например, проблема и интегрированными GPU - во первых свою память интегрированный GPU выделяет из оперативной, оставляя ОС и игре еще меньше чем было, во-вторых располагаясь на одном чипе они конкурируют за шину, в третьих мы начинаем очень сильно зависеть от частоты оперативной памяти.   Теперь о возможных путях уменьшения используемой оперативной памяти: 1) Можно уменьшить количество используемой RAM за счет того, что при приближении к острову более детальные текстуры будут подгружаться с диска, например, но это может вызвать невыносимые тормоза и лаги в виде исчезающих и появляющихся из ниоткуда островов (как у нас сейчас иногда происходит с кораблями, когда прицел лочится на невидимой цели, а потом уже появляется и цель)   2)Можно ухудшать визуал самой игры - делать еще хуже модели кораблей и островов для low-пресетов графики, убрать домики с островов, или вообще убрать все острова обозначив их просто красными глыбами без текстур. Это еще один краеугольный камень разработки, но теперь уже больше из геймдева - визуал или скорость?   В любом случае, я лично считаю, что наша игра потребляет довольно мало памяти, а ее системные требования ОЧЕНЬ низки. Кстати, буквально сегодня наткнулся на исследование производительности нашей игры на различных видеокарточках. Там же можно посравнивать производительность нашей игры с другими играми, выходит весьма занятно.   Насчет удаления клиента - с заходом паков эта проблема должна уйти. И я надеюсь, что клиент вам в принципе не придется часто переустанавливать с нуля начиная с 0.5.5  

Santcoder: Я не думаю, что какой-то профит от этого будет - диск-то один все равно будет.  

Santcoder:   Работаем над этим, благо проблему удалось локализовать