Hornetの現状の問題点

元々、Hornetは3Dを標準サポートする開発環境であり、さらにクロスプラットフォームであるというのが前提であるため、OpenGLを描画に使用しなければならない。
しかし、実際にOpenGLをサポートした場合、要求するスペックがビデオカード側に傾き、CPUがそれなりの速度なのにビデオ周りがだめなためにゲームが動かないと言う状況が出てくる。

それを解決するためには、ある程度はCPU側でグラフィックの処理をさせ、不必要にハードウェアアクセラレーターを利用しないことで解決できると考えている（CPUで画像処理させた後で、表示だけGPUに任せるのは、安定性を求めるゲームでは上等手段）。もちろん、高度なエフェクトは使用するかどうかスイッチを設けて切り替えられるようにするのも必要だろう。

また、他のホットスポットとして、ADVなら文字表示が多いので、フォント周り（レンダリング済みフォントを利用するのか、それともベクタフォントをリアルタイムでラスタライズして使用するのか）が問題となってくるし、現在シナリオ言語を直接プレーンテキストから実行している点も問題だろう。

なんで、今後の方針としては

1．フォント周りのベンチマーク（SDL_ttfとSDL_kanjiの比較をやれば十分かなと見ている）
2．OpenGL周りの最適化（ディスプレイリストを使用するのと、コマンド郡を効率よくGPUに流すために、頂点バッファを利用すればある程度改善されるはず）
3．中間バイナリコードによるシナリオの実行（すでにシナリオ言語部分は中間コード作成のための仕組みを持っているため、それを利用）

をまずやろうと思う。

というわけで、SDL_ttfとSDL_kanjiの比較について。

その前に、SDL_kanjiはSJISやEUCしか使えないなど、Hornetで利用するための前提条件を満たしていないのでUnicode対応させる必要がある。
SDL_ttfでは、レンダリングフォント作成時に無駄な処理が入っているのと、UTF-8を使用する際にバグがあるので、その点をメーリングリストで報告して修正してもらわなければならない。

レンダリング済みフォントは、OSを換えた際に起こるフォントドライバによる描画の差異を吸収するためのものであって、描画の速度だとかそういったものはあまり考慮されていないとも考えられる。
ベクタデータの方が、ピクセルデータよりもデータ量としては少ないから、読み込みアクセスが減少することでレンダリング済みフォントよりも高速に描画できるとも考えられるため、速度的に必ずしもレンダリング済みフォントの方が優れているともいえない。

というわけで、なぞがあるならとことん追求。速度的な比較をまずはやってみようと思う。