Se me ha encomendado la tarea de crear una demostración de "pantalla completa" en tiempo real para ejecutar en una matriz de 5x2 de televisores LED de más de 60 pulgadas: o, en otras palabras, una pantalla de 20 megapíxeles.
Tenemos una máquina construida que puede ejecutar un solo escritorio Win7 distribuido en las pantallas a resolución completa, y algunas tarjetas de video bastante decentes.
Mi pregunta es: aparte de la cantidad ridícula de trabajo que van a hacer mis sombreadores de píxeles, ¿hay alguna otra limitación de DX10. * Que entraría en juego aquí que no lo haría en una ventana gráfica de tamaño más sensato? No tendré acceso al hardware hasta la próxima semana, pero me gustaría tener algo escrito para entonces que pueda usar para comparar el sistema.
Actualizar
Si bien logré hacer que esto funcione en una sola máquina con un montón de tarjetas AMD EyeFinity (6 salidas), para que todo funcione sin problemas, la forma "más fácil" resultó ser crear una ventana DX por pantalla, ya que tiene una ventana de visualización causó algunos problemas de rendimiento: también lo hice funcionar bastante bien al distribuir la tarea en un grupo de máquinas, cada una de las cuales maneja dos pantallas.
Fue sorprendentemente fácil. Para mi aplicación XNA de prueba, agregué un GameComponent que captura algún estado del juego (posición / orientación de la cámara, etc.) y UDP lo envía a través de la subred local por cuadro.
Ese componente tiene un Mode
interruptor (enviar o recibir). Si está en Receive
modo, captura datagramas UDP y actualiza el estado del juego con la información del remitente. Send
el modo solo envía paquetes de estado y, a través de un servicio / demonio, hace que los nodos inicien o detengan la aplicación cliente. Cualquier cliente puede actuar como un "maestro", y cambiar un cliente a Send
modo solicita que todos los demás nodos se conecten Receive
. Es bastante entretenido ver lo que sucede cuando las personas luchan por el control.
Otro beneficio interesante: creé una aplicación de consola que procesa una serie de definiciones de estado de fotogramas clave (ubicación, hora, etc.) interpola según sea necesario y las envía usando el mismo código que se usa en el motor del juego. Esto me permite mover fácilmente el script, enviar transformaciones desde un navegador web, etc.
En general, se necesitaron unas 50 líneas de código para mantener sincronizadas varias copias de la aplicación. Parte de la complejidad adicional provino de desactivar la posición de la cámara para cada máquina y corregir algunas molestias de perspectiva / proyección, pero la mayor parte se redujo a un archivo de configuración por nodo.