トップページ⇒gamedev
935コメント361KB

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

■ このスレッドは過去ログ倉庫に格納されています
0001名無しさん＠お腹いっぱい。01/11/07 23:55ID:HnYWCQK1
OOをどのように用いれば美しくゲームプログラミングを
行うことが出来るのか語り合うスレです。
0709名前は開発中のものです。02/02/25 20:42ID:???
>>708
ドキュメント書かないヤツは論外だが、ドキュメント過剰も良くないとは思う。プロ
ジェクトの規模が大きくなって、それこそ業務用システムのような

　数千人月

みたいな世界になると開発者間で直接コミュニケーションなんてのは不可能だか
ら、細部までドキュメント化してないと話にならないけど、

　開発者数人

という規模だと、コア部分関してはきっちりドキュメント化するのは当然としても、
細部の頻繁に変更される部分までドキュメント化しても無駄になる可能性が高
い。

細部は doxygen あたりのドキュメント作成ツールで済ませることにして、コア部
分だけきっちり資料を作るってのも、現実的な選択肢だと思うよ。

>>707
資料って OO だと UML で大雑把に書いて、そこにノートでコメントを書き込む方
が、文章で書くより分かりやすくないか？
0710名前は開発中のものです。02/02/26 03:25ID:???
＞だいたい、３〜４年たつと新ハードがでて、作ったものがかなり陳腐化するのが
＞どうしようもない原因であるよ。３ＤといってもＸ−ＢＯＸとＰＳ２とＰＳ１で
＞も別世界だし。　もうしばらくはその場しのぎを続けるしかないだろうな。
いっちゃ悪いけど、「描画系」と「アプリ系」をきっちり分別して開発する
ことに困難を感じている君は修行不足だと思う。
071171002/02/26 03:28ID:???
特に、PS2 -> X-Box への移植に困難を感じているのならば
開発時の整理整頓を真剣に考えた方がいいと思う。
0712名前は開発中のものです。02/02/28 12:39ID:ssS9vuX/
OO ってプログラムの複雑度を下げるよなぁ…って思ったんだけど、
これについての意見プリーズ。

思いつきだから自分でも確証ないんだよね。どうなんだろう？
0713名前は開発中のものです。02/02/28 20:40ID:???
>712
構造的にはそうかもしらんが
ソースコードは長くなるぞ

というよりアンチOOから怒濤の煽りが来そうなﾖｶﾝ
0714名前は開発中のものです。02/02/28 21:31ID:???
スパゲッティがほどけて独立性が上がっても、
その独立したものどうしを繋ぐのに複雑性が上がる罠。
071571202/03/01 00:34ID:???
>>713
ソースコードの長さって問題なのかな？たいした問題じゃないと思うんだけど。
みんなそんなにキーボード打つの遅いの？

>>714
なるほど、だから UML とか デザインパターンズ とかが重要になるんだね。
0716名前は開発中のものです。02/03/01 01:55ID:???
ズ
0717名前は開発中のものです。02/03/01 02:27ID:???
そうズら
0718名前は開発中のものです。02/03/01 02:48ID:???
複雑度を下げるというより上げると思うんだが
複雑なことが安全にできるようになるって感じ。
ソースコード対効果比（Ｓ／Ｎ比）は高い。
掛ける時間は設計９０％、コード１０％くらいになった。
0719名前は開発中のものです。02/03/01 03:50ID:???
たしかここだったと思うけど、OOPでSTG（凄く簡単な雛型）作った人が、
ソースUPしてたと思うけど、勝手に弄らせて貰ってます。

何か形になりそうだったら、UPします。
0720名前は開発中のものです。02/03/01 09:01ID:2Wt9xxPq
Effective STL買ってきて読んでるけど
shared_ptr（・∀・）ｲｲ!! 怪しい自作スマートポインタとはお別れだな。
0721名前は開発中のものです。02/03/01 12:24ID:???
>>720
weak_ptr も調べると幸せになれる。(boost 1.27 以降だったかな)
0722名前は開発中のものです。02/03/01 12:28ID:???
>>719
ライセンス条件は確認した？　BSD ライセンスとかならともかく、そうでないと
「参考にするのは OK だが、コピペで使うと著作権法違反」とかの可能性もあ
るから注意ね。
0723narucy5602/03/01 23:18ID:06YWXjZs
>>718

設計に時間をかけるのはよい心がけ。

ただ、大抵、設計にかける時間というのは言うなれば「どうすれば簡単になるか」
ということを考える勉強の時間なのよ。

OO に慣れた人なら、ちょっとしたディスカッシヨンですぐに設計は完成しちゃう（・・・と思うんだけど、どうかな）

設計に時間費やすのはいいけど、それでデザイナが求めていないところまで
柔軟性を持たせる意味もないし。

だれもが 3分 で内容が理解できるくらい単純な設計でないといけない。
そういう意味じゃ本来は設計には時間を費やさないのが、OO をマスターしてからは
重要なんだと思う。
0724名前は開発中のものです。02/03/01 23:40ID:???
>>723
> OO に慣れた人なら、ちょっとしたディスカッシヨンですぐに設計は完成しちゃう
気のせい。
0725名前は開発中のものです。02/03/02 06:07ID:???
>723
その３分程度でできるのはモデリングだけだろ・・・
072671802/03/02 06:46ID:???
ありがとうございます。
往々にしてあほ(笑)なので私はまだすぐに設計が完成…という境地には
至ってないですね。がんばりたい。
0727XP02/03/04 04:33ID:fGL1MkkH
先のことを考えて作らないこと。自分が設計にこもりはじめたり、
一般化をはじめたりしているのに気がついたら、ストップ。動作す
るもっとも単純なことを実装して、今しなくてはいけないことをす
るのだ。「あとで必要になるはずだ」と言っている自分に気がつい
たら、あなたは貴重な時間を無駄にしているということだし、顧客
からプライオリティを設定する権利を奪い取っているということだ。
0728名前は開発中のものです。02/03/04 04:57ID:???
>>727
正直、リファクタリングは

　ちゃんと設計できる能力がある人

前提の話だと思う。いい加減な設計しか出来ない／設計しない人が言い訳に
使うのは許さん。
0729名前は開発中のものです。02/03/04 06:18ID:???
もとの設計がダメでそれから派生した多種のクラスもダメだった
その修正がいい加減嫌になって全部捨てて結果
全世界の開発者の貴重な時間を無駄にした例がＭＦＣだよね
0730名前は開発中のものです。02/03/04 15:01ID:???
>>729
MFC 叩きはよそでやれ。
0731名前は開発中のものです。02/03/04 17:42ID:???
>>729-730
秀同（ｗ
0732名前は開発中のものです。02/03/06 03:48ID:d8OL+l1I
良スレ期待age
0733名前は開発中のものです。02/03/08 16:14ID:QLWVytdE
設計のベストなあり方としては、以下のページによいものがあった。

設計の終焉?
http://objectclub.esm.co.jp/eXtremeProgramming/IsDesignDead.html


設計はやっぱしなきゃだめ。
でもそれは複雑になりすぎちゃだめ。
時間をかけすぎてもだめ。
しっかりできても他人に説明できなきゃだめ。
0734名前は開発中のものです。02/03/08 18:16ID:???
>>733
読んでみたけど、妥当な意見に思えるな。
0735名前は開発中のものです。02/03/08 23:38ID:???
>>733
どうでもいいが、こうあるべきという主張はやめたほうがいいよ。
XPかぶれてるのはわかるけど。
0736名前は開発中のものです。02/03/09 00:33ID:???
>>735
> XPかぶれてるのはわかるけど。
リンク先のドキュメントも >>733 の文章（設計の終焉? の要約だと思うが）も、
むしろ XP の中では穏健派の書いた文章だぞ。

XP について賛成するにせよ反対するにせよ、とりあえず XP について調べて
理解しとけ。話はそれからだ。
0737名前は開発中のものです。02/03/09 00:50ID:zvT+Hk0x
XPを実践できるのは天才だけ？
073873502/03/09 00:51ID:XwdiXSCe
>>736
んー？ベストなものなんて世の中には無いって言ってるのさ〜。
XPについては何も言ってないぞ。
0739名前は開発中のものです。02/03/09 01:23ID:???
>>738
> XPについては何も言ってないぞ。

XP について何も知らないのに
> XPかぶれてるのはわかるけど。
と言うの？　ダメじゃん。
0740名前は開発中のものです。02/03/09 01:25ID:???
>357
＞XPかぶれてるのはわかるけど。
>738
日本の政治家みたいなﾔｼだな（藁
0741名前は開発中のものです。02/03/09 01:26ID:???
ポインタ間違えた・・・
×>357
○>735
0742名前は開発中のものです。02/03/09 01:55ID:???
がんばれよ（藁
0743名前は開発中のものです。02/03/09 02:50ID:???
やだ（ｗ
0744名前は開発中のものです。02/03/17 02:50ID:62wXi74P
age
0745名前は開発中のものです。02/03/17 03:13ID:???
XPなんてｶﾞｷのｼｮﾝﾍﾞﾝ臭いものを勝手に作っておいて
勉強しろなんてひどいな
074671902/03/17 07:42ID:SG2XMPR0
（多分ここで）UPされたOOPSTGに、簡単なタスク管理追加、DIRECTX化、
したものをUPしようかと思います。
（環境、Ein98SE,P31G,GForce3）
著作権法違反は、特に記述がなかったのでOKだと思います。

当り判定（タスク間のやりとり）をまだ入れてないんです。
各（自機の）弾タスクが、（敵の数分の）タスクを総ナメしないと
いけないんですかね？やっぱ。判定に段階を設けるとしても。
0747名前は開発中のものです。02/03/17 11:29ID:mjqfxEH/
>著作権法違反は、特に記述がなかったのでOKだと思います。
　
お〜い、はに丸。著作権は何もしなくても自動的に発生しますよ。
改変と再配布の許可が明示されているのでなければ、
一応作者に問い合わせるしか。
0748名前は開発中のものです。02/03/17 13:38ID:???
>>747
同意。

明示的に再配布可能とか記述がない限りは、勝手に使うとまずいぞ。

っつか C++ で書いたシューティングゲームの雛型なら MIT ライセンス
で公開されてるものがあるぞ。
074971902/03/18 00:39ID:tIFzPCA5
>>747
はにゃ？そうスか、、。無知を晒してしまったですな。
ソース自体は、殆ど書き換えちゃったんですがね。実は。
やめといた方がよさそうですね。
作者の方へコンタクト取れそうにないし。

>>748
出来れば、詳細を教えて下さい。どんな設計か興味あります。
（特にクラス間の情報のやり取り等）
シューティング　C++　で検索しても見つけられなかったです。
0750名前は開発中のものです。02/03/18 02:40ID:VWHiZCDa
ximpactもC++で書いてあった気が
0751名前は開発中のものです。02/03/18 04:31ID:???
>OOPSTG
開発状況報告スレのここらへんじゃない？
http://game.2ch.net/test/read.cgi/gamedev/1005143186/212-

あとここ。
http://www.sm.rim.or.jp/~shishido/gamedev.html
0752名前は開発中のものです。02/03/18 19:05ID:???
>>749
これ。

http://www.issei.org/programming/Windows/DxApp

ただしソースはあるけど操作に必要なリソースファイルは置いてないし、
当たり判定もまだのようだが。
075371902/03/19 01:30ID:9e3mOAQn
>>751
おお！THX!ビンゴです。早速問い合わせてみます。

>>752
THX!です。見てみます。
でも、本業の方が押してきてるので、作業進まないかも。
（でも、やりたいのはSTGｗ）

今、某CUBEやってるんですが、コールバック関数のラッピングに手間取ってます。
(static)関数内でクラスにアクセスのに、とりあえず、グローバルポインタ渡すしか
思いつかない、、。
0754名前は開発中のものです。02/03/19 01:56ID:???
>>746
　当たり判定は当たり判定管理クラスにタスクを登録して結果を
コールバックで取得＆反映って感じでしょ。

　後は判定管理クラス内をレイヤー化して置く事で様々な状況に
対応できるようにすると。
075571902/03/19 04:05ID:9e3mOAQn
>>754
すいません。良く解らないです。

コールバックって、キリの良い所で処理を返す必要がないものに
対して使うものだと認識してます。
（メモカ、CDの裏読み等）当り判定って、フレームごとに全て完了
させないとイケナイ気がするんですが・・。
0756名前は開発中のものです。02/03/19 04:17ID:???
>>755
> コールバックって、キリの良い所で処理を返す必要がないものに
> 対して使うものだと認識してます。
認識が間違ってます。
0757名前は開発中のものです。02/03/19 05:05ID:???
>>755
ウンウン、コンシューマな人だねぇ…。
別にハードウェア割り込みから呼ばれる関数をコールバックと限定
するワケじゃないハズだよ。

当たり判定管理クラスを１つのデヴァイスと見なして、そこからの
情報伝達をコールバックという形で見れば大体言いたい事は解って
もらえるかな？

　だから１タスクは他のヒット効果をもつタスク全てを知らなくても
自分と判定管理クラスとの相互関係のみで当たり判定を管理できるよ
うになる訳。719氏のタスクシステムの全貌は知らないけど、
HitMe( Task& enemytask , int layer );
Hit時にこーゆー関数がコールバックされば大体の処理は管理しきれる
し、パワーアップアイテムとかとの住み分けの汎用性も高いっしょ？

　次にレイヤー化する事によるメリットって？みたいな質問がくると
更に嬉しいんだけど。
0758名前は開発中のものです。02/03/19 11:42ID:???
レイヤー化する事によるメリットって？
0759名前は開発中のものです。02/03/19 11:53ID:???
>758
ｵﾏｴ755じゃないだろ
0760名前は開発中のものです。02/03/19 12:07ID:???
うん
0761名前は開発中のものです。02/03/20 01:06ID:OKAtcaEA
>>757
　それより先に、コールバックで結果を通知することのメリットの方が聞きたい。
（レイヤー化のメリットは、わかる。俺もそうしよ（ｗ ）
　当たり判定管理クラスにAddHitData(Task &, int) IsHit(Task &, int) ってなメソッド
を用意して、前者で当たりの登録（これはTaskスタート時１回でいい）、でIsHitで結果
を知るってな方が自然だと思う。
　コールバック方式って、やっぱ、HitMeの時には登録が行われるだけで、タスク処理
が全部終わったあと、当たり判定管理クラスの実際に判定を行うメソッドを呼んでやる
と、その中でコールバックが呼ばれる感じだよね？となるとコールバックの中で進入禁
止の処理やら、アイテム拾ったときの処理やら、攻撃受けたときの処理やら全部やら
なきゃいけないわけで、そういう処理はタスク処理の中に書けた方がわかりやすいので
は？
0762名前は開発中のものです。02/03/20 01:11ID:???
>>761
本筋からずれるが、なんでもかんでも Task クラスに突っ込まずに、

- 当たり判定関係のメソッドだけ抽出したインターフェースを用意
　（純粋仮想関数だけ定義したクラスを容易）
- タスク実装クラスに、そのインターフェースを多重継承

の方が、柔軟性が増すぞ。
076376102/03/20 01:15ID:OKAtcaEA
あ、わかった。タスク処理の中であたり判定処理しちゃうとタスクの実行順で
当たり判定データが現フレームの物だったり前フレームの物だったりしちゃう
からか。
0764名前は開発中のものです。02/03/20 01:20ID:???
>>761
757 じゃないが、メリットは

1 当たり判定順序をタスク実行順序と切り離せる

2 タスクの状態変化のタイミングと、タスク実行のタイミングを分離できる
　タスクを順次読んでる途中で、タスクの状態が変わって、タスク管理クラス側
　にも影響を与える（たとえばタスクを殺して管理クラスから削除）場合には、
　よくよく考えないと dangling pointer を参照するバグが出る

3 特殊な判定（特定のキャラクタにのみ当たり判定があるとか）を付け加える
　ときに、その処理が各タスクに分離せずに、管理クラスで一括して処理でき
　る

っつーあたりじゃないか。

当たり判定はともかく、タスク実行と描画は実行順序を独立に定義するために、
分離するのが普通だよな。
0765名前は開発中のものです。02/03/20 01:21ID:OKAtcaEA
>>762
多重継承より、オブジェクトコンポジションの方が良いと思われ。
0766名前は開発中のものです。02/03/20 01:27ID:???
>>765
インターフェースの多重継承と、実装の多重継承を勘違いしてないか？

コンポジションだと、タスク内部の情報にアクセスするのが難しくなるぞ。
076776102/03/20 01:33ID:OKAtcaEA
>>764
>当たり判定はともかく、タスク実行と描画は実行順序を独立に定義するために、
>分離するのが普通だよな。
うい、そうですな。

　俺のタスクシステムの場合、タスク処理本体を二つの関数に分けてあって、基本
的な処理は１番目の関数をオーバーライドして定義し、実行順の問題がある処理
は２番目の関数をオーバーライドして、ってな感じでやってるんですが、これだと、
２つじゃたんない、３つ必要！ってな事になったらおいそれと足せない。
　なんかもっといい実装例ないかなぁ。それか、実行順に依存させたくない処理は
ぜんぶコールバックでやるべきなんだろうか？（この方式にこだわるのは、処理の
流れがソースからわかりやすい、から）

＃ちなみにその二つのメソッドはanimate、renderという名前。renderといいつつ、
当たり判定とそれによる位置変更もやる……名前と内容が一致してない……。
076876602/03/20 01:38ID:???
実例を挙げた方が良いか。

struct hittable {
　 virtual void get_hit_rect(rect&, hit_type&) = 0;
};

class player_task : public hittable
{
　　bool invisiable_;
public:
　　void get_hit_rect(rect& rc, hit_type& htype)
　　{
　　　　if (invisible_)
　　　　　　rc = INVALID_RECT;　　// 不可視状態の時には、当たり判定なし
　　　　else
　　　　　　...
　　}
};

インターフェースの多重継承を利用すれば、こんな感じでタスクの内部状態
を利用して当たり判定を変更することが、容易に可能になる。コンポジション
で同じ事をやろうとしたら、思い切り不自然なコードを書くことになるぞ。
0769名前は開発中のものです。02/03/20 01:40ID:???
>>766
ん、勘違いしてた。
ああ、762が言っている方式では、タスクマネージャーの方から当たり判定用の
メソッドを呼び出して当たり判定を実現するって事なのかな？（柔軟、か？）
077071902/03/20 01:52ID:3YnMUW/P
winのような、イベント駆動型とかをイメージすればいいのかな？
いやー。正直、よくわからんスｗ避けてました。
勉強してきます。

＞719氏のタスクシステムの全貌は知らないけど、
HitMe( Task& enemytask , int layer );
Hit時にこーゆー関数がコールバックされば大体の処理は管理しきれる
し、パワーアップアイテムとかとの住み分けの汎用性も高いっしょ？

自分が今実装してる方法は、
UpdateFrame()、（全タスクに対するAI処理等)
EndScene()、（全タスクのキルスク、チェンジタスク要求チェック、実行）
Draw()、全描画
てな感じです。
判定は、キルタスク同様、大まかな範囲チェックに引っ掛かったものを、
EndScene()内でさらに判定、て感じで考えてました。

で、判定関数は、矩形,球ぐらいを用意しといて、タスククラスに
持たせようと思ってました。

＞次にレイヤー化する事によるメリットって？みたいな質問がくると
更に嬉しいんだけど。

それじゃ、
次にレイヤー化する事によるメリットって？
0771名前は開発中のものです。02/03/20 01:54ID:???
>>767
> 実行順に依存させたくない処理は ぜんぶコールバックでやるべきなんだ
> ろうか？
そう思う。

上のほうで挙がってた DxApp だけど、あれは描画とタスク実行を切り離して
別々の優先順位で処理するようになってる。

　タスク関係　　ITask, CTaskManager
　描画関係　IObject, CObjectManager

が対応するクラスなんで、読むと参考にはなるかも。

（あと優先順位無し、登録順で処理する IObjectCommand っつーのもある）
0772名前は開発中のものです。02/03/20 01:56ID:OKAtcaEA
　>>768 の方式だと、オブジェクトごとに当たり判定の実装が必ず
違うのであれば問題ないけど、このオブジェクトとこのオブジェクトは
実装一緒ってな事が多いとコピペが氾濫したり、もう一個クラス作って
へんちくりんなメッセージングすることになったりしない？

　俺は757のいう当たり判定管理クラスってのを導入した方が
スマートだと思うから。
　メンバとして持ったhittableのインスタンスの参照を当たり判定
管理クラスに丸投げしてやるだけでいいと思うので、複雑にはな
らないと思う。
0773名前は開発中のものです。02/03/20 02:05ID:???
>>772
> このオブジェクトとこのオブジェクトは実装一緒ってな事が多いと
そのときには template を使って Mixin すれば OK。

っつか 768 も

- 当たり判定管理クラスを作り
- そこに当たり判定チェックを行うインスタンスを登録
- 管理クラスから、各インスタンスをコールバック的に呼び出す

のは同じだけど。設計方針は変わらず、たんに C++ で都合がいい実装方法を
紹介しただけ。（コールバックの代わりに多重継承を使うと this の受け渡しが楽
だぜ、という程度の話）
077476702/03/20 02:11ID:OKAtcaEA
　俺のは２つだけど、>>770 のは３つに別れている、って事なのね（w
　こうなるとじゃぁ４つに分割、５つに分割と仕様要求次第じゃきりがない
って話になるな。
　タスク処理メソッドを可変長リストで持って、とかすると無駄に複雑に
なりそうだから、>>771 の言う通り、「実行順に依存させたくない処理は
ぜんぶコールバックでやるべき」なのかも。

>上のほうで挙がってた DxApp だけど、あれは描画とタスク実行を切り離して
>別々の優先順位で処理するようになってる。
　フロー制御はタスク機構だけで十分、というのは強引かな、やっぱ。（あ、俺
のシステムだとanimate、renderメソッドの呼び出しそれぞれに別々の実行順を
設定できるから、同じ事が実現できてはいる）

>>773
>> このオブジェクトとこのオブジェクトは実装一緒ってな事が多いと
>そのときには template を使って Mixin すれば OK。
あ、なるほど（ｗ
0775名前は開発中のものです。02/03/20 02:17ID:OKAtcaEA
>>773
>（コールバックの代わりに多重継承を使うと this の受け渡しが楽
だぜ、という程度の話）
たしかに、関数のポインタを渡すより、オブジェクトのインスタンス
渡した方がいいですな。

　つまり、基本はタスクでフロー制御して、その実行順に依存したく
ない物は全部GoFの言うところのCommandパターンでやるのが吉、
ってことかな？
0776名前は開発中のものです。02/03/20 02:29ID:???
>>772
C++ 限定の手法だが、template を使った Mixin の例。

template <class T>
struct hittable_invisible : public hittable
　　void get_hit_rect(rect& rc, hit_type& htype)
　　{
　　　　T& obj = static_cast<T&>(*this);
　　　　if (obj.invisible_)
　　　　　　rc = INVALID_RECT;
　　　　else
　　　　　　...
　　}
};

class player : public hittable_invisible<player>
{
　　bool invisible_;
public:
　　...
};

効率と汎用性、そして型安全性を全て損なわずに実現してる。ペナルティは
コードサイズの増大。
077771902/03/20 02:47ID:3YnMUW/P
>>774
３つ？ですか？

大まかな流れはさっき書いたものなんですが、言葉足らずだったかも。
ちょっと細かく言うと、
UpdateFrame()は,ゲームアプリ、タスクマネージャ、
描画エンジン、vプリミティブ（描画）、v各TCB、v各タスククラスが持ってて、
vがついてる奴が仮想関数です。

EndScene()は今の所、託すマネージャのみのメンバ間数です。

Draw()はタスク処理とは関係ないです。
こちらは描画エンジン、各（と言っても今実装してるのはスプライトのみ）
プリミティブクラスで使ってます。

タスククラスは、
tcbBase<-tcbSprite(今これだけ)
tskBase<-各キャラタスク　となってて、
tcbSpriteのメンバにVectorでtskを保持して、チェンジタスクで
切り替えています。

tcbSpriteが、（スプライト）プリミティブからリソースを貰って
UpdateFrameで更新してます。

描画エンジンの方にも、UpdateFrameはあって、アニメ処理、タスクが
弄った頂点データをビデオボードに転送したりしてます。
0778名前は開発中のものです。02/03/20 02:51ID:???
>>757
話が落ち着いたところで、そろそろ「レイヤー化する事によるメリット」を
語ってくれると嬉しいトコロだが。

そもそも「レイヤー化」を、どういう意味で使ってるのか分かってなかったり
するので、単語の定義からお願いします。
0779名前は開発中のものです。02/03/20 03:03ID:???
>>777
　ああ、タスク毎の処理は１種類で、当たり判定の処理（タスク実行順に
依存したくない処理）はタスクマネージャーがグローバルに行う、ってわ
けですね。
（´ー｀）。oO（ 本当、人それぞれだなぁ ）　
0780名前は開発中のものです。02/03/20 06:31ID:9RjuXxJB
このスレの最初のほうにCとC++ではCの方がC++で作ったときよりも
実行速度が速い、もしくは同等と書かれていたんだけど、
ヘボプログラマはCで作っておいたほうが無難ということなの？
そこで言われているCとC++との違いはクラスの使用から来るもの？
0781名前は開発中のものです。02/03/20 07:15ID:???
>>780
実際にわずかなオーバーヘッドがあるし、まずい設計では
暗黙のコンストラクタ/デストラクタによって積み重なって遅くなる。
C++についてよく理解してないと、ただ遅いだけの道具になるよ。
078278102/03/20 07:18ID:???
C と C++ の違いは主にクラスによる。
同一な C プログラムなら C++ でコンパイルしても
速度はほぼ同一なはず。ライブラリとか最適化の具合にももちろんよるけど。
0783名前は開発中のものです。02/03/20 11:13ID:???
>>780
書籍「Inside the C++ Object Model」で詳細に解析してるから、それを
読むのがいいと思うが。

メンバ関数（メソッド）を呼び出す場合に this が暗黙のうちに渡されたり、
仮想関数を呼び出すと間接参照が何度か（一般には 2 回）入ったりす
る。ただ、このあたりのことは C でも同じ処理をやろうと思ったら、

　関数の引数として、構造体へのポインタを渡す
　関数ポインタを使う

必要があるから、ホントは変わらないんだけど。

> 暗黙のコンストラクタ/デストラクタによって積み重なって遅くなる。
synthesize constructor / destructor のことを言ってるんだと思うが、
それなら C だって「初期化処理を入れたら遅くなる」というのと同じ。
trivial constructor / destructor で済むクラスなら、初期化・終了処
理を省くことも出来るし。

C でも C++ でも「同じ処理をさせよう」と思うと、実際には「同じだけの
コストがかかる」ことになる。ただ C++ では、synthesize constructor/
destrurctor や temporary object のように

　コンパイラが、見えないところでコードを付け加える

ことがあるから、そこを意識していないと、たった数行のコードなのに
コンパイルすると数千命令に展開されていた、ということが有りうるの
で注意が必要。
0784名前は開発中のものです。02/03/21 00:42ID:I/OXI3by
>>778
　フォトショップのレイヤーを思い浮かべると良いと思われ。
　当たり判定を取る当たり同士をグループ化して、グループに番号を付けておく。

　進入禁止系のあたりをレイヤー０番に置くとして、壁、NPC、敵キャラのあたりは
HitMe( ???, 0)と呼び出してやる。プレイヤーオブジェクトはそれが壁なのかNPCな
のか区別せずにすむ。
　で、レイヤー１番はアイテム系の判定として、アイテムオブジェクトとプレイヤー
オブジェクトだけが所属する。そうすればNPCオブジェクトの方で接触のあった
オブジェクトがアイテムだったら何もしない、なんてコードを書かなくて済む、と。

　こんな感じ？
0785名前は開発中のものです。02/03/21 11:11ID:???
すげぇ、この板に役に立つスレがあったのか。
0786名前は開発中のものです。02/03/21 13:39ID:???
>>784
なるほど。参考になったよ。
0787名前は開発中のものです。02/03/22 10:21ID:???
レイヤー化って、OS−ミドルウェア−アプリケーションみたいなプログラムの階層化と思ってたけど、違ったのね
0788名前は開発中のものです。02/03/22 23:51ID:???
>>784
　すまそん。マスター入れてやっと家に帰って来れました。

　レイヤー化のメリットはまさに784さんの言うとおり。汎用的な当たり判定管理クラスを
１つ作ってあとはゲームデザイン次第でプログラマが自由にレイヤーを利用みたいな感じね。

　更なるメリットとしてヒットアルゴリズムの分離ってのもありまして。
「矩形の重なりによるヒット判定」
「球形や線分との距離による判定」
「背景物のようなｎ次元マップデータとの判定」
「ランドスケープやポリゴン等のベクトルデータとの判定」
など、これまたゲームデザインの要求に応じて利用/拡張すればいいと。
はっきりいってこの機構自体は１個作っちゃえば３Dゲームにもバリバリ
に応用できるし、斑鳩みたいな２Dの３Dの混在なんかも結構簡単に出来
るよね？

　ただまぁ、C++としての実装は自分はヘタッピなのでだれか上手い実装例
をみせてくれないかなーと。テヘッ。
0789名前は開発中のものです。02/03/23 01:20ID:???
コールバック関数による当たり判定って

全キャラクタのタスク更新
↓
判定管理クラスの関数を呼び出し→各キャラクタのタスクのコールバック関数呼び出し
↓
描画

みたいな流れかと思ったんですが、
コールバック関数内でタスクの状態（位置など）を変化させられないと、
キャラクタ同士めり込んだ状態とかで描画されてしまいますよね？
その辺はどう処理されてるのでしょうか？
0790名前は開発中のものです。02/03/24 05:59ID:WWKNmPMo
良スレなのでage
0791 02/03/24 09:15ID:DgRqu+K2
C++なんぞOOPLではないのでsage
0792名前は開発中のものです。02/03/24 11:04ID:???
>>788
なるほど、それは便利だ。
ちゅうか今、当たり判定で困ってるところなんだわ。

>>791
すでにそんなことはどうでもいい
0793名前は開発中のものです。02/03/24 11:12ID:???
>791
マ板で語り尽くされた事を隔離板で吠えられてもﾅｧ...
つーか、sagaってねぇし（藁
0794名前は開発中のものです。02/03/25 12:06ID:???
>>789
俺の場合、基本的にあたり判定の中では当たったかどうかの判定だけで
めり込んでも無視です。
当たり中に状態変化(移動、フラグ立てなど)を行うと実効順によってそれ
以降の判定が異なってしまうからです。
どうしてもやりたい場合、完全な例外処理ですね。
こいつはこういう処理だから気をつけるとかコメント書いてます。
つーか、うまい処理が思いつかん。
0795名前は開発中のものです。02/03/31 00:07ID:???
このスレに影響されて、当たり判定管理クラスを構築中age
0796名前は開発中のものです。02/03/31 06:17ID:???
頑張れー＆公開キボン。
0797名前は開発中のものです。02/03/31 08:22ID:???
当たり判定はその処理のタイミングも必要なので、
それ単体をクラスで定義しただけでは難しいと思うのだが
何かいい解決手段あったらよろしく
0798名前は開発中のものです。02/03/31 09:34ID:???
>>764
それだと、当たり判定の種類毎にレイヤー用意しなきゃいけなくなって面倒じゃない？

079979802/03/31 09:40ID:???
>>764
じゃなくて
>>784
でした。
0800名前は開発中のものです。02/03/31 11:32ID:???
800get
0801関係ないが02/04/01 00:49ID:z86bt0A7
最近C++でゲーム開発しているんだが、ヘッダーファイルをincludeするだけで
最終コードのサイズが増えるという現象に遭遇して思いっきり萎え。
コンパイラのバグだがあまりにもひどいっす。
Cならこんなことはならないよなぁ・・
0802名前は開発中のものです。02/04/01 00:56ID:???
どのコンパイラ？
0803名前は開発中のものです。02/04/01 01:01ID:???
CWだな…。オレも経験済み。
0804名前は開発中のものです。02/04/01 01:35ID:???
参照してないシンボルもリンクしちゃうってこと？ >>801
080580102/04/01 02:25ID:z86bt0A7
g++なんだがCWでもあるんか・・。
classの中のstaticなinline関数が関数ローカルのstatic変数を持つコードが
あると、その関数を一度も使わなくともコード、データ領域ともその翻訳処理
単位で展開されてしまうんだよ。いわゆるシングルトンパターンの構造をもつ
ヘッダファイルをインクルードするだけで飛躍的にコード、データサイズが増加する
罠。
やっぱC++は組み込みには向いてないよな・・・。
0806名前は開発中のものです。02/04/01 02:31ID:???
組み込みだからって、そんな関数なんでinlineにすんだよ？>>801
0807名前は開発中のものです。02/04/01 02:34ID:???
>>805
ちなみに gcc のバージョンいくつ？
080880102/04/01 02:34ID:z86bt0A7
class foo {
static foo& Instance() {
static foo bar;
reurn bar;
}
}

これだけですが何か？
■ このスレッドは過去ログ倉庫に格納されています