星一:こんにちは、Ebitengine作者です。Ebitengineのパフォーマンスのために、自分は次のような点に注意しています。 ドローコールを減らす 描画は、基本的にGPUに命令を送ることで行われます。この命令をドローコールと呼びます。ドローコールの数はパフォーマンスに重大な影響を与えるので、極力この数を減らすようにします。EbitengineはユーザーにとってわかりやすいAPIを提供する一方、これをそのままドローコールに直訳してしまうと、ドローコールが膨大になってしまいます。そのため、描画をまとめて一つの命令にする「バッチング」という処理を行います。 たとえば、隣接する画像描画命令が程度似通っていれば一つの命令にまとめることができます。一つの条件としては、描画元と描画先のテクスチャ (GPU が取り扱う画像) が同じである必要があります。そのため複数のEbitengine画像をまとめて一つのテクスチャにすると命令がまとまりやすくなります。ちなみに、一般的にはこれは「テクスチャアトラス」と呼ばれます。ゲームプログラミングではよくあるテクニックです。Ebitengineはこのテクスチャアトラスを内部的に自動的に作成しています。 EbitengineはAPIとしてはテクスチャアトラスの概念を露出していません。ebiten.Imageオブジェクトはあくまでピクセルの集まりである矩形であり、ユーザーにとってはこれがどうテクスチャに乗っているかどうかを気にする必要はありません。テクスチャアトラスというのはあくまで実装都合による最適化手段にすぎず、ユーザーがなるべく気にするべきではない、というのが Ebitengine のポリシーです。残念ながらこれは100%ではなく、たとえばカスタムシェーダーを使う場合はどうしてもテクスチャアトラスを意識する必要があります。ちなみに、どうしても下回りを自力で最適化したいひとには、自動テクスチャアトラスを無効にして自前で管理するモード (Unmanaged) もあります。 プロファイルを取る プロファイルを取ってそこから重い処理をなんとかしていくのはパフォーマンス最適化の常套手段です。Ebitengineはあまりマイクロベンチにはこだわらず、exampleや実際のゲームを元にプロファイルをとって最適化してます。Goだとgo tool pprofが使えます。またWasmにコンパイルしてブラウザの開発者ツールを使うという方法もあります。実のところ、ブラウザの開発者ツールを使うのが一番お手軽だったりします。 あんまりやりすぎない Ebitengineは2Dゲームエンジンを謳っています。2Dゲームに必要なパフォーマンスというのは3Dに比べると一般的にそこまで高くありません。実用上に支障をきたすのでない限り、あまりEbitengineのパフォーマンス最適化にこだわっていません。むしろパフォーマンスに対して厳密にケアすることは、早すぎる最適化になってしまい、進化を妨げる可能性があります。 もちろん、Discordなどのコミュニティ報告されるパフォーマンスの問題については、毎回調査を行っています。多くのケースではEbitengineの使い方の問題 (NewImageを毎Update呼んでしまっている、など) であって、Ebitengineそのものの問題ではありません。ただ、少ないケースですがEbitengineの問題であることがあり、その場合は直すことを検討します。