ゲームプログラミング相談室

**プチ9627ｍ** · 01/11/06 18:47

ゲームプログラミング全般についての質問スレッド。
駄スレ立てる前にココで聞きましょう。

■旧スレ（プログラミング技術板より）
○パート１
http://piza.2ch.net/tech/kako/969/969984472.html
○パート２
http://pc.2ch.net/test/read.cgi/tech/985540361
○パート３
http://pc.2ch.net/test/read.cgi/tech/1002894129/

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

すいません、環境は

VS.NET
C++
DirectX8

です。

**名前は開発中のものです。** · 02/10/22 20:41

どうやるもなにも自分で好きなように変えれば良いだけ

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

>>742
初心者スレ向けの内容だね。

「普通に読めない」というのは、暗号化（スクランブル）の場合と
圧縮の場合がありますが、それぞれについて。
スクランブルに決まったやり方はありません。
なぜなら、決まった暗号化の手続きがあるのであれば、
決まった複号の手続きで簡単に戻されてしまい、暗号化の意味が無いからです。
ですが、全部1bitローテートするだけで普通に読めなくなるので
簡単なものでも問題なしかと。

圧縮については、辞書圧縮や動的ハフマン法、ランレングス法といった
有名なアルゴリズムがありますのでそういったものを利用する場合が多いようです。
具体的なアルゴリズムは文献を調べるなりネットで調べるなりしてください。

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

マップの書き方はどういうのがいいのやら

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

先頭に余分なものを追加するなり1ビットずつ反転するなり好きにするよろし

拡張子だけ変えて実はgifそのもの、なんてのもあったなー。すぐばれるけど。

**名前は開発中のものです。** · 02/10/22 23:38

>>746
どんなマップ？
平面なら二次元配列でいいと思うが。

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

逆汗すれば終わりだなー
名かには逆汗ブロックするものもあるけど

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

>>749
ん？　発想が逆だと思うよ。

「リバースエンジニアリングされたら終わり」じゃなくて、
「リバースエンジニアリングされなきゃ大丈夫」。
平文で読まれなきゃ読める人は大きく限定されるわけだからね。

でも、解析されても、個人製作のソフトにそこまで情熱を傾けてくれるのなら
それはそれで嬉しい気もする。

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

ゲーム製作者に質問です。

正直、Vectorにある数多くのフリーゲームで、何割くらい(または、いくつくらい)が
遊べるゲームだと思っていますか？

人によってかなり答えが異なると思いますが、みなさんの意見を聞かせてください。

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

プログラミングとの関係がないなら雑談スレでやろうよ・・・

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

>>751
http://game.2ch.net/test/read.cgi/gamedev/1007129482/84n-

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

>>751
個人的にはゼロ。
ぜんぜん遊べん。

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

タスクあるいはジョブコンと呼ばれるリアルタイム処理なプログラミング技法上で
再帰処理が必要な思考ルーチンを組まなければならない場合、どうやってますか？

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

製作中断

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

>>755
ageないと質問に答えてもらいにくいよ
急いでいないならいいが

**755** · 02/10/24 19:37

>>757
急ぎではないのでﾏﾀｰﾘ待ちます。

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

>>755
・マルチスレッド
・再帰処理をタスクシステムへ載る様に組み直す

パッと思いつくのはこれぐらい。

**名前は開発中のものです。** · 02/10/24 20:59

>>754
そんなことはない。少なくともゼロではない。

>>760
必死だな(w

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

>>760
なんでそんなに必死なの

**名前は開発中のものです。** · 02/10/24 22:06

warata

**名前は開発中のものです。** · 02/10/24 22:50

ﾜﾛﾀ

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

こんな事で笑っていてはいけません。
もっとおかしい事はたくさんありﾏﾝｺ｡

**755** · 02/10/25 10:46

>>759
２番目の奴の詳細解説キボン。
擬似スタックを作るんだっけ？

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

おまいらは、そんなにも擬似とつけたいのでつか？
おまいらが、いまよんでいるのは擬似文字でつか？

**名前は開発中のものです。** · 02/10/25 14:59

擬似じゃなくて仮想なら無問題？

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

いまここにある文字は
おまいらにとっては仮想文字なんでつね？

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

ごめん、virtualにしといて

**755** · 02/10/25 16:07

仮性ホーケーは黙ってて欲しいな >768

**759** · 02/10/25 17:17

>>765
そういうことです。配列にスタックを作って自前で管理し、ローカル変数を
そのスタック上に置きます。
再帰を単純なループに開いた上、タスクシステム上でまわす事になります。

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

DirectXフルスクリーン＠C言語で、
ユーザーからの入力文字（漢字変換とかもアリ）をげっちゅーするには
やっぱりInputBoxのAPIしかないのでしょうか？

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

XindowsXP HomeEditionを使っているのですが、
自分のプログラムを実行するごとに重くなっていきます。
プロセス自体はちゃんと終了しています。

windowsって、プログラム終了時にメモリの解放って行ってくれないんですか？
まぁ、自分がメモリリークをつぶさなければいけないのですが。

特に、大き目の画像を扱った後にそのような現象がおきるみたいです。
どうなんでしょう。

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

>>773
タスクマネージャに該当プロセスがないことは確認したかい？

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

はい、確認しました。

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

解放は自動的に行われることになってるし、XPはNT系だからさらに安全なはず。
ただしこれはドライバが正常に動作していればの話。
ディスプレイドライバを更新するとかしてみれば？

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

メモリ確保して開放せずに終了したら駄目じゃん。

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

>>777
プロセス終了時のメモリ解放は
OSの管轄ですが何か？

メモリリークが問題になるのは
長時間常駐するプロセスだけ

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

不正な処理で終了した場合も開放してくれる？

**名前は開発中のものです。** · 02/10/26 03:54

>>779
まさか、しないと思ってるのか？

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

Win95のころはひどかったな。
一応OSが開放してくれるハズだが、
それを過度に期待したプログラムを組むのは避けた方が無難。

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

関係ないけど、windowsでプログラム書くんだったら
確保したメモリは必ず自分で解放しなくちゃダメだよ。
OSを信用する方が悪い。

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

ＯＳが開放してくれるとしても、それはあくまでも開放ミスに対する
救済措置と思ったほうがいい。確保したメモリは必ず開放するのが鉄則。

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

またmalloc&freeネタか・・・飽きないねえ

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

>>783
> ＯＳが開放してくれるとしても、それはあくまでも開放ミスに対する
> 救済措置と思ったほうがいい
そりゃ違うだろ。

そもそも仮想記憶を使ってる OS の場合、ページテーブルやら TLB (*1) やら
は OS 以外は触れない。そこにバグがあると疑い始めたら、もはやアプリケー
ション側でとれる対策は何もないよ。

(*1)
IA-32 だと TLB はソフトウェアからいじる必要はない（ページテーブルをハード
が勝手にコピーしてくれる）けど、MIPS などは TLB ミスが起きると例外を発生
して、OS が自前で埋める必要がある。

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

どんな環境でも開放しなかったメモリの後始末をしてくれる
という保証は無いからメモリリークするようなプログラムは
そもそも欠陥品と見ていい。だから開放しないと駄目。
それにＯＳが開放しなかったからといって、それはＯＳの
過失ではない。プログラム作った奴が悪い。

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

786でまとまりました。

では次の話題。
↓

**名前は開発中のものです。** · 02/10/26 15:24

実験に使いたいのですがOSがリソースを開放できない終了方法を教えてください
いくらやってもけしからんことに勝手に開放されてしまいます

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

>>788
Win98でRPCだか何だかを使うと起こりやすいそうだ
使ったことないけど

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

>>788
ＤＯＳ環境とかゲーム専用機等ならたぶん開放しないのでは。

**名前は開発中のものです。** · 02/10/26 22:41

>>745
アルゴリズムが公開されている暗号もある。

>>755
タスクと再帰処理がなぜ両立できないのか分からん。

>>788
何の実験に使うのか知らんが。
ファイルや共有メモリ等、OSが勝手に解放することがないリソースは存在する。
存分に使え。

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

>>786
そもそも「どんな環境でも」なんて言い出したら、それこそ malloc/free がない
世界とか、あっても C 言語の規格書に従ってない環境まで出てくるから、議論
にならんよ。

規格書を行間まで読めば、C 言語の hosted environment を前提とする限り
malloc したメモリは OS に解放されるはず、が結論。

だいたいヒープの仕組みとか仮想記憶の仕組みを知っていれば、そんなに
ビクビクする必要はないと思うんだが。解放されないって、実際にどんな環境
を想定してるんだ？

（スタイルとして解放する方が良いかは別問題な）

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

つーか、解放しないと再利用できないじゃん？
こまめに解放してメモリを開けたほうがいいと思うんだが。

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

ＰＳ２のアルファブレンド設定を
DirectXでもやりたいのですが、　そういうことはできないのでしょうか？
たしか　こんな計算式
　C　=　（A+B）>>7+D

　　　A:　と　B:
　　　ソースのカラーか　フレームバッファのカラー
　　　
　　　D:　ソースかフレームのアルファ値

**名前は開発中のものです。** · 02/10/27 03:45

>>794
IDirect3DDevice8::SetTextureStageState( )

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

>>793
ところが大抵の処理系では
freeは解放済みフラグが立つだけで
実際に解放されるのはプロセス終了時なんだな・・・

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

JAVAなんかはガベッジコレクションを行ってくれるけどね。

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

>>796
それじゃfree自体存在意義ねーじゃん

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

>>798
けど同じプロセスが再び○allocするときは
その解放済みの領域からメモリ確保するので
あながち無意味とも言えない

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

>>798
一種のキャッシュだよ。まっとーなメモリ保護のある環境下で OS を呼び出して
メモリを割り当ててもらうのは

　ソフトウェア割り込みによる特権モード変更
　割り込みハンドラでのレジスタの待避などの定型処理
　 (ここで OS のメモリ割り当て関係のコードに入って)
　各種制限のチェック（たとえばユーザあたりのメモリ割り当て越えてないか、
　とか)
　仮想記憶のページテーブル、TLB の変更
　 OS の持つ仮想記憶レイヤーにおけるページエントリの変更

と、いろいろ手間がかかる。ユーザ空間で完結できれば、それに越したことはな
い。

このあたりは使ってるライブラリによっても変わってくるけど、昔の UNIX だと
一度 malloc したら二度と OS には返さないのが一般的で、最近でも条件 (*1)
が揃わない限りはまず返さない。

本当に OS からメモリを短時間・大量に借りたいなら malloc/free なんか使っ
ちゃダメです。mmap() とか VirtualAlloc() とか使いましょう。

(*1)
ヒープの端っこが free() されるとか、ページ単位で連続した空間が free される
とか。この条件を緩くして OS 側に返すチャンスを増やそうとすればするほど、
malloc/free が内部で管理・チェックするデータが増え、割り当て・解放に掛か
る時間もメモリ消費も大きくなるというトレードオフがある。

たとえば Solaris だと libc, libmalloc, libmapalloc あたりに実装が異なる
malloc/free がいくつかあるから、ソースを眺めながら処理速度を比べてみると
勉強になるよ。

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

検索で調べてみたが、実際メモリリークは問題になって
るからメモリ開放しないプログラムを書くのは良くないと思う。

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

>>800
Win32の場合、mallocもVirtualAlloc呼び出してんじゃないの？
同様に、freeはVirtualFreeって感じで。
メモリマップはこれらとは違うだろうけど。
思い切り勘違いなら、ごめんな。

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

＞Win32の場合、mallocもVirtualAlloc呼び出してんじゃないの？
Win32じゃなくてCのランタイムライブラリの実装次第

＞思い切り勘違いなら、ごめんな。
あやまるくらいなら最初からいい加減なことは書くな

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

>>802
malloc() したら毎回 VirutalAlloc(), free() したら毎回 VirtualFree() してると
思ってる？　んなこたないって。ソース読めば明白なんだが、msvcrt.dll だと

1. VirutalAlloc() 系ではなく一つ抽象度が高いHeapAlloc() 系を使っていて、
　こいつがユーザ空間でいろいろメンテナンスしていてる。
2. それに加え C Runtime Library 内部でも、小規模なメモリ割り当てに関して
　毎回 HeapAlloc(), HeapFree() を呼ばないで良いようにキャッシュしている。

と、OS 直のメモリインターフェースから 2 枚の皮をかぶせてある。

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

あと OS が提供するメモリ割り当てのインターフェースは、基本的にページ単位
でしかメモリを割り当ててくれない。VM とか CPU アーキテクチャによるんだが、
たいてい 1 ページは 8192 バイト前後。

だから小さなメモリブロックを割り当てるときに毎回 OS を呼んでるとムダに
なるメモリも莫大になるんで、

　でっかいメモリブロックを OS からもらってきて
　そいつを小さく切り刻んだ上で malloc 呼び出してきた側に返す

っつー仕組みにしてる面もある。

（あと昔の OS だと、そもそもメモリブロックを割り当てるような API を提供
してなかったりな。brk() とか sbrk() で検索してみ）

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

メ　モ　リ　リ　ー　ク　が　イ　ヤ　な　ら
　Ｊ　ａ　ｖ　ａ　で　も　つ　か　っ　て　い　ろ　

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

>>804
2. はたしか廃止されたような気がする
今手元にないのでわからんが、どっかで見た

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

802だけどよ

malloc=VirtuaｌAlloc呼び出しで解決されてるんじゃないか、
と思ったんで、質問の意味もあって書いてみたんだが。

それをいい加減とか決め付けてる>>803氏んどくように。

あと、HeapAllocは既に廃止されてるはず（MSDN libに載ってたと思う）
今のWin32では、HeapAllocは内部でVirtualAllocを呼び出してるんじゃなかったかな。

**名前は開発中のものです。** · 02/10/27 23:34

いろんなmallocの実装を紹介するスレはここですか？

**名前は開発中のものです。** · 02/10/27 23:47

>>808
HeapAlloc が内部で VirtualAlloc を呼び出してるのは確かだが、単なる
ラッパじゃない。内部で色々処理をしてる。

それと廃止されたのは GlobalAlloc(), LocalAlloc() だろうが。嘘八百を
並べるなよ……。

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

>>810
訂正さんくす。

HeapAllocが廃止されたってのは、勘違いだったよ。
廃止されたのはGlobalAlloc/Freeで、HeapAlloc/FreeはVirtualAllocで
確保したメモリをヒープ構造で管理してるってことなのね。
Win32APIで開発する時は、たいていHeapAllocと同じことを自前でしてるせいで、
よく知りませんですた。

ご指摘さんくす、と同時に、嘘八百とか書くなよ、ぼけ。

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

それじゃ今後は同様の事態を表現するときは嘘七百五十くらいで。

**名前は開発中のものです。** · 02/10/28 03:11

>>811
> HeapAlloc/FreeはVirtualAllocで
> 確保したメモリをヒープ構造で管理してるってことなのね。
全然違うぞ…。なんでそこでヒープ構造が出てくる？

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

>>802,808,811
いいかげん。うそはっぱく。よくしらないのにしったかぶり。
晒しsage

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

>>806
JavaやC#がメモリリークないと思ってるヤツ発見
http://www-6.ibm.com/jp/developerworks/java/010824/j_j-leaks.html

**名前は開発中のものです。** · 02/10/28 11:57

うーん、微妙に話題ズレてない？
>799も言うとおり、解放済みマークのついた領域は再利用される。
（そのためのfreeだろ？）
だから、mallocにラッパーが掛かってようが掛かってまいが、
>793が原則として正しいということでいいんでないの？

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

確保したら必ず開放しなくてはいけないと思ってたほうが無難だよ。
そのほうが余計なトラブルの心配しなくて済むじゃん。

**名前は開発中のものです。** · 02/10/28 20:30

>>817
俺は

free(p);
free(p);

とかやって、メモリ領域壊したことがある。実際にはこんな簡単なコードじゃ
なくて、サイクルのある複雑なデータ構造で、遠く離れた関数で実行されて
たんだが。

結局、そのデータ構造扱う部分は「でっかくメモリを取って中で使い回し、
使い終わったら丸ごと free する」っつー方針で書き換えました。

**名前は開発中のものです。** · 02/10/28 20:38

普通、

free(p);
p=NULL;

ってしない？

**名前は開発中のものです。** · 02/10/28 20:49

>>819
しない。そもそも p に相当するものが関数の引数として渡ってくる場合には、
それって無理だし。

free_something(void* p)
{
　　free(p);
　　p = NULL;
}

func()
{
　free_something(p);
　// p は相変わらず NULL じゃない
}

これは極端な例だけど。あとサイクルがあるデータ構造だと、解体する順番
やタイミングが非常に難しい。コンパイラを書くときに良く出てくる DAG 程度
のデータ構造でも、気を付けないとすぐ二重 free しちゃうよ。

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

ttp://isweb43.infoseek.co.jp/art/yn515/game.gif
こういった感じのゲームを作ろうと試みています。
フィールド上をクリックすると、キャラがそこへ歩いて行くような。
ですが、障害物なんかを遠回りして避けていくようにするにはどうすれば
いいのか見当もつきません。どうしても凹んでいるところでつっかかってしまいます。
皆様のお知恵をお貸しください。おながいします。
ちなみに言語はＨＳＰです。

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

>>821
絶対に答えが出るアルゴリズムだと A* とかかねぇ。

**821** · 02/10/28 22:50

>822
検索してみましたが、適当なところが見つかりませんでした。
A*とはなんでしょうか？

**名前は開発中のものです。** · 02/10/28 23:11

クォータビューのマップで当たりをとりたいんですけど
高速なやり方ってあります？
内部的にはトップビューというのではなく、
クォータビューそのままでマップとキャラの菱形の当たりをとりたいのですけど…。
動作環境はへちょいので浮動小数点とか線分の交点などを求めないような軽いのを考えているのですが。

**名前は開発中のものです。** · 02/10/28 23:30

その当たり判定で何をやりたいかによると思うんだが

**名前は開発中のものです。** · 02/10/28 23:47

>>821
とりあえず障害物で行き詰まったら、障害物の表面に沿って
目標に到達できそうな位置まで移動してみるというのはどうか。

**824** · 02/10/28 23:51

>>825
クォータビューのマップを主人公が歩くとき、マップと当たりをとりたいのです。
高さがない似非クォータビューなので、それほど苦労しまい、と思っていたら
あまり芳しい結果になりませんでして。
マップが歩けるような当たりなので、常時判定するという方向性で軽くしたい、とそういうことなのです。

**821** · 02/10/28 23:55

>>826
その障害物が岩とかだったら、どっち側に避けても目的地までいけるんですが、
＿＿＿　＿＿＿＿■＝キャラ　○＝クリックした場所
　　／　＼
■ ｜　　｜○
　　＼＿／

この場合、上を周って行こうとすると当然ひっかかっていけませんが
下を通って避ければ目的地までいけますよね。
こういう風にケースバイケースでどっち側に避けるかどうやって
判断させればいいのかがわからないんです。
わかりにくかったらスミマセン…

**821** · 02/10/28 23:58

ずれちゃった…なんとかわかってください（汗　＜図
つまり、出っ張った障害物なんかをちゃんと
キャラが通れるコースを歩いてくれるようにしたいのです

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

>>824
1)床だけの画像を描画する
2)キャラの足元付近のドットの有無で判定する
3)マップの残りとキャラを上書き描画する

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

>>828
ひっかかったら辿りかたを反転させれば？

**824** · 02/10/29 00:24

>>830
ワンダーウィッチなのでそうもいかないのですよ…。すみません。

**821** · 02/10/29 00:28

>>831
やはりそれしかないですかねぇ…（汗
下手したら明らかに違う方向へ歩いていって、引っかかったら
今気付いたように遠回りをする…なんかスマートじゃなくないですか（・-・;;

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

>>833
それじゃ内部的に表示より先行して動かしておいて、未来の自分が
引き返してきたらその場で反転するようにすれば多少マシになるのでは。

**821** · 02/10/29 00:34

あーなるほどぉ…それもそうですね
どうもありがとうございます。試してみます。（_ _

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

>>824
マップの床が碁盤の目のようになっていて、床の升目が全て同じ大きさ
同じ形であるなら、床の升目と全く同じ形状のイメージデータを配列
などで用意して、升目の座標と判定点の座標からイメージ内に対応する
座標を求め、その座標の点がセット状態であれば当たりとする。

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

>>828
一番いいのは、袋小路にならないマップを作ることですが。

そうもいかない、というなのなら、下の図みたいにマップを
大きなブロック（エリア）に分けてやるとか。
（いつかこの板で公開された進路探索方法）

A1 A2 A3
＿＿＿　＿＿＿＿
　　／　＼
■ ｜B2　｜○
B1　＼＿／ B3

C1 C2 C3

　B1 → C1 → C2 → C3 → B3

**837** · 02/10/29 01:21

うわー、直したはずが大きくずれた。　すまん。

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

>>821
１：現在位置から目的地までの直線を引く

２：その直線が障害物と交差していたら交差した点から
移動できる方向へ直線を引いてみる（左右どちらにも行けるならどちらも）

３：枝分かれした線分はできるかぎり目的地へ向かうように折り曲げていく

４：現在の走査位置と目的地とを結ぶ直線が
走査線の角度と同じになったら１へ戻る

Ｎ：先に目的地にたどり着いた方が正解ルート

折れ曲がった位置と角度を配列に保存しておけば
それをトレースするだけ

計算中も枝分かれする直前までの移動をしていけば
迷路にでも迷い込まない限りそれほど時間はかからない

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

図解するとこう
＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　／＿,,. ＼-─●目的地
☆-─''''''''│~　　　 │
　　　　　↑＼＿＿／
　　　　　交差点

＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　／＿,,. ＼-─●目的地
☆-─'''''''|.│~　　　 │
　　　　　 iヽ＼＿＿／
　　　　　 : 　＼　　　　できるだけ目的地の方向へ
　　　　　 :　　　＼→

＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　／＿,,. ＼-─●目的地
☆-─'''''''|.│~　　　 │　 /
　　　　　 iヽ＼＿＿／／
　　　　　 : 　＼＿＿／

**名前は開発中のものです。** · 02/10/29 06:41

>820
解放したポインタにNULL代入するのは作法でしょう。
どうしてもめんどうなら、ちょっと気持ち悪いけど
free_something (void **p) {
free(*p);
*p=NULL;
}
func() {
free_something(&p);
//p=NULL
}
でいいのでは。
というか、そういうところで面倒くさがる人はC++を使うべきでは。

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

なんでややこしい方へ向かうかなぁ…

＿＿＿＿＿＿＿■＝キャラ　○＝クリックした場所
　　／　＼
■｜　　｜○
　　＼＿／
　　　Ａ

ひっかかりそうなところにはポインタを作っておく。
■から○へ行く時、間にポインタがあれば
まずそこへ向かうようにする。

　　　　　 ■
|￣￣￣￣￣￣￣￣|
|　Ａ　　　　　　 |
|　　　　　　　　 |
|＿＿＿＿＿＿＿＿|
　　　　　 ○

ポインタの捜索範囲はキャラ→クリック間の長方形。

以上！