05/28(金)
すでに、日記とは呼べん・・・・
気にするのはよそう。
MDxDrawは、おおむね出来たので、そもそもの目的である「C++によるゲームプログラム」を試してみた。
「なんだ、そんな話あったっけ?」などと言わないように・・・(^^;;
日記のあらすじのページに書いてあるです。で、結果、意外に簡単に出来た。まだ、Task関連だけしかやってないけど。
作ってて思ったんだけど、TaskManager自体をTaskから継承してやると、スバラシイです。
つまり、TaskManagerにTaskManagerがぶら下げられるんですけど、これにより、木構造が自動的に実装されちゃうわけです。
しかも、難解な再帰を記述する必要もなくです!!
以下に、TaskとTaskManagerのソースを乗せておきますね。// Task.h //--------------------------------------------------------------------------- #ifndef TaskH #define TaskH //--------------------------------------------------------------------------- class TTask { public: __fastcall TTask(void); virtual __fastcall ~TTask(void); virtual void __fastcall Execute(void) = 0; }; class TTaskManager : public TTask { private: TList *List; int __fastcall GetCount(void){ List->Pack(); return List->Count; }; TTask * __fastcall GetItems(int Index) { return (TTask *)List->Items[Index]; }; public: __fastcall TTaskManager(void); __fastcall ~TTaskManager(void); int __fastcall Add(TTask *Task); void __fastcall Delete(int Index); void __fastcall Execute(void); __property int Count = {read=GetCount}; __property TTask *Items[int Index] = {read=GetItems}; }; //--------------------------------------------------------------------------- #endif // Task.cpp //--------------------------------------------------------------------------- #include <vcl.h> #pragma hdrstop #include "Task.h" //--------------------------------------------------------------------------- __fastcall TTask::TTask(void) { } //--------------------------------------------------------------------------- __fastcall TTask::~TTask(void) { } //--------------------------------------------------------------------------- //--------------------------------------------------------------------------- __fastcall TTaskManager::TTaskManager(void) { List = new TList(); } //--------------------------------------------------------------------------- __fastcall TTaskManager::~TTaskManager(void) { delete List; } //--------------------------------------------------------------------------- int __fastcall TTaskManager::Add(TTask *Task) { return List->Add((void *)Task); } //--------------------------------------------------------------------------- void __fastcall TTaskManager::Delete(int Index) { List->Delete(Index); } //--------------------------------------------------------------------------- void __fastcall TTaskManager::Execute(void) { TTask *Task; for (int i = 0; i < List->Count; i++){ Task = (TTask *)(List->Items[i]); Task->Execute(); } } //--------------------------------------------------------------------------- #pragma package(smart_init)チョットまだ足りないメソッドとかあるけど、コアの部分はこれだけでOKです。
TListはVCLのクラスなので、Builderじゃない場合は各処理系に書き直すといいでしょう。
って言うか、ここはSTLで書けばいいんだね。
とりあえず、仮って事でTListのままです。
他にも優先順位とかも付けないとだめですね。それから、スプライトのクラスなんかもこのTaskから継承するとよさそうですね。
で、スプライトのマネージャではスプライトのZ値でソートするように作ると、PlayStationのOTそっくりですね。実際にTTaskとTTaskManagerを使って組んでみたけど、スバラシイ使い心地です。
で、気付いたんですけど、すべてのオブジェクトの頂点にTaskをおくのがよさそうです。
つまり、すべてのオブジェクトをTTaskから継承するワケ。
えむっちの中では久々の大ヒット作です。こいつはそもそも、1年ぐらい前に考えてたのにやっと組んだです。
やらずじまいにならなくてホッしました。
話、全然変わります。
「チョット、これは問題だろ」ってことを見聞きしたので書いときます。とある、ゲーム専門学校の学生さんのページで読んだんですけど、「ゲームのプログラマの人々」は「アプリのプログラマ」(変な表現だけどこう書いてあったのでそのまま引用)は、使えない(ダメ)と思ってるらしい。と言うか、こういった発言をしているらしい。
もちろん、すべてのゲームのプログラマの人がそう思ったり、発言しているわけではない。
なぜなら、えむっちはそんなこと思ってもないし、もちろん発言もしていない。
知っている人も多いと思うがえむっちも(プロの)ゲームのプログラマである。で、そのゲームのプログラマの発言によると、
「アプリのプログラマってスピードとか気にしないから、a = b * 4; って余裕で書くんだよ〜」
「でも、こんなのクソ!!はっきりいって、使えねぇ〜」
「ゲーム・プログラマなら、a = b << 2; だね」
「乗算って結構重い処理だし〜、ビット演算はコンピューターの得意中の得意だからね、はえ〜よ」ってことで、アプリのプログラマはダメらしい。
・・・開いた口がふさがらん。
同業者として恥ずかしい。
はっきり言って、コイツの方が使えねー。説明すると、まず、a = b << 2;って書いてもa = b * 4;って書いても結果は同じです。
なぜって、コンパイラもそれぐらいは知っているからです。
勝手に最適化してくれます。このゲームのプログラマはそんなことも知らないのでしょうか?
っていうか、そんなことも調べずにワザワザa = b << 2;って書いているんでしょうか?
ゲームやアプリに関係なく、わざわざ難解な記述をするのは良くないでしょう。って言うかダメでしょう。まあ、そんなアホなプログラマはほっといてですね、問題はもっと別の次元にあります。
この学生が、このアホなプログラマの発言を鵜呑みにして、「この様に、細かいところか常に気を配るのがゲーム・プログラマという人種、よって偉大!!」
などと、発言していることです。
鵜呑みにするなよ。
調べりゃすぐわかるじゃん。
と、学生にも責任の一端はあります。が、問題はこの学生がゲームの専門学校の学生だと言うことです。
つまり、この学校ではそんなこと教えてんのか?ってことです。
恐ろしいことです。アホがアホを拡大生産しているんです。アホのネズミ溝です。
このままでは、ゲームのプログラマはアホだらけになってしまいます。中国には、「まず、展開を求め、後に緊奏に至る」って言葉があるそうです。
わかりやすく言えば、「まず、概要をつかむ、それから詳細をつかむ」ってことです。
プログラマ的に言えば、「バブルソートを最適化するより、クイックソートをベタで書いた方が速い」です。「この様に、細かいところ」にとらわれているようでは大成できないですよねぇ。
と言うことで、もし、ゲームの専門学校への進学を考えているなら、学校選びは慎重におこなってくださいね。
あと、すでに学生の人は人の言葉を鵜呑みにしないようにしてくださいね。