私はコンピューターゲーム（ゲーム用）について学ぶ初心者です。これまでのところ、私が出会った唯一の方法は、各フレームを描画し、すべてのフレームを更新することです。そのため、すべてのフレームの開始時に、フレーム全体が消去され、そのフレームに必要なものが再描画されます。

私の質問は、この方法がアニメーションやゲームの作成に使用される唯一の方法であるかどうかです。少し効率が悪いようです。また、この方法が3Dゲームでどのように機能するのかもよくわかりません。誰かがこれをより詳細に説明してもらえますか？

非常に古いゲームでは、フレーム上で変更されたフレームの一部のみを再描画する手法が使用されていました。私が覚えているのは、「リトルビッグアドベンチャー」というゲームがこのテクニックを使用していることです（1994）。しかし、ほとんどの場合、ゲームには静止カメラがあることがわかります。可視領域から出たときにのみ、シーンが再描画されます。ゲームをプレイすると、そのフレームにわずかな遅れがあることに気付くでしょう。最新のゲームエンジンを備えた最新のGPUでは、状況は変化しています。すべてが各フレームに再描画されます。レンダリング手法によっては、物事が数回レンダリングされることさえあります。GPUの計算能力は、正しく使用すると非常に高くなります。しかし、再利用が行われています。たとえば、エンジンは、5番目のフレームごとにのみシャドウマップを更新することを決定できます。または、光源に変更がない限り、照明は更新されません。

番号。

少なくとも、ベクトル表示を使用していた70年代の古いゲームを含める場合。

たとえば、広く知られているゲームAsteroidsは、もともとはグラフィックを画面にレンダリングする根本的に異なる方法であるベクターディスプレイ用に開発されました。

ベクトルモニターは、1970年代後半から1980年代半ばのアーステロイドゲーム（アステロイド、テンペスト、スターウォーズなど）でも使用されていました。アタリは、Quadrascanという用語をビデオゲームアーケードで使用したときの技術を説明するために使用しました。

https://en.wikipedia.org/wiki/Vector_monitor

現代のグラフィックスは、ラスタライズ用にほぼ100％作成されており、定義により、グラフィックスバッファの内容がフレームごとにディスプレイに書き込まれます。

最下位レベルでは、マシンのグラフィックプロセッサが実際に各フレームを一から計算し、画面に送信します。ただし、この低レベルのものを自分で管理する場合にのみ、これにさらされます[1]ただし、グラフィック（およびゲーム）エンジンがこれらを処理し、シーンを自由に表現できます。フレーム間で変更できるが、永続的である多くのエンティティの点で。

...この方法が3Dゲームでどのように機能するか...

3D空間の要素は永続的であり、グラフィックエンジンは、発生した変更（カメラの動きなど）について画面上の画像を再計算します。

[1] ...たとえば、OpenGLのようなもので独自のエンジン[2]を作成する場合。その場合でも、フレーム間で永続的なものを保存する可能性があります。

[2]これは現在のスキルレベルではオプションではありません。

短い答え：いいえ。

長い話：

学校でゲームプログラミングを学んだとき、次のことをするように教えられました。

ゲームで必要なfpsレートを決定します（たとえば30）。

各間隔のカウンターに1を追加するコードを記述します（30 fpsで33ミリ秒）。このコードは、ゲームループと同時に実行されます。

次に、ゲームの計算（ゲーム状態の更新）を行うゲームループは、フレームごとに同じカウンターを1減らします。ただし、グラフィック計算と画面への描画は、カウンターがゼロの場合にのみ実行されます。

その結果、グラフィックフレームレートは、CPUがゲームの計算をどれだけうまく処理できるかに応じて調整されます。ゲームであまり起きていない場合、計算は簡単で、グラフィックフレームレートは実際のゲーム状態の更新よりも高くなります（基本的に、同じゲーム状態を画面に複数回描画するため、サイクルが無駄になります）。

しかし、その後、ゲームで多くのことが行われ、CPUの処理が増え、画面への描画よりもゲームの状態の更新が優先されます。

ほとんどの場合、ゲームは意図した速度で更新され続けますが、画面に各更新が表示されないため、「遅延」しているように見えます。これは、画面に各更新を強制的に描画するため、ゲーム全体がスローダウンするよりも好ましい場合があります。

これはすべてC ++で行われ、ゲームエンジンもグラフィックカードもありません。すべてが単一のコアCPUで実行されました。2Dグラフィックスにはいくつかのライブラリを使用しました。

ビデオゲームがフレームごとにディスプレイを「描画」するかどうかを判断する前に、まず「描画」の意味を定義する必要があります。確かに、多くのビデオゲームでは、ビットマップをゼロから組み立ててすべてのフレームを描画するわけではありません。実際、多くのゲームプラットフォームは、完全なビットマップをまったく組み立てません。

ビデオゲームがディスプレイを生成するために使用できる方法はいくつかあります。非常に小さな数では、CPUが電子ビームをオンまたはオフにしたり、ピクセルごとにオンにしたり、ベクトルスキャンゲームの場合は、プロットするすべてのドットのXY座標を設定します。これを行うほとんどのゲームは、CPUが十分に高速であることを実証するために、主にそうします。より一般的なゲームには、CPUの関与がない場合、ピクセルまたはベクターのパターンをディスプレイに繰り返し出力するハードウェアがあります。このパターンは、メモリの領域からデータを連続して読み取り、各ビットまたはビットのグループをピクセルカラーとして解釈することで生成できます（これはビットマップディスプレイと呼ばれます）。場合によっては、ハードウェアは8x8、16x16、またはディスプレイの他のサイズの領域を使用し、そのバイトを使用してピクセルデータを読み込むメモリの範囲を選択します（これは多くの場合、文字マップディスプレイと呼ばれます）。一部のハードウェアプラットフォームは、構成可能な位置で複数のビットマップディスプレイをオーバーレイできます。これらはスプライトと呼ばれます。

一部のプラットフォームでは、画面に送信されている間は表示パターンを変更できませんが、代わりに、ビームが1つのフレームの描画を完了した後、次のフレームの描画を開始する前にすべての更新を行う必要があります。そのようなプラットフォームでは、フレームに表示されるすべてのものは、そのフレームの開始前にディスプレイハードウェアにロードする必要があり、ディスプレイは一度に設定できるパターンの表示に制限されます。フレームの表示中にCPUの実行が停止すると、同じフレームが無期限に表示され続けます。他のプラットフォームでは、画面に描画されている間にパターンを変更または再構成できます。これにより、ビデオ回路自体が処理できるよりもはるかに複雑な画面を表示できます。

ほとんどのパーソナルコンピューターゲームは、単一のビットマップ画面を描画するように構成されたハードウェアを使用し、その画面に既に存在するものとは異なる必要があるものをすべて描画します。特定のケースで実際に必要かどうかを考慮せずに物事を描く方が簡単な場合もありますが、画面の一部を変更する理由がないことがコードで簡単にわかる場合は、その部分をスキップすることでパフォーマンスが向上する場合があります。今日のプラットフォームは、フレームの過程で画面全体を何度も描画できるほど十分に速いことがよくありますが、歴史的にはそうではありませんでした。たとえば、Apple IIコンピューターの高解像度画面にすべてのピクセルを書き込むための最速のコードは2つ以上のフレームを必要とし、Apple IIコンピューターのすべてのピクセルをコピーするための最速のコード ■別のバッファからの高解像度画面では、その2倍の時間がかかります。良いパフォーマンスを得るには、ゲームが実際に変化しているものだけを更新する必要があり、それが良いゲームが一般的にしたことです。

簡単に言うと、すべてのフレームが描かれているわけではなく、ゲームやゲームプレイのストーリーやテーマを提示するのに必要なフレームだけが描かれていると思います。さらに、特定のインスタンスで発生させたいことのタイミングが重要になります。