シューティングゲーム製作技術総合 15機目

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


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

1 名前：名前は開発中のものです。 [2008/02/18(月) 12:02:20 ID:JNgyhRqZ]: ゲームプログラマなら誰もが通る、もしくは、通った道。青春の香り？
それは「シューティングゲーム製作」・・・。

このスレでは、そんなシューティングゲームの製作技術や技術の検証、成功談
失敗談笑い話、難易度の設定方法論、多弾の是非などについて語り合いましょう。
もちろんBulletMLなどで弾幕を作成してみたり、自分の作ったシューティングを
晒してみたり、プロジェクトをはじめてみるなどもOK！

ただし、シューティングの未来とか既存のゲームの話題などは、関連する他の
スレでやってくれ。

過去スレ，関連スレは >>2-3で。
188 名前：名前は開発中のものです。 mailto:sage [2008/03/28(金) 23:11:26 ID:ikErMOXa]: メガデモのメタボールの仕組みよく知らないんだが、あれって

　濃度を格納したボリュームデータを用意して
　ある濃度をしきい値にして面を張る

みたいな、ベタなやり方だったのかな
10年近く前にクラシックペンティアム積んだPCでぐりぐり動いてた
ような記憶があるんで、上記の手続きだと（特にボリュームデータの
更新、というかアニメーション？あたりが）かなり重たいものになりそうだし
やっぱ何らかのトリック（フェイク）が使われたのかな

あ、ソース公開されてる作品あるからそれ覗けばいいだろってのは分かってる
話題がないのでなんとなくネタ振りということで・・・

グニャグニャ（連続体？）オブジェクトが出現するSTGとか作ってみたいし
189 名前：名前は開発中のものです。 mailto:sage [2008/03/29(土) 01:52:02 ID:oF0Q5YC2]: ム板のメガデモスレ池
マジレス
190 名前：名前は開発中のものです。 mailto:sage [2008/03/29(土) 02:49:58 ID:4C1bZfLa]: >>188
ソフトレンダもので初代Pentiumでぐりぐり(60FPS以上で)動いてたなら
スクリーン解像度は400*300とか320*240程度だったはず
濃度値を収める三次元格子もかなり荒かったんじゃないかなぁ

濃度値の精度は8ビットで格子数は16*16*16=4096バイトとかで十分
この程度なら当時でも余裕で処理できたはず

つか、今時のビデオカードで2DSTGでメタボールっぽいキャラ出すなら
パーピクセルで描ける
法線マップとアルファ付きカラーマップにぼやけた円を重ね描きしていって
アルファテストで閾値設定して描けば立体感（光沢付き）ぷよぷよだよ！
DirectXのSDKにもそんな感じのサンプルが入ってたはず
191 名前：名前は開発中のものです。 mailto:sage [2008/03/29(土) 10:50:00 ID:p4/t7kS/]: 背景が黒いなら加算合成で出来ちゃうんだけどな。
192 名前：名前は開発中のものです。 mailto:sage [2008/03/29(土) 10:52:47 ID:PdR5kqA3]: メタボはメタボールの略だったのか。
193 名前：名前は開発中のものです。 mailto:sage [2008/04/01(火) 15:39:40 ID:3rITgYf3]: メタルボーク発進
194 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 00:38:42 ID:JN0z56Et]: 質問
CGってグラフィックボードで描いてるんだよね？
ハード的な理由で描画はマルチスレッドみたいになるの？
てことは、処理落ちの原因はほとんど当たり判定とかのせいになるの？
ということは、当たり判定をマルチスレッド分担すればいろいろ完璧？
195 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 01:02:14 ID:1TsuscT3]: 今時、当たり判定程度で処理落ちするCPUはない
プログラムにむちゃくちゃ無駄が多かったりしない限り

3Dならポリゴン数が多いと、GPUの性能次第で処理落ちするし、
物理演算があるとCPU性能次第で処理落ちするかな
196 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 03:26:09 ID:kdoRe4RJ]: >>194
「てことは」の前後の文脈がどういう理屈で繋がるのか知らんが、2DSTGの話をしてるなら
今時どんなヘボノートPC環境であろうとも「当たり判定」で処理落ちさせるなんて至難の業だな
5年近く前のモバノート(1GHz前後のペンM…当然シングルコア)でシングルスレッドの総当りで
敵50匹と弾1500発の処理やらせて普通に60fps出るんだから、この時点で既に「いろいろ完璧」
197 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 03:59:52 ID:VspohKvQ]: そのスペックで1500の総当りってどう考えてもきつい気がするんだけども・・・
198 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 07:15:31 ID:69exqbeK]: ウチのご隠居チンコパッドX31が初代セントリーノの1.2GHzで
だいたい同世代みたいだけど、1500個くらいならイケてる

ビデオチップがMobileRadeonとやや貧弱だから、計算よりも
描画周りに気を使う

使うっつってもテクスチャをケチりまくるとか
頂点バッファとDrawPrimitiveの使い方を適切に、とか
その程度の話だけどね
199 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 10:16:35 ID:AI/AEUDG]: 総当り以外の当たり判定処理ってのが思いつきません。

ずっと昔に仮想マップみたいなのを用意しておいて
そこにキャラや弾の情報を書き込み、判定の際に使うってのを
何かで見た記憶があるけど、こういうのの事でしょうか。
200 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 10:46:32 ID:hPpN0s4/]: 空間分割ってのがありまして。

完全2Dなら当たり判定のある空間を縦横20くらいに分割して、
それぞれの空間に属するもの同士で判定を取ることで、
当たる見込みの無いものとの判定を事前に回避する。
201 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 12:27:23 ID:euXxyvh6]: >>199
pc11.2ch.net/test/read.cgi/gamedev/1199303757/762-765n
↑の質問したのお前？
仮に別人だとしてもこの過疎板でこのタイミングで同じ質問が二度出るのは変だな
どっかのゲー専の宿題か何かか？正直に吐いたら褒美をくれてやるぞｗ
202 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 13:27:02 ID:AI/AEUDG]: 違います。
ゲー専の宿題でもないです。

今、自分で２Dゲーム作ってて、
キャラと弾、全部あわせると最高1600強を動かしてて、総当りでやってて問題なく遊べてる。
（もちろんあくまで「最高1600」であって、常にそれだけ動いてるわけではない）
「自機と敵弾」だけの判定じゃなくて、「敵と敵弾」とかの判定もやってるのに
ちゃんと遊べるから、最近のPCの処理速度はすげーなーとか思いつつも
やっぱもっと効率のいい判定方法ないかな、と考えてただけです。
203 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 14:08:55 ID:98Hdy+Q5]: 1600*1600の総当りは3年位前のスペックだときつくないかな？
204 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 14:20:04 ID:kACwEiIs]: 三年前、2005年のスペックというと
athlon64が全盛でathlon64x2が登場、Core2Duoがまだ、という辺り

有り得ないくらい余裕だな
205 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 14:36:20 ID:8r+omDm7]: 1600*1600だと最新マシンでも空間分割しないときついんじゃないか。
>>196は弾*キャラなんじゃない？
206 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 16:24:58 ID:XVBdGsRf]: 典型的な2DSTGで1600のオブジェクトを表示するったって大半が弾なんだけど
1600*1600という数字(組み合わせ)に一体何の意味があるのか>>203は説明できないだろ
207 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 16:25:30 ID:KKsDXKAb]: ja.pastebin.ca/970731
やっつけだがpen3 1GHzのマシンで平均32ミリ秒
30fpsで間に合わないってところか
208 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 17:04:15 ID:KKsDXKAb]: ja.pastebin.ca/970760
今度は32*32の敵64体と16*16の弾1600発のテストで、弾はヒットしたら壊れるという想定
同マシンで2～3ミリ秒
余裕すぎるな

ただのジコマンなのに連投してすまん
209 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 17:25:12 ID:0OItj9LK]: 総当りっていったら、普通は敵だの弾だの関係なく
{1600}C{2} = 1600*1599/2 の組み合わせになるんじゃないのか？
64*1600の組み合わせじゃあ桁が違う
210 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 17:32:55 ID:KKsDXKAb]: >>209
それは>>207

>>208は単なるジコマンぽ
211 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 19:04:55 ID:g/x8ThIF]: >>203は
”総当りの意味をちゃんと使ってくれ”
と、暗に言ってるだけだと思うんだが
212 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 20:34:11 ID:GfOfbOVS]: オブジェクトを敵機・弾など種類ごとにリストにしておき、
あるリストの要素と別のリストの要素の当たり判定を行うことで、
無駄な判定はなくせると思うが
213 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 20:42:54 ID:9+TzVPLQ]: 俺もそれだ。
214 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 21:04:37 ID:qbhzPNp0]: >>212
例えば自機が画面の左下にあるのに
右上に固まってる敵弾と判定と判定を行うのは無駄な判定だとは思わないか？
215 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 21:06:02 ID:qbhzPNp0]: なんか変な文章に・・・
216 名前：199=202 mailto:sage [2008/04/04(金) 21:43:26 ID:WdCHFh7R]: なんか俺の書いた事について色々あったみたいで、申し訳ないです。

俺が問題としてた話題はあくまで「総当り以外の判定方法」であって、
それ以外（俺がどんな事やってるか）は、この際関係ないから
>>201さんに納得してもらえる程度の情報出せばいいと思って
おおざっぱな説明しただけで、実際に1600*1600の判定やってるわけじゃないです。

常に全キャラ使ってるわけじゃないし、キャラ同士、弾同士の衝突判定は
ある場合より無い場合の方が多いし、そもそも味方同士の判定はやってないし、
というようにかなり減らしてはいます。

という事で>>201さんに納得していただいて、その褒美を貰おうと心待ちにしている次第です。
217 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 22:03:57 ID:GfOfbOVS]: >>214
当たり判定範囲が矩形なら無駄な判定は生じない
むしろ、空間分割の方が無駄
5～10個の矩形の複合体とか円形とか多角形なら、空間分割にも利があるけど、
矩形のバウンディングボックスで一度判定すれば十分だろ
218 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 23:32:07 ID:qbhzPNp0]: 俺の日本語がダメなばっかりに変な誤解をさせてしまってるかもしれない・・・
それとも俺が誤解してるのかも？

>>212の方法って敵弾が1000個あったとしたら
1000回自機と判定しなきゃならないってことだよね？

悪い例えだけど（実際はツリーだったり）
敵弾を分割した空間ごとにリストにしておき、
自機のある空間とその空間のリストの当たり判定を行うことで、
無駄な判定はなくせると思うが
219 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 23:32:34 ID:KKsDXKAb]: 組み合わせが多いときは、分割は有効だけどね
220 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 23:37:39 ID:KKsDXKAb]: グリッドハッシュ
ttp://lucille.atso-net.jp/blog/?p=85

シューティングにここまで必要か？と問われたら
個人的には要らないと答えるが
知っておいて損は無いと思う
221 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 23:50:38 ID:98Hdy+Q5]: 昔は、IF文使うときに&&を使わず
入れ子にして速度を稼いだりしたなぁ
222 名前：名前は開発中のものです。 mailto:sage [2008/04/04(金) 23:53:49 ID:qbhzPNp0]: 確かに1対多だったら労力のわりにたいした恩恵受けるもんでもないんだけども・・・
223 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 00:13:39 ID:ElJWYWg0]: とりあえず、オマエラ「空間分割衝突」で１回ググれば幸せになれるんじゃね？
224 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 00:23:10 ID:xg5znUOR]: >>221
わざわざ入れ子にしなくても
if( A() && B() )
これA()がfalseならB()は実行されないから
左のほうをfalseになりやすいものにすればいいと思うんだけど
昔のコンパイラは違うのかね
225 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 00:27:12 ID:ndMxol9I]: >>209
敵弾とか敵機はお互い衝突しない
つまり敵属性同士は衝突しない
自機と自弾についても同じこと

敵(Enemy)と自(プレイヤー、味方、Friendly)。たった「2種」の敵味方属性
そしてオブジェクトに割り当てられる敵味方属性情報は静的。定数。const
プリプロセッサ、コンパイラにかける前から明らか。火を見るより
ゲームデザインの時点で既に決まってること
それなのに、判定…意味も無く…1600*1600回…あり得ない…愚行…常軌を逸する…愚鈍
226 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 00:28:02 ID:ndMxol9I]: BULLET enemybulletarray[1500];
ENEMY enemyarray[100];
PLAYER player;
for(int n0=0; n0<1500; n0++){
　　for(int n1=0; n1<1500; n1++)
　　　CollisionDetection( enemybulletarray[n0] , enemybulletarray[n1] );
　　for(int n1=0; n1<100; n1++)
　　　CollisionDetection( enemybulletarray[n0] , enemyarray[n1] );
}
for(int n0=0; n0<100; n0++){
　　for(int n1=0; n1<1500; n1++)
　　　CollisionDetection( enemybulletarray[n0] , enemybulletarray[n1] );
　　for(int n1=0; n1<100; n1++)
　　　CollisionDetection( enemybulletarray[n0] , enemyarray[n1] );
}
//↑ここまでで1600*1600回
227 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 00:38:24 ID:ndMxol9I]: BULLET playerbullet[100];
//2DSTGで総当りで当たり判定するっつったら普通コレ
for( int n0=0; n0<1500; n0++)
　　CollisionDetection(player , enemybulletarray[n0]);
for( int n0=0; n0<100; n0++)
　　CollisionDetection(player , enemyarray[n0]);
for( int n0=0; n0<100; n0++)
　　for(int n1=0; n1<100; n1++)
　　　CollisionDetection( enemyarray[n0], playerbullet[n1] );
228 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 00:43:36 ID:ndMxol9I]: BULLET enemybulletarray[1500];
>>226訂正

ENEMY enemyarray[100];
PLAYER player;
for(int n0=0; n0<1500; n0++){
　　for(int n1=0; n1<1500; n1++)
　　　CollisionDetection( enemybulletarray[n0] , enemybulletarray[n1] );
　　for(int n1=0; n1<100; n1++)
　　　CollisionDetection( enemybulletarray[n0] , enemyarray[n1] );
}
for(int n0=0; n0<100; n0++){
　　for(int n1=0; n1<1500; n1++)
　　　CollisionDetection( enemyarray[n0] , enemybulletarray[n1] );
　　for(int n1=0; n1<100; n1++)
　　　CollisionDetection( enemyarray[n0] , enemyarray[n1] );
}
//↑ここまでで1600*1600回
229 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 00:47:03 ID:KzcCKEO1]: >>225-228
言いたい事は概ね同意だが下手なカイジネタは寒いからヤメレ
230 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 00:51:05 ID:ouV9zovg]: 自機と敵弾・敵機と自弾以外に衝突判定する必要無いだろ
1600×1600になるのは自機1600機と敵弾1600個みたいな時
231 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 00:57:53 ID:fK+4rNgg]: 弾同士が打ち消しあうときもな
232 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 01:02:18 ID:xg5znUOR]: 弾同士の当たり判定が無いなんて勝手に決め付けるなよ。
そういうSTG作りたいと思ってる人がいるかもしれないじゃないか。
というより5年前に俺が作った。
ビリヤード風弾幕ｗｗｗとかいいながら。
ひどい処理落ちで泣いた。
233 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 01:03:00 ID:KzcCKEO1]: 計算機アルゴリズムで使われる「総当たり」とか「総当たり法」ってのは
理論的にありうるor考え得る全ての組み合わせ全てを○○する、ことであって
この理論的にありうる、考え得るってのがキモ

理論的にありえない、100%かんがえられない組み合わせを端から除外しても
やはり総当たりだ

敵同士、味方同士は「当たらない」というルールになってるなら端から除外しても
やはり総当たりだ
234 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 01:04:20 ID:ouV9zovg]: 弾同士が打ち消し合うときは(1599 + 1) / 2×1599じゃないか？
235 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 01:37:44 ID:ndMxol9I]: >>229
ウッセー自分で書いて後で赤面してんだからそれ以上言うな
236 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 15:10:07 ID:yDdR+5eW]: 33MHzくらいのCPUでSTGを作ったときは空間分割にしないと重くて大変だった。
そういうプアなハードじゃないなら好きに作った方がいいかもね。
237 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 15:19:58 ID:q5ZpKtyT]: 自機の弾が1600発とか弾で画面が見えなくなりそうだなｗ
238 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 18:40:45 ID:9fddUrpP]: >>224
私の記憶が確かならば、A()でとっとと打ち切られるのはCの仕様で保証されているはずだ。
239 名前：名前は開発中のものです。 mailto:sage [2008/04/05(土) 19:27:04 ID:hxbbxTAw]: O(n^2)の壁は厚すぎる
240 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 01:22:08 ID:+j0OgDSv]: >>218
矩形同士の判定程度だと、
　　ツリー管理コスト＞＞＞衝突判定のコスト
だと思うのだが。これが3Dでコリジョンも複雑になってくると、
　　衝突判定コスト＞＞＞ツリー管理コスト
になるけど
241 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 01:42:33 ID:5ljxdwAA]: >240 の頭の中にはどんな木が生えているのだろう？
木ってぐらいなんだから再帰なんだんろうけど、

それよりも、ずっと簡単なs個の空間分割でこんな感じだよ。

比較回数(衝突判定回数)は総当たりが一定でO(N^2)としたら、

s個の空間に分割した時は、
最小 O(N^2/s +N)　～　最大 O(N^2 +N)
　+Nってあるのは、中心より上とか下とか、左右とか、分割条件との比較。

最大は、全ての判定対象が一つの空間に有るとき。
最小は、全ての判定対象が均一にそれぞれの空間に別れたとき。

最大なんて状態ばかりのゲームはそう滅多に作れない。
必要とあらば中心を移動する事もできちゃうしね。
242 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 02:25:27 ID:KzCv2Ahg]: あれだ

弾幕ゲーが嫌いで、オブジェクト数がさほど多くない俺には不要＞空間分割
243 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 08:33:57 ID:lZPN8UOZ]: 空間分割して、空間内にあるかどうかの判定って矩形判定みたいな
もんだよね。差し引きして恩恵あるのかね？あと、空間の境界にいる
場合は隣接した空間も含めなきゃいけないし、その判定のコストも
加わるから、あんまり恩恵がない気がするんだけど。
244 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 09:49:50 ID:LNMxVQdl]: 現空間x-1 <= 判定対象空間x && 判定対象空間x <= 現空間x+1
245 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 10:21:25 ID:UvIpq6SI]: すみません。
空間分割による判定、のメリットというものがどうもイメージできないのですが、
例えば、縦シューで自機と敵弾（256発）の当たり判定で、

for(int i=0; i<256; i++){
if((自機Ｙ座標-敵弾Ｙ座標)の絶対値＜当たりの深さ）{
if((自機Ｘ座標-敵弾Ｘ座標)の絶対値＜当たりの深さ）{
（当たっている処理）
}
}
}
という単純な座標比較による総当たりを行っている場合、
空間分割にする場合どのように変更して、またそれによりどのくらいの恩恵が
得られるのでしょうか？
246 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 10:32:56 ID:wmWZV0ag]: >>243
＞空間分割して、空間内にあるかどうかの判定って矩形判定みたいなもんだよね。
それじゃ逆に判定回数増えるだろ。
例えば4分割だとしたらオブジェクトのポインタのリストを4つ準備して
オブジェクトを動かした後にでも空間別にリストに登録する。
判定したいオブジェクトの空間のリストのみ判定する。

空間の境界をまたぐ場合があるから実際はリストよりツリーを使うみたいだけど。
自機対敵弾みたいな1対多のような場合は>>240の可能性もあるが
しっかり最適化すれば恩恵はあると思う。
247 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 10:51:59 ID:ZtZMep9I]: 弾幕ゲーで弾同士の相殺でもない限り、
空間分割の恩恵は誤差範囲だと思うな
80-20の法則的にもっと別の部分の最適化に労力を使えばいい
248 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 11:12:26 ID:lDJhBuwb]: 空間分割なんて16ビット機でやってもいろんなオーバーヘッドで効果は微妙だった。
いくらか弾数が増えてるとはいえ、今のPCでみみっちいことしないでよろしい。富豪的に池
つーかまず衝突判定にそんなに時間かかってるのかプロファイリング取れ。
249 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 14:07:39 ID:IUsiyVu+]: 空間分割自体は当たり判定以外でも使える場合もあるかもしれないから
そういう方法があるとだけ覚えておけばいいんじゃない？
250 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 19:03:41 ID:lZPN8UOZ]: ＞＞２４６
難しくて分かりません。
他のレスを見て、合わせて、
必要ないということで納得しました。
251 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 19:14:32 ID:Cm7rU9iY]: シューティングって、三角関数のテーブルは360度で足りる？
252 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 19:38:45 ID:ZtZMep9I]: それくらい自分で判断しろ
253 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 20:07:47 ID:S2eA97Dz]: どんなもん作りたいかによる
要するに自分で判断しろ
254 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 20:51:46 ID:HV30LXTn]: 普通に標準ライブラリ関数使いまくりでおｋ
255 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 21:21:13 ID:09KIF8si]: むしろ度数法を久し振りに見た……。
256 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 22:24:48 ID:lDJhBuwb]: だからテーブルとか考える前に普通に三角関数使ってみなよ。富豪的に。
たかがシューティングごときを作るのに、
あれこれレガシーな技をどこで覚えてくるんだいったいｗ

弾幕シューが技術的にすごかったのはX68000までよねーｷｬﾊﾊ
257 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 22:37:18 ID:+JZYHxk+]: 微妙に誉め言葉ｗ
258 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 22:45:56 ID:mi699AnH]: 俺もそうだったが、
初心者ってどうでもいい部分の最適化にこだわるよなｗ
259 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 22:54:25 ID:wmWZV0ag]: アセンブラ勉強し始めたりとかなｗ
260 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 22:55:52 ID:tOJ8RPAp]: >>256
たぶん超連射のことを言いたいんだと思うがあれは弾幕シューじゃない。
そもそも68全盛期に弾幕シューなんてジャンルは存在しない。
知ったか乙。
261 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 23:00:07 ID:S2eA97Dz]: マジレスとな
262 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 23:13:28 ID:3n+Chkyh]: 爆裂矩形弾が泣いてます
263 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 23:19:08 ID:S2eA97Dz]: 敵弾の多さならメルトダウンも負けない
テキストだけどｗ
264 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 23:29:06 ID:ZtZMep9I]: >>260
265 名前：名前は開発中のものです。 mailto:sage [2008/04/06(日) 23:33:09 ID:+JZYHxk+]: 爆裂矩形弾懐かしいｗ
あれで弾幕シューは俺には不向きだと悟ったなぁ。
266 名前：名前は開発中のものです。 mailto:sage [2008/04/07(月) 00:09:38 ID:RkL7uReo]: 針弾弾幕は、その場で計算して回転で大丈夫？
267 名前：名前は開発中のものです。 mailto:sage [2008/04/07(月) 00:29:10 ID:SYSPe7mm]: 大丈夫も何も、針弾は角度とか回転情報を持ってなくね
針弾＝曳航弾。尾＝残像＝向きは速度(ベクトル)に平行
所有する変数は座標、速度、尾の長さ。せいぜいこんなもん
表示に際しても、太った線分＝OBBを一個作るだけであり
角度とか回転計算が出る幕はない
268 名前：名前は開発中のものです。 mailto:sage [2008/04/07(月) 00:40:04 ID:UhDksLO+]: その場で回転を計算の意図が今ひとつ掴めないが
俺は弾の情報として角度は持たせてる
前の座標や速度からその都度計算してると完全に停止する場合に困るからね
あとは途中で方向が変化しない弾なら発射時に角度を計算して放り込んで弾が消えるまで使いまわし
変化する場合は毎回計算

まぁ好みでやればいいと思うよ
269 名前：名前は開発中のものです。 mailto:sage [2008/04/07(月) 01:18:56 ID:SZ+jR7s6]: 融通が効くと思う方法にしとけ。
速度で困ることは無いと思うし。
270 名前：名前は開発中のものです。 mailto:sage [2008/04/07(月) 06:57:49 ID:+8OjOCNS]: 前に、三角関数使いまくったら流石に重かったなあ。
271 名前：名前は開発中のものです。 mailto:sage [2008/04/07(月) 07:39:55 ID:Rur2+VQh]: 改めて自分のソース見てみたら360度のテーブル使ってた。
不都合無いのでこのままいくがｗ
272 名前：名前は開発中のものです。 mailto:sage [2008/04/07(月) 09:06:33 ID:+8OjOCNS]: >271
俺も見てみたら、unsigned charのオリジナル角度表記を使ってた。
意味あんのかな、これｗ
273 名前：名前は開発中のものです。 mailto:sage [2008/04/07(月) 18:27:25 ID:jWrDXnrl]: 自分は１周＝256分割にしてますね。
360度だと、nWay弾とかの処理するとき、弾と弾の間の角度に端数がでませんか？
274 名前：名前は開発中のものです。 mailto:sage [2008/04/07(月) 18:35:56 ID:Ln6527jm]: 2Dでもちょっとした誤差くらい気にならんよ
それに角度を度でやるなら360も約数多いから端数出にくいんじゃねえの
275 名前：名前は開発中のものです。 mailto:sage [2008/04/07(月) 19:08:11 ID:jWrDXnrl]: 確かに誤差の範囲ですね。組み方次第でどうにでもなる問題かも。
自分の場合、多Way弾の弾と弾の幅を考えるときに、360度法でいうところの
90度からスタートして、半分、半分、半分、って幅を狭めていく考え方を
することが多かったから、１周が２のn乗のほうがやりやすかった、というだけの話。
276 名前：名前は開発中のものです。 mailto:sage [2008/04/07(月) 19:20:21 ID:/whlgGmL]: いまだに三角関数のテーブル使ってる人が俺以外にもいたなんて
俺は1024分割

当然座標も整数だよな
277 名前：名前は開発中のものです。 mailto:sage [2008/04/07(月) 22:10:13 ID:nzfTFxMf]: そうか！　座標を整数以外にするという手もあったのか！！
278 名前：名前は開発中のものです。 mailto:sage [2008/04/08(火) 00:03:17 ID:UTGYbURq]: 整数つかうときって、何倍かして入れるんだろうけど
当たり判定とか表示のときは毎回戻すの？
279 名前：名前は開発中のものです。 mailto:sage [2008/04/08(火) 00:54:41 ID:sOsom0Zc]: 何回ってどういう意味なんかよく判らんｗ
280 名前：名前は開発中のものです。 mailto:sage [2008/04/08(火) 00:57:21 ID:NDn3kKP8]: >>279
281 名前：名前は開発中のものです。 mailto:sage [2008/04/08(火) 01:08:48 ID:RXIPGVdD]: >>278
戻すって、整数部だけが欲しい場合か？
そんなん普通にビット演算子とかシフト演算使えば済むでしょ

おそらく初心者だと思うが、固定小数演算に興味示すのは結構だが
FPU内蔵＆SIMD系の命令でもfloat値が使えて当たり前の今時のPCで
わざわざ固定小数を使うメリットはほぼ無しってことも合わせて理解しとけよ

それでも年寄りの悪趣味懐古趣味に付き合いたいなら別に止めはしない
282 名前：名前は開発中のものです。 mailto:sage [2008/04/08(火) 13:13:10 ID:Wd7FQUJf]: 次に作るSTGにリプレイ機能を搭載しようと思っているのですが、
小数を使う場合、CPUによって小数点以下に誤差がある？という話を聞いたのですが、
例えば敵弾の座標に小数を使っていたら、リプレイを再生する環境によって
微妙に挙動がずれたりする可能性はないのでしょうか？
組み方次第で回避できるとは思うのですが。
283 名前：名前は開発中のものです。 mailto:sage [2008/04/08(火) 18:46:46 ID:RXIPGVdD]: ＞小数を使う場合、CPUによって小数点以下に誤差がある？という話を聞いたのですが

とりあえず
固定小数点数演算で生じる誤差の話なら、それは整数演算で生じるものと全く同じ
浮動小数点数演算で生じる誤差の話なら、それは「小数点以下」とか関係ないから

浮動小数点数演算の結果はCPUによって異なる、というのは事実だが
それは全く異なるアーキテクチャ上のFPU同士を比較した場合の話であって
x86系のPCに限定すれば_fpcontrol()等できちんとFPUの設定をすることで
インテルだろうがAMDだろうが加減乗除算平方根三角関数の結果は同じになる

FPUに不具合があって回収された10年以上前のペンティアムとかは例外
あとSSE関連はよく知らね
284 名前：名前は開発中のものです。 mailto:sage [2008/04/08(火) 19:22:22 ID:RXIPGVdD]: あと、数値計算法の基本をふまえて相応のコードを組んでいれば
異なるFPU間で生じる演算結果の極めて微少な差は問題にならないはず

FPUの演算結果にはたいてい不要な桁数の仮数が入ってるのだから
そういうゴミ情報入りの数値は適切なタイミングで有効桁に丸めること
不要な桁も何もかも後生大事に丸々保存して使いまわすのは
無意味な貧乏根性
285 名前：名前は開発中のものです。 mailto:sage [2008/04/08(火) 21:05:39 ID:NDn3kKP8]: D3DXが内部でSSEやら3DNow!を使ってそいつらで誤差が出ると2chで聞いたことがある。
試してないから知らんけど、リプレイで記録するデータはCPUで普通に計算すればOKじゃね。
286 名前：名前は開発中のものです。 mailto:sage [2008/04/08(火) 21:14:53 ID:5+HU4lQf]: >>285
www.01step.net/tobitsuki/bbs/test/read.php/tobi_bbs/1116256631/18
これだな。
一応対策はできるらしいが。
287 名前：名前は開発中のものです。 mailto:sage [2008/04/08(火) 23:49:54 ID:uw9YU9FV]: NyaRuRu氏は同人ゲームのプログラマもやっていたのか・・・。
288 名前：名前は開発中のものです。 mailto:sage [2008/04/09(水) 03:34:01 ID:B1YmjfJu]: 何やってる人なんだろうと思っていたが
不思議キッチンの人だったのか

[ 続きを読む ] / [ 携帯版 ]

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