Вы говорите о «многопоточности», но о каких трудностях вы на самом деле говорите? В некотором смысле вы цитируете проблему с фантомом, которая может даже не существовать. Настоящая проблема - это та, которую вы создаете для себя - если вы абсолютно решительно настроены использовать каждую аппаратную часть до последней капли энергии, то для этого необходимо использовать оборудование для достижения наилучшего эффекта, но это также увеличивает разрыв между самой мощной машиной. и наименее мощный. Смысл этого заключается в том, что если у вас есть игра, которая действительно использует PS3 (например), вы все равно не сможете запустить ее на дешевом мобильном телефоне, так что ваша проблема больше не заключается в том, «как я могу получить 1 программу? работать на очень разных аппаратных средствах ", но становится", как я могу реализовать одну идею игры несколькими различными способами, чтобы она работала на аппаратных средствах с различным питанием ".
Хотя такая библиотека, как SDL, предоставляет кроссплатформенный API-оболочку для многопоточности, я думаю, что было бы наивно полагать, что это напрямую ведет к простой разработке игр для совершенно разных платформ (настольных и мобильных).
Легкая разработка игр - конечно. Оптимальной многопоточности нет. Но вам не нужна многопоточность для создания игр. Чтобы сделать высокопроизводительные, это, безусловно, помогает. Но многие отличные игры работают в одном потоке.
Каков наилучший способ разработки таким способом (с учетом любого кроссплатформенного API потоков), учитывая следующее:
- разное количество ядер
- очень разные возможности обработки на ядро
- Как правило, другая системная архитектура, например, различные задержки для кэша, оперативной памяти и доступа к вводу / выводу
Вместо того, чтобы пытаться назначать системы потокам, назначайте задачи потокам. Предоставьте каждой задаче данные, необходимые для ее выполнения, и перенесите задачи на любое доступное оборудование. Обычно у вас есть какой-то пул потоков для абстрагирования различных ядер или процессоров, а также диспетчер задач, который имеет очередь задач и передает их различным потокам, когда поток сообщает, что завершил предыдущую задачу и готов к новому. Аппаратное обеспечение с большим количеством ядер, очевидно, быстрее выполнит задачи и сможет рендериться быстрее. Специализация этой системы для оптимальной работы на системах с различными характеристиками становится сложной задачей оптимизации, но может основываться на определенных эвристиках (например, задача, которая не '
Однако разложение игровых функций на отдельные задачи является довольно сложным делом и зачастую не стоит усилий, если только вы не уверены, что вам нужна производительность, поэтому большинство даже не будет пытаться ее выполнить.
Некоторое дальнейшее чтение:
http://www.gamasutra.com/view/feature/1830/multithreaded_game_engine_.php - см. раздел «Параллель данных». С помощью этой модели данные разбиваются на несколько идентичных задач и разбиваются на отдельные потоки.
http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/ - довольно плотно, описывает вещи на уровне ОС, а не на уровне игры.
http://drdobbs.com/high-performance-computing/216500409 - не относится к конкретной игре, но совершенно уместно с точки зрения того, как вам нужно разделить задачи.
http://www.itfgaming.com/news/tech-focus-crysis-2-and-the-future-of-cryengine-3 - на полпути к этому интервью есть анекдот о том, как они перешли на систему на основе задач ,