新しいプロジェクトを開発するために、Cube Art Project はテスト駆動開発手法を採用しました。このアプローチでは、アプリケーションの特定の機能のテストが最初に実装され、次に特定の機能が実装されます。このアプローチの大きな利点は、機能の開発が開始される前に、実装の詳細にできるだけ関与しない最終インターフェイスの実装であると考えています。このアプローチでは、インターフェイスが特定の実装のコントラクトである場合、テストによってさらなる実装が決定され、コントラクト プログラミングの利点がすべて追加されます。
キューブアートプロジェクト –ユーザーが立方体からフィギュアを構築する 3D エディターは、少し前までは非常に人気がありました。これはグラフィカルなアプリケーションなので、スクリーンショット検証を含むテストを追加することにしました。
スクリーンショットを検証するには、OpenGL コンテキストからスクリーンショットを取得する必要があります。これは glReadPixels 関数を使用して行われます。関数の引数の説明は簡単です –開始位置、幅、高さ、形式 (RGB/RGBA/など)、出力バッファへのポインタ。SDL を使用したことがある人、または C でデータ バッファを使用した経験がある人は、必要な引数を単純に置き換えることができます。ただし、glReadPixels 出力バッファの興味深い機能について説明する必要があると思います。SDL_Surface ではすべての基本操作が上から下に行われるのに対し、ピクセルは下から上に保存されます。
つまり、png ファイルから参照スクリーンショットをロードしたのですが、2 つのバッファーの 1 つが上下逆だったため、2 つのバッファーを直接比較できませんでした。
OpenGL から出力バッファーを反転するには、Y 座標のスクリーンショットの高さを減算して出力バッファーを埋める必要がありますが、埋めるときに 1 を減算しないとバッファーの制限を超える可能性があることを考慮する価値があります。メモリ破損の原因となります。
私は常に C のようなポインタによる直接メモリ アクセスではなく、「インターフェイスによるプログラミング」という OOP パラダイムを使用しようとしているため、バッファの外にデータを書き込もうとすると、メソッドの境界検証のおかげでオブジェクトがこれを通知してくれました。 。
トップダウン スタイルでスクリーンショットを取得するメソッドの最終コード:
auto width = params->width;
auto height = params->height;
auto colorComponentsCount = 3;
GLubyte *bytes = (GLubyte *)malloc(colorComponentsCount * width * height);
glReadPixels(0, 0, width, height, GL_RGB, GL_UNSIGNED_BYTE, bytes);
auto screenshot = make_shared(width, height);
for (auto y = 0; y < height; y++) {
for (auto x = 0; x < width; x++) {
auto byteX = x * colorComponentsCount;
auto byteIndex = byteX + (y * (width * colorComponentsCount));
auto redColorByte = bytes[byteIndex];
auto greenColorByte = bytes[byteIndex + 1];
auto blueColorByte = bytes[byteIndex + 2];
auto color = make_shared(redColorByte, greenColorByte, blueColorByte, 255);
screenshot->setColorAtXY(color, x, height - y - 1);
}
}
free(bytes);
ソース
https://community.khronos.org/ t/glreadpixels-fliped-image/26561
https://stackoverflow.com/questions/8346115/why-are-bmps-stored-upside-down
ソースコード
https://gitlab.com/demensdeum/cube-アートプロジェクトブートストラップ
