トップページ > 記事閲覧
Android版:ChangeVolumeSoundMem
名前:ギウ 日時: 2017/03/24 07:30

いつもお世話になっております。 Android版で、 メモリに読み込んだ音データを、ChangeVolumeSoundMem で音量調整しても、音量はデフォルトのままでした。 (戻り値は 0 です) 同じプログラムをWindows版で動かすと、正常に機能しています。 ご確認お願いいたします。
メンテ

Page: 1 |

Re: Android版:ChangeVolumeSoundMem ( No.1 )
名前:管理人 日時:2017/03/26 03:58

ご指摘ありがとうございます 少し前に修正した「6個目のサウンドハンドルから再生しても音が鳴らない」バグを修正した際に 音の再生に関する処理を変更したのですが、その影響で ChangeVolumeSoundMem の音量の変更が 反映されないようになっていました 修正版をアップしましたので、よろしければお試しください m(_ _;m http://dxlib.o.oo7.jp/temp/DxLibAndroidTest_ARM.exe // Android版 ARM用
メンテ
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 など画像読み込み全般に影響 )を修正しましたので、 こちらにその修正を行ったバージョンをアップしました http://dxlib.o.oo7.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 http://dxlib.o.oo7.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 http://dxlib.o.oo7.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

音量が正しく変化するようになり、処理も高速になったようで何よりです > 因みに、”画像を操作した時”と”画像操作を何もしない時”で、ReCreateGraphFromSoftImageの速度差が倍くらい違ってました。 > (操作した時の方が高速。キャッシュの影響とかなら問題ないですけど、一応、ご報告ということで) ご報告ありがとうございます 画像を操作したときとしていないときで行う処理を分岐するといったことはしていないので、 恐らくキャッシュの影響だと思います > あと、Windows版にもMakeX1R5G5B5ColorSoftImageやMakeR5G6B5ColorSoftImageがあると高速になるでしょうか。 > (その場合、555なのか565なのかを判定する関数も必要に?) はい、例えば MakeARGB8ColorSoftImage だと 1ピクセル 4バイトですが、MakeX1R5G5B5ColorSoftImage や MakeR5G6B5ColorSoftImageでは 1ピクセル 2バイトになるので、アクセスするメモリ容量が抑えられる分だけ高速になります ( GetImageAddressSoftImage で取得できるビットマップメモリへのアクセスが多ければ多いほど MakeARGB8ColorSoftImage との 処理時間に差が表れると思います ) 今回の変更は Android版限定ではありませんので、よろしければ Windows版でも MakeX1R5G5B5ColorSoftImage や MakeR5G6B5ColorSoftImage を お使いください m(_ _)m http://dxlib.o.oo7.jp/temp/DxLibVCTest.exe // Windows版 VisualC++ 用 http://dxlib.o.oo7.jp/temp/DxLibBCCTest.exe // Windows版 BorlandC++ 用 http://dxlib.o.oo7.jp/temp/DxLibBCC2Test.exe // Windows版 C++ Builder 10.1 Berlin 用 http://dxlib.o.oo7.jp/temp/DxLibGCC_MinGWTest.exe // Windows版 MinGW 用 http://dxlib.o.oo7.jp/temp/DxLibDotNet.zip // Windows版 .NET用 http://dxlib.o.oo7.jp/temp/DxLibMakeTest.exe // ソース (中身を既存のライブラリのファイルに上書きして、BCCをお使いの 場合は『再構築』を、VCをお使いの場合は『リビルド』をして下さい)
メンテ
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

了解しました。 有難うございます。
メンテ

Page: 1 |

題名
名前
コメント
パスワード (記事メンテ時に使用)

   クッキー保存