エロゲのシステムまわりを考える（A・H・OP ver.8）
発売前は話題にならないが実際に遊んだ人からはしっかりと評価されるシステム周り。
システムが良ければ売れるわけではないがシステムという土台がしっかりしてないと、良い絵やシナリオ、濡れ場の魅力も半減。
そんな縁の下の力持ちであるシステム周りについて語りましょう。
「ここのメーカーのシステム使いにくいんだけど。こんな風だったらよかったのに・・・」
「このゲームのこのシステムは(・∀・)ｲｲ」
「エロゲにこんな機能があったら便利」
そういった情報の検討・蓄積を行うスレです。
ここの地道な意見がシステムデザインの参考にされることを願ってやみません。 【速報】mp3の特許が切れてフリーに
http://www.mp3licensing.com/
>On April 23, 2017, Technicolor's mp3 licensing program for certain mp3 related patents and software of Technicolor and Fraunhofer IIS has been terminated. SandBurst1.4
2017/05/20 01:38
http://eternalpaymenholiday.blog.fc2.com/blog-entry-42.html
SandBurstを1.4に更新しました。
http://ux.getuploader.com/MasterD/download/15/SandBurst.zip
Vectorでも公開しましたが、間違えて古いファイルで公開してしまいました。
Vector版だと今まで動作してたゲームの一部が動作しません。
Vectorはファイルの更新に営業3～4日かかるので、最新版はこのブログ内のURLからダウンロードしてください。
■ 更新内容
① 吉里吉里2 と LiveMakerの対応を強化
② 拡大率ボタンを可変に
③ 非アクティブ時にウィンドウを戻す設定を廃止
① 吉里吉里2 と LiveMakerの対応を強化
(古い)吉里吉里2とLiveMaker製のゲームが元のウィンドウサイズ分しか補正できてなかったところを修正しました。
動作モードに「吉里吉里2 & LIveMaker」と言うのを作りましたので、これらのゲームの場合はこのモードを使ってください。
② 拡大率ボタンを可変に
拡大率のところを右クリックで最大、最小、各ボタンの拡大率を変更できるようになりました。
③ 非アクティブ時にウィンドウを戻す設定を廃止
ゲームが非アクティブになっても常に拡大を維持するようになりました。
設定としてあった方がいいんですが、①の対応でこの処理が変わったため、廃止です。 うん、Zに移行してくださいってことらしい。
https://internetcom.jp/203933/end-of-kirikiri
ゲーム制作アプリ「吉里吉里」公式配布が終了へ―「Fate」シリーズでも採用 aoTuV beta 6.03 (2018) リリース
https://aynote.wordpress.com/2018/05/02/aotuv-beta-6-03-2018%e3%83%aa%e3%83%aa%e3%83%bc%e3%82%b9/
本家のlibvorbisの新しいバージョン1.3.6がリリースされたため、それと統合したaoTuVを公開しました。
脆弱性の修正がメインとなっており、公式の1.3.5から1.3.6への変更点は以下の通りです。
Fix CVE-2018-5146 - out-of-bounds write on codebook decoding.
Fix CVE-2017-14632 - free() on unitialized data
Fix CVE-2017-14633 - out-of-bounds read
Fix bitrate metadata parsing.
Fix out-of-bounds read in codebook parsing.
Fix residue vector size in Vorbis I spec.
Appveyor support
Travis CI support
Add secondary CMake build system.
Build system fixes
新しいaoTuVについても以上の変更・修正点を反映しているため、ライブラリとしてaoTuVを利用されている場合は
旧バージョンからアップデートされることを推奨します。
もちろん公式の1.3.6の代わりに今回のaoTuVを使用することも問題なく可能です。 以下雑談
久しぶりの更新となりました。
今回は前回よりもアップデート作業自体はスムーズに進んだものの、その前段階でPCにトラブルがあったりしたため、
そちらの方に時間が取られてしまい難儀しました。（この辺のお話はそのうち書きたいです）
今回も相変わらずエンコードに影響するような変更は有りません。
コンパイラを更新したこともあり、リファレンスバイナリの出力結果は微妙に異なりますが、コンパイラや実行環境が同じであれば、
同じ出力結果になるはずです。
後は地味にエンコーダのvencの更新をしています。
今回は8/24/32bit整数と32bit浮動小数点のPCM形式の入力に対応したのが主な変更点です。
オーディオデータは32bit浮動小数点数で処理されるため、32bit整数は精度的にはオーバースペックになりますが、
対応してないよりは対応していたほうが良いでしょう。
aoTuV Beta6.03 (2018) (2018/5/2)
http://www.geocities.jp/aoyoume/aotuv/index.html
# The latest aoTuV beta6.03 was unified with Xiph.Org's libvorbis1.3.6. The part related to sound quality is not changed from previous version.
・ libvorbis 1.3.6を統合しました。エンコード品質については前バージョンと同様です。 ゲーム開発向けの統合型サウンドミドルウェアWwiseのOpusサポート
https://blog.audiokinetic.com/ja/wwise-2018.1/
OPUSコーデックが、全プラットフォームでサポートされています。Opusは、CPUを少し余分に確保するだけでWwise Vorbisに匹敵する品質を保ちつつ、さらに圧縮できるので、ファイルサイズを特に縮小する必要があるときは、Wwise Vorbisの代替案として非常に有効です。
これらのコーデックを組み合わせて使い、両者の長所を利用することで、ファイルサイズやCPUの競合するニーズに対応できます。
Opusを使ったループやシークについて
Opusでは、シークやループ用のシークテーブルは不要ですが、その分、CPU負荷が高くなり、ディスクアクセスが増えます（ストリーミングの場合）。
これを念頭に、Opusの利用はシークやループのニーズが最小限または皆無のサウンドに制限すべきです。なお、ファイル冒頭のシークやループは軽度なので、このような余計なコストがありません。
Resource usage - リソースの消費 - OpusとVorbisの比較: [http://listening-test.coresv.net/results.htm]で見る限り、Opusコーデックの方がVorbisよりも、同程度のビットレートでの音質評価がやや高いようです。
同じファイルサイズで音質が高い方が、一見、有利なように思えますが、品質が多少なりにも高い裏には、Opusの方がWwise VorbisコーデックよりもCPU負荷が4倍から5倍も高いという現状があります。
とはいえ、何千ものダイアログラインや、長いSFXや、ループなしの単一ストリームミュージックなどを圧縮するには最適の選択です。
Opusとほかのコーデックのオーディオ品質の比較についてさらに詳しく知るには、 [https://opus-codec.org/comparison/]を参照してください。 