Архитектурные подходы к созданию игрового меню / оболочки на ПК / Linux?

Я работаю над коллекцией игр для индивидуальной настольной цифровой установки (аналогично таблицам Microsoft Surface). Каждая игра будет отдельным исполняемым файлом, который работает в полноэкранном режиме. Кроме того, одновременно должна быть запущена программа наложения меню / оболочки. Меню / оболочка позволит пользователям приостанавливать игры, переключаться на другие игры, проверять их историю игр и т. Д.

Некоторые ключевые требования оболочки:

• он перехватывает весь пользовательский ввод (в основном мультитач) перед передачей его текущей запущенной игре (так что он может знать, например, всплывающую команду «пауза»);

• может отображаться на произвольных участках экрана, при этом текущая (но, по-видимому, приостановленная) игра по-прежнему отображается снизу, в идеале с динамической формой / размером, что позволяет создать анимированный эффект выдвижного ящика в игре.

В настоящее время я изучаю различные архитектурные подходы к этой проблеме, включая наложения Fraps и DirectX, но я уверен, что мне не хватает некоторых способов обдумать это. Какие основные подходы я должен рассмотреть?

(Обратите внимание, что таблица в настоящее время работает на ПК с Windows, но потенциально она может представлять собой Linux-систему. Под этим я не подразумеваю, что мне нужно решение, не зависящее от ОС. Я был бы доволен решением для Windows. Я хотел бы рассмотреть вопрос о переходе на Linux и использовании решения, ориентированного на Linux, если это будет намного проще сделать в Linux.)

Я не думаю, что есть что оценивать, правда. Производительность / отзывчивость на первом месте, особенно при установке такого рода. Вы можете использовать DirectX или OpenGL отложенный рендеринг / рендеринг в текстуру (RTT).

Для этого визуализируем подкладку оболочки в буфер кадров по умолчанию (передний / экранный буфер), визуализируем наложение вашей активной игры в квадратор размером с экран, перемещаем этот квад в соответствующую позицию в мировом пространстве в соответствии с текущим статусом «выдвижного ящика». msgstr "переходите, а затем визуализируйте его в буфер кадра по умолчанию. Теперь у вас должна быть активная игра, наложенная поверх оболочки, и это очень быстрая операция, и, следовательно, она поддается плавным переходам (учитывая некоторую математическую интерполяцию).

Взаимодействия, вы даже можете сделать пиксельное обнаружение попадания под / оверлей идеальным, если вы будете считывать данные RTT на стороне ЦП для каждого кадра. В этом случае вам нужно будет вернуть хотя бы оверлейный буфер как дешевый RTT с 1-битной маской.

РЕДАКТИРОВАТЬ Другой способ - полностью использовать браузер, так как вы можете использовать полноэкранный режим. Вы можете загружать игры как модули, а не иметь отдельные «программы». Проблема с браузером в том, что вы не получите ту же производительность. Вы все еще могли бы использовать WebGL (так как у вас был бы контроль над тем, какой браузер вы бы использовали) для многоуровневой и быстрой графики, но игры должны были быть простыми. Помимо производительности, этот способ может быть немного проще для разработки, но все еще не зависит от ОС.