thaseponのチラシ裏

気が向いた時や詰まっていたバグなどを解決した時に書いたりしてます。twitter : twitter.com/thasepon1023

Unity開発時のC++DLL作成の際の注意点

あまりに暑くてプログラムを組む気力がごりごり減ってるはせぽんです。
かといって何もしないのもどうかなと思ったのでブログを書こうかなと…

今回の話は
Unity(C#)からdll(VS C++)の関数呼び出しについて
のお話。

まず基本的な情報に関しては凹みさんの
tips.hecomi.com
を見れば解決すると思います。

じゃあなんで記事書いたの?ってなるのですがマーシャリングやら文字列やらで詰まったのでそれについて少し書こうかなと

そもそもマーシャリングって何?

ってなると思うのですがC#C++間の橋渡しのようなもの、だと個人的に思っています(違う可能性もあります)。
確かに冷静に考えれば言語が違うのに通じるわけはないので何かしらする必要がある(英語から日本語へ通訳みたいな)とは思いましたが。

マーシャリングの壁?
一応色々あったにはあったのですが今回は特に思い出深い内容を

マネージ コードからのネイティブ関数の呼び出し

こちらは対応表になっているのですがdll側はunicodeで作っていたので、[文字列を 2 バイトの Unicode 文字列 LPWStrでマーシャリング ]という例に習って作ったのですが、まぁ、これがとても面倒だったんですよね。

それが
ワイド文字 - Wikipedia ここの内部表現に書いてあるのですが。

しかし、Windowsでは16ビット (UTF-16)、LinuxmacOSでは32ビット (UTF-32) であるため、その他の環境でもUnicodeを用いた符号化形式であると誤解されて、あるいは仮定してプログラムが作られることがある。

えぇ…('ω' )

これが大体の元凶です、こういう事が初めてだった私にとって「何言ってるんだ?」って感じでした。

一応解決へ・・・

このことをtwitterでつぶやいたところ
twitter.com さんから様々な情報が、色々あるのですが大まかには

  • Unityは.NetではなくMonoである
  • P/Invokeでstring(C#)をconst char*(C)に変換するとUTF-8
  • 上で書いた環境ごとの差

などの話をしました、ここでさらに
twitter.com
さんの参戦により解決は加速します

その答えは


という事でした


難しいね!プラグイン作成!
(ここまで話はしましたけどひとまず私はwchar_t使ってます、ちゃんと直さなきゃ)

OpenAL-Soft+Unity

おはようございます、はせぽんです。

細々と続けてやっとファーストステップを迎えることが出来ました、色々やっていたら月が2回も変わってしまった…

そして内容なのですが…
github.com

を見てください、としか言いようがないんですよね。
openalを使用してdll化してUnityで再生しただけといってしまえばそれだけなので

作っていく上で色々困った点など沢山あったのですが、それはある程度纏まったらという感じで…

ずっとゲームやってました

どうもお久しぶりです、はせぽんです。

新社会人の準備をしたりゲームをしてたらこんな時期になってました。時の流れが速すぎる…

本題

早速ですが今回やったことはこれです。
youtu.be

ちょっと音がガバっているところがあるのですがまぁ…
これ何をやっているかというと足の裏に小さなコリジョンをつけまして~
f:id:thasepon:20180401161259p:plain

このコリジョンが何かに接触した際に自動で音が鳴るって感じになってます。
一応この接触した際にベクトルの速度を測っているのでWwiseのRTPCとかにそのまま適応することも出来る状態です。

ではこの設定をどこでやっているのかというと

<SoundList>
 <Header>
  <Title>Test Data</Title>
  <Subtitle>Soundinfo Test</Subtitle>
  <Date>2018/3/28</Date>
 </Header>
<SoundData>
 <Foot ID ="0">
  <Sand>
   <ID>0</ID>
   <SoundName>SandFoot</SoundName>
   <Material>Sand</Material>
  </Sand>
  <Grass>
   <ID>1</ID>
   <SoundName>GrassFoot</SoundName>
   <Material>Grass</Material>
  </Grass>
 </Foot>
</SoundData>
</SoundList>

こんな感じで管理しています、いろいろ拡張できないと困るのでこういう風にしました。
ただこれ手打ちなのでそのうちこれを作るためのツールをまた準備しないとなぁって思ってたり

まぁそれはいつか別の機会にやるとして、今回の中で大事なのはSoundNameとMaterialの部分です

SoundNameについて

SoundNameは言わずもがな使用する音声ファイルの名前です、同一じゃないとダメです。
インスペクタ内にAudioClipのリストがありそこに使用音声を入れる事で初めて動作します。
ただ、どのclipを使用するかを内部で選別しているので同名でないとダメという状態になってます。
f:id:thasepon:20180401161509p:plain
(こんな感じです)

Materialについて
これはゲーム内のオブジェクトについているマテリアルの名前です。
その音声がどのマテリアルに触れたときその音がなるというのを判断する部分になってます。
今回ですと茶色が土、緑が草ということでマテリアルを設定しているのでこの音が鳴ります。
この属性はいくつもつけることが出来るようにもなってます。
なので鉄の床やコンクリートでも簡単に設定できるかなぁって思います。

その他
ここでは足音で使用してますが武器が何かに当たった時や物を投げつけたときなどにも利用できて、今回は使用してませんがベクトル数値を使用することによってどの程度の強さで物を投げたかの状態毎にいろいろ出来ると思います。

終わりに
これをこのまま強化しつつ色々なことをやっていこうと思っています。
特にCEDEC2017ではいくつもやってみたいことがあったのでそれを実装してみたいなぁとか、後外部ツール作らないとなぁとか色々あります。
社会人になり時間がどの程度とれるかもわからないので何とも言えないのですがこれからも更新できるといいな('ω')とか考えたり考えなかったり。

最後になりますが、ここまで読んでくださった皆さんありがとうござました!

更新することが特になかったので

こんちわっす!はせぽんだよ~

 

はい。ということでね、タイトルの通り書くことなかったんですが更新しないのもなぁ…と思ったのでプラットフォームというかライブラリ周りなどの話でもしようかなと思います。

 

皆さんはゲームやアプリなどを開発する際どんなサウンド環境で制作をしているのでしょうか?そんな悩みの話です。

 

とりあえず環境などは考えないである程度上げていこうと思います。

 

まず最初に XAudio2 ですね、今のところは自分にとって一番身近なものです一応XACTというものが後継であるんですけどwikiを見ると廃止されているらしいんですよね、あれビジュアルベースで色々いじれてよかったのに…

廃止されたものの話はさておいて好きなところ、嫌いなところも書いていこうと思います、まず嫌いなところから。

これがというかこれに限るんですが「デバッグが死ぬほど面倒」これに限ります、しっかりとルールに従って使用すれば特に問題はないはずなんですけどバグが出るとXAudio2_7.dllに飛ばされて原因がわからなくて死にたくなることが多々あります、未だに意味が分からないバグとしてSetvolume()を使用すると解放時にエラーを吐くとかいうものですこんなのもあったりします。

好きなところは様々な勉強が出来るところです。

.wavの構造って?種類って?oggの読み込みって?同一リソースからサウンドを使いまわすためには?各エフェクトってどういう仕組みなの?とか書きだすと沢山あります、これらは間違いなく力になるでしょう。

 

次に OpenAL です、私はそんなに触ってはいないのですが…どうなんでしょうかね(丸投げ)?というのもパっと調べた感じ約7年ほど前に更新が止まっているんですよね~、XAudio2もdllが_9(win10用)が存在していて更新はされているんですが…まぁXAUDIO2_9.DLL,なんて使おうものなら10より前のOSのユーザーに切れられそうですけど。

 

 

次からはちょっと変わってミドルウェアについてです。

まずは日本産の CRI ADX2 リンク先に飛ぶと恐らく皆さん一度は見たことのあるマークが出てくるのではないでしょうか、採用タイトルも多く幅広いマルチプラットフォーム、欲しい物に合わせてしっかりと選べるタイプなど充実しています、ライセンス周りがちょっと面倒ですが。

使ったのはADX2LEですが導入に面倒なこともなくUIのおかげで操作が直感的に出来るのでとても扱いやすい物だと思います。

 

最後は最近日本でよく見るようになった?気がする Wwise です。

PUBGやNieR : Automata、Witcher、overwatchなどハイエンドコンテンツが目立つ気もしますが様々なタイトルに導入されているミドルウェアエンジンです。

今絶賛勉強中なので詳しいことはおそらく後日ですがCRIとの差を簡単に言うと、個人的にはプラグインの差だと思います。

SDKが公開されていて足りない機能を自分で補う、構築できるのが最大の強みだと思います。先日発表のあった

developers.google.com

WWiseプラグインとしても登場しています、他にもライセンス料を別途で払うことでプラグインを購入するなどマーケットのようなシステムもあります、ただその分時間はかかりがちです。

所々が英語だというのも時間がかかる原因の一つですが。

ただ色々な意味で幅広く扱えるのかなぁ…って思ってます。

 

とまぁ色々なものについて感想を言いました、触っている時間に差があるので公平じゃない気もしますがこんなところです。

UnityやUE4などについてる既存のサウンドについては…まぁ…詰めるとこまで詰めれば結局自分でやらないとダメなんじゃないかなぁって思います。

 

長文になっちゃいましたけど読んでくれた方には感謝です‼

まったね~

 

<追記~>

このブログを書いた後とある方と話をしました、どうやらそこでは各環境に合わせた低レイヤー層のapiを叩いてるらしいです、ほんとにたまげた…

 

<またまた追記>

ちょっとどうしても書きたいことがあったのでもう一回

じゃあどの環境がいいんだ!って感想も出ると思います、まず労力などを考えないのであれば間違いなく各プラットフォーム、環境に合わせた低レイヤーのAPIを叩くのがいいです、これは間違いないと思います。ですが現実はそうはいかないのが大半だと思います、ではそうなった場合どれを選ぶのか?私であればWwiseを選ぶと思います。

1.プラグインが多種多様に存在していてこれからも増えていく、また自分でも作ることが出来るため

2.他にも同様のことが言えるものもあるが幅広くプラットフォームに対応している

3.有名なゲーム講演動画が多数ある

なんかは理由としてしっかり言えると思う。

ただゲームにおいてのサウンドというのはゲームそれぞれに合わせた変化が少しずつ必要になってくる、これはゲームに限った話やサウンドだけではないと思うけど

そうなったとき一番強いのは自社ライブラリなどの低レイヤーから生成したものだ、ただ事はそうもいかない、そもそもそんな開発がすべての会社で出来ればこんな事は書いたりしない、そうなったとき次にどこがいいとのかという話だ。

そこでpluginやコミュニティ開発のあるWWiseがいいと思うというお話。このご時世ある程度自由が利かないと厳しいしね

 

サウンドプログラマってなんぞ?

このタイトルは2017年の前半の私の感想です。

ちなみに私自身サウンドプログラマじゃないです、独学で勉強してただけです、なので必ず間違いはあります('ω')

 

ただ割と色々見て、調べて私なりの答えを見つけたのでブログに書こうと思います、もしかしたらこれから興味を持った人がより速いスタートをきれるように。私はめちゃんこ遅かったです。

 

まずサウンドプログラマという職業そのものについてです、会社によってはサウンドデザイナーが一緒にやっているところもありそうですがサウンドデザイナという名前でなくサウンドプログラマという職業がある以上別の物だと思います。

 

じゃあ何するのか?簡単な言い方をすると「音を制御する」事だと思います、かっこいい言い方をすると操るという事。作曲者とはまた別だと思うよ!

 

ただその中でも様々なものがあると思います、空間音響・インタラクティブサウンド・VR音響などなど…この辺がどういうものであるかは CEDiL や CRI Middleware 、Wwise | Audiokinetic なんかで調べてくれればなんとなくわかると思います。

 

そしてこの辺を調べていくとツールを制作する事になるんじゃないかな、うん

もちろんミドルウェアを使用してというのもありだと思うのですが自前で作れるようにした方がいい、少なくともプラグインくらいは作れるようにした方がいい。というかそのうちほしくなる。

 

あとサウンドプログラムというだけあってプログラムは組めないとダメです、これは間違いなくそう。エフェクトなんかを組むというよりかはもっと、こう、プログラム的な部分で使います、空間音響のエフェクトレベルをどのように変化させるのか、小物の音を鳴らすためにはどうするのか、空間を表現するための方法などなど。結構使います。

 

とまぁ色々書いてきましたが注意するべきところが一つ。

ぶっちゃけるとゲーム本体の制作とはちょっと離れていると思います、AIやシェーダーのようにプレイヤーに直接かかわってくる部分でもないし人によってはミュートでゲームをプレイする人もいるでしょう、ただそれでもサウンドプログラムが楽しい、サウンドを120%の能力を出したい、これからはVRだ!よりリアルなサウンドを!という方は間違いなく向いてます、折れずに組みましょう。

 

 

 

あ、そうだ。じゃあ明確に何をすればいいの?って方にこの言葉を送りたいと思います。

 

教材なんかは

 

では!

 

追記 ) 

github.com

一応少しは見れる部分もあると思いますのでもしよければどうぞ、

これからもサウンドプログラムの勉強はするのでなにかあれば情報があればTwitterなりブログなりでお願いします。

e-sportsという単語

ほんとに個人的でどうでもいいことも書くよ!ということで

 

今日もやるべき事とやりたい事の狭間で悶々としていた私なのですがふとこんなワードを見つけた。

VR x e-Sports

という単語、始めて見た(考えたことはあったが)のでちょっと突っ込みというか野暮なことを書こうと思う。

PvPというなら特に記事はしなかったと思うけど「e-Sports」という単語だったので。

個人的にe-Sportsというのは「プレイする人」と「それを観戦する人」がいて初めてe-Sportsというコンテンツにまで昇華できると思っている。

LoL格闘ゲームFPS(順不同)のジャンルがあるがこれらにはある程度の共通点があると思っている、それは「プレイヤーの入りやすさ」だと思っている。

敷居の高さではなく、あくまで入りやすさという事。FPSe-Sportsと消化されているものやMOBAなんかもそうだがある程度スペックの低いpcでやれるゲームが多い、さらには漫画喫茶みたいな場所でもアカウントがあればプレイが出来る。これはとても大事だと思う。現状VRにはこれがない、動かすPCを買うのに数万、機材に数万、コミュニティが出来上がる前にゲーム運営が耐えられるのか?スタープレイヤー(senpaiのような)は生まれるのか?など色々な問題がある。

とまぁここまでどっちかというとマイナスなことを書いたがこのご時世どうなるかなんていうのはわからないしどのようなゲームに作り上げるのかなど凄く楽しみに感じている自分もいる。いいよね、そういう夢のあるゲーム。

ただVRのPvPってOverwatchWWise講習見てても思ったけどとても大変そう