グラフィック機能に関しては先のあれで大体触ったので、スプライトとBGも触る。
スプライトは、スプライトという言葉が形骸化して、ただの2Dを示すようになって以降の方が馴染みがあるので使い勝手に関してはなんともかんとも。メモリにゴリゴリと色を書き込んでいる感覚のある、グラフィック機能の方が好きかな。
サンプルなどでは固定値でN個確保してやっているのですが、これをフレキシブルに管理してみたいので、生成・破棄関数作って空きスプライトの番号を探してとるとかいうマネージメントをやってみたりするも、100個の使用状況を舐めて比較したあたりで処理落ちしだしたのであえなく終了。必要最小限に小分けするべし。
スプライト100個全部出し切って、無茶できるようになってほしいものです。
BGは、BGだけでFPVが表現できるのかなと試す。
これは全部プリセットを使っていますが、自分でキャラとパレットの定義をしないと駄目ですね。洋ゲー臭いドットと色遣いにしたいところです。ドット打てませんが。
BGは8×8単位なので、場所によっては斜めの壁と正面の壁の繋ぎ目がどうしてもずれたりするので、ちゃんと不自然に見えないようにLODを作らないと駄目なようです。
あとBGは変に工夫するよりも、そのまま出してしまう方がかえって高速なのが曲者な気がします。高速とはいっても、流石にこれだけの書き換えはすぐには終わらず、書き換えるタイミングで見えてはいけない部分が見えてしまうので、レベルの構造がばれて台無しに。かといって、一旦バッファに番号を書きだして差分だけを書き換えるとかもやってみたのですが、比較処理が増えてかなり重たくなってしまうという。
画面全部を使ったこの手のゲームがあの時代になかったように、描画サイズをこれ以上に小さくしていまえば楽ですが、それは最終手段ということで高速化の研究が必要なようです。画面サイズの倍以上BGの描画領域があるので、この余白を使わない手は無いといったところでしょうか。
しかしながら、この手の古い表現は失われていってるので、新規でアルゴリズムを考えるのに等しいのでなかなか大変ですね。今ならポリゴン置くだけで正確に描画できるし。サンプルでもラインで描画しているものがありますが、なかなか力業でやってるんだなあと。
ちなみに私はこの手の超古典的なRPGはかじった程度で碌にやったことはないので、このまま投げ出さずに出来上がっていくとどんなものができるのか、色んな意味でちょっと楽しみです（妄想しながら）。
