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

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

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

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

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

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

**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

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

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

98VM以前だっけ…？

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

DirectDrawで縦2DSTGの雛型作ってるんだが、各描画オブジェクトを実際にDraw
する時の順番の管理に悩んでる。

つうのは各キャラクタには”高度(z)”の情報を持ってて、高度が低いｷｬﾗは小さく、
高いｷｬﾗは大きく描画する予定（レイフォースの敵雑魚を想像してくれい）なんだが、
ここで描画の順番を考慮しないと高高度を飛んでるキャラクタの上に低空を飛んでる
小さいキャラが上書きされてしまう事がありｶｺﾜﾙｲ。

１フレーム毎に全ての雑魚を高度情報を元に描画順をソートしてると時間がかかりそうなもんだが…
なんか良い手はないんかね？

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

ふつうにソートしろ

２００ＭＨｚ以上がターゲットならば
スプライト１０００くらいバブルソートでも余裕だぞ？

６０ＭＨｚクラスだと少し厳しいかもしれない

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

>>628
そんなに時間かからない。2Dシュー程度のオブジェクト数なら、
何も考えずCのqsort()とかC++のsort()とか使って平気なくらい。今時のPCは滅法速いからな。

ソート時間実測してみて、本当に重いようならバケツソートとか基数ソートとかを検討のこと。

**628** · 04/07/16 19:40

気にし過ぎだったかな
普通にソートしてみるよ
ﾏﾝｶﾞﾄ

ﾉｼ

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

２Ｄの場合ソートする必要があるオブジェクトの方が少ないんでは？
少なくとも敵弾のプライオリティは他のオブジェクトよりも上だろうし

**偽ガルーダ** · 04/07/16 22:58

定期報告です。

敵情報設定ツール、ステージ設定ツールに敵配置機能を追加。
どちらも仮実装で、まだまだ仕様が固まってないです。

ランタイムの方は、配置データを食わせるのと、
仮タイトル画面＜＞ゲームの行き来を実装。
これからボスにかかります。
その後は、無断使用している素材の全書き直し、、。

自分の場合、２Ｄのソートはとりあえず避けました。
拡大すると不味いんだけど、取り合えず、アルファテスト使ってます。

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

古典的な方法なら、初めから高度別にリストを何本も用意しておくのが普通ですな。

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

毎回ソートしない手としては、
描画専用のリスト構造を用意して、それを常にソートされた状態にしておく、ってのがある。
挿入やZの移動が発生したときだけリストを辿ればいい。

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

PSのオーダリングテーブルと同じ方法でいいんじゃねーかな。

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

>>634
>>636
うむ。それがバケツソート（bucket sort）。

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

ほんとだ。調べたらそのまんま説明が出てた。
バケツソートを使うのが普通じゃなかろうか。

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

素材で思い出したんだが、開発途中の素材の管理も面倒じゃね？
沢山のキャラや各パターンのビットマップを最終的に１枚のビットマップに纏めてるんだけど、
>633みたいに後から差し替えるとなるとかなり手間なんだよなぁ
もっと簡単に管理したいんだが･･･

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

バケツはその名前しらなくても少しでもプログラムやっていれば
自然とみんな使うようになるアルゴリズムの代表だね

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

オレは最近は手抜きで、
バケツは使わずにC++のstd::multimap使ってる。

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

ぶっちゃけゲーム、とくにＳＴＧなんて
コレクション系使いこなすための勉強にすぎない

といいたくなるくらいコレクション分かっていればどうにでもなるからな
一番技術的なレベルが低くても作れる物だけに熱くなれるというか

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

>>639
素材は１パターン１枚のビットマップで作る。
最終的にそれを編集して一枚のビットマップにするツールを自作。
マップチップツールの応用で結構いける。
ツールにはパターンマップを吐かせる。
後から配置換えしたくなっても、ツールでいじればいいので簡単。
場合によってはパレット管理つけるとかお好きなように。

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

>>642
バカは帰って寝てろ邪魔だ

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

>>644
俺なんかへんなこといったか？

ＳＴＧは制作者側にとって一番敷居が低いゲームだろ
絵や音楽が優れてなくともアイディアとかバランス面でなんとかなったりするものだ

それだけにゲーム本編に力を入れることが可能だし、
職業プログラマなら気にしなくとも日曜プログラマのような趣味で作る場合
少しずつの時間の捻出でなんとでもなるというのが大きい

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

シューティングを作る技術＝プログラム技術と思われたらかなわんな・・・。
そのアイデアやバランスのノウハウも含めてのスレタイじゃないのかい。

百歩譲ってそうだとしても、君の理屈だと（例えば）ポリゴンＲＰＧやらＡＤＶの
プログラマーなら、ＳＴＧなど朝飯前で作れるという事になるのか？
そこまで言うのなら、自らの作品を以て実証して頂きたいものだ。

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

真っ先にゲームプログラム開始してそれなりに形になるのがＳＴＧだから
８ｂｉｔ時代にＳＴＧから勉強下って人は多いんじゃないのか？
いっておくけど、他のジャンルと比べて簡単というのは単純に技術力だけの物じゃない

ＲＰＧやＡＶＧなんかはボリューム出すためにだれやすく最後まで完結させることは難しい
また絵や音楽が重視される傾向にあるために一人で作るのは難しい

とりあえず最初に進むべき基本となるのが２ＤＳＴＧと思っただけだ
ＸＹとスプライト表示さえわかればどうとでもなる
それだけに基本は非常に単純であるが奥深いもので初心者から上級者まで
一緒に語りやすいいいジャンルじゃないのか

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

おいおい、釣られるなよ。
６歳並の絵しか描けない大学の教授だって、
絵について能書きたれたいこともあるんだよ

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

朝飯前で作れても
それが面白いかどうかは
また別の問題になるしな

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

テキトーなもんならシューティングに限らずどれも大して変わらないと思うが。

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

結局何が言いたいのかも不明だしな
口だけなら何とでもという典型

**偽ガルーダ** · 04/07/18 09:05

>>641,>>642
コレクション系ねー。何が良いのかちゃんと研究してないな。
これが良かったとか教えてくれると嬉しいな。

現在使用してるのは、ms標準のvectorとlistだけ。
（しかもベクターモドキ使ってる。標準のだと、中身が見辛い。それだけの為にｗ）
ファクトリーにはmapのが良いらしいけど、何かの本にmapは遅い。と書いてあったのでこれもvector。
にしても、オーサリングツールが整ってくると、結局汎用クラス作った方が楽な気がしてきた、、、。

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

ファクトリにvector？　逐次探索使ってるんか？
それに比べたらmapのほうが高速だと思うが。
それともハッシュと組み合わせたらvecto

mapが遅いのはおそらく同様の

mapは内部構造が二分木だから遅いんじゃなかったっけ？
ハッシュ二分木のhash_mapってのがSTLに追加されたと思う。
そちらを使ってみては。

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

ああ…編集中に書き込んでしまった＿|￣|○

mapが遅いのは同様の機能を別の方法で実装したときのほうが速い
というだけであって逐次探索に比べたらよほど速い。
で、この程度のことならハッシュを使うのがいい、ってことかな。

**偽ガルーダ** · 04/07/18 09:42

>>653
ファクトリに、newされたポインタを返すstaticメゾットと
オブジェクト名をセットにしたクラスを登録してます。
まんまmapの分野なんですがね、、。

文字列検索はそこらじゅうで使ってます。ｗ
ハッシュを使うのがいい。てのは判ってるんですが、
差し迫ってないので、保留してます。ｗ
それとアロケート系がＣＰＵ負荷の殆どだと予想してます。
どちらも、数の上で重要であろうは、タスクステータス関連ですが、
アルゴリズムとメンバの分離をやるべきかと思うけど、手付かずです。

そもそも、ＣＰＵと描画の負荷をチェックする機能そのものがないですが、、。
追々やります。（最初にやるべきか？）

公開出来たら、追々ソースも晒そうかと思ってます。
酷くショボイので、勇気要りますが、、、。

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

SGIのSTLが元になってる系列のSTLならhash_mapは標準装備されてる(gccとかSTLportとか)。
デフォルトアロケータも一旦プールを作って使い回すような作りになってるので、
別にOSのメモリアロケート速度が遅くてもそんなに影響しないようになってると思う。
結局は思い込みでチューニングせずに、ちゃんと計測しないと却って遅くなってるかもよ？

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

このスレも３機目のようなので
よくわからないけどエクステンドしておきますね

(・ω・)ノ　[1up]

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

10upくらいしちゃった（茸）

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

ろじっくかよ。

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

今週末はグラディウスVをトコトン調べつくそうぜ！

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

グラ5ってアケじゃないのかよ・・
もう達人シューターがギャラリーはべらせて超絶プレイを披露する
時代は終わったのか・・orz

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

今は達人シューターがリプレイをupして
超絶プレイを世界中に披露する時代、なのかな？

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

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