OOとゲームプログラミング

**名無しさん＠お腹いっぱい。** · 01/11/07 23:55

OOをどのように用いれば美しくゲームプログラミングを
行うことが出来るのか語り合うスレです。

**名前は開発中のものです。** · 02/01/10 04:58

燃やすまい、日本の遺産、地球の遺産。

**名前は開発中のものです。** · 02/01/10 05:05

>>443
熟練者ですか？（自分が経験激浅）
ぶっちゃけた話、どういう構造がベストなんですかね？

今のメイン組んでる人は、あるシーン用素材を元に、
必要なオブジェクトをどんどんnewしていって、
ヒープへのポインタをオブジェを管理するクラスが持つvectorに
pushしてく。
アニメーション関係はコンテナ化されています。
プリミティブ、モデル等はベースクラスから派生してて、
Render等のvirtual関数でそれぞれのCpu処理,描画処理をする。
て感じです。

難点は、殆どの処理が自動化されてて、テスト的な処理をしたくても、
シーンの素材ファイルを読まないと何も出来ない。
シーンはストリームで読み込んでて、手動で自分が作ったオブジェクトを
作る時等、初期化手続きが凄い面倒。等

STLはlist,vectorぐらいしかつかってないなあ。

**名前は開発中のものです。** · 02/01/10 05:08

・・・・・・・・・だから、資源は大切に。

**名前は開発中のものです。** · 02/01/10 05:09

PC 向けだったら資源は浪費できるでしょ

**名前は開発中のものです。** · 02/01/10 07:55

わかってそうでわかってない人が夢見がちな幻想として
「ＯＯＰ＝即座に開発効率が上がると思い込む」
というのがあるのだけど。

ＯＯＰはその前に痛みを伴う。初期の設計に欠点があれば
設計が見なおされるまでその禍根は残る。
設計が完璧になればその再利用性は飛躍的に向上するけど
問題はそのコストを支払い、堪えられるかということ。
それでもかまわないという男気あふれる者にこそＯＯＰは
ふさわしい。
（Template Method で実装を切り離せば良いって
いう話ではなくて、より構造的な問題。）

**名前は開発中のものです。** · 02/01/10 08:21

GenericProgramingのいい資料ってない？

**名前は開発中のものです。** · 02/01/10 12:44

>>449
Ｍｏｄｅｒｎ　Ｃ＋＋　ｄｅｓｉｇｎ／アンドレイ・アレキサンドレスク
今この本を注文しているんだけど、変態っぽくてなかなか良いらしいぞ。

**名前は開発中のものです。** · 02/01/13 22:14

でも、普通にプログラミングやってれば、3割～5割(場合によっては祖霊所)は無意識にOOしてるよね？
だから、べつにOOが良いか悪いかとか言う必要も無いと思う今日この頃。

**名前は開発中のものです。** · 02/01/13 23:45

認めたら最後、言語変更が行われてしまうという罠。

**名前は開発中のものです。** · 02/01/14 19:49

>>451
単純にオブジェクトの寿命と接続の関係が整理されるだけでも、
確実にプログラムの堅牢さも作業効率も上がる。
職業プログラマは大抵経験則的にそれを分かってるし、OOP言語を用いなくとも
自前のルールでそれを実装してすらいる。
通常、OOP的アプローチが足を引っ張る状況の全ては「学習不足」に起因する。

ただ、実際の開発行為は、ほとんどの場合常に自身の学習不足と向き合わなければならないわけで…。
既に分かりきったハードで慣れ親しんだ機能を実装する「答えが見えてる」場合はともかく、
学習を伴う開発行為（出たばっかの新ハードを扱うとか）で、アプローチの仕方がわかんにゃい場合、
出だしがやたら遅くなったり、一日紙の上だけで悶々としたり、傍から見てると遊んでるようにしか
（本人苦しんでても）見えないという罠や、最初のアプローチの仕方を間違えると、その遺恨を
いつまでたっても残してしまうという罠も。

>>445
STL は俺も普段は vector と list だけだ。
ツール類なら、string iostream なんかにも出番が回ってくる。
一時期 map も使ってたが、この連想マップがベタな比較コードに勝る
速度を出したことが（経験上）ないので、最近は出番なし。

**名前は開発中のものです。** · 02/01/14 19:53

一度Ｊａｖａで組んでみろ。
話はそれからだ。

**名前は開発中のものです。** · 02/01/14 20:23

>>453
罠んところ読んでると泣けてきた。

**名前は開発中のものです。** · 02/01/14 20:26

>>454
GCのふん詰まりを恐れて
オブジェクトがnewできない＆クラス分けできない罠に陥ります。

**名前は開発中のものです。** · 02/01/14 23:13

>>456
インクリメンタルGCと言うものがあるのだよ

**名前は開発中のものです。** · 02/01/15 00:03

>>457
なんだよそれ。参照カウンタＧＣのこと？

**名前は開発中のものです。** · 02/01/15 09:02

>>458
ちょっとづつ断続的にGCしていくやつのことでは。
まとめてGCするのと違って長時間のふん詰まりがない

**名前は開発中のものです。** · 02/01/15 16:48

世代別GCも注目できる技術か？

**445** · 02/01/16 01:57

タスク処理って結局、C++で再現出来るんでしょうか？
考えてみたんですが、やっぱり、関数ポインタ＋（実体）ワークでないと駄目な気がする。

理由としては、
関数の切り替えがクラスのポインタだと、別途newしておく必要がある。
てことは、１００個のタスクの中身が、全部A、全部Bという状況だと、
A,Bともに１００個ずつクラスをnewする必要がある。
て所で詰まりました。

俺の知らない良い、解決方法があるんですかね？やっぱ。

**名前は開発中のものです。** · 02/01/16 02:20

>>461
デザインパターンマンセー的にはflyweightパターンが適用できると思われ

**名前は開発中のものです。** · 02/01/16 02:22

ＡＢ行き来するときに、delete、newすればいいんじゃないの？

**445** · 02/01/16 03:08

>>462
デザパタはまだ調べてないです。
どういったものなんでしょうか？部分的にでも教えてくだせい。

>>463
それって、OKなんですかね？CPU負荷とか。
自分はやったことがないです。（ゲーム中にnew/delete）

**名前は開発中のものです。** · 02/01/16 03:12

>>461
それならメンバー関数を関数ポインタを登録しようよ・・・。
つか、Aクラス、Bクラスをメンバに持つCクラスを作って
Cクラスで切り替え管理とか。そゆいみじゃない？

　詳しくは割愛するけど、テンプレートを利用するとCに戻れな
くなるぐらい完璧なタスク処理が実現できるよー。

**名前は開発中のものです。** · 02/01/16 04:10

>>445
それ今うちで作っているライブラリの仕様と全く同じだよ。
その難点はそういう仕様がそのライブラリに無いのが原因だから、
つけてもらえばよいさ。

**445** · 02/01/16 04:34

>>465
>Cクラスで切り替え管理とか。
うーん、具体的には、どうやって切り替えをするのかわからないです。

テンプレートですか、、。
あれって、大雑把に言うと、引数の型チェックしてくれるマクロ関数
ですよね？
taskクラスをテンプレートで作って、taskが使用するリソース
（GraphAPI,SoundAPI,,,等）クラスを引数で渡す。て感じですかね？
ヒント下さい。

>>466
そうすか、、。
ウチは、安くてプラグイン書きやすい３Dツールで吐き出すのを
前提にしたライブラリだと思います。多分

**名前は開発中のものです。** · 02/01/16 04:49

タスク処理って
A)優先順位をつけて、処理を割り振る機構
と
B)処理を割り振られた方が状態を遷移させながら仕事をこなす
のと二つがセットなんですね。
私は、A)だけがタスク処理だと思っていた。

**名前は開発中のものです。** · 02/01/16 05:00

で、B)の書き方ですが、以前のC++で書いていたプロジェクトでは
状態を整数で持っていて、switch文で切り換えていたね。
#全然、オブジェクト指向じゃないな。

**名前は開発中のものです。** · 02/01/16 05:01

>>467
　うんと、テンプレートの方はとりあえず忘れて。きちんと理解
できた時に必然的に解るとおもう。

　で、下のモデルみたいな感じにすればいいとおもうんだけど。

taskC
{
public:
void changeA(){ pTask = &m_TA; }
void changeB(){ pTask = &m_TB; }
private:
void Exec(){ pTask->Exec(); }

task* pTask;
taskA m_TA;
taskB m_TB;
}

まぁ、これでもいーんだけど

void Exec(){
switch(m_Mode){
case 0: m_TaskA.Exec();break;
case 1: m_TaskB.Exec();break;
}

**名前は開発中のものです。** · 02/01/16 05:19

恰好良く書くなら、
一つの抽象クラス(A)を継承して、関数に相当するクラスを書く。
一つの抽象クラス(B)を継承して、実体ワークに相当するクラスを書く。
Aに、Bへのポインタを引数にとるapply()関数を実装。
Bに、Aへのポインタとexecute()関数と、change_state()関数を実装。
# あっ、ややこしいね。確かに。

**名前は開発中のものです。** · 02/01/16 05:23

あぁ、そういえば、メンバ関数への関数ポインタを使えば
楽なのか。
#おすすめしないけど。

**名前は開発中のものです。** · 02/01/16 06:36

なんか話が思いっきりループしてるよーな気がする。
スレの最初のほうをご覧ありたし。

**名前は開発中のものです。** · 02/01/16 07:59

俺、仮想関数テーブルのポインタ直接書き換えてるよ。
インターフェイスクラスを多重継承して、
自前の仮想関数テーブルへのアドレスを上書きする。
C++の仮想関数と、Cの関数ポインタをオーバーヘッドなしに両立できる。

**名前は開発中のものです。** · 02/01/16 13:04

プロファイルしろｳﾞｫｹども

**名前は開発中のものです。** · 02/01/16 21:30

>>474
メンバ関数ポインタを使えばいいだけ、という気がするが。

**名前は開発中のものです。** · 02/01/16 21:43

>>474
実装継承が絡んだ場合、this にオフセットをかまし忘れて死にそうな予感。

**名前は開発中のものです。** · 02/01/16 22:13

>>476
関数呼び出し方法はあくまで、C++的にしたいんですわ。
メンバ関数ポインタコールをインライン関数でラップする方法もあるけど、
仮想関数としてはつかえんでしょ。

>>477
だから多重継承を使うの。
最初の４バイトは実装継承用の仮想関数テーブルアドレス、
次の４バイトにオーバーライドするアドレスをマッピングする。
スーパークラスの仮想関数の数に影響されずに上書きできる。

**名前は開発中のものです。** · 02/01/16 22:28

>>478
仮想関数へのポインタを取ることは可能だけど、そういう話じゃなくて?

実装継承の話は、

class Deriv : public A, public B
{};

と定義されていた場合、Deriv 経由で B のメソッドを呼び出すときにはメソッドに渡す this ポインタは
Deriv::this では NG だって話と思われ。コンパイラの実装によるけど、たとえば Deriv に A, B のサブ
オブジェクトが順番に並んでる場合には

　reinterpret_cast<char*>(Deriv::this) + sizeof(A)

を this として渡す必要があるよね。

**名前は開発中のものです。** · 02/01/16 22:33

>>479
まあコンパイラの実装依存ですが、

class Deriv : public A, public B
{
int a;
};
の場合、

virtual table address A
virtual table address B
int a

とマッピングされるので、
virtual table address B
の部分を独自の関数テーブルへのアドレスに書き換えてやれば可能かと。

Bのインターフェイスを渡すときは、
this + 4とされているので、Aのサイズに依存はしないはず。

**名前は開発中のものです。** · 02/01/16 23:21

>>478
ハックくせー…つうか、明らかにC++の言語仕様上でやる意味ないぞ？そんなの。
単にシンボル解決の問題みたいだし、やはり>>476が順当だろう。
スレの主旨的には邪道の極みだと思うが、どーさ。
煽るつもりじゃないのでsage

**名前は開発中のものです。** · 02/01/16 23:24

>>481
趣味でやるなら止めないが、仕事でそんなコード出してきたら肩を叩かせていただく、ってところだな。
ま、コンパイラの吐くコードを探りつつ、いろいろやるのは面白いことは面白いよな。

参考文献
Inside the C++ Object Model

**481** · 02/01/16 23:48

>>482
ゲームプログラムでは必須のテクだと思うぞ。
関数ポインタの使い勝手と、Ｃ++の便利さの両方を享受できる
画期的な手法。

もし移植性を高めたいなら、
仮想関数テーブルのアドレスをインスタンスメモリ内から検索してやればいい。

class B;
int adr = *((int*)&B);
int* src = ((int*)this);
for (int i=0;i<sizeof(this_class);i++){
if (adr == src[i]) src[i] = overwride_address;
}

**名前は開発中のものです。** · 02/01/16 23:55

んー、なんかオレ的にC++で安全面、速度面、使い易さ全てで
不満の無いタスクシステムは完成しているのだが、どーも、生成
時の記述だけ異常に複雑になるんだよなー。

　なんかよさげな方法で実装している人いる？

**名前は開発中のものです。** · 02/01/16 23:58

>>483
画期的っていうかswitch分で処理分岐するのじゃダメなの？
コンパイラのコード的には似たようなもんだと思うけど。

**名前は開発中のものです。** · 02/01/17 00:02

>>485
まぁ、人間たまに「俺は天才なんじゃないか」って思うことがあるから、落ち着くまではそのままに
しておいてあげるのが良いかと。

**名前は開発中のものです。** · 02/01/17 00:04

>>485
switch分岐はオーバーヘッドが大きいでしょ。
１、ステートのフェッチ、
２、範囲チェック×２、
３、ジャンプテーブルのフェッチ、
４、ジャンプ

仮想関数テーブルのオーバーライドなら、
コストは仮想関数を直接呼び出すのと変わらない。

コンパイラのコード的には別物です。

**名前は開発中のものです。** · 02/01/17 00:08

>>486
おいおい、折角貴重なノウハウを享受してやっているのに。
お前もちょっとは有益なことを書き込めよ。

**485** · 02/01/17 00:21

>>487
つか、ワークシステムにおいてそのオーバヘッドがどれぐらいの
ネックになるのん？１Sync内に１０００個もワークは生成しない
しょ？まぁ技術論的には面白いが。

**名前は開発中のものです。** · 02/01/17 00:30

>>487
default文の無いswitchは単純なJumpTableにコンパイルされるけど。

**名前は開発中のものです。** · 02/01/17 00:32

>>489
まあワークシステムのUpdate程度の用途であれば
オーバーヘッドの差は微々たる物でしょうね。
どちらかというと、new/deleteなしに、
Stateパターンを適応するのが本来の目的なのです。

**名前は開発中のものです。** · 02/01/17 00:35

>>491
前にも誰か書いてたが、なぜ関数ポインタを使わないんだ？　C++ だと仮想関数へのポインタも取得
できるから、それで何ら問題ないと思うんだが。

**名前は開発中のものです。** · 02/01/17 00:38

>>490
それは有り得ません。
なぜなら、例えdefaultがなくとも、
変数が必ずcase内の値を取ることが保証されない限り
範囲チェックは必須だからです。
switch(a){
case 0:break;
case 1:break;
};
という構文において、aが0と1の値以外を取らないことは、
静的に保証できません。
まあ、
switch(a&1){}
とすれば最近の最適化コンパイラならdefaultを省略してくれるかもしれませんが。

**名前は開発中のものです。** · 02/01/17 00:41

>>486
ハイハイ。ＰＳ２だかＰＣは偉いね。

**名前は開発中のものです。** · 02/01/17 00:43

>>492
外部からクラスメンバを呼び出すとき、
unknown->Method()
としたいからです。

02/01/17 01:06

switch使ったらライブラリ化できないでしょうが。

**名前は開発中のものです。** · 02/01/17 01:10

>>495
それは、単純な転送関数を書けば良い気がするけど。たとえば、下のようなコードと比較して得失は
何なんでしょ？

> 仮想関数としてはつかえんでしょ。
これなのかなぁ。

struct State
{
　　void exec1() {}
　　void exec2() {}
};

class Foo
　　: private State
{
　　void (Foo::*pMethod)();

public:
　　Foo() : pMethod(&State::exec1) {}
　　void method() { (this->*pMethod)(); }
};

int
main(void)
{
　　Foo foo;
　　foo.method();
　　return 0;
}

**名前は開発中のものです。** · 02/01/17 01:20

>>478でも書いてるけど、ようはmethodを仮想関数にしたいわけです。
methodを仮想関数にすると、インライン展開できないので、
関数コール分のオーバーヘッドが増える。
この両者を解決するのが仮想関数テーブルアドレスの上書きであるということ。

**名前は開発中のものです。** · 02/01/17 01:33

もはや日本語じゃなくてC++で話した方がいいような気がしてきた。

**名前は開発中のものです。** · 02/01/17 02:08

ジャンプテーブルの参照なんて、どう組み込んでもおんなじじゃん…
直接vtable書き換えるようなオバカな真似してどうするのさ。
それはコンパイラ提供側の仕様に依存しているという最悪の選択肢。
正直、仮想関数のオーバーヘッドが気になるレベルの性能が必要なら、
もっと別の解決法を考えた方がいい。

仮想関数の機構は、基底を同じくするクラスの多態性を実装するためのものなんだから、
状態別でアッパーキャストするならまだしも（これだってクラスの内容によっては
何が起きるか分からなくなるので、実装依存もいいとこなんだが）、正直その使い方は
およそ賛成しかねるなあ…。

あと、直接関係ないネタだけど。

>methodを仮想関数にすると、インライン展開できないので、

これは多くの人が誤解していることだけど、実際に仮想関数がvtable経由で
コールされるのは、アッパーキャストが絡むときのみ。
わざわざ vtable を辿らなくてもコール先が自明な場合、コンパイラは直接
関数を呼び出すコードを生成する。
inline virtual なんて、珍しくないよ？

煽るつもりじゃないのでsage

**500** · 02/01/17 02:09

sage忘れた。
500ゲットに免じてご勘弁。

**名前は開発中のものです。** · 02/01/18 10:04

>>500

＞実際に仮想関数がvtable経由でコールされるのは、アッパーキャストが絡むときのみ。

まともに OOP してるなら、ベースクラス通して使う事がほとんどだと思うのですが…。

**502** · 02/01/18 10:10

書いた後に誤解を受ける文章だと気づいた。

私も vtable 書き換えなんて、よっぽどの事でもないかぎり反対です。
というかゲーム業界のプログラマって、過酷なターゲットいじり過ぎて
「まず速度ありき」なのはちょっとマズイ状況だと思う。

最適化は最後の作業ってのはソフトウェア業界の常識だと思いますけど、
そこらへんは皆さんどうお考えですか？

02/01/18 10:45

まず速度ありき
速度の前にコード無く、コードの後に速度無し。

**名前は開発中のものです。** · 02/01/18 13:19

速度を考えるなら、まずはアルゴリズムの最適化

**名前は開発中のものです。** · 02/01/18 15:54

>>503
まず、モジュール化ありき。

ボトルネックになる部分はほんの一部に過ぎない。システムを詳細な、依存関係が少ない部分にばらして
おけば、ボトルネックを見つけて改良するもの楽。（後からアルゴリズム差し替えようなんて話は、それこそ
クラスをきっちり分けてモジュール化してないと、危なくて出来ない）

**名前は開発中のものです。** · 02/01/18 16:35

>>504
確かに、コードを一行も書かなければ最速だわな。（違う?）

**名前は開発中のものです。** · 02/01/18 17:28

>>503
まともなゲームプログラマは、
Ｃ++のコードみた瞬間にアセンブリコードが浮かぶので
無駄だらけに感じるのだろう。そっとしておいてやれ。

**名前は開発中のものです。** · 02/01/18 18:54

「最も速いプログラムは何もしないプログラム」ってやつか？

**名前は開発中のものです。** · 02/01/18 18:58

バグのないプログラムもね（ｗ
しかし、vtable書き換え……俺もやめようよそれは派だな。
Cみたく完全に枯れた言語ならともかく。

**名前は開発中のものです。** · 02/01/18 20:17

>>508
その無駄ってのも顕微鏡で覗いてやっと分かる、みたいな
もんだしな。これからの時代はそういう人達をいかにｼｶﾄして
作業するかが問題になってくる。ん、時間が経てばいなくなるか（ｗ

**名前は開発中のものです。** · 02/01/18 20:36

>>511
ウイルスも何十万集まれば風邪になるってね。

**名前は開発中のものです。** · 02/01/18 20:42

ネタとしては面白くないし、比喩としては本質を掴んでない。

02/01/19 02:08

あのー。ム板ではＣ＋＋なぞＯＯＰＬとは認められて無いようなんですが・・・。

**名前は開発中のものです。** · 02/01/19 02:18

>>514
どこでそういう結論になっているのか教えてちょ
SmallTalk以外は認めない、とかかな?

02/01/19 02:31

俺に聞かれてもわからん。

**名前は開発中のものです。** · 02/01/19 02:34

>>516
おいおい（ｗ　少なくとも C++ 相談室スレでは C++ 使って OO な設計する話で盛り上がってたぞ。

C++相談室 Part4
http://pc.2ch.net/test/read.cgi/tech/1009071535/

**名前は開発中のものです。** · 02/01/19 03:06

最近は
http://www.amazon.co.jp/exec/obidos/ASIN/4894714353/ref%3Dsr%5Faps%5Fd%5F1%5F1/249-8109842-4582733
こんな本も話題だったような

**名前は開発中のものです。** · 02/01/19 04:13

>>511
禿同。

>>515
514じゃないけど、Ruby関係のスレとかでは名文句「C++なぞ問題外」
って言われるね。漏れも(万が一)環境が許すならば C++ よりも Java や C# で逝きたい派だけど。

02/01/19 04:21

再利用の極意はクラスにあらず。
ファイル分けに有り。

**名前は開発中のものです。** · 02/01/19 06:25

>>519
Rubyの煽りは敵を増やしただけだな。
RubyもOOPとしての完成度は低い。たかが一言語としての立場を
わきまえるべきなのだが。作者がそんな厨だからスレが荒れるんだよ。

**名前は開発中のものです。** · 02/01/19 07:51

ていうか、rubyをゲーム制作に利用しようとしているドキュソな
言語ヲタな時点で激しく逝ってると思われ

**名前は開発中のものです。** · 02/01/19 11:05

>>514-517
Stroustrup先生自身がOO言語じゃないって言ってなかったっけか？
俺的にはOOも可能なてんこもり言語。

**名前は開発中のものです。** · 02/01/19 13:15

>>521
>RubyもOOPとしての完成度は低い。

どのへんが？

**名前は開発中のものです。** · 02/01/19 13:41

Rubyは結構いけてる言語で、プログラムの側からスクリプトとして呼ぶこともできるのでゲームに応用できなくもない。
しかし、以下の欠点からRubyが使われることは将来にわたっても無いだろうと考えられる。

1:UNIX系生まれなので、@や$みたいな記号に重要な意味を持たせている(Win育ちには読みにくい)
2:実績がない。Python使ったスクリプトや大規模プログラムはいくつか例が見られるが、RubyではせいぜいがCGIで、後は誰も使わないライブラリや技術的テスト物ばかりが大量生産されている。
3:コミュニティがC++を蛇蝎のごとく嫌っている。PythonはC++とのブリッジとなるライブラリがいくつか存在している。

OO的にはどうなんかな? 上記2のように大規模プログラムが全然存在していないので、あまりありがたみを感じられる事例が存在していないだけのようにも思う。

**危険レベル3** · 02/01/19 13:41

Rubyの話は終了しましょう。（；´Д｀）

**名前は開発中のものです。** · 02/01/19 15:38

コンソール機用の C++ コンパイラって、どの程度の物なの？
PS2 とかは GCC って聞いたけど、それ以外は？

そっち系の方教えて下さい。

02/01/19 17:34

gcc以外？
ゲームでは見た事ないなあ。
ＰＣならＭＳ－Ｃか。

**名前は開発中のものです。** · 02/01/19 17:48

CodeWarrior

**名前は開発中のものです。** · 02/01/19 23:19

>>523
C++ は

- 手続き型プログラミング
- データ抽象
- オブジェクト指向プログラミング
- 汎用プログラミング

など、複数のパラダイムを支援する言語。OOPL としてみればメタクラスが無いとかクラスが FCO では
ないなど「中途半端」な面もあるが、現実の要求に則してうまく仕様を取捨選択してある。使いこなせば
強力な言語。

っつーことで。

**名前は開発中のものです。** · 02/01/19 23:23

>>528
VC じゃなくて MS-C なのか?

いや、俺は XBOX は触ってないから知らないんだが。

02/01/19 23:57

コンソール機用＝CUIだと解釈したが？違う？

**村人A** · 02/01/20 00:13

>>532
その昔、VB1.0という恐ろしいソフトが存在したそうな

**名前は開発中のものです。** · 02/01/20 00:18

>>532
ああ、それは勘違い。

ゲーム関係でコンソール／コンソールボックスといったら、いわゆるゲーム専用機のこと。汎用
の PC や Mac なんかとと対比しての呼称ね。

**名前は開発中のものです。** · 02/01/20 01:03

ヲタ用語なぞ知らんな。

**少女∀** · 02/01/20 01:08

>>533
そのソフトはどんな悪さをしたの？おじいちゃん。

**名前は開発中のものです。** · 02/01/20 01:16

>>535
ヲタ用語か?　海の向こうだと割と使われてる気がするが。

っつか、話が OO と関係ないな。終わらそう。

**名前は開発中のものです。** · 02/01/20 12:39

OO の冗長性がどこらへんでボトルネックになるかっていうのが
判断できないと、勇気をもって OO できないね。

で、結局パフォーマンスを気にしすぎてセコセコした設計をすると
OO のよさが活かされずに「ゲームは特殊なんだよ。」みたいな
結論に達する厨がいる。と。

02/01/20 14:30

>>538
だからＣ＋＋以外で組んでから言えつうの！
死ね！

02/01/20 14:31

＞結局パフォーマンスを気にしすぎて

死ね！

**名前は開発中のものです。** · 02/01/20 14:43

>>538
> で、結局パフォーマンスを気にしすぎてセコセコした設計
設計段階からパフォーマンスを意識する必要は、最近はない気がするなぁ。とりあえずプロファイラ
かけてからモノをいえ、に一票。

**名前は開発中のものです。** · 02/01/20 14:53

>>538
少なくともPS2の場合だったら、
クラスのサイズが大きくなりすぎない事に注意すればいいだけ
だよ。

02/01/20 16:10

はいはい、ＰＳ２以外のプログラマ―はセコセコした設計をする厨房
だと言う事だね。

死ね