HSPTV!掲示板

HSP3dishでbufferに
一度画像をロードをし、描画をして
又、同じバッファに画像をロードして描画すると
Windowsでは正常に描画されるのですが、Android上ではアプリが強制終了してしまいます。
Bufferを初期化しても同じでした。

仕様かと思われますが、
別のバッファや同じバッファで一度読み込んだ、
同じ画像をロードした場合は正常に動作するようです。

過去ログで画像サイズを1024以下にしないと一部の端末で動かない等という情報もありましたが
他の画像は1024を超えていますが、正常にロード出来る模様です。

Androidではbufferで仮想画面が３つまでしか使えない機種もあるようなので、
どうすれば、バッファを上書き又はクリア等で一新して使う事が出来るのでしょうか？

#include "hsp3dish.as"



redraw 0
gosub *load_BG
gosub *draw_BG;　gosub先は省略しています。celputがあります。
gosub *load_titlebutton
gosub *draw_titlebutton;　gosub先は省略しています。celputがあります。
redraw 1

*load_BG
celload "BG.jpg",2
celdiv 3,1920,1080
return

*load_titlebutton;タイトルボタンの画像を読み込み
	buffer 2,928,1296
	gsel 0
	celload "Title_Button.png",2
	celdiv 2,928,216;縦216で6分割
return

または

*load_titlebutton;タイトルボタンの画像を読み込み


	celload "Title_Button.png",2
	celdiv 2,928,216;縦216で6分割
return

1024ではなく　2048x2048　です。
マニュアルのどっかに書いてなかったかなーって。

その３枚までというのはうちでの検証結果ですが、
バッファに再度ファイルからロードすると同じように変になることがあります。
なので、もうこれは現状の仕様だと諦めて私のところでは
1枚 2048x2048を最大サイズとして、プログラムの最初に３枚までバッファに読んだ後は
一切書き換えをしない、という仕様で作成しています。

HSP3Dish android(NDK)版プログラミングガイド　から引用：

> 画像サイズについて
> celload、picload命令などで読み込まれる画像の縦・横サイズが、2048を越えるものについては、
> 正しく扱えない機種もあるので、推奨されません。

HGIMG4のようにPVRTCのような圧縮テクスチャに対応するのはどうでしょう？
また目的次第ですがAndroid2.x世代のハードのシェアは5%程度なのでそろそろ無視するか別途低解像度版で対応するって手も。

なるほど、Android 4.0〜だと 4096x4096 も扱えるという情報が。
上記のようにマニュアルにあったので2048までにしていましたが、
Android 4.0〜に限定すればもっといけそうですね。
実機で動作検証して問題無い＆大きな画像を必要とするケースの場合は
試してみます。

窓月ららさん＞
公式で2048x2048と発表しているのは存じておりましたが、
過去ログに1024と書いている人もいたので気になり、
強制終了する以前も、1024を超え2048未満の画像を使っていたので
関係ないと思いましたが、一応ながら、記述致しました。

zakkiさん＞
私はHGIMG4をincludeして、スクリプトを書いたことがないので良くわからないのですが、
PVRTCという圧縮方式の画像をHSP3Dishでも、公式もしくはモジュールで使えるのでしょうか？
ちなみに私は開発用に知人から借りている、
化石スペックのXperiaでAndroid2.3.4の端末しか持っていないのですが、
1024を超えた画像を扱えています。
（もしかしたら、低解像度はそういう意味ではないのでしょうか？）

PVRTC対応はhgtex.cppやhspwnd_dish.cppなどlibhsp3dish側を変更するのを想定してました。
スクリプトやモジュールで対応するのは無理かすごく大変だと思います。

> 化石スペックのXperiaでAndroid2.3.4の端末しか持っていないのですが、
> 1024を超えた画像を扱えています。
バッファの3枚っていうのがどこから来る制限なのかによるんですが、まずメモリについて考えてみます。

Android 2.xだと1プロセスが使えるメモリは16MB〜64MB程度のようです。
http://stackoverflow.com/questions/5350465/android-heap-size-on-different-phones-devices-and-os-versions

ところが2048x2048のARGBテクスチャ3枚ととUXGAのサーフェース前後2枚で60MB以上消費します。
4Byte*2048*2048*3+6Byte*1280*1024*2=63MB

元の画像ファイルサイズ分のメモリも読み込み時には使いますし、当然画像以外にもメモリを使うことを考えると限界超えます。
ここで画質落として1028x1028のテクスチャにすると同程度のメモリ消費で12枚使えるはずです。
また圧縮テクスチャだとテクスチャサイズが1/4〜1/16程度になるようなので同じく扱える画面数増えそうです。
＃概算なのでと他にも制限はあるはずなのでピッタリとはいかないでしょうけど

その３枚というのはメモリはあまり関係無さそうな雰囲気なんですよね。
すごく小さな画像でも同じなんです、とにかく枚数だけが引っかかる。
Androidのバージョンは 4.0.3以降でのみ確認。
どこで問題が起きてるのか今のところ不明なんですけど。

画像の圧縮はJPGやPNG等で画質と容量のバランスを考えつつ、可能な限り高圧縮を施しているので
今のところ1.85MB以下です。
もしかして、VRAMに読み込む時に未圧縮画像として展開され、
未圧縮BMPと同じような容量になるのなら、関係ないのかもしれませんが。

>> 窓月ららさん
メモリ以外のところに制限あるんですか。何処で引っかかってるのか謎ですね。

>> 空気さん
圧縮テクスチャは圧縮状態でメモリ上に置かれますが、PNGやJPEGはディスクやダウンロードサイズの節約にはなりますがメモリにロードするタイミングではおっしゃるように展開されます。