[過去ﾛｸﾞ] ゲームプログラミング相談室 (986ﾚｽ)
上下前次1-新
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
806(1): [age] 02/10/27 18:15 ID:??? AAS
メ モ リ リ ー ク が イ ヤ な ら
Ｊ ａ ｖ ａ で も つ か っ て い ろ
807: 02/10/27 19:01 ID:??? AAS
>>804
2. はたしか廃止されたような気がする
今手元にないのでわからんが、どっかで見た
808(2): 02/10/27 23:24 ID:??? AAS
802だけどよ
malloc=VirtuaｌAlloc呼び出しで解決されてるんじゃないか、
と思ったんで、質問の意味もあって書いてみたんだが。
それをいい加減とか決め付けてる>>803氏んどくように。
あと、HeapAllocは既に廃止されてるはず（MSDN libに載ってたと思う）
今のWin32では、HeapAllocは内部でVirtualAllocを呼び出してるんじゃなかったかな。
809: 02/10/27 23:34 ID:??? AAS
いろんなmallocの実装を紹介するスレはここですか？
810(1): 02/10/27 23:47 ID:??? AAS
>>808
HeapAlloc が内部で VirtualAlloc を呼び出してるのは確かだが、単なる
ラッパじゃない。内部で色々処理をしてる。
それと廃止されたのは GlobalAlloc(), LocalAlloc() だろうが。嘘八百を
並べるなよ……。
811(2): 02/10/28 01:58 ID:??? AAS
>>810
訂正さんくす。
HeapAllocが廃止されたってのは、勘違いだったよ。
廃止されたのはGlobalAlloc/Freeで、HeapAlloc/FreeはVirtualAllocで
確保したメモリをヒープ構造で管理してるってことなのね。
Win32APIで開発する時は、たいていHeapAllocと同じことを自前でしてるせいで、
よく知りませんですた。
省1
812: 02/10/28 02:03 ID:??? AAS
それじゃ今後は同様の事態を表現するときは嘘七百五十くらいで。
813: 02/10/28 03:11 ID:??? AAS
>>811
> HeapAlloc/FreeはVirtualAllocで
> 確保したメモリをヒープ構造で管理してるってことなのね。
全然違うぞ…。なんでそこでヒープ構造が出てくる？
814: 02/10/28 09:40 ID:??? AAS
>>802,808,811
いいかげん。うそはっぱく。よくしらないのにしったかぶり。
晒しsage
815: 02/10/28 11:02 ID:??? AAS
>>806
JavaやC#がメモリリークないと思ってるヤツ発見
外部ﾘﾝｸ[html]:www-6.ibm.com
816: 02/10/28 11:57 ID:??? AAS
うーん、微妙に話題ズレてない？
>799も言うとおり、解放済みマークのついた領域は再利用される。
（そのためのfreeだろ？）
だから、mallocにラッパーが掛かってようが掛かってまいが、
>793が原則として正しいということでいいんでないの？
817(1): 02/10/28 12:05 ID:??? AAS
確保したら必ず開放しなくてはいけないと思ってたほうが無難だよ。
そのほうが余計なトラブルの心配しなくて済むじゃん。
818(1): 02/10/28 20:30 ID:??? AAS
>>817
俺は
free(p);
free(p);
とかやって、メモリ領域壊したことがある。実際にはこんな簡単なコードじゃ
なくて、サイクルのある複雑なデータ構造で、遠く離れた関数で実行されて
たんだが。
省2
819(1): 02/10/28 20:38 ID:??? AAS
普通、
free(p);
p=NULL;
ってしない？
820(1): 02/10/28 20:49 ID:??? AAS
>>819
しない。そもそも p に相当するものが関数の引数として渡ってくる場合には、
それって無理だし。
free_something(void* p)
{
free(p);
p = NULL;
省9
821(10): 02/10/28 21:14 ID:??? AAS
画像ﾘﾝｸ[gif]:isweb43.infoseek.co.jp
こういった感じのゲームを作ろうと試みています。
フィールド上をクリックすると、キャラがそこへ歩いて行くような。
ですが、障害物なんかを遠回りして避けていくようにするにはどうすれば
いいのか見当もつきません。どうしても凹んでいるところでつっかかってしまいます。
皆様のお知恵をお貸しください。おながいします。
ちなみに言語はＨＳＰです。
822(1): 02/10/28 22:37 ID:??? AAS
>>821
絶対に答えが出るアルゴリズムだと A* とかかねぇ。
823(1): 821 02/10/28 22:50 ID:??? AAS
>822
検索してみましたが、適当なところが見つかりませんでした。
A*とはなんでしょうか？
824(4): 02/10/28 23:11 ID:Y1mIhqb7(1/2) AAS
クォータビューのマップで当たりをとりたいんですけど
高速なやり方ってあります？
内部的にはトップビューというのではなく、
クォータビューそのままでマップとキャラの菱形の当たりをとりたいのですけど…。
動作環境はへちょいので浮動小数点とか線分の交点などを求めないような軽いのを考えているのですが。
825(1): 02/10/28 23:30 ID:??? AAS
その当たり判定で何をやりたいかによると思うんだが
826(1): 02/10/28 23:47 ID:??? AAS
>>821
とりあえず障害物で行き詰まったら、障害物の表面に沿って
目標に到達できそうな位置まで移動してみるというのはどうか。
827: 824 02/10/28 23:51 ID:Y1mIhqb7(2/2) AAS
>>825
クォータビューのマップを主人公が歩くとき、マップと当たりをとりたいのです。
高さがない似非クォータビューなので、それほど苦労しまい、と思っていたら
あまり芳しい結果になりませんでして。
マップが歩けるような当たりなので、常時判定するという方向性で軽くしたい、とそういうことなのです。
828(2): 821 02/10/28 23:55 ID:??? AAS
AA省
829: 821 02/10/28 23:58 ID:??? AAS
ずれちゃった…なんとかわかってください（汗 ＜図
つまり、出っ張った障害物なんかをちゃんと
キャラが通れるコースを歩いてくれるようにしたいのです
830(1): 02/10/29 00:00 ID:??? AAS
>>824
1)床だけの画像を描画する
2)キャラの足元付近のドットの有無で判定する
3)マップの残りとキャラを上書き描画する
831(1): 02/10/29 00:05 ID:??? AAS
>>828
ひっかかったら辿りかたを反転させれば？
832: 824 02/10/29 00:24 ID:UKOhyL2z(1) AAS
>>830
ワンダーウィッチなのでそうもいかないのですよ…。すみません。
833(1): 821 02/10/29 00:28 ID:??? AAS
>>831
やはりそれしかないですかねぇ…（汗
下手したら明らかに違う方向へ歩いていって、引っかかったら
今気付いたように遠回りをする…なんかスマートじゃなくないですか（・-・;;
834: 02/10/29 00:32 ID:??? AAS
>>833
それじゃ内部的に表示より先行して動かしておいて、未来の自分が
引き返してきたらその場で反転するようにすれば多少マシになるのでは。
835: 821 02/10/29 00:34 ID:??? AAS
あーなるほどぉ…それもそうですね
どうもありがとうございます。試してみます。（_ _
836: 02/10/29 01:11 ID:??? AAS
>>824
マップの床が碁盤の目のようになっていて、床の升目が全て同じ大きさ
同じ形であるなら、床の升目と全く同じ形状のイメージデータを配列
などで用意して、升目の座標と判定点の座標からイメージ内に対応する
座標を求め、その座標の点がセット状態であれば当たりとする。
837(1): 02/10/29 01:19 ID:??? AAS
AA省
838: 837 02/10/29 01:21 ID:??? AAS
うわー、直したはずが大きくずれた。 すまん。
839: 02/10/29 02:19 ID:??? AAS
>>821
１：現在位置から目的地までの直線を引く
２：その直線が障害物と交差していたら交差した点から
移動できる方向へ直線を引いてみる（左右どちらにも行けるならどちらも）
３：枝分かれした線分はできるかぎり目的地へ向かうように折り曲げていく
４：現在の走査位置と目的地とを結ぶ直線が
走査線の角度と同じになったら１へ戻る
省5
840: 02/10/29 02:20 ID:??? AAS
AA省
841(1): 02/10/29 06:41 ID:??? AAS
>820
解放したポインタにNULL代入するのは作法でしょう。
どうしてもめんどうなら、ちょっと気持ち悪いけど
free_something (void **p) {
free(*p);
*p=NULL;
}
省6
842: 02/10/29 07:51 ID:??? AAS
AA省
843: 821 02/10/29 07:52 ID:??? AAS
画像ﾘﾝｸ[gif]:isweb43.infoseek.co.jp
例えば、こういう場面でカーソルのあるところをクリックすると
池の周りを遠回りして歩いていきます。
ですが、このゲームのすごいところはカクカクした動きじゃなくて
ちゃんと池の形にぴったり沿って歩いていくということです。
もしよろしければ、実際にやってみていただけませんでしょうか？
見たほうが早いと思いますので…
省2
844: 02/10/29 09:31 ID:??? AAS
障害物のまわりにガイドラインのような情報をもたせて、
それに沿って移動するようにすれば？
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する瞬間に重くなるなら分かるけど、後々にも響くってのは
理解できませんよね。
上下前次1-新書関写板覧索設栞歴
あと 100 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.021s