А разве в современных x86 камнях АЛУ не настолько развитые, чтобы выполнять умножение за 1 такт?
Ну т.е. умножить, сложить, разделить - разницы нет, оно всё делается разом, а если операции разные на взаимонезависимые в пределах скольки-то тактов данных, то камни из хотя бы не самых дешёвых линеек в теории могут ещё и нагрузить все блоки АЛУ сразу, получив за один такт результат для нескольких уже находящихся на конвеере инструкций. Так что замена солянки из сложений и умножений на одни только сложения - максимум даёт более простую вычислительную модель, при реализации которой, гипотетически, можно перейти с бинарных операторов на векторные инструкции, но, насколько я понимаю игромех этой игры - векторные вычисления тут применять особо негде.С производительностью, по крайней мере в стелларисе, проблема с организацией многопоточности и ленивых вычислений.
Из того, что я вижу как пользователь, структура вычислений такова, что когда объём данных становится слишком большим, начинаются каскадные блокировки тредов, через ожидание ответа от других тредов. При этом таймеры обновления данных никто не останавливает, что приводит к перегрузке запросами. Ленивые вычисления - это вообще обоюдоострый меч - они прекрасно экономят процессорное время пока вычислять нечего или незачем, но когда объём данных растёт и, соответственно, растёт время выполнения вычислений - запрашивающему ленивые вычисления коду нужно задать какое-то поведение на то время, пока не получен результат. Если этого нет - код стоит и не выполняет ввод/вывод, в стелларисе это тот случай, когда интерфейс намертво подвисает, пока создаёт новый элемент и рисует его. Сами помните, что в лейте в больших галактиках перед тем как что либо делать руками, надо поставить игру на паузу и не делать больше одного нажатия клавиши пока интерфейс не отрисует всё, что связано с последним нажатием куда бы то ни было. Плюс полная остановка интерфейса на то время, пока игра пересчитывает справочные таблицы поиска путей, что происходит всякий раз, когда системы меняют владельцев или когда на карту добавляется новая система (хотя как это должно мешать, например, работать с очередями строительства в колониях - я просто не понимаю).
Но вот объём вычислений.. данных с каждым патчем становится больше, и тут первое что нужно делать - это рефакторить код на предмет выполняемых много раз вычислений, результат которых не меняется, т.к. не меняются ни правила расчёта, ни исходные данные. В 2.6 на эту тему вроде неплохо так поработали, судя по тому, как игра идёт в лейте. Но каскадные фризы тредов - тут работы ещё много.
Короче: точность - (шанс уклонения - обнаружение) + шанс попадания
Лучше так:
шанс попасть = max(0, (min(100, итоговая_меткость_пушки) - max(0, (уклонение - ведение))))
Разбираем:
max(0, (уклонение - ведение))
Если ведение пушки позволяет постоянно держать цель на прицеле (т.е. tracking >= evasion), то на меткость нет штрафа. Если ведение не позволяет постоянно держать цель - на меткость накладывается штраф в размере разности уклонения и ведения.
min(100, итоговая_меткость_пушки)
Меткость не может быть больше 100%.
max(0, (min(100, итоговая_меткость_пушки) - max(0, (уклонение - ведение))))
Шанс попасть не может быть меньше нуля (на тот случай, если штраф от уклонения больше меткости)(чтобы мало ли, не было побочных эффектов из-за отрицательных значений в последующих вычислениях).
