週刊ブリュンヒルデ創刊号。
遂にBrynhildrの通信プロトコル仕様を公開で御座います。これで自由にクライアントの開発が可能になります。今年最大の他力本願プロジェクトで御座います。
憧れのAndroid版を作るも良し、オサレなMac版を作るも良し、完全にアレな艦これ仕様版を作るも良し、とまー何でも御座れになる感じです。お正月休みとかにどーぞ的な。
一応プログラマー向けの内容でするので御了承下さい・・・(´･ω･`)
さて、まずコチラを御覧下さい。
サンプルソースコード （ ライセンスについて）
コチラが「Brynhildr 1.0.1.0」以降のパブリックモードを有効にした際に接続できるサンプルソースコードになります。VisualStudioでビルドが出来ると思います。ソースコードの書き方については御覧になって御分りになる通り「これアカンやつや」です。もうカナリ自覚してるんでスルーします。「0」と「1」しか代入されんのにlong型とかホントにモーですよね。
ちなみにパブリックモードを有効にする方法ですが、「brynhildr.exe」を起動させると生成される「brynhildr.ini」の「ServerMode」の項の「publicmode=0」を「publicmode=1」に変更するだけです。再びBrynhildrを起動させるとパブリックモードが有効な状態になります。
さて、このソースコードは「ホントただ接続するだけ」になってまして、一通り通信までは出来るものの、画面描画や音声再生は含まれておりません。画像や音声はバッファに入るところまでで御座います。また、シングルスレッド形式で書いていますけど、間違いなくマルチスレッド形式にすべきかと思います。ウインドウも生成していませんし、無限ループになってますので終わる時も手動です。あくまでもサンプルですので。
今回は創刊号とユー事で大まかな説明だけにしておこうかと思います。徐々に細かな説明とかしていこうかと思いますが、感の良い方はこれだけでサクッっとAndroid版とか作れると思います。実際いらっしゃいます。
さて、それではソースコードの中身の説明に入ります。
中身は極めてシンプルです。関数は「WinMain」「recv_data」「send_data」しかありません。「WinMain」から始まってグルグル回して色んな通信します。
通信は同一ポートに対して複数のセッションで張ります。セッションは「操作系」「画像系」「音声系」の３つです。順番に接続を行う必要があるのと、少し安定するまで次のセッションを張る事ができません。安定のカウントは「g_sock1_ct」と「g_sock2_ct」になります。まず、操作系を接続して５周通信で、次に画像系を接続して５周通信で、次に音声系を接続して通信となります。こんな流れです。
画像系での本体受信は「JPEG形式」です。ヘッダーも含まれているのでそのままファイルを書き出すとJPEGファイルとして読む事が可能です。
音声系での本体受信は「PCM形式」です。サンプルレートは音声系通信セッションの「com_data.samplerate」に返ってきまして、量子化ビット数は「16bit」でステレオの2チャンネルです。実際に操作系通信セッションの「com_data.sound_quality」で指定したサンプルレートやBrynhildr側のパソコンのサウンドデバイスの設定とは異なり、最適化された形でリサンプリングされPCM形式のデータが送られてきます。尚、こちらにはヘッダーありませんのでRIFF形式等にする時はヘッダーを別途生成する必要があります。
さて、接続先のIPアドレスやPort番号は「WinMain」に埋め込まれていますが、パスワードの仕様について御説明します。パブリックモードは、最大で16byteという制限があり、これはBrynhildr側の標準のパスワードの最大32byteとは異なります。ですので、brynhildr側で17byte以上のパスワードを設定するとパブリックモードでは接続する事が出来ません。この点を御注意下さい。逆にパブリックモードによるセキュリティが心配という方は、17byte以上のパスワードを設定する事をオススメ致します。
あと、接続以外の異常系の処理はほとんど書いていませんので、書く事をオススメ致します。てか書かない人はいないと思いますけど。
さて、えらく長くなるのも面白くありませんので、今回はサンプルコードを公開しただけに留めて、次回からはもうちょっと細かいところを御説明したいと思います。それにしてもこんなソースコードの説明なんてした事ないし、他の方が書かれているのもさらっとした読んでないので、どんな風に書いたら良いかわからんですね。もしかしたら次回より書き手が変わるかもしれん事を予告しておきます。とか言いながら誰もいなくて自分になるんでしょうけどきっと。
そんなこんなでパフォーマンス的にはOrthrosと同等イヤそれ以上が出るはずですので、どうぞ開発の参考になれば良いかなと思っております所存で御座います。
でも冷静になってよー考えたらホントに欲しい人おるんかなコレ・・・(´･ω･`)
憧れのAndroid版を作るも良し、オサレなMac版を作るも良し、完全にアレな艦これ仕様版を作るも良し、とまー何でも御座れになる感じです。お正月休みとかにどーぞ的な。
一応プログラマー向けの内容でするので御了承下さい・・・(´･ω･`)
さて、まずコチラを御覧下さい。
サンプルソースコード （ ライセンスについて）
コチラが「Brynhildr 1.0.1.0」以降のパブリックモードを有効にした際に接続できるサンプルソースコードになります。VisualStudioでビルドが出来ると思います。ソースコードの書き方については御覧になって御分りになる通り「これアカンやつや」です。もうカナリ自覚してるんでスルーします。「0」と「1」しか代入されんのにlong型とかホントにモーですよね。
ちなみにパブリックモードを有効にする方法ですが、「brynhildr.exe」を起動させると生成される「brynhildr.ini」の「ServerMode」の項の「publicmode=0」を「publicmode=1」に変更するだけです。再びBrynhildrを起動させるとパブリックモードが有効な状態になります。
さて、このソースコードは「ホントただ接続するだけ」になってまして、一通り通信までは出来るものの、画面描画や音声再生は含まれておりません。画像や音声はバッファに入るところまでで御座います。また、シングルスレッド形式で書いていますけど、間違いなくマルチスレッド形式にすべきかと思います。ウインドウも生成していませんし、無限ループになってますので終わる時も手動です。あくまでもサンプルですので。
今回は創刊号とユー事で大まかな説明だけにしておこうかと思います。徐々に細かな説明とかしていこうかと思いますが、感の良い方はこれだけでサクッっとAndroid版とか作れると思います。実際いらっしゃいます。
さて、それではソースコードの中身の説明に入ります。
中身は極めてシンプルです。関数は「WinMain」「recv_data」「send_data」しかありません。「WinMain」から始まってグルグル回して色んな通信します。
通信は同一ポートに対して複数のセッションで張ります。セッションは「操作系」「画像系」「音声系」の３つです。順番に接続を行う必要があるのと、少し安定するまで次のセッションを張る事ができません。安定のカウントは「g_sock1_ct」と「g_sock2_ct」になります。まず、操作系を接続して５周通信で、次に画像系を接続して５周通信で、次に音声系を接続して通信となります。こんな流れです。
画像系での本体受信は「JPEG形式」です。ヘッダーも含まれているのでそのままファイルを書き出すとJPEGファイルとして読む事が可能です。
音声系での本体受信は「PCM形式」です。サンプルレートは音声系通信セッションの「com_data.samplerate」に返ってきまして、量子化ビット数は「16bit」でステレオの2チャンネルです。実際に操作系通信セッションの「com_data.sound_quality」で指定したサンプルレートやBrynhildr側のパソコンのサウンドデバイスの設定とは異なり、最適化された形でリサンプリングされPCM形式のデータが送られてきます。尚、こちらにはヘッダーありませんのでRIFF形式等にする時はヘッダーを別途生成する必要があります。
さて、接続先のIPアドレスやPort番号は「WinMain」に埋め込まれていますが、パスワードの仕様について御説明します。パブリックモードは、最大で16byteという制限があり、これはBrynhildr側の標準のパスワードの最大32byteとは異なります。ですので、brynhildr側で17byte以上のパスワードを設定するとパブリックモードでは接続する事が出来ません。この点を御注意下さい。逆にパブリックモードによるセキュリティが心配という方は、17byte以上のパスワードを設定する事をオススメ致します。
あと、接続以外の異常系の処理はほとんど書いていませんので、書く事をオススメ致します。てか書かない人はいないと思いますけど。
さて、えらく長くなるのも面白くありませんので、今回はサンプルコードを公開しただけに留めて、次回からはもうちょっと細かいところを御説明したいと思います。それにしてもこんなソースコードの説明なんてした事ないし、他の方が書かれているのもさらっとした読んでないので、どんな風に書いたら良いかわからんですね。もしかしたら次回より書き手が変わるかもしれん事を予告しておきます。とか言いながら誰もいなくて自分になるんでしょうけどきっと。
そんなこんなでパフォーマンス的にはOrthrosと同等イヤそれ以上が出るはずですので、どうぞ開発の参考になれば良いかなと思っております所存で御座います。
でも冷静になってよー考えたらホントに欲しい人おるんかなコレ・・・(´･ω･`)
Verethragna
KeroKeyboard