特記事項: GamePad APIは、FirefoxとGoogleChromeによって2つのまったく異なる方法で処理されます。このため、ブラウザのIDをテストするためのコードを含め、それに応じてケースを処理する必要があります。
navigator.getGamePads()メソッドが呼び出されると、オブジェクトの配列が返され、それらのオブジェクトには、ゲームパッド/ジョイスティックのID、およびその軸/ボタンの状態に関する情報が含まれます。
問題は次のとおりです。Firefoxでは、メソッドは配列を呼び出し元のコードに渡します。その後、その配列を繰り返し調べて、独自のコードの軸/ボタンの状態の変化を探すことができます。Firefoxは期待どおりに動作し、受け取ったオブジェクトを新しい軸/ボタンデータで更新します。
一方、Google Chromeは、配列をまったく異なる方法で処理します。Chromeは、配列をゲームパッド/ジョイスティックのステータスの1回限りのスナップショットとして扱います。新しいデータをフェッチする場合は、navigator.getGamePads()をもう一度呼び出して、新しいスナップショットをフェッチし、古いスナップショットを破棄する必要があります。 1。
結果として、両方のブラウザーでコードを機能させるには、このようなものが必要です(変数'gp'が、navigator.getGamePads()の最初の呼び出しからの戻り値を以前に格納した変数であると仮定します...)
var ua = navigator.userAgent;
if (ua.toLowerCase().indexOf("chrome") != -1)
gp = navigator.getGamePads();
2つのブラウザーの動作がこれほど異なる理由は、別のスレッドのトピックですが、GamePad APIはまだ実験的であり、それに適用される標準の詳細はまだ確定されていないという事実と関係があると思います。
私の場合、Windows 7 64ビットでChromeを実行します(ただし、32ビットバージョンは、この方法でインストールしたコンピューターの製造元に最もよく知られている奇妙な理由で)、navigator.getGamePads()によって返される配列には現在含まれています私のコンピュータに接続されている実際のゲームパッド/ジョイスティックと同じ数のエントリのみ。LinuxのChromeで何か違うことが起こっている場合は、配列にnull値があるかどうかをテストして、これも考慮する必要があります。
考慮すべきもう1つの要素は、ゲームパッド/ジョイスティックを選択するときに、標準ではGamePadオブジェクトのインデックスプロパティが参照され、その後配列にインデックスを付けるために使用されることです。この理由については、このドキュメントで詳しく説明しています。
W3Cページ:GamePadインターフェースの編集者ドラフト
ただし、これの実装は上記のGoogle Chromeの化身で説明されているように機能しますが、バージョンを実験的にチェックして、私のバージョンと同じように動作するかどうかを確認する必要があります。そうでない場合は、標準が完成するまでコードを適宜調整し、最新のすべてのブラウザーとそのすべてのOSの化身に適切な準拠が適用されます。
したがって、操作する特定のゲームパッド/ジョイスティックを選択すると、コードは次のようになります(インデックスセレクターとして変数「gid」を使用)。
var gLen = this.gamePads.length;
done = false;
idx = 0;
while (!done)
{
if (this.gamePads[idx] !== null)
{
if (gid == this.gamePads[idx].index)
{
//Here, choose this GamePad as the selected GamePad, based upon the index number as per the W3C recommendation ...
selectedGamePadIndex = gid;
selectedGamePad = this.gamePads[idx];
done = true;
//End if
}
//End if
}
//Update counter in case we haven't selected one of the available GamePads above ...
idx++;
if (idx >= gLen)
done = true; //Exit loop altogether if we've exhausted the list of available GamePads
//End while
}
私は実際に上記のコードを(最後にいくつかの整理を加えて)カスタムオブジェクトのメソッドとして実装しましたが、実装の細部に関係なく、原則は同じです。(この時点で、このようなタスクを処理するために独自の短いライブラリを作成する習慣があることを告白します!)
注意すべきもう1つの問題は、ゲームパッドAPIがゲームパッド/ジョイスティックの物理データソースをゲームパッドオブジェクトの軸/ボタン要素にマッピングする方法と、そこに含まれる値です。私はMicrosoftSidewinderPro USBジョイスティックを持っていますが、コンピューター上のこのデバイスのマッピングは非常に奇妙です。
- 軸0/1:ジョイスティックハンドル(予想どおり)
- 軸2/3:割り当てられていません
- 軸4/5:4つは割り当てられておらず、5つはツイストグリップに割り当てられています
- 軸6/7:6はラウンドスライダーに割り当てられ、7は割り当てられていません
- 軸8/9:8が割り当てられておらず、9がハットスイッチに割り当てられています(えー、何ですか?)
はい、そうです。アナログ軸9がハットスイッチに割り当てられており、非常に奇妙な値が返されます。
- 中央に配置されたハットスイッチ:+1.2
- ハットスイッチアップ:-1.0
- ハットスイッチダウン:+0.1
- 左ハットスイッチ:+0.7
- ハットスイッチ右:-0.42
このような癖は、GamePadAPIを試すときに注意する必要があるものです。さらに悪いことに、いわゆる「標準」ゲームパッド(上記のリンク先のドキュメントで定義)は、一部のブラウザーでは標準として報告されますが、他のブラウザーでは報告されない場合があります。さらに悪いことに、WindowsのブラウザーXでは標準として報告されますが、 Linuxの同じブラウザX!これは、ブランブルの茂みに相当するこのソフトウェアを介して戦い、途中でいくつかのとげにひどく引っかかれることで、多くの髪を引き裂く欲求不満を引き起こしますが、少なくともブラウザ開発者が働いているという事実に安心することができますこれを改善しようとしますが、他のことが優先されるため、時間がかかります(たとえば、ブラウザがランサムウェアの乗っ取りの標的になりにくいことを確認するなど、それが起こった場合は非常に)。