XENO | Переход на 64 бита и многопоточность

Для достижения лучших показателей в скорости вычислений, необходимых для размещения в прототипе фантастической игры хоть какого-то флота, было проведено распараллеливание задач в многоядерное приложение, а заодно проведен перевод кода с 32 на 64 бита, теперь EXE файл 64 битный и многопоточный, распараллеливание вычислений позволило больше чем вдвое увеличить FPS, который теперь позволяет добавить в 3D сцену что-то еще, и появилось желание потратить часть его на улучшение детализации планет, подумав о том как сделать их не просто сферами с текстурой а более детализированными. В x64 переведена практически вся 3D основа кроме набросков интерфейса, на который позже уйдет некоторое время на рутинные задачи с ним что уже не представляет большой сложности.

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

Что касается модели взрывов, то примитивная модель видится в светящейся сфере которая расширяется и постепенно гаснет становясь прозрачной и при исчезновении по краям сферы генерируются обломки, однако такой взрыв примитивен, поэтому предполагается что будет сделан заказ графики взрывов 3-м дизайнерам, и выбрана лучшая модель лучше всего сочетающая красочность и одновременно приемлемую производительность.