Hablas de "dificultades de subprocesos múltiples", pero ¿de qué dificultades estás hablando realmente? En cierto modo, estás citando un problema fantasma que puede no existir. El verdadero desafío es uno que se haga por sí mismo: si está absolutamente decidido a obtener la última gota de energía de una pieza de hardware, eso implica utilizar el hardware para obtener el mejor efecto, pero eso también amplía la brecha entre la máquina más poderosa y el menos poderoso. La implicación de esto es que si tienes un juego que realmente aprovecha al máximo una PS3 (por ejemplo), de todos modos no puedes ejecutarlo en un teléfono celular barato, así que tu problema ya no es "¿cómo puedo obtener 1 programa? para trabajar en hardware muy diferente "pero se convierte en" ¿cómo puedo implementar 1 idea de juego de varias maneras diferentes para que funcione en hardware con potencia diferente?
Si bien una biblioteca como SDL proporciona una API de envoltura multiplataforma para subprocesos, creo que sería ingenuo suponer que esto conduce directamente al desarrollo fácil de juegos en plataformas muy diferentes (escritorio / móvil).
Fácil desarrollo de juegos: seguro. Multithreading óptimo, no. Pero no necesitas multihilo para hacer juegos. Para hacer unos de alto rendimiento, sin duda ayuda. Pero muchos juegos geniales se ejecutan en un solo hilo.
¿Cuál es la mejor manera de abordar el desarrollo de esta manera (dada cualquier API de subprocesamiento multiplataforma) teniendo en cuenta lo siguiente:
- diferentes números de núcleos
- capacidades de procesamiento muy diferentes por núcleo
- Una arquitectura de sistemas generalmente diferente con, p. diferentes latencias para caché, RAM y acceso de E / S
En lugar de intentar asignar sistemas a subprocesos, asigne tareas a subprocesos. Dele a cada tarea los datos que necesita para ejecutar y agrúpelas a cualquier hardware disponible. Por lo general, tendrá algún tipo de grupo de subprocesos para abstraer los diversos núcleos o procesadores, y un administrador de tareas que tiene una cola de tareas y los entrega a los diversos subprocesos cuando el subproceso indica que ha terminado la tarea anterior y está Listo para uno nuevo. El hardware con más núcleos obviamente completará las tareas más rápidamente y podrá renderizar más rápidamente. La especialización de este sistema para que funcione de manera óptima en sistemas con diferentes características se convierte en un problema de optimización avanzada, pero puede basarse en ciertas heurísticas (por ejemplo, una tarea que no funciona).
Sin embargo, la descomposición de las características del juego en tareas discretas es un asunto bastante complejo y, a menudo, no vale la pena el esfuerzo a menos que esté muy seguro de que necesita el rendimiento, por lo que la mayoría ni siquiera lo intentará.
Algunas lecturas adicionales:
http://www.gamasutra.com/view/feature/1830/multithreaded_game_engine_.php - vea la sección 'datos paralelos'. Con este modelo, los datos se dividen en varias tareas idénticas y se distribuyen en subprocesos individuales.
http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/ - bastante denso, describe cosas a nivel del sistema operativo en lugar del nivel del juego.
http://drdobbs.com/high-performance-computing/216500409 : no es específico del juego, pero es completamente relevante en términos de decirle cómo debe dividir las tareas.
http://www.itfgaming.com/news/tech-focus-crysis-2-and-the-future-of-cryengine-3 - a mitad de esta entrevista hay una anécdota sobre cómo migraron a un sistema basado en tareas .