HSPTV!掲示板

ゲームを作成中で、キャラクター画像を表示させる際に下記のようにbufferで読み込ませているのですが

buffer 25030
picload"画像名.bmp"

1400個ほど使用した状態で、差分画像作成のためにコピーし、

buffer 125030
picload"差分画像名.bmp"

と行ったところ、エラー１が表示されました。

ためしに、差分画像分のbufferを３００個ほど削ったところ、
無事に起動したのでbufferの数の上限に引っかかってしまったのではないかと考えているのですが、
何か良い解決方法はないでしょうか？


補足として、
①1400個の画像は全て使用しています
②差分画像は元画像と同時に使用します。
③画像を１つに纏め、範囲指定で読み込ませる方法は個数の問題もあり回避したいです

できればceldiv使った方がいいんですけど。
それだったら強引ですけど、vramの配列を使うとか？
流石に強引すぎか…｡

1400個全部違う画像ですか。すごくたくさんの素材用意したんですね。
プログラミング・マニュアルのHSPシステムの許容範囲によると、ウィンドウIDの最大数は無制限とのことです。
といっても実際はメモリが許す限りだと思います。仕様上は問題なさそうに見えますね。


> ①1400個の画像は全て使用しています
同時にでしょうか？
あるいは、次の瞬間どの画像を使うか全く予想ができない状態でしょうか？

> ②差分画像は元画像と同時に使用します。
画像数多いからシューティングかなと思っていたのですが、もしかしてアドベンチャーゲームですか？
口パク、目パチとかのアニメのための差分画像ということなのかな。
どういった用途なのか説明いただけると別の解決策を提案できる方が出てくるかもしれません。

> ③画像を１つに纏め、範囲指定で読み込ませる方法は個数の問題もあり回避したいです
画像サイズがそろっているものであれば、管理の面からもceldivが簡単でおすすめです。
hspdxfixプラグインでDirect3D描画という手もあります。


ところで、、、個数的にPCへの負荷が高そうな気がします。
問題解決とはまた別の話になるのですが、タスクマネージャを起動してメモリの消費やCPU負荷が以上に大きくないか見ておいた方がいいかもしれません。他環境で実行したらまともに動かないほど重いかも？

>kanamaruさん

やはりceldivがベストなんですねぇ……


>GENKIさん

補足になります
①次の瞬間の画像の予測がとりにくい状況です
（再度picloadを行い、同じbufferで複数の画像を当てはめることは難しそうです）


②ジャンルとしてはリアルタイムの育成シュミレーションになります。
アクション用のアニメ差分が用途となります。

③画像サイズは全てそろえてあります。

>hspdxfixプラグインでDirect3D描画という手もあります

調べてみてceldivとどちらが移行が楽か、比較してみますー

負荷的には同時の使用数は（ほかの画像も含めて）１００未満ですので、今のところは問題ないと思いますー
（開発用のローとミドルの間くらいのスペックのPCでFPSを制限解除すると２～３倍速ほどで動作するので）



やはり、一括化してceldivでの指定を行うしかないような気もするのですが、
差分画像のパターンが多く、一括化してしまうと管理が煩雑化してしまいそう＆一括化の手間が億劫な感じで、
出来れば他の解決法か、コツみたいな物があればご教示頂けると幸いです。

強引でいいなら、vramの配列。
強引ではダメなら、ファイルの中身のバイナリデータとして、
なんらかの方法で圧縮したデータをテキストファイルに入れてそれをよみこんで、
圧縮したのを内部で解凍、
そしてメモリストリームで読み込むとか。

下記スレッドでも似たような(?)ことが書かれています。
http://hsp.tv/play/pforum.php?mode=pastwch&num=11877
メモリサイズの問題ということで結論が出されているので、大量のバッファを使うのは推奨できません。
バッファサイズを減らすのには、やはり画像をまとめることをおすすめします。
ファイルが多いと面倒そうですが、それこそHSP等で一括処理してしまえば、そんなに手間取らないでしょう。
また、ゲームであれば私はステージ(場面)ごとでバッファをクリアします。
少し説明しづらいですが、ステージごとに変数、音声、画像等を全く別にして書くと、
自然に変数やバッファに何が入っていても正常に動作するようになります。
(例えば、現在バッファ1にAが入っているが、次ステージではBを上書きする、など)
同じリソースを使うステージでは、再読み込みするため無駄に思えますが、
少ないリソースを管理するだけで良いので、非常に楽です。

> ①次の瞬間の画像の予測がとりにくい状況です
> （再度picloadを行い、同じbufferで複数の画像を当てはめることは難しそうです）
ステージごとなど何らかの大きな区切りごとに、不要なバッファを破棄して必要になる画像を読み込むようにすればバッファ節約できると思ったのですが、無理なのかー。

> ②ジャンルとしてはリアルタイムの育成シュミレーションになります。
> アクション用のアニメ差分が用途となります。
回答ありがとうございます。状況がイメージしやすくなったので回答しやすくなりました。
シムシティとか庭で野菜育てる系かな…？

> ③画像サイズは全てそろえてあります。
ならやはり１個のbufferに１素材として管理するより、celdivが簡単便利です。

> 一括化してしまうと管理が煩雑化してしまいそう
ウィンドウID１個だけで管理するより管理しやすいと思いますよ。
キャラクターごとにバッファを用意したりといったことができますから、全部を通し番号１個で管理するよりわかりやすくなると思います。
後から素材追加するのも容易ですしね。

> 一括化の手間が億劫な感じで、
catsさんの言う通りHSPで画像連結ツール書くか、ベクターあたりで画像連結ツール探せば簡単です。
しかし1400個も画像素材用意するのに比べたら大したことないような…。

>buffer 25030
のID部分を分割NOとバッファIDに別ける
上位下位ワードを別々の値として別ける方法もあるけど
今回は一つのバッファに読み込む数で別けた

#define PICSIZEX 640
#define PICSIZEY 480
#define PICDIVMAX 5	//一つのバッファに読み込む画像の数
#define ctype GetID(%1) ((%1)/PICDIVMAX)
#define ctype GetNO(%1) ((%1)\PICDIVMAX)

#define buffer2(%1,%2=640,%3=480,%4=0)  :no@temp=GetNO(%1):id@temp(GetID(%1)) | 0 :if id@temp(GetID(%1))=0 {buffer GetID(%1),PICSIZEX*PICDIVMAX,PICSIZEY,%4 :celdiv GetID(%1),PICSIZEX,PICSIZEY: id@temp(GetID(%1))=1}else{gsel GetID(%1)}
#define picload2(%1,%2=0,%3=0) pos GetNO(no@temp)*PICSIZEX,0 :picload %1,1
#define celput2(%1,%2=0,%3=1.0,%4=1.0,%5=0.0) celput GetID(%1),GetNO(%1),%3,%4,%5

offsetid=25000
picloadmax=15

chdir dir_exe+"\\hsptv\\"
repeat picloadmax
	buffer2 offsetid+cnt
	picload2 "sozai"+str(1+cnt)+".jpg"
loop

gsel 0
repeat
	pos 0,0
	celput2 offsetid+rnd(15)
	await 1000
loop

>GENKIさん
ジャンルで言うと、ペット育成シミュレーションなんですが、1キャラクターに1400個使っている状況で、キャラクターを追加しようとした所今回のエラーが発生しました。
１動作で平均して４～５枚前後の画像を使っているのですが、それら全ての読み込みをID指定から分割No指定に変えるのが少々億劫な感じです。
ただ、今までの皆さんの解説的に、celdivでの分割管理を行うのが今後も踏まえるとベストな手法であると理解できました。

>暇人さん
先にceldiv管理がベストと言っているのに反しますが、やはり手間は省きたいのでこちらを試してみて、（自分の技術的に）難しいようであれば、celdiv方式に変更したいと思います。



皆様、親切丁寧な回答ありがとうございました。

自分で描いたにせよ別の方法で用意したにせよ、
1400枚もの画像を用意したこと自体、その労力には感服します。

一方で、それだけの画像を使うということはメモリの使用量も半端じゃないでしょうし、
プログラム上の管理も煩雑になるということで、
はたしてゲーム内容に比してそこまでの枚数が必要なのかどうか、
たとえばアニメーションの枚数を間引きするとか、似たような画像は統合するとか、
ゲームデザインに支障のない範囲で画像枚数を減らす方法を考えてもいいのではないでしょうか？

こうなってくるとプログラムではなくゲームデザインの話になってしまいますが。