スプライト機能を考える

DXRubyにはスプライトクラスは無い。
世の中のゲームライブラリにはあるものもある。
そのあたりについて考えてみる。

スプライト機能は初代ファミコンやMSXなどのゲーム機や安価なパソコンにも搭載されている、それはそれは古い機能である。
なにができるかというと、メモリ上にグラフィックデータを置いて、スプライト情報メモリに座標と、画像がどれかを表す番号を書き込むだけで、スプライト専用回路がその情報をもとにVRAMに展開してくれる。
描画処理にCPU時間が食われないようにするアイデアだ。
DirectXのポリゴン描画も基本的には似たような感じで、テクスチャをメモリに置いといて、座標やテクスチャ指定やその他のエフェクトなどを指定することで描画する。
スプライト機能は、ハードウェアが参照するスプライト情報の位置や数が固定されていたりするが、DirectXは半分ソフトウェアがやるのでそういう制限は無い。

スプライト機能の概念から言えば、描画できるスプライト情報がある程度の数あって、そこに位置と画像情報を入れていく感じになるから、ベースとなるのは「スプライト」というものである。
ハードウェアが提供する「スプライト」というものに対して、位置と画像を指定して、それを描画させる。
オブジェクト指向的に言えば、最上位のクラスが「スプライト」というものを扱うスプライトクラスになって、描画機能を持つ全てのクラスはそこから派生する、もしくはスプライトクラスを内包する。
この構造は、あくまでもハードを安く、高速に動作するよう設計するためにできたものであって、現在のソフトによる描画や、DirectXを使った処理では、この考えをひきずる理由はない。
ハードウェア的な制限というだけで、ソフトウェア的は理想ではないからだ。
もちろん、オブジェクト指向では自分や敵などの描画を伴うオブジェクトは、自分で描画機能を持つのが正しい、ともいえるから、スプライト機能を作りこむのは決して間違いではない。
が、それがわかりやすいかと言うと話は別だ。

まあ、ようは描画さえできればなんでもいいわけなのだが。
単純に画面に向かって描画するメソッドが一つわれば十分で、スプライトという概念をわざわざ間に挟むのは、複雑さを増すだけなのではないか、と思うのだ。
とはいえ、見方を変えれば、DXRubyはスプライト機能をシステムに取り込んでいるとも言えるから、そのあたりは微妙な話ではある。
Window.drawは座標とイメージオブジェクトを指定して、スプライト描画登録をしている。
ふむ、理屈では確かにそうだ。
でもどちらかというとDXRubyの考え方はDirectXに近くて、スプライトという概念をベースにしておらず、ソフトウェアで処理しやすい形を追求したらこうなった。
したがってこれはスプライト機能ではない。
うーん、微妙なラインだ。

結局のところ、実際にハードウェアでスプライトを処理しているわけではないのだから、そういう機能は自由に作ればよい。
ハードウェア処理のスプライトに慣れていればそれを模したものにすればいいし、そういう経験が無い人をターゲットにするなら、また別の、わかりやすいと思う考え方にすればいい。
現在ではスプライトという言葉も、ハードウェア処理の方式を指すものでもないわけで、機能の名前にたいしてどうこう言うものでもない。
ただ、もともとのスプライトの概念はハードウェアによる制限とアイデアから生まれたものであって、単純にそれを適用するとソフトウェア的に非常に扱いにくいものになる、というのは、間違いなくそうなのだ。
DXRubyは簡単にしたいから、スプライトの概念を採用せず、似た仕組みはあっても表に出したりしない。
そんな感じだ。