[過去ﾛｸﾞ] ゲームプログラミング相談室 (986ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
845: 02/10/29 11:30 ID:??? AAS
今まで考えもしなかった方法がいろいろ出てくるんでおもろい。
846(2): 02/10/29 12:45 ID:??? AAS
AA省
847: 02/10/29 13:09 ID:??? AAS
>>821
外部ﾘﾝｸ[html]:www.campus.ne.jp
を読むと多少はイメージできるかも。
2次元配列でマップを管理しているのなら,再帰関数っていうのを使って
考えていくんだけど(うまく言ったときのうれしさといったら･･･),
他の方法で管理しているとなると,上で書いているような方法しかないかな。
2次元配列を用意して,障害物のある座標に１とか入れて,再帰関数を使えばいいとは思うけど。
848: 02/10/29 13:10 ID:??? AAS
>>846
まずいと思う。
こっそりかえしてきな。
849: 755 02/10/29 13:58 ID:??? AAS
>>771
759さん、ありが㌧。
これをヒントにがんばってみます。
>>791
ターゲット＆要件によっては両立できない場合もあるんでつよ。(つД`)
850: 02/10/29 20:23 ID:??? AAS
>>823
"A star algorithm" で再検索。
851: 02/10/29 20:32 ID:??? AAS
外部ﾘﾝｸ[html]:www.geocities.com
852(2): 02/10/29 20:44 ID:??? AAS
>>841
> 解放したポインタにNULL代入するのは作法でしょう。
気休めに過ぎない作法なんか、やめとけよ……。
だいたい複数のポインタが同一の領域を指している環境では、そんな手は
使えないし。
> どうしてもめんどうなら
その程度の「手間」で済むのは free_something() なんてオモチャみたいな
省16
853(1): 02/10/30 00:06 ID:??? AAS
>>852
>そこで「すべての要素に pointer の pointer を持たせて、二回 dereference
>しましょう」ってのはかなり厳しいよ。
PalmOSの開発環境では、ヒープメモリを確保するときにポインタのポインタしかくれない
(OS側でガベコレするため)のだけど、それでもなんとかなっているのは興味深い。
ポインタのポインタで生きていくための知恵が、Palm界では蓄積されてるのかもね。
854: 02/10/30 00:13 ID:??? AAS
>>853
それはコンパクションしたいからだろう。Win16 のグローバルヒープとか、昔の
MacOS とかもお仲間。
まっとーな MMU が使えない環境でもメモリの断片化が防げる代わりに、デ
バッグと処理速度に悪影響が出る。智恵というか、血と汗が蓄積されてると
思われ。
(俺も Win16 時代には泣いた覚えが）
855(1): 02/10/30 00:33 ID:??? AAS
>852
俺の場合、free後NULL代入してないだけで怒られたもんだが……。
二重ポインタっても、Ｃ言語に参照がないから代用してるだけだ。
参照で実装してもいいかもね。値渡しでfreeする関数に渡した
つもりのfree後のポインタが実は参照渡しで暗黙でNULLに
書き換わっていたとして、なんら問題あるまい？
むしろ、解放後のポインタにアクセスするという潜在的バグをつぶせる。
856(1): 02/10/30 00:49 ID:??? AAS
>>855
> 参照で実装してもいいかもね
C++ の参照のことを言ってるなら、初期化のタイミングの制約がキツいから、
完全にポインタの代用にはならんよ。
ポインタの実体を一つにして、常にポインタのポインタを使え主義が破綻す
るのは、「そのポインタの実体を解放してしまったら、やっぱり不正なメモリ
アクセスが検出できない」っつートコロなんだよな。そのための細工を積み
省1
857(1): 02/10/30 01:01 ID:??? AAS
>856
いや、freeに一個ラッパーを掛けて、そこへ渡すポインタを
参照渡しにして関数内でNULLを代入しようってだけのことね。
実際はメモリをマネジメントするクラスなり関数郡なり作って
ＧＣをそこで実装したほうがいい、っていうのにはもちろん同意。
858(1): 02/10/30 01:49 ID:??? AAS
>>857
> いや、freeに一個ラッパーを掛けて、そこへ渡すポインタを
> 参照渡しにして関数内でNULLを代入しようってだけのことね。
それでは不正なメモリアクセスの問題は解決しないんだけど。実例が
想像つかない？
859(1): 02/10/30 02:18 ID:??? AAS
>858
もともと不正なメモリアクセスは別問題。それは単にバグ。
>818を読む限り、単に解放済みポインタとそうでないポインタで
条件分けしたくないだけなら、NULLを代入すればいい。
NULLは解放済みを示すマークで、free(NULL)が素通りという
仕様はそのためにある。
ループのある枝分かれリストみたいのを解放するケースを
省3
860: 02/10/30 07:39 ID:??? AAS
正直、メモリ管理は人間がやるべき仕事ではないような気がしますた。
生産性低くなる原因の一端。
861: 02/10/30 08:46 ID:??? AAS
しかし明示的に開放する機能が無いとメモリが無駄になり、下手すると
足りなくなる罠。メモリ確保の機能がある限り人間が管理するしかない。
862(1): 02/10/30 09:22 ID:??? AAS
２重開放はエラー出たりしてすぐ発見できるからあまり問題にならない
ような気がする。メモリリークは表面化しにくいから厄介なバグになるが。
863: 846 02/10/30 12:54 ID:??? AAS
素通り･･･
864(1): 02/10/30 20:43 ID:??? AAS
>>862
> ２重開放はエラー出たりしてすぐ発見できるからあまり問題にならない
そうでもない。
メモリ関係の問題はどれもそうなんだが、問題が出たときと原因が遙か彼方に
隔たってることが多い (二重 free なら一回目の free はどこで行ったんだ？)
から、原因を突き止めるのは大変だよ。特に微妙な条件でのみ発生するとか、
マルチスレッドや DMA が絡むと死ねる。
省13
865(1): 02/10/31 00:04 ID:??? AAS
>864
一回目のfreeは、無効なデータを解放するつもりでやってるんだろ？
それを問題が起こらないようにとただ消してしまうのは、
無効なデータへの不正なアクセスを隠してしまうだけだと思うが。
NULLポインタで明示的エラーを出させたほうが、安全。
落ちないバグの原因探すほうがよっぽどやっかいだろう。
こまめな解放はいらないとしても、一応プロセスの最後には明示的に
省2
866: 02/10/31 00:17 ID:??? AAS
boost::shared_ptrとSTLのコンテナを使えばいいのに．．．
867: 02/10/31 09:37 ID:??? AAS
C#を使え
868: 02/10/31 16:06 ID:??? AAS
ません
869: 02/10/31 18:22 ID:??? AAS
か？
870: 02/10/31 19:45 ID:??? AAS
ﾁｮﾄﾏﾃ!
ｺｺﾊ､
ゲームプログラミング相談室
ﾃﾞﾂﾖ!
871(1): 02/10/31 20:02 ID:??? AAS
>>865
状況によるだろう。アセンブラのラベル情報とか 864 が言ってるようなコンパイラ
の型情報とかは、free したところで直後にプロセスが終了するのが目に見えてる
ので、free せずに終わらせるのもアリだ。
そこで free しても単なる自己満足。ユーザにとっては、むしろ邪魔なだけ。
872(1): 02/11/01 00:07 ID:??? AAS
>871
ちょいまち、ユーザの「邪魔」って、具体的にはなんのことだ？
ユーザには関係ない、というのなら分かるんだが。
あとでメンテナンスする人のこと考えたらメモリリークつぶすくらいは
常識だと思うがな。大量の警告メッセージに埋もれて、つぶすべき
メモリリークが見えにくくなる。
873(2): 02/11/01 00:32 ID:??? AAS
>>872
> ちょいまち、ユーザの「邪魔」って、具体的にはなんのことだ？
キャッシュを汚すわ、終了に(本来不要なはずの）余計な時間を食うわ、
開発コストは上がるわ。
> あとでメンテナンスする人のこと考えたらメモリリークつぶすくらいは
> 常識だと思うがな。
プロセスの寿命とデータの寿命が一致してる場合にはメモリリークとは言わん
省6
874(1): 02/11/01 00:44 ID:??? AAS
>873
ＯＳに暗黙的に解放してもらったって時間は掛かるだろ。
開発コストったって、ただメモリ確保に一枚ラッパーかませて
最悪の場合でも終了処理で明示的に解放されるように作るだけだろ。
その「万能じゃない」機能をさらに使いにくくしてどうするのだ。
俺は引き継いだソースがメモリリーク放置していたら、
ちょっとウンザリするがな。
875(4): 02/11/01 00:54 ID:26Va0gRH(1) AAS
この流れに便乗して質問させてください。
VC++でシューティングゲームを作っているのですが、敵や弾をたくさん表示させては
消すために、メモリをnew、deleteしまくっているのです。
ところが、実行しているとすぐに重くなってしまいます。
メモリリークに関しては、デバッグモードで
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF)
を呼び出して確認したのですが、一つもありませんでした。
省3
876(1): 02/11/01 01:02 ID:??? AAS
>>875
> 表示させたオブジェクト(newしたインスタンス)の数に比例して
それって、ふつうに処理量が増えてるんじゃないの？
877(1): 02/11/01 01:23 ID:??? AAS
>>875
敵や弾の画面表示だけしない場合も重くなるか？
878: 02/11/01 01:24 ID:??? AAS
> ＯＳに暗黙的に解放してもらったって時間は掛かるだろ。
いわゆるunixあるいはwin32ならばかかりまへん
879(2): 02/11/01 01:28 ID:??? AAS
>>876
いえ、そういうのではありません。
キューに、敵だの弾だの詰め込んで、敵をやっつけ(deleteし)ます。
その後しばらく敵を出さなければ、キューがちゃんと空になっていることも
確認しました。
そして、その後また同じように敵を出して…と繰り返すと、だんだん重くなっていくのです。
プログラムを終了したときなんか、数秒フリーズしたように止まります。
省2
880: 02/11/01 01:34 ID:??? AAS
>>875
たぶんソース見ないと原因は分からない。
881: 02/11/01 01:39 ID:??? AAS
>873はVBかJavaでもやってろってこった（藁
882: 02/11/01 01:39 ID:??? AAS
>>879
HDDにスワップしているから遅くなっているとかそういうのは？
883: 02/11/01 01:44 ID:??? AAS
メモリを解放しているから、メモリが足りなくなることはない
→スワップはしない。
って考えるのは間違ってますか？
スワップしてる気配はないのですが…
884: 02/11/01 01:47 ID:??? AAS
>>879
１個１個new/deleteせずに、最初に一定数一括確保して使い回すように
してみて、軽くなるようならnew/deleteで重くなっていると見る。
885: 02/11/01 01:53 ID:??? AAS
>>875
profilingしてみりゃいいだけじゃん?
886: 02/11/01 01:53 ID:??? AAS
ありがとうございました。わかりました、やってみます。
ところで、new/deleteで重くなるとしたら、どうしてなんでしょう。
deleteする瞬間に重くなるなら分かるけど、後々にも響くってのは
理解できませんよね。
887(1): 02/11/01 02:02 ID:??? AAS
あまりにも頻繁に確保・開放を繰り返すと、それを管理する
ほうも大変なんじゃないの。確保・開放を繰り返すと割り当てた
メモリが断片化するよね。そんな状態で効率よく領域を割り当てる
ようにするにはどうすればいいんだろうね。
888(1): 02/11/01 02:03 ID:??? AAS
>>874
> ＯＳに暗黙的に解放してもらったって時間は掛かるだろ。
free() のソースを読んで、どういう処理をしているのか調べてみ。OS の
方の処理とはまた別に、いろいろやってるから。
889: 02/11/01 02:07 ID:??? AAS
>>887
仮想記憶を採用している環境なら、気にしないのが正解だと思う。スワップは
喰うかもしれんが、実メモリの断片化はページングにお任せってことで。
仮想記憶がない環境だと、最初にメモリのレイアウトを決めてしまって、固定
長のメモリブロックを割りあてるのが常套手段。
890(1): 02/11/01 02:17 ID:??? AAS
>888
それが問題になるほど大きな処理なのか？
もしそうなのだとしたら、最初にどんとメモリ取って、
それを小分けにして使って、最後にどんと解放したら
いいじゃないか。だったら一回で済む。
891: 02/11/01 02:34 ID:??? AAS
>>890
そこまでして、わざわざヒープの解放に拘る意味があるのか？
だいたい使ったメモリ全部解放しろっつーなら、スタックやテキスト
はどうするんだか。
892(1): 02/11/01 02:38 ID:??? AAS
そこまでって言うほどの手間じゃねえだろ、と言っている。
最後にしか解放しないと割り切れば、簡単に実装できるだろ。
893: 02/11/01 02:42 ID:??? AAS
>>892
そんな丼勘定な実装に何の意味があるんだ？ だいたい最初からサイズが
見積れるなら static でとれば良いだけだし。
894(1): 02/11/01 03:20 ID:??? AAS
メモリリークをつぶせるという意味がある。警告メッセージ潰し。
サイズ見積もれなんていってないじゃないか。
allocに一枚ラッパーかぶせて、ポインタを全部記録しておいて、
終了時に順にfreeするだけ。
895: 02/11/01 03:35 ID:??? AAS
ダイナミックに確保するならちゃんと開放しないとダメだよ。
メモリを再確保するたびに使用メモリ量が積もっていく。
ゲームの場合はメインの処理がループなので、たいしたことないと思っていても、
処理によっては１秒60回でメモリリークされたりしてちょっとまずいことになる。
開放しないメモリを確保するくらいなら初めからスタティックに確保した方がいい。
896: 02/11/01 05:41 ID:??? AAS
>894はループの中で確保するのを前提にした話ではないよ。
どうしても解放するのが面倒くさい場合の最後の手段で言ってるだけ。
シューティングゲームのバッファなんかはstaticでいい気が。
数の上限は知れてるし、容量もたいしたことないでしょう。
897: 02/11/01 09:10 ID:??? AAS
.NETのガベージコレクタを使え
898: 02/11/01 09:22 ID:??? AAS
boost::pool ﾀﾞ! (ｳｿ
899(2): 02/11/01 09:55 ID:??? AAS
メモリ開放しないプログラムはそのまま再利用できないからクソ。
900(1): 02/11/01 14:36 ID:??? AAS
>>899
スレの内容を全く読んでいない馬鹿発見！
901: 02/11/01 16:44 ID:??? AAS
メモリ開放しないやつは開発者の姿勢としてクソ。
902(2): 02/11/01 19:58 ID:??? AAS
boost::poolって早いの？
903: 02/11/01 20:41 ID:??? AAS
>>902
そんな抽象的すぎる質問にどうやって答えろと（藁
904(1): 02/11/01 21:08 ID:??? AAS
突然ですみませんが当たり判定のアルゴリズムでOBBについて解説してある日本のサイトなどはないでしょうか？
905: 02/11/01 21:49 ID:??? AAS
メモリ開発しないやつは解放者の姿勢としてクソ。
906: 02/11/01 23:22 ID:??? AAS
>>904
日本のサイトは知らん。
海外ならいっぱいあるけど。
907: 02/11/01 23:58 ID:??? AAS
>>900
まんざらそうでもない。
javacなんかがそれで一時期ハマってたらしい。
908(1): 02/11/02 00:24 ID:??? AAS
＞９０６
すみませんが、できたらそのサイトをおしえていただけないでしょうか？申し訳ないです。
909(1): 02/11/02 00:29 ID:??? AAS
>>908
最近の厨房様は検索と言う言葉をご存知ないらしい。
外部ﾘﾝｸ:www.google.com
910: 02/11/02 00:46 ID:??? AAS
日本語のサイトは皆無だよな･･･
911: 02/11/02 01:01 ID:??? AAS
>909
すみません、すみません。（´Д｀；）
912: 02/11/02 02:32 ID:??? AAS
>>902
開発は、早くなり増田。
913(1): 02/11/02 15:33 ID:??? AAS
>>899
本当に、そのプログラムは再利用されるのか？ 汎用性は諸刃の剣だぞ。
914: 02/11/02 16:06 ID:??? AAS
>>913
まあ、C/C++に限って言えば再利用なんて、ほとんど幻想に過ぎないんだが、
ここは希望的観測の意味も込めて、「安易な手法での再利用は諸刃の刃だぞ」にしとこうや。
915: 02/11/02 16:19 ID:??? AAS
んでも、普段からメモリを解放するクセをつけておかないと思わぬところで…ってこともあるかもね。
GCがサポートされてる言語なら別として。
916(1): 02/11/02 16:23 ID:??? AAS
・処理速度至上主義
・プログラムコードは基本的に使い捨て
・激しく機種依存するプログラムばかり組む
ゲームプログラマは特に価値観が偏っているから常識は通用しないよ。
偏りすぎていて他のジャンルでは通用しない気もするけど。
917(1): ゲーム業界の真相 02/11/02 16:45 ID:??? AAS
再利用ができない
↓
生産性が上がらない
↓
労働者が沢山必要
↓
１人あたりの賃金が安くなる
省2
918: 02/11/02 18:52 ID:??? AAS
>>917
再利用を念頭においた結果、過度に複雑なクラスライブラリができて、結局
使われずに封印ということもある。バランス感覚重要。
っつか、ゲーム業界に限っていえばプログラマの数はむしろ少ないと思うが。
919: 02/11/02 20:59 ID:??? AAS
ゲームばっか作ってると、変な癖がついてしまう面はあるんじゃないの。
パフォーマンスを追及するあまり、超複雑・可読性ゼロ・再利用性ゼロみたいな。
まあ、ゲームに限って言えばそれでいいのかもしれないけど。
資産が継承できないとしたら賽の河原状態かな。
920: 02/11/02 21:41 ID:??? AAS
> ゲームばっか作ってると、変な癖がついてしまう面はあるんじゃないの。
気のせい。ファミコン時代ならいざ知らず、今時はそんなコードでは通用しない
程度には開発の規模が大きくなってる。
プログラマ一人で三ヵ月の仕事と、プログラマ三人で十八ヵ月の仕事だと、最適
な仕事の進め方は変わってくるわな。（さらに SI みたくプログラマ何百人みた
いな体制だと、また違ってくる）
921: 02/11/02 22:36 ID:??? AAS
今だと、プログラマ２～３人ぐらいのプロジェクトが多いのかな。
平均的な話。
922(1): 02/11/02 23:03 ID:rSTkonKP(1) AAS
>>916
> ・処理速度至上主義
ここはその通りだとおもうけど、下の２点は同意できないなぁ
特に機種依存コードを多用したりすると恐ろしく読みにくいコードになって、
デバッグ困難になったりするよね
もし担当が交通事故で急死したとしても、他のメンバーが問題無く引き継げるように
読みやすさ優先でコード書けって先輩にたたきこまれたクチなんだけど…
923: 02/11/02 23:10 ID:??? AAS
>>922 自己レス
916 は、ゲームプログラマはそういうのが多いって言ってるだけだね
勘違いしてた、もうしわけねぇ
924(2): 02/11/02 23:18 ID:??? AAS
多いって一般のプログラマとどうやって比較したのか出所提出を小一時間求めたい
ありもしない妄想を根拠として抽象的な論理を展開するのが流行りか？
925: 02/11/02 23:31 ID:??? AAS
そこまであちこち顔を出してる人ってそんなにいるとも思えんのう
上下前次1-新書関写板覧索設栞歴
あと 61 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.027s