Re: Android版:ChangeVolumeSoundMem ( No.1 ) |
- 名前:管理人 日時:2017/03/26 03:58
|
Re: Android版:ChangeVolumeSoundMem ( No.2 ) |
- 名前:ギウ 日時:2017/03/26 08:27
最新版を入れてリビルドして実機で実行したところ、画面が映らず、音も鳴らない状態になってしまいました。
どこでエラーが出てるか等はこれからですが、取り急ぎご報告ということで。
(Windows側は同じソースで普通に動いてます)
|
Re: Android版:ChangeVolumeSoundMem ( No.3 ) |
- 名前:ギウ 日時:2017/03/26 10:13
すみません、音は鳴ってました。(ただ、BGMが何故か鳴らないので、調査中です)
あと、画像が映らないのは、ReCreateGraphFromMem のせいかもしれません。
(昔のバージョンになってしまったとか?)
普通にDrawStringした文字は表示されました。
|
Re: Android版:ChangeVolumeSoundMem ( No.4 ) |
- 名前:ギウ 日時:2017/03/26 16:47
追記。
ReCreateGraphFromMemで -1 が返ってきていました。
その後のDrawGraphは 0 が返ってきます。
画面は黒一色か、概ね黒で上の方にゴミデータ的な線が表示されます。
(ReCreateGraphFromMemは全画面サイズのBMPで使ってます)
|
Re: Android版:ChangeVolumeSoundMem ( No.5 ) |
- 名前:管理人 日時:2017/03/26 20:56
お試しいただきありがとうございます
本件とは関係ないかもしれませんが、本日『横幅が奇数サイズの16bitカラーの画像が正常に読み込めない』という
バグ( LoadGraph や ReCreateGraphFromMem など画像読み込み全般に影響 )を修正しましたので、
こちらにその修正を行ったバージョンをアップしました
https://dxlib.xsrv.jp/temp/DxLibAndroidTest_ARM.exe // Android版 ARM用
よろしければお試しください m(_ _;m
ただ、↑このバグは ReCreateGraphFromMem が失敗する( -1が返って来る )原因となる類の物でもなく
私の環境では ReCreateGraphFromMem も -1 を返すことなく動作しているので、謎ですね…
お手数で申し訳ないのですが ReCreateGraphFromMem が
失敗してしまうという全画面サイズのBMPをアップローダー、若しくはメールでこちらまで
BQE00322(あっとまーく)nifty.com
( (あっとまーく)を@に置き換えてください )
送って頂けないでしょうか?
手元で -1 が返って来る状況を再現できれば原因はすぐに分かると思いますので m(_ _;m
|
Re: Android版:ChangeVolumeSoundMem ( No.6 ) |
- 名前:ギウ 日時:2017/03/27 12:53
有難うございます。
メールさせて頂きました。
よろしくお願いいたします。
|
Re: Android版:ChangeVolumeSoundMem ( No.7 ) |
- 名前:管理人 日時:2017/03/28 01:31
ありがとうございます
メールを拝見いたしました
何も表示されなくなった原因はDXライブラリのBMP読み込み処理にありました
少し前まで 16bit BMP のピクセルフォーマットの判定にバグがあったので、そのバグを修正したら
biCompression = BI_RGB + biBitCount = 16bit の BMP が読み込まれないようになっていました
( 修正を行う前はバグで判定が変になっていて、たまたま読み込む処理が行われ、たまたま問題ないような
動作をしてしまっていました )
『バグでたまたま読み込めてた』ではなく、正しく biCompression = BI_RGB + biBitCount = 16bit の BMP を
読み込むように処理を追加したところ、送っていただいたプログラムで生成された BMP を読み込むことが
できるようになりましたので、よろしければその修正を行ったバージョンをお試しください m(_ _;m
https://dxlib.xsrv.jp/temp/DxLibAndroidTest_ARM.exe // Android版 ARM用
ところで CBmp::Cls の中の 16bit BMP に対する処理の中で高速化のために 4バイト転送( 1ループで 2ピクセル転送 )を
行われていますが、BITMAPFILEHEADER の構造体サイズが2の倍数である関係で現在の BmpVram.cpp の処理では
2の倍数のメモリアドレスに対して4バイトの書き込みを行うことになってしまい、Releaseビルドをした場合
EXC_BAD_ACCESS が発生してエラー終了してしまいます( x86 の CPU と異なり、ARM の CPU は 2の倍数の
メモリアドレスに対して4バイトの操作を行うとエラーとなります( エミュレータ( 仮想デバイス )ではエラーになりませんが…
詳しくは Google などで『ARM アライメント EXC_BAD_ACCESS』などのキーワードで調べてみてください )、
なので、メンバー変数に
BYTE *buffer; // 確保メモリの先頭アドレス
のような、確保メモリの先頭アドレスを保存するための変数を追加した上で CBmp::Create の中のこちらの処理を
// 読み込み用メモリ確保
all_size = lSize1+lSize2+lSize3;
BITMAPFILEHEADER *bmfh = (BITMAPFILEHEADER *)new BYTE[all_size];
if(bmfh == NULL)
return -1;
このように変更して
all_size = lSize1+lSize2+lSize3+2; // 確保メモリを2バイト追加
BYTE *buf = new BYTE[all_size]; // bmfh に直接代入するのではなく、確保メモリの先頭アドレスを保存する方式に変更
if(buf == NULL)
return -1;
// BITMAPFILEHEADER の先頭アドレスを2バイトずらして、BITMAPINFOHEADER 以降の先頭アドレスが4の倍数になるようにする
BITMAPFILEHEADER *bmfh = (BITMAPFILEHEADER *)( buf + 2 );
ZeroMemory(buf,all_size);
buffer = buf; // 確保メモリの先頭アドレスを保存
CBmp::Free の処理のこちらの部分も
if(bmpFileHed)
{
delete[] bmpFileHed;
bmpFileHed = 0;
bmpInfoHed = 0;
}
このように変更する必要があります
if(buffer)
{
delete[] buffer;
buffer = 0;
bmpFileHed = 0;
bmpInfoHed = 0;
}
この変更をすることで BMP のイメージに対して4バイトアクセスをしてもアクセス対象のメモリアドレスが
4の倍数になるようになり、EXC_BAD_ACCESS のエラーは発生しなくなります
( 手元の Android の実機で Release ビルドで実行してもエラー終了しないようになりました )
よろしければお試しください m(_ _)m
 |
Re: Android版:ChangeVolumeSoundMem ( No.8 ) |
- 名前:ギウ 日時:2017/03/28 08:20
ご対応有難うございます!
無事に表示されました!
ARM アライメントの件も有難うございます!
かなりやばい状態だったんですね;
(私の実機だとリリースモードでもエラーにならないので、OSのバージョン(?)によって上手く管理してくれたりするのかも?)
発売してからエラー報告があっても、たぶん全く気付けないバグだったと思います。助かりました。
※上記のように修正しておきました。
それと、本題のChangeVolumeSoundMemの方ですが、音量調整できるようになりました。
ただ、Windowsとバランスがだいぶ違う印象なのですが、これは仕様やスピーカー等の影響ということで大丈夫でしょうか。
こちらの環境だと、効果音のボリュームが255の時、
BGMを、Androidの場合は230、Windowsの場合は170で丁度良い感じになりました。
(Androidの方が一気に音量が下がる印象です)
|
Re: Android版:ChangeVolumeSoundMem ( No.9 ) |
- 名前:管理人 日時:2017/03/29 02:15
> (私の実機だとリリースモードでもエラーにならないので、OSのバージョン(?)によって上手く管理してくれたりするのかも?)
あの後別の箇所では変わらずアラインを跨いでいた箇所があったことに気付いたのですが、私の環境でも
エラーが発生せず動作していました
なので必ずエラーが発生してしまうわけではないようです… ( そのコードを実行しても私の環境でもエラーは発生しない )
> それと、本題のChangeVolumeSoundMemの方ですが、音量調整できるようになりました。
> ただ、Windowsとバランスがだいぶ違う印象なのですが、これは仕様やスピーカー等の影響ということで大丈夫でしょうか。
すみません、Android版の音量反映処理の計算が誤っていました
修正しましたので、よろしければこちらをお試しください( 何度も申し訳ありません ) m(_ _;m
https://dxlib.xsrv.jp/temp/DxLibAndroidTest_ARM.exe // Android版 ARM用
あと、ReCreateGraphFromMem よりも高速にグラフィックハンドルの画像を更新する方法がありました
それは MakeARGB8ColorSoftImage などで作成できる『ソフトウエアイメージハンドル』を使用することです
『ソフトウエアイメージハンドル』は画像のビットマップ情報をシステムメモリ上に持つ機能で、
『グラフィックハンドル』とは異なり画像のピクセルにアクセスしたりすることが主な用途となります
( 『グラフィックハンドル』は画像のピクセルにアクセスすることができないので )
そして、『ソフトウエアイメージハンドル』の画像情報を『グラフィックハンドル』の画像として
転送するための関数として ReCreateGraphFromSoftImage があるのですが、こちらは
ReCreateGraphFromMem より高速に動作します( ReCreateGraphFromMem はBMP画像やPNG画像などをまず
『ソフトウエアイメージハンドル』の画像形式と同じものに変換して、その後 ReCreateGraphFromSoftImage と
同等の機能でグラフィックハンドルに転送するので、ReCreateGraphFromSoftImage を使用すると
『BMP画像やPNG画像などをまず「ソフトウエアイメージハンドル」の画像形式と同じものに変換』の
工程がまるまる省けるのです )
『ソフトウエアイメージハンドル』を作成する際はピクセルフォーマット別に呼ぶ関数が変化するのですが、
これまでのところ用意していた 16bitカラーの『ソフトウエアイメージハンドル』を作成するための関数が
// ソフトウエアイメージハンドルの作成( A4R4G4B4 カラー )
int MakeARGB4ColorSoftImage( int SizeX, int SizeY ) ;
の1種類しかなかったので、今回
int MakeA1R5G5B5ColorSoftImage( int SizeX, int SizeY ) ; // ソフトウエアイメージハンドルの作成( A1R5G5B5 カラー )
int MakeX1R5G5B5ColorSoftImage( int SizeX, int SizeY ) ; // ソフトウエアイメージハンドルの作成( X1R5G5B5 カラー )
int MakeR5G5B5A1ColorSoftImage( int SizeX, int SizeY ) ; // ソフトウエアイメージハンドルの作成( R5G5B5A1 カラー )
int MakeR5G6B5ColorSoftImage( int SizeX, int SizeY ) ; // ソフトウエアイメージハンドルの作成( R5G6B5 カラー )
の4種類を追加しました
『ソフトウエアイメージハンドル』がシステムメモリ上に確保した画像イメージ格納用のメモリアドレスは
// ソフトウエアイメージハンドルの画像が格納されているメモリ領域の先頭アドレスを取得する
void *GetImageAddressSoftImage( int SIHandle ) ;
↑こちらの関数で取得できますので、MakeX1R5G5B5ColorSoftImage などでソフトウエアイメージハンドルを作成した後、
戻り値のソフトウエアイメージハンドルを GetImageAddressSoftImage に渡して画像イメージが格納されているメモリアドレスを
取得して、そのメモリ領域に対して描画処理を行い、以下の ReCreateGraphFromSoftImage で
// ソフトウエアで扱うイメージから既存のグラフィックハンドルに画像データを転送する
int ReCreateGraphFromSoftImage( int SIHandle, int GrHandle ) ;
グラフィックハンドルの画像データを更新する、という方式にすると ReCreateGraphFromMem を使用した場合より
高速にグラフィックハンドルの画像を更新することができるようになります
因みに4つの 16bitカラーの『ソフトウエアイメージハンドル』を作成する関数の内、Android上で最も高速に
動作するのは MakeR5G5B5A1ColorSoftImage です
何故なら、 OpenGL ES 2.0 が対応している 16bitカラーフォーマットが R5G5B5A1 なので、
『ソフトウエアイメージ』の時点で R5G5B5A1 になっていると、ReCreateGraphFromSoftImage の際は
R5G6B5 → R5G5B5A1 や A1R5G5B5 → R5G5B5A1 といったピクセルフォーマット変換処理をする必要が無くなるからです
なので可能でしたら R5G5B5A1 フォーマットを使用してみてください m(_ _)m
( 手元のテストでは使用するソフトウエアイメージのピクセルフォーマットを A1R5G5B5 を R5G5B5A1 に
変更したところ処理時間が半分近くに短縮されました )
 |
Re: Android版:ChangeVolumeSoundMem ( No.10 ) |
- 名前:ギウ 日時:2017/03/29 10:20
新関数の追加有難うございます!
同じ条件でMakeR5G5B5A1ColorSoftImageを試したら、3msくらい速くなりました!
詳しいご説明も有難うございます!
因みに、”画像を操作した時”と”画像操作を何もしない時”で、ReCreateGraphFromSoftImageの速度差が倍くらい違ってました。
(操作した時の方が高速。キャッシュの影響とかなら問題ないですけど、一応、ご報告ということで)
あと、Windows版にもMakeX1R5G5B5ColorSoftImageやMakeR5G6B5ColorSoftImageがあると高速になるでしょうか。
(その場合、555なのか565なのかを判定する関数も必要に?)
--
ChangeVolumeSoundMemの方も修正版確認しました!
聴いた感じ、Windows版と同じ音量差になってると思います。
|
Re: Android版:ChangeVolumeSoundMem ( No.11 ) |
- 名前:ギウ 日時:2017/03/29 15:03
あ、Windows版のMakeX1R5G5B5ColorSoftImage等ですが、
需要はほとんど無い気がしますし、速度もそんなに違わないかもですので、後回しでも(又は無くても)大丈夫です。
私も困ってるわけではありませんので。
|
Re: Android版:ChangeVolumeSoundMem ( No.12 ) |
- 名前:管理人 日時:2017/04/02 14:26
 |
Re: Android版:ChangeVolumeSoundMem ( No.13 ) |
- 名前:ギウ 日時:2017/04/02 20:27
ご対応有難うございます!
>恐らくキャッシュの影響だと思います
了解です。
>MakeX1R5G5B5ColorSoftImage
おお。1.5msくらい速くなりました!
因みに、RGB565のビデオカードでMakeX1R5G5B5ColorSoftImageを使ってしまった場合、
「少し遅くなるけど、表示は問題ない」と考えて大丈夫でしょうか。
|
Re: Android版:ChangeVolumeSoundMem ( No.14 ) |
- 名前:管理人 日時:2017/04/05 23:25
> 因みに、RGB565のビデオカードでMakeX1R5G5B5ColorSoftImageを使ってしまった場合、
> 「少し遅くなるけど、表示は問題ない」と考えて大丈夫でしょうか。
はい、その通りです
|
Re: Android版:ChangeVolumeSoundMem ( No.15 ) |
- 名前:ギウ(解決) 日時:2017/04/06 15:38
了解しました。
有難うございます。
|