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

**プチ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/

**718** · 02/10/10 19:15

>>723
違うだろ。さすがに。

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

ID3DXSpriteだと256*256以上の大きさのテクスチャを扱えないからじゃねーの？

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

そんな制限は無い

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

>>726
あるぞ。

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

>>708
> DirectDrawより簡単ではるかに便利。
DirectDraw は初期化と、ロスト時の再初期化処理だけで意外と面倒。

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

>>727
無い
サイズの制限はハード依存であってID3DXSpriteそのものの制限とは関係ない

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

どのみち相対的な話である。

**730** · 02/10/11 00:46

730は728へのレス。

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

＞725 ：名前は開発中のものです。：02/10/10 20:45 ID:pMa8asNt
＞　　ID3DXSpriteだと256*256以上の大きさのテクスチャを扱えないからじゃねーの？
＞726 ：名前は開発中のものです。：02/10/10 20:50 ID:???
＞　　そんな制限は無い
＞727 ：名前は開発中のものです。：02/10/10 22:57 ID:???
＞　　>>726
＞　　あるぞ。
＞729 ：名前は開発中のものです。：02/10/11 00:28 ID:???
＞　　>>727
＞　　無い
＞　　サイズの制限はハード依存であってID3DXSpriteそのものの制限とは関係ない
　
このやりとりは不毛だな。まず具体例書いてくれ。
　
　Windows98SE + DirectX8.1(debug runtime)
　GeForce256 (Detonatorﾄﾞﾗｲﾊﾞ 40.72)
　D3DCAPS8.MaxTextureWidth　 = 2048
　D3DCAPS8.MaxTextureHeight　= 2048
　
　Windows98SE + DirectX8.1(debug runtime)
　ATI RADEON ALL-IN-WONDER (ﾄﾞﾗｲﾊﾞ 4.13.01.9039 7.72-020524M-004273C)
　D3DCAPS8.MaxTextureWidth　 = 2048
　D3DCAPS8.MaxTextureHeight　= 2048
　
上記2つ例ではID3DXSprite固有のテクスチャサイズ制限(256x256)は確認できない。

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

チュートリアルの5だと多少の変更で実行できるので、とりあえずコード書いて動かしてみたが、
Drawだと左上から256×256の部分が表示されるだけだな。
GeForce2MXだからVoodooのような256×256の制限はない。

確かDirectX7の時にはこの制限がなかったと思うが。

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

Geforce3(32MB)で512*512テクスチャを試した。問題なく表示された。
ドライバは40.72 Beta

**734(補足)** · 02/10/11 03:44

環境はWin2k+DirectX8.1SDK

**734** · 02/10/11 03:50

>>733
2MXで問題が出るってことは結構メジャーな問題ぽいね。
HALドライバ依存の問題はいつも頭痛の種になるから欝。

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

テクスチャサイズが256x256に制限されるのは、
VooDoo系チップの場合じゃ、ホゲェェェ!!
そういうハード特有の事情を知らんやつが、
Direct3D触るとろくなことがない。

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

>>737
だからハードウェアの制限とID3DXSpriteの制限を分けろよ（藁

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

>>737
おまいのまなこたんは、ふしあなさんでつか？

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

要点は256×256以上のテクスチャサイズを扱えるにも関わらず、
ID3DXSprite・Drawだと256×256以上のテクスチャは使えないだな。

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

>>733
DirectX8.1bのランタイムと
ｎVidiaの最新ﾄﾞﾗｲﾊﾞを使ってみたか。

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

ゲームで、プログラム以外のファイルからデータを読み出したいのですが、
データを生で置きたくないのです。

他のゲームを見てみたら、結構暗号化(?)されてたりして読めないのがあるのですが、
あれはどうやっているのでしょうか。

セーブデータや環境設定。
jpeg画像。
midやwavファイル。

についてそれぞれ教えてください。

**名前は開発中のものです。** · 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*とはなんでしょうか？