○○とゲームプログラミング Rev 3.0.0

　「OOとゲームプログラミング」から派生したスレです。
　OOも含め、ゲームプログラムの制作に関わる様々なトピックを
語りましょう。

　単なるC++でのクラスの書き方から、設計やパターン、制作手法
まで守備範囲広し。

過去スレ:
OOとゲームプログラミング Role2
http://pc2.2ch.net/test/read.cgi/gamedev/1067458051/

OOとゲームプログラミング
http://pc2.2ch.net/test/read.cgi/gamedev/1005144931/

略語一覧
　OO オブジェクト指向
　OOP オブジェクト指向プログラミング
　OOPL オブジェクト指向プログラミング言語
　OOA オブジェクト指向分析
　OOD オブジェクト指向設計

別にOOPLでなくとも、OOPはできます

番外
　AOP アスペクト指向プログラミング
　　　平たく言うと継承よりも集約重視のプログラミング

>>1
スレ立て乙

○○は、ObjectOrientedじゃなくて
「ソフトウェア工学」
「バージョン管理」
「メモリ管理戦略」
等、好きなものを入れてくれってことだよね？

乳首とゲームプログラミング

>>4
まあその時その時でテーマが自然発生するから、それにそって話せばいいんじゃないかな。
何かを議論して決めるというスレでもないし。
あんまり酷いスレ違いテーマの場合は、参加者の方で無視するでしょ。

じゃあ、ネタになりそうな事でも書いときますか。食いつきたい人はどうぞ。

まず、例外はどうでしょうか？
例外とゲームプログラミング、というテーマとかで。

>>4
そこまで広範囲になるなら

ゲームプログラミング相談室【Part5】
http://pc2.2ch.net/test/read.cgi/gamedev/1036410116/

こっちと統合すればよかったんじゃない？

>>7
ぬるぽ

>>8
こっちは設計方法論とか方針とかまぁそういう方向性で。
まぁ、「○○」と「ＯＯ」掛けてるつもりかもしれないので、一応OO中心で？

>>9
ｶﾞｯ

という事で、皆さんは例外投げてますか？
キャッチしてますか？
同僚はどうですか？

海は死にますか？
山は死にますか？
風はどうですか？
空もそうですか？

とりあえず、ＯＯでギャラクシャン造ろうぜ！
main.cpp と main.h の二つのファイルのみから造るギャラクシャン。

>>12
司会気取ってねーでお舞いがまず煽り入れるんだろうが、このｸｿｺﾃが

いいから手短にナムコ・クラシック造ってみろよ。
OOよりも学ぶべき大切な手法が見えてくるから。

ドルアーガの塔はどうかしら？

TreasureEachFloorパターンの典型例だね

ってかゲームってつくってたら普通にOOになりやすいジャンルだと思うのですが

OOで分析しやすいからといって
そのまま実装できると思うからまた躓く人が多いわけで

んじゃー、インベーダ。
実はギャラクシャンよりもちょっと難しい。
トーチカの実装がね。

インベーダや自機の弾丸によって、トーチカがドット単位で削れていく。

乗りますか。

ギャラクシアンというゲームがどんなだったかかなり忘れてるんだけどね〜。
じゃ、例えば敵はCEnemyという共通のクラスを継承したオブジェクトになるとしましょう。
敵の中にもいくつか種類あったよね。CEnemyRed : public CEnemyな感じで。
そんで、敵全滅させるとクリアだよね。
で、例えば一番お手軽に、敵の数そのものをCEnemyクラスに持たせるとして。
staticメンバで。コンストラクタでプラス、デストラクタでマイナスと。

＞敵の数そのものをCEnemyクラスに持たせるとして

あんたのレベルの低さがよくわかった。

ここでまた何時もの言い合いが始まるわけですよ。

>>23
どこかの国の野党じゃあるまいし、とりあえず対案を出そうよ。

ま、敵の数の把握には他にも色々方法はありますね。
ステージ情報のようなクラスを作って外部に持たせる方法もありますし、もっと直接的に、
CEnemyの派生クラスへのポインタを格納するコンテナのサイズを直接取得するという
方法もありますね。

ちなみに私は超レベル低いですよ。先に言っておきます。いちいち指摘してくれなくても
結構ですよ。でもご指摘ありがとうね。

>>23
これでＯＯの話なんかできるわけないことが分かっただろ？
こいつらは２次元
指摘しても逆ギレ
代案だそうよとか言って結局自分は何もしない
他人の作ったものでしか組み上げることしかできない三流ＰＧ
自分の為に時間を使おうぜ

＞敵の数そのものをCEnemyクラスに持たせるとして
これはたしかに根本的な設計思想でもめそうな予感。
はっきりいって俺はこいつ（>>22）とは合わない。

>>27
見苦しいな。そんなに前スレの件が悔しかったのか？
こんな所に一流PGが来る訳ない事ぐらいわかれよ。
もしかして前スレでの自分の不備を気付いてないのか？

http://homepage1.nifty.com/fujiwo/develop/oo/dscsnptn.html

まさに団栗の背比べということだな

>>30
すまんかった。精進する。

>>30
このスレに、ぴったり当てはまる。

とりあえず自称1流PGといっておこう。
何か質問ある？

>>34
質問：代表作は何ですか？

やっぱ
り俺は
最強だ
な。

自称1流PGの俺に代表作などないわっ！（ビシッ！

レスの流れを見て思ったんだけど、私は別に「正解」を書いてるわけじゃないので、
「レベルの低さがわかった」とか「俺は合わない」とかじゃなくて、「ここをこうするともっと
良くなるんじゃないか？」という話にすれば、ある程度スレが盛り上がると思うんですよ。
そりゃ批判するのはラクだし楽しいとは思いますけどね。

>>38
いや、過去ログ読んだけどあんた絶対に譲らない人でそ？
だからＯＯもそんな独りよがりなわけよ。
おかしい設計をおかしいと認識できないのは
あんたの性格に問題があるわけよ。

あんた絶対食ってかかってくるからいちいち指摘したくないもん。
まわりもそんなんでそ。じゃあねー。

＞敵の数そのものをCEnemyクラスに持たせるとして

いてててて

じゃあ

★俺ならこうする
・CEnemyはファクトリを通して生成するようにする。
・Enemyのファクトリにはオブザーバを登録できるようにする。
・Enemyのファクトリは新しいEnemyインスタンスが生成された時に
　オブザーバのOnEnemyCreateイベントハンドラを呼び出す。

★とむ氏の実装より何が良いか
１．「数を数える」以外の用途が必要になった時も、既製のソースに変更を加えることなく機能追加できる。
２．例えば関係しない２つの世界が必要になった時、とむ氏の方法の場合は作り直しだが
　私の方式の場合はファクトリを２つにするだけで作業は終わる。

１．が理解できない人は委譲指向のOOが理解できていないと思われる。
２．が理解できない人はSINGLETONとMONOSTATEの違いもきっと理解できない。

実際、２．のシチュエイションは仕事でハマっている人を見た事がある。
そのソースは元々グローバル変数に依存していたが、
仕変で画面分割モードができて対応におおわらわしてたよ。
その仕事のバグレポートはたしか項目4000個超えてた。大変な仕事だった。

>>40
まあ、確かにあれでは軍との契約は獲得できないでしょうね。

CEnemyが敵のリストなのか、敵単体なのか今いち理解できてないが
どちらにせよ、staticで敵の数なんて持ったら、>>41でいう ２．でハマルってことか。
なんでもかんでも、monostateするより、拡張に備えてsingletonにしとけってことですか？

>>39
確かに私は「食ってかかる」タイプですね。それが嫌な方は、最初から何も指摘しなければ
いいんじゃないでしょうか。

その点で>>23さんはいいと思います。最初は単に「レベルの低さがわかった」などと書いて
それっきりだったので、「またいつものか」くらいにしか思ってなかったんだけど、ちゃんと
その後自分ならどうするというのを書いたので、これだと議論になるというか、スレとして話に
なると思います。

>>43
うん。Singletonじゃなくてもいいけどね。
あとせっかくのSingletonも毎回インスタンスの取得してたら
グローバル依存とそう変わらないから、ポインタなり参照なりをメンバに保持するのが賢いやり方だと思う。

>>44
で、私の実装案へのご意見などは？
「それは駄目だろ」とか「これは納得」とかあるでしょう？

とりあえず今日は俺は寝る！

>>39
そんなの七誌も含めてほとんどの人間がそうだろｗ
とむがコテハンだから目立ってるだけ
だから余分にたたかれるのも覚悟してるんだろうがな。

>>45
いや、うん、いいと思いますよ。
あなたの言う、「例えば関係しない２つの世界が必要になった時」などは全く念頭に
置いていなかったので。そういう拡張されたギャラクシアンを作る事を念頭におけば、
確かに基底クラスに数を持たせるというのは問題かも知れませんね。

私が書いた時は、単に手っ取り早く敵の数を表現したかっただけなので…。そのへんが
確かにつっこまれると自信がなかったので（笑）、「一番お手軽に」などと言い訳がましい
形容詞がついてたのです…。

せっかくだからサンプルコード書いてほすぃ＞Enemy関連のOO
勉強になりそうだし。

あ、私も希望。
ちなみに前スレの930氏が出してたURL。置いてよしBBS。

ttp://do.sakura.ne.jp/~junkroom/cgi-bin/megabbs/readres.cgi?bo=lounge&vi=1075503745&rm=100

で、今さっき風呂入りながらぼけーっと考えてたんだけど、やっぱり自分でギャラクシアン
作れって言われても、CEnemyなるものを作ってそこに数を管理させたりしないよな、とか
思いました。確かに私の低レベルさを示してますね（笑）。

ちなみに、>>42のレスで気がついた人がいるかも知れないけど、敵の数をその基底クラス
に持たせるのは、Effective C++に書いてあったやり方。だからなんだと言われても困るけど。

風呂に入りながらぼけーっと考えているとむを想像してしまうから
できればそういうことはいちいち書かないでもらえると非常にありがたい
ついでにコテハン止めてくれればなお良い。

>>50
俺はキミみたいなののほうが鬱陶しい。

変に反発する奴がいなけりゃ、進行役みたいのがいた方がいいと思うんだが…。

ギャラクシアン自体知らないから誰の言ってることが正しいのか判断できねーや

プッチンプリンは、プッチンとプリンに分けないほうがいいんじゃないのか？

>>54
わけろよ。
わけておけばプッチン　ゼリーも作りやすいだろ。
だいたいプッチンの部分なんて容器だけで中身と大してかかわりすくねーじゃねーか。

>>55
そんなことはない。
中身によってはプッチンの大きさを変えないと十分に空気が入らず、
「ママー！プリンがプッチンできないー」と泣き叫ぶ子供が多数発生する。

で、こういった 開き直りタイプはどう処置すればいいんだ？

俺は上を目指したいんだよ。
分かってて静観してる奴、おまえらが発言してくれないと
俺はこいつらと同じ人間だと思われ、こいつらのざれごとに もまれなきゃならんわけよ
で、俺が反論したりコテ叩きだしたら 俺が荒らし認定だ。

やってられんわけよ。上の議論のアンチパターンみたく
なんか うまく開き直りを処置する方法は ないもんかね？

放置するのも手だが、それじゃ あんたらのサインは読み取れないわけよ。

>>56
大きさ変えりゃ解決できるんだからそこまで密接なもんじゃねーだろ。

私はプッチンしないでそのまま食べる。

>>59
プッチンの開発者が聞いたら号泣ものだな。

俺はプリンよりヨーグルト派だ。はたしてヨーグルトにプッチンは有効だろうか。

>>57
なんつーか…まずは人を見下したり馬鹿にするのをやめるべぎだと思うぞ。
2chだって紳士のいるところには紳士が集まるもんだ。まぁこの板は荒し多すぎだけどな。
ところで君は上を目指すと言うが、その言葉に見合う努力はしているか？
まずは人が推薦するような本を20冊は読もうな。
でもってその本の内容を理解したら、こんな所で燻ってる必要は無いぞ。
まともな奴がいる所を探して、そこで議論しような。

プッチンプリンとゲームプログラミング Rev 3.0.0

>>57
あんた誰？

全然、関係ないが、昨日、初めて処女を食べた。
冷静に考えてみれば、三十路になるまで、処女を食ったことがなかったのだ。

>>64
三十路になるまでｾｸｰｽをしたことが無い奴が大半のこの板でする話ではないな。

まぁよい
迷惑かけたな

>>47
あんたが負けず嫌いだという事が良くわかった。>>39を読んであらかじめ覚悟していたから
何とも思わなかったが、前フリが無かったら今ごろ俺ケンカごしで書き込みしてたな。
ちなみにEffective C++はC++の本であってゲームプログラミングの本じゃない。
ゲームプログラミングの本ではない本のサンプルを実践的なゲームプログラミングの話をしている時に
さも正しいかのように持ち出すのはおかしいと思うよ。
「別に正しい例だと言っていない」っていうんだったらわざわざそんな事描く必要性まったくないよ。
まあスレにまともなネタ振れる人間がいないみたいだから、
あんたがネタ振り絞る事は「俺は」否定しない。てか頑張れ。
言い訳がましいレスさえつけなければ悪くないと思う。

>>48
俺の例の話ならGoF本読んで考えて下さい。

関係ないけど俺的買った本
amazonにて購入
・ソフトウェア工学とコンピュータゲーム
今日届いたので当然まだ読んでない。
何か面白いトピックでも見つけたら俺もネタ振りするかも。

Gof本持ってるけどいまいちよー分からん。
結城先生のデザパタ本読んだ後、改めてGof本読もうかにゃー。

GoF本は今更買って読むほどの価値無いだろ。

GoF本て
http://www.amazon.co.jp/exec/obidos/ASIN/4797311126/
だよな。買う価値無しってほど廃れちゃいないと思うがなぁ。

>>71
その本って原著がWindows95が発売される以前に書かれただけあって、内容が古いなー
と思う箇所が多々ある気がするのは俺の気のせい？
それにSmalltalkとの比較とかも沢山あるけど、そんなもん大半の読者にとって必要無いだろ。
昔ならともかく、今はGoFのデザインパターンに関して噛み砕いて説明した書籍やサイトが沢山
あるのに、わざわざその本を\5000も出して買う価値があるとは俺は思えない。
てか、その金で美味い飯でも食ったほうが絶対幸せになれる。

ところで設計ってどの程度やってる？
UML使ってゲームの設計やるような奴ってどれぐらいいるのかなぁ。
みんな普通に使ってるってんなら俺も本腰入れて勉強するから
実践投入の実例があれば教えれ。

>>67
お前はすでにケンカごしすぎるぞ。
とむだってEffective C++に書いてあるから正しいとは書いてないだろ。
そこに書いてあったと言ってるだけ。
自分の非を認めてる奴にそこまで噛みつく必要があるのか？

>>67
>ちなみにEffective C++はC++の本であってゲームプログラミングの本じゃない。
>さも正しいかのように持ち出すのはおかしいと思うよ。
んー、なんでもかんでも否定にとるのはよくないぞ。バイアスかかりすぎ。
あれはとむ君一流のジョークだと解釈してあげないと。

Effective C++でとむが挙げた話が出てるところだってそういう文脈じゃ
なかったっけ？＞軍との契約云々

マターリとゲームプログラミングについて語ろ？

>>72
> GoFのデザインパターンに関して噛み砕いて説明した書籍やサイトが沢山ある
そういう事なら納得だよ。てっきりデザインパターン自体に価値が無いのかと。

>>75
そう、あれじゃ軍との契約は得られないが、話として分かりやすければそれでいいみたいな流れで書いてあった。
要は、そこにつっこみを入れてたら話が進まないだろってことだ。

多人数で大規模ゲームつくるなら
GoFとかEffectiveC++とかの知識は本当に必要になる。
マジで

あっしの勤めてるﾈｯとゲー会社、Cなんだけど・・・（涙
C++で作らせてほすぃ・・・。

GoFなんかはCでも応用できね？CでOO

＞CでOO
そんなこと言う人（ｒｙ

>>81
できるけど気が引ける

Cで無理矢理OOしよう　ってのが
例のタスクシステムとか言ってるやつじゃないの

>>84
いや、そりゃ違う話だよ。
まぜるな、また、変な議論はじまるから。

CでOOの分かりやすい例は
FILE*と高レベル入出力まわりか

あとは関数ポインタ使ってクラスの真似事も無理やりできなくはない

まぁ、俺に言わせれば、C++ごときでOOはキツイと思うがな。

C#だとかD言語だとかが出てるこのご時世に、
なぜC++にこだわる？

「俺はC#でゲーム組みたいんだ」と思っても諸般の事情が許さないからじゃないでしょうか？

PS2でC#動くの？

むしろC#やDが動く環境ってどれ位あるんだろう。
それにOOだけにこだわるならsmalltalkでもやりなさいな。
つーかさ、このスレって毎日…。

まーまー、煽りだよ煽り。そう簡単に釣られるなよ。
ただ、煽りなんだが、87の所感は正直なんだ。
現実的な問題として、89氏が指摘してるように
「最大市場でそれ動くのかよ？」という壁にぶつかる。

コンシューマは当分、C++での辛抱は続くな。枯れてるぶん、無難か？

> つーかさ、このスレって毎日…。
同じ厨が沸き沸きしてるな。と思ってたわけだが。
コンシューマっつても色々あるけど、C++まともにサポートしてる環境ってどれだけある？
俺はPSとPS2しかやったこと無いんで詳しくないんだが。

>>91
激 し く 同 意

C/C++しか選択肢がない環境に耐えられん

>コンシューマは当分、C++での辛抱は続くな。枯れてるぶん、無難か？
C++はまだ枯れてないような気がする。テンプレート周りとか。

>Cで無理矢理OOしよう　ってのが
>例のタスクシステムとか言ってるやつじゃないの
あれは、プロセス、タスク、スレッドとかそういう方向性の話題ですな。
OOとは直交してるんじゃない？だから、OOでタスクシステムを実装とか
いう話が出てくるわけだし。

プログラムじゃなくて議論を楽しむようじゃ向いてないかと。

OOPLを求めている奴はC++ごときって思うのかもしれないけど、
C++はOOもできるPLだからね。
C#のテンプレート仕様は見えてこないし、
Javaのgenericsは必要以上にシンプルになっちまったし、
Dのテンプレートもあと一歩大事な所をサポートしていないし。

まあC++を語る前にModern C++ Designを読んで理解してみろって事だ。

OOとGenericsもある程度直交概念じゃね？
強い型付けの言語は大変だってことで(それしか選択肢が無いからしょうがないんだが)。

C#やらDやらのガベージコレクションのある言語はゲーム開発には向かない罠

最近のGCの進化と最近のCPUの速度があれば、そんなこと無い(もしくは
なくなってくる)と思うけど。

まぁ、メモリ量が限られているプラットホームでは怖くて使う気にはな
れんが(コレも偏見かもしれん)。

>>100
ＰＣなら再起動してもらえばいいけどな・・・。
専用ハードなら自前でＧＣ以上の機能実装くらいしてるべ？
同等機能じゃなくて、ＧＣなくてもまったく問題ないアプリというか。

ＧＣないと困るのは設計ヘボすぎだろう。ないと困る言語使用はしゃーないとしても。

ゲームは性能が求められるの世界なので
仮にGCが必要だとしても
自分で実装するぐらいの人間じゃないとね

>>98
もちろん直交してる。「C++なんて」っていう奴がOOと直交した他の概念を
知らなさ過ぎるという話。

C++テンプレートはもはやgenericの概念を超えた新しいステージに到達している。
これを利用できない環境へはもはや全面移行できないだろ。

とりあえずゲームプログラマーとしては
現状C++マンセーでOK？
先を見るならC#, Dあたりかな。

genericsを極めるなら関数型言語へ
OOを極めるならSmalltalkとかへ
実用性を求めるならC++へ

なんだかしらないが妙に必死でﾜﾛﾀ
別にここはスローガンを考える場所じゃないんだから
まともに中身話あおうや

久々にまともな事書いてあるなぁと思ってたが
人によっては必死に見えるんだな。

おまいら、携帯電話用ゲーム開発者は蚊帳の外ですか、そうですか。
Javaなのにクラス使えない環境でOOを語るなということですか、そうですか。

すみませんでした。

ほほう、そんな環境あるんだ。J2MEでクラス使えないと？
具体的にどういうJavaなのか見当がつかない…

メモリ制約が厳しいから使いたくても使えないってことじゃない？
俺も良く知らんけど。

>>108
クラス使えなくてもOOはできるよな。

C#なんてありええねだろ。

つーか言語なんてどうでもいい。
C++がいいとか、Javaがいいとか、そんな瑣末なこと
どっちでも大して変わらないよ。

>>109
i503時代(10k制約)に研修で作ったけど>>110の言うとおり。
クラス定義を１つ追加しただけで何百バイトか食うから、
全部１つのクラスに納めてた。

でも今って100kくらいいけるんだよね？

>>113
それ業務PG時代にコボラからよく聞いたセリフだな。

// 多分、それらは「ほげ」と同じくらいパワフルなんだろうけど、
// どういうわけかふわふわしたおまけがいろいろついているんだ

>>108
俺も派遣で昨年まで開発してたよ＞携帯ゲーム
中間コード30k制限ですた。。。
複数あったクラスは最終的に1つに。。。

>>108
そのくせポインタとか使えないからな。
かなり性質悪い。

>>112
まったくだな。
Dならまだ分かるにしても(GC切れるし)、ゲーム用言語としてはあり得ない。
C#ならマルチプラットフォーム環境が整備されているだけJavaの方が遙かにマシだ。

C#もマルチプラットフォームじゃなかったっけ？一応ｗ

Monoなんて使い物になってないじゃん。
これからも、ある程度出来上がってきたら新バージョンが出て追いつけずの繰り返しになるだろう。
しかもGUIはWineを使ってるから、パフォーマンスは圧倒的に悪い。
ゲームなんて話にならない。
Windows専用言語だな。

Javaもそうなんだけどね。
ところで、GCについて一家言あるみたいだけど、どういう苦労しました？

JavaはC#と比較にならないほど、マルチプラットフォーム環境は整ってるけどね。
グラフィックは遅いけどWindows以外のC#よりは遙かに速いし、OpenGLを直接
触れるライブラリもあるし、いずれ標準に組み込まれるそうだ。
とは言っても、C#よりはマシなだけで激しい動きのあるゲームには向いてないね。

２行目は俺に書いてんの？
GCがある環境ならオブジェクトの廃棄を出来るだけ行わず、プーリングすると
言うのが定説だったと思う。
負荷にかかわらず、確実にGCを起こしてしまう命令があればいいのにね。

>>121
javaのSystem.gc()って、負荷次第で無視されるんだっけ？

GCを起こすメソッドは普通の言語なら準備してるとおもうが・・・。

C#はWindows上ではDirectXが使えるので決行マシかもしれん(いろいろ問題あるらしいが)。
まぁ、実際のところゲームでマルチプラットフォーム性なんてだれも求めてないんだよね。
かろうじてWin/Mac互換の需要があるくらいか？

現状のゲーム業界だと、採算性考えると、マルチプラットフォームは
かなり重要なんだがな。趣味ならしらんが。
まあ、そもそもC#は駄目すぎだが。
C#なんて勉強する時間あるぐらいなら、他に有益なことたくさんあるだろ。

>>122
無視と言うよりも、いつ起こるか保証されないんだよ。
先送りされる可能性がある。

>>123
Windows専用ならC++やD言語の方がいいんだよね。
ツールの類ならDelphiやC++Builderでもいいんだし。
そっちの方が速いし、DirectXだって使える。
だからゲームとしては問題外。
マルチプラットフォームを考えても問題外。

>>125
どういうときに先送りにされるんですか？

「あ〜もうかったり〜ゴミ集めないとな〜でも今日はめんどいからやめよっかな〜
　いいや、明日やろうっと、明日明日」

という感じじゃないでしょうか。少なくとも私個人はそうです。

>>126
こんなのあったよ。
http://java.sun.com/docs/hotspot/gc1.4.2/index.htm

というか、バージョンや実装によっても違うらしいよ(調べたこと無い)。

＞現状のゲーム業界だと、採算性考えると、マルチプラットフォームは
事実上、市場はPS2かGBAだけだし。間違いなく3年はこの状態、続くだろ。
マルチってなに？

大手だとC++でマルチプラットフォーム意識したライブラリ作ってるだろ

マルチプラットフォームも突き詰めると
結局優れたひとつのプラットフォームで良いじゃんってことにならない？

複数のハードを作るコスト、複数のラッパを作るコスト
無駄だよなって思う。

んで、独占とか(妥協の産物としての)規格化とかの弊害の話が出て
話がループする、と。

ネットワークゲーム（Windows）開発している会社から内定もらったけど、Cで組んでいるそうな。
なぜC++で組まないんでしょうか？

それはもうその会社に聞かないとわからないと思うんだけど…。

想像するに、古参開発メンバーがまだC++に移行しきれてない、というのが
挙げられますが。

>>131
どのハード、あるいは流通形態が「優れている」かを誰が判定するの？

それは誰にも分からないから、各人が作った製品を市場に並べて、そこで
淘汰させるのが自由主義経済。頭の良い官僚が唯一絶対の規格を決めて、
国民全部従おうというのが計画経済（社会主義経済）なわけだが。

そりゃ売れてるハードだろ。ユーザの負担が一番少ない。
んでその弊害が>>132な。

>>135
いや、そらもちろんそうなんだが理想論の話だから。

マルチプラットフォームのライブラリというか、
要するにひとつの統一開発環境を前提とするのなら
当然大部分は最大公約数的な機能中心に絞られるわけだから、
ライブラリの要件を満たすだけの機能、性能があればいいわけで。

結局何が言いたいかというと、各ハードウェアの旨みを消している部分も少なからずあるから、
マルチプラットフォームな展開はそれほど重要視するべきプライオリティを
持ってないような気がするということです。

大体わかるがその話も過去になりつつあるな。

＞いや、そらもちろんそうなんだが理想論の話だから。
それがDirectXだという見方もあるな。実際に理想だったのかは見たとおり。

ちょい別の話になるけど。
つか、もう、いい加減、とりあえずＣＤＲＯＭ突っ込んだら
ＰＳ２だろうがＧＣだろうがＸＢＯＸだろうがとりあえず画質悪くても動けよ！
って感じするな。
音楽ＣＤやＤＶＤは規格が統一されてんのにな。
ハードウェア会社の都合でなんで俺等が苦労してんだよホント。

じゃ、次はWinodwsで統一ということで。

売れてるソフトは現状、PS2とGBAのみ。この二つで94%のシェア確保。
残り5%がGC。残り1%（X箱、PS1、PC-Gameなど）
ゲーム業界では珍しく、安定期と言われてる。
おそらく最低３年間は、このPS2安定期が続く。
次世代X箱も来年末。
この次世代X箱が破竹の勢いでPS2市場を駆逐するという前提で3年。
できなければ、この安定期は4年、5年と続く。
任天堂の据え置き型次世代ハードに関しても、
先行発表どころか噂すらもない。

マルチプラットフォームなどという時代違いな考えでは
光栄のようなPS2に特化した無双シリーズのような高品質な
アクションゲームを定期的にリリースできない。

どこの制作現場もPS2のみで一杯。合間にGBAのラインを走らせる。
見事なバランスが取れた状態が、ここ3年続いてきた。

ハード乱立時代であれば賢明なマルチプラットフォーム戦略も
こう太平な時代ではかえって非効率で作業工程を増やすだけの摩擦に過ぎない。

会社的にはＰＳ２がいいのかもわからんけど、
開発者は使い捨てられる感じムンムンだなぁ。
ＰＳ２終わったらまた次世代ハードでチューニングがはじまるわけかな。
ＰＣで利益出せてる会社って結構いいかもしれないな。

できるだけ会社の仕事もツール製作担当になると楽だよな。
Win32API+DirectX覚えるだけで重宝してもらえるし。
次世代ハードになっても影響あんまりないからね。

おまいら会社のトップの立場で考えてみろよ。
PS2だけでいいなんて理想論だろ。
GCとPS2なら圧倒的にGCのほうが性能上だし作りやすい。
市場がシフトし始めた時、GCのノウハウ持ってなかったらまずいって思わない経営者はDQN。

どうでもいいけどソニーのハードは
「これだけ性能がでます、チューンに何年かかければ」じゃなくて
「性能はそこそこですが、チューンしなくても最高性能に近い性能が出ます」にしてくれ。
誰もPS2の性能を使い切ったソフトなんぞ作りたくないよ。

ところで
ゲームプログラミング相談室【Part5】
の次スレはどこ？

しかし、GCじゃソフト売れないしなー。

技術開発は重要だが、それが出来る余裕があるところがどれだけあるか…という話じゃ？

いや、元々はマルチプラットフォームでC#よりJavaって話。
で、PS2やGCから言うと、C++以外ありえない。
そもそもC#は永久に論外だけどな。
ただ、ライブラリレベルではマルチというか同じ言語であると事は重要。
あと、今、安定期っていっても、ハードメーカーに近い所なら、
次世代機の開発考えなきゃ駄目だろ。
とりあえず、旧世代機で作って、次世代機の開発環境が
上がってきたら移植するとかよくあるしな。
それを考えると、現在のプラットフォームは、
PS2/PS3/PSP/GBA/GBA2/NDS/GC/GC2/PC
こんだけあるわけだ。
まあ、どっちにしろC++しかないわけだが。

うん、C#やJavaにおける「マルチプラットフォーム」の話が、いつの間にかPS2やGCなどの
機種ごとのマルチの話とごっちゃになってて、なんか変だと思った。
元は言語の話なんだから、現在コンシューマやるならC++一択だと思うけど。
「なんでC#にしないんだ」と言われても、無理言うなって感じですね。

だよな。
しかも、ハードの機能を限界まで引き出すためにマルチ不要とか
前時代的な事いわれてもなって感じです。

最近はマルチプラットフォームよりもマルチランゲージな方が重視されるんじゃないのか？
PS2でいかに短期間で海外バージョンを出すのかが重要。
ようは、日本の終わってる市場から脱却し、いかに海外で売れる製品を作るか。

おまいら、そのへんの”海外版への移植性”はどうやってる？
メッセージとかNTSC/PALで表示領域かわったりとか。

>>152
表示物買えて、画面更新時間と音楽が同期してるものは調整してたなぁ。
ゲーム自体はそのまま未調整で出してたよ。オレんとこは。
あんまプログラム技術は影響しない部分だと思われ。特に３Ｄでフレーム
レート可変で対応してるならば。

でも描画アップデートでゲーム処理してる奴が必ずいるんだよな。

でも、2Dのパタパタアニメなんかだと、データ作成の段階でフレームレート固定でやってたりするから
可変フレームレートになると動きがぎこちなくなるというケースはありうるな。

>>155
だからゲーム部分はスローがちょっとかかっちゃうけどそのままで出してたよ。
２Ｄのやつは。

どうしても気になるものだけ調整だな。

>>155
> あんまプログラム技術は影響しない部分だと思われ。
3D でもリアルタイムに生成したポリゴンを使ってると、意外とハマる。
たとえばエフェクトを出すときに

1. キャラクタの前フレームの肩位置、肘位置
2. キャラクタの今フレームの肩位置、肘位置

をつないで四角形を作ってるような場合、フレームレートが下がると
四角形が細くなったりさ。見た目だけならともかく、ヒット判定も
同じような形で取ってるとバランスが変わってしまうし。

まぁ、ほら、俺って天才プログラマだからさ。
秀才プログラマのOOして合理化を図ってみるという小物の神経を
理解できないわけよ。
頭わりぃーから、整理せずには、像を把握することができねーんだろ？

だせーな。

おまえらみたいな秀才的小物では、俺のような大器のこなす仕事に
ついてこれないどころか、俺にとって摩擦でしかないわけよ。

ぶはははははは。

何か変なのがきたね。

158
みたいなのは確かに摩擦ですね

テスト

>>158
http://www.google.co.jp/search?q=%E2%97%86TAPy3blMsc&hl=ja&lr=&ie=UTF-8&oe=UTF-8&c2coff=1&start=0&sa=N

荒らし用なのね

C++マンセー
OOマンセー
仮想関数マンセー でも手当たりしだい仮想関数にしないでください。お願いします。inline化出来ないんですよ堪忍してください。
template(ライブラリ含む)マンセー
operatorマンセー つかoperator newオーバーライドできない言語は用なしです。
perl pythonマンセー 補助的に使うツールをちんたらC/C++で書いてる奴死んでください。
PS2のピーク性能重視もマンセー DMAマンセー でももうちょっとキャッシュミスペナルティの低いメモリが乗ってくれるとさらにイイネ(SPあるけどね)
な俺は結構少数派？結構多いと思うんだけど。
ちなみに Vertex/PixelShaderは結構好きです。GCは触ったこと無いのでワカンネ。1TRAMは少しよだれが出る。

すまん
s/オーバーライド/オーバーロード/
逝って来る。

あーでのDはいいかも知れんね。がんばれD。ちと語感が悪い気がするけど。

>>164
普通の人

このスレは、すでに氏んでるのかな？

> 仮想関数マンセー でも手当たりしだい仮想関数にしないでください。お願いします。inline化出来ないんですよ堪忍してください。
仮想関数でも、呼び出し時にクラスが確定していれば（参照やポインタを
介して呼んでなければ）インライン化できるぞ。

DMA は転送方向の切り替えができればもっと便利なんだけどね
転送方向を切り替えるごときでCPUが介入しなきゃならないのは最低だ
てゆうか、データと転送方法コマンドは分離しろって感じ
なぜにあんなにグダグダな仕様にしますか？
ついでにDMAコントローラはDSPモドキにして、プログラマブルにしておけばいいのに

マイクロモードとマクロモードについて語るスレとかないの？
ネタはすでに一通りでてるだろうし、そういうのぶっちゃけて話せないかね？

>>170
話せば？　俺は止めないぞ。

クリリンのことかー

　　　　　　　　　　　　　　 _.. ..‐::´／
　　　　　　　　　　　　　_/::::::::::::/
　　　　　　　　　　　＿/:::::::::::::/　＿＿＿_
　　　　　　　　 ,..::::´:::::::::::::::::::::￣:::::::::::._／
　　　　　　　／:::::::::::::::::|　ヽ､:::::;::::::::::::／
　　　　　　 /:::::::::::::::::::::|´|ヽ　　　|/_:::.::／
　　_ .. -─':::::::::::::::､::|｀'　 　,　　　.!::∠
　　｀''　‐-.._:::::::;-‐､｀（●）　　（●）　|::::｀::-､オッス！　オラ、ゲＰＧ！
　=ﾆ二::::::::::::::::|６ 　 　＼＿＿_／､｜　-──｀ ネタ切れでスレがやべえ状態だってのに
　　　　‐=.二;;;;;｀‐ｔ　　 　＼／　　ノ　　　　　　　なんだかすっげえワクワクしてきたぞ

ところで、プロジェクトの管理って皆さんどうやってます？
ディレクターが進捗から何から管理してますか。それとも、ＰＭっぽい人がいたりします？
もし「俺んとこはこうしてる」みたいなのがあれば、教えてください。

>>174
司会気取ってねーでお舞いがまず煽り入れるんだろうが、このｸｿｺﾃが

>>175
だからキミのほうがよっぽど鬱陶しいって。

>>174
つーか、人にもの聞くんなら、
「自分のところはこうやってる」ぐらいは言ってけよ。

＃だいたいＰＭとディレクターなんて「いるだけ」って意味じゃなにも変わらねーだろ。

うーむ、ネタ切れっぽいから振ってみたつもりだけど、煽りしか食いつかないのか…。
残念だ。

>>178
とりあえずこのような過疎スレにも、常時監視している人間
がいると分かっただけでも喜ぶべきでは？

クレクレ文章じゃネタにならないと思うよ。
ネタ提供ならちゃんと「ネタ」になるレスしないと…

もしくは名無しで書き込めば少しは盛り上がったかも？

まともなネタを振る能力が無いのに、無理矢理書き込んでも、
＞煽りしか食いつかない
のは当然の結果。

要するに誰も自分から話はしたがらないが、他人は叩きたいんだよな。このスレ。昔からそうだ。

コテハン叩きとゲームプログラミング Rev 3.0.0

sonet君の一件以来、この板は少しはマトモになったと思ったのに
また叩きしか出来ない奴が沸いてきた。元の木阿弥だな

２週間もスレほったらかしにしてるくせに、誰かが何かを言うと袋叩きにする。
そんな性格の捻じ曲がった奴らばっかり。

Class A
{
protected:
A(){}
public:
virtual void func() = 0;
protected:
int x;
};
Class B : public A
{
public:
virtual void func(){
　x = 1;
}
};
Class C : public A
{
public:
virtual void func(){
　x = 2;
}
};

int main()
{
B b;
b.func();// b.x = 1;になる？
}
この場合、b.funcはインライン化されるのかな？VCの場合

int main()
{
A *pA = new B;

pA->func();
}
この場合はインライン化されそうにないけど。。。

>>186-187
VC++6.0

; 37 : B b;
; 38 : b.func();// b.x = 1;になる？
; 39 :
; 40 : C c;
; 41 : C* pc= &c;
; 42 : pc->func();// pc->x = 2;になる？

leaecx, DWORD PTR _c$[esp+8]
movDWORD PTR _c$[esp+8], OFFSET FLAT:??_7C@@6B@ ; C::`vftable'
callDWORD PTR ??_7C@@6B@; C::`vftable'

; 43 :
; 44 : return b.getX() + pc->getX();

moveax, DWORD PTR _c$[esp+12]
inceax

http://updown.coolnavi.com/down/file37807.swf
http://updown.coolnavi.com/down/file37808.swf
http://updown.coolnavi.com/down/file37809.swf
http://updown.coolnavi.com/down/file37810.swf
http://updown.coolnavi.com/down/file37811.swf
http://updown.coolnavi.com/down/file37812.swf
http://updown.coolnavi.com/down/file37813.swf

【ゴールデンレス】
このレスを見た人はコピペでもいいので
10分以内に3つのスレへ貼り付けてください。
そうすれば１４日後好きな人から告白されるわ宝くじは当たるわ
出世しまくるわ体の悪い所全部治るわでえらい事です

(ﾟдﾟ)＜�i�g�f�`�b�e�f�k�n�n�k�i�c�c�n�b�m�n�n�_�k�f�b�`�`�n�_�b�`
�b�`�h�b�a�`�_�k�j�g�e�d�c�f�h�k�l�`�c�g�c�d�j�l�n�k�g�d�b�g�i�n
�_�m�j�g�a�`�j�l�n�i�g�f�e�d�c�a�`�j�i�g�f�`�b�e�f�k�n�n�k�i�c�c
�n�b�m�n�n�_�k�f�b�`�`�n�_�b�`�h�b�a�`�_�k�j�g�e�d�c�f�h�k�l�`�c
�g�c�d�j�l�n�k�g�d�b�g�i�n�_�m�j�g�a�`�j�l�n�i�g�f�e�d�c�a�`�j�i
�g�f�`�b�e�f�k�n�n�k�i�c�c�n�b�m�n�n�_�k�f�b�`�`�n�_�b�`�h�b�a�`
�_�k�j�g�e�d�c�f�h�k�l�`�c�g�c�d�j�l�n�k�g�d�b�g�i�n�_�m�j�g�a�`
�j�l�n�i�g�f�e�d�c�a�`�`�h�b�a�`�_�k�j�g�e�d�c�f�h�k�l�`�c�g�c�d
�j�l�n�k�g�d�b�g�i�n�_�m�j�g�a�`�j�l�n�i�g�f�e�d�c�a�`�j�i�f�`�b

>>185
出る杭打っとかないと、仕事なくなるからでしょ？
少なくともOO出来るやつは刈っとかないと、って魂胆が見え見え

2chの書き込みごときで、世の中の仕事の割合が変化すると思っている、
>>192の脳内世界は、相当小さそうだ。

>>191
ネクロノミコン確認

最適化かけてアセンブラソース吐き出しも出来ないやつが
なにをかたるって？

>>192 OOできる奴＝出る杭って思考回路がもぅ、ｱｲﾀﾀﾀ…
つーか、OO理解出来ませんなんて奴は、既にこの業界にいないだろ。

>>196
>既にこの業界にいないだろ
｡･ﾟ･(ﾉД`)･ﾟ･｡

OO自体の理解とOOの実践は別次元だけどな

>>174の場合は叩かれてもしょうがないんじゃないの。
まったく何も知らないで質問してるならともかく、
自分（ら）なりの答えを持っているような口ぶりじゃないか。
>>177の言うとおりだろ。

あとはネタが無くて飢えてるところで
ギブアンドテイクを無視して自分だけ搾取したいような
スタイルは反感買って当然。

という風に、お互い牽制しあって何も話が進まないわけだ。

なんか見覚えあると思ったら、>>175は>>15のコピペだったのかよ。
進歩しない人だねぇ。

とむは駄目だな。

http://chanpu2.hp.infoseek.co.jp/

で、他人が何か言うとすぐさま叩いて終了と。
お前らこのスレいて楽しいか？
なんのためにいるんだ？

で、結局>>198みたいな奴も、自分からはネタは振らない。他の奴のネタに文句言うだけ。
それじゃお前もギブアンドテイクを無視して自分だけ搾取してるのと変わらんだろ。

先に書いておくが、俺もこんなスレでネタ振る気はないから、同類だ。
中途半端な知識で人を叩くのは楽しいしな。

>>204
いや>>174はネタがどうこう以前に単純にむかつくから相手にしなくていいだろ。

>>206
キミみたいなのも見ててよっぽどむかつくんだが。自覚してないでしょ。

俺も話振ろうと思ったが、自信がない。
だから俺も叩く側に回ります。
誰がどんな話を振ろうと徹底的に叩いてけなします。よろしく。

能動的にくれくれ言うのとただ様子を見てるの、
質は変わらないかもしれないが心象はまったく違うだろ

>>209
アホかてめえは！
何くだらねえレスしてんだ！
帰れヴォケ！！

ふふっ　さっそく　ばとうことばをつかっているな
そうやって　ひとびとのこえから　みみをそむけるのだ

みかた同士で殴り合ってると思ったらそういう訳だったのか・・・

いまのばとうをわすれるな！

喧嘩は表でやってくれ

馬騰？

ところで、プロジェクトの管理って皆さんどうやってます？
ディレクターが進捗から何から管理してますか。それとも、ＰＭっぽい人がいたりします？
もし「俺んとこはこうしてる」みたいなのがあれば、教えてください。

そもそもこの手の話が難しいのは
このスレの人間の環境が違いすぎるからだと思うな。

例えば会社でゲームを作ってる場合はディレクターがいるだろうが
同人で作ってる場合はディレクターがいない場合も多いだろう

>>216
なんで自分のことを言わずに他人のこと聞き出そうとするの？
人としてコミュニケーション能力欠如してるんじゃない？

ちなみに俺のところじゃディレクターは毎日遊んでて状況なんて把握してないし、
ＰＭなんか会社にこないよ。
進捗なんて各部門ごとの長が勝手にやってるよ。
プログラマだったらメインプログラマーだな。
ほら、話したぞ。聞きたかったんだろ。

で、お前のところはどうなんだよ。

ディレクターって他と兼任してない？
遊んでるってあれえねーーー

そういう話は、こっち↓で聞いたほうが盛り上がると思うよ。

ゲームプログラマーの人に聞きたい 2問目
http://pc.2ch.net/test/read.cgi/prog/1078293745/

ここだとすれ違いっぽいような気がするし。

＞なんで自分のことを言わずに他人のこと聞き出そうとするの？
別にそんなのどうだっていいだろ。

話題を振るときは、「自分はこうなんですが皆さんはどうでしょう」という提起の仕方をしないと、
話が発展する機会が失われやすくなる。
リアルでも一方的に質問するだけの奴は敬遠されるし、その逆もまた然り。
ただそれだけの話。

プログラミング能力以前に会話の能力が必要だな

つーか2chなんて「お前ら教えろ」系のスレがうじゃうじゃ立ってるだろ。
いちいち細かいこと言うくらいなら流せよ。

>>224
はぁ？くだらねぇ質問かましてボコボコに叩かれてるスレだって多いだろ？
いちいち細かいこというくらいなら流せよｗ

お前らの、どんな話だろうがけなして叩いて煽り合いに持ち込む才能は素晴らしいと思う。

>>226
>お前らの、どんな話だろうがけなして叩いて煽り合いに持ち込む才能は素晴らしいと思う。

「泥中の蓮華」という言葉をご存知ないか？








・・・しかし、実際に咲いたのは蓮華では無く、蓮コラだったという罠。

ええい、やめんか。思い出したじゃないか。

良スレになる可能性はあると思うんだけどな。
なぜこんな風になってしまったのか。

単にネタ切れでしょ

ム板から分裂したときにすでに終わってたんだよ

隔離板だもんな、ここ

一定期間、どんな馬鹿な相手も罵倒しない、罵倒されても相手にしないってルールで
話を進めれば、自然に良スレになるんじゃね？
とりあえず400くらいまで、賛同者は発言を

『【罵倒しない】【相手にしない】運動参加中』

で囲んで話をしないか？

『【罵倒しない】【相手にしない】運動参加中』

こんな感じで、
とりあえず＞400くらいまで。
150レスくらいの間に進展なければそれまでのスレだったという事で。
どうでしょうか？

『【罵倒しない】【相手にしない】運動参加中』

>>234
罵倒と反論の境目は何処？

罵倒は名前欄に「罵倒中」と書くのはどうか？
こっちの方が、ローカルであぼーんしやすいし

なんか逆転裁判みたいだが。

いちいち叩かれるの怖いのなんの言ってないで
ログから既出の話題でもピックアップしてきて馬鹿っぽく釣りレスかいてみれ

つーか、叩かれると痛いようなエゴまるだしの発言しかできないような
頭の悪い人達しかいないんじゃな。話題ふったって知れてるだろ
テメーのくだらねぇ感想しかでてこねんだから

罵倒中だそうです。

やっぱゲーム業界の人間って、デキ悪いのかな？
２chでもここまで壊れてるとこ、ないし。

たたきたい「お年頃」の人が多いんです。
そういえば、前に罵倒することで仕事のストレスを解消してる
って宣言してた人も居たな。

ストレス解消にはバット振る。
これ最強。

最近スレの雰囲気がどうこう口出ししてるのは中学生か高校生か大学生か？
業界人のありがたいお言葉がききたいならスレがダメだダメだいってないで
煽れ。釣りレスしろ。バカっぽくな。そういう作文能力もないんなら
こんなとこ見てないで本でも読んでろ。ミジンコが。

ていうか、質問にしても、話題を振るにしても、まず自分の状況を言え。
質問なら
「目標はこれで、自分はここまでやって、これがうまくいきません。」
が必要だし、
話題を振るなら
「自分がこういうことをしたときに、こんな問題がありました。
　そのときは自分はこうやって対処しましたが、みなさんはどうしていますでしょうか。」
等など、まず自分の状況を相手にわかるように説明してから話を始めろ。
これをキチンと説明しないと煽りという形でしかレスがつかないぞ。

会社で仕事をするとわかるが、ＰＧは自分のことを説明しないで相手に理解を求めようとする奴が
多すぎる「説明しなくても、素でわかれよ！」みたいな奴。
結論からいうと「わかるわけない」。

>>245
時間足りないからな。全部説明しておまえが理解できたころにはおまえがプログラマになってる。

こんなところに書き込む暇があるのなら、じゅうぶん時間がある。
足りないのではなく、使い方が下手なだけ。

そうか！ここは罵倒とゲームプログラミングスレだったんだ！
○○＝罵倒

その割にはゲームプログラミングの話題が少ないな。

じゃあとりあえずみんな自分の事かたれや。
俺は今ちょっと遅い晩飯食ってる。
以上。

俺は飲んで帰ってきた、以上

俺は今更ながらババネロ食ってる
以上

>>251
護符を持ってきたので『＜』下さい。

ほらよ　　（ ･∀･）つﾐ　＜

ようはあれだ、スレタイにOO（オブジェクト指向）がつかなくなったせいで廃れたわけだ。
最近とむもこねーし。

>>254
あいつはいらねーよｗ
ＯＯわかってなかったしｗ
でも、そろそろ理解してリベンジにくるかなｗ

↑こういう奴こそ要らない。

>>256
よう、とむ、久しぶりｗ

そもそも○○(まるまる)って付けたのがとむだってことがわかってねーようだな。
>>1と>>6、プロクシまで使ってご苦労なこった。

>>254
時々見てるけどね。
なんかね。
アレだよね。

なにいってんだとむ
どっかのクソコテがアレなことするからアレなんじゃないか
アレ気取ってないで少しはアレしたらどうなんんだ

コテハンが出てくるたび切れてる奴がうざい。
お前はコテハンにレイプされた過去でもあるのか？

コテハンうざいって言ってる奴がうざいって言ってる奴もうざい。

以下ループネタ禁止。

俺はこれまで一度も「うざい」などとガキがやるような無意味な不快感の表明をしたことはない
ただ最初は俺ひとりだったはずが、最近叩いてる奴が一人増えたみたいだ。
こっちは頭があんまりよくなさそうだな。

午後は○○ゲームプログラミング♪

おまいらのためのスクリプトです。活用してください。

<?php
print("コテハン");
for($i=0;$i<1000;$i++)
{
print("うざいって言ってる奴が");
}
print("うざいって言ってる奴もうざい。");
?>

>>266
凄く便利ですね

>>264
うざっ

凄く便利って言う奴が便利

じゃあここいらで

FC版サンサーラナーガとゲームプログラミング

いってみようか！
まずね、くそ。
いけね、おわっちゃった。

技術と関係ない雑談とゲームプログラミング Rev 3.0.0

>>270
牛、なにもわからずレーザー光線で牛を殺しまくるゲームと認識した。
街から出ると死がまってるｗ

GBAとOO(C++)とか。
あのメモリでSTLを使うのは、やっぱ無謀か…

議論とかしてねーで
○ender○are
のヘッダうｐとか

>>273
なんでカスタムアロケータ書かないの？

カスタムアロケータ書けば問題ないのかな？
というか、試してないです！ごめんなさい。
先行の実例があれば参考にしたいな、と。

前略
#ifndef RWCORE_H
#define RWCORE_H
中略
#endif /* RWCORE_H */

>>273
木になる
全部、動的確保なしでやんのもうやだ

最近のC++の方向性ってどう思う？
ジェネリックプログラミングって無駄にテクニカルになっているだけで
再利用性はともかく、書いたやつ以外理解できないコードになりがちな気がする・・・

うちじゃメインＰＧがテンプレートを駆使してゴリゴリ書いてて、
とりあえず動くんだけどその部分は本人しか理解できないから保守できないとか、
そういうチトやヴぁい状況になってきてるんですけど・・・
なんか、可読性という面だけ見るとアセンブラで開発してた頃みたいだ。
＃ちなみにメインの人はやねうらおとModernC++Designをこよなく愛しているようでつ・・・

こういう状況ってうちだけ？おまいらの所はチーム全員がC++完全に理解してる？

>こういう状況ってうちだけ？
>おまいらの所はチーム全員がC++完全に理解してる？

ウチのメインPGは、
C++そのものに関する理解度は卓越してるかもしれないけど
STLや標準ライブラリは控えめにしろだの、継承は控えろだの
意味不明なコスト感覚の持ち主で疲れる。
だったら素直にC言語にしろよとｗ

その癖、妙で半端な仕様のへんてこmapだのへぼへぼvector
をテンプレートで自作っては、その使用を推薦する。

かんべんしてくれよ、オヤジ。

>>279
>ジェネリックプログラミングって無駄にテクニカルになっているだけで
>再利用性はともかく、書いたやつ以外理解できないコードになりがちな気がする・・・
これは確かにある。
もう、オブジェクト指向がどっかいっちゃって
やたら難解なコードになってるだけで大した効果が得られなくなっているのも特徴だと思う。

関数内無名関数とかクロージャとかあればもう少しすっきりするのにね、とか。

昔：アセンブラでゴリゴリ書かれてて書いた奴以外理解不能。
ちょい前：Ｃでポインタとキャストとマクロを駆使してゴリゴリ（ｒｙ
現在：C++でテンプレートを駆使してゴリゴリ（ｒｙ

ようは、ゲームじゃ再利用性なんて考えてる奴はいないってことでＦＡ？

>>280
そーゆーあきらかにアレなのはどうしたもんだろうね。

「べたで作る」という行為がありまして、とりあえずその場で動くものを作る
再利用は考えない。

でも、次にあるかもしれない....で関数化＞ライブラリ化＞クラス化と
いろいろ考えるうちに回り道がはじまる。

回り道が回り道を誘発しコードがかえって複雑化する。

>283
禿同

テンプレートに凝るバカはアセンブラに凝るバカと同じ匂いがしますので、近寄りたくありません。
つーん

再利用、拡張を考えないのはアフォ

コードが理解不能かどうかと再利用性は関係ないぞ
再利用できないのはインターフェースの問題でしょ

JavaやC++のクラスって、サブクラスを作ると
スーパーのprivateじゃないメソッドが全て使用可能になるよね？
これって、100個のメソッドを持つクラスから100個のメソッドを持つサブを作ると
計200個のメソッドになって激しくウザい状況になるし、
サブで制限出来るようになるとわかりやすくなると思わね？
仮想クラスなんて最大公約数的仕様になってる訳で、大概上のようなウザい様相になる。

最大公約数とはおもしろい捉えかたをするなぁ
そんなこと考えたこともなかったよ

そういう時は継承じゃなくて委譲でやるんじゃないの？

てーか、100個もメソッド持つクラスを作るなよ。

>>289
privateやprotectedで継承してusingでpublicに移せばいいじゃないか

アフォか再利用のためのテンプレートだろが
だいたいジェネリックとOOは全然関係ない

ジェネリックは関数型言語からだね。
Haskellとか見れば、C++がテンプレートでものすごく汚く解決していることを
普通に(かつ高度に)実現しているのが分かると思うよ。
そのかわり所謂高級アセンブラ的な部分がほとんどなくなってるわけだけど。

この辺が参考になるかな
http://www.radiumsoftware.com/0305.html#030516

関数型言語でプログラムしたくてもコンシューマだと環境がねーよ
結局、C++でごりごりやるしかないわけだが
いつになっても所詮は組み込み系だよ

C++はプログラマーが職を失わない為という理由で
無駄に難しく作られたプログラムだとは本当だろうか？

んなアホな

>>298
ストラウストラップの偽インタビューとかに書いてあったね。

「奥が深い症候群」だね。
何でも使えるようにするから、読みやすさも考えずになんにでも使っちゃう
人が出てくるんだ。しかも、何か高度なことをしているような気にさせて
くれるのが、そういうのを加速しちゃう原因か。

>>288
コードの再利用性と可読性は一見無関係に思えて
実は非常に重要な関連があると思うぞ。

そもそも再利用性とは何の（誰の）ためのものか？って事を考えると、
チーム開発などで"自分以外の誰か"がコードを使いまわすことで
新たに書き起こす手間を省きましょうというのが本来の目的だと思う。

しかも、その"誰か"が自分と同等以上の能力を持っている保証は無く、
再利用したコードのデバッグは自分以外の奴がやる事になるかもしれないし、
そもそもコードが再利用されるときに自分はその場にいないかもしれない。

そのコードが本当に"再利用可能"であると言うのなら、運用面から見た再利用性も
考えた実装方法を追求する必要があると思う。

開発効率の向上を目指すのならば、単なる技術屋の自己満足ではなく
多くの人に理解でき、デバッグもしやすい書き方をするということは重要だと思う。

そりゃ、自分だけが使いつづける分にはトコトンやっても良いんだろうけど、
テンプレートバリバリのテクニカルオナニーライブラリなんて
誰も引き継げなくて１から作り直すってことも多いので…

メインメモリが64KBしかないんですよ。下っ端にはそれがわからんのです。

>>288
激しく賛成、再利用が出来ないプログラマのコードは必ずと言って良いほどインターフェイスの重要性を軽視している
実装に対してプログラムをするな、インターフェイスに対してプログラムせよというオブジェクト指向の基本中の基本ができない無い事が多いと思う。
これがキチンと出来ていれば、実装コードは多少汚くても、交換するのが簡単なのだが
いくらコードを丁寧に書いても、この部分がおざなりになっているコードは煮ても焼いても食えないものになる。
テンプレート以前の問題なんだよな。

>>304
基本的には>>288と>>304の言いたい事はわかるし同意するんだけど・・・

>これがキチンと出来ていれば、実装コードは多少汚くても、交換するのが簡単なのだが
それは交換が可能なメンツが集まってる場合の話だと思うが・・・
自分がいなくなったら他の奴にそのコードを再利用してもらえるかってこと。
コードを読んで理解できなきゃ再利用したくないよね。

たしかにインターフェースのデザインがしっかりしてれば交換は可能かもしれないけど
交換するって事は、インターフェースはそのままアルゴリズムの部分を書き直すってことでしょ？
そういう状況で「コードの再利用が出来てる」と言って良いのかは疑問だな。

なんか意味不明な文章になっちまった。
簡単に言うと、
どんなに再利用性を考えたデザインのコードでも
自分以外のプログラマが、一見して理解するのに時間がかかると感じるようなものだと
「このコードを追っかけてバグを見つけるぐらいなら自分で書いちゃえ」
って考えてしまう奴が多いので、なるべく理解しやすいレベルのコードを書くべき。
・・・ってことです。

＞「このコードを追っかけてバグを見つけるぐらいなら自分で書いちゃえ」
それは実績によるんじゃないの？

>>305
やめる前にはドキュメントを残してもらえばいいんじゃないかな。
ソースコードなんてどんなに綺麗に書いた所で、作るより読むほうが三倍手間がかかる訳で、
インターフェイスを見て分らないものは、ソースコードをいじろうなんてあまり考えないですね。
この辺りはまあ趣味の問題としても、オブジェクト指向ではインターフェイスを手抜きすると設計が崩壊する、
肉を切らせず骨を断たれては堪らないと思うので。
ソースコードを丁寧にと言っていたら、いつの間にか重箱の隅を突付いていたなどと言う事が無いように自分に言い聞かせてます。
時々見かけます、やたらに神経質なんだけど本質を突いていないので、メチャクチャになっている人を。(こういう人がいるとチーム内の士気がやたら落ちて迷惑なんですよね)
そんな風な人にだけは成りたくないものです。

テンプレートばかり使う自己満足ダメプログラマと
テンプレートも使う実力派プログラマの両方を見たことがある

テンプレート使ってるからはなから読めないダメだって言ってる
人は勉強が足りない怠け者じゃないかな

>>309
｜　　 ≡　('A` )
│　≡　〜( 〜)
↓　　≡ 　ノ ノ

「日本」のプログラムの仕事は
凡庸な人間が１０人でやる仕事が一番多い。

>テンプレート使ってるからはなから読めないダメだって言ってる
だれもそんな事言ってなさげ

>>309
ほっとけばよいのです
テンプレートばかり使う自己満足を通過しなけりゃテンプレートも使う実力派プログラマにはなれない訳だし。
オブジェクト指向の出立ちの頃もオブジェクトが読めないからダメだという人間はいくらでも居たし。

>>313
いや、そもそもテンプレー厨はＯＯの本質を見抜けず、
とりあえず使い方だけわかるテンプレートで技巧を凝らしてしまうところに問題がある。
テンプレー厨は自分がテンプレー厨であることに気づけない。

>>314
別に構わないと思うけど、始めなければ始まらないし。
それにtemplateを使うならオブジェクト指向にこだわっていると視野が狭くなり過ぎる。
template は行き着くところまで行き着けばプログラミングではなくメタプログラミング
本質的にはプログラムを生成するプログラムでオブジェクト指向は
通常のプログラムでのデータ構造の設計的位置づけになる。
データ構造の設計は重要だからオブジェクト指向は無視できないが、
だからといって操作対象はオブジェクト指向である必要性もないだろう。
たとえば効率的なコードを書きたいが難解だから、
記述内容とは違うコードをそこに書き出して記述内容は
意味的に簡単になるようにやってみようとかね。
Gems にもあったよな気がする。
ゲームに特化しないならboostなどはネタの宝庫だろう。

>>308
下手なソース書く香具師のドキュメントは、
ソース以上に危険な罠。
下手ソースを読む能力もプログラム能力の一部で、
経験等による能力差が大きい罠。

しかし、テンプレばかり使うテンプレ厨なんて見たことないな。
テンプレなんてSTLとBoostとあと汎用的な所に自前テンプレ使うぐらいが
ほとんどじゃ？
Lokiばりのコードを自作して使いまくってる香具師とかいるのか？

>>316
>しかし、テンプレばかり使うテンプレ厨なんて見たことないな。
やねうらおのことかと思たよｗ

>>314
だからテンプレートによるジェネリックプログラミングと
オブジェクト指向プログラミングは
まったく別のプログラミングパラダイムなんだって
STLの設計者はJavaが嫌いだと
RadiumSoftwareに書いてあった

>>316
いやはや、ちとキチガイ神経症ヤロウにグチグチやられていて、
発言煽り気味だったかな

＞STLの設計者はJavaが嫌いだと
＞RadiumSoftwareに書いてあった
Java好きの俺がSTLの関数オブジェクトを多用するコードに
馴染めない理由が分かった気がする。

>320
Java好きなら、Java+Jakarta Velocity　でも
ジェネリックプログラミングは可能なんじゃないか？

とたいして知りもしないのに言い放つﾃｽﾄﾌｧｰｽﾄ。

Javaも1.5からGenericsが導入されるね。
http://objectclub.esm.co.jp/JavaGenerics/
http://www.mamezou.com/tec/Tips/javaGenericsVsCppTemplate/article2.html

C++のとはだいぶ違うみたいだけど。

なかなかよさげだけど・・・
やっぱりジェネリックプログラミングが今後の流れになっていくのかな
構造化→オブジェクト指向→ジェネリック
みたいな。

ちと、真面目に勉強してみるか・・・・鬱

ジェネリックプログラミングの解説って、どれもやたら小難しくない？
いい解説ってないかなぁ

boostのページに書いてあるけど要はコレだけ。
>ジェネリックプログラミングはソフトウェアコンポーネントを汎用化すること であり、
>それによってコンポーネントが多様な状況下で簡単に再利用できるよう になります。

で、コレを実現するための「(C++の)技法」が一杯あるわけだけど、普通にゲーム作ってる限り
boostとかの成果の一部を使えればいいんであって、そういう技法を真面目に追求なんてべつに
しなくてもいいではないかな？
へたに「技法」を使ってしまうと、糞コード量産してテンプレ厨とか言われかねない罠。

マクロ使って逃げるしかないのかな？
と思ったらテンプレートでできないか検討する
ぐらいでちょうどいいと思われ

復帰age

ところで、STLって使えるけど使えないと思いませんか？
vectorの場合、100要素しかないかもしれないし、１万要素になっちゃう
かもしれないvectorで、reserveしとくのもなんかダサいし、かといって
要素を追加すると1万要素もmemcpyなんて事態も恐ろしい。
かといって、listもmapもsetもなんかヒープに１万個の要素のメモリ断片
を作るかと思うと恐ろしい。
なんて事を考えるとSTLを使ってしまうけど使いにくいです。
iteratorもキモイですね。[]オペレーターもキモイです。
かといってキモさを払拭するために、ジェネリックにする事が存在理由になっている
スパゲッティコードを読むきはおきません。それは怠惰がゆえかもしれませんが、
しかし、そこに、とてつもない不毛感、虚脱感、無益感、あらゆる世の中の無意味さを
感じてしまうのです。なんだろう、複雑さの割には効果がないっていうんでしょうか。
中途半端な理解による誤解かもしれませんが。

要するに、データの設計段階に問題があると。

>>329
というか、何のための"vector"なのかということですね。
最初っからデータ量がわかっているなら、素直にnew type[ numElements]
でいいわけですよ。
予測として余分にリザーブしてある領域を超えると、とてつもない
メモリー帯域の浪費が起こる。
この辺が美しくないでしょう？
かといって何かいい手があるかというと”？”ですけど、だったら
最初っからないほうが潔いんじゃないかって考えたりします。

＞new type[ numElements]
これでサイズ変更時に、メモリの再確保と転送をデータ型に合わせて、
一つ一つ書く方が潔いと思うのならそうすればいい。
ただしデータ設計の問題をSTLの問題にするのは本末転倒。

>>331
データ設計もクソもないでしょう？
問うている問題自体が判ってないよ。

だいたい、データ量が未知＝データ設計の問題かよ？

＞これでサイズ変更時に、メモリの再確保と転送をデータ型に合わせて、
＞一つ一つ書く方が潔いと思うのならそうすればいい。
これが読めないの？

STLはあくまでも特定のアルゴリズムで型の扱いを汎用的にするためのものであって、
メモリーサイズが変化する事に万能に対応できる魔法の道具ではない。
そんな魔法が存在しない以上は、負荷軽減を目的とする場合、
データの転送が最小限で済むように、データをグループ化したりするわけだが。

で、潔い方法とやらは、メモリの再確保に関してSTL以上に簡潔に書けるの？
ぜひ
＞new type[ numElements]
で、どうやって
＞メモリー帯域の浪費が起こる。
が回避されるメモリ再確保に対応するのか、その魔法を見せてもらいたい。

とむの口調がだんだん荒々しくなっていく過程が面白い。

条件を緩め、
＞new type[ numElements]
これは外そう。

・条件
データ設計は直は見直さず、「メモリー帯域の浪費がおこらない」、
メモリーの再確保を行うための魔法の呪文。

＞データ設計は直は見直さず、「メモリー帯域の浪費がおこらない」、
↓訂正
＞データ設計は見直さず、「メモリー帯域の浪費がおこらない」、

>>328
うーむ、こうやってオレコンテナライブラリが増えていくのだろうか…

>>328
そんなの臨機応変に使えば？だれも強制してないよ。
潔いのがいいならＣでもアセンブラでも使えばいいし
C++でもSTL使いたくなきゃ使わないで済むしね。
それなのにキモイから不要とか潔くないって意見を押し付けるのはどうかと。

>>334
>STLはあくまでも特定のアルゴリズムで型の扱いを汎用的にするためのものであって、
>メモリーサイズが変化する事に万能に対応できる魔法の道具ではない。

糞設計は、STL使いの罪。それを許してしまうのは、STLの罪。

>>334
『予測として余分にリザーブしてある領域を超えると、とてつもない
メモリー帯域の浪費が起こる。
この辺が美しくないでしょう？
かといって何かいい手があるかというと”？”ですけど』

って書いているのに、

『潔い方法とやらは、メモリの再確保に関してSTL以上に簡潔に書けるの？』

って反論するかよふつう。完全に論点をはずしているんだよね。
問題を論理的かつ的確に見極めるのもプログラマの能力のうちだよ。

>>341
そこで「本当の論点は何か？」を書かないくせに、
やたらと「論理的・的確な」という言葉を濫用するのも
プログラマの能力って奴ですか？

>>342
>プログラマの能力って奴ですか？
煽りの能力です(文章の荒れ具合を見るともしかしたら天然なのかも知れないけど)。

>>341
＞予測として余分にリザーブしてある領域を超えると、とてつもない
＞メモリー帯域の浪費が起こる。
解決方法は、
＞かといって何かいい手があるかというと”？”ですけど
そして
＞最初っからないほうが潔いんじゃないかって考えたりします。
という、とんちんかんな結論を出すと。

どうしても必要な場合に、いちいち再確保と転送を自分で書くよりは、
テンプレートを使って自動的にやってくれた方が楽でしょ？
それだけの話なのに、いったい何が言いたいのか、
＞論点
がさっぱり見えない。

これをlistに置き換えると、

listを使うと断片化が起こる。
かといって何かいい手があるかというと”？”ですけど
だったら最初から使わない方が潔いのでは？

論点はこれでOK？

論点はここでしょ。
>iteratorもキモイですね。[]オペレーターもキモイです。
>かといってキモさを払拭するために、ジェネリックにする事が存在理由になっている
>スパゲッティコードを読むきはおきません。それは怠惰がゆえかもしれませんが、

つまり愚痴が言いたいだけ、と。

>>345

>だったら最初から使わない方が潔いのでは？

そうそれを言ってんの。やっと言っている事を判ってくれたね。

リストなんかだったらさ、
typedef struct _tagWhatever
{
struct _tagWhatever* next;
struct _tagWhatever* prev;
...
public:
void insert( _tagWhatever* pElem );
void remove( _tagWhatever* pElem );
...
} whatever;
でいいわけさ。

別にSTLを否定しているわけでもないよ。
ただ、そのヒープの原理上、どうしてもSTLの利点が生ききらない
よなって愚痴っているだけ。

それを、「設計上の問題をSTLの問題に摩り替えている」とかいうから
なんなん？って思うわけよ。

>347
おまえの考えている「STLの利点」って何よ？

>>347
＞typedef struct _tagWhatever
断片化が解決されるわけでもなく、手間がかかるようにしか思えないのに、
これを型ごとに毎回書く利点は？

>断片化が解決されるわけでもなく

基本的には、そうだ（文脈的に無視しちゃっていいが、厳密には、
STLでも一要素単位でヒープ領域が割り当てられるわけじゃない）。

＞これを型ごとに毎回書く利点は？

型は関係ないよね。もし問題にするなら汎用コンテナの問題を挙げてくれよ。
templete = STLじゃないよ？わかってんのかな？

Listに限った、コンテナの再利用でいうなら、これでいいわけ。
templete < typename T >
class CList
{
CList* next;
CList* prev;

T CONTAINER;

public:
void insert(...);
void remove(...);
};
ってやりゃいい。

>>350
それでわざわざ自分で実装する利点の説明は？

>>351

＞それでわざわざ自分で実装する利点の説明は？

仕組みを理解している人間だったら、そんなの訊くまでもないでしょ。
STLはvector, list, setなどのデータ構造間の汎用性を追求している
がための複雑さとオーバーへッドがある。
って、１から１０まで書かんとわからんか？

っていうか、確かに煽り半分で書いた事は書いたが、それは
プロが出てきて有意義な話ができるかなと期待したんであって、
こんな意味のない話をしたかったわけじゃないんですが。
もうやめましょうこれ。時間の無駄です。

先生!、>>350の中に、オーバーヘッドを解決する画期的なコードが見あたりません。
お願いですから、まだ逃げないでください。

実際問題、オーバーヘッドを回避するために、
独自のアロケーターを内蔵しているSTLに、
>>350のソースで勝ち目があるようには思えない。

コードの質を落とした車輪の再発明なら、
＞もうやめましょうこれ。時間の無駄です。
確かにその通り。

ゲーム機でSTL使ってるやついるの？
ツールならがんがん使うんだが・・

先生!、コンシューマーのような限られた環境では、
データ量の上限を設定して、想定した範囲内に収めるように作ると思います。

>>347のリンクリストをおとなしく使うのが(･∀･)ｲｲ!!

>>353
ちょっとはSTLのコードを読んでからモノをいおう。

>>354
文脈考えてね。「型ごとにlistクラス」つくんのかよって言われたから、
テンプレートつかってlistコンテナをこうやって組むんだよって
サンプルを書いたんだろうが。

>>354

>独自のアロケーターを内蔵している

newオペレーターオーバーライドだろ。
そんなの実装するの当たり前じゃん。
その他、find,sort等色々なメソッドも実装するよって、こんなとこに
一々書いてられるかボケ。

あのさ、おまえら人が掲示板で具体的に説明するために
ちょろっと書いた（コピペですらないよ）サンプルコードに
いちいちうるさいんだよ。

>>357
きみとなら仕事を一緒にやっていけそうだ。

＞その他、find,sort等色々なメソッドも実装するよって、こんなとこに
つまり結局はSTL同様、複雑になるわけなんだけど、
その車輪の再発名でSTLには無いオーバーヘッドを回避する方策は？

＞newオペレーターオーバーライドだろ。
先生!、オーバーロードとオーバーライドの区別はついてますか？

>>359

>>341
をよめ。何回もﾅﾝｶｲﾓﾅﾝｶｲﾓｵﾅｼﾞｺﾞﾄｦｲﾜｾﾙﾅ。

>>360
ﾀﾏﾆﾂｶﾈｰﾝﾀﾞﾖ。っていうか、まぁ英文C++本でも"overload"になっているがだな、
"override"のほうが現象を的確に表している。"overload"は不正確だ。
英語が堪能なオレにとってはどうしても自然な方を使ってしまうんだな。

おっと、ちょっと待て。
オレのいっているオーバーヘッドは、メモリ帯域の無駄の話じゃない。
データ構造間の汎用性を持たせたことによるメソッドのオーバーヘッドの話。

>>361
つまり、
＞かといって何かいい手があるかというと”？”ですけど
何も解決しないまま、車輪の再発明だけ行うわけなのか。
それが潔いと思えるようになるのは、一生かけても難しい。

＞"override"のほうが現象を的確に表している。"overload"は不正確だ。
＞英語が堪能なオレにとってはどうしても自然な方を使ってしまうんだな。
先生!、かなり苦しいです。

馬鹿だなあお前ら、
ゲームでは再利用可能なコンテナが確かに必要だが、
STLの設計はゲームに最適ではないだけの話じゃないか

ゲーム向け俺コンテナを持ち寄って
boostに寄贈ぐらいすればこのスレも役に立ったといえるな

>>363
潔いの話題違い。
メモリバンド幅の話と、メソッドのオーバーヘッドの話がごっちゃになってるよ。
>>364
あのな、overloadとoverrideを辞書で調べてみ。
http://www.infoseek.co.jp

>>365
＞馬鹿だなあお前ら、
＞ゲームでは再利用可能なコンテナが確かに必要だが、
＞STLの設計はゲームに最適ではないだけの話じゃないか

まぁ、そういうことだな。

pc2が消える前の、生産性とかメンテナンス性とか、そんな話はどうなりましたか？

結局のところ、「メソッドのオーバーヘッド」に関しても、
何の解決方法も示めさず、言い訳で逃げ回り、
用語の誤用に関しても、素直に間違いを認めずまた言い訳。

データの汎用性のオーバーヘッドを問題にしても、
型ごとに書くのかと聞かれるとその時だけサンプルはテンプレート。
複雑さを問題にしても、機能の面を指摘されると、
STL同様の機能を実装するという。

既存のものに対して、利点は特にないけれど、とにかく自分で実装。
滅茶苦茶で突っ込みきれない。

例外投げてるの、みんな・・・。

>>368

>結局のところ、「メソッドのオーバーヘッド」に関しても、
何の解決方法も示めさず、

メモリー最配置の時に発生するメモリバンドの無駄はどうにもならないが、
「メソッドのオーバーヘッド」に関しては、
「STLはvector, list, setなどのデータ構造間の汎用性を追求している
がための複雑さとオーバーへッドがある。」って問題提起し、
ゲーム用に贅肉を削ぎ落としたバランスの取れたコンテナをちょろっと
書けばメソッドのオーバーヘッドは軽減できるっていってんだよ。


＞用語の誤用に関しても、素直に間違いを認めずまた言い訳。

Override 誤用じゃないよ。適切な英語だ。

＞利点は特にないけれど

あるよ。ゲームにとっては重要な利点だよ。
シロートとは付きあいきれん。

>>369

try catch例外うざい。
マクロで↓みたいな例外処理いれてる。
DBG_ASSERT( bool bEval, TCHAR* szMessage, UINT uErrorType );

> STLはvector, list, setなどのデータ構造間の汎用性を追求しているがための複雑さとオーバーへッド

それは興味深いですね。具体例をいただけますか？

アロケータ書いてでもSTL使えってやつは
テストプログラムとかツールとかじゃなくて
本当に商品でSTL使ってるのか？
どこ製のSTL？

>>373
STLport。設定マクロをたくさん提供してくれるのでいいと思います。
例外発生時の挙動や、メモリ管理の設定もいろいろカスタマイズできます。

>＞用語の誤用に関しても、素直に間違いを認めずまた言い訳。
>Override 誤用じゃないよ。適切な英語だ。
え？この場合オーバーライドがC++的にも正しくね？

で、オレは最適でないのは承知の上で楽だから使ってるよ(別にｷﾓｲとかどうでもいいし)。
クリティカルな部分だけ特別に最適なのを作る(ちうのは普通の最適化戦略だが)。

なので、別に愚痴りたくは無いかな。
愚痴りたいのは、STL使わせてもバグ埋め込むし、かといって普通にリスト構造とか作ら
せてバグを埋め込んでしまう新人君(に使わせるためのSTL)。

Effective STLシリーズを読まなきゃ使い物にならないのが一番大きいオーバーヘッドだｗ

ところで、STL（テンプレート）で書かれたコードのうまいデバッグ方法教えてくれ。
トレースとか非常にうざいんだけど、何か良い方法ある？

>>用語の誤用に関しても、素直に間違いを認めずまた言い訳。
>Override 誤用じゃないよ。適切な英語だ。
まぁ、君の意見は正しいと思うよ。君の世界の中ではね・・・
ｺｳﾔｯﾃSTL厨が出来上がっていくわけか。
ｱｾﾝﾌﾞﾗ厨の言ってた事とかわらんなぁ。
何かと言うと「俺が正しい」「俺は間違ってはいない」
ﾔﾚﾔﾚ棚

なんか、もう寝たほうがいいと思うよ。

>>372

なんで書き込む前に自分で調べないかな？これで最後ね。時間のムダだし。
例えば、vectorの[]オペレータ一つとっても

vector <int> vInt;
...
int& r = vInt[idx];

とやるだけで、このようにコードが実行される（読みにくいけど長すぎるので）。
まぁ自分で調べりゃ済む事だし。

reference operator[](size_type _Pos)　{ // subscript mutable sequence　
return (*(begin() + _Pos));}
iterator begin(){ // return iterator for beginning of mutable sequence
return (iterator(_Myfirst));}
iterator(pointer _Ptr) : const_iterator(_Ptr)　{ // construct with pointer _Ptr　}
const_iterator(_Tptr _Ptr)　{ // construct with pointer _Ptr
_Myptr = _Ptr;　}

iterator(pointer _Ptr): const_iterator(_Ptr)　{ // construct with pointer _Ptr　}
iterator begin()　{ // return iterator for beginning of mutable sequence
return (iterator(_Myfirst));　}
reference operator[](size_type _Pos)　{ // subscript mutable sequence
return (*(begin() + _Pos));}
iterator operator+(difference_type _Off) const　{ // return this + integer
iterator _Tmp = *this; return (_Tmp += _Off);　}
iterator& operator+=(difference_type _Off)　{ // increment by integer
this->_Myptr += _Off;　return (*this);　}
reference operator*() const　{ // return designated object
return ((reference)**(const_iterator *)this);　}
const_reference operator*() const　{ // return designated object
return (*_Myptr);　}
reference operator[](size_type _Pos)　{ // subscript mutable sequence
return (*(begin() + _Pos));　}

iterator begin()　{ // return iterator for beginning of mutable sequence
return (iterator(_Myfirst));　}
iterator(pointer _Ptr): const_iterator(_Ptr)　{ // construct with pointer _Ptr　}
const_iterator(_Tptr _Ptr)　{ // construct with pointer _Ptr
_Myptr = _Ptr;　}
iterator(pointer _Ptr)　: const_iterator(_Ptr)　{ // construct with pointer _Ptr　}
iterator begin()　{ // return iterator for beginning of mutable sequence
return (iterator(_Myfirst));　}
reference operator[](size_type _Pos)　{ // subscript mutable sequence
return (*(begin() + _Pos));　}
iterator operator+(difference_type _Off) const　{ // return this + integer
iterator _Tmp = *this;　return (_Tmp += _Off);　}
iterator& operator+=(difference_type _Off)　{ // increment by integer
this->_Myptr += _Off;　return (*this);　}
reference operator*() const　{ // return designated object
return ((reference)**(const_iterator *)this);　}
const_reference operator*() const　{ // return designated object
return (*_Myptr);　}

以上。

実際にどういうアセンブラに落ちるか確かめてみた？

>>375

>で、オレは最適でないのは承知の上で楽だから使ってるよ(別にｷﾓｲとかどうでもいいし)。
>クリティカルな部分だけ特別に最適なのを作る(ちうのは普通の最適化戦略だが)。

だね。オレもそう。STLの問題点がわかってりゃ適材適所で使いこなせるってことだな。

みんな最適化で殺ぎ落とされる部分じゃん
マルチスレッドで使うとロックコードが入るだけ。

全部インラインになって最適化されるとかなり効率的なコードになるってのが
templateの利点のひとつだしね(メタプログラミングというのか？)

STLなんかも、もろコンパイラの最適化前提。

>>382

自分で調べてみなって。上のCコードどおり最悪なことになっているから。
ちなみに普通の配列だったら4stateくらいで済む話です。

>>386
いや、調べてみていってるんだが。
最適化を掛けなきゃすごいことになったが、掛ければ配列と変わらなかったけど。
ちなみにgccの-O2で確認。

>>379
おつかれさまでした。
ちなみに、STLportのHEADでは、

reference operator[](size_type __n) { return *(begin() + __n); }
iterator begin() { return this->_M_start; }
_Tp* _M_start;

以上（@stlport/stl/_vector.h）でした。
そういうことなので、貼っていただいたモノはSTLのオーバーヘッドの具体例とはいえませんね。
おそらく、「中途半端な理解による誤解」でしょう。
STLportの使用をお勧めしますよ。

連続投稿とかいわれてかきこめねーよ。

>>385
>全部インラインになって最適化されるとかなり効率的なコードになるってのが
>templateの利点のひとつだしね(メタプログラミングというのか？)

templateの利点？実行コードの話だよね？
効率的なコードになるのはinlineの利点であって、templateとは関係ないが。
templateはむしろ、複数の実体が生まれるっていう副作用以外、コード効率への影響はない。

>>387
>掛ければ配列と変わらなかったけど。
それはありえないね。

>>388
それじゃまだ甘い。まず＋オペレーター部分が抜けてるでしょ？
そして＋オペレーターから更に続くわな。
その字面通りだったら、char型でもない限り、まともにアドレスとれないよ。
トレースしてみ、ほかにも呼ばれるものがいっぱいあるよ。
字面ほど単純じゃないのがSTL。

>>掛ければ配列と変わらなかったけど。
>それはありえないね。
・・・こいつには何を言っても無駄かと。
久々に真性のヴァカを見たよ。

>>389
あーすいません。抜けてましたね。
typedef valute_type* iterator;
typedef valute_type& reference;
ということで、続く + も * も、共に組み込み演算子ですよ。

＞その字面通りだったら、char型でもない限り、まともにアドレスとれないよ。

えっと、Cの基本が全く分かってない人ですか？

; 14 : int& r = vInt[idx];

00000a1 00 00 00 00 mov eax, DWORD PTR ?idx@@3HA ; idx
000058b 0d 04 00 00
00 mov ecx, DWORD PTR ?vInt@@3V?$vector@HV?$allocator@H@std@@@std@@A+4
0000b8d 04 81 lea eax, DWORD PTR [ecx+eax*4]

; 15 :

お前ら釣られすぎ

重要
・間違えても言い訳はせず、素直に認めることは大切。
・あり得ないと決めつける前に、自分で確かめることも大切。

双方とりあえず汗コード載せろと。

>>389
>効率的なコードになるのはinlineの利点であって、templateとは関係ないが。
型の安全性を保ちつつマクロのようなことが出来るという意味で、両方だよ。
テンプレートメタプログラミングって聞いたこと無い？
(そして、そこがC++の汚さなわけだが。。。)

>>393
そのうちシンボルの長さの分非効率って言い出すからよろしく

(((（ ;ﾟДﾟ)))ｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ

自前実装の有利さは移植したときに発揮されるよ。
おまえら知らないかもしれなが、ＳＴＬがサポートされてないＣＰＰがアルンデスヨ。

>>400
世の中には malloc も無い C コンパイラもあるが、
そこら辺、どうよ？

Cコンパイラも無い環境はどうしますか？

昔はそれが普通だった

つまり、移植性を高めるためには、Cすら使わずに書かなければならない、と。



・・・・あれ？

おいらの場合、ＳＴＬ使ってるけど、極端に使い込んでるわけではない。
list map vector 程度だし、使ってるメソッドもごく一部。
それらを網羅するだけのテンプレートなら、自作してしまったほうが
なにかトラブルがあったときに対処しやすいかも。

パチンコ系の仕事だと、メモリ少ないし、C++は使えるけどSTLは
使えないなんて環境がザラなので、自作するですよ。
ま、昨今のPS2の3Dゲーが普通な世間についていけなくてスピンアウトした
負け組みな自分の意見など参考にならんかもしれんけど。

でも、ゲーム用途で使用するSTLのメソッドなんて、やはり片手で
数えれる程度なんではないでしょうかねぇ？

標準でSTLが添付されているなら迷わずそちら使うんですけど

windows系のゲーム開発ならSTL使っても全然問題ないかな？

問題はWindowsかどうか（リソースがたくさん取れる環境か）ということじゃなくて
使う人間がどうか、どんなゲームを作るつもりなのかの方が何十倍も影響する

んなアホな。

ここ見てると、STL=テンプレートベースのコンテナ集
みたいな見方しかしてない椰子がたくさんいるような気がするのは
俺だけなのだろうか

>>409
ぜひ、そうじゃないと言う意見を教えて欲しい。
実際のところコンテナ集程度の認識でしか使えていないので・・・

STLにしても、mallocにしてもゲームじゃ普通に自前で書くだろ。
でもって、状況判断して、標準・自前・使わないを使い分ける罠。
キモいiteratorの自作は結構楽しい罠。

>>410 <iterator> <algorithm> <functional> <utility>

>>412
それらは全部コンテナと関連してる気がするが…

コンテナと関連はしてるけどコンテナ集じゃないでしょ。
ただの配列とかにも適用できるんだから。

んでもって、そこがSTLの(ジェネリックプログラミングの)一番キモいとこだな。
bind系なんて見てらんない。

コンシューマは大変ですね
プログラマさんの日記見てても、いちいちアセンブラに落として比較してたり、
よくそんなことやってるな、と
なんでもかんでも自作したり、ミイラ取りがよくミイラにならないか不思議です。

PCだと、軽くプロファイルとって大抵はそのまま終了だからなー

このスレみてると自分はなんて恵まれてるのかと思えてくるよ

>410
STLはただのコンテナ集ではない
データ構造とアルゴリズムの汎用化を実現した（正確には目指した）ライブラリと捉えるべき

>>417
でも、使いときの認識はコンテナ集なんでしょ？

>418
わかってない子だね
STLのアルゴリズムは、STLに含まれてる標準コンテナじゃなくても
自作のコンテナや、プリミティブな配列にも適用出来るんだよ

自分の考えでは
狭義のSTL： データ構造・アルゴリズムなどを含む標準「ライブラリ」
広義のSTL： 汎用的なデータ構造・アルゴリズムを使う際の「プロトコル」
ちょっと無理あるかもしれんｶﾞﾅ

>>416
俺もPCだけだけど、どんなC/C++コード書けばどんなアセンブリコードが出てくるかは
だいたい把握しとくもんだと思うけど。
>>379見てちゃんと配列同様のコードに落ちるとか予測できるくらいにはさ。

別に四六時中アセンブリ出力眺めるわけじゃなし、ちょっと地ならししとくだけで、
リーズナブルなコードを吐くC++コードを自信を持って書けるんだから。
プロファイル取って遅かったら原因は100％アルゴリズムなわけだし。

>>420

>>>379見てちゃんと配列同様のコードに落ちるとか予測できるくらいにはさ。


>>379って、オプティマイザで本当に、>>393になるの？
それはそれで凄いコードだよね。

それはいいとして、
The insertion (called inline expansion or inlining) occurs only if
the compiler's cost/benefit analysis show it to be profitable.
Inline expansion alleviates the function-call overhead at the
potential cost of larger code size.
ってあるように、コンパイラのコスト/利益 分析次第で展開もされる
こともされないこともあるってことで、完全に処理系（オプティマイザ
オプションも含め）依存だよね？
もしコンパイラがインライン展開がコストに合わないと判断すれば、
>>379になっちゃうんだよね？

まあいまどきはgcc派生だろうからそこまで心配しなくても良いとは思うがね。
ＳＴＬでダメだったら自作ってのが一番無難な流れなんだろう。

つーかＳＴＬっつーかテンプレート使えないCPPが（略

>>418
型があっていさえすれば相手はコンテナである必要はないよ

俺やお前らが、こうしたらいいのにーなんて思う最適化は
ふつーにやってくれる罠。
VC++のthiscallでは、thisポインタはECXに保持されるのだが
昔それを知らないで、「mov eax, this」と
eaxにthisポインタを持たせたプログラムを書いたことがあるが
最適化で見事にeaxが全部ecxにすげ替えられてた。

>>419
どっちにしてもそれで設計が変わることはないし
別に何が便利になるわけでもないんでしょ？
ささいな問題じゃん。

というか、STLのアルゴリズムは激しく使いにくい。
beginとendでsortするくらいならいいけどさ…。

>>424
ＭＳのコンパイラは最高峰だろ・・・。gccの10倍はがんばってる。

> >>379って、オプティマイザで本当に、>>393になるの？

疑う前に試してみなさいって。あんなもんがちゃんと最適化されないコンパイラあったら
俺はベンダに殴りこみかけるぞ。マジで。

>>428

そうかぁ。オレのは.NET Standardなもんで、オプティマイザーを
かけられない。なんかいじるとオプティマイザーをアンロック
したりできないかな？やっぱ安物買いの銭失いだったか・・・。

>やっぱ安物買いの銭失いだったか・・・。
まぁ、今のCPU性能ならよっぽど変なことやら無い限り問題ないんじゃね？
問題が出てから買い換えても遅くない罠。独自実装で最適化でもいいけど。

・・・いや、もし学生なら安いんだから買い換えとくべし。

>>429
試すだけならGCCでもいいんじゃないかと。

今時はgccも頑張ってますよ

86の最適化はかなり良い感じだよね、
大局が分らないと出来ない最適化や、
作った人間には分るがコードからは分らない種の最適化以外は
ほぼ限界までやってくれる。

それに引き換えミップスは・・・・はぅ〜

86のgccはLinuxあたりでもやらない限り使う機会はそうそうないからなぁ。
MIPS系でgccの最適化マズーとか思うのも、使ってるgccが古いせいか。

枯れたハード使ってるんだけど、メーカーのサポートも枯れてるんだよね・・・。
ライブラリリコンパイルすればちょっと速くなったりするんだろうなぁ。

Linuxならiccがあるから無理してgcc使うことも無いと思うけど

iccって86だけでしょ?

>86のgccは

サーバ移転してたんだね…。気づかなかった。

雑談スレじゃねーぞ

たいして意義があるスレでもないので案外大丈夫。

コテ叩きスレだろ？
コテが出たからとりあえず叩かないと。

　　　　　　　　　☆ ﾁﾝ　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ〜
　　　　　　　　　　　　　　　　　　　　　　　　　ﾏﾁｸﾀﾋﾞﾚﾀ〜
　　　 　 　 ☆　ﾁﾝ　　〃　 Λ＿Λ　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣
　 　 　 　 　　ヽ　＿＿_＼（＼・∀・）　＜　次の話題まだ〜？
　　 　 　 　 　 　 ＼＿／⊂　⊂＿ )　　 ＼＿＿＿＿＿＿＿＿＿＿＿＿＿
　　 　 　 　 　 ／￣￣￣￣￣￣ ／|
　　　　　　　　|￣￣￣￣￣￣￣|　 |
　　　　　　　　|　 愛媛みかん　 |／

設計とコーディングわけてるところってある？
企画レベルじゃなくて、実装レベルで。

「自分のところはこうやってる」と書かないと、物凄い叩かれるよ（笑）。
（過去ログ参照）

と冗談はともかく、私はやってませんねえ。知り合いにもやってる人はいなさそうです。
やってるところあるのかな？

〜どうやってます？
〜をやってますか？

違いが分からないのね。

やってたらやってる書くよ。やってないのは当然と思ってたんだが、伝わらないかね。

お前ら皮肉かどうか判断しろよ。

え？設計ってコーディングの後にするものじゃないの？
いや、ゲームじゃなくて業務系の話だけど。

>>443
ねーよ。

コーディングの後に来るのは仕様書だよ

そして仕様書を作るフェーズが「設計」です。

つまり、

コーディング→設計→仕様作成

という手順ですね。

ゲーム開発にちゃんとした仕様書も設計もないのは
・コロコロかわる仕様
・メンテが必要ないため詳細な文書化は要らない
・(人数的に)それほど大規模ではないプログラム
あたりが理由かな？

・・・とか言う俺は448

食いつき悪いな。大手だともうちょいマシなんだと想像して
おまいら、オレは中小の小規模開発チームプログラマーと素人ってことで。

大手でも仕様・設計・コーディング手順の逆転状況は似たようなモンだよ
むしろ中小の方がそんな余裕のある事をしていると破産するからマジになってやっていたりする。

>>453

その調子で作るからネトゲがぐだぐだになるのね。

このスレ、タイトルが面白そうでみてみたけど
ひどいインターネットで残念でした。

参ったね。

おわっとるな。
マ板のゲＰＧスレに移動したのか？

そうかもな。たいして実りがあるスレじゃないしな・・・。

プログラミングはゲームです

＝､,-､　　､ヽ､　＼>　　　,,　 '''＼　＿
メﾞヽ､＼￣"""￣--‐　　 ､ ＼　　／ゝ､＼
＝─‐＼＼‐　 ／─'''''ニ二＼''' |レﾚゝゝ､＼
￣く<<く >, ﾞ､／＜三三二＼￣＼ゝゝゝゝゝゝﾞ''ヽ､　　　　　　 　／￣￣￣￣￣
＜<<<〈__入 ﾞ､く彡三三三二ヽくゝ＼メメメゝ､＿ゝ､＼　　　　　 | クラス名を言え
くく<<<<<< ﾞ､ ﾞ､ミ三三二ニ─ゝゝゝゝゝ,,,,,,,､ '（ ﾞ''ヽ､ヽ､　　　＜ どんなクラスでもインスタンス化してやる
くくくくくく彡‐ヽ ﾞ､ﾐ三三二ニ'''くくゝゝ＿ゝゝ､＼＼＿,>」ﾉ,　　　 |
く く く く く 彡ﾞ､ﾞ､三三二ニ‐くゝ､／ ,,,,,,,,メメゝヽ''''"ゝゝﾞ丶､　　＼＿＿＿＿＿
二─二二彡彡､ﾞ､三三二==くメゝ／　　 ﾞ'ヽ､メゝゝゝゝゝゝゝﾞ''ヽ-､,,,,,,＿
‐'''"￣ ＼彡彡ﾐ､ﾞ､三二=''"く<メ/::　　AV 　　＼''-､メメゝゝゝ＿ゝ ､ ,,､ヽ
､　　,,,,-　ﾞ彡／/ヽﾞ､三二＝ くゝ/:::....　　　　　　＼>∠ﾚ-,-‐ニ二メヽ''ヽ ﾉ
　ﾞヽ､,,,-‐//_//／,,､ﾞ､三二=　　ﾞ､　""'''　　　　　　ヽ＞／／ﾚﾚヽ,,＿__　 /
-,,,,,,-‐'''"""/////,,ヽ ﾞ､三二─　ﾞヽ.　　　　　　　　 ／／-ﾍﾍ,､ ﾚレレﾚノ
''"　　　　　　,ｌ|"////ﾉ,､＼彡'''''‐-ニ,､　::::::::::,,,,,,,,／／　　　　ﾞヽﾌ/|/| ﾚ'
　　　　　　／ゝ､/ヽ|ヽﾚ,,ﾞヽ､ﾞ''ヽ､,,,,,,＿ヽ''ニ＝'',,-'"､─-,,,,,＿　　￣"'ﾉ
　　　　　/メ / ﾚ／,''"へへへﾞ''─----￣-メヽ"ゝゝﾞゝヽ､　　＞---''"
　　　　/ﾍﾍ､|／／ヘヘヘﾍﾍﾍﾍﾍ,,-イ￣　|￣"'''-ニニニ二-''"
　　　/ﾍﾍ∧/./ﾌヘﾍﾍﾍﾍﾍﾍ,／ｲ　 /　　/　　　/　　　　ﾞﾉ＼､＼
　　 /ゝゝ| / /メﾍﾍﾍﾍヘﾍ／'" |　 /　 ／　　／　　　　／　　＼＼
　 /ゝ /|‐/ /ﾌヘへﾍﾍﾍ/∧　 /-'"-'''"__,,-''"　　　　／　　　　 /､＼
　//|_|　/./へへへﾍﾍ､//　|／　　　　　　＼＿,,,,-‐'"　　　　／　 ﾞ､.ﾞ､

13 名前： 以下、名無しにかわりましてVIPがお送りします [sage] 投稿日： 2005/10