1

フレームの更新時にレンダリング計算を行い、一定の時間間隔で物理計算を行うのが一般的な方法です。Ashでこれを行う方法がわかりません。私が見たゲーム オブジェクトの例はすべて、ティックごとITickProviderに呼び出す 1 つ (FixedTickProvider または FrameTickProvider の可能性があります) を使用するだけengine.update()です。たとえば、レンダリング システムを 60 fps で更新したいが、ラグがある場合に備えて一定の時間間隔でゲーム ロジックを更新したい場合はどうすればよいでしょうか?

tickProvider = new FrameTickProvider( container );
tickProvider.add( engine.update );
tickProvider.start();

いくつかのアイデア...

  • システムのグループを個別に更新できますか?
  • エンジンは2つ使うべき？
4

1 に答える 1

0

ash フレームワークに関する特定の考慮事項を入力しなくても、物理エンジンとグラフィック エンジンの更新を処理する方法は多数ありますが、使用しているフレームワークに必ずしも依存するわけではありません。まず第一に、十分なハードウェア要件を持つデバイスのみを対象とする AIR モバイル アプリを作成しない限り、安定した 60fps フレームレート (または任意の安定したフレームレート) を想定することはできません。これにより、いくつかのオプションが残ります。

  • 物理エンジンを固定のデルタ t で更新します。この場合、欠落したフレームがあるとゲームの物理が遅くなります。良くない

  • 最後のフレーム間の実際のデルタ t を測定し、それに応じて物理エンジンを更新して、前のフレームの遅延を補正します。ほとんどの場合、これで十分です。

  • 何らかの理由で物理エンジンが固定増分を必要とする場合 (たとえばupdatePhysic(1/30); 、 とはあまりにも異なる結果を返すupdatePhysic(1/60); updatePhysic(1/60);場合、またはリプレイの計算やネットワーク化されたクライアントの物理同期を維持するなど、完全にフレームレートに依存しない再現可能な物理が必要な場合) に置き換えますupdatePhysic(dT);( for(var i:int = 0; i< dT * 60; ++i) updatePhysic(1/60); デルタ t がそうでない場合)常に 1/60 の倍数の実装であり、次の更新のために分割の残りを蓄積する必要があります)

  • 最適なパフォーマンスとマルチコア CPU の最適な使用が必要な場合は、別のワーカーで物理エンジンを更新することを検討できますが、Flash Player のサポート、デバッグ ツール、およびワーカー間のデータ共有はまだ実験段階です!

いずれにせよ、私はポイントがわかりません

レンダリング システムを 60 fps で更新したいのですが、遅延がある場合に備えて一定の時間間隔でゲーム ロジックを更新しますか?

「ラグ」がある場合は、表示が 60 fps で更新されないことを意味し、たとえそうであったとしても (別のワーカーで物理演算を実行した場合)、同じフレームが再び表示されるためです。

要約すると、物理エンジンをグラフィック エンジンより「速く」実行する必要があるかもしれませんが、その逆はありません。

また、actionscript では、実際のフレームレートよりも速くティックをトリガーすることはできません。Timer、setTimeout、setInterval... への呼び出しは、せいぜいディスプレイと同期されますが、決して速くはなりません。これが、物理エンジンを呼び出す必要がある理由です。たとえば、ティックを60 fpsに設定するだけでなく、メインループ内で手動で数回

于 2014-03-19T14:38:55.117 に答える