Я в процессе переноса игры на основе Flash Player на рабочий стол (OSX и Windows) через Adobe AIR (3.1).Портирование на сам AIR прошло довольно гладко.Единственное, с чем я столкнулся, это то, что игра будет распространяться через сеть Steam.Чтобы взаимодействовать с клиентом Steam, мне пришлось написать собственное расширение, чтобы представить API Steam SDK для AS3.Встроенная поддержка расширений была реализована для обеих платформ, и у меня есть приложение, которое запускает и связывается со Steam по желанию.
Область, с которой я столкнулся, связана с наложением Steam, которое приводит к перегрузке игр, когдаэто активировано.По сути, когда игра запускается, клиент Steam приостанавливает процесс, чтобы подключить свою библиотеку оверлеев к D3D или OpenGL.Первоначально наложение не отображалось вообще, поскольку дескриптору приложения AIR по умолчанию был задан режим рендеринга «auto».Однако, как только я переключил режим рендеринга на «gpu», наложение появилось бы по желанию.
На стороне OSX все работает как положено.Я могу просто включить и выключить оверлей.На оконном конце спектра я столкнулся с небольшой проблемой, когда активировал Overlay.В частности, когда включен режим «Наложение» (это рендеринг поверх игры), и я либо перемещаю мышь, либо генерирую ввод с клавиатуры, и «Наложение» и игра «зависают» (рендеринг останавливается) на 2-3 секунды.Кроме того, я заметил, что когда я открываю диспетчер задач при запущенной игре, загрузка процессора составляет примерно 75-80%.Использование процессора остается прежним, когда я впервые активирую оверлей (что желательно).Однако, когда я перемещаю курсор мыши или нажимаю клавишу на клавиатуре, загрузка процессора падает примерно до 1%.Эта проблема возникла на 4 из 5 машин Windows (2 XP, 3 Win 7), на которых мы тестировали.Естественно, я впервые связался с Valve по поводу этой проблемы, так как это происходит только при включенном Overlay.Я загрузил сборки OSX и Windows для их разработчиков для отладки;однако, мой контакт предложил, чтобы я также узнал больше о рендеринге / вводе AIR.
Вот фрагмент поста с разработчиком Steam, подробно описывающий, как работает оверлей:
"Требования к оверлею в Windows следующие:
- Для игры необходимо использовать D3D7, D3D8, D3D9, D3D10, D3D11 или OpenGL
- Игра должна вызывать D3D Present () или OpenGLSwapBuffers () на быстрой регулярной основе (эти вызовы перехватываются наложением и дают ему возможность выполнять работу). Например, 2D-игры, которые вызывают эти функции, только когда движение мыши происходит или графика на экране фактически меняется, а не каждый кадр, не будетхорошо функционируют.
- Игра должна использовать стандартные входные сообщения Win32, необработанные входные сообщения Win32 или DirectInput для ввода, а наложение затем будет обнаруживать горячие клавиши и скрывать / блокировать события ввода из игры, когда они активны.
Похоже, ваша игра может нарушить # 2 и перестает вызывать Present / SwapBuffers иногда, когда наложение активно. TЭто может произойти, если вы вызовете эти функции в ответ на пользовательский ввод, который теперь заблокирован из-за активизации наложения.Вы должны гарантировать, что вы продолжаете перекачивать кадры и менять местами через регулярные промежутки времени, даже если входные события не происходят. "
После небольшого подталкивания разработчики Valve профилировали мое приложение, чтобы определить, было лиВ приложении Overlay возникла конкретная проблема. К сожалению, они не смогли найти ничего, что происходит в самом Overlay. Это в значительной степени означает, что AIR в Windows не нравится, что Overlay блокирует входные сообщения Win32. Вот ответ разработчика Valve:
"Я получил ваши склады и провел некоторое тестирование. Ничего необычного не происходит в оверлее. Профилирование вашего приложения с помощью xpref во время возникновения проблемы и выполнение нескольких мини-дампов для проверки стеков вызовов, похоже, приложение просто полностью блокируется и использует нулевой процессор во время когда он заблокирован, когда это происходит, он вызывает Present () только с интервалом примерно в 1 секунду, пока не восстановится (возможно, где-то в коде AIR есть 1-секундный тайм-аут). Трудно получить много деталей, так как у меня нет любые символы для библиотек времени выполнения AIR.
Однако похоже, что это как-то связано с состоянием ввода и тем, что AIR недоволен остановкой входных сообщений win32. Если я изменю наш оверлей, чтобы вообще не блокировать какие-либо входные данные после активации (что, очевидно, имеет некоторые довольно большие проблемы для удобства использования, но только для целей тестирования), тогда проблема не возникает. Вполне возможно, что код AIR имеет какую-то странную логику, когда, если он видит какое-то конкретное сообщение WM_WHATVER, он ожидает другое сразу после этого и блокирует его как-то.
Надеюсь, вы сможете решить на своей стороне или в Adobe, почему приложение ведет себя плохо в таких ситуациях и начинает блокировать и не показывать через регулярные промежутки времени. "
Я писал на форумах Adobe, но мне не повезло. В основном, я надеюсь, что кто-то или имел дело с этим раньше или имеет представление о том, как я мог бы обойти эту проблему. Любые предложения, комментарии или мысли будут с благодарностью!