¿Enfoques arquitectónicos para crear un menú de juego / superposición de shell en PC / Linux?

Estoy trabajando en una colección de juegos para una instalación de sobremesa digital personalizada (similar a las tablas de Microsoft Surface). Cada juego será un ejecutable individual que se ejecutará a pantalla completa. Además, debe haber un programa de superposición de menú / shell ejecutándose simultáneamente. El menú / shell permitirá a los usuarios pausar juegos, cambiar a otros juegos, verificar su historial de juegos, etc.

Algunos requisitos clave del shell:

• intercepta todas las entradas del usuario (principalmente multitáctil) primero antes de pasarlas al juego que se está ejecutando actualmente (para que, por ejemplo, pueda aparecer en un comando de "pausa");

• puede mostrarse en partes arbitrarias de la pantalla, con el juego actualmente en ejecución (pero presumiblemente en pausa) que todavía se muestra debajo, idealmente con su forma / tamaño dinámico, para permitir la creación de un efecto de cajón de entrada / salida animado sobre el juego.

Actualmente estoy buscando diferentes enfoques arquitectónicos para este problema, incluidas las superposiciones Fraps y DirectX, pero estoy seguro de que me faltan algunas formas de pensar sobre esto. ¿Cuáles son los principales enfoques que debería considerar?

(Tenga en cuenta que la tabla está siendo ejecutada actualmente por una PC con Windows, pero podría ser una caja de Linux en su lugar. Con esto no quiero decir que necesite una solución independiente del sistema operativo. Estaría contento con una solución específica de Windows. Pero Estaría dispuesto a considerar cambiar a Linux y usar una solución específica de Linux si es mucho más fácil lograr esto en Linux).

No creo que haya mucho que evaluar, de verdad. El rendimiento / capacidad de respuesta es lo primero, especialmente en una instalación de este tipo. Puede usar DirectX u OpenGL con renderizado diferido / render-to-texture (RTT).

Para hacerlo, renderice la capa subyacente del shell al búfer de cuadro predeterminado (el búfer frontal / en pantalla), renderice su superposición de juego activa a un quad del tamaño de una pantalla, cambie este quad a la posición adecuada en el espacio mundial según el estado actual del "cajón" "transición, luego renderizarlo al búfer de cuadro predeterminado también. Ahora debería tener el juego activo sobre el shell, y es una operación muy rápida y, por lo tanto, se presta a transiciones resbaladizas (dadas algunas buenas matemáticas de interpolación).

Con respecto a las interacciones, incluso puede hacer que la detección de hit bajo / superpuesta sea perfecta en píxeles si vuelve a leer los datos RTT en el lado de la CPU, por cuadro. En ese caso, necesitaría devolver al menos el búfer de superposición como un RTT de máscara barato de 1 bit.

EDITAR Otra forma es ir completamente basado en el navegador, ya que puede hacer el modo de pantalla completa. Puede cargar los juegos como módulos en lugar de tener "programas" separados. El problema con el navegador es que no obtendrá el mismo rendimiento. Aún podría usar WebGL (ya que tendría control sobre qué navegador usaría) para capas y gráficos rápidos, pero los juegos tendrían que ser simples. Además del rendimiento, podría ser un poco más fácil de desarrollar de esta manera, y aún no dependerá del sistema operativo.