問題タブ [double-buffering]

ちらつきが止まらない。dubbel-buffering を追加するようアドバイスを受けました。それ、どうやったら出来るの？

Java で初めてのアプレット ゲームを作成し、いくつかのチュートリアルを読み、ダブル バッファリングのさまざまな解決策を見つけました。それらの違い、長所と短所などを知りたいです。よろしくお願いします！

最初の1つ：

二つ目：

ゲームに使用するスプライトを継続的に描画、消去、再描画しながらちらつきを防ぐ方法について、Google で何時間も検索しました。私が目にするサイトの多くは、方法を説明することなく、ダブル バッファを使用するように指示しています。--- masm32 アセンブリでダブル バッファを実装する方法を誰か教えてもらえますか? あなたの答えは大歓迎です！

編集：ところで、私はint 10h、ah = 13hを使用しています

SurfaceView現在、個人用およびダブル バッファリングを使用して、Android アプリを開発しています。ただし、コードで少し問題に直面しています。一方で、階層
に基づく xml ビューがあります。アクティビティをインスタンス化するとき、この xml にLinearLayoutmy を設定します。contentView問題は、ダブルバッファリングが機能しなくなったことです。スレッドは実行中ですが、何も表示されません。
一方、contentView新しい個人的なSurfaveView要素を設定すると、ディスプレイは正常に動作します。しかしもちろん、 my の他の要素にはもうアクセスできませんLinearLayout。

実際、私はcontentView自分の xml ビューを設定し、ディスプレイを機能させ続けたいと思っています。

私は十分に明確だったと思います、あなたの答えをありがとう！

ここに私の活動があります：

私の表面ビュー:

そして私のxmlビュー：

編集：
さらなる調査と分析の後、次のことが明らかになりました。

• setContentView(R.layout.main_controller_activity): この場合、アクティビティからすべての要素を取得しますが、MCustomDrawableView何も表示されません。
• setContentView(new MCustomDrawableView(getApplicationContext()))：その場合、MCustomDrawableViewうまく機能しています（必要なものが表示されます）が、他のものはありませViewんmain_controller_activity

両方の場合において：

• 私のスレッドは実行されており、うまく機能しています。
• holder.lockCanvas()およびメソッドを使用して、私の描画関数も呼び出されholder.unlockCanvasAndPost(bufferCanvas)ます。

コンソールでダブルバッファリングを使用しようとしています。私はこのコードを書き、コンパイルしますが、作成されたコンソールでは、最下部の行がランダムな文字で埋められています。に変更CHAR_INFO cur[Width*Height]; すると CHAR_INFO cur[Width*Height+200];役立ちますが、幅*高さのメモリでは不十分な理由がわかりません。

問題は、chiBuffer に対応する一部のメモリが予約されていないことが原因だと思いますが、その理由はわかりません。それで、問題は何ですか？

HWSURFACE|DOUBLEBUF|RESIZABLEを使用してウィンドウのサイズを変更することをオンラインで見ました。

動作しますが、HWSURFACEとDOUBLEBUFが実際に何をするのかわかりません。

ハードウェア サーフェスとダブル バッファの略であることは知っていますが、それらが実際に何に役立つのかはわかりません。

私はマルチスレッドの学習を開始し、共有リソースを介してスレッドを同期するための未来と約束に出会いました。そこで、Futures と Promises (単一の生産者と単一の消費者) を使用して、有名なダブル バッファリングの問題を実装することを考えました。私が考えた基本的な方法論は次のとおりです。

プロデューサー スレッド:

ConsumerThread :

コードは次のとおりです。

このコードを実行すると、彼の巨大な問題に出くわしましたが、私はまったく気づいていません

このエラーについてググったところ、リンクとコンパイル時に -lpthread スイッチをリンクすることをお勧めします。しかし、問題を解決できませんでした。

私を助けてください、どこが間違っているのですか..

画面イメージが静的であることが多い OpenGL アプリに取り組んでいます。この状況を処理するには、次の 3 つの方法が考えられます。

1. とにかく画面全体を何度もレンダリングし続けるだけです
2. 変更がある場合にのみレンダリング ループを呼び出すように OpenGL に指示する
3. 画像が変更されたときにのみ再描画し、それ以外の場合はすぐにレンダリング ループを終了します。

明らかに、オプション 1 は処理能力 (つまり、モバイル デバイスのバッテリー充電) の膨大な浪費であり、オプション 2 が最適なソリューションです。

ただし、オプション 2 とオプション 3 の消費電力の違いはおそらくごくわずかです (間違っていたら訂正してください)。これは、レンダー ループへの不要な呼び出しと関連するセットアップ オーバーヘッドが小さいためです。私のマルチスレッド レンダリング パイプラインでは、オプション 3 の方がオプション 2 よりもはるかに簡単に実装できることがわかりました。

一度静止画像をレンダリングして試してみたところ、画面がその画像と黒の間で狂ったようにちらつき始めました。私の推測では、これは二重 (または三重?) バッファリングが原因であると考えられます: 私の画像はバッファの 1 つにのみ描画されますが、render-loop を呼び出すたびにバッファが反転されるため、画像は最終的にその 1 つのバッファーがたまたまアクティブなバッファーである場合にのみ画面を表示します。

簡単な解決策: 静的イメージをすべてのバッファーに 1 回描画してから、すぐにレンダリング ループを終了します。

このためには、バッファの数、つまり画像を描画する必要がある回数を知る必要があります。この番号を照会する方法はありますか? または、レンダー ループが NO-OP になった場合、バッファの切り替えを何らかの方法で防ぐことはできますか?

最大限のデバイス サポートのために、このコードの OpenGL ES 1.0 および OpenGL ES 2.0 バージョンを構築しています。