ads by Amazon

2013年4月10日水曜日

3. エミュレータで音を鳴らす仕組み

VGSは、エミュレータの仕組みを応用した仮想ゲーム機です。そのため、音声発音システムの実装は、エミュレータのアーキテクチャを参考にして実装しています。なので、mameのソースコードを見れば、だいたいどんな仕組みで実装すべきか分かると思います・・・ただ、それが難儀なことだから、この仕組みで実装できない人の方が多いのであろうと思います。
エミュレータの場合、細かい時系列単位(だいたい50ms~100ms間隔)で、リアルタイムな計算により音声波形データを生成して、それを音源デバイスに書き込み続ける形で音声システムが実装されています。つまり、音が全く鳴っていない状態であっても、「無音」の波形データ(0が連続した配列)を発音しています。

(1)Windows
Windowsの場合、DirectX(DirectSound)と標準のWaveMapperのどちらでも、一定時間間隔で任意の波形データを発音できる仕組みがあります。なので、どちらの仕組みを使っても実装可能ですが、VGSの場合はDirectSoundを使っているので、DirectSoundを用いたエミュレータの発音システムの実装を解説していきます。

(2)Android
Androidの場合、Android 2.3.3以降から提供されるようになったOpenSL/ESを用いることで、コールバックにより一定時間間隔で任意の波形データを発音できる仕組みを実装できます。なお、OpenSL/ESはJavaでは使えません。そのため、ゲーム本体をJavaで実装する場合であっても、音声発音の部分はC言語(JNI)で実装する必要があります。

(3)iPhone
iPhone(iOS)の場合、OpenALを用いることで、DirectSoundと似たような実装方法により、一定時間間隔で任意の波形データを発音できる仕組みを実装できます。

(4)アンマネージド・コードのプラットフォームは除外
当初、私はVGSをメトロにもポーティングしようと考えていた時期もありました。しかし、メトロの場合、XAMLでC言語での実装が可能ですが、.NET frameworkアーキテクチャみたいな感じのマネージドコードと呼ばれる仕組みの上で実装しなければなりません。
音声波形は、リアルタイムな演算により算出しなければなりません。そのため、アンマネージドコード(Nativeコード)で実装しなければ、とてもじゃないけど演算速度が追いつかないです。なので、メトロを切りました。
当然、HTML5(FireFoxOSとか?)やJavaスクリプトみたいなものも、現時点のモバイル機器では、実用に耐え得る性能を確保することは不可能です。HTML5等は、ライトゲームを作るだけなら問題無い程度ですが、並行してリアルタイム波形演算をできる程度の性能は確保できません。
ドラゴンボールのように、CPUの戦闘能力がインフレーションしていた時期(10年ぐらい前)であれば、「今はダメだけど将来は・・・」という期待を持てましたが、省電力などの関係からハードがチープ化している現状から、「マネージドコードで何でもできる」という時代は、まだまだ先のことであろうと想定しています。当面、モバイル機器対応のゲームを作るには、Nativeコードをサポートしているプラットフォームしか選択肢はありません。メトロやHTML5等の存在を否定する訳ではありません。しかし、メトロやHTML5は、少なくともこのブログで紹介する音声発音方式に耐え得るプラットフォームではありません。
Androidですら、仮に「Javaだけ」だったら対応不可能でした。(AndroidでNativeを解放したのは、当初のプラットフォーム思想からは外れた行為でしたが、結果的には良かった事だったと私は評価しています)

なので、このブログで紹介する音声システムで対応できるプラットフォームは、
・Windows(デスクトップアプリ)
・Android
・iPhone
に絞ります。

0 件のコメント:

コメントを投稿