我正在通过 Adob​​e AIR (3.1) 将基于 Flash Player 的游戏移植到桌面(OSX 和 Windows)。移植到 AIR 本身进行得相当顺利。我遇到的一个问题是游戏将通过 Steam 网络分发。为了与 Steam 客户端交互，我不得不编写一个 native 扩展以将 Steam SDK API 公开给 AS3。两个平台都已实现 native 扩展支持，我已根据需要启动应用程序并与 Steam 通信。

我遇到麻烦的领域是处理 Steam 的 Overlay，当它被激活时，它会呈现在游戏之上。本质上，当游戏启动时，Steam 客户端会暂停进程，以便将其覆盖库连接到 D3D 或 OpenGL。最初，Overlay 根本无法显示，因为 AIR 应用程序描述符将默认渲染模式设置为“自动”。但是，一旦我将渲染模式切换为“gpu”，叠加层就会按需要出现。

在 OSX 方面，一切都按预期工作。我可以很好地切换进出叠加层。在频谱的窗口端，我在激活覆盖时遇到了一些问题。具体来说，当启用覆盖(它在游戏之上渲染)并且我移动鼠标或生成键盘输入时，覆盖和游戏都会“卡住”(渲染停止)2-3 秒。此外，我注意到当我在游戏运行时打开任务管理器时，CPU 使用率大约为 75-80%。当我第一次激活 Overlay(这是需要的)时，CPU 使用率保持不变。但是，当我移动鼠标光标或按下键盘上的某个键时，cpu 使用率下降到大约 1%。我们测试过的 5 台 Windows 机器中有 4 台(2 台 XP，3 台 Win 7)出现了这个问题。自然地，我首先就此问题联系了 Valve，因为这仅在启用 Overlay 时才会发生。我已经上传了 OSX 和 Windows 版本供他们的开发人员调试；然而，我的联系人建议我也了解更多关于 AIRs 渲染/输入的信息。

以下是 Steam 开发人员的帖子片段，详细介绍了叠加层的工作原理:

"The requirements for the overlay on Windows are as follows:

1. Game must use D3D7, D3D8, D3D9, D3D10, D3D11, or OpenGL
2. Game must call D3D Present() or OpenGL SwapBuffers() on a fast regular basis (these calls are hooked by the overlay and give it opportunity to do work). For instance 2D games that only call these functions when mouse movement occurs or graphics on screen actually change rather than every frame will not function well.
3. Game should use standard Win32 input messages, raw Win32 input messages, or DirectInput for input and the overlay will then detect hotkeys and hide/block input events from the game when active.

It sounds like your game may violate #2 and stops calling Present/SwapBuffers sometimes when the overlay is active. This may happen if you call these functions in response to user input which is now blocked due to the overlay being activated. You should guarantee you keep pumping frames and swapping at a regular interval even if input events aren't occurring."

经过更多的督促，Valve 开发人员对我的应用程序进行了概要分析，以确定 Game Overlay 是否出现了任何特定问题。不幸的是，他们无法在 Overlay 本身中找到任何发生的事情。这几乎意味着 Windows 上的 AIR 不喜欢 Overlay 阻止 Win32 输入消息。以下是 Valve 开发人员的回复:

"I got your depots and did some testing. Nothing unusual happens in the overlay. Profiling your app with xpref while the issue occurs and taking some minidumps to check callstacks it looks like the app just blocks up completely and uses zero CPU during the time it is blocked, when it happens it calls Present() only at roughly 1 second intervals until it recovers (maybe there is a 1 second timeout somewhere in the AIR code). It's hard to get much detail since I don't have any symbols for the AIR runtime libraries.

It does however look like this is somehow related to input state and AIR being unhappy with win32 input messages stopping. If I change our overlay to not block any input at all once activated (which obviously has some pretty big problems for usability, but just for testing purposes.) then the issue does not occur. It's possible that the AIR code has some weird logic where if it's seen some specific WM_WHATVER message it's expecting another right after and blocks on it waiting somehow.

Hopefully you can work out on your side or with Adobe as to why the application behaves badly in these situations and starts blocking and not presenting at regular intervals."

我已经在 Adob​​e 论坛上发帖，但在那里没有这样的运气。主要是，我希望有人以前处理过这个问题，或者对我如何解决这个问题有想法。如有任何建议、意见或想法，我们将不胜感激!

最佳答案

事实证明，AIR 核心框架中存在一个深层错误，这是导致此问题的根本原因。 Adobe 已确认该错误，他们正在为 Cyril (AIR 3.3) 版本修复。可以在 Adob​​e AIR 错误列表中查看错误的状态 (#3089755)。

在短期内，我被迫检测 SteamOverlay 使用的 Windows 消息，并传递虚假消息以防止 AIR 锁定。我通过使用 Windows API 完成此操作 SetWindowsHookEx连同 WH_DEBUG 和 WH_GETMESSAGE Hook 。这绝对不是理想的方法，但在 Adob​​e 发布修复程序之前短期内需要这样做。

关于windows - Adobe AIR 3.1 渲染/输入问题与 Steam 覆盖 (Windows)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8838839/