キャラクター画像のVRAM節約方法

[コマンダーヤンマーク]

格闘ゲーム製作中です。
キャラ画像によるVRAMの超過で困ったときに一つ解決方法を思いつきました。

５１２×５１２のキャラ画像ファイルがあったとします。

それを
LoadDivGraph(*FileName , 256, 16 , 16,32 , 32 , *HandleBuf ) ;
でマップチップのように読み込んだ後
格納したハンドル32×32の中に何も書かれていなければ（透過処理色が白のとき、真っ白とか）、ハンドルを開放をする。
残ったグラフィックハンドルを連続で描画し一枚絵にするという方法です。
キャラクターのほしいところだけグラフィックハンドルに入るのでかなり節約できると思います。

そこで３点質問がございます。

1.
>格納したハンドル32×32の中に何も書かれていなければ（透過処理色が白のとき、真っ白とか）
という判断はどういった関数を使えばよろしいでしょうか
一度描画してから描画先の色を取得するしかないですか？

2.
この処理により大量のグラフィックハンドルを消費することになりますが
「DXライブラリのグラフィックハンドルの上限数は32768個」とどこかで見ました。
余裕で上回ります。
上限の変更は容易ではないのでしょうか？

3.
この方法はダメ？


よろしくお願いいたします。

[h2so5]

そもそも何も書かれていない領域がたくさんあるグラフィックを使っている時点で無駄が多いと思います。
空白の領域がそんなに沢山あるんでしょうか？

[softya（ソフト屋)]

普通はツールで自動的に最低限のブロックに自動分割させるんです。
読み込む前に加工しておけば、変な処理も入らないですし、５１２ｘ５１２の数枚の絵からDrawRectGraph()でパーツを抜きだして表示するのでVRAM上で高速処理が期待できます。ここで手を抜くと苦労した割に高速ではないと言うシロモノが出来がりますよ。

>格納したハンドル32×32の中に何も書かれていなければ（透過処理色が白のとき、真っ白とか）
という判断はどういった関数を使えばよろしいでしょうか

LoadSoftImageがありますが、ツールの加工時に使ったほうが良いです。

>上限の変更は容易ではないのでしょうか？

遅くなると思うので止めたほうが良いです。

[コマンダーヤンマーク]

そもそも何も書かれていない領域がたくさんあるグラフィックを使っている時点で無駄が多いと思います。
空白の領域がそんなに沢山あるんでしょうか？

返信ありがとうございます。
沢山あります。
武器とキャラクターを分けていないので、武器を振るだけで無駄な空白ができています。

武器の中心点やら持ち手の中心点やらをアニメーション一枚ごとにちまちまと管理するのが大変そうなので・・・
しかも武器が斜め向いているだけで無駄スペースが・・・

普通はツールで自動的に最低限のブロックに自動分割させるんです。
読み込む前に加工しておけば、変な処理も入らないですし、５１２ｘ５１２の数枚の絵からDrawRectGraph()でパーツを抜きだして表示するのでVRAM上で高速処理が期待できます。ここで手を抜くと苦労した割に高速ではないと言うシロモノが出来がりますよ。

>格納したハンドル32×32の中に何も書かれていなければ（透過処理色が白のとき、真っ白とか）
という判断はどういった関数を使えばよろしいでしょうか

LoadSoftImageがありますが、ツールの加工時に使ったほうが良いです。

ありがとうございます！
>普通はツールで自動的に最低限のブロックに自動分割させるんです。
知りませんでした・・・。
これなら元画像に無駄な空白はほぼ無いですし、作るグラフィックハンドル数も節約できそうです！

とりあえずツール作ろうと思います。ありがとうございました！

[ISLe]

ちなみにLoadDivGraphは、元画像を1つのテクスチャとして作成し、各ハンドルは部分的に描画する実装になっているはずなので、一部のハンドルを解放してもビデオメモリの消費量は変わらないと思います。
元画像が2の累乗サイズでない場合はさらに複雑に分割されることになるでしょう。

[softya（ソフト屋)]

ツールの詳しい話は良かったのでしょうか？
自動的に画像を再現するための座標とパーツ番号をバイナリデータとかで吐き出さないといけませんが。

[コマンダーヤンマーク]

ツールの詳しい話は良かったのでしょうか？
自動的に画像を再現するための座標とパーツ番号をバイナリデータとかで吐き出さないといけませんが。

ご親切にありがとうございます。
ツールは自分なりに考えて作ってみようと思います。ちょっとおもしろそうなので。
生意気言っておいて助けを求めるかも知れませんが、そのときはよろしくお願いいたします。

ちなみにLoadDivGraphは、元画像を1つのテクスチャとして作成し、各ハンドルは部分的に描画する実装になっているはずなので、一部のハンドルを解放してもビデオメモリの消費量は変わらないと思います。
元画像が2の累乗サイズでない場合はさらに複雑に分割されることになるでしょう。

そうなんですか！？てっきり分割したサイズでテクスチャを作っているんだと思っていました。
ということは元画像を丸々LoadGraphでぶっこんでるのと変わらないんですね・・・。
道理でVRAM計算結果より大幅にオーバーしてたわけだ。
今までとんだ勘違いをしていました・・・。
お教えていただきありがとうございます！