エロゲのシステムまわりを考える（A・H・OP ver.8）
■ このスレッドは過去ログ倉庫に格納されています
紙芝居程度で重くするってエンジン以前にスクリプターに問題ありそうな 多機能と汎用性を備えると劇的に重くなるんですよ
2D-ADV用のエンジンを使ったほうが速くて楽なのは当たり前というか 機能の実装で劇的に重くなるって
プログラマが悪くないなら誰が戦犯だと言うんだよ 原因を調査しない・出来ない時点でまともなプログラマーとは思えない >>769
劇的に重くなる機能を実装したのはエンジンを作った奴な
戦犯はそのエンジンを選んだ奴だなｗ >>771
エンジン標準の使うと重くなる機能、か……
あれか、H2Oを沢山飲むと死ぬ並みに低レベルな話か
ぶっちゃけ紙芝居で重くするなんて画像や音源を全てメモリに展開するくらいしか思い付かないが、
それはリソース読み込む機能が悪いんじゃなくてリソース管理するコードを書けなかった奴が悪いと思う >>772
音楽はストリーム再生させるからともかく、
画像は全部メモリに載せるもんだろ 起動するだけで1.5GB食うのをプログラマーのせいにせず誰のせいにするのか
32ビットWindowsなら通常1つのソフトにつき2GBまでしか使えないので、クラッシュするのも当然だろう >>773
それが可能なら世の中のゲームからNow Loadingが消えてる http://forums.geforce.com/default/topic/937374
Microsoft Windows Vista support for GeForce GPUs
has been deprecated with driver branch R367_00 and onwards.
Driver 365.19 is the last driver to support Windows Vista.
http://forums.geforce.com/default/topic/957568
Microsoft Windows XP/Windows XP 64-bit driver support for GeForce GPUs
has been deprecated with driver branch R370_00 and onward.
Driver 368.81 is the last driver to support Windows XP/Windows XP 64-bit.
XPとVistaのGPUドライバが遂にワポート打ち切り >>775
ああ、まあ、このエンジンを使うのは無謀、絶対に酷いことになるから止めるべきだって
押し通さなかったのはプログラマーが悪いな。 ※修正パッチVer.1.10公開（2016/08/29）
http://laplacian.jp/kimiyume/patch.php
キミトユメミシのパッチVer1.10を公開いたしました。
主な改善箇所は以下です。
・32ビットマシンでクラッシュするバグ
・消費メモリの軽減
・一部バックログでの誤作動の修正
・誤字脱字修正
・一部CGの修正
・小鳥遊みこと立ち絵追加
※Ver.1.10のパッチは1GB程度のデータサイズになっております。非常に重いデータ容量となり、
ご利用の方には大変ご不便お掛けいたしますが、ご理解の程何卒よろしくお願いいたします。 公開日：2016/08/31 最終更新日：2016/08/31
JVN#85213412
有限会社AKABEi SOFT2 製の複数のゲーム製品における OS コマンドインジェクションの脆弱性
https://jvn.jp/jp/JVN85213412/
公開日： 2016/08/31 最終更新日： 2016/08/31
有限会社AKABEi SOFT2からの情報
脆弱性識別番号：JVN#85213412
脆弱性タイトル：有限会社AKABEi SOFT2 製の複数のゲーム製品における OS コマンドインジェクションの脆弱性
ステータス：該当製品あり
以下の情報は、製品開発者から JVN に提供されたものです。
https://jvn.jp/jp/JVN85213412/995740/index.html
影響を受けるシステム（ゲームタイトル）は下記のとおりです。
なお、初回版、通常版、ダウンロード版など、パッケージのバージョン、
販売形態にかかわらずすべての商品が含まれます。 どーせまたセーブデータだろと思ったらやっぱりそうだった なんか、設定ファイルが見つからないとか吐いて、インストーラが走らないぞ
どーなってんだこれ SandBurst
http://forest.watch.impress.co.jp/library/software/sandburst/
ウィンドウをリアルタイムに拡大表示できるソフト
マウス入力にも対応する、ゲームウィンドウのリアルタイム拡大ツール。
高解像度モニターでは、ウィンドウサイズが640×480ピクセルや800×600ピクセルなどのゲームをプレイすると、
文字などが小さくてプレイしにくい場合がある。
本ソフトを利用すると、指定した任意のウィンドウを、100％から300％まで任意の倍率で拡大表示できる。
描画にはWindows Vista以降のAero環境における描画エンジンであるDWMもしくはDirectXが利用でき、
DWMを利用した場合は低負荷で遅延のない表示が可能。
また、マウス入力も拡大したウィンドウに合わせて補正されるようになるので、マウスを利用するゲームも問題なくプレイできる。 最近一週間ほど昔のことを色々と想い出して古いエロゲーを最プレイしてるんだが
2002～2003年頃までのエロゲはいきなり問答無用で全画面で起動するのが多くてブチ切れそうになる
懐かしい想い出に浸りつつもエロゲのシステムは昔に比べてずいぶんと進歩したなあと実感
それとともに古いエロゲの8割くらいはWindows10でも全く問題無くプレイできて
2割くらいの動かないものもアクセス権いじるとかで半分くらいは対応可能
結局9割くらいのエロゲが今もプレイ可能だったことにも驚いてる fullscreenwinでも最大化できないゲームがある
古すぎるのは対応していないのか
しかしツクール系のゲームはUI最悪なのばかりでせっかく好みのCGがあっても遊ぶ気になれない
ADVやSLG型なのになんでツクールで作るんだ
YU-RISの方がいいと思うけどな～ そろそろOpus使ってもいいんじゃないの
ロイヤリティフリーだよ AHOPってなんだ？ って話題があったおかげでこのスレは8まで続いた 15年ｗｗ
696 名前：名無しさん＠初回限定 ：02/07/20 21:44 ID:fxuFC9QG
（´-`）.。oO（このｽﾚもA・H・OPの謎が解けずに八ヶ月たったが
プログラマに手を拍たせることが一つくらいあったろうか……） なぜそのレスをチョイスしたのか
>>3でもう疑問上がってるだろ 吉里吉里Zが進化しすぎて旧吉里吉里を使う理由がなくなってきた ショートカットキーの割り当て変更って使ってる？
俺は結局いつも標準のまま……。 >>800
ゲームエンジン／ウインドウクラス名でまとめてマウスボタンをカスタマイズしてるから、その統一ルールにあうようにオート、スキップ、窓消しのキー割り当て変更することはある
スペースキーが窓消しで変更できないと地味にイヤ せっかくの休みを>>801のフリーソフトの翻訳改訂とベータテストに費やしてしまった
エロゲや専ブラその他で欠かせないってぐらいにお世話になってきたが作者さんに恩返しできたかな
積みゲを切らしてたからべつにいいんだけどとても疲れた（英語が苦手なので） 【速報】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/]を参照してください。 ■ このスレッドは過去ログ倉庫に格納されています
