HSPTV!掲示板

【2DSTGで弾幕ではない】
サークル制作でプログラマーのプログラムを覗く機会があったのですが、
配列変数を大量?(適量かもしれない)に使ってオブジェクトの様々な状態を
操作するわけですが、100個のオブジェクトに対して約10くらいの情報で操作。
100*10の1000をループを利用して処理しますが・・・
当たり判定関係では、オブジェクト同士は矩形で対応してもらったのですが、
どうしても円(距離)を使った判定が必要になり、それを100回も200回も
ループしていると思うと・・・

一応参考にできる！・・・？ようなものを発見しましたが
http://hsp.tv/play/pforum.php?mode=pastwch&num=49136
http://hp.vector.co.jp/authors/VA022217/tips/hsp/bench.html
情報が古いし、何より情報学みたいな知識ゼロな高校１年生なので
情報から学べる知識が1~2割くらいしかないです。(理解力に欠けてるのか・・・

描写処理にhmmというdxプラグインなんか使えば画期的に早くなるように
計算にもそれっぽいの見つけて使えば早くなる？とは思ったものの
・・・いや計算処理はHSPの翻訳が入るらしいから限界あるのかな。
APIをどうのこうの言う話をチラッと見たこともあって、何がどうなっているのかサッパリです。



処理速度を上げる具体的な方法をいくらか考えてみたいので
ご協力お願いします・・・
（レスは不定期です）

■初期化部分を見て取れた変数状況
実数型１次配列変数が6~セット
整数型１次配列変数が10~セット
それぞれオブジェクト数にあわせて100コずつ初期化。
少なくても100*16以上やつをループループしていると思われる。
プログラマーのPCでは既に処理落ちしていた。

ごめんなさい、このスレッドの内容とは全く関係ない話なんですけど、
http://alienshootertenkusu.jimdo.com/
に僕たちが作ってるエイリアンシューターの新しいゲームのスクリーンショットを貼ったので
SADOUSさんのホームページのリンクを更新してくれませんか？
スタッフはテンクス、3ルキー、ばくだんマン
でお願いします。
忙しいのであれば遅くなっても構いません。ゆっくりでいいので。
よろしくおねがいします。

手軽と言いますか雑な方法ですが、当り判定の処理を2フレームあるいは3フレームに一度のみ
行うようにすると、だいぶ速くなるとは思います。
当然判定の行われないフレームが発生する訳で、厳密性や競技性（？）は落ちますが、
一度お試し下さい。

まずはゲーム内のアルゴリズムを見なおして最適化しましょう。
不要な計算を行っていないか、別のアルゴリズムで高速化できないか、などを考えてください。
アルゴリズムを最適化することによって、非常に高速な処理が実現できることが多いです。
その上で高速化を求めるなら外部プラグイン等に頼るしかないかと。
HSPからOpenCLが扱える便利なプラグインがあります。
http://dev.onionsoft.net/seed/info.ax?id=476
詳しくありませんがカーネルというコードを書くことで、並列実行による高速化ができるそうです。
これによりC言語などよりも非常に高速に計算を行うことが可能になります。
ただゲームに組み込むべきかというと分かりません。
SADOUSさんの作りたいゲームが本当に大量の計算を「必要」とするのならばこのような手もある、というだけです。

ゲームを作るのにSADOUSさんの挙げられたような大量の処理が必要とは思えません。
アルゴリズムを再度考えなおしてみることで、思わぬ箇所で高速化が図れるかもしれません。
頑張ってください。

>テンクスさん
了解しました・・・がしばらく時間をください。（色々あってキツイ）
記述の際、バクダンマンさんはグラフィッグという扱いでよろしいですか？

>祐矢さん
さすがにそれは・・・

>catsさん
オブジェクトに様々な情報を組み込み、ほぼ無限通りの組み合わせが作れるよう
画像ID・行動ID・状態をはじめとしたたくさんの配列変数を用意するわけですが
詳しいことはプログラマーでないとわかりませんし僕自身無限通りにする意味も
わかりません。
僕が理解できていないのか、
プログラマーの理想のシステムが(ゲーム本編よりも使いまわせるようなのを目指していると言う)
本作に対してオーバースペックなのかわかりませんが、
アルゴリズムの見直しは9割型望めません。
「おーばーすぺっくなんじゃね？」みたいな話は何度かしてみたのですが
プログラムに疎いディレクターに「無限通りの組み合わせができるシステム」を
目指しているプログラマーと現状をいまいち把握しきれていない自分では
どうも話をスッキリまとめることができないんです。

というかプログラマーのモチベを維持させるために極力反対意見を
押し通さないようにしているんですけどね。
サークル随一のプログラム作業担当ですから、頑張ってもらっているだけありがたい。
因みに全員高１。

>GPGPU用プラグインHSPCL32デモ
openCLってそんなに速いんですね。
コメント0件なのが気になりますが今度試してみたいと思います。
openCL,カーネル,マルチ処理とかの専門用語？が全くわからないけど
とにかくHSPよりもずっと速い計算速度を望めそう・・・

>catsさん
追記ですが、100コ以上の動的、非動的オブジェクト(地形も)を
「マッピングを実装すんのだりー」「この苦労が案外好き」という理由で
座標を手打ち(32,64とかを掛けて配置するのではなく、タイミング出現させる)する人
なので、アルゴリズムをいちいち変更するような作業を入れるのはかなり
負担をかけてしまうことになる。

サークルのゲームの為にもプログラマーの為にも処理速度を向上させて、
かつマッピングをゲームに適した形で実装できるようにしたいと思います。

矩形と距離なら
(判定の記述方法にも拠るかもしれないが)
元より距離の方が計算早いんではなかろうか…

>SADOUSさん
はい。お願いします。
ブログに書けばよかったのか...と後で気がつきました...

ざっと拝見しました。ちょっと誤解があるような気がするのですが
DLLを導入するということは、それにあわせてプログラムを書き換える必要があるので、
結局プログラマの人がソースを全部書き換えることになるんですが、そこは良いんでしょうかね？

本題ですが、車でも何でも速度を上げるのに一番効果があるのは軽量化です。
つまりいらないものは捨てる、いるものも何とかしていらなくするということです。
ですから、プログラム担当の方が目指してるらしい「無限通りに対応したシステム」が今後早くなる見込みは薄いです。
しかし理想のシステムを組みたいという彼の気持ちを誰が止められよう、いや誰も止められまい。

そういうわけで、現実的で具体的な方法が二つ提案します。
ひとつは、今作ってるものに適したシステムを他の誰かががんばって作る方法、
もうひとつは、もっと早いパソコンに買い換えることです。

描画は何を使って行っているのでしょうか？
ゲームにおいて最も負荷がかかるのは描画部分です。

標準命令で描画しているのであれば、hgimg3などの
DirectX系の描画プラグインのが最も手っ取り早く効果も大きいです。

>とおりすがりさん
確かに！
DLLを導入するにあたってのソースの書き換えは確かに難しそうです。
いくら数メートル先で作業していても、プログラムを100%理解していないと
書き換えは無理でしょうね。
どうせ理解するなら、プログラマーさんのものを元に僕の方で新しくつくっちゃえば
いいんですもんね。
それは怠い・・・

買うって・・・
今のところプログラマーさんのPC以外(ディレクターや僕、サブプログラマのPC)では
処理落ちしないのでデバッグ・テストの時だけ実行ファイルを共有しています。

>ZAPさん
描写部分はhmm.dllを利用してdxでしています。
僕の知識不足・理解力不足のせいでhgimg3という開発が続いている上に
高性能？なプラグインを利用できないのは実に残念。
でも、標準よりはずっと高速で(検証済み)、ほしい機能は今のところ満たしているので
問題はないんですけどね。

因みに言うと、自分のサークル内立ち位置としては
音・画像処理のプログラムとパッケ絵をかいたりGUIやその他のデザインをする
わりと気楽なもんです。
プログラムを組むのはかなり下手くそでアルゴリズムを考えるには時間がかかりまくって・・・



現在考えているものは、
計算処理とループ部分の主に当たり判定の軽量化ができないかの見直しと
単純にループが多い部分から不要部分を探す、
今思い出したんですが
定数でもいいような部分もいくつかあった気がするので総見直しですかね・・・

要するに"見直し"をするのかー

【ごめんなさい。スレ関係なし/連絡が取れるかどうか】
テンクスさん見ていますか？

PRの件ですが、
旧PR画像では
「難易度4段階、全6ステージ、超ド級の弾幕避けSTG！」
「テンクス、3ルキー」
となっていますが、スタッフ以外に修正点は有りますか？
希望の文章や修正点、問題なしかどうか連絡下さい。
できればここかツイッターにお願いします。(ブログはレスが不定期)

例えば、

if 40.0>=absf(sqrt(powf(plox(cont)-objx(cnt),2)+powf(ploy(cont)-objy(cnt),2))){

という部分。距離計算・・・円の判定の部分を無断でコピってきましたが、
(大丈夫、大丈夫・・・)
カッコをむやみに多くすると重くなる
累乗とかルートの計算とか特に重くなりそうな感じしますが、
コレ自体は軽量化のしようがありませんよね？

absfが不要だったり、powf(a,2)の代わりにa*aが使えたりしますね（aは適宜変更してください）

tmpx=plox(cont)-objx(cnt)
tmpy=ploy(cont)-objy(cnt)
if 1600>=tmpx*tmpx+tmpy*tmpy {

比較する数値（４０）をあらかじめ二乗しておけば平方根をとる必要もない

>Flatさん
なぜ気づかなかったんだろう・・・

repeat
	;検証対象
	//a=10:a=powf(a,2)
	a=10:a=a*a
	;簡易FPS
	fps_cnt++
	sec_old=sec:sec=gettime(6)
	if sec_old!=sec {
		fps=fps_cnt:fps_cnt=0
		color 255,255,255:boxf
		color 0,0,0:pos 0,0:mes fps
		}
await
loop

で試してみたところ、powfが85万あたりなのに対し
アスタリスクで掛けると100万超え。これはすごい。
実際にこれを円判定でやってみてどうなるかでどうにでもなりそう。

>ZAPさん
ああ、これもなぜ思いつかなかったんだろう。要検証ですね。

処理速度を早くするのでしたら、
条件文やループをなるべくなくす
内容によって関数をインライン展開する
メモリを頻繁に取得や解放をしない
重複する部分はなるべくなくす
などがC言語などで使われています。

>skybleさん
なるほどです。


・・・
プログラミングを始めてから最適化・軽量化といった作業をまともにやってこなかったので
イマイチイメージがつかめていなかったのだと思います。
今回のコレはすごく勉強になりました。ありがとうございます。