MIDI遅延は、その1で改善が確認できたので良しとして...。値99%に設定したランダム分岐を1000回または1万回繰り返すサンプルシナリオを作成し、そのうち何回失敗するかを見ました。1000回も繰り返せば、「偶々全て成功」の偶然をかなり排除したと考えて良いだろうというわけです。1回でも失敗すれば、少なくとも値99%が100%扱いではなくなっている事が確認できます。逆に失敗0回だった場合は、100%扱いのバグが発症している可能性が考えられます。テストでは、1000回ループと1万回ループを各5回ずつ実行しました。以下は、その結果です。1.28エンジン拡張DLLあり→1000回ループでの失敗回数:10、10、11、11、12(平均10.8回)→1万回ループでの失敗回数:111、114、5、99、96(平均85回)1.28エンジン拡張DLLなしと1.20エンジン→1000回ループでの失敗回数:5回全てでゼロ→1万回ループでの失敗回数:5回全てでゼロこれは、間違いなく修正が効いていると考えてよさそうです。環境表示に用いた仮想システムクーポン「@MP3」の所持判定も、正しく処理されました。ついでと言っては何ですが、テストに使ったシナリオを公開しておきます。興味がある方は、ご自分の目で確かめてみて下さい。・ランダム分岐テスト用シナリオ残りは、MP3関連、スクリーンショット撮影機能、エフェクトブースター関連。同梱のcwconv.dll含めて導入(※))(※)winmm.dll(v.1.3)に同梱されているcwconv.dllはバージョン不明です。現行エンジンのものとサイズが異なり、何らかの変更が行われていると思いますが、その詳細は不明です。日記記事は書かれた日付時点のもので、内容が古いことがあります。上のリンク先で最新の情報をご確認下さい。公式に新エンジンテストのお知らせが出ていたので、実際使ってみることにしました。何かあれば報告、という事で。Extenderの最新版(v.1.3)を上書きして使用しました。他のゲーム環境設定項目の直後、先頭から42バイト目に割り込む形で追加されるため、それより後のシナリオ済印や宿ゴシップなど大部分のデータが1バイト分後ろにずれます。Environment.wydへのデータ追加のため、拡張DLL存在下で保存した宿は、それ以前の環境ではロードできなくなります。逆に言えば、バイナリエディタ等でその1バイトを削除すれば以前の環境でロード可能です。「1~99%の確率が内部的に2~100%として扱われる」のが正しく直ったとすると、拡張DLLの有無で1%の差が出ます。対策1:1%差をつけた2つの分岐処理を準備しておき、仮想システムクーポン「@MP3」の有無でプレイヤーの環境を特定して振り分ける。対策2:1%ぐらいの差は目をつぶることにして、バグ未修正の環境で100%扱いにならないよう、数値を1~98%の間で設定する。○カードに透過BMPを用いる場合どんな感じに見えるかと、とりあえず見てみました。どこぞの使い回しですが、透けてそうなキャラで。ついでに手札の方も表示を確かめました。表示見た目は、メモ箱内のまとめでご確認ください。透過非対応だと半透明部分がかなりおかしな事になっていますが、拡張を入れた方では問題なく表示されています。対策1:透過非対応環境向けに、従来型の画像を使った差分(イメージ格納を含むWSM・WIDファイルやフォルダ内に置く画像の差替え版)を用意しておく。対策2:シナリオの内容はそのまま透過BMPを使った所だけ従来型の画像に差し替え、拡張DLL対応版と従来向け版の両方を公開する。対策3:シナリオ開始時に仮想システムクーポンを利用して拡張DLL導入状況を見分け、説明を表示した上で宿に戻す。対策4:シナリオ側で特に何もしない場合は、添付テキストの目立つところに拡張DLLの機能を利用している事を書き、画像の表示がおかしくてもシナリオの不備ではない事を主張しておく。(これは何だかなぁ...。透過と同じような対策が必要そうです。MP3ループ再生非対応環境用にMIDIファイルを準備しても上書きによる差し替えができないため、差分は駄目ですね。代わりの手段としては、同じ場面のBGMをMP3とMIDIの両方で準備しておき、仮想システムクーポンを利用した振り分けで再生するファイルを変えるといった方法が考えられます。個人的には、拡張DLLの100%普及を確信できる方法が無い以上、あれこれ対策に手間をかけるより、従来通りの画像やMIDIを使った方が楽なように感じます。軽量に作りたい個人的事情のせいもありますかねぇ。昨今の傾向から考えると、透過BMPやMP3ループ再生への対応を歓迎される方も多そうです。今後のシナリオは、互換性や軽さなどを重視する従来型タイプと、グラフィックや音楽に凝れるだけ凝る拡張活用タイプに分かれていくのかも...などと、ふと考えたり。【MIDI再生遅延はどうなった?】(1)エリア上メニューカードをクリックするとBGMを再生する。(2)到着イベントを利用してBGMを流す。2種類のイベントを作り、(1)ではメニューカードをクリックしてから、(2)ではエリア移動用のカードをクリックしてからBGMが流れ始めるまでの時間を、ストップウォッチで計りました。使用したエンジンは1.28のみ。MidiPatch(CWMPと略)有・無の組合せで4パターンです。再生するMIDIファイルはデフォルト素材の「RYUNE.MID」を使いましたが、条件を同じにするため、シナリオフォルダ内に置いて参照しました。○クリックイベント拡張DLLなし+CWMPなし→1回目:2.60秒/2回目:2.54秒/3回目:2.54秒(平均:2.56秒)拡張DLLなし+CWMPあり→1回目:1.92秒/2回目:1.90秒/3回目:1.87秒(平均:1.90秒)拡張DLLあり+CWMPなし→1回目:1.66秒/2回目:1.60秒/3回目:1.59秒(平均:1.62秒)拡張DLLあり+CWMPあり→1回目:1.60秒/2回目:1.59秒/3回目:1.60秒(平均:1.60秒)○到着イベント拡張DLLなし+CWMPなし→1回目:2.99秒/2回目:2.99秒/3回目:2.97秒(平均:2.98秒)拡張DLLなし+CWMPあり→1回目:2.30秒/2回目:2.32秒/3回目:2.27秒(平均:2.30秒)拡張DLLあり+CWMPなし→1回目:2.02秒/2回目:1.96秒/3回目:2.03秒(平均:2.00秒)拡張DLLあり+CWMPあり→1回目:2.01秒/2回目:1.99秒/3回目:2.02秒(平均:2.01秒)以前、メディアプレーヤー事前起動の効果をほとんど実感できなかった事から、それと同等と説明されている拡張DLLも同じ結果になるのではないかと考えていましたが、予想は裏切られました。クリックイベントと到着イベントの双方で、約1秒ずつ曲の再生開始が早くなっています。拡張DLLなしの状態ではCWMPでMIDIの再生が早くなりましたが、拡張DLLありだとほとんど差はみられないという結果でした。修正後は、ストレスなく聞ける早さです。公式ファンサイトにメディアプレーヤー起動の効き目は環境によると書いてありましたし、環境によって差が出るのかもしれません。【NPC増殖バグの修正確認】キャスト加入イベントを持つシナリオを作成し、テストを行いました。キャストを1人加入させるごとに中断→再開を行い、2人以上になっていないか確認。NPCの数は、最大6人まで増やしました。拡張DLLなし→加入枠が一杯のキャスト6人の時を除いて毎度増殖あり拡張DLLあり→増殖は起こらずもうすぐ5時か。試すべきことはあるけれど、今は寝よう。同梱のcwconv.dll含めて導入(※))(※)winmm.dll(v.1.3)に同梱されているcwconv.dllはバージョン不明です。現行エンジンのものとサイズが異なり、何らかの変更が行われていると思いますが、その詳細は不明です。?全く役に立ちそうにありませんが、興味本位で以下のような事を試してみました。↓[4]CWエンジンを起動して[1]で作った宿をロードすると、winmm.dllを削除しただけではロードできなかった宿データがロードできました。...いや、内容から考えて当たり前ですね。[4]の後でセーブすると、宿のデータバージョンは10に戻ります。拡張DLLを削除した事で透過対応がなくなりますので、既に透過BMPを使ったカードがある場合、その表示が酷い事になります。何かの事情で環境を戻す場合、今のところ、気をつけるべきはそこぐらいです。(3/21追記)拡張DLLのバージョンが1.4以上になるとエンジン本体にも修正が施されているため、追加1バイト分の削除と拡張の削除だけでは戻せません。拡張なしのCW本体を新規インストールするなりして、本体も元に戻す必要があります。翳の回廊(絵置き場)の一部をTINAMIのスペースに置かせて頂いています。pixivでも何かやっている......かも。ゆう当サイトの内容を無断で使用、複製、転載することを禁止します。