HSPTV!掲示板

初めましてmatsuedaと申します。
hsp3.3で2Dゲームを制作中です。

プレイヤーと敵の２キャラ＋背景＋ＧＵＩ
といった構成の格闘の様なゲームです。
プログラム初心者です。

制作が進むに連れ、画像やサウンドを追加する度に
起動の読み込みが遅くなっていくと思いますが
皆さんはどう対処していますでしょうか？

デバッグに段々と時間が掛かってしまうので
どうしたものかと悩み中です。

読み込む画像を1/4ぐらいの解像度にして制作を続け
最終的に等倍に戻す方法も考えていますが、
手間を増やしたくないので、なるべく避けたいと考えています。

ＰＣの性能を上げると良いのでしょうが
それは金銭的に無しにしたい所でして。

現在は１０〜２０秒ぐらい読み込み時間がかかります。

そもそもこれぐらい読み込みに時間が掛かるのは当たり前だよとか、
あるいは、まだ全然速い方だよと、そのうち２，３分は軽く超えだすよ
などお教え頂ければ幸いです。

PC構成
celeron 1.73GHz RAM 1G
OS windows vista

まさか、いっぺんに全部読み込んでないよね？
必要なときに必要なものをこまめに読み込む、それじゃだめですか？

毎回picloadとかしてないですよね?
画像や音声の大きさは知りませんが、明らかに遅いと思います

>>荒河さん

レス有難うございます。

現在、画像を一変に読み込んでいます。
一変と言いましても、敵の全アクション(約150枚)、自キャラの全アクション
（約150枚）背景１枚、ＧＵＩ（スタート、ＷＩＮ、ＬＯＳＥなど数点）で全てBMP。
あとＳＥが数点です。

480*320という解像度で、敵や自キャラのアクションを用意していますので
それがかなり読み込み時間に影響を及ぼしていますかね？

絵は解像度分を丸々持っていますので、
抜き部分などそのままでかなり勿体無い状態です。

一枚の絵の不必要な部分をメモリに載せない様に、
細かくパズル状に配置して一枚の絵にして、
それを表示するようにして、
さらにそのアニメ管理部分を構築する必要がありますかね。

今はベタ一枚を次々切り替えるというだけの、
楽なアニメ方法を取っていまして、
お手軽なのでそのままこれで行ければなと考えていますが
甘いですかね。

必要な時に読み込むという点ですが、
攻撃毎、防御毎に画像を読み込むと
攻撃や防御の入力の度に少し遅くなった感触が出てきましたので、
ここまで頻度を増やすのは違いますよね？

>>TMKLさん

レス有難うございます。

最初に300枚ほどpicloadしています。

プレイヤーの入力を受け付け開始以降は
picloadしておりません。

デバッグの際ですが、
読み込む画像が変わらない場合は、
メモリに残っているはずですので、

画像は読み込ませずコードの更新だけをさせてデバッグする。

という方法は取れ無いのでしょうか？

最初に一度に読み込むのがいいと思います
また、自分の環境で↓のようにして
buffer 1〜buffer 300に
480*320の画像(dummy0.bmp〜dummy299.bmp)を読み込んでみましたが、
読み込みは5秒程度でした

repeat 300
buffer cnt+1
picload "dummy"+cnt+".bmp"
await 1
loop
dialog "終わり"

デバッグの方法についてはわかりません、すみません

画像ファイルをパックして、exeファイルでデバッグをしていれば、
次のスレッドが参考になるかもしれません。
http://hsp.tv/play/pforum.php?mode=pastwch&num=39993

>>TMKLさん

了解致しました。
ダミーデータで実験までして頂いて恐縮です。

>>HK2さん

なるほど！
これはかなり自分の期待する方法かも知れません！
有難う御座います！

単純に計算すると (高さ * 幅 * 3 * 画像の枚数) byte となるため。
環境によっては、フリーズします。

ファイルをロードする際のオーバーヘッドよりも、メモリの確保の負担が大きいこともあるので、大量のデータを扱う場合には、配慮が必要になると思います。



　

絵の色数を全て１６ビットにしてメモリ使用量をケチる・・・のは後ろ向きですかね（＾＾：

画面の色数そのものを１６ビットにしないといけなくなるのと、HSPが内部で３２ビットで扱っていれば無意味ですけど・・・

>>ヂオンさん

根本的にデータが大きいという事ですよね。
pngを試してみましたが、圧縮展開の時だと思いますが
自分のノートＰＣではパワーが足りませんでした（笑）
明らかに処理落ちが発生しました。

>>ZAPさん

１６ビットは有効ですね。
でもたしか３２ビットだった様な気がします。
どこかにフルカラーと書いてあった様な・・・
調べてみます。

--------------------------------------
皆様、色々なご意見を有難う御座いました。

有効そうなdpmでしたがパックして試した所、
読み込み速度は余り変わりませんでした。

もしかしたら１秒程度は速くなったのかも知れませんが体感は出来ませんでした。
絵の追加毎にパックする作業時間を考慮するとかなり微妙ですね。

packfileの登録できるファイルの11文字制限もやっかいで、
何のファイルか分から無くなってくると言いますか。

取りあえず現状のまま作業を続けます。
その際、有効な手段が見つかりましたら報告致します。

一先ず解決とさせて頂きます。

皆様大変お手数をお掛け致しました。
有難う御座いました。

補足を。

画像の容量を減らす為には、
下記の様なツールで行われている表示方法で
アニメパターンを作る必要がありますね。

ttp://www.webtech.co.jp/sstudio/about.html

この環境を作るのは相当辛いですが。

すべてのデータを一気に読み込もうとするとまず間違いなく遅くなる。
必要なデータを必要な時に読み込めばいい。
ただ、ファイルからデータを読み込むのは時間がかかるので
市販のゲームはデータの先読みだの、キャッシュだのを利用してどうにかやりくりしている。

あとは画像データの圧縮だな。
HSPはゲーム向きと謳いながらPNGファイルが標準で読み込めないという非常に残念な仕様となっている。
早く改善されないものか。
HSPDishでは読み込めるみたいだが、これはDirectXの機能を使ったものだろう。
もしかしておにたま氏はlibpngの使い方がよく分からないとか、そういうことはないだろうな。

俺の愚痴はおいておいて、ファイルを減色したり、圧縮する。
BMPファイルの実態を知ったら「なんだこれゲームにはとても使えねーよ」と叫びたくなるだろう。
音声の形式はoggがお勧めだ。MIDIでもいいが、再生音は環境に左右される。

>画像は読み込ませずコードの更新だけをさせてデバッグする。
のは難しいだろう。
ゲームAからゲームBのメモリを勝手に参照できないように、
仮想メモリアドレスというものがWindowsから割り振られているから。

>敵の全アクション(約150枚)
>自キャラの全アクション（約150枚）
とありますが、もしかして1枚の絵を1つのファイルとして
用意し読み込んでいるのでしょうか？

もしそうであれば、ひとつの[技]単位などで画像を分けるなどすれば
かなり負担が減りそうな気がします。
[PlayerMove.bmp]
[PlayerAttackA.bmp]
[PlayerAttackB.bmp]
といった感じです。

画像の中身自体は↓このような感じで
http://gyazo.com/7b76242b8846832b8e7f7dd63aa49e53
ひとつのモーションの全てのコマをひとつの画像内に横や縦に並べた物を用意します。

これをプログラム上で動かす場合、
PlayerAnimePatternという変数があるとして、
その変数にプレイヤーのアニメーションパターンを
プレイヤーの挙動を処理している部分で、挙動に応じて代入します。
そして表示部分のプログラムで、

gmode 4, 480, 320, 256

gcopy *, 480 * PlayerAnimePattern, 320

などという風に記述すれば、
PlayerAnimePatternに代入された変数に応じたアニメーション番号が表示できます。

もしこれらが煩わしいということであれば、
celdivおよびdelputという命令を使うと楽に扱えます。
こちらはサンプルも用意されているのでヘルプをご覧下さい。

なぜこの方法をお勧めしているかというと、
私の環境で 100x100 の画像ファイル(bmp)を、

repeat 1000

	buffer cnt
	picload "test.bmp"
loop

とし、1000回picloadした時より、
100x100,000 の画像ファイル(bmp)を、単純に

buffer 1

picload "test.bmp"

とした時のほうが圧倒的に時間がかからなかったためです。
まあ、バッファを初期化する手間などがないので当たり前なのですが…。
matsueda様の文面から汲み取った限り、
300枚の画像を300個のbufferに読み込んでいるような気がしたので、
このようなレスをさせて頂きました。
もし見当違いな内容であれば申し訳ありません。

参考までに、それぞれの読み込み方法にかかった時間を載せておきます。

■100x100の画像を1,000回読み込んだ場合
726 / 724 / 725 / 723 / 720 / 726 / 722 / 732 / 721 / 724

■100x100,000の画像を1回読み込んだ場合
258 / 178 / 217 / 222 / 184 / 176 / 229 / 188 / 210 / 229

(それぞれの方法で10回試した結果を全て表記しました。
　上記数値はミリ秒です。)

>> checkさん

画像を減色する事にしました。
アルファ抜きを使いたかったのでフルカラーでしたが
1bit抜きの256色にした所幾分速くなりました。
体感が変わりました。

>> ひじきさん

まさにご指摘の通り1bufferに一枚の画像を読み込んでおりました。
バッファの初期化でかなりタイムロスが発生するんですね。
勉強不足でお恥ずかしい。
bmpも纏められて画像のデータ管理も楽になりそうです。

これはかなりのスピードＵＰが期待出来そうです。
今度の休日にデータを連結して見ます！