爆裂眠

バーチャルコンソールやばば。
任天堂えげつない。

クラスの意味が分からない。
世界のモデリングはオブジェクトでも、
人間思考のモデリングは手続きじゃガが。

きゃーごつい本がいっぱいー
c、c++、VC++、Winプログラミング、クラスと継承、
DirectX、Direct3Dとな。
ダイレクト関係はハズレっぽい。
新しいとムズイし乱雑だし、古すぎると鬱死。
初心者にダイレクト本選びは難しい。
まあ別学科の8kの生化学本買って、
ほとんど読んでないの考えると有意義な買い物か。
ゴツイゴツイゴツイ。

ドットとかアニメとか効果音とか知識足りなやー

言語仕様からじゃなく、情報の流れから考えてみる。

情報が変化するタイミングでの分類。
・入力タイミング
・常時タイミング
・自動タイミング

これらは処理の効率から、
概念の意味でのマルチスレッドとして機能するのが好ましい。
すなわち、
入力−＞入力があるまで待機
常時−＞60fpsで事実上の常時
自動−＞各動作の最低単位時間の待機(最小公倍数タイマ)

ここで、
入力×自動の最小公倍数が実際の常時(最小単位)となる。
(実際にはデキューされるまでのラグがあるが)
つまり、えーっと、
自動タイミングは常時タイミングでなければならない。orz
意味ねー意味ねー
常時スレッドで入力動作と自動動作各毎に
固有の最低単位タイマを割り振ろうにも、
実行するのが自動スレッド一つである以上、
レスポンスが60fps以上で求められるなら、
結局それは常時スレッドとしてタイミングをチェック
してることに他ならない。
また、
入力タイミング実行専用のスレッドを用意したとしても、
入力開始イベント中に更に入力イベントが開始する場合には、
その時点で専用スレッドは常時スレッドとなる。
んヴぁー

次、ルーチンの管理を考える。

クラスのカプセル化と継承を考えると、
それはクラスの肥大と複数のオブジェクト生成を
前提として設計されているように思う。
しかし、ゲームプログラムにおいてはどうか。

率直に感じるところ、ゲームプログラムは
クラスを必要とするほど高レベルではないように思う。
それはつまり、高レベルなプログラマが
クラスを使うわけでなく、
高レベルなプログラムがクラスを必要とするという意味で。

まず、ゲームのオブジェクトは保持するメンバが
基本的に少量である。
そんなことないと言うのであれば、
それはクラスの使い方を間違っている。(こ、殺さないで・・・)
そして、オブジェクトの数を大量に求める傾向にある。
そしてゲームプログラムの簡便とは、
そのオブジェクト群の一元管理の方による。

クラスはいわば一軒家である。
しかしゲームメンバ独身男たった一人には広すぎる。
そこで独身男をアパートに詰め込む。
そしてこれを一元管理の単位とする。
アパート自体の数はそんなに必要ではない。
このアパートをフェイズと名付ける。
名付けてみただけでとりあえず終わる。

余計ややこしくなった・・・