[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 2chのread.cgiへ]
Update time : 05/09 23:55 / Filesize : 123 KB / Number-of Response : 519
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

ゲームプログラムなら俺に聞け



1 名前:デフォルトの名無しさん [2009/01/02(金) 19:01:16 ]
エロゲしか作ったことないけど
なんでも聞いてちょ

175 名前:デフォルトの名無しさん mailto:sage [2009/05/11(月) 22:44:42 ]
で複雑にしてデバッグ不可能になると

176 名前:デフォルトの名無しさん mailto:sage [2009/05/12(火) 12:15:33 ]
お前じゃ無理かもナw

177 名前:デフォルトの名無しさん mailto:sage [2009/05/12(火) 12:21:24 ]
お決まりのやりとりが始まったな。
早くこっち↓に移動してくれ。
pc11.2ch.net/test/read.cgi/gamedev/1241670786/

178 名前:デフォルトの名無しさん [2009/05/12(火) 18:09:38 ]
ロスブラみたいに広大なマップ走り回るのって、マッブポリゴンの管理どうやってんの?
あのポリゴン数だったら一気に読み込むのも描画するのもきついだろ。
キャラと同じで遠方はローポリかな。

179 名前:デフォルトの名無しさん mailto:sage [2009/05/12(火) 22:54:08 ]
ロスブラって何よ

180 名前:デフォルトの名無しさん mailto:sage [2009/05/13(水) 03:03:47 ]
どうやんのも何もないだろw

181 名前:デフォルトの名無しさん mailto:sage [2009/05/13(水) 03:19:02 ]
>>178
LOD とキャッシュだよ。

182 名前:デフォルトの名無しさん mailto:sage [2009/05/13(水) 03:30:51 ]
キャッシュ?

183 名前:デフォルトの名無しさん mailto:sage [2009/05/13(水) 09:33:43 ]
あれだけハイスペックなPC要求するんだから特に小細工ないんじゃないの



184 名前:デフォルトの名無しさん [2009/05/13(水) 11:28:44 ]
なんだよ小細工って

185 名前:デフォルトの名無しさん mailto:sage [2009/05/13(水) 12:53:26 ]
動的LODじゃなくてミップマップみたいに事前に用意しておくタイプだよね?

186 名前:デフォルトの名無しさん mailto:sage [2009/05/13(水) 22:56:42 ]
おまえらレスに重みなさっすぎw

187 名前:デフォルトの名無しさん mailto:sage [2009/05/14(木) 19:19:33 ]
洋ゲーでそのへんのインタビューがあったハズだが、 spin てもう無くなったのか。

188 名前:デフォルトの名無しさん mailto:sage [2009/05/15(金) 18:36:01 ]
>>178
遠方ローポリってことはあのマップが分割されまくってるってこと?

189 名前:デフォルトの名無しさん mailto:sage [2009/05/15(金) 19:40:22 ]
おまえはここになにしにきてんの?

190 名前:デフォルトの名無しさん mailto:sage [2009/05/17(日) 16:13:39 ]
唐突だが、何歳まで現役プログラマーで仕事できると思う?
海外なんかはけっこういい年までというか生涯現役みたいなプログラマーが多いが、日本では少なくとも他業種で40ぐらいのプログラマーは割りと少ないように見える。
ゲーム業界の仕事スタイルは比較的欧米に近いスタイルだと思うのだが、実際何歳ぐらいまで現役としてやってるのかなー?
知ってる範囲では40ぐらいまでしかいないんだが。
・・・というか、会社そのものにそれ以上の年齢の人がいないので、正直わからんのがホンネ

191 名前:デフォルトの名無しさん [2009/05/17(日) 16:22:19 ]
大きい企業は管理職にされちゃうからいないだけ。
中小にはそれなりに50近いひととか普通にいますよ。

192 名前:デフォルトの名無しさん mailto:sage [2009/05/17(日) 16:38:16 ]
現場で若手に抜かれたら基本終わり。
特殊技能を持ってるか年下の指示でも仕事として一定品質出せれば残留の可能性はあり。
俺は下が育ってないから強制現役w

193 名前:デフォルトの名無しさん mailto:sage [2009/05/17(日) 16:44:13 ]
管理職飽きたー
会社作って現場に出たいわ・・・



194 名前:デフォルトの名無しさん mailto:sage [2009/05/17(日) 19:51:31 ]
>>190
25名くらいのゲームではない中小だが、
俺の右隣りの席のお方は、60近いな。
386BSDの頃に鳴らしたという。
今の上長も現役で、掛け持ちで3つのプロジェクトの
リーダやってる50過ぎの人だね。

さて、うちの会社は定年あったんだろうか?
両者とも役員兼任のためよくわかんねw

195 名前:デフォルトの名無しさん mailto:sage [2009/05/17(日) 20:20:59 ]
特別に役員の定年制を決めないと。
普通の定年制は役員には当てはまらない。

196 名前:デフォルトの名無しさん mailto:sage [2009/05/17(日) 20:53:45 ]
>>195
そうなんだよね。
50代以上は、4人くらいいるかな
役員じゃない人は一人いたような。

197 名前:デフォルトの名無しさん mailto:sage [2009/05/18(月) 09:23:47 ]
ゲームプログラマの人に聞きたい 35問目
pc11.2ch.net/test/read.cgi/prog/1239984551/l50

マの話はマの板で。

198 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 07:46:08 ]
シューティングゲームの処理速度アップのための
計算の簡素化とかはここで聞いてOKですかね?

199 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 09:55:57 ]
テーブル参照にしても変わらんぞ
精度が落ちるだけでほとんど意味無い
素直に三角関数使え

200 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 10:42:48 ]
まあまず手を入れる前にプロファイルとるところからだな。

201 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 11:10:59 ]
atan系関数を使わず、自機と敵の角度を求める方向はありますでしょうか?

202 名前:201 mailto:sage [2009/05/22(金) 11:12:02 ]
方向じゃなく方法でした。

203 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 11:41:00 ]
あるよ、荒ければatanより早い場合があるけど、
細かく調べると断然遅い。

昔のアクションゲーム(10年以上前)はatanは使わずにやってたよ。



204 名前:201 mailto:sage [2009/05/22(金) 11:52:37 ]
>>203
そうなんですか。
軌道変更に関しては別方法があるのは知ってるんですが
問題は画像の回転処理のためにどうしても角度が必要でして・・・

205 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 12:17:26 ]
なんでatanじゃ駄目なんだ?

206 名前:201 mailto:sage [2009/05/22(金) 12:29:26 ]
>>205
駄目というわけではないんですが、別の方法で軽くできるならと思いまして

低速移動の弾幕系のゲームなので結構切り詰めないと厳しいんですよね

207 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 12:39:38 ]
なんですぐバレるような嘘つくかなぁ。
これでも使ってろよ。

int GetDir(int srcx, int srcy, int dstx, int dsty) {
  int absx = abs(dstx - srcx);
  int absy = abs(dsty - srcy);
  return (dstx == srcx) ?
    (dsty > srcy) ? 0 : 180
    : (dsty == srcy) ?
      (dstx > srcx) ? 90 : 270
      : (dstx > srcx) ?
          (dsty > srcy) ? 90 * absx / (absx + absy) : 180 - (90 * absx / (absx + absy))
        : (dsty > srcy) ? 360 - (90 * absx / (absx + absy)) : k = (90 * absx / (absx + absy)) + 180;
}

208 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 12:42:06 ]
一箇所誤りがあったので訂正

int GetDir(int srcx, int srcy, int dstx, int dsty) {
  int absx = abs(dstx - srcx);
  int absy = abs(dsty - srcy);
  return (dstx == srcx) ?
    (dsty > srcy) ? 0 : 180
    : (dsty == srcy) ?
      (dstx > srcx) ? 90 : 270
      : (dstx > srcx) ?
          (dsty > srcy) ? 90 * absx / (absx + absy) : 180 - (90 * absx / (absx + absy))
        : (dsty > srcy) ? 360 - (90 * absx / (absx + absy)) : (90 * absx / (absx + absy)) + 180;
}

209 名前:201 mailto:sage [2009/05/22(金) 12:44:23 ]
>>207
嘘はついてないですってw

某ゲーム機の自作アプリなんでハードウェアの性能の上限が決まってるので
あれこれ工夫しないと厳しいんです。

210 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 12:44:24 ]
コスト高そうだな

211 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 12:49:33 ]
>>209
PSPはnewlibのatan2で問題ない
DSならテーブル参照版ATAN2を作れ

212 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 12:51:33 ]
改善する意味があるほど atan が遅いということは、計測して確かめたの?
言語は何?
毎フレームじゃなく、生成時と、その後4フレームおきとかにすると計算量が 1/4 になるかもよ。
方角が右回りか左回りかで十分なら(九十度回転させて)内積が使えるかもね。

ゲーム機なら精度はx/1000程度で十分だから自前でテイラー展開するとよい。

回転機能にラジアンを渡すなら atan だが、行列を渡すなら正規化するだけで sin, cos が出るのでこちらを使う。


つーか情報小出しにしすぎだろ。

213 名前:201 mailto:sage [2009/05/22(金) 12:52:12 ]
>>211
なるほど

じゃあ後はホーミング弾の画像を回転処理しなくても辻褄があう
単なる○とかにするしかないんですねえ。
そうすれば画像を回転させるためのatanなくなりますんで



214 名前:201 mailto:sage [2009/05/22(金) 12:54:41 ]
>>212
>毎フレームじゃなく、生成時と、その後4フレームおきとかにすると計算量が 1/4 になるかもよ。
これはすでにやってます。
60fpsなんで演出上もなんとかごまかせる範囲でホーミングしてくれてます。

>回転機能にラジアンを渡すなら atan だが、
この辺は土台として某所で最近使われだしたDXライブラリのPSP版を使ってるので
どうしてもラジアンである必要があるんですよね。

ライブラリ上で動くのでチューニングしにくいのもあるんですけどね。

215 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 12:59:57 ]
>>210
いまどき携帯ゲーム機ですらプリフェッチを備えているのに分岐しまくりだしねぇ
もしDSだったら、除算命令が無いので更にコスト増

216 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 13:00:51 ]
>>213
atan2で問題ないっつってんのになんでそうなるんだよ
テーブルの作り方知らないの?

217 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 13:03:12 ]
また東方厨かよ・・・

218 名前:201 mailto:sage [2009/05/22(金) 13:05:38 ]
>>216
atan2で問題ないということは現状以上の速度アップはできないということになるので
改善するには画像の回転という演出をやめるしかないという結論なんですが・・・

219 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 13:11:01 ]
つまりどこにボトルネックがあるのか
本当のところはわかってないと

220 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 13:12:37 ]
PSPのようなクロスで開発する場合プロファイリングできるんだっけ?

221 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 13:50:15 ]
非公式環境でも普通にpsp-gprof提供されてるし。当然できる。

222 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 14:54:00 ]
schiphol.2ch.net/test/read.cgi/gameurawaza/1240309452/874
>874 :シューティング大好き ◆hvhkrhIMnI :2009/05/22(金) 06:19:31 ID:w31tRwU1
>>>862
>ボトルネックなのは弾幕の演出上必要となる計算処理とかですかねえ。
>今はごまかしてますが、ホーミングの軌道修正計算も負担だったりします。

なるほど…

223 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 15:00:21 ]
まあ、ソースをみる限り
atan2はcosやその他超越関数より
はるかに軽そうだがな。
これをボトルネックとみるのは
どうかな。



224 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 15:04:43 ]
ライブラリ側のソースも見てるが回転機能が付いてる描画関数は
sinとcos使ってるからどうしても処理を軽くできないなら回転をやめるのは
ある意味正解かもしれん。

225 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 15:08:52 ]
まぁそれでも、あらかじめ回転した画像を用意するだけの話ではあるがな

226 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 15:19:27 ]
今時それは非効率すぎないか?


227 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 15:24:54 ]
効率的に目的を達成する方法があるなら提示してあげればいい

228 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 15:40:39 ]
>>227
重たいロジックを入れない->回転やめる

229 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 15:41:58 ]
まぁそれも、あらかじめ回転した画像を用意するだけの話ではあるがな

230 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 15:44:43 ]
分岐のコストが低いプロセッサならCORDICどうかな?
やってみたことないからうまくいくかわからんけど。

231 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 15:46:50 ]
画像を用意する場合はどのくらいの分解能
引っ張ってくる画像を判断するための処理ロジックのコスト
無駄が多いな

232 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 15:50:35 ]
    | ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
    | スンマセン、直ぐに連れて帰ります
    |__  ________
      __∨______.__.__
    , '"――――‐, '"―‐ ヽ`l:1
   ./ ∧_∧   //'~ ̄ ̄|.||::| |    ∧_∧ アヒャ
   .i (´Д`;.)  i !  _,._|.||::| |   ( ゚∀。 ) ←>>201
 [;].!_っ⌒'と _0[;],l |  f _..┘|| | :|__( つ  つ___n____n
  ~l!=;:,...二二....,:;=iヨ.'ー''"~ . __ !|:| :|lー‐―i iー‐―i iー‐―i iー‐―l i|
  li..,._.  ̄。 ̄. _.,..!.|   ........~ノ,!;|__|l__!_!__!_!__!_!__l__!|
  il_`}≡≡{´_E|..::' /⌒ヽ'ヽl|!=イ二ll二二ll二/_/ ⌒ヽヽ(ニ(]
.  {=i:::::::[二]:::::::i=i::」  |i.(*).i;;;;|ii□□::(ニ三ニ)::::|;;;;;;|ii.(*) i;;;|
   ̄ ̄ゞ三ノ  ̄ ̄ ̄ゞ_ノ ̄  ゞゞ三ノ    ̄ゞゞ_ノ~    ≡3

233 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 15:56:33 ]
駄々こねても困るのは東方厨だから別にかまわんけどね



234 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 15:57:48 ]
一応プログラミングの話題で議論してるのに
関係ないスレにまで出張してくるアンチはしねばいいのに

235 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 16:01:20 ]
>>234
で、流石にもうプロファイルはとったよな?
どこにボトルネックがあったんだ?
まだとってないならpspDebugProfilerEnableという手もあるぞ

236 名前:デフォルトの名無しさん [2009/05/22(金) 16:38:32 ]
タイヤが回ると車って前進するじゃないですか
この仕組みがよくわかりません。
タイヤの回る力が並進する力に変わるプロセスってどうなりますか?

タイヤと路面のすべりは0だとすると、
1、タイヤにトルクを加える。
2、タイヤに角加速度が発生。
3、タイヤと路面の接触点(面)に加速度が発生。
4、??? <-このプロセスがわからない
5、タイヤの重心に加速度が発生。
6、タイヤは回転しながら並進する。


237 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 17:06:49 ]
>>236
接してる面だけしかない場合は軸を円周方向の角速度の逆に蹴ってる。
単なる棒で接してるなら軸は真っ直ぐ前ではなく倒れてしまうけど
タイヤという円形なので連続して蹴るために軸は同じ高さを保ったまま
ベクトルとしては水平方向に進む?


238 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 19:48:01 ]
>>237
その棒の例えは、感覚的にはわかるのですが
原理的にあまりよくわかりません。
これがわかれば、球の前進も理解できそうな気が
するんですが。

すべり0の路面とは、接触した点はX-Yのどの方向にも
動かすことは出来ないということ。つまり速度=加速度=0の拘束を受ける。
タイヤが角加速度を発生すると、接触点に加速度が発生するはずであるが
さきの拘束がある為、加速度=0になる。その帳尻合わせる為?代わりに
接触点以外の質点の加速度をマイナスする。。のかな、ん〜よくわからない。

239 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 21:19:16 ]
なんか中学生の疑問ぽいな

壁に向かって力を押せば、反対側に進む
作用・反作用の法則だ
タイヤの場合もそんな感じ

240 名前:212 mailto:sage [2009/05/22(金) 21:47:48 ]
>>201
DXLibralyPortable 見てみた。
DrawRotaGraph() の類を使っているのだな?
リストの線形探索というとても効率の悪い GraphHandle2Ptr() を、
一枚描画するたびに何度も呼ぶことになっているが、同じ画像を
使う描画をまとめることで、実は一度だけでよいようにできる。
当然、SetTexture() も一度でよくなる。

また、sceGuGetMemory() を毎回呼び出しているが、事前に枚数が
分かっているのなら、これも一度でよい。
ついでにいうと、GuListSafety() はうんこだ。
sceGuGetMemory() の直前に必要量が足りるかを判定して、足り
ない場合に不ラッシュするようにすべきだ。
さらにいうと、この処理を見れば分かるように、パケットエリアが
足りなくなると sceGuSync() を呼ぶことになるが、これは処理速度
の観点から好ましくないので、sceGuGetMemory() 直前に、パケット
エリアが足りなければ assert() するようにした方が良いかも知れない。
メモリ効率が重要ならリングバッファに。

double は論外。
どうしても必要な場合だけにしなさい。
float <-> double の変換だけでかなりの時間を使う。

まず間違いなく、atan は無罪だ。
DrawRotaGraph() を引数を含めて最適化したほうがずっと効果が
高いだろうと思われる。

あとお前、212 のテイラー展開とか正規化で sin, cos とか無視しやがったな。
進行方向修正だけなら(九十度回転)内積だけで済むとかも。

241 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 22:01:50 ]
DXlibってド素人向けゴミクズライブラリの分際でPSP用とかあるのか

242 名前:デフォルトの名無しさん mailto:sage [2009/05/22(金) 22:04:21 ]
ゴミ以下な>>241より人気あるしな

243 名前:デフォルトの名無しさん [2009/05/22(金) 22:19:22 ]
開発者 「スレで開発すればプログラムの勉強になるし名声とかも得て一石二鳥♪」

実際   PSP独自の関数とか絶対他で使んねぇのに開発とか超受けるんですけどww
      2ちゃんで開発とかwwずっと乞食共に食われてろよw
      自身のブログで公開してアフェリエイトでも期待してた方がまだマシだなw
      名声?まあ、そのくらい分かるよなw
      そもそも完成しないのに開発って矛盾しすぎww
      っていうかなんでパスつけてんの?優しい優しい開発者が乞食のために公開してんじゃなかったの?
      いいよ、俺が教えてやるよPASSは601だwww
      一生このスレで乞食の相手やMの奴隷でもやって、くたばっちまいなぁwww

乞食   「やべwwPSPで東方ができるwwダウンロードっと」

実際   「はぁ?こんなの東方でもなんでもねぇよ、くそつまんねぇ〜
      でも、そのうち本物と同じくらいの出来が来るかもしれないから毎日来るか」
      こんなスレにずっといると精神腐っちゃうぞ☆
      将来のためにお勉強した方がよっぽどいいよ、マジで



244 名前:憂煉 ◆yreeen/0R2 mailto:sage [2009/05/22(金) 23:28:51 ]
>>240
わざわざ私のソースコード呼んでくれてありがとうございます。

次のバージョンあたりで線形探索とかsceGuGetMemoryとかの最適化も含めようと思います。
バッファ足りなくなった時点でassertですか・・・それもありですね。双方に利点欠点があるので適宜切り替えられるようにしようかなと思います。
リングバッファはPSPSDKの設計上難しそうです。
引数にdoubleが存在するのは本家ライブラリに合わせているのが原因です。これもプリプロセッサか何かで対応しようかと思います。

的確な指摘本当にありがたいです^^

245 名前:憂煉 ◆yreeen/0R2 mailto:sage [2009/05/23(土) 00:06:26 ]
>>240追記
進行方向修正で左右を判別するなら90度回転して内積つかうよりも直接外積使った方がいいですよ。
正確には2Dでは外積そのものは定義できないので「外積の大きさ」を使うことになりますが。
atanは無罪ですね。でもatanよりatan2使った方が良くないですか?
atanだと第一象限と第四象限の角度しか返さないので補正に一手間必要ですが、atan2だと全象限カバーできますし。
そのあたり実際にベンチマークが必要ですね・・・


246 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 00:24:04 ]
なんか伸びてると思ったら最近あちこちで利用されてる龍神録関係か

数学はあまり詳しくないんだが確か龍神録のホーミングは360度
軌道修正できる感じだったので内積とか外積は関係ないんじゃないか?

247 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 01:39:05 ]
>>245
わかってるなら初心者に東方もどきを作らせずに自分で作れば良いと思うのだが

248 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 01:57:21 ]
>>247
私は実際のプログラムよりライブラリを作る方が性に合ってるのでw
実のところ纏まった時間も無いですし、ゲームの開発はしばらく人任せにしようかと思ってます。

249 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 13:56:00 ]
あばばばば

250 名前:212 mailto:sage [2009/05/23(土) 14:23:21 ]
>>244
assert の話は利用側への話。

psp sdk を軽く見てみたけど、リングバッファにもできそうだ。
デメリットもあるからメモリ効率を追求するのでなければ不要だが。

GPU の処理負荷はどうだ?
GPU が原因で処理落ちするようなら、パケットエリアのダブルバッファを検討
すべきだ。
今の構成では、多分 GPU が遊んでる時間が結構あるし、フレームの最後の方で
大きなプリミティブを描画すると処理落ちの危険が不必要に高まると思う。

double を使うと本当に重い。
-S オプションでアセンブリリストを出力させ、double 変換関数が呼ばれて
いないか調べなさい。
変換関数の名前は覚えてないから、テストプログラム作ってリスティングして
調べてくれ。
sprintf() などの可変引数に渡すときや、float から long への代入時に暗黙
の格上げがあったりするので注意。

>>245
カチンときて何か言わずに済まなくなったのか。

atan の話で、テイラー展開の話を理解していないことがわかる。
自前の atan を実装しろという話なのだから、標準ライブラリの atan() を使え
と言っているわけがない。
標準ライブラリの atan() は double なのだから、double を論外とする人がそれ
を使えというわけがない。

実際に標準ライブラリの atan()/atan2() を使っていたのなら、すぐに atanf()
か atan2f() に直すべし。

251 名前:212 mailto:sage [2009/05/23(土) 14:24:17 ]
>>245
> (略)直接外積使った方がいいですよ。
君は自分がなにをしなければならないかを知っているが、俺の言ったことは
理解していない。

ベクトル (x, y) を九十度回転させて (x', y') にする操作は、
(x', y') <- (-y, x) である。
一般の回転は (x*cos - y*sin, y*cos + x*sin) であるが、今回は九十度
なので cos(90) == 0, sin(90) == 1 であり、結果 (-y, x) となる。
ではこれを使って、九十度回転したベクトルとの内積をとってみよう。
ベクトル A と B の内積を Ax * Bx + Ay * By とすると、九十度回転した
A(-Ay, Ax) との内積は Ax * By - Ay * Bx となる。
おや、何か外積と似てるね。

さて君は外積の大きさを使うと言ったが、具体的にはどのようなことだろうか。
(Ax, Ay, 0) と (Bx, By, 0) のベクトルの外積をとって、出てきたベクトル
の各成分の二乗和の平方根と解釈して良いだろうか。
このとき、当たり前だが、外積の結果は、x 成分と y 成分がゼロである。
元の二つのベクトルの z 成分がゼロであるから、これは当然である。
であれば、最初から z 成分だけ計算すればよいのであり、だとしたら、その
計算を外積だと主張するのは、間違いではないがピントが外れていると言えない
だろうか。
それに、ベクトルの大きさならば負の値をとらないから、その点でも説明不足
な表現といえるだろう。

252 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 14:26:36 ]
245 は分かっているだろうが、ライブラリを使う側の話なので、折角だから進行
方向の更新処理についても説明する。

弾の位置から自機の位置を引いたベクトルを A、ホーミング弾のフレームあたり
の移動量(進行方向)のベクトルを B としたとき、B と九十度回転した A との
内積の値は |A||B|sin となる。
ここで角度を得るためには |A||B| で割ればよいのだが、平方根と除算が必要に
なる。
平方根自体は psp ならば浮動小数点ユニットに実装されているはずだから、
目くじら立てるほど遅いということは無い。
しかし平方根や除算を消せるならそれに越したことはない。

ホーミングの進行方向修正を考えた場合、必要なのは、右に回転すべきか
左に回転すべきか、それとも正対すべきか(向きの差が回転性能未満の場合)
ということを判断するのに十分な情報だけである。

右か左かというのは、sin の符号でわかるので、回転性能未満かどうかの判定
について説明する。

ベクトル A 同士の内積、つまり Ax * Ax + Ay * Ay の結果は、|A| * |A|
である。二乗和であるから当たり前だが。
件の内積の結果であるところの |A||B|sin を二乗すると、
|A| * |A| * |B| * |B| * sin * sin となる。

これを A の二乗和と B の二乗和で割ると sin * sin が出るのだが、今回は
比較に使うだけなので割る必要はない。

a > 0 かつ x > y のとき、 ax > ay という法則があるので、これを利用する。
a を |A| * |A| * |B| * |B| とするわけだ。

また |x| > |y| の時、x * x > y * y を利用して、回転限界の sin の二乗
と、A と B のなす角の sin の二乗との比較を行う。

253 名前:212 mailto:sage [2009/05/23(土) 14:27:27 ]
回転限界を r 、その sin を sr、さらにその二乗を sr2 とすると、

outerp = Ax * By - Ay * Bx; // |A| * |B| * sin
outerp2 = outerp * outerp; // |A| * |A| * |B| * |B| * sin * sin
alen2 = Ax * Ax + Ay * Ay; // |A| * |A|
blen2 = Bx * Bx + By * By; // |B| * |B|
limit2 = alen2 * blen2 * sr2; // |A| * |A| * |B| * |B| * sin(r) * sin(r)
if ( fabsf(outerp2) < limit2 ) /* 回転限界未満 */;
else if ( outerp < 0 ) /*右回転*/;
else /*左回転*/

というようにして、除算も平方根も無いばかりかコンパイラがスケジュール
しやすそうなコードが出来上がる。
前述の法則から、fabsf(outerp2) < limit2 は結局 sin*sin < sin(r)*sin(r)
と同じ結果になることが理解できるだろう。

回転限界未満では atan などを使うことになるが、テイラー展開で自前で実装
したバージョンを利用するなら、asin の方が収束しやすいので、平方根で割って
でも asin を使った方がいいかもしれない。
これは実測しないとどちらが有利かはわからない。



254 名前:212 mailto:sage [2009/05/23(土) 14:28:30 ]
余談だが、最適化のヒントになるので追記する。
ベクトル B は、ホーミング弾の進行方向のラジアンから sin cos で算出する。
角度から sin cos に直すのは DrawRotaGraph() でも行う必要がある。
そこで元々ホーミング弾の進行方向を sin cos で保持しておけば、その処理が
不要になる。

上記 aim 処理(aim は照準することで、日本のゲーム文化の中ではホーミング
のことと思ってよい)も、回転限界未満の時は A * (1/|A|) を採用することで、
限界外の時は(事前に計算しておける)sin(r) cos(r) を用いて進行方向
ベクトルを回転させることで、進行方向の角度(ラジアンなどの表現)無しで
実現できる。
さらに DrawRotaGraph() のバリエーションに sin cos を渡すバージョンを追加
したら、移動方向は sin cos の表現だけで全く十分となる。

もうひとつ、移動方向の sin cos を持っていれば、それは長さ 1 なので、
outerp は |A| * sin、outerp2 は |A|*|A| * sin*sin となり、limit2 は
alen2 * sr2 となる。blen2 は 1 のハズだから計算不要なのだ。よって、aim
処理自体の(微々たる)高速化も果たせる。
このように、三角関数なしでベクトルのまま処理することができる。
平方根での除算が必要だが、r4000 なら rsqrt という命令があって 1 / |A| を
一命令で行うことができる。

255 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 14:42:54 ]
psp-gprofのことを書いたのは失敗だったかな。
あの流れで書くのは自然なことのように思えたが
結果として木を見て森を見ずになっちまった。

256 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 14:48:12 ]
>>250
GPU の処理負荷はどうだ?
GPU が原因で処理落ちするようなら、パケットエリアのダブルバッファを検討
すべきだ。
今の構成では、多分 GPU が遊んでる時間が結構あるし、フレームの最後の方で
大きなプリミティブを描画すると処理落ちの危険が不必要に高まると思う。

この辺のコツとか関連関数を教えていただけませんか?
前からCPUで仕事しきった後Guに仕事を渡すというのでは効率悪いんだろうなあと
思ってたんですがGuの非同期制御のコツがいまいちわからなかったので
実現できていないんですよね。

257 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 14:53:11 ]
>>255
いえあれはあれで有効ですよ。

今まではライブラリの上で動くプログラムの効率が悪いのではないかという
盲目的な考えでチューニングしてましたが、ライブラリ側の問題も見えてきたので
今後は本家の関数に忠実にというだけでなくPSP独自の関数の実装を
検討しやすくなりましたし。

258 名前:245 mailto:sage [2009/05/23(土) 15:46:05 ]
>>250
>カチンときて何か言わずに済まなくなったのか。
なぜそう喧嘩腰なのか理解に苦しみますが・・・

>自前の atan を実装しろという話
sinf、cosfは既にハードウェアで実装されている関数の方が自前で組んだ物より高速だったので、私はそっち使ってます。
atan系はライブラリ側では使ってないですね。

>>251
3次元ベクトルの外積の大きさの計算を2次元ベクトル向けに妥当な変形しています。
そちらのアプローチとは若干異なりますが、結果としては同じ式になりますね。


259 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 17:43:21 ]
なんだか真面目に回答してるスレ民がかわいそうになってきた…

憂煉って奴は工房でこんなの作れる俺SUGEEEとか思ってるのかしらんが前から
偉そうというか他人を見下した書き方をするのでカチンときたと思われても仕方が無い
シューティング大好きという奴は自分が気に入らなければ他人の意見を取り入れない節がある

260 名前:245 mailto:sage [2009/05/23(土) 17:49:10 ]
>>259
む、そういえばそうかも知れません。
以後悪癖直せるように努力します・・・

261 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 17:51:24 ]
>>259
シューティング大好きで括るのやめて

262 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 18:03:43 ]
まあ何にでもアンチはわくものだ

263 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 18:04:26 ]
工房なのか
ならテイラー展開を知らなくても無理は無い
大学の一般教養二日目あたりでやる範囲だしな



264 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 18:07:27 ]
>>261
シューティング大好きっていう糞コテのことだろ

265 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 22:33:52 ]
やっぱりプロの人はC++でベクトルクラスをET使って実装しちゃったり
するんですか

266 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 22:49:35 ]
プロとか関係ないしょ

267 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:17:30 ]
趣味なので一時オブジェクト生成のコストとか気にしません

268 名前:デフォルトの名無しさん mailto:sage [2009/05/23(土) 23:40:09 ]
>>259は向こうのスレの人間か?さりげなく住人批判してるしw
情報の取捨選択は個人の自由だろ。
特に2chソースなんだし。

269 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 00:17:09 ]
アンチってよく飽きないよなー

270 名前:212 mailto:sage [2009/05/24(日) 00:29:17 ]
>>256
掲示板では無理。
OpenGL のディスプレイリストについて調べて、pspgu.h の sceGuStart() の
コメント読んで、sceGeListEnQueue() の動作調べて、
sceGeListUpdateStallAddr() の動作を考察してから調べてみなさい。


開発者向けには、

背景などはゲームとの同期が一フレームずれてても問題ないことが多いだろう
から、フレームの先頭で、ゲーム更新処理前に背景だけ書くようにすると
フレーム先頭のアイドルタイムが減る。

なるべく大きいもの(背景やボス)から描画して、小さいもの(玉や破片)
を後回しにするとアイドルタイムが減りがちになる。

というようなことをアナウンスしたらよいだろう。


ていうか実測が先。
sceGuSync() に時間がかかりすぎているならば、GPU 処理時間に改善の余地が
ある可能性がある。
元々フルパワーで動作しているのにフィルレートが足りないというようなこと
だと、そういったコトを工夫しても無意味だ。

271 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 00:30:16 ]
>>258
> なぜそう喧嘩腰なのか理解に苦しみますが・・・
読解力が無さ杉だろう。
 "カチンときて何か言わずに済まなくなったのか"
が言外に意味するのは、"それは言う必要の無いことだ" ということだ。

俺は標準ライブラリの atan を使えといっていないし、君も使っていない。
言及する必要が全く無いのではないか。
そもそも 201 あての文章を勝手に引き取って
 "使った方が良くないですか?"
ときて、"そんな話はしていない" というような意味の返答に対して
 "atan系はライブラリ側では使ってないですね"
だからね。

また、"直接外積使った方がいいですよ" についても、結果同じことになるのが
分かっているなら書く必要がない。
その上 "いいですよ" と上から目線で書くというのは、何か意趣があると思った
としても自然だろう。

そういうわけで俺は、"君は何か言い返さないと済まない" から書いたのでは
ないかと想像したわけだ。君は >>245 を書く必要が無かったし、書く必要が
無いことを知るのに十分な情報はあったのだからね。

というような、書き込む前に何分か寝かせておけば気づくようなコトなのに、
それに対して君は
> なぜそう喧嘩腰なのか理解に苦しみますが・・・
とくるわけだ。
「ああそうですね」とでも言っておけばいいのに。
喧嘩腰の人間が >>251-254 のような丁寧な説明をすると思うのか。
分かってて書いたのなら、かなり性格が悪いね。

これは気分を害するのに充分だ。

272 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 00:30:53 ]
気分を損ねたので、ちょっと意地悪をしよう。


俺は >>251 の最後の段落で二次元のベクトルを (x, y, 0) というように三次元
に拡張した上で外積の計算をして見せた。
その文章では不要なので触れなかったが、画面手前から奥に向かうベクトルを
(0, 0, 1) として外積の結果のベクトルと内積を取ると、その符号から、外積
の結果のベクトルが xy 平面に対して手前向きか奥向きかが分かる。

全く三次元のまま解決できるわけだ。少しも変形していない。


>>245
> 正確には2Dでは外積そのものは定義できないので「外積の大きさ」を使うことになりますが。
外積の大きさとは何かを説明してもらいたい。
三次元ベクトルの二乗和の平方根でよいのか。
さもなくば、文面からは、"二次元ベクトル同士の「外積の大きさ」"ならば正確
に定義できるというようにも思えるし、そういうことであるのか。
説明してもらいたい。

さらに、なぜ外積の大きさが必要なのかについても説明してもらいたい。

>>258
> 3次元ベクトルの外積の大きさの計算を2次元ベクトル向けに妥当な変形しています。
三次元のまま計算して全く問題ないのに、2次元ベクトル向けの妥当な変形とは
一体どのようなものなのか説明してもらいたい。


ていうかホントに理解しているのか?

>>245 で、助言者(しかも他人への)に対して "直接外積使った方がいいですよ"
ってんだから。追記してまでね。充分に自信があるのだろうね。楽しみだ。

273 名前:デフォルトの名無しさん mailto:sage [2009/05/24(日) 01:30:45 ]
憂煉とシューティング大好きは向こうでも叩かれてるみたいだなw
性格ねじれてる上に荒らしに構うほど馴れ合いならどこ言っても叩かれる罠



274 名前:245 mailto:sage [2009/05/24(日) 01:37:11 ]
>>271
納得のいく説明感謝です。もっと読解力付けないとです。
ただスレを見たら命令口調の物言いやうんこなどと書かれていた事から、喧嘩腰なのかなと感じただけです。
こちらの勘違いだったようで、申し訳ない。
>>272
おっしゃる通り、私が言いたいのは二次元ベクトル同士の外積の大きさです。
ただ、本当に理解しているかと言われると怪しい部分がありますね
楽しみの所失礼ですが、これ以上の返答は控えてせっせと復習することにします。


275 名前:256 mailto:sage [2009/05/24(日) 02:00:03 ]
>>270
>掲示板では無理。
確かに・・・
>OpenGL のディスプレイリストについて調べて、pspgu.h の sceGuStart() の
>コメント読んで、sceGeListEnQueue() の動作調べて、
>sceGeListUpdateStallAddr() の動作を考察してから調べてみなさい。
ヒントだけでももらえると助かります。
APIリファレンスも一応は目を通しているんですが、どういう風に組み合わせて使えばいいかが
さっぱりだたので・・・

>背景などはゲームとの同期が一フレームずれてても問題ないことが多いだろう
>から、フレームの先頭で、ゲーム更新処理前に背景だけ書くようにすると
>フレーム先頭のアイドルタイムが減る。
確かにこの辺は有効そうですね。

上でもでてましたコマンドのダブルバッファを行って無い場合にフレーム開始時に描画しておく分
と一連の処理をしたあとに描画する分が重なるケースも想定しておく必要があるんですが
前の描画が終わってるかどうかの検知はどの辺の関数で行えばいいんですかね?






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<123KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef