ラスタライザ改めレンダラーフレームワーク進捗。

アルファブレンディングの処理を一部直した。

計算式から言うとこれは加算なのでは？と思ったので、関数名は変更予定。

ついでにExtraバッファからの描画も加算描画に対応させた。

https://x.com/__machia__/status/2025815398449627506?s=20

これだと一度描画した領域をずっと使い回せるので楽ではある。

これをもっと拡張して縦スクロールの画像に使うという手はありそうだが、そうなると何枚か持たせたほうがいいのか。

実質的なグラフィック領域として使うこともできそうだな。

ビットシフトに関連する計算を間違えていたので修正した。

あくまで0x1Fとかで抜き出さないとダメみたいなので、そこだけ注意。

自分がビット演算に関する知識がだいぶなかったのがあかんかったな。

これなら軽く作るだけであればスクリプトで画面を作れるようにする手はありそう。

実際Update関数はそれほど凝った作りにしていなくて、これをスクリプトにするというだけなので。

レイトレーシングを描画していたら何故かGDI描画だけがFPSが遅くなる影響あったので、レースコンディションが発生してるのか確認するため排他制御をかけて処理してみた。結論から言うとまったく関係なかった。

ソースコード・コンパイラ・IDEについては同じものを利用しているため、あとは最終的な描画方法に起因する速度の違いかなと考えた。そうなると残念だがレイトレについてはGDIだと遅いよ、というほかない・・・

ちなみにもう1個スレッド立ててDraw関数をぶん回してみたところ、ティアリングに近い挙動が発生したのでこれは無理だと思った。

具体的にはメイン・ウィンドウ・Draw関数スレッドを立てたけど、ウィンドウの更新が中途半端になる等これは無理だと結論づけるレベルだった。

GDI描画の場合、Draw関数（実際に仮想スクリーンに描画する関数）→BitBltを1スレッドで行っているため、ここで他ライブラリよりCPU負荷が大きいのが原因かな？と結論付けた。

画像の切り取り処理がうまく動いてくれなかったので確認してた。

データの抽出の仕方がうまくなかったことが原因だった。

相対座標だけで対応しようとしてたけど、データの長さはデータ自体の幅と高さを参照しないとそりゃあうまくない。

これだけで1時間くらいかかった気がする。