[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 701- 801- 901- 2chのread.cgiへ]
Update time : 05/09 17:16 / Filesize : 258 KB / Number-of Response : 918
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

【初心者】スレを立てる前にココで質問を【Part18】



1 名前:名前は開発中のものです。 mailto:sage [2008/10/09(木) 20:13:28 ID:0XIZWRlM]
疑問に思うことがあれば、スレを立てずに、まずはココで質問。
スレッドを立てる前にはローカルルールを読みましょう。
pc11.2ch.net/gamedev/

>>980 を踏んだ人は次スレ立てをお願いします。
【アップローダ・避難所・Wiki】
ゲーム製作技術板公式Wiki
gamdev.org/w/

ゲーム製作技術板公式アップローダ
gamdev.org/up/

ゲーム製作技術板公式掲示板避難所
bbs.gamdev.org/gamedev/

ゲーム製作技術板予備
yy13.kakiko.com/gamdev/

アップローダー予備
gamdev.hp.infoseek.co.jp/

gamdev.orgが落ちるたびにあげてみるスレ
pc11.2ch.net/test/read.cgi/gamedev/1107022166/


875 名前:名前は開発中のものです。 mailto:sage [2009/03/02(月) 17:39:35 ID:iJMzbuhK]
>>874
文脈で変わるとは思うけど
ゲームやソフトウェア分野では専門処理を行ってくれる
汎用性が高いプログラムライブラリのことなんじゃね

ja.wikipedia.org/wiki/%E3%82%B2%E3%83%BC%E3%83%A0%E3%82%A8%E3%83%B3%E3%82%B8%E3%83%B3

876 名前:名前は開発中のものです。 mailto:sage [2009/03/02(月) 18:40:25 ID:O6ibebek]
>>872

ありがとうございます。
とりあえず今日はそういう場所を見つけることを目標にしようと思います。

877 名前:名前は開発中のものです。 mailto:sage [2009/03/03(火) 10:25:38 ID:aC0MgDxU]
シューティング作ってて、
自機の近くにある弾だけと当たり判定をするようにしたいのですが、
2次元上の距離の近さを1次元で表現するようなことってできませんか?
下のように画面に番号を振ると自機が13にいるとき、上下左右の弾と判定するのに
8〜18の範囲の弾を判定しなくちゃいけなくなり11 15 の弾と
の無駄な判定が出てしまいます。
5×5だとそれでもいいけど画面が広いと結構無駄な計算が発生するので・・。

1 2 3 4 5
6 7 8 9 10
11 12 13 14 15
16 17 18 19 20
21 22 23 24 25

878 名前:名前は開発中のものです。 mailto:sage [2009/03/03(火) 10:42:22 ID:OTlbnBJs]
総当たりで当たり判定をとるって、大変そうだけどゲーム製作では普通

重いゲームはほとんど計算部分よりも描画のせい
例えばゲーム画面が640*480なら、ドットの数30万をそれぞれ計算してるって考えると
当たり判定の計算なんてたいしたことない

879 名前:名前は開発中のものです。 mailto:sage [2009/03/03(火) 11:00:38 ID:aC0MgDxU]
>>878
弾と弾をぶつけて消そうと思ってるんだけど
(弾ごとに自機のような計算が必要になる)
それでも描画のほうが重い?

880 名前:名前は開発中のものです。 mailto:sage [2009/03/03(火) 12:29:43 ID:6Eet7zAZ]
画面上全ての弾と当たり判定を計算するのと
画面上全ての弾との距離を計算するのは
処理として等価だろう。

881 名前:名前は開発中のものです。 [2009/03/03(火) 12:34:00 ID:vQ464eyf]
>>879
CPUは一秒間に一万回以上計算できます

画像処理と計算どっちが重いかって、そんなの比べるまでもない

882 名前:名前は開発中のものです。 [2009/03/03(火) 13:00:16 ID:8YEdO1Hm]
自機を円で近似すれば比較一回

883 名前:名前は開発中のものです。 mailto:sage [2009/03/03(火) 13:05:53 ID:5imbcKrj]
リカーシブディメンショナルクラスタリング使えばいいじゃん
総当たりよりは高速だろ
でも確かもっと速い方法があったな



884 名前:名前は開発中のものです。 mailto:sage [2009/03/03(火) 15:24:45 ID:e47eJq+H]
>>877
多分空間分割が必要な場面は
1、衝突判定対象が1万以上とか馬鹿多い
2、OBB(3Dの非軸平行なバウンディングボックス)同士など、複雑な場合。

2に関しても、あまり細長い判定対象がなければバウンディングスフィアで判定してからOBB判定、とかやれば空間分割しなくてもよさそう。
2Dならバウンディングボックスも必要なく回転矩形程度だろうから必要あるのかなぁ


>>883
ググってもでてくる気配がない・・・ぐすん



885 名前:名前は開発中のものです。 mailto:sage [2009/03/03(火) 15:40:38 ID:4wKwtDfl]
Recursive Dimension Clustering の話?

886 名前:名前は開発中のものです。 mailto:sage [2009/03/03(火) 15:42:37 ID:4wKwtDfl]
Recursive Dimensional Clustering か。ヒットしたページをコピペしたらDimensionだった

887 名前:名前は開発中のものです。 mailto:sage [2009/03/03(火) 19:13:52 ID:ezGJoFgw]
>>877
例えば…

struct KATA
{
int x, y;
};
static KATA array[] = {
{-5, -1}, {-5, 0}, {-5, 1},
{ 0, -1}, { 0, 0}, { 0, 1},
{ 5, -1}, { 5, 0}, { 5, 1},
};

for(int i = 0; i < siezof(array)/sizeof(KATA); i++)
{
hantei(X + array[i].x, Y + array[i].y);
}

…みたいな。5とかは定数で宣言したほうがお洒落かな。
実際の判定とか範囲チェックとかはよしなに。

888 名前:名前は開発中のものです。 mailto:sage [2009/03/03(火) 19:38:53 ID:J9hOuuPk]
>880-881
弾と弾との当たり判定がいるから
1000個の弾なら単純計算で1000×1000で1000000回の計算になる。
1000までなら問題ならんかもしれんが1万なら1億とかになる。
(そこまでの弾使うかどうかは別問題として)
それが秒間60回とするとそこまで無視できるかどうかは疑問だと思った。

仮に877ができればソートされたリストから
indexの近い番号の弾だけを比較すればよくなる。

>>883-886
サーセン、趣味グラマ程度なんで理解できませんでした。

>>887
違ったらごめん、
もしかしたら対象が決まった状態で個別の判定の処理を軽くする方法を書いてる?
俺が知りたいのは判定処理の回数を減らす方法だ。
でもこれはこれで参考になりそうだ、サンクス。

889 名前:名前は開発中のものです。 [2009/03/03(火) 19:44:56 ID:8YEdO1Hm]
銀河シミュレータではないんだ。 厳密解はいらないだろ
玉の数を減らせよ。 1000も玉が表示してあったら見にくいだろう

890 名前:名前は開発中のものです。 [2009/03/03(火) 19:49:45 ID:8YEdO1Hm]
3次元立方体の中に、玉を生成して衝突が起こる回数を計測する。
以下に速くできるかを競う。
たとえば100Mの立方体で玉を5cmなどとする。あとの設定は適宜。

891 名前:名前は開発中のものです。 mailto:sage [2009/03/03(火) 20:46:49 ID:5CFQdrST]
>>888
弾が壁で反射するとかでなければ、
自分が発射した弾同士の判定は削れる可能性が高い。
弾速度が違って自分が撃った弾すら打ち消せるとか無ければね。

自機の発射した弾と敵が発射した弾という区別がつけばいいから、
演算回数の枝切りは可能だと思うよ。
面倒だけど。

弾が全て円のあたり判定なら弾同士のコリジョンは楽勝だからどうにでもなるし、
高速化を考えるなら、判定を1ドットにするという方法もある。

892 名前:名前は開発中のものです。 mailto:sage [2009/03/03(火) 21:33:09 ID:dkloOCHD]
1000も弾があるような弾幕ゲーは
当たり判定が1ピクセル分とかそんなもんだな。
RPGだと衝突判定をフレーム単位でスキップするケースもあるみたいね。
まぁどの道、分割判定なりなんなりは処理が重いと思ってからやれば良いよ。
すっぽどスパゲティーなコーディングしない限り、
後からコードを変更するのは難しくないはず。

893 名前:名前は開発中のものです。 mailto:sage [2009/03/03(火) 21:34:05 ID:J9hOuuPk]
>>889
ゲーム内容説明するのがメンドイからはしょるけど
広いフィールドを動き回るイメージなので弾はあまり減らせない。
(フィールド内の弾幕の密度が下がる)
だから、減らさない手法で高速化できる方法を探してる。

>>891
それもひとつの手だと思って考えとくわ、サンクス。

測ってみた感じだと
現状の状態だとやっぱり弾の判定が1000個ぐらいから極端に重くなって
システムを圧迫しだす。

とりあえず考えてるのが、

フィールドを5×5ぐらいに分けてその中で判定するというもの。
フィールドの切れ目とかの判定がおかしくなるからあまりやりたくない。

xの値でソートしたリストを用意して
yの値がかぶるかどうかを判定。
フィールド内を動き回るのでやっぱり無駄な判定が多くなる。
listを定期的にソートする必要がある。

よい案が出ないから下をやって問題ないかどうか
様子を見ようと思ってる。



894 名前:名前は開発中のものです。 mailto:sage [2009/03/03(火) 22:00:25 ID:9mcFBbl3]
>フィールドの切れ目とかの判定がおかしくなるからあまりやりたくない。
隣接フィールドも併せて判定すればいいだろ

895 名前:名前は開発中のものです。 mailto:sage [2009/03/03(火) 23:03:57 ID:ezGJoFgw]
情報後出しですねわかります

896 名前:名前は開発中のものです。 mailto:sage [2009/03/04(水) 00:04:14 ID:xmkv8/CD]
えー…、本気の質問なのでどうか引かずに教えてください

アドベンチャー形式で、ある人物の立ち絵が画面に一つありまして、
話しかけるたびに違うコメントをする、というゲームを想像してみてください
その会話パターンだけを趣味でコツコツ作ってたんですね、3000通りほど
だいぶ溜まったのでそれを本当にゲームにしたいなと思ったのですが
ゲーム製作の知識はまったくないのです。

それで、簡単に作れるようなフリーのADV製作ソフトや、
それを使用したゲームで改変が許されてるものなどはありますでしょうか?

897 名前:名前は開発中のものです。 mailto:sage [2009/03/04(水) 00:11:07 ID:7UHlvhIC]
すげー気持ち悪いが、人工無能とか勉強してみれば

898 名前:名前は開発中のものです。 mailto:sage [2009/03/04(水) 00:18:18 ID:csabQCX4]
ゲーム作成より自然言語処理の研究に進むことを薦める
参考書籍を一つ挙げておく。
「恋するプログラム―Rubyでつくる人工無脳」

899 名前:名前は開発中のものです。 mailto:sage [2009/03/04(水) 00:23:25 ID:xmkv8/CD]
人工無能ですか? うーむなるほど、それは使えそうですね
フリーソフトでもたくさんあるようなので、利用できそうなのを探してみますね

900 名前:名前は開発中のものです。 mailto:sage [2009/03/04(水) 01:24:17 ID:NGIX5+Ih]
会話パターンが大量にあるなら伺か(デスクトップマスコット)を
作るのもいいかもな

901 名前:名前は開発中のものです。 mailto:sage [2009/03/04(水) 08:21:16 ID:/zOtMtBD]
一時期はやってた
ja.wikipedia.org/wiki/伺か
この辺とかが向いてるんじゃない?
使ったことないからできるかどうかはわからんけど。

902 名前:名前は開発中のものです。 [2009/03/05(木) 12:15:09 ID:vCwVAC+C]
>896
とりあえずHSPでゴニョゴニョしてみたら?

903 名前:名前は開発中のものです。 mailto:sage [2009/03/05(木) 18:29:00 ID:OJHQDXBE]
質問に忠実に答えるとフリーのADV製作ソフトはたくさんある
たぶんNScripterか吉里吉里のユーザーが多い(前者のほうが簡単)
それを使用したゲームで改変が許されているケースはほとんどない

>>903
HSPは自力でバックログやセーブシステムを実装しないといけないから
特殊なシステムを使いたい場合を除いてADVツールのほうが向いている



904 名前:名前は開発中のものです。 mailto:sage [2009/03/05(木) 19:18:35 ID:CwokJJKn]
うん。ADVなら吉里吉里とかNスクのがいい
まぁHSPでも出来ないこたないが

905 名前:名前は開発中のものです。 mailto:sage [2009/03/05(木) 23:04:49 ID:QF+GPlPd]
C/C++のフォントについてなのですが、
アクションゲームの「HPの数値」など
頻繁に書き換えなければならないの文字の描画は
何を使うのがお勧め/定番なのでしょうか?

手元にはD3DXCreateFont、デバイスコンテキストの資料が有るのですが
どっちも「処理が重いのでノベル程度に」などと書かれていて・・。

数値だけはドット絵等で用意して、日本語だけそういう処理に頼るなど
分けるのが定番なのでしょうか?

906 名前:名前は開発中のものです。 mailto:sage [2009/03/05(木) 23:11:31 ID:QpvwXMOT]
まずは頻繁に書き換える頻度を明示しろ
1秒間に何回書き換える?
話はそれからだ

907 名前:名前は開発中のものです。 mailto:sage [2009/03/05(木) 23:48:32 ID:1d/NzH52]
>>905
フォントでやっておいて、速度に問題がでてきたらドット絵を用意。
後でプログラムを書き換え・差し替えるのがそこまで難しくなさそうな部分は問題が出るまで放置でOK。

908 名前:名前は開発中のものです。 mailto:sage [2009/03/06(金) 02:54:40 ID:7nYZ0Zsi]
マルペケにフォントをテクスチャにする方法が書いてあるだろ

909 名前:名前は開発中のものです。 mailto:sage [2009/03/06(金) 10:30:43 ID:4YMxwutE]
プロポーショナルフォントを諦めればテクスチャをキャッシュに使うのが
簡単でいい。文字コードからUV取得するハッシュテーブル

910 名前:名前は開発中のものです。 [2009/03/06(金) 14:11:37 ID:d8Rjwk95]
画像にしとけ

911 名前:905 mailto:sage [2009/03/06(金) 15:09:55 ID:mqlorO7U]
>>907 >>909 >>910
ありがとうございます。

>>908
あの関数は避けたいもので、すみません。

>>906
1秒に多くて10回 平均すれば2秒に1回ぐらいです。
処理が多い時に画面がガクガクし始めないかが心配でして‥

912 名前:名前は開発中のものです。 mailto:sage [2009/03/06(金) 15:49:29 ID:2NJ4kCLr]
HP表示なんてせいぜい10文字なんだから常時テクスチャーで保持して置けよw

913 名前:905 mailto:sage [2009/03/06(金) 17:36:57 ID:mqlorO7U]
そうですね・・
できればフォントの切り替えが出来るようにしたかったのですが
今回は画像で用意して、後で色々試してみます。
ありがとうございました。



914 名前:名前は開発中のものです。 mailto:sage [2009/03/06(金) 18:01:40 ID:k62Mxjk1]
何を言っているのかわかってないようだなw

915 名前:名前は開発中のものです。 mailto:sage [2009/03/06(金) 22:33:31 ID:Sz1YpuaK]
テクスチャに好きなフォントでテキストを描画すればいいだけなのに、
ビットマップを用意するとか言っている奴はどれだけ頭が悪いんだよ?

916 名前:名前は開発中のものです。 mailto:sage [2009/03/06(金) 23:55:27 ID:i8lra3Tz]
>915
別に画像で用意すること自体は何ら問題ないだろw


917 名前:名前は開発中のものです。 mailto:sage [2009/03/07(土) 00:06:51 ID:/IUWrmEE]
フォント次第だろうな。






[ 新着レスの取得/表示 (agate) ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<258KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef