Идеи по оптимизации Stellaris

[Detech 2,183]

Core i7-4770K + 24GB оперативы + SSD. Игра никогда не загружала ни одно ядро даже на 10%.

 

Игра просто летала на любых скоростях и даже намека на фризы не было. Пока не начался War in Heaven. В этот момент как будто тумблер переключили, игра начала фризиться каждый день на пол секунды, и первого числа каждого месяца - на 8-10 секунд. При том что в принципе ничего кроме активизации эвента не произошло. Проц как не был загружен - так и не загружен. Отображаемые флоты не увеличились. Перезагрузка не спасает.

Причем когда проснулась первая империя и начала воевать с половиной карты - ничего не произошло, все было ок. Но как только проснулась вторая и отобразилось сообщение WiH - все поплыло

 

У них явно в коде где то зацикливания, другого объяснения не вижу..

Изменено 11.03.2017, 13:00:29 пользователем Detech

[Saby 201]

В 11.03.2017 в 16:59, Detech сказал:

Причем когда проснулась первая империя и начала воевать с половиной карты - ничего не произошло, все было ок. Но как только проснулась вторая и отобразилось сообщение WiH - все поплыло

 

У них явно в коде где то зацикливания, другого объяснения не вижу..

 

Никаких зацикливаний. Просто выросло число расчетов по экспоненте - вот и фризы появились.
Для каждой страны рассчитывается взаимодействие с другими сторонами. У Вас было 20 воюющих сторон (притом 1 vs 20), стало 40 (20 vs 20). Объем вычислений был 1 х 20 + 20 х 1 = 40, стал 20 х 20 + 20 х 20 = 800. Увеличение в 40 раз. 40 раз = 0,5 секунды, 1 раз = 0,5 / 40 = 0,0125 секунды (что незаметно).

Как-то так, я думаю.

[had 2,587]

@Saby

Там как минимум в интерфейсе есть какие-то петли (ну в хои, но мне кажется, что в стелларисе то же самое).

Обещали убрать тормоза при выборе большого флота, что тоже факт в пользу петлей.

 

 

Меня вообще удивляют люди, которые где-то в стелларисе нашли сложные для современных процессоров расчеты.

Просто откройте диспетчер посмотрите как убого распаралелена игра.

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

[Zugr 15]

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

Изменено 22.03.2017, 01:34:29 пользователем Zugr

[Saby 201]

17 часов назад, had сказал:

@Saby

Меня вообще удивляют люди, которые где-то в стелларисе нашли сложные для современных процессоров расчеты.

Просто откройте диспетчер посмотрите как убого распаралелена игра.

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

 

То есть на Вашей системе фризов нет?

Про нагрузку долго смеялся.
Максимум на ГПУ можно часть расчетов скинуть, но - это явно не логические расчеты, if / else конвейер видеокарты вообще плохо переваривает, а в логике игры как раз большая часть это if / else (точнее switch).

 

Что до х64 - не будут трогать вылизанный код ровно до тех пор, пока не припрет. ИМХО, перепишут уже в следующей игре, поскольку 32 бита ушли в прошлое лет 10 тому назад.

Update. Вроде люди пишут, что игра 64-бита пользует.

Изменено 22.03.2017, 15:03:05 пользователем Saby

[had 2,587]

4 часа назад, Saby сказал:

То есть на Вашей системе фризов нет?

Есть офк.

Парадоксы же рукожопы.

 

Вот еще посмейся

Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое.

 

4 часа назад, Saby сказал:

Вроде люди пишут, что игра 64-бита пользует.

Зачем читать, если можно открыть диспетчер?

 

Из дневника по хои  

И последнее, самое полюбившееся мне. В нашем движке Clausewitz существовала старая часть цикличного кода, к которому никто не хотел прикасаться. Он обрабатывал все элементы пользовательского интерфейса "напрямую", а не "иерархично". Это значит, что чем больше окон и кнопок мы добавляем, тем этот цикл становится все объемней и объемней. Окну даже не обязательно было отображаться, оно все равно продолжало замедлять игру. Мы знали об этом позорном недостатке, но переработать его, при этом не сломав весь интерфейс игры, было невозможно. До этого момента - я нашел способ! Раньше цикл производил около 120 000 проходов за один кадр, а теперь же меньше 700, обрабатывая только необходимые элементы интерфейса. Под этим имеется в виду, что когда вы смотрите на древа технологий, то код больше не обрабатывает остальные закрытые окна производства, политики и.т.д

Hide  

Изменено 22.03.2017, 19:46:57 пользователем had

[Saby 201]

2 часа назад, had сказал:

Парадоксы же рукожопы.

Кто сказал? 
Будь они такими - их бы давно вышибли со своего сегмента )))

 

2 часа назад, had сказал:

Вот еще посмейся

Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое.

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

Осталось понять, каким образом мы это сможем сделать на С/С++ (чтобы побыстрее работало) для скриптового языка а-ля Lua, которая ничего подобного не умеет в принципе.

Я понимаю, когда табличные значения можно использовать, допустим, для sin(x) / cos(x) с шагом в 0,1 градус. Окей, это оправдано.
Но для скрипта... Ржака.

 

2 часа назад, had сказал:

Зачем читать, если можно открыть диспетчер?

Точно. Запустил винду и проверил.

Ну а тут самое вкусное )))

"И последнее, самое полюбившееся мне. В нашем движке Clausewitz существовала старая часть цикличного кода, к которому никто не хотел прикасаться. Он обрабатывал все элементы пользовательского интерфейса "напрямую", а не "иерархично". Это значит, что чем больше окон и кнопок мы добавляем, тем этот цикл становится все объемней и объемней. Окну даже не обязательно было отображаться, оно все равно продолжало замедлять игру. Мы знали об этом позорном недостатке, но переработать его, при этом не сломав весь интерфейс игры, было невозможно. До этого момента - я нашел способ! Раньше цикл производил около 120 000 проходов за один кадр, а теперь же меньше 700, обрабатывая только необходимые элементы интерфейса. Под этим имеется в виду, что когда вы смотрите на древа технологий, то код больше не обрабатывает остальные закрытые окна производства, политики и.т.д "

Во-первых слово "цикличный" тут не подходит. Имелся ввиду обыкновенный перебор, слепленный на коленке под возможности тогдашнего старого движка. Его (ИМХО) один раз сделали, посмотрели что работает, и нахер. Подстроили под него продакшн процесс и не трогали, ибо дорого (и долго) - они писали, что до выхода Vic2 жили от проекта до проекта, на грани банкротства - соответственно просто не могли себе позволить рефакторинг.
Надо понимать, что такое "движки" конца 90-ых, когда лепили первую Европу )))

Я начинал знакомство с программированием с OGRE3D / С++. Вывод overlay там был... Очень интересный. А это уже минимум 2005 год и ОДИН ИЗ ЛУЧШИХ open-source движков, наиболее продвинутый из бесплатных на тот момент.
Второе - скриптовые движки были малоизвестными. Тот же LUA популярным стал ближе к 2003 году, насколько я помню. А они свой скриптовый двиг писали ЕЩЕ РАНЬШЕ. Скорее всего там была очень жгучая смесь )))

 

Сегодня все куда лучше.
Потому что и шаблоны умеет использовать каждый, и Boost довольно сильная вещь для С++ программиста, и много еще чего, включая развитие и самого языка. И инет в каждом доме (раньше книги скачивали / покупали, там ошибки еще бывали). В-общем, доступ к инфе в 1999-2000 году был мал-мал другой, нежели сегодня )))

 

Из личного примера - мне доводилось работать с кодом 2003 года, где сокеты были хоть асинхронными, но не имели длины. И там был код для подсчитывания контрольных сумм полученных данных, чтобы определить, пришли ли пакеты. В-общем, там ОБЕРТКА над этим превышала полезный код (код логики) раз этак в 10. 
Я спросил - а с фуя ли в 2014 году не переделать все под нормальные сокеты. Мне было отвечено в стиле "Молодой человек! У нас сервер писался с 1999 года. Там столько взаимосвязанного кода, что его никто не будет переписывать. Работает - ну и куй с ним!"
Поэтому то, что можно было сделать за пару часов на нормальных сокетах, а там делал дня 4, пока не вдуплил в механизм работы этой херни. Попутно поправил ошибку с дублированием одной из редкоиспользуемых команд. Тикет висел с 2005 года...

Вот так оно в производстве и обстоит.

Ладно, закончим на этом.

[had 2,587]

@Saby

Плохих кодеров вытягивают хорошие гейм дизайнеры.

В итоге в игру интересно играть, а потом ты ее дропаешь из-за лагов.

 

Над чем смеяться?

Ты считаешь функцию 1 раз. Потом вызываешь ответ по таблице. В си без проблем написать свою реализацию, впрочем, все сделано до нас, метод то банальнейший. Причем не единственный.

 

Более чем уверен, что в стелларисе дофига одних и тех же обсчетов.

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

 

Ой, ну мы в курсе о проблемном участке, но нам короч не впадлу стало только сейчас. Этож ппц.

Изменено 23.03.2017, 02:10:30 пользователем had

[Saby 201]

4 часа назад, had сказал:

@Saby

Плохих кодеров вытягивают хорошие гейм дизайнеры.

Не, Эадор это совсем другая тема.
 

4 часа назад, had сказал:

Над чем смеяться?

Ты считаешь функцию 1 раз. Потом вызываешь ответ по таблице. В си без проблем написать свою реализацию, впрочем, все сделано до нас, метод то банальнейший. Причем не единственный.

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

 

4 часа назад, had сказал:

Ой, ну мы в курсе о проблемном участке, но нам короч не впадлу стало только сейчас. Этож ппц.

)))

Это практически стандарт в разработке. Я работал в средней компании (> 100 человек), общался с другими программистами из таких же контор. Везде одинаково. Чем кода больше, тем менее вероятность приведения его в божеский вид. Только когда совсем припрёт.

[had 2,587]

3 часа назад, Saby сказал:

Это практически стандарт в разработке. Я работал в средней компании (> 100 человек), общался с другими программистами из таких же контор. Везде одинаково. Чем кода больше, тем менее вероятность приведения его в божеский вид. Только когда совсем припрёт.

А если у тебя на форуме почти год создают темы с вопросом "когда же продукт перестанет лагать?", то тоже все забивают?

3 часа назад, Saby сказал:

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

Таблицы являются самым важным типом данных в Lua и являются фундаментом для пользовательских типов данных, таких как Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое. , Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое. , Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое. , Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое. . Таблица в Lua представляет собой набор пар — (Ключ, Значение). Ключом может выступать значение любого типа, кроме nil.

(с) вики.

Ну не видел и не видел.

Изменено 23.03.2017, 10:01:28 пользователем had

[Saby 201]

3 часа назад, had сказал:

А если у тебя на форуме почти год создают темы с вопросом "когда же продукт перестанет лагать?", то тоже все забивают?

Можно упростить часть расчетов, сделать АИ тех же секторов "менее умным". Будет лагать поменьше. Но пользователи будут еще больше вянгать, потому что "АИ стал тупЭе"...
 

3 часа назад, had сказал:

Таблицы являются самым важным типом данных в Lua и являются фундаментом для пользовательских типов данных, таких как Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое. , Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое. , Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое. , Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое. . Таблица в Lua представляет собой набор пар — (Ключ, Значение). Ключом может выступать значение любого типа, кроме nil.

(с) вики.

То есть ты непонимаешь отличие между tabling-функцией и массивом? Бывает.
На всякий случай дам ссылку на вики для понимания

Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое.

И попутно погляди на примеры, в которых эта табличность и используется. Там в основном функция принимающая 1 параметр и использующая только его.

А теперь давай подумаем, что же можно улучшить табличным способом...
Расчет пути по графу из 1000 планет? Так оно и так сделано.
Расчет АИ секторов - вряд ли, там не одна и не две переменные.
Расчет дипломатического АИ? Аналогично. 
Расчет построения кораблей по системам? Аналогично.
Что же мы будем улучшать табличными значениями?

 

3 часа назад, had сказал:

Ну не видел и не видел.

Вот только что посмотрел lua-файлы стеллариса. Массивы есть, табличных функций - нет.

[had 2,587]

3 часа назад, Saby сказал:

Можно упростить часть расчетов, сделать АИ тех же секторов "менее умным". Будет лагать поменьше. Но пользователи будут еще больше вянгать, потому что "АИ стал тупЭе"...

Да он и так тупой, (минутка хвастовства, мой скрипт на автопостройку хотяб не игнорит пустые клетки с населением), а вот без лагов было бы прикольно играть.

 

3 часа назад, Saby сказал:

Там в основном функция принимающая 1 параметр и использующая только его.

В чем проблема написать собственную реализацию от десяти параметров с 10мерным массивом?

Просто суть метода в том, чтобы не считать 10 раз одно и то же.

Я конечно доступа к исходникам не имею, но по наблюдениям там такие одинаковые расчеты есть на дневных тиках.

Кроме ии есть куча вещей типо расчета урона кораблей или доходов с каждого тайла, космостанций и тд.

3 часа назад, Saby сказал:

Вот только что посмотрел lua-файлы стеллариса. Массивы есть, табличных функций - нет.

Луа такое может, так что это уже проблемы стеллариса.

 

И да, это просто обсуждение ОДНОГО из возможных методов снижения нагрузки на проц за счет памяти. Может быть даже он используется (верится с трудом), факт в наличии алгоритмов, торгующих цпу за рам. А также в высокой нагрузке на цпу и низкой на рам.

 

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

[Saby 201]

9 минут назад, had сказал:

В чем проблема написать собственную реализацию от десяти параметров с 10мерным массивом?

Просто суть метода в том, чтобы не считать 10 раз одно и то же.

Вы, вероятно, очень далеки от программирования, раз такое пишете.

Предлагаю посчитать.
Возьмем для прикола чисто целые числа - от 1 до 10. И представим, что каждый параметр у нас изменяется не более чем в таких пределах.
Суммарный массив всех вариантов у нас займет 10 в 10 степени - 10 Гигабайт памяти в лучшем случае (на самом деле эту цифру надо умножать на размерность возвращаемого результата).
Плюс - в Стелларисе не целочисленная математика, а дробная.

Я уже писал, где можно пользовать такое.

 

9 минут назад, had сказал:

И да, это просто обсуждение ОДНОГО из возможных методов снижения нагрузки на проц за счет памяти. Может быть даже он используется (верится с трудом), факт в наличии алгоритмов, торгующих цпу за рам. А также в высокой нагрузке на цпу и низкой на рам.

Нет таких алгоритмов )
 

9 минут назад, had сказал:

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

Шта? Если Вы играете достаточно ДАВНО, то Вы наверное помните, что в том же Варкрафте третьем было ОГРАНИЧЕНИЕ на кол-во юнитов. Как Вы думаете, чем оно вызвано у "нерукожопых программистов"? Подсказываю - расчетом пути по графу.
Возьмем 4х. Цива третья - в 2001 году в концовке игры один ход компа с полностью отключенной анимацией всего что можно, длился от 5 до 15 минут. Я нажимал "завершить ход" и читал книгу . Через 8-10 ходов комп вылетал на рабочий стол, а я перегружал комп и играл в другую игру. Поэтому за 2 месяца игры завершил одну партию - на вторую банально терпения не хватило.

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

[had 2,587]

20 минут назад, Saby сказал:

Шта? Если Вы играете достаточно ДАВНО, то Вы наверное помните, что в том же Варкрафте третьем было ОГРАНИЧЕНИЕ на кол-во юнитов. Как Вы думаете, чем оно вызвано у "нерукожопых программистов"? Подсказываю - расчетом пути по графу.

Эм, в первую очередь балансом, можно в кастомке спаунить юнитов вплоть до графических артефактов.

И с перемещением у них будет все ок (ну насколько это возможно в такой толпе из сотен юнитов).

21 минуту назад, Saby сказал:

Суммарный массив всех вариантов у нас займет 10 в 10 степени - 10 Гигабайт памяти в лучшем случае (на самом деле эту цифру надо умножать на размерность возвращаемого результата).
Плюс - в Стелларисе не целочисленная математика, а дробная.

Не обязательно же все сохранять. Можно сохранять последние эн вызовов функции.

Памяти игра все равно потребляет мало.

Ну и я как юзер разменял бы 10гб оперативы на прирост в -10% нагрузки цпу как нефиг делать.

22 минуты назад, Saby сказал:

Нет таких алгоритмов )

Я привел один пример. Дальше гугл.

23 минуты назад, Saby сказал:

в Стелларисе не целочисленная математика, а дробная.

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

[Pasha223 122]

51 минуту назад, had сказал:

Ну и я как юзер разменял бы 10гб оперативы

Вернись в реальность. Планки на 10гб в разы дороже сабжевой игры. 

[had 2,587]

Только что, Pasha223 сказал:

Вернись в реальность. Планки на 10гб в разы дороже сабжевой игры. 

Ну так можно в кучу игра играть с оперативкой на 12-16гб.

Ну и 8гб стоит 4к, прям как крусайдеры со всеми длс.

Я думаю, у большинства 8гб оперативы, 4гб будет стоить 2к.

Это намного дешевле, чем апать проц.

[Saby 201]

1 час назад, had сказал:

Эм, в первую очередь балансом, можно в кастомке спаунить юнитов вплоть до графических артефактов.

И с перемещением у них будет все ок (ну насколько это возможно в такой толпе из сотен юнитов).

В те годы игры рассчитывались на запуск на компах 4-5 летней давности (сейчас проверю - вот минимальный процессор PII 400 MHz - как раз с 97 года выпускался, 128 Мб памяти и 32 Мб видео.
Попробуйте запустить на этой конфигурации орды.
 

1 час назад, had сказал:

Не обязательно же все сохранять. Можно сохранять последние эн вызовов функции.

Памяти игра все равно потребляет мало.

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

1 час назад, had сказал:

Ну и я как юзер разменял бы 10гб оперативы на прирост в -10% нагрузки цпу как нефиг делать.

Зачем брать память, когда взять более проц с более высокими частотами на ядро и большим кэшем - он нисколь не меньше скорости добавит.

 

1 час назад, had сказал:

Я привел один пример. Дальше гугл.

Вот смотри - когда то давно я пробовал только-только программировать, и, наигравшись в ХоИ2, решил написать нечто подобное. С++ я знал на очень любительском уровне. Сказано, сделано... - скачал книжонок по С++. Задался целью для начала сгенерировать случайный мир.
О диаграмме Вороного, шумах Перлина и прочем я тогда ПОНЯТИЯ не имел, но у меня был модемный инет и огромное желание кодить в свободное от работы время.
Постановка задачи была проста - сделать достойную карту провинций по заданному шаблону (соотношение суша/вода, сколько континентов, сколько мелких островов (1-2 провинции), сколько средних, есть ли озера, какого размера озера допустимы, минимальное расстояние между континентами и ПРОЧЕЕ. Карта должна быть seamless со всех сторон (если бы не это, генерировалось бы побыстрее).
На момент начала мои познания были равны чуточку выше "Hello world". Я даже собрать чужой код (тот же 3d движок из исходников посредством CMake) - не умел.
Но задачу я тогда решил. (Хотел поискать картинку с результатом - выкладывал когда-то на gamedev'e, не нашел). Но оценив объем работ, бросил )
Код у меня оптимизировался по ходу "роста".
Сперва карта размером 2000 х 2000 пикселей (вот вспомнить бы там кол-во провинций... По-моему около 2500 на выходе было) генерировалась за примерно 8-10 минут (в зависимости от рандома).
По мере изучения С++ и совершенствования алгоритма (но в основном работы с памятью, конечно - просто выделял под все задачи сколько нужно памяти сходу, чтобы избежать реаллокаций) - та же самая карта с теми же самыми условиями стала генерироваться за 2-3 сек.

Что сократило время генерации? По большей части несколько самописных рандомов (где был нужен хороший рандом - отдельный класс, где примитивный - простейший: сдвиг / умножение / плюс = новый seed, если я правильно помню). Ну и замена всех new на выделение статических массивов максимального объема.

Это основное - работа генератора снизилась с 600 секунд до примерно 16.
Дальше в ход пошла "постоптимизация".
А именно предрассчитывались массивы минимального и максимального диаметра для того, чтобы быстрее обносились "занятыми" точки воды. Это уменьшило одну из самых тяжелых стадий расчета (а значит и время общего) еще в несколько раз.

И могу тебя уверить, что в продакшене подобные вещи делаются СРАЗУ. Поскольку неоптимизированные подобные расчеты увеличивают время работы программы в РАЗЫ. Время работы функций отслеживается инструментами IDE и поехали исправлять самые тормозящие вещи. 

Исправление в сторону быстродействия в 99,99% случаев одно - изменение алгоритма в сторону упрощения. Но иногда вот бывают вещи, подобные той, что выше. "Ой, мы таки исправили проблему, которая преследовала нас последние 3 года... какая красота!"

 

1 час назад, had сказал:

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

Ну потому что прирост на 5% должен быть честным )
И если у тебя пишется прибавка к +5 минералам равна 5 * 0,05 = 0,25, то на выходе должно быть именно 5,25%, а не 6, не 0, и не 10.
Поэтому могут перейти с double на float (это так, гипотетический пример, на самом деле точность вычислений в основных функциях всегда минимально допустимая по точности.

Например, на мобилках большинство шейдеров рассчитываются на half-float'e (по крайней мере, в 2014 это было именно так).

Все, закончим флуд, извините.

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

[had 2,587]

@Saby

На актуальном пк вк3 не лагал. Даже с тыщами юнитов в кастомке.

 

На пк, превосходящем требования, стелларис изи лагает на 1к галактике. Не говоря уж про моды. При том стелларис типо новая игра, технологии не стоят и тд. Мне сложно припомнить игру с лоу фпс. Даже в индюшатине стандарт 60фпс, не говоря уж про нормальные студии.

 

Оператива дешевле проца в разы.

 

Какие могут быть вычисления у сектора?

В начале накидать ферм в конце снести.

Дальше уважать плитки ресурсов, дальше строить по приоритету плюс подстраивать энергию.

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

 

Короче свое видение я реализовал в моде. Насколько это возможно с апи стеллариса.

 

Я выше писал, где бы я использовал такой метод.

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

 

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

[Saby 201]

27 минут назад, had сказал:

@Saby

На актуальном пк вк3 не лагал. Даже с тыщами юнитов в кастомке.

Актуальный пк в те годы был у 20% пользователей. Сейчас - менее чем у 10%. Покажите пальцем на буржуя, который захочет иметь в 5 раз меньше прибыли.
 

27 минут назад, had сказал:

На пк, превосходящем требования, стелларис изи лагает на 1к галактике. Не говоря уж про моды. При том стелларис типо новая игра, технологии не стоят и тд. Мне сложно припомнить игру с лоу фпс.

В жанре 4х стратегий? Загибайте пальчики - Civ5, Civ5: Beyond, Endless Legend - тормозят дай боже.
В 6-ую я не играл, вангую, что на огромных картах тоже самое в конце (если конечно игрок не нагнул всех).

 

27 минут назад, had сказал:

Даже в индюшатине стандарт 60фпс, не говоря уж про нормальные студии.

)))

В индюшатине нечему тормозить обычно. Но Rimworld на крупной колонии тормозит весьма и весьма.
Можешь глянуть последние видео у Антохи Галактического. Даже на его неслабом компе игра тормозит. Притом что в самой игре закэшировано все что можно, потому как Тайвин (или Петр) очень шарит в этом. Было видео, где он рассказывал про чанкирование/кэширование областей и что сделано для того, чтобы игра не тормозила даже при больших размерах. Тем не менее, даже при этом от производительности не убежишь - лагает.
 

27 минут назад, had сказал:

Оператива дешевле проца в разы.

Войдите или зарегистрируйтесь, чтобы увидеть скрытое содержимое.

Разница между i5-7600K и i7-7700K 5800 рублей. Разница в вычислениях на ядро ~15%.
2 планки памяти на 16 Гб стоит порядка 6500 (2 потому что двухканальные для многоядерного проца сегодня работают быстрее, чем 4-ех).
 

27 минут назад, had сказал:

Какие могут быть вычисления у сектора?

В начале накидать ферм в конце снести.

Дальше уважать плитки ресурсов, дальше строить по приоритету плюс подстраивать энергию.

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

Очень сложные.
Начиная от типов поведения и ограничений и до выбора приоритетов.
И считается он конечно не каждый день, а строго по надобности, для чего ставят флажок (needUpdateBuildingQueue, например). При Update смотрятся по флагу, есть ли изменения, и сектор пересчитывается. Флажок, подозреваю, отнюдь не один. Потому как одно дело - у нас построился объект, надо строить новый. B совсем другое - у нас бастанул рабочий, надо пересчитывать ПОПов на местах + модификаторы планетки. То бишь вырос новый ПОП, надо пересчитывать и (1) и (2), неприятель разбомбил здание - тоже (1) и (2), и так далее. 

 

27 минут назад, had сказал:

Я выше писал, где бы я использовал такой метод.

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

Я уже описал как там это реализовано (а сделано это именно так, дураков нет, поверьте).

 

27 минут назад, had сказал:

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

Поэтому Вас и нельзя допускать до продакшена )))

[had 2,587]

@Saby 

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

 

Римволд не лагает даже с тяжелыми модами, при том он ерли аксес.

А стелларис - готовый продукт от нормальной студии спустя почти год после релиза.

 

И пк у меня довольно старый.

 

Почему вдруг 32гб? Речь шла о сферических 10. У обычного юзера в век х64 приложений и так будет 8гб, если он в новые релизы хочет играть.

Да и к тому же обладание ай семь от лагов не спасает, а для других игор не нужно.

 

Судя по багам ии (цикличные перемещения попов, порабощение/освобождение по тикам и тд), эти флаги не работают или работают неверно.