「MonoGameでBGMを再生する」の版間の差分

提供:MonoBook
編集の要約なし
 
(6人の利用者による、間の7版が非表示)
1行目: 1行目:
==問題点:Songクラスが不安定==
==問題点:Songクラスが不安定==
2016年1月時点の[[MonoGame]]でBGMを再生するのは色々と難しいようだ。
2016年1月時点の[[MonoGame]]でBGMを正攻法で再生するのは色々と難しいようだ。


* [[MonoMac]]では「Content.Load<Song>メソッド」でクラッシュする。
* [[MonoMac]]では「Content.Load<Song>メソッド」でクラッシュする。
16行目: 16行目:
[[ググって]]みた結果、以下の[[コード]]で動くような気がするが、[[stackoverflow.com]]によると内部実装に色々と問題があるのでSongクラスは使うなとのこと<ref>http://stackoverflow.com/questions/19411922/song-doesnt-play-all-the-time-in-monogame</ref>。
[[ググって]]みた結果、以下の[[コード]]で動くような気がするが、[[stackoverflow.com]]によると内部実装に色々と問題があるのでSongクラスは使うなとのこと<ref>http://stackoverflow.com/questions/19411922/song-doesnt-play-all-the-time-in-monogame</ref>。
<source lang="csharp">
<source lang="csharp">
            var song = Content.Load<Song>("heaven_BGM_tougou");
var song = Content.Load<Song>("heaven_BGM_tougou");
            MediaPlayer.IsRepeating = true;
MediaPlayer.IsRepeating = true;
            MediaPlayer.Play(song);
MediaPlayer.Play(song);
</source>
</source>


24行目: 24行目:
stackoverflow.comの指示に従い、BGM用のSongクラスとMediaPlayerクラスではなく、効果音用のSoundEffectクラスを使うことでクラッシュ自体は避けられることを確認した。
stackoverflow.comの指示に従い、BGM用のSongクラスとMediaPlayerクラスではなく、効果音用のSoundEffectクラスを使うことでクラッシュ自体は避けられることを確認した。
<source lang="csharp">
<source lang="csharp">
            var song = Content.Load<SoundEffect>("heaven_BGM_tougou");
var song = Content.Load<SoundEffect>("heaven_BGM_tougou");
            var backSong = song.CreateInstance();
var backSong = song.CreateInstance();
            backSong.IsLooped = true;
backSong.IsLooped = true;
            backSong.Play();
backSong.Play();
</source>
</source>


33行目: 33行目:
ただしSoundEffectクラスを使う方法ではMonoGame Pipelineで生成されるxnbファイルがアホみたいに巨大になる。約3MBのmp3ファイルが約30MBのxnbファイルになるくらい。MonoGame PipelineでQualityプロパティをBestからLowに変えてもファイルサイズに変化はない。
ただしSoundEffectクラスを使う方法ではMonoGame Pipelineで生成されるxnbファイルがアホみたいに巨大になる。約3MBのmp3ファイルが約30MBのxnbファイルになるくらい。MonoGame PipelineでQualityプロパティをBestからLowに変えてもファイルサイズに変化はない。


===回避策:音質を落としたwavを使う===
====回避策:音質を落としたwavを使う====
ファイルがデカイ理由はMonoGame Pipelineにmp3を食わせると最高音質でwavに変換しているためのようだ。
ファイルがデカイ理由はMonoGame Pipelineにmp3を食わせると最高音質でwavに変換しているためのようだ。


40行目: 40行目:
事前に音質を落としたwavファイルをMonoGame Pipelineに食わせると良いようだ。
事前に音質を落としたwavファイルをMonoGame Pipelineに食わせると良いようだ。


==関連項目==
===問題点:ARM64でクラッシュする===
MonoGame 3.3および3.4かつ[[Android]]かつ[[ARM64]]でSoundEffectクラスを使おうとするとクラッシュする。
 
====回避策2:MonoGame 3.5以降を使う====
この問題はMonoGame 3.5で修正されている。
 
====回避策2:ARM v7aを使う====
MonoGame 3.5にアップデートするとこの問題は治るが、今度は[[3DCG]]の[[レンダリング]]周りで従来と異なる挙動になるなど不用意にアップデートできるものではなさそうだ。


==参考文献==
そのような場合はMonoGame 3.3などの古いバージョンを使い続け、そのうえでプロジェクトのプロパティから[[ARM64]]のチェックをはずして[[ARM v7a]]向けにビルドすることで回避できる。そもそも[[Android]]で[[ARM64]]を使うメリットなど何一つないと思われる上に、簡易的な[[ベンチマーク]]でサクッと測った限りでは速度的な差もない。
{{reflist}}
現状ではARM64だと[[LLVM]]での最適化も効かないので本当に何のメリットもないと思う。


{{stub}}
==関連項目==
* [[Xamarin.Androidで画面の向きを固定する]]


[[category:MonoMac]]
[[category:Xamarin.Android]]
[[category:Xamarin.Android]]
[[category:MonoGame]]
[[category:MonoGame]]

2021年4月20日 (火) 07:16時点における最新版

問題点:Songクラスが不安定[編集 | ソースを編集]

2016年1月時点のMonoGameでBGMを正攻法で再生するのは色々と難しいようだ。

  • MonoMacでは「Content.Load<Song>メソッド」でクラッシュする。
  • Androidでは「MediaPlayer.Playメソッド」でクラッシュするらしい。
    手持ちのGL07Sは問題ないが、最新鋭のNexus 6PNexus 9などでは不具合報告が続発。動く機種と動かない機種があるらしい。
    • 動かない報告のあった機種
      • Nexus 6P
      • Nexus 9
      • MOTOROLA XOOM Wi-Fi TBi11M
      • Redmi Note 3
    • 動く報告があった機種
      • AQUOS PHONE Xx 302SH
      • Xperia ZL2 SOL25

ググってみた結果、以下のコードで動くような気がするが、stackoverflow.comによると内部実装に色々と問題があるのでSongクラスは使うなとのこと[1]

var song = Content.Load<Song>("heaven_BGM_tougou");
MediaPlayer.IsRepeating = true;
MediaPlayer.Play(song);

回避策:SoundEffectクラスで代用する[編集 | ソースを編集]

stackoverflow.comの指示に従い、BGM用のSongクラスとMediaPlayerクラスではなく、効果音用のSoundEffectクラスを使うことでクラッシュ自体は避けられることを確認した。

var song = Content.Load<SoundEffect>("heaven_BGM_tougou");
var backSong = song.CreateInstance();
backSong.IsLooped = true;
backSong.Play();

問題点:ファイルがでかい[編集 | ソースを編集]

ただしSoundEffectクラスを使う方法ではMonoGame Pipelineで生成されるxnbファイルがアホみたいに巨大になる。約3MBのmp3ファイルが約30MBのxnbファイルになるくらい。MonoGame PipelineでQualityプロパティをBestからLowに変えてもファイルサイズに変化はない。

回避策:音質を落としたwavを使う[編集 | ソースを編集]

ファイルがデカイ理由はMonoGame Pipelineにmp3を食わせると最高音質でwavに変換しているためのようだ。

試しにステレオ44kHzのmp3ファイルをモノラル8kHzのwavファイルに変換(約8MB)したものをMonoGame Pipelineに食わせてみたところ、wavファイルとほぼ同じサイズのxnbファイルが生成された。なお変換にはMediaHuman Audio Converter[2]を使った。

事前に音質を落としたwavファイルをMonoGame Pipelineに食わせると良いようだ。

問題点:ARM64でクラッシュする[編集 | ソースを編集]

MonoGame 3.3および3.4かつAndroidかつARM64でSoundEffectクラスを使おうとするとクラッシュする。

回避策2:MonoGame 3.5以降を使う[編集 | ソースを編集]

この問題はMonoGame 3.5で修正されている。

回避策2:ARM v7aを使う[編集 | ソースを編集]

MonoGame 3.5にアップデートするとこの問題は治るが、今度は3DCGレンダリング周りで従来と異なる挙動になるなど不用意にアップデートできるものではなさそうだ。

そのような場合はMonoGame 3.3などの古いバージョンを使い続け、そのうえでプロジェクトのプロパティからARM64のチェックをはずしてARM v7a向けにビルドすることで回避できる。そもそもAndroidARM64を使うメリットなど何一つないと思われる上に、簡易的なベンチマークでサクッと測った限りでは速度的な差もない。 現状ではARM64だとLLVMでの最適化も効かないので本当に何のメリットもないと思う。

関連項目[編集 | ソースを編集]