Você fala sobre "dificuldades de multithreading", mas de quais dificuldades você está realmente falando? De certa forma, você está citando um problema fantasma que pode até nem existir. O verdadeiro desafio que você faz para si mesmo - se você está absolutamente determinado a obter toda a última gota de energia de um pedaço de hardware, isso envolve o uso do hardware para obter o melhor efeito, mas também amplia a brecha entre a máquina mais poderosa e o menos poderoso. A implicação disso é que, se você tem um jogo que realmente aproveita ao máximo um PS3 (por exemplo), não é possível executá-lo em um celular barato de qualquer maneira, então seu problema não é mais "como posso obter um programa?" para trabalhar com hardware muito diferente ", mas torna-se" como posso implementar uma ideia de jogo de várias maneiras diferentes, para que funcione em hardware com alimentação diferente ".
Embora uma biblioteca como SDL forneça uma API de wrapper de plataforma cruzada para threading, acho que seria ingênuo supor que isso leva diretamente ao fácil desenvolvimento de jogos em plataformas muito diferentes (desktop / celular).
Fácil desenvolvimento de jogos - com certeza. Multithreading ideal, não. Mas você não precisa de multithreading para criar jogos. Para criar peças de alto desempenho, certamente ajuda. Mas muitos jogos excelentes rodam em um único segmento.
Qual é a melhor maneira de enfrentar o desenvolvimento dessa maneira (considerando qualquer API de encadeamento de plataforma cruzada), considerando o seguinte:
- diferentes números de núcleos
- capacidades de processamento muito diferentes por núcleo
- Uma arquitetura de sistemas geralmente diferente com, por exemplo. latências diferentes para acesso a cache, RAM e E / S
Em vez de tentar atribuir sistemas a threads, atribua tarefas a threads. Forneça a cada tarefa os dados necessários para executar e faça o farm das tarefas para o hardware disponível. Normalmente, você terá algum tipo de conjunto de encadeamentos para abstrair os vários núcleos ou processadores, e um gerenciador de tarefas que possui uma fila de tarefas e os produz até os vários encadeamentos quando o encadeamento sinaliza que concluiu a tarefa anterior e está pronto para um novo. O hardware com mais núcleos obviamente concluirá as tarefas mais rapidamente e poderá renderizar mais rapidamente. A especialização desse sistema para funcionar de maneira ideal em sistemas com características diferentes torna-se um problema de otimização avançado, mas pode ser baseado em certas heurísticas (por exemplo, uma tarefa que não é necessária).
No entanto, a decomposição dos recursos do jogo em tarefas discretas é um assunto bastante complexo e geralmente não vale a pena, a menos que você tenha certeza de que precisa do desempenho, para que a maioria nem tente.
Algumas leituras adicionais:
http://www.gamasutra.com/view/feature/1830/multithreaded_game_engine_.php - consulte a seção 'paralelo de dados'. Com esse modelo, os dados são divididos em várias tarefas idênticas e gerados em threads individuais.
http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/ - bastante denso, descreve as coisas no nível do sistema operacional e não no nível do jogo.
http://drdobbs.com/high-performance-computing/216500409 - não específico do jogo, mas completamente relevante em termos de como você precisa dividir as tarefas.
http://www.itfgaming.com/news/tech-focus-crysis-2-and-the-future-of-cryengine-3 - no meio desta entrevista, há uma anedota sobre como eles migraram para um sistema baseado em tarefas .