HSPTV!掲示板

DirectXを利用する場合の最低環境として
オフスクリーンバッファは画面解像度以内（≒640×480）という理解の下で質問です。

2Dスクロールアクションゲームでレイヤー数枚分、解像度以上の大きなマップデータから
DirectXで表示エリアだけ描画したいんですが、
はじめにHSP標準バッファで全体を作画しておいたのを毎フレームごとに
es_bufferで必要な部分だけ転送するのと、
DirectXだけで毎フレーム作画（表示領域内の1セル分ずつチップ並べ×レイヤー分）していくのは、
一般的にどっちが速いでしょうか？

ちなみにHSP3.2、hspdx.as利用、es_xxx系のスプライト機能は使わず自前処理。
配布用ゲームなので実行環境は不特定多数です。

　レスがないようなんで、とりあえず枯れ木も山のにぎわい的レス。

　全然まともに検討していませんが、直感的にDirectXだけの方。

　es_syncで２つの画面を切り替えるので、それを意識せずにトリッキーな
ことをやるとうまく描画されません。es_bufferは２画面のどちらに
転送するのかといった問題もあり、実装は難しいと思われます。

レスありがとうございます。

>es_bufferは２画面のどちらに転送するのかといった問題

というのがよく分かりませんでしたが、DirectX表示中もHSP標準バッファで裏作業できるので、
HSPとDirectXの切り替えコストはあまり考えなくてもいいというか、
そもそも毎フレームでes_cls〜es_syncの繰り返しをかけてるので…？

同じく検証はしていませんが、以下は自分の想像なので間違えがあれば指摘してやってください。

まずURLのせていいか分かりませんが以下のサイトさんを参考にします。
http://www.tcn.zaq.ne.jp/akasy005/hsp2.htm
>gcopy 0,0,0,32,32: 2453ms
>gcopy 0,0,0,64,64: 3200ms
>gcopy 0,0,0,160,160:13925ms
（※抜粋、すべてパレットモードとのこと）

条件はいろいろ違うので一概には言えないでしょうが上記データを信用すると、
同じ面積をコピーする場合、小さく複数回より大きく一回ですませた方が速そうです。

自分の案ではマップ作画はステージデータを読込んだ直後に1回だけで、
後はそのバッファを保持しておくだけなので、
たとえば640×480を32×32ずつのセルで埋めるとした場合300回のgcopyが必要ですが
es_bufferの方がかなりコストがかかるとしてもgcopy300回よりは速そうな気がしたんです。

＜適当なサンプルというか手順＞

#include "hspdx.as"
	;// 初期化など
	screen 0,640,480,0
	redraw 0
	buffer 2,640,480,0
	;// ID2にデータやチップファイルを読込んでマップ全体を作画（実際は解像度以上）
	es_ini
	es_screen 640,480,32,,useWindowMode,useDirect3D
	repeat
		es_cls
		;// キー判定や位置計算など
		gsel 2
		es_buffer 2,0,$000000,1,useDirect3D
		es_copy 2,0,0,640,480
		;// 自機や敵などその他の描画
		es_sync
		await
	loop
;// 後略

　昔書いたRPGのサンプルを読んでみたら、es_xferを使いたかったらしいのですが、
うまく動かなかったので、代わりにスプライトを使うことにしたようです。
うーん、背景にスプライトを使うとは、我ながら大胆な……。

自分の場合は加減算で画面演出するため、一度Direct3Dのテクスチャで画面描画やりましたw
で、なんか上手くいかなくてマニュアルよくみたら、
グラフィックボードによっては最大サイズが256以内とか、2の乗数でないととか制限があって、
結局Direct3Dは使わない方向で書き戻したという…。

>3.縦横ともに画面解像度と同サイズまで
これを前提にするなら

全体背景をbuffer 2に作って
>gsel 2
>es_buffer 2,0,$000000,1,useDirect3D
>es_copy 2,0,0,640,480
って、出来ないんじゃ？

やるなら
一画面分のbuffer 3とかを用意して

gsel 3:pos 0,0
gcopy 2,scx,scy,640,480
es_buffer 2,0,$000000,3,useDirect3D
gsel 0:gmode 0:pos 0,0
es_copy 2,0,0,640,480

って、やらないと前提条件満たせないしスクロール出来ない
後、自分の環境じゃ32*32を21*16回es_copyの方が軽かった

自分の環境の場合D3DをONにしたes_bufferだとサイズ制限厳しい（自分のは4096*4096超えるとes_ex系は描画されなくなった）けど
OFFなら特に制限なかった（ONでもVRAMイメージ転送は出来てるけどes_copyじゃないと描画されなくてしかも重い）

>3.縦横ともに画面解像度と同サイズまで
これを前提にして一画面分のes_bufferとマップチップ用のes_bufferを使ってやる方法はあるけど（うちだと32*32を21*16回es_copyよりも軽い）
マップチップ用のes_bufferが何枚も必要だとか
D3DをONのes_bufferだと重くなる・・・
（es_xferを使うから）

＞一般的にどっちが速いでしょうか？
背景枚数やD3D使う使わないなど決めないと、どっちが速いなんて分からない
特定のハード構成で速くても他でも速いかは分からない

＞es_bufferの方がかなりコストがかかるとしてもgcopy300回よりは速そうな気がしたんです。
まずは、自分の環境で試して、疑問だったら他の環境でも同じなのか聞くべきでは？

> KIMUさん
なるほど、色々はしょって書いちゃってましたが丁寧にありがとうございます。
考えてみると、3Dでは何千何万もの頂点計算してるんだし、
グラフィックカードの性能は遥かに高いってことみたいですね。
あと、ゲームの描画でどっちが早いかはすぐ行き当たりそうな問題なんで
聞けば誰でも知ってるくらいかと思ってたんで他力本願ですみません。

>聞けば誰でも知ってるくらいかと思ってたんで他力本願ですみません。
最初にANTARESさんが
>　全然まともに検討していませんが、直感的にDirectXだけの方。
って言われてるのに納得してなかったようなのでね・・・

少なくても自分の環境では
HSPバッファから切り出してes_buffer+es_copyは複数枚の背景では物にならないぐらい重い
背景2枚が限界
32*32を21*16回es_copyの方だと4枚
スクロール分だけ追加してく方法で8枚ぐらい（スクロール速度にもよるけど）


>3.縦横ともに画面解像度と同サイズまで
この前提を無視できないなら

一番速いのは一画面分のes_bufferを背景全体に必要な分枚数を確保して繋ぎ合わせる
ゲーム全体で64枚以内に収める必要があるが・・・

またまた具体例ありがとうございます。
自分の環境だとあまり負荷なく動いちゃってたけど
いま進めてる仕様だと地形判定用レイヤーも入れて4枚分だからギリギリというか
不特定の環境向けって考えると厳しいですね。
ただ、こんなこともあろうかとステージはいくつか細分化できるようにも考えてたので
エリアごとの読み込みは必要になるけど、es_bufferを繋ぎあわせる案で頑張ってみようと思います。