現在、Adobe AIR（3.1）を介してFlash Playerベースのゲームをデスクトップ（OSXおよびWindows）に移植しています。AIR自体への移植はかなりスムーズに進んでいます。私が対処した1つの問題は、ゲームがSteamネットワークを介して配布されることです。Steamクライアントと対話するには、SteamSDKAPIをAS3に公開するためのネイティブ拡張を作成する必要がありました。ネイティブ拡張サポートは両方のプラットフォームに実装されており、必要に応じてアプリケーションを起動してSteamと通信します。
私が問題にぶつかったのは、Steamのオーバーレイを扱っていることです。これは、アクティブ化されたときにゲームのオーバートップをレンダリングします。基本的に、ゲームが起動されると、SteamクライアントはオーバーレイライブラリをD3DまたはOpenGLのいずれかに接続するためにプロセスを一時停止します。当初、AIRアプリケーション記述子のデフォルトのrendermodeが「auto」に設定されていたため、オーバーレイはまったく表示されませんでした。ただし、レンダリングモードを「gpu」に切り替えると、オーバーレイが希望どおりに表示されます。
OSX側では、すべてが期待どおりに機能します。オーバーレイのオンとオフをうまく切り替えることができます。スペクトルのウィンドウ側で、オーバーレイをアクティブにしたときに少し問題が発生しました。具体的には、オーバーレイが有効になっていて（ゲームの上にレンダリングされている）、マウスを動かすかキーボード入力を生成すると、オーバーレイとゲームの両方が2〜3秒間「フリーズ」（レンダリングが停止）します。さらに、ゲームを実行している状態でタスクマネージャーを開くと、CPU使用率が約75〜80％であることに気付きました。オーバーレイを最初にアクティブにしたときのCPU使用率は同じままです（これは望ましいことです）。ただし、マウスカーソルを移動するか、キーボードのキーを押すと、CPU使用率が約1％に低下します。この問題は、テストした5台のWindowsマシンのうち4台（2 XP、3 Win 7）で発生しました。当然、これはオーバーレイが有効になっている場合にのみ発生するため、この問題について最初にValveに連絡しました。開発者がデバッグできるように、OSXビルドとWindowsビルドの両方をアップロードしました。しかし、私の連絡先は、AIRのレンダリング/入力についても詳しく知ることを提案しました。
オーバーレイがどのように機能するかを詳しく説明したSteamDevを含む投稿のスニペットを次に示します。
「Windowsでのオーバーレイの要件は次のとおりです。
- ゲームはD3D7、D3D8、D3D9、D3D10、D3D11、またはOpenGLを使用する必要があります
- ゲームは、D3D Present（）またはOpenGL SwapBuffers（）を定期的に高速で呼び出す必要があります（これらの呼び出しはオーバーレイにフックされ、作業を行う機会を与えます）。たとえば、マウスの動きが発生したとき、またはすべてのフレームではなく画面上のグラフィックが実際に変化したときにのみこれらの関数を呼び出す2Dゲームは、うまく機能しません。
- ゲームは、標準のWin32入力メッセージ、生のWin32入力メッセージ、またはDirectInputを入力に使用する必要があります。オーバーレイは、アクティブなときにホットキーを検出し、ゲームからの入力イベントを非表示/ブロックします。
オーバーレイがアクティブな場合、ゲームが＃2に違反し、Present/SwapBuffersの呼び出しを停止することがあるようです。これは、オーバーレイがアクティブ化されているためにブロックされているユーザー入力に応答してこれらの関数を呼び出す場合に発生する可能性があります。入力イベントが発生していない場合でも、定期的にフレームのポンピングとスワッピングを継続することを保証する必要があります。」
もう少しプロデュースした後、Valve開発者は私のアプリケーションのプロファイルを作成して、ゲームオーバーレイで特定の問題が発生したかどうかを判断しました。残念ながら、オーバーレイ自体で何が起こっているのかを見つけることができませんでした。これは、Windows上のAIRが、オーバーレイがWin32入力メッセージをブロックしていることを好まないことを意味します。これがValve開発者の応答です：
「デポを取得してテストを行いました。オーバーレイで異常なことは何も起こりません。問題が発生している間、xprefを使用してアプリをプロファイリングし、ミニダンプを使用してコールスタックをチェックすると、アプリが完全にブロックされ、その間CPUを使用しないように見えます。がブロックされると、回復するまで約1秒間隔でPresent（）が呼び出されます（おそらくAIRコードのどこかに1秒のタイムアウトがあります）。 AIRランタイムライブラリ。
ただし、これは入力状態に何らかの形で関連しているように見え、AIRはwin32入力メッセージの停止に不満を持っています。一度アクティブ化すると入力をまったくブロックしないようにオーバーレイを変更した場合（これは明らかに使いやすさに関してかなり大きな問題がありますが、テスト目的のためだけです）、問題は発生しません。AIRコードに奇妙なロジックが含まれている可能性があります。特定のWM_WHATVERメッセージが表示された場合、その直後に別のメッセージが表示され、何らかの理由でブロックされます。
うまくいけば、アプリケーションがこれらの状況で正しく動作せず、ブロックを開始し、定期的に表示されない理由について、自分の側で、またはアドビと協力して解決することができます。」
私はアドビのフォーラムに投稿しましたが、そのような運はありませんでした。主に、誰かが以前にこれに対処したことがあるか、私がこの問題を回避する方法について考えていることを望んでいます。任意の提案、コメントまたは考えは大歓迎です！