XENO | Второй этап проблем с производительностью и Open-CL 2.0

В 3D сцене применяется реальная модель гравитации, что приводит через некоторое время к высоким расходам процессорной мощности, объекты начинают сталкиваться или неожиданно скапливаться вокруг центров масс в плотности 3Д моделей которая не планировалось для единовременного наблюдения камерой - все объекты в движении, вычислениях, требуются дополнительные программные решения обеспечивающие эти процессы. При этом Фантастическая игра должна демонстрировать достаточную плавность движения, и при большом мире звезд и объектов с учетом постоянно добавляемых опций сохранять ее все сложнее. Кроме этого началось добавлеие функционала выбора объектов на сцене мышкой, что бы например можноо было нажимать на планеты в фантастической игре, постоянные проверки на пересечения 3D объектов с координатами мышки для выбора мышкой оказались очень сильными потребителями FPS. Изначальную модель столкновений пришлось дополнить дополнительной более детальной, она так же отъедает производительность.

Управление по всем 3-м осям координат, многочисленные вычисления по каждой, начинают давать понимание почему стратегии часто выходит в 2D, или они 3D но размещается все в двухмерной плоскости. Одно дело плавный полет 50 кораблей, другое дело когда есть 3 фантастические цивилизации и у каждой должен быть флот хотя бы по 500 кораблей + астероиды и другие звездные системы, в итоге 4-х ядерный процессор с большим трудом держит кадры и это без боя космических кораблей, с боем он ничего держать вообще несможет (выстрелы и т.д.). Не говоря о том что 3 цивилизации это не то что планировалось. Что бы корабль сталкивался приемлемо на вид это еще одна проблема, одной механики столкновений по сфере и далее вызов подпрограммы проверки промаха или попадания в разные части корпуса 3D модели недостаточно, а каждая технология дающие новые скорости полета кораблям повышает требования к вычислениям этих полетов, но в фантастической игре скорости и должны стремится быть максимально разные что бы отразить технологический прогресс.

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

В 2D экране сложно разместить 1000 кораблей даже при нескольких слоях, умещается 40-80 или 200 кораблей что вполне легко плавно вычисляется и не создает проблем, т.е. сама плоскость экрана непозволяет в нее влететь такому числу объектов которые бы создавали проблему вычислений, в отличие от 3D где вращая камеру по всем направлениям можно увидеть бесчисленное множество объектов во всю глубину каждого направления, которые нужно отображать в реальном времени, а поместится в этих направлениях может много всего потребляющего ресурсы компьютера, либо требуется многоядерный сервер для игры а оффлайн игру реализовывать в минимальном числе цивилизаций и звезд, или нужно подключать к проекту игры физический движек работающий на видео-карте например OpenCL, а будут ли будущие поколения видео-карт поддерживать нынешнюю версию технологии CL? Что если станут выпускать такие OS и драйвера и видео-карты где будут поддерживаться только более ее новые версии и игровое решение небудет работать с новейшими видеокартами. Поэтому любая докрутка новых модулей вызывает риски нестабильности или возможные будущие сложности.

Таким образом программа обзавелась множестом дополнительных вычислений часто маленьких, но очень прожерливый дополнительный код множится на астероиды, планеты, корабли, звезды и требует еще мощности компьютера, конечно если отбросить часть звезд и оставить только плоскую галактику отказавшись от объемных это бы существенно высвободило мощность системы для космических кораблей, т.е. вместо изначальной задумки создавать нечто похожее на то что ранее уже существовало в индустрии фантастических игр или переносить вычисления на сервер, но и это решение сталкивается с проблемой TCP протокола - объем данных по нему при быстрой синронизации по кадрам не соответствует скорости Ethernet кабеля в 100-200 Мегабит в итоге сохраняется проблема расположения рядом друг с другом множества кораблей или космических объектов, пока они в разных частях пространства их параметры можно не передавать по интернету но в случае например войн заставить все империи держать корабли подальше друг от друга неполучится особенно при войнах нескольких империй против одной. Та же проблема возникает при перенасыщенности сцены объектами которые требуют каждый проверку можно ли на них нажать мышкой или нет и это критически снижает частоту кадров. Потребуется найти подоходящее решение / испытывать разные. Первое что пробуется это перенести все эти подпрограммы на рассчеты видеокартой задействуя OpenCL 2.0, и написать на ней нужную физику, версия 2.0 позволяет использовать код при котором процессор меньше нагружается при взаимодействии с видео-картой по данной технологии чем v1.2, это позитивная сторона, однако это стандарт 2013-го, видеокарты его поддерживающие где-то начиная с 2015-х годов выпуска, т.е. если получится задействовать эту технологию то многие видеокарты до 2015-го года выпуска для проектируемой игры теперь неподойдут, и это не очень хорошо так как очень много рабочих видеокарт по технологиям 2013-х годов и более ранних с огромным количеством шейдеров и DX9 и DX11 которые всю графику игры успешно поддерживают поэтому было бы неплохо потом попробовать сделать поддержу и OpenCL 1.2 в дополнение это может позволить применение видеокарт выпущенных на пару лет раньше 2015-х, и он вместе с OpenCL 3.0 входит в самые последние выпускаемые видео карты и значит будет еще долго поддерживатся, было бы просще работать сразу в 3.0 он легче по коду, но это отбрасывает множество видеокарт выпущенных и в 2018-х годах.