HSPTV!掲示板

初めて書き込みさせていただきます。

単刀直入な質問事項を書きますと、
「bufferの数や量は動作や必要メモリ量にどの程度影響するか」
「ゲームとはいえbufferが40・80程度に増えるのは制作上自然なことなのか、もっと効率的な方法は無いのか」
ということになります。

以下長文な状況説明。

現在弾幕STGを製作しています。
その際に素材をbufferに読み込んで使用しています。
方法は640×480の画像の中に、36×48の自機・20×20の敵弾・20×40の自弾、ボムエフェクト……
などなど、ギリギリまで詰め込んでいます。
（この時点で余ったスペースが無駄になっていることも気になっていますが、ここでは割愛）

そこで最近「celput」という命令が「gcopy」「grotate」よりも処理が軽いとの話を聞き、
これの使用を考えています。しかしそれには問題がありました。
この命令のF1を見ると、例えば分割サイズを80×80などに設定した場合、
毎回「celdiv」で分割サイズを書き換えない限り、
36×48の画像や20×40の画像を同じbufferに読み込んで使うのは使いづらいようなのです。

それならば、同じ寸法サイズのものをまとめたらいいのかと考えました。
そこで画像をバラバラにしてまとめてみると、なんと画像枚数が50枚ほどになりました。
同時に使わない画像や、背景などを必要に応じてbufferに上書きする方法も考えましたが、
（完成時にはおそらく）40ほどのbufferを使うことになりそうな状態です。

スクリプトでいえば以下の状態になりそうです（実際のスクリプトではありません）。

	screen 0,640,480, 0, (ginfo_dispx - 640) / 2, (ginfo_dispy - 480) / 2
			#define PI 3.14159265358979//円周率
			//変数初期化
			//〜
			//中略
			//〜
			//画像読み込み
			buffer 1
			picload "op.png",1//オープニング背景
			buffer 2
			picload "op_effect.png",2//オープニング画面エフェクト（0星・1月・2太陽）
			buffer 3
			picload "bullet_1.png",3//敵弾（0赤・1青・2黄・3緑丸弾、4赤・5青・6黄・7緑鱗弾）
			buffer 4
			picload "bullet_2.png",4//敵弾（0赤・1青・2黄色・3緑細長弾）
			//〜
			//中略
			//〜
			buffer 8
			picload "mybullet_1.png",8//自弾（メイン弾）
			buffer 9
			picload "mybullet_2.png",9//自弾（サブ弾 0高速用・1低速用）
			//〜
			//中略
			//〜
			buffer 20
			picload "geffect_1.png",20//撃破エフェクト（ザコ）
			buffer 21
			picload "geffect_2.png",21//撃破エフェクト（ボス 0前半 1後半）
			//〜
			//以下略

動作上は問題ありませんが、どうしても「buffer 21」というような、
仮想ウィンドウの数の多さが気になってなりません。
これが40,80と増えていった場合、それは素材管理の方法に問題があると言えるのでしょうか。
もしくは、規模が大きなゲームの場合であれば、このような状態は自然なことなのでしょうか。

具体的な問題でなく、感覚的で「気にしなきゃいいじゃん」で済んでしまいそうなことですが、
みなさんの意見を聞きたく質問させていただきました。
よろしくお願いします。

うちの場合は、基本 picload で読み込ませて、VRAM 情報として扱うから基本メインとバッファのみの二つかな。

screen作成(buffer/bgscr含む)は、基本 BMSCR 構造体というのを作って、リソースを余計に食うのであまり好きではない。
最近のコンピュータならあんまり影響ないと思うが、スマートフォンなどに移植する場合などリソースの大きさは結構厄介になるかも。

まぁ、普通のコンピュータで扱うなら気にしなくていいかも。

こんな感じかも？
使用する場面ごとにデータをロードするのが一番楽かもしれません。

#enum WID_MAIN = 0
#enum WID_ANDSOON
// この間に固定バッファを定義する。
#enum BID_FREE

#define PI m_pi// 3.14159265358979//円周率

screen WID_MAIN,640,480, 0, (ginfo_dispx - 640) / 2, (ginfo_dispy - 480) / 2

*inopening
	gosub*opening
	if(refstr=="Stat"){
		gosub *initdata
		gosub *game
		// 戻り値として opig とその他を返す。
	}else:if(refstr=="Load"){
		gosub *loadfile//戻り値として Game または Opigを返す。
		if(refstr=="Game"){
			gosub*game
		}
	}
	if(refstr=="Opig"){
		goto*inopening
	}
	goto*endproc
	stop

#deffunc initbuff int wid_ , str fn_,int f_
	buffer wid_
	picload fn_,1//オープニング背景
	return
	

*opening
	#enum BID_OPINGBK = BID_FREE
	#enum BID_OPINGEF
	initbuff BID_OPINGBK,"op.png";,1
	initbuff BID_OPINGEF,"op_effect.png";,2
	// 使用変数などの初期化
	*@
		// opening処理
		await 1
	goto*@b
	return "Stat"

*game
	#enum BID_BULLET_E = BID_FREE
	#enum BID_BULLET_E2
	#enum BID_BULLET_M
	#enum BID_BULLET_M2
	#enum BID_GEFFECT
	#enum BID_GEFFECT_2

	initbuff BID_BULLET_E,"bullet_1.png";,1
	initbuff BID_BULLET_E2,"bullet_2.png";,2

	initbuff BID_BULLET_M,"mybullet_1.png";,1
	initbuff BID_BULLET_M2,"mybullet_2.png";,2
	initbuff BID_GEFFECT,"geffect_1.png";,1
	initbuff BID_GEFFECT_2,"geffect_2.png";,2
	// 使用変数などの初期化
	*@
		// GAME内処理
		await 1
	goto*@b
	return ""

*endproc
	//自動保存処理、処理用Fileの削除など
	end

素早い返信ありがとうございます。
ウィキペディアと往復しながら拝見させていただきました。

>MillkeyStars様
>うちの場合は、基本 picload で読み込ませて、VRAM 情報として扱うから基本メインとバッファのみの二つかな。
>screen作成(buffer/bgscr含む)は、基本 BMSCR 構造体というのを作って、リソースを余計に食うのであまり好きではない。

画像のVRAM 情報だけを扱う方法と、BMSCR 構造体を作成（初期化でしょうか？）するのでは、
VRAM 情報だけを扱う方が目的に対して無駄が無い、と理解することができました。
しかし、「picloadで読み込ませ」ることは、「screen作成(buffer/bgscr含む)」することと全く同じことのように思えます。
つまり、picloadにはscrren作成は不可欠ではないか、と感じているのです。
「VRAM 情報」というところからの知識不足のようです。申し訳ございません。


>ソイスープ様
>使用する場面ごとにデータをロードするのが一番楽かもしれません。

申し訳ございません……。

#deffunc initbuff int wid_ , str fn_,int f_

これが大変に重要でその後に何度も呼び出されているのがわかるのですが、

	#enum BID_BULLET_E = BID_FREE
	#enum BID_BULLET_E2
	#enum BID_BULLET_M
	#enum BID_BULLET_M2
	#enum BID_GEFFECT
	#enum BID_GEFFECT_2

との関連がよくわからず、「なにかあるな！？」という程度の認識でストップしてしまいました……

ですが、

#enum WID_MAIN = 0
#define PI m_pi// 3.14159265358979//円周率

そして

*inopening

でのわかりやすい処理は目から鱗でした。是非とも参考にさせていただきたく思います。


bufferの取り扱いの感覚のほか、実際の画像管理の方法までいただき、ありがとうございます。
他の方の意見も聞きたく思いますが、ここでは便宜上解決とさせていただきます。