ここで詳しく説明する理由により 、ビットマップを使用してクワッドをテクスチャリングする必要があります (8 ビットのピックスマップではなく、1 ピクセルあたり 1 ビットのように)。
現在、デバイス上のバッファにビットマップが保存されており、次のようにマウントしています。
glBindBuffer(GL_PIXEL_UNPACK_BUFFER, BFR.G[(T+1)%2]);
glTexImage2D(GL_TEXTURE_2D, 0, GL_RGB, W, H, 0, GL_COLOR_INDEX, GL_BITMAP, 0);
OpenGL 仕様では、glTexImage2D について次のように述べ られています。
仕様から判断すると、バッファ内の各ビットは 1 つのピクセルに対応するはずです。ただし、次の実験では、何らかの理由で宣伝どおりに機能しないことが示されています。
1) テクスチャをビルドするとき、32 ビット チャンクでバッファに書き込みます。仕様の文言から、各値に 0x00000001 を書き込むと、幅 1 ピクセルの垂直バーとそれらの間に 31 幅のスペースがあるテクスチャになると想定するのが合理的です。ただし、空白に表示されます。
2) 次に、0x000000FF を書き込みます。ビットマップ モードの理解に明らかに欠陥があるため、24 幅のスペースを持つ 8 幅のバーが生成されるはずです。代わりに、幅 1 ピクセルの白いバーが生成されます。
3) 0x55555555 = 1010101010101010101010101010101 したがって、この値を書き込むと、1 ピクセル間隔で 1 幅の縦縞が作成されます。ただし、しっかりした灰色になります。
4) 元の 8 ビット ピックスマップを GL_BITMAP モードで使用すると、正しいアニメーションが生成されます。
GL_BITMAP モードであっても、仕様が示唆しているように見えるにもかかわらず、テクスチャラーは依然として 8 ビットを 1 つの要素として解釈しているという結論に達しました。灰色を生成できるという事実 (ツートーンで作業していると思っていたのに) と、元の 8 ビット ピックスマップが正しい画像を生成するという事実は、この結論を裏付けています。
質問:
1) 仕様で示唆されているように、各バイトを 8 要素として扱うようにテクスチャラーに通知する何らかの前提条件の呼び出し (おそらく、ストライドの長さまたはパックの配置などを設定するため) がありませんか?
2) それとも、最新のハードウェアがサポートしていないために機能しないのでしょうか? (GL_BITMAP モードが 3.3 で非推奨になったことを読みましたが、3.0 コンテキストを強制しています。)
3) シェーダーを使用してビットマップをピックスマップにアンパックしたほうがよいですか? これは私が望んでいたよりもはるかに回り道的な解決策ですが、無料の昼食などというものはないと思います。