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

**名前は開発中のものです。** · 04/06/16 07:45

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

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

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

■前スレ
シューティングゲーム製作技術総合　２機目
http://pc5.2ch.net/test/read.cgi/gamedev/1073736474/

**名前は開発中のものです。** · 04/07/09 21:36

戦車が参照するマップと、表示用のマップが同じである
必要は無い。

マップ編集はちょっと面倒かも知れんけど。

**名前は開発中のものです。** · 04/07/09 22:02

>>480
話の発端はゼビウスとかマップエディタ流用の話なので
そういう無茶な突っ込みしないように。

　・マップチップ毎にアトリビュートを付加できない
　・マップチップをマルチテクスチャ化できない
　・マップを多層化（複数レイヤー化）できない

低機能マップエディタを使ってリアルな背景を
追求したいなら、相応の工夫をしましょう。

**名前は開発中のものです。** · 04/07/09 22:03

確かにそうだけど、実際やってるところあるのかな？
ちなみに漏れはオブジェクト出現テーブルに移動パターンとカウンタオフセットを与える方法で
やってたけど。
戦車ってそれほどハードにくねらないから30フレくらいの頻度でパターン構成してもそれなりにみえる
でも結局、停止->前進->停止の奴が一番多かったんだけど（ｗ

**名前は開発中のものです。** · 04/07/09 22:04

おっと被った
483は481へのレスです

**名前は開発中のものです。** · 04/07/09 22:36

>>482
道路パターンを地面に馴染ませるときは道路パターンを
アルファ付きテクスチャにして地面パターンにかぶせると
楽チンでいいな。
　
自然な描写を目指してくとマップエディタ自作にしたほうが
楽だと痛感した。

**ガルーダ週報** · 04/07/09 23:04

敵配置ツールは手付かずです。

その他のガルーダ仕様や基本的な処理（スコア、パワーアップ、アイテム効果等）は
一通り出来たので、後はボムの実装ぐらいです。

低レベル層の描画周りを見直してたら、致命的なミスを発見、
修正したら処理落ちが全くなくなりました。
（出現キャラ数は調べてませんが、アーケード版の後半ぐらいは出してる）

後はバランス調整、敵配置、ボス実装、最後に絵を直せば公開出来るんですが。
ボスの考案、絵を描くのが一番しんどい。
フィルタ掛けるとかじゃ不味いんですかね。細かい修正は色々してますが。

**名前は開発中のものです。** · 04/07/09 23:30

道路の上を進む戦車って移動はなんとなく分かったんだけど、
建物の中から出てくるときの敵の当たり判定はどうやるんだろう？
まだ建物の中にある部分は弾が当たっちゃいけないんだし・・・。
やっぱりチップで判定するのかな？

**名前は開発中のものです。** · 04/07/09 23:44

>>482
そうね。
絵的なクオリティを上げていくなら3Dカードの機能を活用しない手はないでしょ。
あとマップエディタ。最近は出来のいい汎用エディタがあるのかもしれんけど
俺が作ってたときはマップに深度値を付加したりマップを複数枚重ねられるような
エディタが見つからなかった。この手の機能が無いとマップ編集作業をやってく
うちに不満が炸裂する。
　
>>485
俺は、森林地帯を戦車が通り抜けるシーンを作るためだけにエディタ
自作しちまった香具師なので、むしろアフォの部類かもしれんけど
独自の拡張がどんどん出来るので、自作したほうが結果的に楽ってのは同感。

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

>>487
チップで判定してもいいし。チップのZ値で判定してもいいし。
戦車が何かの下にいれば弾に当たらなければいいということで。

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

マップチップの話だけど、
元のマップの画像は、巨大な一枚絵で描いて、
それを１６×１６とか適当な単位で分割して、チップをあとから作ればいいんじゃない？

**名前は開発中のものです。** · 04/07/10 00:15

>>490
>>338

**名前は開発中のものです。** · 04/07/10 00:40

HSPｽﾚからきますた。

･･･最も速いと思われる当り判定のアルゴリズムを
伝授して欲しいんですが･･･。
CPU500MhzのPCで動かせることを考えると
どうしても処理速度と格闘せにゃならんので･･･。

飛翔鮎が500MhzのPCで軽快に動いてるのが
不思議でたまらないんですが･･･。

**名前は開発中のものです。** · 04/07/10 00:50

>>492
条件次第で変わるから、もう少し限定した条件を出してもらえると答えやすいかも。

判定する物体の形状とか、数とか。
あと、ハードウェア的な制約もあれば。メモリ量も重要だね。

MSXならスプライト同士の接触で割り込みが、とか。

**492** · 04/07/10 00:50

すまそ、質問しといて説明不足だったんで補足

敵弾ｖｓ自機の判定は
HSPスレのほうで解決してきたんスけども、
自弾ｖｓ敵の判定で凄まじく重くなってしまって。
現在実装中の当り判定は

自弾の数だけループ(1)
　　自弾の移動
　　　　敵の数だけループ(2)
　　　　　　自弾ｖｓ敵の当り判定
　　　　ループ(2)終
ループ(1)終

ってなってます。
当り判定の基礎はコレで良いと思うんですが、
うちではコレをやると処理落ちしてしまうんスよ。
（程度の低いSTGしか出来ていないのに････）

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

本当に当り判定の問題？
敵一個の場合とｎ個の場合の速度比べてみ

**名前は開発中のものです。** · 04/07/10 00:58

５００ＭＨｚもあるならインタプリタでもその程度かなり余裕だろう
それ以外のところがおかしいと思われ

**492** · 04/07/10 01:05

>>495-496
うむぅ、一番処理食ってるのが
自弾ｖｓ敵のループと
敵弾ｖｓ自機の判定
だと思うんだけど、
やっぱ別のところで無駄してるんですかねぇ？
敵1コとｎコの場合、明日辺り試して見ますわぁ

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

まぁ、良くある方法としては、
敵や弾の移動時に、y座標単位のテーブルに登録しておいて、
自機と一定以上近い座標にあるものに対してのみ当たり判定を行うとか。

それ以前に、その重さは考えにくいから、
やっぱ当たり判定自体かループがおかしい気はするが。

**492** · 04/07/10 01:29

思いっきりＨＳＰのソースで申し訳ないんですが、
当り判定ルーチンにはこういう内容のものが詰まってます。
http://cgi.members.interq.or.jp/hiphop/youhama/up/source/yaguyasu0495.txt

**名前は開発中のものです。** · 04/07/10 05:42

>>499
この程度で遅くなるかなあ…。
描画じゃないの？回転とか使ってるし。
ビデオカードによってはそれだけで結構遅くなるよ。

**ガルーダ** · 04/07/10 06:53

>>499
コードよくわからんけど、
貫通弾じゃない限り、ヒットしたら敵のループから抜ける
というのがなさげだけど？
あったほうがいいと思う。俺も全然やってないけど。
それ以前に、タスクのリスト総舐めしてる。

**名前は開発中のものです。** · 04/07/10 10:52

>>501
それは後のチューンナップの話しだね
初めは処理が最大の場合でも余裕があるくらいにしておかないと先が厳しい

**名前は開発中のものです。** · 04/07/10 12:24

俺の場合、まず全ての敵オブジェクトに対してBounding Circleによる簡易判定を行って、
ヒットしたもののみ引き続き厳密な判定をするようにしてる。

といっても、当たり判定ごときでそうは重くならないはず。

**名前は開発中のものです。** · 04/07/10 18:13

空間を格子状に割って格子内の物同士で判定を取る、とか低クロックのハードで
ゲームを作った際にやりました。
効果はかなりの物でしたが、５００Mhzもあればそんな処理いれなくても楽勝かと。

それなりの処理、ってのは重くないはですか？

**492** · 04/07/10 18:29

それなりの処理と書いたものの内容は
当たった瞬間だけの処理だから
重いのに影響はないと思うけど、
弾フラグ消し、
敵耐久減らし、
等の処理をします。

>>500が言ったように描画かもしれない･･･
633MhzのPCでは少し無理させても平気だった。

一番気になるのが、
俺の糞ゲーが500Mhzでガタガタになるのに、
飛翔鮎で軽快に動く、というのが･･･。

**名前は開発中のものです。** · 04/07/10 18:47

とりあえず重くなりそうな回転とか拡大縮小(使ってないかもしれないが)を減らしてみるとか
回転使うより回転パターンの絵を用意しておいて角度に対応した絵を表示した方がいいんじゃないか

**名前は開発中のものです。** · 04/07/10 19:11

そもそも描画にDirect3Dを使っていないとか。

**名前は開発中のものです。** · 04/07/10 19:12

HSPの限界じゃないのか？

その飛翔鮎とかいうのは、あたり判定ループの部分だけCで書いてるとか
HSPはそんなことがホイホイできるものなのかはよくしらんけど

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

efx_rotateってことはhspdxa使ってるんだよね？
ちょうど今マニュアル見てて気付いたんだけど
>>互換命令でのキャラクタ表示には、ビデオカードの２Ｄ機能を、efx命令でのefxパターン表示には３Ｄ機能を利用しています。
>>ビデオカードハードウェアがそれらをサポートしていない場合、劇的に描画速度が遅くなる事があります。
ってあるからビデオカードが原因かもしれないな

**名前は開発中のものです。** · 04/07/10 19:32

とりあえず当たり判定ルーチンをいったん外してから試したら？
それともそれまで平気だったのが、当たり判定を組み込んだら一気に処理落ちしたってことかな？

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

そうね。
まず何処で遅くなってるのかしっかり特定しる！

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

グラフィックス性能低いノートPCで
回転拡縮を使ってるとか。

**492** · 04/07/10 20:01

なんかefx命令が原因の可能性が濃厚に思えてきた･･･。

当り判定を外す、外さないとかじゃなくて、
当り判定に使うパワーが大きいからっていう理由だけなんですわ
どこで遅くなってるかと言えば当り判定以外考えられず･･･。

とりあえず、当り判定の中に重い処理を書き過ぎた
可能性が高いので、その辺改良してからそれでも
ダメだったらまたヘルプしまつ
ご迷惑おかけしてます(='ω`）ﾄﾎｰ

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

重いかどうかはあたり判定部分ごっそりコメント化してみればいいだけじゃないの？
ちゃんと問題の切り分けしたほうがいいぞ

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

とりあずいろいろ外してって原因を特定させるほうが先だと思うんだが…。

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

ぐぉ、かぶったｗ

**名前は開発中のものです。** · 04/07/10 21:30

まあそんなことも思いつかない奴だから

**名無しさん＠そうだ選挙に行こう** · 04/07/11 07:51

「やっぱHSPerだよな」と言われてしまうわけだ。

**名無しさん＠そうだ選挙に行こう** · 04/07/11 08:16

で、結果はどうたったんだろ…。
ほんとに原因究明しないまま改良とやらを始めてしまったのだろうか。

**名無しさん＠そうだ選挙に行こう** · 04/07/11 10:33

好きなように
やれば
いいんだよ
夏休みなんだし

**名無しさん＠そうだ選挙に行こう** · 04/07/11 10:38

みつお

**名無しさん＠そうだ選挙に行こう** · 04/07/11 11:53

もう夏休みなのか。
制服女子高生が見られない・・・

**名無しさん＠そうだ選挙に行こう** · 04/07/11 13:37

会社行くとき電車が空いてて嬉しい

**名無しさん＠そうだ選挙に行こう** · 04/07/11 15:26

だめだこいつ。
思い込みはハマりの第一歩だってのにな。

**名無しさん＠そうだ選挙に行こう** · 04/07/11 16:56

まだやん

**492** · 04/07/11 17:08

>>514-515
外したって。

**名無しさん＠そうだ選挙に行こう** · 04/07/11 17:50

外したの？

**名前は開発中のものです。** · 04/07/11 21:38

一度も外したと書いてなかったが、外したのか。で、外しても重たいままだったの？

**名前は開発中のものです。** · 04/07/11 22:14

描画する画面サイズがでかいだけだったとかいうオチだったりすて。
とりあえずゲームシステム的な観点で条件を書いてくれ526よ

1ループの同期時間 or v-sync
画面サイズ
ウィンドウ or フルスクリーン
転送元画像カラーbit数 and 転送先画像カラーbit数

などなど。

でもさーこれで「描画ルーチン外したら早くなった」とかだったらかなり顰蹙ものだなｗ

**526** · 04/07/11 22:31

1フレーム　16ms
V-syncは待っても待たなくても特に変わらず
フルスクリーン640*480　16Bitカラー
と、とりあえず言われた通り晒したけど、
描画で遅くなってる可能性が濃厚、と感づいたレス入れたはず･･･
それを試行錯誤してるトコですわ

>>528
HSPer(?)じゃない人にはわからないと思うけど、
描画もさることながら2重ループとか
入れると重くなることなんてしょっちゅうある
2重ループの中に一部の描画命令入れてるんで
当り判定ルーチンを外す＝一部描画ルーチンを外す
で、必然的に軽くなるってワケ
(この部分が悪いと指摘してくれる方が居たら
是非、と）

6 · 04/07/11 22:53

1フレーム　16msて
６０FPS超えてるよね？十分なのでは･･･
なんか俺勘違いしてる？

１６FPSの間違いなら携帯アプリ並だけど。

**526** · 04/07/11 22:59

16msそのままで計算すると62.5FPSになるんだけど、
HSPの性質なのかハードウェアの性質なのか
その辺はよくわからないけど、ちょうど59.xxFPSになるのが16msなんス。
PCによっては14msでやっと60FPSに近くなるものもあるらしい

**531** · 04/07/11 23:07

そっかそっか～・・・って
59ってかなり高速と思うが
その状態でガタガタに見えるの！？
安定してないとか？？

**名前は開発中のものです。** · 04/07/11 23:08

HSPの話題ですまんが、HSPDXAはウェイトだとFPS安定しないのでチューイせよ。

**名前は開発中のものです。** · 04/07/11 23:23

ん？
タイマウエイト掛けてさらに垂直同期待ってるってこと？

**531** · 04/07/11 23:39

HSPDXAてなんだろとおもてちと調べてたんだけど
HSPって結構すごいことが
できちゃうんですねとかおもいますた（´Д｀;)ﾊｧﾊｧ

**ゆうき** ◆MU2000.LWc · 04/07/11 23:50

迷い込んできました。

HSP&HSPDXAでSTGつくってます。
まだ途中ですが、ネットランキングとかにも仮対応させたので
暇な人やってみてください　○|￣|＿
http://ww22.tiki.ne.jp/~y-shirakawa/

HSPDXAは、垂直同期しないとFPS安定しないんです。
何か対策ないかなぁ・・・。

**ゆうき** ◆MU2000.LWc · 04/07/12 00:02

ログみてたらとんでもなく空気読めてないレスだと分かりました。
ほんとゴメンナサイ。

**526** · 04/07/12 00:07

>>533
ウェイト16とって、それを越えたら
当然FPS40とかになるよん
そうすると、とうとうガタガタになって、
スレのみんなに質問しちゃうってことです。

うちのPCの場合は同期とっても取らなくてもあまり変わりなかった
から気づかんかったけど、みんなの話だと同期なしだと安定しないっぽいね
今のうちからコンフィグで同期の設定できるように
しておいた方がよさそうかな？

>>535
同期待ちだけだとﾘﾌﾚｼｭﾚｰﾄ60以上のPCで困ることになるから、
16msの最低ウェイトを取る方法を採用してまつ。
何度も言うようにうちだと同期待っても待たなくても
一緒だから、テストのしようがない･･･
(最近は友人何人かに頼んでやってもらってるけど）

というかFPSとかの論争がある模様？
ほとんどのPCで同じFPSを出すのってやっぱり難しい？

**名前は開発中のものです。** · 04/07/12 00:10

いや、あんたの方法がダメダメすぎるだけ･･･
FPSをどのパソコンでも安定させる方法については
非常にすばらしい方法がありもう議論され尽くされてるから書かないが

**名前は開発中のものです。** · 04/07/12 00:11

>>539
いいじゃん、んなもんユーザに選ばせりゃ。

**名前は開発中のものです。** · 04/07/12 00:13

レスをみての推測だけど毎フレーム同じ時間だけウェイトを入れてない？
描画や当たり判定などの処理をしてあまった時間分だけウェイト入れないといけないんだけど

**名前は開発中のものです。** · 04/07/12 00:18

>>537
技術的な話をするなら別に良いんじゃないの。
完成品として感想聞きたいなら↓ここで晒すとか。
http://game6.2ch.net/test/read.cgi/game/1087558504/l50
ところでヤマハ音源使い？ｗ

>>539
＞ほとんどのPCで同じFPSを出すのってやっぱり難しい？
HSPではどっちにしろあまり融通は効かないと思う。
HSPDXAはウェイトがどうも信用ならないようだが。
何か他のタイマ使うとかで解決できないのかな。

**531** · 04/07/12 01:08

俺はまた実測アベレージで５９FPSかとおもたよ・・
多分、HSP(HSPDXA？）には更新時間を指定する命令があるんだろう。

一般的なシューティングでCPUやらカードやらで負担かかるっつったら
衝突判定と描画くらいなもんだし。
オブジェクト指向だと生成ってのもあるだろうけど。

で、衝突判定でないと言い張るからには
HSPの仕様上、CPUに負荷のかかる画像形式とか
不要な画像処理してますとかそんなとこかね。
もしくは弾幕が異常に多い→1000発超えてますなんつてな。ﾖｹﾗﾚ(ﾟДﾟ)ﾏｾﾝ

**526** · 04/07/12 01:11

>>542
設定したウェイトから
処理にかかる時間を引いてるので毎回同じ
ウェイトになる（はず）

>>540
本当に論争になっていたみたいだなｗ

**526** · 04/07/12 01:16

連レスすまんネ

弾幕にするつもりはないんで
150～200発程度でやってま。

とりあえず不要かどうかはおいといて
描画で遅くなってる可能性が90%くらいになってきた。
同じ500MhzのPC2台に協力してもらったところ、
一台ではガタガタ、もう一台では軽快に動作した
とのことで、ビデオカードのせい、
つまり、変なエフェクトかけ杉のせいっぽい。
だいたい分かってきた

**名前は開発中のものです。** · 04/07/12 01:53

なんでいまだに原因が推測なんだ？。
描画部分外して試せって言ってるのにやってないの？
ES_SET等の描画命令をコメント化すればすぐ出来るだろ？
何やってんのかぜんぜん判らんぞ。

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

>546
なんかドツボにハマってるような気がする。

もともと飛翔鮎が動くのに自プログラムだと・・・って話からの流れなのに、
他のPCで動いたから、んじゃービデオカードのせいだ・・・って事では、全然
問題が解決してないでは（汗

**526** · 04/07/12 03:00

>>548
痛いトコつかれた気がするけど思い当たる節はある
飛翔鮎ではあまりエフェクト使ってないから動くんだと思う
こっちのは回転・加算合成など使ってるから
せめて回転だけはどうにかするつもり
ビデオカードのせいというのは確定だと思ってる。
（じゃあもうこのスレ来んなと言われそうだがｗ）

**名前は開発中のものです。** · 04/07/12 03:39

来るなとは言わないが、質問しておいて指摘された問題点の検証を
しないならここに来る意味は無いだろう。

**名前は開発中のものです。** · 04/07/12 03:50

余裕でスルーですか(;´Д｀）
人の話を聞く気が無いなら質問しないでくれ。

**ガルーダ** · 04/07/12 05:28

>>544
現バージョンのガルーダ、計測してみたら最大１４２６キャラ出ててた；
ほぼ６０ＦＰＳだけど、ハイエンドなビデオカード使ってるから参考にはならんけどね。

**名前は開発中のものです。** · 04/07/12 05:56

この前SSのシルバーガンで当たり判定表示オプションつけてみたら、
物凄い数の長方形がぐるんぐるん回っててすげぇﾜﾛﾀ。
ソードなら３つの正方形、アカマルやミカエルは20個ぐらいの正方形がぐるぐる
動いてて、レーザーも正方形並べただけw
幾何学的に正しい当たり判定処理をうんうん唸って考えてた俺を思い出して
さらにﾜﾛﾀ。

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

単純な判定を組み合わせるというのは高速化もあわせて8bit時代からのtipsだぞ

たとえば丸いキャラの判定をどうするか
これは縦長と横長の２つの四角をくみあわせるだけでそれっぽい判定になる
さらにちいさめの正方形をあわせて３つになればほとんどの場合問題になることはない

**名前は開発中のものです。** · 04/07/12 12:42

丸？
Ｘ方向の差の二乗とＹ方向の差の二乗を足した数が
半径の二乗よりも小さかったら当たり。
でよくない？

**名前は開発中のものです。** · 04/07/12 12:43

すまん。これ、相手が点の場合のみ有効な方法だった。

**名前は開発中のものです。** · 04/07/12 13:24

丸っこいキャラでも正方形一つか二つで大概事足りるね。

**名前は開発中のものです。** · 04/07/12 14:11

>>552
あれでもそんなに出てるんだ。
ガルーダは大往生と同じ基板でスペック的には
大したこと無い筈（怒首領蜂より下）なんだけどな。

所々でソフトによるウェイトでなくマジ処理落ちするけど。

**名前は開発中のものです。** · 04/07/12 14:50

552が自前で作っている「ガルーダを参考にしたSTG」の話だと思われ

アーケードガルーダのオブジェクトは558の言うとおりで、300もない程度だろう
アレンジガルーダなら1000行くかも知れないが

**名前は開発中のものです。** · 04/07/12 14:56

PS2版を知らない人のために一応フォロー。アレンジガルーダってのはPS2版のアレンジモードのこと

**名前は開発中のものです。** · 04/07/12 16:46

さすがHSPerだな…

**名前は開発中のものです。** · 04/07/12 17:49

>549
とりあえずガンガレ。

HSPは良くわからんけど、Timerが使える環境ならデバッグ用に
ゲーム開始からのフレーム数と時間の差分なんかをダンプする
簡単な関数を用意しておくと何かと便利よ。本当はちゃんとした
プロファイラを用意するのが良いんだろうけど。

**558** · 04/07/12 18:28

>>559
ああ、そゆことか。
失礼した。

**529** · 04/07/12 18:32

なんだか予想通りの展開になってるし・・・orz

晒したソースの「それなりの処理」とか個別に外して
それでも当たり判定が遅いと言っているのか思ってた。

レスされた内容を吟味してないんなら漏れも550-551と同じ意見だ。

これでエフェクト外しても遅いって言ってきたら更に顰蹙もんだぞ。

**526** · 04/07/12 21:20

レスは大変参考になってるし
それにしたがってテストもしてる･･･と主張したいのだが
説明も下手だし状況報告も不十分だったから無理ぽいな。

でも今さら聞いてもらえるかワカランが
問題点の検証はレスに沿ってやってる。
最初当り判定だと思い込んでいただけだし、
描画かもしれないよ、と言われたら描画関連はいじったよ。
修正・検証に時間が掛かるのはソースが汚いからだと(特に描画専門のルーチンを作っていないあたり）、
俺のレスの程度の低さから察して欲しかった。

>>551は素で完全に見えてなかった、ゴメンナサイ！ｗ
今さらレスするとes_setは使ってない。（そういうことじゃないか）
描画は外した。もちろん速くなった。単純に弾の量は倍いける。

すまそ、つまり、
原因検証はしていたけど報告せずに
一人でソースいじって試行錯誤してた、と･･･。
叩かれて当然かもしれないけど、努力してたのは
少しくらい認めてください･･･。虫がいい話かもしれないけど。

**名前は開発中のものです。** · 04/07/12 22:16

アウトプットを出さないと何もしてないのと同じなので、同情はできないな

**名前は開発中のものです。** · 04/07/12 22:58

結局何をどうやって結果はどうなったの？
順番にやったのならどれがどうだったのかでも
報告してくれれば他の人も参考になるかもしれないのでよろしく

**526** · 04/07/12 23:31

①当り判定が悪いと判断しこのスレへ来る
（この時は既に当り判定を外し処理落ちしないことを確認）
②敵1のときと敵nの時の
　処理速度を大まかに計測。大体比例する。
③500がここで描画とビデオカードの
　ことについて述べるので
　友人のPC5台ほど(古いメーカーものでビデオカードの情報は無かったな･･･
　差はあれど軽快に動いたのは3台）
　でテストさせてもらう。結果はまちまち。
④514-515の指摘でとりあえず色々外す
　(色々すぎて何を外したかよく覚えてないが描画は外してみたはず）
　処理速度が向上したことを確認。
　描画、当り判定それぞれ外して処理が軽くなったので
　この時点では原因は分かってない（分かってなかったと思う）
⑤やっぱHSPerだよなと言われてしまう。
⑥FPSの話題になるが問題解決につながるような
　ことは無し
⑦友人のPCにて飛翔鮎が軽快に動き、俺のがガタガタであることから
　命令処理速度ではなく描画処理速度の問題であることに気づく。
　飛翔鮎ではエフェクトの使用を抑えているように見えることから。
⑧さすがHSPerだなと言われてしまう
⑨んで現在はあらかじめ回転させた画像を作ったり
　無駄な処理を削ったりしているところ。

とまぁ振り返ってみたけど
やっぱ俺のレスは内容薄かったね。。
すんません(='ω`）

**名前は開発中のものです。** · 04/07/12 23:53

まあいいけどさ…

なんか試し方がおかしい気がするんだが。
ウェイト無し、sync待ち無しにして
・デフォルト
・当たり判定ルーチンだけ外す
・描画ルーチンだけ外す
・描画ルーチンの回転拡縮、半透明処理だけ外す
それぞれでFPS計測して表示させれば、どこで大幅に処理落ちてるか判るだろ。

**偽ガルーダ** · 04/07/13 00:38

>>563
紛らわしかったですね。ｽﾝﾏｾﾝ

>>559
アレンジモードでは、１０００以上出てるように見えます。
自分のは、アーケードの弾幕を参考にしてますんで。
（アレンジ再現するなら、ＧＦ３以上は必須になるかと思うので）
ただ、頻度や配置の調整が全然で、初心者考慮して弾速を遅くしたので、
画面上に溜まってるキャラが多いと。
弾の封印等を入れたら、９００台まで減りましたが。

再現しようか迷ってるのが、倍率表示。
敵弾　Ｘ　Ｘ１００（＜（０～１００）４文字）で、
今の４倍近く表示数増やさないといけなくなる。
テクスチャＬＯＣＫして書き換えるにも、数が多く、全部独立してるし。
それ以前に、点数計算方法がわからない。ｗ
まあ、これはいらないかな？と。ｗ派手で良い演出なんだけど。

**名前は開発中のものです。** · 04/07/13 01:42

ん？テクスチャロックって毎回テクスチャ生成するの？
「×」と「０－９」を先に作っといてくみ合わせればOKでは？
さらにインチキとしては明らかに使用頻度が多い「x100」だけは事前に
できあがった画像を準備しといたりしてもいいかも。

**名前は開発中のものです。** · 04/07/13 02:12

>>569
そうそう、そういう手順を追った測定方法をすればいいんだけど、
>>568を読むと、場当たり的で原因を突き詰める方法を理解してなさげ。
偶然うまくいったら「うまくいきました」で済ませちゃいそうな感じ。

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

デバック能力も必要ってことだ。

**偽ガルーダ** · 04/07/13 02:47

>>571
Ｘ１～Ｘ９９の部分をテクスチャを生成するは、そうなるのかな？と。
でも、生成用のテクスチャを９９個持ってるんなら、初めから用意しててもかわらんねｗ
そもそも、そういう使い方は想定してないだろうし。

そのインチキ法は、書いてる時に思いついた。という事で、Ｘ＋２桁表示でいける。

でも、そこまでして入れるもんでもないかな。
一瞬でよく見えない部分だし。
それだったら、首領蜂系のように、○ＨＩＴと表示する部分を持ったり、
格ゲーのコンボみたいに１０ごとにgood!等の文字にするとかしようかと。

**偽ガルーダ** · 04/07/13 02:58

何度もスマン。

テクスチャを生成なら、画面全体をキャプチャするべきか。
だから、空テクスチャはデカイのが１つ。と。
そもそもするつもりないからよく考えず書いてた。

後は、最低動作スペックが気がかり。
ハードウェアＴ＆Ｌは必須なんで最低でも、GForce2MXぐらいは必須か。
描画周りには、殆どＣＰＵ使わない方針でやってるので、ビデオカード依存率高い。

**名前は開発中のものです。** · 04/07/13 03:06

グラフィックでちょっと無理したいならある程度のスペック要求は仕方ないね。
GForce2MXくらいなら問題ないと思うけど。

**名前は開発中のものです。** · 04/07/13 11:08

ここは、とてもやさしいスレですね

**名前は開発中のものです。** · 04/07/13 11:59

ところで、みんなは必須スペックをどの程度に見積もってる?

俺は開発環境が古め(Althon700 + GeForce2MX)なので、
それでやってる。
一応更に低い環境(Celeron500 + M-RAGE)でもテストしてる。

**名前は開発中のものです。** · 04/07/13 12:37

celeron300 + TNT
開発環境がこれなので。

**名前は開発中のものです。** · 04/07/13 12:45

いまだDirectDraw野郎な俺はSurfaceに使えるVRAMが8Mあるマシンを想定
CPUはP3-600MHzぐらい？

しかし開発環境はVRAM2.5MBしかない…orz
#Let'sNote M2な

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

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