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

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

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

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

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

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

**名無しさん＠そうだ選挙に行こう** · 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な

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

Pentium4　1.6Ghz　Geforce4440go　ノートで開発
半透明処理を随所に施したゲームを開発してた時↑なら楽勝だったけど
予備のPCで動作させたら重たくなって焦った事があるよ

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

GeForce3/RADEON8500以上必須。

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

漏れはマヌアルに「～必要」って書くのが嫌いなのでDirectXは一切未使用。
ゆえに求めるスペックはCPUのみ。
それでもPen2 400くらいあれば余裕。低スペック志向な漏れ・・orz

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

今だとJava２Ｄがかなり早くて環境に合わせた
アクセラレーションを選んでくれるので
DirectXを使用しないという人にはいいだろうね

そういう人はＤＩＢやＤＤＢでアプリ作ってそうだし
何げにNT4でもXPでもちゃんと動くのは面白い

500MHzクラスのマシンでスプライトが16bpp/60fpsで
1500個でたので問題ないなぁとおもた

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

>>578
PenIII-700～800あたりとGeForce2くらいで処理落ちせず動けばとりあえずOKライン。
それより下でも動くようにはしたいけど執着はしない。

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

PenIII 800 + RADEON7500ぐらい。
(GeForceで言うと2MXぐらいなのか？)

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

パンピーの使うメーカー製PCも対象にしてるので、Intel Extreme Graphics 2とSiS315。
あとはGeForce4 MXとRADEON 9000あたり。

**偽ガルーダ** · 04/07/14 06:23

>>578
自分の開発環境は、P4(2.8),RADEON9700PROに、
ノートがPM(1.6),モバイルRADEON9000です。
どちらも快適に動きます。

で、低スペック検証用というか、ただの物欲でシャープのモバイルノート、
PC-MM50Fを購入しちゃいました。(CPU:TM8600 1.0G,モバイルRADEON)
動作させた所、最低で30FPSまで落ちる。う～ん。きついか。普段は落ちないんだが。
更に言うと、DVD-Rに焼いたDivXムービーがコマ落ち激しい、、。
今、VC++等を入れてる所です。

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

>>578
どんなゲームかにもよる。スペックを超えたゲームとはいかないまでも
せめて「このゲームにしてはオーバースペックだな」
と思われないようにはしたい。

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

>>588
そんなに低スペックではないよな
同クロックのPenMより遅いが同クロックのPen3クラスの性能はある
ビデオがかなり貧弱であるか
もはやＵＭＡビデオカードより低スペックだしなぁ

でもＵＭＡの性能が確実に上がっていて、そういうマシンは
どんどん増えているからこのあたりで手を打つのは悪くない
ＣＰＵだけはどんどん上がっているのでそっちでカバー
するような作りが出来ればね

DiVの再生が思いってのは違うところがネックになってるんじゃ・・・

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

>>588
＞DVD-Rに焼いたDivXムービーがコマ落ち激しい、、。
　
それは激安DVD-Rメディアを使ってるのでは。

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

今もってるパソコン
Pentium4 2.4G　メモリ 512
ビデオ：sis651のオンボード
OS XP
が、初めて買ったパソコンだから
動作環境の定義が自力で出来ないです orz..

**ゆうき** ◆MU2000.LWc · 04/07/15 00:01

ひとつ前の作品なんか、
ノーウェイトでFPS=300ぐらいだったから、
単純に2.4を5で割って500MHz　とかｗ
かなり無責任なこと書いてました。

今回はいろいろ報告があってウレシイんですが。

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

自作やってる仲間が多いと、低スペックPCの1台や2台
タダですぐに組めちゃうんだけどねｗ

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

>>590

＞もはやＵＭＡビデオカードより低スペックだしなぁ
これ以外だった。RADEONというのに騙されたかな？9000以上は非常に良いっぽいけど。

モバイルで開発ってのは、まだ厳しいのかな？
VC,DirectXは動作確認したので、一応は出来るようだけど。
今VC#入れてます。

**ゆうき** ◆MU2000.LWc · 04/07/15 00:18

>>594
みんな　もってない　or 最近の企業の　なんです('A`)
って、俺も自作なんて良くわからんヘタレですが。。。

っていうかHSPなんで、描画なんてライブラリ作った人まかせ。
偉そうに動作環境とか書く権利すらないような・・・。
ウインドウズの知識はおろかCPUとかの動きなんて何も知りません（´・ω・`）

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

CPUの動きなんて俺も知らぬｗ

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

>>595
というかUMAのチップセットがここんところ速度品質ともに進歩しすぎ
元々ネックはメモリ帯域だったんだけどDDRが標準になってきたり
PentiumMや90nmのPen4とか大容量キャッシュが当たり前になってきたりとかね

あと地味にクロックが上がっていたり(855GMEあたりは250MHzなはず)
パイプライン数が増えていたり確実な進歩しているよ

単純な速度的にはノートのは無印RADEONとほぼ同じと思っていいはず
ただ、VRAMがUMAのほうは64MBまでとれるので何かと便利
最近は同人レベルでも16MB超えるのがあったりしてるしねぇ

ただ、こういった底辺のチップセットはまだまだDirect3Dは重く、
速度的にDirectDrawに大差つけられてる
回転機能が欲しかったら３Ｄで実装するよりＶＲＡＭ１６Ｍくらいくってもいいから
１６方向分起動時に描画してバッファに持っておくとかすれば低スペックマシンで
快適になるだろうといった考え方が必要かな

**582** · 04/07/15 00:52

>>595
Mobility-RADEON-D(16MB)は
GF256(DDR) ～ GF2MXの間ぐらい。

Fixed-T&L機能搭載のﾋﾞﾃﾞｵﾁｯﾌとしては
最低ﾗｲﾝだが、PIII-1GHz程度のCPUとの
組み合わせならば3DMark2000の点数で
3500程度は出る。

俺のサブノートがこの組み合わせなのだが
Unreal Tournamentが60FPSで動いている。
2DSTGが重たくなるのは、比較的派手な
演出をしているかコードがおかしい場合のみ。

**582** · 04/07/15 01:03

>>598
16MBの内蔵DDRメモリにテクスチャが収まる場合
よほど間抜けなコードを組まない限り軽快に動く。
　
BF1942でさえ30FPS出るのだから、要は組み方の問題。　

**偽ガルーダ** · 04/07/15 01:47

>>598,>>599
ナルホド。参考になりました。

＞派手な演出
特にないです。
回転についても、まだ保留しています。
（完全に再現するなら、パターンで持つしかないんですが）

＞コードがおかしい
ＣＰＵについては、まだ全然チューニング出来てないです。
特に、メモリプール、ハッシュ等は。

まあ、追々やってきます。

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

>>600
2Dのほうが大幅に早いってのは855GMの話な
さすがに１フレームあたりスプライト数１０００は変わるので
かなりかわるというわけさ

**582** · 04/07/15 12:20

>>602
それは全く事実ではない。
i855GMの内蔵グラフィックス機能（Intel Extreme Graphics2）は
RivaTNTクラスに相当する。ハードウェアT&Lを搭載していないが
ラスタライズはハードウェアが行ってくれる。
　
このような構成のビデオチップでは、アプリケーション側のコードで
行列計算を行い、T&L済みの頂点データを流し込んでやるのが
一般的だ。2Dゲームの場合は特にパフォーマンスが改善される。

**582** · 04/07/15 12:24

http://pc.watch.impress.co.jp/docs/2003/1105/hotrev234.htm
　
参考までに。

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

>>604
それ7500やん
無印とだいぶ違うぞ

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

一応補足しておくけどDirect3Dで全く回転させない描画とDirectDrawの比較な

だからT&Lがどうのこうのというレベルではないよ
単純にバッチで処理するようになってるので
単体使用ではオーバーヘッドが大きいというだけさ

だからこそ低スペックＰＣでの話な＞回転機能OFFでDirectDraw

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

>>603
そうですね。私はi854ユーザーですが
Quake2エンジン系のゲームちゃんと遊べます。
Direct3DのソフトウェアT&Lパイプラインは
2DSTGには非効率ですから自前でやりますね。
　
>>605
ベンチマーク結果の表を見ましょう。
右隅はi855GM。T&L未搭載でUMAです。
真ん中はモバラデIGP。モバラデのUMA版です。
Quake3-Arenaに注目してください。

**582** · 04/07/15 13:58

>>606
つまり、フルスクリーン256色モードでカラーキー使った
VideoMemory(UMA)->VideoMemory(UMA)のBlt()と
Direct3Dを比較していたということか。

別にそれでも構わないが、DirectDraw VS Direct3D の
重い軽いを比較するにはやや不条理な前提であろう。
　
前者はVideoMemory(UMA)->VideoMemory(UMA)の矩形転送。
つまり全ての描画はハードウェアラスタライザの支援を受ける。
　
それと同じ処理をDirect3Dでやるということはハイカラー以上。
VideoMemory(UMA)->VideoMemory(UMA)の矩形転送では
データ転送量は最低でも倍になる。

古いビデオチップであろうと新しいビデオチップであろうと
DirectDrawにとって極めて有利な条件といえる。

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

俺は昔からハイカラーしかつかわんよ
riva128クラスからは256色のほうがblt遅かったし

多機能な３Ｄのほうに不利な条件ってのは分かってるけどね
だからこそメモリ使用量を抑えて３Ｄ描画より回転させる程度ならその分用意すればいいといったまで
省メモリと速度とのトレードオフだが、要16MBくらいなら今は許してもらえる範囲か？という話な

あとQuake３の結果はまったく当てにならん
CPUがPenM1.4GHzと高速な割に可変フレームレートで70fps程度しかでてないことから
１ＧＨｚ以下を対象に２Ｄの固定フレームレート維持は結構厳しそうだ

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

前にも出た気がするけど、みんな画面の解像度いくつでやってる？
横STGなら俺は320ｘ240でやりたいんだけど、縦で画面比3:4にこだわると
縦240ドットだとどうしても小さすぎるんだよな。
レトロコンシューマ風なら横長320ｘ240もアリだと思うけど、アーケード風で
やりたいので…。でもアーケード風だと縦480は細かすぎる罠。

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

じゃあ300x400でどうよ

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

今なら躊躇無く640×480でいいんでない？

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

320*240はちゃんと表示されない環境多いし
誰でも出せる640*480だろう

自分さえよければいいという人はしらね

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

320*240を2倍に拡大するのがいいのかなー。

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

アーケード風縦画面縦STGなら横360縦480で決まり
640x480の解像度以外は遊べないプレイヤーが出てくる
画面全体を任意拡大できるSTGもいくつかあったな

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

個人的には、2DSTGもD3D必須となっている今、
多少VRAMを多く使うとしても、800*600に移行し始めてもいいと思うんだけどな。
今どき320*240なんてみみっちいものを選ぶ理由ってなに？

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

ドッターが死ぬ

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

>>616

>>610はアーケード風でやりたいから、と書いてるぞ

**610** · 04/07/16 02:09

レスThx。
主にアーケード2DSTG風ね。
やっぱVGAの縦をいっぱいに使った360ｘ480に落ち着くかなあ。
ちょっと細かいんだけどね～。
800ｘ600にしてピクセル縦横2倍のほうが（実質300ｘ400）雰囲気は
近いかな。速度とメモリが問題なければこれもアリか。

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

往年のは縦320なんだよな。
ウィンドウモード限定にして縦640または960なんてことをやると…環境によってはマズいかな？

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

240*320で縦シューつくって
フィルターかけずに
1240*1024の解像度に
3.0倍拡大させて描画

**610** · 04/07/16 03:40

今更619の訂正
×＞800ｘ600にしてピクセル縦横2倍のほうが（実質300ｘ400）
○＞800ｘ600にしてピクセル縦横2倍のほうが（実質225ｘ300）
何やってんだ俺様orz

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

関係ないが、今開発のために1280ｘ1024の液晶モニタを縦にして
2台横並べで使ってるんだけどさ、
この環境だと殆どのフルスクリーンのゲームが動かないんだよな。
当たり前だろといわれればそうなんだが…。
（Radeon9600pro使用、ドライバによる90度画面回転）

縦シューを縦画面でやりたくても、そういうのってなかなか無さそうだ。
そもそもSXGA液晶だと縦横比4:3じゃないしね。

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

今の俺の案
ゲームワールドは240x320（縦）で作成。
これを２倍に拡大して画面解像度1024x768の中心に。（表示域は480x640）

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

モニタを横倒ししてください、という同人ソフトがあってもよいと思う。

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

同人じゃないけど、キャリーラボのギャプラスを思い出す。

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

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