つーさのくーかん

間が空いてしまいました。まだ悩んでます。あはん。

昨日の集中講義の間とかにも、ずーっとクラスの設計を考えていたんですが、どうにもこうにも、考えれば考えるほど、GameContext的なクラスを用意してそいつにDirect3DだのDirectSoundだのを持たせるのが正解なように思えてきてですね。うだつが上がらない毎日を過ごしてしまっています(なんか違う)。学生の特権である長期休暇ももう終わってしまうというのに……！

前の日記では、Direct3D.LoadTexture(...);を持たせるとか考えてましたが、それをやると、たとえばテクスチャの一部を切り出して定義するアニメオブジェクトの生成にも、D3DTexture.CreateAnime(...);とかやんなきゃいけないわけですね。すべてのオブジェクトの生成はその元になるオブジェクトのLoadやらCreateで生成することになって、つまりnew演算子を封印ですか？　なんかそれは、、ちょっと、、キモいです。いや、アリかもしれませんが……。

逆にnew演算子を使って。D3DAnime anime = new D3DAnime(texture, ...);みたいに実装するとしたら、テクスチャもやはり、D3DTexture texture = new D3DTexture(d3ddevice, ...);のような宣言になるでしょう。これを考えるともうこの時点でstaticはあり得ないように思えてくる。

staticメソッドは手続き型言語のためのAPIの提供方法なの！　それはオブジェクト指向ではないの！　はぁぁぁこれはぁぁ！　アプリケーションでDirect3Dデバイスは1個しか作れないっていう制約があるのー。みたいな。

キーコンフィグ設定が施せる入力翻訳クラスがあります。今はボタン0～15が1Pで、ボタン16-23が2Pで...なんてやってるわけですが、これを仮想化して、1Pのボタン0、2Pのボタン0って取れるようにしたい。仮想化された入力デバイスは複数作れる必要があります。ゲームのプレイヤー数は作るゲームによって異なるので仮想入力デバイスは複数作りたい。ほらもうstaticじゃいられない！　いや、DirectInputを制御するクラスに、仮想入力デバイスを生成する staticメソッドを設ければいいのかしら。でも、あーんstaticキモいよー。

自己満足のためにライブラリを耕しているはずなのにこれじゃあもはや何が何だか。