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

**名前は開発中のものです。** · 2007/07/11(水) 08:32:54

ゲームプログラマなら誰もが通る、もしくは、通った道。青春の香り？
それは「シューティングゲーム製作」・・・。

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

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

過去スレ，関連スレは >>2-3で。

**名前は開発中のものです。** · 2007/11/01(木) 10:12:09

それではVBlank待たないと遅延は発生しないの？

**名前は開発中のものです。** · 2007/11/01(木) 10:13:37

すまｓん

**名前は開発中のものです。** · 2007/11/01(木) 12:29:04

>>500
前半2段落はあってるのになんでダブルバッファがラインバッファに比べて１フレーム遅延するんだ?
同じだろ?

**名前は開発中のものです。** · 2007/11/01(木) 14:25:29

>>500
18年もやっててそれでは才能がないと言わざるを得ない。
スプライトや背景の更新とダブルバッファのFlipが等価な処理。

ゲーム処理1→バックバッファの更新→VSync→Flip→ゲーム処理2→…
ゲーム処理1→VSync→背景＆スプライトの更新→ゲーム処理2→…

どちらもゲーム処理2の最中に1の画面の表示が始まる。

**名前は開発中のものです。** · 2007/11/01(木) 14:49:18

>>499
スルーされてるから突っ込んでおくが嘘はイカンよ。
つか、DSってポリゴンすらラインバッファなのでスプライト機と同じ感覚でポリゴンが出せる。

**名前は開発中のものです。** · 2007/11/01(木) 22:52:56

・Flipでバックバッファに描画済みの絵を切り替える
・Flipでたまった描画パケットをキックしバックバッファに描画開始

どっち？

**名前は開発中のものです。** · 2007/11/01(木) 22:58:05

>>506
んん、そうなのか？
VBlank中にVRAMへの転送とアトリビュートメモリの更新を同時にしたら
VRAMのデータは更新されてるのに位置の更新が遅れているってことがあったのだが…
何か俺が根本的に俺が間違ってたのかも。もう大分前の話で詳細は覚えてない

**名前は開発中のものです。** · 2007/11/01(木) 23:08:57

500です。

確かに>>505　のような処理もできますね。
その場合はもちろんラインバッファと同等です。

ただそれだとCPUとGPUを非同期で動かせない
（CPUの余った時間でしか描画できないし、描画中はCPUが動けない）
ので、ハードウェアをフルに活用するためには選択しないのが常識
だと思っていました。

**名前は開発中のものです。** · 2007/11/01(木) 23:36:39

>>508
キャッシュのフラッシュ忘れとかその辺じゃね？

**名前は開発中のものです。** · 2007/11/01(木) 23:42:09

>>509
キーレスポンスを追求するという考えのゲームなら選択されるんじゃないか？

で、厳密に言えばCPU処理とパケット転送をしている裏でレンダリングをしているから
非同期で動いていると思うんだが。

**名前は開発中のものです。** · 2007/11/02(金) 00:00:02

>>509
遅延をなくす場合の最優先のプログラムの話でしょ
それに２DSTGならマシンパワーが足りないなんてのは古いのを除いてまずないし・・・

スループット重視したいのならトリプルバッファオススメ

**名前は開発中のものです。** · 2007/11/02(金) 00:14:23

遅延は最優先事項としてできる限り小さくしたい

**名前は開発中のものです。** · 2007/11/02(金) 00:23:45

1とか2、3フレーム遅延しても和漢ねーよ。
そんな意味不明なこだわり見せてないでさっさと完成させろよ。

**名前は開発中のものです。** · 2007/11/02(金) 00:34:32

それだけこだわれる知識もってるくらいだから実績あるんじゃないの？

俺なんか何を言ってるのかほとんどわかんねーよ。
何をもめてるのか、が、かろうじて解る程度。

**名前は開発中のものです。** · 2007/11/02(金) 00:34:45

>>512
>それに２DSTGならマシンパワーが足りないなんてのは古いのを除いてまずないし・・・
確かにCPUパワーはすごいけど、fx5200程度だと
ピクセルシェーダ使って派手な爆発させただけで描画に16ms消費するよ。

あと遅延に関してだけど、60フレで作った場合、ダブルバッファによって発生した遅延は
そんなに神経質になる必要はないと思う。(極々一部のプレイヤーを除く)
ちゃんと作ってあっても遅延が体感できる場合、ゲームパッドのドライバやハードウェア、ディスプレイ、
Windowsのパッド情報の更新タイミングの方が問題な気がする。＜この辺は詳しくないです。

360の無線コントローラーの遅延は体感できる。

**名前は開発中のものです。** · 2007/11/02(金) 00:36:27

どこのスレか忘れたが、住人が遅延のテストしてて1フレの差を
みんな判ったって覚えがあるんだがな。だいたい3フレ遅れたら流石にわかるだろ。

意味不明のこだわりってこたないだろ。もしかして技術的な話以外に
シューティングには大して興味ないとか？

**名前は開発中のものです。** · 2007/11/02(金) 00:46:34

結局具体的にはどう実装すればいいんでしょうか。
解る人が居る以上最善な解にしたいんですが、自分は鈍感なんで気づけないかもしれないし。

**名前は開発中のものです。** · 2007/11/02(金) 00:48:15

そら遅延だけに意識を手中させるようなテストプログラムならわかるかもな。
でも実際のゲームでは50msなんてわかんないから。

**名前は開発中のものです。** · 2007/11/02(金) 00:59:46

弾幕シュー作るなら特に遅延は気になるよ。低速で自機を凝視して目視で
避けるゲームだから。高速弾切り返し系はあまり自機見ないので実は意外と気にならない。

**名前は開発中のものです。** · 2007/11/02(金) 01:40:31

>>516
負荷のかからない描画方法を選ぶだけ
もしくは選択できるように

重視するのがグラフィックなのか遅延なのか選択は自由なんだから好きに汁

俺的には915、できれば945で大幅に性能増えたから開発者の負担はかなり下がったと思ってる
やっぱりノートPCがほとんどの現在、統合チップセットは無視できんからね
デスクトップでもかなりの割合でUMAだし

**名前は開発中のものです。** · 2007/11/02(金) 01:47:55

今のマシンで秒間60フレームならどーやっても遅れますので
古いマシンからの移植でもない限り気にすんな。

セガサターンとプレステが出た頃のネタ、
あるいはTOWNSとX68Kの間の抗争をぶり返してるだけです。

差なんてねえよって自演で言ってるのは、その後から始めた知ったか君。

**名前は開発中のものです。** · 2007/11/02(金) 09:11:02

>>520
断言するが、2、3フレームなら気にならない。

人間には環境適応能力もある。
50msの世界は気づかないか、または勝手に感覚を適応させる。

50msなんて神経の伝達速度を超えてるんだから。

**名前は開発中のものです。** · 2007/11/02(金) 09:52:50

VSync同期させない2DSTGでも気にならないプログラマと許せないプログラマがいるわけだが。

**名前は開発中のものです。** · 2007/11/02(金) 10:59:24

ティアリングもイヤだけど、VSync同期するとあからさまに遅延が判る。
回避方法あるなら教えてほし。遅延するくらいならティアリングのがましだけど…。

**名前は開発中のものです。** · 2007/11/02(金) 13:15:01

>>525
NVIDIAの場合ドライバで最大3フレーム遅延するようになっているから、
それが原因の場合はPresentの前でバックバッファをLock-Unlockする。

**名前は開発中のものです。** · 2007/11/02(金) 13:38:16

DirectX9なら、IDirect3DQuery9を使う方がいいかも。

**名前は開発中のものです。** · 2007/11/02(金) 14:59:30

実際のとこ、PCだとどこで遅延してんのか判らんから何フレ遅れてるのかも
まったく判らんね。だからプログラムでは出来る限り減らしておきたいって
ことなんだけど。

**名前は開発中のものです。** · 2007/11/02(金) 23:58:34

>517
以前このスレかな？入力遅延をさせるテストプログラムがあった気がする。
大体３フレぐらいから遅延を感じる人が出た気がするが、
１フレはほとんどわかんなかったぞ。

**名前は開発中のものです。** · 2007/11/04(日) 03:47:41

入力遅延についてはそもそもボタン類の物理的構造によっても変わるよな
ソフト的に遅延が無いといわれているものでも、実際にはみんな一瞬早めに押してるんだよ
人間ってのはそのぐらいの融通は利くようになってるんだから遅延遅延と騒ぐよりも実際にやってみんとわからんよ

**名前は開発中のものです。** · 2007/11/09(金) 18:24:20

遅延をｼｽﾃﾑに活かせないかな…

**名前は開発中のものです。** · 2007/11/09(金) 18:49:07

やだよそんなの

**名前は開発中のものです。** · 2007/11/09(金) 20:02:29

遅延をシステム的に活かして成功した例といえばグラディウスのオプション

**名前は開発中のものです。** · 2007/11/09(金) 21:40:40

そら動きが結果的に同じだけで活かしたわけじゃねえし

**名前は開発中のものです。** · 2007/11/09(金) 21:54:58

ドラキュラのムチのように押してから発動するまでにタメがある攻撃なら活かしてる？
狙って撃たなきゃいけないようなシステムになるのかな
撃ちまくり爽快感の方が好きだからどうでもいいけど

**名前は開発中のものです。** · 2007/11/09(金) 22:09:38

昔のマルチFPSはクソ遅い回線の遅延もプログラムで何とかしたのに。
シューティングの奴らはいつも他人が悪い環境が悪い言ってんだな。
FPS論争のときもリフレッシュレートを60Hz以外に設定している奴が悪いって流れになるし。

**名前は開発中のものです。** · 2007/11/09(金) 22:25:03

60Hz以外が悪いとは言わんけど、
60FPS前提で作りたい場合は環境の切捨ては仕方ないな

**名前は開発中のものです。** · 2007/11/09(金) 23:02:34

昔ながらの2Dシューはプレイヤー側でも60Hzを望む人が居たりするからな
FPSとは違う要望があるジャンルだから比べてもしょうがないよ
全キャラ3Dならレート可変でもいいんだろうけど、操作感とかどうなんだろ

**名前は開発中のものです。** · 2007/11/10(土) 00:45:31

>>536
2DSTGはリフレッシュレートがゲームに与える影響がでかすぎるんだよ
FPSというか3Dゲームはリフレッシュレートが可変でもプレイに耐えるが
平面ベクトルや領域のギリギリのやりとりをする2DSTGだと可変になっただけで大惨事だ。
理屈の上では滑らかに補完できてるはずが実際動かしてみたらガタガタだったとかよくあるし。

**名前は開発中のものです。** · 2007/11/10(土) 01:15:30

そもそも絵をドット絵など2Dアニメで描いてる場合レート可変でやるには
無理がある

**名前は開発中のものです。** · 2007/11/10(土) 01:19:58

>>539
tonyu使ってる俺にとって悩みの種なんだよな
Ｃ言語に移りたいけどなかなか理解できない

**名前は開発中のものです。** · 2007/11/11(日) 02:07:28

なんか最近のPCだとタイマーが安定しないというか
環境によっていろいろ変わるようなんだが
マルチコアとかその辺の影響だろうか

**名前は開発中のものです。** · 2007/11/11(日) 02:47:42

タイマがQueryPerformanceCounterのことなら、AMDのマルチコアのシステムで
CnQ使ってたりすると問題があるよ。KB896256で修正される。

**名前は開発中のものです。** · 2007/11/11(日) 10:24:52

QueryPerformanceCounterがマルチコア環境で可笑しくなるのは仕様みたいなもんだろ。
アフィニティマスクでクロック取得先のコアを指定すればちゃんと動く。

**名前は開発中のものです。** · 2007/11/11(日) 10:45:45

仕様と思えるくらいにバグが蔓延しちゃってるのが問題なのでは

**名前は開発中のものです。** · 2007/11/11(日) 11:00:18

CPUクロックとってる場合があるんだからコアが複数あったら
どこコアから取得するか指定できないほうがまずかろ。

確かにデフォルトで1番目のコアに固定されてないのは問題だが。

**名前は開発中のものです。** · 2007/11/11(日) 13:00:55

QueryPerformanceCounter使ってないな
CPUクロックはなんだか安定感がなさそうなふいんき（なぜか変換(ry で

**名前は開発中のものです。** · 2007/11/11(日) 15:19:34

昔のゲームはマルチコアだとおかしくなる
HTでもわりとおかしくなってたけど
・超連射とか

最近出たソフトならまず対応してるだろ
してないのなら作者が悪いだけ
デュアルコアの確認はしていませんとかせめて開発環境を公開するべきだ

**542** · 2007/11/11(日) 15:59:09

レスどうもっす。やっぱいろいろあるのね。
俺はメイン絵描きでプログラムはHSPしか出来ないんで
制御はどうにもプラグイン頼みになっちまうのですが、
やっぱ内部的に何やってるかぐらい知らんとダメですな…。
皆さんいろいろありがとう。

ちなみに超連射はうちのクアッド機では平気な感じでした。
会社のHT機ではおかしくなったけどｗ

**名前は開発中のものです。** · 2007/11/11(日) 20:12:18

超連射はPen4HTとIntelCoreでおかしくなってるのを確認
プロセス探してCPU固定割付すると大丈夫

まぁサウンドだけおかしいんだけどね
68soundがまったくマルチスレッドを考慮していない

**名前は開発中のものです。** · 2007/11/11(日) 20:15:04

>>550
あーそれ互換モードで直るんじゃないかな

**名前は開発中のものです。** · 2007/11/11(日) 20:18:17

自レス
要するにマルチスレッドに対応してないOSの互換モードに
してやればいいって事か。

**名前は開発中のものです。** · 2007/11/11(日) 20:24:12

>>551
全ての互換モード試したけどなおらんかったよ
2000のときはたしか発病しなかった気がする

**名前は開発中のものです。** · 2007/11/11(日) 20:27:06

あれスマン。ダメだったか。
うちのQ6600だと非互換モードとw2kモード以外は正常に鳴るんだけど…。

**名前は開発中のものです。** · 2007/11/12(月) 15:04:19

Vistaのサウンドドライバがクソとかそういう話なん名じゃねーの？

**名前は開発中のものです。** · 2007/11/13(火) 00:38:01

すべてXPだし、オンボードのサウンドだよ
あとAudigyも同じなのも確認済

理由はXSoundDLLの仕組み

実際2世代古い超連射はどのOSでも問題ない
最新版がやばいというのはよくでてくるし常識かと

**名前は開発中のものです。** · 2007/11/15(木) 00:45:54

そろそろモニタをCRTから液晶に換えようと思うんだが
24インチワイドとか使ってる人いる？
ちょっと調べてみたところ
大きいのは応答速度が遅いらしいんだが・・・

**名前は開発中のものです。** · 2007/11/15(木) 00:50:22

http://pc.watch.impress.co.jp/docs/2007/1114/mitsubishi.htm

**名前は開発中のものです。** · 2007/11/15(木) 01:30:40

最近のワイドパネルは動画性能重視なんでそこそこ応答性は悪くないんじゃない。
韓国製VAパネルが多くてチカチカギラギラして目が疲れやすいけど…。
ただ応答性悪くないといってもCRTに対してはまったく勝負にならない。

個人的にワイドでお勧めはNECのLCD2690WUXiなんだけどゲロ高い。
ttp://www.nec-display.com/products/display/model/lcd2690wuxi/index.htm

**名前は開発中のものです。** · 2007/11/15(木) 01:32:28

すまんなぜかアドレスの最後が削れた。
ttp://www.nec-display.com/products/display/model/lcd2690wuxi/index.html

**名前は開発中のものです。** · 2007/11/15(木) 21:50:46

20マソ使ってイイなら
ワコムのでっかい液タブ買っちまいそう

**名前は開発中のものです。** · 2007/11/15(木) 22:51:57

タブレットはA5くらいがちょうどよくね

**名前は開発中のものです。** · 2007/11/15(木) 22:55:54

三角関数のテーブル化って本当に高速化されるのか？
弾が1000以上出る弾幕系2DSTG作ってて今は65535分割テーブル使ってるが
標準関数に戻しても殆ど差が無かった
標準関数で統一しようかなぁ

**名前は開発中のものです。** · 2007/11/15(木) 22:58:01

今はメモリアクセスを以下に減らすかが勝負だから
やり方次第で計算したほうが速い

**名前は開発中のものです。** · 2007/11/15(木) 23:29:20

最近のCPUなら1000程度の三角関数の計算など
どちらでやっても誤差程度ではないのか？

**名前は開発中のものです。** · 2007/11/15(木) 23:35:55

テーブルはsin/cosが遅かった時代の技術。
今でも携帯機とかで使えない場合には持つこともあるけど。

VCなら組み込み関数にしちゃうと速度的なペナルティはほぼないね。

**名前は開発中のものです。** · 2007/11/15(木) 23:36:15

でもゲーム会社にたまに生き残ってるだろ。固定少数や三角関数テーブルに血道をあげてる厄介な奴。
男の生き様なんだよ。

**名前は開発中のものです。** · 2007/11/15(木) 23:42:57

π==3.14にするためにテーブルにした
逆関数はしらん

**名前は開発中のものです。** · 2007/11/16(金) 00:50:25

テイラー展開の三角関数つくっておいてゲームが破綻しない精度まで
じょじょに項数へらしていくってのはどうよ

**名前は開発中のものです。** · 2007/11/16(金) 01:17:21

テーブルだろうがなんだろうがCPUでやろうとして悩むのがそもそもアホなんじゃねえの。
多くの弾は直進なんだから毎フレーム三角関数で求める必要ないし
スプライトの回転はシェーダですりゃいい。　
XYZが回転中心。法線のXYが頂点へのオフセットでZが回転のようなフォーマットなら
弾1000個 6000頂点をDrawPrimitive1回でできる。

**名前は開発中のものです。** · 2007/11/16(金) 07:25:58

>>569
前にそれやってる人みかけたなー
テーブルより遅いが、Sin関数など呼ぶより速いという
^C氏の記事でもあった気がする・・・

**名前は開発中のものです。** · 2007/11/16(金) 15:40:45

>テイラー展開
どうよと思って調べてみたけどこりゃだめだね
なんというか項を重ねるごとに-∞から∞までの波全体の形が整っていくのかと思ったら
原点から左右に紡いでくみたいに形ができていくのね
近似自体はn=2までで十分な品質になるけど-PI/2からPI/2までの範囲だけ
θをその編み上がってる狭い範囲にもってくるmodにコストがかかっちゃう

**名前は開発中のものです。** · 2007/11/16(金) 16:09:24

よくわからんけど知らなくてもよさそうだ

**名前は開発中のものです。** · 2007/11/16(金) 21:42:13

いまどき固定小数でシュー作ってるとこってケイブくらいなモンだろ

**名前は開発中のものです。** · 2007/11/16(金) 22:00:03

ケイブがやってんならそれで良いんじゃね
とか思ってしまうわけで

**名前は開発中のものです。** · 2007/11/16(金) 23:19:14

一線をリタイアしたロートルプログラマが携帯でそういうのをやってんじゃないの

**名前は開発中のものです。** · 2007/11/16(金) 23:44:37

別に何を使おうがちゃんとしてるならいいんじゃないの？

**名前は開発中のものです。** · 2007/11/17(土) 14:40:50

俺は整数でやってるんだが・・・

**名前は開発中のものです。** · 2007/11/17(土) 16:17:02

俺は素数でやってるぜ！

**名前は開発中のものです。** · 2007/11/17(土) 17:06:34

3Dでマトリックス演算とか全部整数なのか？

**名前は開発中のものです。** · 2007/11/17(土) 17:38:58

出来なくもないだろうけどやる必要もないと思うよ

**名前は開発中のものです。** · 2007/11/17(土) 17:50:59

まぁ必須ではないな
2DSTGならなおさら

**名前は開発中のものです。** · 2007/11/17(土) 18:57:25

DSとかPSPなら固定少数は主流だったりする？

**名前は開発中のものです。** · 2007/11/17(土) 19:14:52

DSはしらんがPSPはfloat普通に使う。

**名前は開発中のものです。** · 2007/11/17(土) 20:58:46

角度がアナログなら計算しちまったほうがいいかもだけど
グラディウスの敵弾みたいに16方向とか32方向とかの限られた方向しか使わない仕様だと
三角関数テーブル（と言っても行数はごく少ない）が良さげ？

**名前は開発中のものです。** · 2007/11/17(土) 21:35:55

どっちを選んでも実際のゲームで変化が見えないなら趣味の問題。

最適化に凝る同僚に面倒な規約を強要されるが、これ無意味なんじゃねーのと
うんざりする経験の有無で、汎用性や分かりやすさを重視するかどうか
分かれるかもしれない。

**名前は開発中のものです。** · 2007/11/17(土) 21:59:33

ゲームを作ることにおいて、技術的な追求を重視するかどうかってことかもな

**名前は開発中のものです。** · 2007/11/18(日) 10:12:39

>>586
軌道が微妙にずれるぐらいの変化はあるだろ

**名前は開発中のものです。** · 2007/11/18(日) 10:17:16

ちゃんと文章嫁

**名前は開発中のものです。** · 2007/11/18(日) 12:34:27

一ピクセルもずれねーと思う。

**名前は開発中のものです。** · 2007/11/18(日) 23:09:12

float と double で、差はある？
俺は大概 double で組んでいるんだが、それで不自由を感じた事が殆ど無い。
現在の PC 環境下 float との差はある？　ってか、差を感じた事のある人はいます？

あと、整数使うのはは誤差が（基本的に）無くて、心がすっきりするってのがでかいと思う。
個人的な感じ方だが、これって結構重要だと思う。
実際の処理上の有効無効はさておいてもね。

**名前は開発中のものです。** · 2007/11/18(日) 23:18:49

サイズに差があるからまったく同じ速度ではないと思うけど、
頂点データとかSSEで使うデータなんかはfloatにしてる。
SSEは128Bitだからdoubleだと2つまでしか並列化できないし。

**名前は開発中のものです。** · 2007/11/19(月) 00:10:31

>>591
普通にFPUつかった場合だけど、たとえば必要スペックがPentiumM1.2GHzだったのが1.6GHzくらいまで
といった感じに1.5倍くらいはねあがるからそれをどう見るかだな

オンボードビデオでもそれなりに動くようにいろんなところを軽くしようと考えるとあんまり選択したくはないかも

**名前は開発中のものです。** · 2007/11/19(月) 00:23:14

計算速度自体には差はなさそうだけど
メモリのキャッシュの効率のほうが悪そうだなぁ、doubleのほうは。

まあ速度なんてはなから気にして無いけどねｗ

**名前は開発中のものです。** · 2007/11/19(月) 21:40:30

基本的にfloatでやる。

ちなみにDSには浮動小数は無い。
マトリクスも固定小数。

>>591
int64がハードで出来る環境以外は固定小数は精度落ちまくり・無駄な乗除算(シフトでもいいけど)が
増えまくりでいいことが無いと思う。

**名前は開発中のものです。** · 2007/11/19(月) 22:52:07

STGでは固定小数の加算しか使わないんでしょう。
固定小数のマトリクスなんて頻繁に正規化しないと目に見えて崩れて行きそうなイメージ。

**名前は開発中のものです。** · 2007/11/19(月) 22:58:02

STG程度なら全部floatでいいだろ。
ゲーム自体が大してCPUくわんし。

**名前は開発中のものです。** · 2007/11/21(水) 01:36:00

CPU負荷の問題じゃなく、リプレイがずれないようにするために使うんだよ。固定小数点数は。

**名前は開発中のものです。** · 2007/11/21(水) 01:44:29

CPU毎に最適化されたSIMD命令を使わない限りfloatでもリプレイがずれるようなことはないぞ・・・。

最近話題になったのはD3DXの算術関数が内部でCPU毎に違うSIMD命令で計算してっからだよ。

**名前は開発中のものです。** · 2007/11/21(水) 01:58:42

最近のD3DXのバージョンだとそれは直ってるのか？

**名前は開発中のものです。** · 2007/11/21(水) 01:59:32

ああすまん、書き方からして直ってないっぽいね・・・。

**名前は開発中のものです。** · 2007/11/21(水) 10:17:42

直ってないっていうか速度を優先させるなら当たり前の仕様だしな。
スイッチでSIMDのON/OFFできるようにはしてもらいたいが･･･。

まぁリプレイを実装するようなゲームは自分でマトリックス演算を用意しろということなのだろう。