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

シューティングゲーム ..

100:名前は開発中のものです。
08/03/21 13:08:41 kWp5gXWi
2は横移動先が壁にめり込んでたらめり込んだ分横に押し戻し
3はスクロールしてめり込んだらめり込んだ分スクロール方向に押し戻し
とか

101:名前は開発中のものです。
08/03/21 13:44:46 XmgrQpyE
２は普通に作ればたいてい空いてる方向に移動すると思うぞ
要するに、キー入力方向に壁があったら、その方向の移動量をゼロにする
あと、地形を重視するなら大きなマップの中で視点がスクロールすると考えるといい
一度アクションゲームを作ってみるといいよ
4点とも簡単に解決できる

102:名前は開発中のものです。
08/03/21 23:10:22 Y2tGkS1P
ありあとうございます。

>>100
今やっているのだとそんな感じなのですが、斜めの壁のとき
おかしくなる気がします。X方向とY方向を別々に判定してるんで
順番によっても変になってる気がします。

>>101
その場合先に壁と隣接しているかどうか判定するのでしょうか
今考えてるやり方だとめり込んでから戻すって感じなのですが。

103:名前は開発中のものです。
08/03/22 00:30:26 YjjlX8do
>>102
縦壁だけじゃなく斜め壁もあるのか
そしたら斜めの当たり判定のとり方から説明が必要？

それとも壁の角に斜めにぶつかった場合ってことだろうか
>>100はx方向を先に判定すれば壁の角から横に進むしy方向なら縦だし
どっちにも進みたくないなら別の処理が必要だし

どっちにしてもどういう挙動がおかしい挙動なのか仕様がわからいとなぁ

104:名前は開発中のものです。
08/03/22 00:43:49 8Y+Va9zt
めり込んだら押し戻すで全部解決するはずだがなあ・・・
接触判定がおかしいんじゃないのか？

105:名前は開発中のものです。
08/03/22 05:42:47 44zgMaPM
>>102
「壁ずり」で検索

106:名前は開発中のものです。
08/03/23 13:04:48 VlbCWj/H
当たり判定ってどんな形にしてる？
円形または矩形で統一するのが楽だけど、
円形だと細長い弾やレーザーが、矩形だと斜めの弾の表現が難しい
複数の矩形とか？

107:名前は開発中のものです。
08/03/23 13:25:23 d2zOUJKL
俺は基本的には矩形以外使わないな
ところで斜めの弾ってなんだ？

108:名前は開発中のものです。
08/03/23 13:40:58 XpxtelVy
俺は楕円にしてる

109:名前は開発中のものです。
08/03/23 13:43:51 9Ostvv4d
矩形だけだな
斜めは回転で対応

110:名前は開発中のものです。
08/03/23 13:46:52 VlbCWj/H
斜めの弾＝斜め方向に飛ぶ弾、斜め方向に長い弾
矩形だと見た目とずれるし、矩形を回転させるのは手間。楕円も同じ
円形だと、斜め向きでも縦向きでも
尖がった部分に当たり判定が無いのは共通だからまあマシかな、と

111:名前は開発中のものです。
08/03/23 14:02:08 DkU5E/rv
円形で細い弾は作らない。

112:名前は開発中のものです。
08/03/23 14:14:31 d2zOUJKL
>>110
針弾のこと？
矩形回転くらいやんなさいよｗ
それが面倒なら針弾なんか使わなければいい。
丸い弾だけなら正方形判定だけで出来る。

113:名前は開発中のものです。
08/03/23 15:33:05 SMEFBCL/
俺は斜めだろうと楕円だろうと何だろうと正方形で済ませてるど素人です。
自分でプレイしてて全然気にならないんですが、
やっぱ弾幕シューとかだと重要なんでしょうかね。

自分は緻密な弾避け行為にこだわってないから解んないけど
そういうのが好きな人は違うのだろうか。

114:名前は開発中のものです。
08/03/23 15:40:46 ZbRSLUlC
まぁ、好きな人はそういう仕様まで利用していくから良いと思うよｗ

115:名前は開発中のものです。
08/03/23 15:58:42 4ckcNna2
弾幕目の敵にしすぎﾜﾛﾀ
弾幕ゲーじゃなくても、見た目と違うあたり判定はどうも嫌いだな
某同人弾幕ゲーは見た目と当たり判定の乖離がひどいが

俺は矩形の当たり判定を複数持たせて近似している
地面とかは円形だとうまく表現できないし
本当はビットマップを走査して判定したいけど、さすがに重過ぎる

116:名前は開発中のものです。
08/03/23 16:14:15 XpxtelVy
線分交差判定か何かでいいんじゃないか

117:名前は開発中のものです。
08/03/23 18:40:14 d2zOUJKL
見た目と違うというが、昔からゲームやってる人間なら
むしろ見た目どおりの判定のほうがおかしく感じるハズだｗ

118:名前は開発中のものです。
08/03/23 20:14:18 2cPCy0BJ
何回もやってりゃなれるしな

119:名前は開発中のものです。
08/03/23 21:27:48 cK7bOzt5
自機の当たり判定が点なのに
弾の判定が見た目と違うと文句をつけるのもおかしな話だ

120:名前は開発中のものです。
08/03/23 22:14:24 /kBQhQQw
んだな

針弾の当たり判定オブジェクトが矩形（正方形のAABBの数珠繋ぎ）でも
判定が甘め（針弾イメージからAABBが飛び出ない）なら俺は気にならん

だが矩形回転（OBB）が面倒とかいうのも
ちと情けないというか。高校レベルの算数だろ

121:名前は開発中のものです。
08/03/23 22:17:16 /kBQhQQw
あと針弾をAABB数珠繋ぎでやるくらいなら
円の数珠繋ぎのほうがマシな気がしないでもない

122:名前は開発中のものです。
08/03/24 00:08:41 +0T08afk
>>120
×算数　○数学

回転矩形同士の当たり判定は結構面倒だと思うが
難しいんじゃなくて面倒

123:名前は開発中のものです。
08/03/24 00:29:47 Yr94LLRU
STGスレだから
OBB vs 点の判定という前提で
簡単と書いたったのゆーしてくらはい

124:名前は開発中のものです。
08/03/24 10:01:29 IupNpfeC
俺は先端に矩形を一個だけｗｗ
手抜きサーセンｗｗｗｗｗ

125:名前は開発中のものです。
08/03/24 11:24:17 mEuEcy6w
それで良いんじゃね

126:名前は開発中のものです。
08/03/24 12:08:38 fwLvQ6Ft
難しいとか面倒とかでもあるけど
比較的どうでもいい事に処理を食わせたくないという旧い人間な俺。

127:名前は開発中のものです。
08/03/24 12:35:06 mEuEcy6w
たとえば中型のプロペラ機の機体後部とか尾翼とかに判定なんか要らんのですよ
主翼部分だけで良いんです

128:名前は開発中のものです。
08/03/24 13:17:05 sI3+U67E
>>115
どうでもいいけど、確かひとつのオブジェクトに複数の当たり判定を持たせる、
という方法はセガが特許をとっていたはず

129:名前は開発中のものです。
08/03/24 13:27:41 mEuEcy6w
知らんがなそんなもんｗ

130:名前は開発中のものです。
08/03/24 14:00:30 3DNtnzJR
>>128
3Dオブジェクトの周りに球形の当たり判定を複数つけるというのがセガの特許だから
2Dなら大丈夫なんじゃないか？

131:名前は開発中のものです。
08/03/24 14:31:02 fwLvQ6Ft
そんなんで特許取れるのか……。

132:名前は開発中のものです。
08/03/24 14:34:58 GL5PdgnZ
＞特許3603898
＞特開2003-299877
＞交差判定方法及びこれを用いたゲーム装置

この辺かなぁ

これ普通に既知・公知の基本技術だよねぇ
趣味野郎にとっては完全無視しても事実上無問題の話だけど
ゲームで飯食ってるその手の業界の競合他社の法務部門は
こういうナメた特許を取られて異議申し立てもせずに
完全スルーしてて大丈夫なのか？タダ飯食って寝てるだけだろ

133:名前は開発中のものです。
08/03/24 16:20:11 mEuEcy6w
アメリカで「入力装置による操作で画面の絵が動く」とかいうサブマリン特許で
ゲームメーカー各社が訴訟起こされたりしたからな。そこら辺は防衛手段だと思われ。

134:名前は開発中のものです。
08/03/24 20:09:54 RTOqTDW3
もういっそ
「誰でも考え付くくだらない技術で特許を取る方法」という特許を取ればいいのに

135:名前は開発中のものです。
08/03/24 22:03:31 nPahSoi8
普通に矩形判定の回転とかやり方が思いつかない理系の俺はどうしたらいい？

136:名前は開発中のものです。
08/03/24 22:22:10 sI3+U67E
回転した矩形の衝突判定なら、多角形の衝突判定でいいと思う

137:名前は開発中のものです。
08/03/24 22:23:12 k9aWkyJr
>>135
中学生？

138:名前は開発中のものです。
08/03/24 22:31:04 YAOqhvfe
敵キャラの基本と思ってスライムを作った

あー、STGの空飛ぶ世界でスライムって使いどころが……

139:名前は開発中のものです。
08/03/24 22:33:21 V5wQxKJV
横シューでグラVのバスクリン見たいに落ちてくるとか

140:名前は開発中のものです。
08/03/24 23:21:17 nPahSoi8
>>137
えぇ。適当にベクトルの式の立てて解くっぽいことしか想像できないｗ
しかもやり方わからんし
数Cもっとまじめにやるんだったかな・・・ちょっくら高校の教科書とにらめっこしてくる。

141:名前は開発中のものです。
08/03/24 23:44:00 YAOqhvfe
一方がもう一方に入り込む可能性を無視するなら、各辺が交わっているか判定する
入り込む場合は、一方の頂点がもう一方の領域に入っていることを判定する

頂点が領域に入っている判定は、
矩形に限定するなら、座標変換した後、普通に矩形と頂点の判定をするとか
凸多角形なら、辺と頂点の位置関係（常に頂点が辺の左側にあるか）を判定すればOK

こんな感じ？

>>139
背景の当たり判定考えてないんだよねぇ
何か土台でも作ろうかな

142:名前は開発中のものです。
08/03/25 00:22:40 +WqpoOyM
ライフゲージをスライムの大きさで表示
そしてアイテムは全部スライム

143:名前は開発中のものです。
08/03/25 00:32:40 9+3bwAjS
普通に地上キャラでスライムだせばいいのでは・・・

144:名前は開発中のものです。
08/03/25 00:39:21 BjCc4re0
接触したら、コマンド入力方式戦闘シーンに突入すればいいのでは……。

145:名前は開発中のものです。
08/03/25 01:38:38 uFzRVnSV
ゲーム中の物体は全てオブジェクトで、
登場するたびにnewでメモリ確保してlistに突っ込んでるんだが、
newは自重したほうが速度的に有利なのかな
いまどきのPCなら問題ないよ・・・な？

146:名前は開発中のものです。
08/03/25 11:55:46 mSvRfoAk
そのぐらいの最適化、ちょっと手を加えれば済むんだからやっとけよ
プールして再利用、あとは事前にまとめて確保しておけ

147:97=99
08/03/25 12:04:14 pBCIUDY5
遅くなりましたがいろいろありがとうございました
今試行錯誤中です

148:名前は開発中のものです。
08/03/25 19:28:38 njfgxTgM
>>141
まさにその形で組んだ所だったよ。

内包する場合も141と同じ方式。
前にどこかで拾った式コピペしときま。外積使って頂点が左にあるか。を求めてるのかと。

828 2008/01/25(金) 18:20:24 ID:wCWKO3oH
名前は開発中のものです。(sage)

四角形ABCDと点Pの当たり判定
(Px-Ax)*(Py-By)-(Py-Ay)*(Px-Bx) > 0 and
(Px-Bx)*(Py-Cy)-(Py-By)*(Px-Cx) > 0 and
(Px-Cx)*(Py-Dy)-(Py-Cy)*(Px-Dx) > 0 and
(Px-Dx)*(Py-Ay)-(Py-Dy)*(Px-Ax) > 0
の時は当たり

149:名前は開発中のものです。
08/03/25 20:47:36 ZVswnUkG
>>146
ぶっちゃけSTGに可変長配列は要らないな
オブジェクトの配列を最初にまとめて確保して、存在フラグをメンバ変数に持たせる
派生クラスも作らないで、オブジェクトの種類はメンバ変数で管理

ぜんぜん美しくないけどな

150:名前は開発中のものです。
08/03/26 17:47:55 H5DuUJqf
オブジェクトのプールってどのように実装しているんでしょうか？

まとめて確保したオブジェクトのポインタをstackに積んでおいて
取り出したり使い終わったら戻したりみたいなやり方と
プールのlistと使用中のlistでやりとりするみたいなやり方
を思いついたんですけど・・・

もっとかっこいいやり方あるんでしょうか？

151:名前は開発中のものです。
08/03/26 18:31:19 kiBU8E/6
STLは使って無いんだけど、後者と同様の事をしてる。

任意サイズメモリを確保してそれをローカルヒープとして管理し、
そこからAlloc/Freeってのをやってたこともあったけど、可変サイズに対応可能だけど
メモリ管理ブロック分がもったいないとか、微々たるものだが処理コストが気になる、とか一長一短。
PCなら気にしなくてもいいかな？

152:名前は開発中のものです。
08/03/26 19:28:28 GuggIAK/
PCなら気にする必要は全く無しというのが俺の実験結果
ボス、弾、破片(パーティクル)に至るまで一個一個new(LocalAlloc)してdeleteして
24時間デモシーンをぶん回しても異常なしだったんだぜ

153:名前は開発中のものです。
08/03/26 20:34:31 59FgdjS6
物理演算とか相当煩雑な処理させない限り、
現在のPCの処理速度では最適化の意味がない、ってのは常々言われてるな
処理速度より、生産性とかソースの可読性とかを優先していいと思われ

154:150
08/03/26 22:29:36 BPyz/7I/
自分も今はそのままnewを使っているんですが
同じ動作をするなら少しでも軽いほうが精神衛生的に良いかなと。
処理もそんなに難しそうじゃないし。

まあ、一人でしこしこ作ってるので自分が納得できるようにやります。

155:名前は開発中のものです。
08/03/26 23:10:59 u3R/2Gep
それが一番だな。＞自分が納得

156:名前は開発中のものです。
08/03/26 23:18:09 pNomGL32
俺は配列で確保してる

157:名前は開発中のものです。
08/03/26 23:37:23 59FgdjS6
クラスのサイズがバラバラだから、使いまわし出来ないなぁ
最大サイズで確保するのはなんか癪だ

158:名前は開発中のものです。
08/03/27 00:08:07 sUf83WPb
しかし最大サイズで確保するのが最も現実的な罠
断片化を抑えるために色々小細工してるから遅い、という原因には効く

159:名前は開発中のものです。
08/03/27 01:08:19 V2zSEp+V
>>157
＞癪だ
富豪厨の俺に言わせれば
boost::simple_segregated_storageでガバッと確保して固定サイズでジャブジャブ融資
原資（メモリ）が足りない？そんなしみったれた貧弱PCユーザーは今すぐrejectだ！

160:名前は開発中のものです。
08/03/27 01:33:36 PgdiK5wh
アジャイル、ＵＭＬ，オブジェクト思考、階層化・・・
色々悩ませてくれたが・・・俺は最大の手段を使うことにした

それは・・・

goto文

161:名前は開発中のものです。
08/03/27 05:29:56 /WF5Ry8k
>>157
使いまわせるように作るんだよぅ

162:名前は開発中のものです。
08/03/27 09:52:59 4/N0HnfM
単純な直進弾や自機狙い弾と、
ホーミング弾や複雑なAIを持った敵機で、
必要なメンバ変数の数が違うんだよねぇ

163:名前は開発中のものです。
08/03/27 13:42:30 QODpit3Q
で？みたいな（笑）

164:名前は開発中のものです。
08/03/27 16:42:19 V2zSEp+V
>>162
3DSTGの敵機に編隊飛行、指令送受信、策敵、射撃、回避、離脱、体当たり
こんだけ積み込んでおおよそ64[Bytes/Instance]
ブースターだの脱出ポッドだのバリoートだのフライ○グアーマーだのといった
子インスタンスを加えても合計128[Bytes/Instance]を上回ることはなかった
誘導弾は64[Bytes/Instance]以下
直進弾は32[Bytes/Instance]以下

敵機200機の飽和攻撃により誘導弾800発と直進弾2000発
合計3000個のインスタンスが画面内を乱舞するとする

割り当て方法は全部同じプールでも別々のプールでも
インスタンス毎にnew(HeapAlloc)でも好きにしたまえだが
毎回HeapAllocだと管理領域分も考慮しなければいけないので
ここでは話を単純化するためプールとする

165:続き
08/03/27 16:42:55 V2zSEp+V
富豪厨は太っ腹なので全て128[Bytes/Instance]の固定サイズで
湯水のごとくアロケート

種類　　　ｻｲｽﾞ(使用ﾒﾓﾘ)　個数　ｻｲｽﾞ合計　使用ﾒﾓﾘ合計　無駄使い
----------------------------------------------------------
敵.　　　　　 128(128)　　　　200　　　25600　.　 25600　.　　　　　 0
誘導弾　　　　64(128)　　　　800　　　51200　　102400　.　　　 51200
直進弾　　　　32(128).　　　2000　　　64000　　256000　　　　192000
----------------------------------------------------------
合計　　　　　224(384)　　　3000　.　140800　　384000　　　　243200

敵、誘導弾、直進弾、別々のプールから割り当てる場合と比較すると
3倍弱のメモリを使用して約243KBを無駄にすることが分かる
これを「に、243KBも！（#@Д@）」とするか
「たったの243KBで騒ぐ貧乏人はrejectだな」とするかは
各人のエンゲル係数や可処分所得に左右される大変デリケートな問題
ここではあえて言及しないことにする

以上

166:名前は開発中のものです。
08/03/27 17:01:14 V2zSEp+V
×　約243KBを無駄にする
○　約237KBを無駄にする

167:名前は開発中のものです。
08/03/27 20:03:42 p+6nv0BF
>敵機200機の飽和攻撃により誘導弾800発と直進弾2000発
>合計3000個のインスタンスが画面内を乱舞

これは酷いな。生きのこれる気がしないぜ

168:名前は開発中のものです。
08/03/27 20:38:33 /7zHrXV5
一昨日PC2 6400 2GBx2を8000円で買ったんだが
243200バイトの損失なら
8000 * 243200 / (1024^3 * 4) = 4.53E-01
たった45銭3厘の損失かぁ

MSXの32KB拡張RAMカートリッジ、高かったなぁ（遠い目

169:名前は開発中のものです。
08/03/27 21:35:50 PgdiK5wh
もまいらいったいいくつから作ってるんだ？

170:名前は開発中のものです。
08/03/27 21:58:45 d3jrFqn7
パピコンでBASICゲーム作ってたのは中学んときだけど、
まがりなりにもシューティングらしきのを作ったのは高校ん時だったかなぁ。
やはりパピコンのBASICコンパイラ＋表示部分だけマシン語（ハンドアセンブル）で。

あの頃からほとんど成長してないのは正直どうかと……ｗ

171:名前は開発中のものです。
08/03/27 22:04:51 V2zSEp+V
>>169
もまいの故郷

goto文を恐れなく使う兵達のスレ
URLﾘﾝｸ(pc.2ch.net)

172:名前は開発中のものです。
08/03/27 22:07:22 DaOlp9/i
真の富豪厨は毎回new/deleteだろ。

173:名前は開発中のものです。
08/03/27 22:11:27 V2zSEp+V
やった(>>152=俺)が、余りにもアッサリとうまく動きやがったので
面白くないからrejectしてやった

174:名前は開発中のものです。
08/03/27 22:58:05 WDUR6Kc3
3Dで敵機64バイトって小さすぎない？
姿勢情報とかでどうしても容量デカくなりそうだけど

175:名前は開発中のものです。
08/03/27 23:44:06 XP2qgfZL
変位（座標）と回転の情報を4x4行列にぶち込んでればそりゃブクブク膨れ上がるだろうけど
回転にクォータニオンとか使ってれば2要素増えるだけだぜ？（圧縮すれば1要素増加で済む）
変位のほうは単純にz成分（1要素)が加わるだけ

結局、姿勢情報はfloat値6個（24バイト）もあれば十分表現できる
後は速度情報を加えて計48バイトとか

まぁ普通はそんな感じじゃね？

176:174
08/03/28 00:28:27 PZRPRNjR
＞変位（座標）と回転の情報を4x4行列にぶち込んでればそりゃブクブク膨れ上がるだろうけど

うっ、それまさに自分だ。。。
クォータニオンか。。。D3DXで提供されてるから素直に使ってみるか

レス㌧

177:名前は開発中のものです。
08/03/28 00:57:37 p3ibL9sX
そうかなぁ
4x4行列をジャブジャブ使ったほうがある意味で爽快かもよ

178:名前は開発中のものです。
08/03/28 01:12:03 0fJyqmGF
>>172
なんという俺

179:名前は開発中のものです。
08/03/28 01:12:06 PZRPRNjR
そ、そういう発想の転換もアリだよね、ね
PCならこの程度何の実害ないし
クォータニオンはまたその内検討してみまつ。。。

180:名前は開発中のものです。
08/03/28 01:13:36 PZRPRNjR
すまんこアンカー忘れ。>>177だた

181:名前は開発中のものです。
08/03/28 01:18:13 Pgm9Hf0W
>>177
おまいもうboostスレに帰れよｗ

182:名前は開発中のものです。
08/03/28 01:26:20 p3ibL9sX
どうもお邪魔しました！

＿＿＿＿___　　　　boostｽﾚの　　　　　STGｽﾚの
|←boostｽﾚ|　　　　中の人　　　　　　中の人
.￣.||￣￣￣　　　　　　 ┗(^o^ )┳(^o^ )┳(^o^ )┛≡＝-
　　||　　　　　　　　　　　　┏┗　　┗┗　　┏┗　≡＝-
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

183:名前は開発中のものです。
08/03/28 02:01:16 ZjS17OFO
絆スキップ

184:名前は開発中のものです。
08/03/28 14:37:29 SjpgUEnZ
>>175
＞ブクブク膨れ上がる

常日頃からメタボメタボ言われまくってる俺の
センシティブなハートをお前は深く傷つけたよ

185:名前は開発中のものです。
08/03/28 20:50:33 qlc6IPHd
メタボ臭とかいう新ジャンルのSTGを開拓すればいんじゃね

186:名前は開発中のものです。
08/03/28 21:15:38 /8lohFxt
それ何てミクロの決死圏
血管の中で中性脂肪の弾幕でもかわすのか？すげぇ既視感あるネタだけど

泡状のとかブニョブニョしたものを描くの面倒臭そうだな
昔のメガデモでよくみかけたMETABALLみたいな手法を使えばいけそうだな

オヤジギャグじゃないからな

187:名前は開発中のものです。
08/03/28 22:00:27 wFA3mk0n
ﾒｶﾞﾃﾞﾓ（笑）
ﾒﾀﾎﾞｰﾙ（笑）

オッサンばっか（笑）

188:名前は開発中のものです。
08/03/28 23:11:26 ikErMOXa
メガデモのメタボールの仕組みよく知らないんだが、あれって

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

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

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

グニャグニャ（連続体？）オブジェクトが出現するSTGとか作ってみたいし

189:名前は開発中のものです。
08/03/29 01:52:02 oF0Q5YC2
ム板のメガデモスレ池
マジレス

190:名前は開発中のものです。
08/03/29 02:49:58 4C1bZfLa
>>188
ソフトレンダもので初代Pentiumでぐりぐり(60FPS以上で)動いてたなら
スクリーン解像度は400*300とか320*240程度だったはず
濃度値を収める三次元格子もかなり荒かったんじゃないかなぁ

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

つか、今時のビデオカードで2DSTGでメタボールっぽいキャラ出すなら
パーピクセルで描ける
法線マップとアルファ付きカラーマップにぼやけた円を重ね描きしていって
アルファテストで閾値設定して描けば立体感（光沢付き）ぷよぷよだよ！
DirectXのSDKにもそんな感じのサンプルが入ってたはず

191:名前は開発中のものです。
08/03/29 10:50:00 p4/t7kS/
背景が黒いなら加算合成で出来ちゃうんだけどな。

192:名前は開発中のものです。
08/03/29 10:52:47 PdR5kqA3
メタボはメタボールの略だったのか。

193:名前は開発中のものです。
08/04/01 15:39:40 3rITgYf3
メタルボーク発進

194:名前は開発中のものです。
08/04/04 00:38:42 JN0z56Et
質問
CGってグラフィックボードで描いてるんだよね？
ハード的な理由で描画はマルチスレッドみたいになるの？
てことは、処理落ちの原因はほとんど当たり判定とかのせいになるの？
ということは、当たり判定をマルチスレッド分担すればいろいろ完璧？

195:名前は開発中のものです。
08/04/04 01:02:14 1TsuscT3
今時、当たり判定程度で処理落ちするCPUはない
プログラムにむちゃくちゃ無駄が多かったりしない限り

3Dならポリゴン数が多いと、GPUの性能次第で処理落ちするし、
物理演算があるとCPU性能次第で処理落ちするかな

196:名前は開発中のものです。
08/04/04 03:26:09 kdoRe4RJ
>>194
「てことは」の前後の文脈がどういう理屈で繋がるのか知らんが、2DSTGの話をしてるなら
今時どんなヘボノートPC環境であろうとも「当たり判定」で処理落ちさせるなんて至難の業だな
5年近く前のモバノート(1GHz前後のペンM…当然シングルコア)でシングルスレッドの総当りで
敵50匹と弾1500発の処理やらせて普通に60fps出るんだから、この時点で既に「いろいろ完璧」

197:名前は開発中のものです。
08/04/04 03:59:52 VspohKvQ
そのスペックで1500の総当りってどう考えてもきつい気がするんだけども・・・

198:名前は開発中のものです。
08/04/04 07:15:31 69exqbeK
ウチのご隠居チンコパッドX31が初代セントリーノの1.2GHzで
だいたい同世代みたいだけど、1500個くらいならイケてる

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

使うっつってもテクスチャをケチりまくるとか
頂点バッファとDrawPrimitiveの使い方を適切に、とか
その程度の話だけどね

199:名前は開発中のものです。
08/04/04 10:16:35 AI/AEUDG
総当り以外の当たり判定処理ってのが思いつきません。

ずっと昔に仮想マップみたいなのを用意しておいて
そこにキャラや弾の情報を書き込み、判定の際に使うってのを
何かで見た記憶があるけど、こういうのの事でしょうか。

200:名前は開発中のものです。
08/04/04 10:46:32 hPpN0s4/
空間分割ってのがありまして。

完全2Dなら当たり判定のある空間を縦横20くらいに分割して、
それぞれの空間に属するもの同士で判定を取ることで、
当たる見込みの無いものとの判定を事前に回避する。

201:名前は開発中のものです。
08/04/04 12:27:23 euXxyvh6
>>199
ｽﾚﾘﾝｸ(gamedev板:762-765番)n
↑の質問したのお前？
仮に別人だとしてもこの過疎板でこのタイミングで同じ質問が二度出るのは変だな
どっかのゲー専の宿題か何かか？正直に吐いたら褒美をくれてやるぞｗ

202:名前は開発中のものです。
08/04/04 13:27:02 AI/AEUDG
違います。
ゲー専の宿題でもないです。

今、自分で２Dゲーム作ってて、
キャラと弾、全部あわせると最高1600強を動かしてて、総当りでやってて問題なく遊べてる。
（もちろんあくまで「最高1600」であって、常にそれだけ動いてるわけではない）
「自機と敵弾」だけの判定じゃなくて、「敵と敵弾」とかの判定もやってるのに
ちゃんと遊べるから、最近のPCの処理速度はすげーなーとか思いつつも
やっぱもっと効率のいい判定方法ないかな、と考えてただけです。

203:名前は開発中のものです。
08/04/04 14:08:55 98Hdy+Q5
1600*1600の総当りは3年位前のスペックだときつくないかな？

204:名前は開発中のものです。
08/04/04 14:20:04 kACwEiIs
三年前、2005年のスペックというと
athlon64が全盛でathlon64x2が登場、Core2Duoがまだ、という辺り

有り得ないくらい余裕だな

205:名前は開発中のものです。
08/04/04 14:36:20 8r+omDm7
1600*1600だと最新マシンでも空間分割しないときついんじゃないか。
>>196は弾*キャラなんじゃない？

206:名前は開発中のものです。
08/04/04 16:24:58 XVBdGsRf
典型的な2DSTGで1600のオブジェクトを表示するったって大半が弾なんだけど
1600*1600という数字(組み合わせ)に一体何の意味があるのか>>203は説明できないだろ

207:名前は開発中のものです。
08/04/04 16:25:30 KKsDXKAb
URLﾘﾝｸ(ja.pastebin.ca)
やっつけだがpen3 1GHzのマシンで平均32ミリ秒
30fpsで間に合わないってところか

208:名前は開発中のものです。
08/04/04 17:04:15 KKsDXKAb
URLﾘﾝｸ(ja.pastebin.ca)
今度は32*32の敵64体と16*16の弾1600発のテストで、弾はヒットしたら壊れるという想定
同マシンで2～3ミリ秒
余裕すぎるな

ただのジコマンなのに連投してすまん

209:名前は開発中のものです。
08/04/04 17:25:12 0OItj9LK
総当りっていったら、普通は敵だの弾だの関係なく
{1600}C{2} = 1600*1599/2 の組み合わせになるんじゃないのか？
64*1600の組み合わせじゃあ桁が違う

210:名前は開発中のものです。
08/04/04 17:32:55 KKsDXKAb
>>209
それは>>207

>>208は単なるジコマンぽ

211:名前は開発中のものです。
08/04/04 19:04:55 g/x8ThIF
>>203は
”総当りの意味をちゃんと使ってくれ”
と、暗に言ってるだけだと思うんだが

212:名前は開発中のものです。
08/04/04 20:34:11 GfOfbOVS
オブジェクトを敵機・弾など種類ごとにリストにしておき、
あるリストの要素と別のリストの要素の当たり判定を行うことで、
無駄な判定はなくせると思うが

213:名前は開発中のものです。
08/04/04 20:42:54 9+TzVPLQ
俺もそれだ。

214:名前は開発中のものです。
08/04/04 21:04:37 qbhzPNp0
>>212
例えば自機が画面の左下にあるのに
右上に固まってる敵弾と判定と判定を行うのは無駄な判定だとは思わないか？

215:名前は開発中のものです。
08/04/04 21:06:02 qbhzPNp0
なんか変な文章に・・・

216:199=202
08/04/04 21:43:26 WdCHFh7R
なんか俺の書いた事について色々あったみたいで、申し訳ないです。

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

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

という事で>>201さんに納得していただいて、その褒美を貰おうと心待ちにしている次第です。

217:名前は開発中のものです。
08/04/04 22:03:57 GfOfbOVS
>>214
当たり判定範囲が矩形なら無駄な判定は生じない
むしろ、空間分割の方が無駄
5～10個の矩形の複合体とか円形とか多角形なら、空間分割にも利があるけど、
矩形のバウンディングボックスで一度判定すれば十分だろ

218:名前は開発中のものです。
08/04/04 23:32:07 qbhzPNp0
俺の日本語がダメなばっかりに変な誤解をさせてしまってるかもしれない・・・
それとも俺が誤解してるのかも？

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

悪い例えだけど（実際はツリーだったり）
敵弾を分割した空間ごとにリストにしておき、
自機のある空間とその空間のリストの当たり判定を行うことで、
無駄な判定はなくせると思うが

219:名前は開発中のものです。
08/04/04 23:32:34 KKsDXKAb
組み合わせが多いときは、分割は有効だけどね

220:名前は開発中のものです。
08/04/04 23:37:39 KKsDXKAb
グリッドハッシュ
URLﾘﾝｸ(lucille.atso-net.jp)

シューティングにここまで必要か？と問われたら
個人的には要らないと答えるが
知っておいて損は無いと思う

221:名前は開発中のものです。
08/04/04 23:50:38 98Hdy+Q5
昔は、IF文使うときに&&を使わず
入れ子にして速度を稼いだりしたなぁ

222:名前は開発中のものです。
08/04/04 23:53:49 qbhzPNp0
確かに1対多だったら労力のわりにたいした恩恵受けるもんでもないんだけども・・・

223:名前は開発中のものです。
08/04/05 00:13:39 ElJWYWg0
とりあえず、オマエラ「空間分割衝突」で１回ググれば幸せになれるんじゃね？

224:名前は開発中のものです。
08/04/05 00:23:10 xg5znUOR
>>221
わざわざ入れ子にしなくても
if( A() && B() )
これA()がfalseならB()は実行されないから
左のほうをfalseになりやすいものにすればいいと思うんだけど
昔のコンパイラは違うのかね

225:名前は開発中のものです。
08/04/05 00:27:12 ndMxol9I
>>209
敵弾とか敵機はお互い衝突しない
つまり敵属性同士は衝突しない
自機と自弾についても同じこと

敵(Enemy)と自(プレイヤー、味方、Friendly)。たった「2種」の敵味方属性
そしてオブジェクトに割り当てられる敵味方属性情報は静的。定数。const
プリプロセッサ、コンパイラにかける前から明らか。火を見るより
ゲームデザインの時点で既に決まってること
それなのに、判定…意味も無く…1600*1600回…あり得ない…愚行…常軌を逸する…愚鈍

226:名前は開発中のものです。
08/04/05 00:28:02 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:名前は開発中のものです。
08/04/05 00:38:24 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:名前は開発中のものです。
08/04/05 00:43:36 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:名前は開発中のものです。
08/04/05 00:47:03 KzcCKEO1
>>225-228
言いたい事は概ね同意だが下手なカイジネタは寒いからヤメレ

230:名前は開発中のものです。
08/04/05 00:51:05 ouV9zovg
自機と敵弾・敵機と自弾以外に衝突判定する必要無いだろ
1600×1600になるのは自機1600機と敵弾1600個みたいな時

231:名前は開発中のものです。
08/04/05 00:57:53 fK+4rNgg
弾同士が打ち消しあうときもな

232:名前は開発中のものです。
08/04/05 01:02:18 xg5znUOR
弾同士の当たり判定が無いなんて勝手に決め付けるなよ。
そういうSTG作りたいと思ってる人がいるかもしれないじゃないか。
というより5年前に俺が作った。
ビリヤード風弾幕ｗｗｗとかいいながら。
ひどい処理落ちで泣いた。

233:名前は開発中のものです。
08/04/05 01:03:00 KzcCKEO1
計算機アルゴリズムで使われる「総当たり」とか「総当たり法」ってのは
理論的にありうるor考え得る全ての組み合わせ全てを○○する、ことであって
この理論的にありうる、考え得るってのがキモ

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

敵同士、味方同士は「当たらない」というルールになってるなら端から除外しても
やはり総当たりだ

234:名前は開発中のものです。
08/04/05 01:04:20 ouV9zovg
弾同士が打ち消し合うときは(1599 + 1) / 2×1599じゃないか？

235:名前は開発中のものです。
08/04/05 01:37:44 ndMxol9I
>>229
ウッセー自分で書いて後で赤面してんだからそれ以上言うな

236:名前は開発中のものです。
08/04/05 15:10:07 yDdR+5eW
33MHzくらいのCPUでSTGを作ったときは空間分割にしないと重くて大変だった。
そういうプアなハードじゃないなら好きに作った方がいいかもね。

237:名前は開発中のものです。
08/04/05 15:19:58 q5ZpKtyT
自機の弾が1600発とか弾で画面が見えなくなりそうだなｗ

238:名前は開発中のものです。
08/04/05 18:40:45 9fddUrpP
>>224
私の記憶が確かならば、A()でとっとと打ち切られるのはCの仕様で保証されているはずだ。

239:名前は開発中のものです。
08/04/05 19:27:04 hxbbxTAw
O(n^2)の壁は厚すぎる

240:名前は開発中のものです。
08/04/06 01:22:08 +j0OgDSv
>>218
矩形同士の判定程度だと、
　　ツリー管理コスト＞＞＞衝突判定のコスト
だと思うのだが。これが3Dでコリジョンも複雑になってくると、
　　衝突判定コスト＞＞＞ツリー管理コスト
になるけど

241:名前は開発中のものです。
08/04/06 01:42:33 5ljxdwAA
>240 の頭の中にはどんな木が生えているのだろう？
木ってぐらいなんだから再帰なんだんろうけど、

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

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

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

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

最大なんて状態ばかりのゲームはそう滅多に作れない。
必要とあらば中心を移動する事もできちゃうしね。

242:名前は開発中のものです。
08/04/06 02:25:27 KzCv2Ahg
あれだ

弾幕ゲーが嫌いで、オブジェクト数がさほど多くない俺には不要＞空間分割

243:名前は開発中のものです。
08/04/06 08:33:57 lZPN8UOZ
空間分割して、空間内にあるかどうかの判定って矩形判定みたいな
もんだよね。差し引きして恩恵あるのかね？あと、空間の境界にいる
場合は隣接した空間も含めなきゃいけないし、その判定のコストも
加わるから、あんまり恩恵がない気がするんだけど。

244:名前は開発中のものです。
08/04/06 09:49:50 LNMxVQdl
現空間x-1 <= 判定対象空間x && 判定対象空間x <= 現空間x+1

245:名前は開発中のものです。
08/04/06 10:21:25 UvIpq6SI
すみません。
空間分割による判定、のメリットというものがどうもイメージできないのですが、
例えば、縦シューで自機と敵弾（256発）の当たり判定で、

for(int i=0; i<256; i++){
if((自機Ｙ座標-敵弾Ｙ座標)の絶対値＜当たりの深さ）{
if((自機Ｘ座標-敵弾Ｘ座標)の絶対値＜当たりの深さ）{
（当たっている処理）
}
}
}
という単純な座標比較による総当たりを行っている場合、
空間分割にする場合どのように変更して、またそれによりどのくらいの恩恵が
得られるのでしょうか？

246:名前は開発中のものです。
08/04/06 10:32:56 wmWZV0ag
>>243
＞空間分割して、空間内にあるかどうかの判定って矩形判定みたいなもんだよね。
それじゃ逆に判定回数増えるだろ。
例えば4分割だとしたらオブジェクトのポインタのリストを4つ準備して
オブジェクトを動かした後にでも空間別にリストに登録する。
判定したいオブジェクトの空間のリストのみ判定する。

空間の境界をまたぐ場合があるから実際はリストよりツリーを使うみたいだけど。
自機対敵弾みたいな1対多のような場合は>>240の可能性もあるが
しっかり最適化すれば恩恵はあると思う。

247:名前は開発中のものです。
08/04/06 10:51:59 ZtZMep9I
弾幕ゲーで弾同士の相殺でもない限り、
空間分割の恩恵は誤差範囲だと思うな
80-20の法則的にもっと別の部分の最適化に労力を使えばいい

248:名前は開発中のものです。
08/04/06 11:12:26 lDJhBuwb
空間分割なんて16ビット機でやってもいろんなオーバーヘッドで効果は微妙だった。
いくらか弾数が増えてるとはいえ、今のPCでみみっちいことしないでよろしい。富豪的に池
つーかまず衝突判定にそんなに時間かかってるのかプロファイリング取れ。

249:名前は開発中のものです。
08/04/06 14:07:39 IUsiyVu+
空間分割自体は当たり判定以外でも使える場合もあるかもしれないから
そういう方法があるとだけ覚えておけばいいんじゃない？

250:名前は開発中のものです。
08/04/06 19:03:41 lZPN8UOZ
＞＞２４６
難しくて分かりません。
他のレスを見て、合わせて、
必要ないということで納得しました。

251:名前は開発中のものです。
08/04/06 19:14:32 Cm7rU9iY
シューティングって、三角関数のテーブルは360度で足りる？

252:名前は開発中のものです。
08/04/06 19:38:45 ZtZMep9I
それくらい自分で判断しろ

253:名前は開発中のものです。
08/04/06 20:07:47 S2eA97Dz
どんなもん作りたいかによる
要するに自分で判断しろ

254:名前は開発中のものです。
08/04/06 20:51:46 HV30LXTn
普通に標準ライブラリ関数使いまくりでおｋ

255:名前は開発中のものです。
08/04/06 21:21:13 09KIF8si
むしろ度数法を久し振りに見た……。

256:名前は開発中のものです。
08/04/06 22:24:48 lDJhBuwb
だからテーブルとか考える前に普通に三角関数使ってみなよ。富豪的に。
たかがシューティングごときを作るのに、
あれこれレガシーな技をどこで覚えてくるんだいったいｗ

弾幕シューが技術的にすごかったのはX68000までよねーｷｬﾊﾊ

257:名前は開発中のものです。
08/04/06 22:37:18 +JZYHxk+
微妙に誉め言葉ｗ

258:名前は開発中のものです。
08/04/06 22:45:56 mi699AnH
俺もそうだったが、
初心者ってどうでもいい部分の最適化にこだわるよなｗ

259:名前は開発中のものです。
08/04/06 22:54:25 wmWZV0ag
アセンブラ勉強し始めたりとかなｗ

260:名前は開発中のものです。
08/04/06 22:55:52 tOJ8RPAp
>>256
たぶん超連射のことを言いたいんだと思うがあれは弾幕シューじゃない。
そもそも68全盛期に弾幕シューなんてジャンルは存在しない。
知ったか乙。

261:名前は開発中のものです。
08/04/06 23:00:07 S2eA97Dz
マジレスとな

262:名前は開発中のものです。
08/04/06 23:13:28 3n+Chkyh
爆裂矩形弾が泣いてます

263:名前は開発中のものです。
08/04/06 23:19:08 S2eA97Dz
敵弾の多さならメルトダウンも負けない
テキストだけどｗ

264:名前は開発中のものです。
08/04/06 23:29:06 ZtZMep9I
>>260

265:名前は開発中のものです。
08/04/06 23:33:09 +JZYHxk+
爆裂矩形弾懐かしいｗ
あれで弾幕シューは俺には不向きだと悟ったなぁ。

266:名前は開発中のものです。
08/04/07 00:09:38 RkL7uReo
針弾弾幕は、その場で計算して回転で大丈夫？

267:名前は開発中のものです。
08/04/07 00:29:10 SYSPe7mm
大丈夫も何も、針弾は角度とか回転情報を持ってなくね
針弾＝曳航弾。尾＝残像＝向きは速度(ベクトル)に平行
所有する変数は座標、速度、尾の長さ。せいぜいこんなもん
表示に際しても、太った線分＝OBBを一個作るだけであり
角度とか回転計算が出る幕はない

268:名前は開発中のものです。
08/04/07 00:40:04 UhDksLO+
その場で回転を計算の意図が今ひとつ掴めないが
俺は弾の情報として角度は持たせてる
前の座標や速度からその都度計算してると完全に停止する場合に困るからね
あとは途中で方向が変化しない弾なら発射時に角度を計算して放り込んで弾が消えるまで使いまわし
変化する場合は毎回計算

まぁ好みでやればいいと思うよ

269:名前は開発中のものです。
08/04/07 01:18:56 SZ+jR7s6
融通が効くと思う方法にしとけ。
速度で困ることは無いと思うし。

270:名前は開発中のものです。
08/04/07 06:57:49 +8OjOCNS
前に、三角関数使いまくったら流石に重かったなあ。

271:名前は開発中のものです。
08/04/07 07:39:55 Rur2+VQh
改めて自分のソース見てみたら360度のテーブル使ってた。
不都合無いのでこのままいくがｗ

272:名前は開発中のものです。
08/04/07 09:06:33 +8OjOCNS
>271
俺も見てみたら、unsigned charのオリジナル角度表記を使ってた。
意味あんのかな、これｗ

273:名前は開発中のものです。
08/04/07 18:27:25 jWrDXnrl
自分は１周＝256分割にしてますね。
360度だと、nWay弾とかの処理するとき、弾と弾の間の角度に端数がでませんか？

274:名前は開発中のものです。
08/04/07 18:35:56 Ln6527jm
2Dでもちょっとした誤差くらい気にならんよ
それに角度を度でやるなら360も約数多いから端数出にくいんじゃねえの

275:名前は開発中のものです。
08/04/07 19:08:11 jWrDXnrl
確かに誤差の範囲ですね。組み方次第でどうにでもなる問題かも。
自分の場合、多Way弾の弾と弾の幅を考えるときに、360度法でいうところの
90度からスタートして、半分、半分、半分、って幅を狭めていく考え方を
することが多かったから、１周が２のn乗のほうがやりやすかった、というだけの話。

276:名前は開発中のものです。
08/04/07 19:20:21 /whlgGmL
いまだに三角関数のテーブル使ってる人が俺以外にもいたなんて
俺は1024分割

当然座標も整数だよな

277:名前は開発中のものです。
08/04/07 22:10:13 nzfTFxMf
そうか！　座標を整数以外にするという手もあったのか！！

278:名前は開発中のものです。
08/04/08 00:03:17 UTGYbURq
整数つかうときって、何倍かして入れるんだろうけど
当たり判定とか表示のときは毎回戻すの？

279:名前は開発中のものです。
08/04/08 00:54:41 sOsom0Zc
何回ってどういう意味なんかよく判らんｗ

280:名前は開発中のものです。
08/04/08 00:57:21 NDn3kKP8
>>279

281:名前は開発中のものです。
08/04/08 01:08:48 RXIPGVdD
>>278
戻すって、整数部だけが欲しい場合か？
そんなん普通にビット演算子とかシフト演算使えば済むでしょ

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

それでも年寄りの悪趣味懐古趣味に付き合いたいなら別に止めはしない

282:名前は開発中のものです。
08/04/08 13:13:10 Wd7FQUJf
次に作るSTGにリプレイ機能を搭載しようと思っているのですが、
小数を使う場合、CPUによって小数点以下に誤差がある？という話を聞いたのですが、
例えば敵弾の座標に小数を使っていたら、リプレイを再生する環境によって
微妙に挙動がずれたりする可能性はないのでしょうか？
組み方次第で回避できるとは思うのですが。

283:名前は開発中のものです。
08/04/08 18:46:46 RXIPGVdD
＞小数を使う場合、CPUによって小数点以下に誤差がある？という話を聞いたのですが

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

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

FPUに不具合があって回収された10年以上前のペンティアムとかは例外
あとSSE関連はよく知らね

284:名前は開発中のものです。
08/04/08 19:22:22 RXIPGVdD
あと、数値計算法の基本をふまえて相応のコードを組んでいれば
異なるFPU間で生じる演算結果の極めて微少な差は問題にならないはず

FPUの演算結果にはたいてい不要な桁数の仮数が入ってるのだから
そういうゴミ情報入りの数値は適切なタイミングで有効桁に丸めること
不要な桁も何もかも後生大事に丸々保存して使いまわすのは
無意味な貧乏根性

285:名前は開発中のものです。
08/04/08 21:05:39 NDn3kKP8
D3DXが内部でSSEやら3DNow!を使ってそいつらで誤差が出ると2chで聞いたことがある。
試してないから知らんけど、リプレイで記録するデータはCPUで普通に計算すればOKじゃね。

286:名前は開発中のものです。
08/04/08 21:14:53 5+HU4lQf
>>285
URLﾘﾝｸ(www.01step.net)
これだな。
一応対策はできるらしいが。

287:名前は開発中のものです。
08/04/08 23:49:54 uw9YU9FV
NyaRuRu氏は同人ゲームのプログラマもやっていたのか・・・。

288:名前は開発中のものです。
08/04/09 03:34:01 B1YmjfJu
何やってる人なんだろうと思っていたが
不思議キッチンの人だったのか

289:名前は開発中のものです。
08/04/12 15:27:37 usi/yLYp
似たようなオブジェクトを同じクラスにするかどうか迷うなぁ
違う見た目（＝テクスチャの領域）で同じAI（＝updateメソッド）とか
AIのうち一部分だけ違う場合はifで分岐させるか、別クラスにするか

290:名前は開発中のものです。
08/04/12 16:01:22 ywj6p1Ij
好きにすりゃいいんじゃねーの。
そんな細かいことに定石も流行りもないだろうし。

291:名前は開発中のものです。
08/04/12 20:25:36 KRx1/teW
AI部分にStrategyパターンを適用して
付け替えできるようにするのもありだ。

292:名前は開発中のものです。
08/04/12 22:37:11 ObDRadP0
残機制にしたいんだけど、キャラの都合上死んだあとにもう一機出てくるのはおかしい
メカシューだから魔法みたいに復活するのも変
どうしよう…なんかいい例ある？

293:名前は開発中のものです。
08/04/12 22:51:37 Efa9OHIu
ばらばらに飛び散った破片が元通りに戻ってみたりするとか？

294:名前は開発中のものです。
08/04/12 22:56:53 Yh3eYIme
ゲーム内の設定によるだろうけど、例えば
「瞬間的にバリア張って高速自己修復出来るけど、
めちゃくちゃエネルギー消費するから回数制限がある」みたいな感じとか。

295:名前は開発中のものです。
08/04/12 22:58:31 /z0agk9x
夢オチ。

296:名前は開発中のものです。
08/04/12 23:00:31 GyPJI/ms
クロノトリガー式に未来からやってきた仲間がダミーと差し替え

297:名前は開発中のものです。
08/04/12 23:01:59 Efa9OHIu
思ったんだが普通に被弾したら、例えば片羽が落ちるとか
パーツがこぼれていく描写入れて暫く無敵時間を入れて
残機減らしてもそれはそれで良いんじゃないかな

298:名前は開発中のものです。
08/04/12 23:16:03 ZyjFSU8/
ナイトストライカーのようにシールド張ってる設定にすれば
被弾エフェクトはシールドの色が変わるとかSEとかで知らせる

299:名前は開発中のものです。
08/04/12 23:30:26 Yh3eYIme
夢オチﾜﾛｽｗ

300:名前は開発中のものです。
08/04/13 00:07:42 VNOh5k7z
>292
爆発したら首だけすっとんで、新しいからだが飛んできて合体する逆アンパンマン方式。

301:名前は開発中のものです。
08/04/13 00:14:37 gNZFNySx
博士が来て修理するファミコンのアトム方式とか

302:名前は開発中のものです。
08/04/13 00:39:19 Z1kaHYoi
ツインビーｗｗｗ

303:名前は開発中のものです。
08/04/13 01:39:10 NkPkjT6X
バリア張ってる設定にしたら？
残機＝バリアの残りエネルギー
被弾するためにバリアのエネルギーを消費する

次ページ