私は HTML5 キャンバスを使用してゲーム エンジンを作成しています。画像用の「ラッパー」を作成することにしました。これにより、さまざまなタイプのアニメーション、画像などに共通のインターフェイスが得られるからです。メソッド、回転の値.picture、 などを提供するプロパティです。私にとってこのアプローチの優れている点は、本質的に、このプロパティは何でもかまいません。draw().phi.alpha.picture
Picture画像 (実際に呼び出されるラッパー)。- アニメーション (
next()やなどの機能を持つ多くの画像のラッパーgetImage())。 - コンポジション (多数の画像とアニメーションを重ねて描画するか、 draw メソッドを持つもの)
- 状態 (コンポジションと同様)
便宜上、これらすべてのラッパー (画像、アニメーション、コンポジション、状態) はコンテキストを変換して回転します (最初に回転ポイントに変換しないと、HTML5 キャンバス コンテキストを正常に回転させることはできません)。さぁ、たくさんの翻訳です！最初の問題:すべての描画呼び出しのコンテキストを変換するのは高価ですか?
もう 1 つの問題は、この設計が多くの関数呼び出しを意味することです。
プロセスは次のとおりです。
- レンダラーはシーンを反復し、次にシーンのレイヤーを反復します
- drawable (
ob.picture != undefined) に到達すると、その draw 関数を呼び出し.pictureます (すべての可視オブジェクトは、Drawable と呼ばれる「クラス」から継承されます。このクラスには、実際には位置と画像のプロパティがあります)。
最良のシナリオで何が起こるかを次に示します。
- ドローアブルの
.pictureプロパティは Picture オブジェクト (画像のラッパー) です .pictureコンテキストをその位置に変換します- は
.pictureコンテキストを回転します .picture呼び出し_context.drawImage(.picture.image, etc);
最悪のシナリオでは次のようになります。
- 画像のプロパティは合成または状態オブジェクトです
- コンポジションは、その要素の反復を開始します。各要素は、別の画像またはアニメーション (さらに悪いことに、別のコンポジション/状態) です。
- 描画メソッドを呼び出します
- それらは実際の画像をレンダリングし、要素を反復処理し、これが繰り返されます
ご覧のとおり、多くの draw 関数呼び出しがあります。これは重大な速度の問題になりますか、それとも関数の呼び出しは安価ですか?
編集：この質問は少し変更されました。「ゲーム」が「エンジン」になり、エンジンの構造が少し変わっています。しかし、あまりにも本質的または異なるものは何もありません。