レコードと少しだけ整理

進捗報告

  • アセットをdata.scmに名前変更、データ構造をレコードに修正
  • testコード用のサブディレクトリを追加
  • 相変わらず描画システムのAPIに悩み中・・・

テスト

開発していくなかでテストは必要だと思いますので、
テスト用のサブディレクトリを追加しました。
テストユーティリティを何使うか決めてないので、
まだテスト自体が書いていませんが、後々ここも整理していこうかと思います。

描画

2D描画が一通り実装できて、アプリ自体のプロトが作れる段階まで、
処理速度は気にしないつもりだったので、glBegin-glEndで可能な範囲で
とりあえず組もうかと考えています。

2Dメインのゲームだと下手にQUADのバッファを生成して、
インスタンシングするよりも動的頂点バッファに積み込んだほうが
何かと効率とか柔軟性があったりするので、
描画API自体はストリーム入力形式でまとめようかと思います。*1

静的頂点バッファはストリーム入力を "固める" ことで生成させます。
将来的には "固めた" 頂点バッファをBLOB経由で保存/ロードできるようにも
拡張するつもりです。

あと考えたくない面倒なものがシェーダーだったりトランスフォームだったりします。
シェーダーはここ10年くらいのホットな仕様なので枯れておらず、
仕様が年単位で変化していっているので、正直API側でサポートするのは面倒なものです。*2

今回はシェーダーは拡張プログラム的な扱いにするようにします。
2Dであれば特殊な描画をしない限り、
シェーダーは単一でもパフォーマンス以外にはさほど影響ないため、
他アセットほど生成/解放をする必要性がないと踏んでいます。

トランスフォームは逆に枯れた機能なのですが、
必要になる数学的な機能が膨大で、独自に組んでもメンテナンスが大変で、
ハードウェアの高速化を受けようと思うとさらに実装が面倒になります。

とはいえ、2Dでは最低限のものがあれば十分なので、
効率化が必要になるまでは f32vector での素の実装をしようかと思います。

*1:どちらかというと動的なシェイプ描画のほうが多そう

*2:それでいてかなりハードウェアに依存するので標準化とか効果薄いです