2015/12/21

Wine上のWOLF RPGエディター(ウディタ)作品の動作

WineにおけるWOLF RPGエディター(ウディタ)作品の動作についてを扱う。

初めて扱ったときの記事は2011年8月に書かれたが、その後色々と新しいことが分かったり、Winetricksの機能で対処が簡単になったりと状況が変わっていることも多く、大幅に内容を書き直し、追加の記事として2011年9月,2012年2月,同年9月に扱った内容も統合した。

  1. 作品によって不具合が出たり出なかったりする理由
    1. Game.exeのファイル情報を用いてウディタのバージョンを識別
      1. 最終更新日時とファイルサイズ
      2. MD5
  2. 幾つかの問題点とその対処
    1. フォント関係
      1. バージョン2.2x系作品で一部の文字が描画されない問題と対処 (2017/10/6追記)
    2. MIDI形式のBGMの再生
    3. ゲームパッド接続時のキーボード操作の問題
    4. エラーメッセージを表示する作品
    5. バージョン2.10作品の3Dモード使用時の文字化け
    6. Wine 1.8上のバージョン2.10作品におけるサウンド全般の問題
      1. 問題の修正 (2016/2/7追記)
  3. Config.exe使用時の作業ディレクトリについての注意点
  4. Gallium Nine使用時の不具合と回避方法 (2017/1/8追記)
    1. 画面が真っ黒になる問題
    2. バージョン2.10作品の文字化け現象 (解決済み)
    3. その他の不具合
  5. ウディタ2.22以上におけるDirect3D 11対応とWineの動作 (2018/6/10追記)
  6. 過去に修正済みの問題点
    1. 日本語の入力
    2. 3Dモードの動作
    3. 一部のMP3ファイルが再生されない不具合 (2017/2/26追記)
    4. 効果音が数回鳴った後で鳴らなくなる (2018/6/10追記)
    5. XAudio2使用時に音量変更が反映されない (2018/6/10追記)

作品によって不具合が出たり出なかったりする理由

WOLF RPGエディター(ウディタ)は “DXライブラリ” というライブラリを使用しており、どのバージョンで作品が作られたかによって作品を動かすGame.exeとその中のDXライブラリのバージョンも変わるため、作成ツールが同一でも作品によって同ライブラリ内のバグやWine特有の挙動の関係で問題が起こったり起こらなかったりすることがある。

また、作品自体が同じものでも、作品の作者がバージョンアップの際にWOLF RPGエディター(ウディタ)の新しいバージョンへ切り替えることもあり、そのタイミングでGame.exeとその中のDXライブラリのバージョンが変わって挙動が変わる場合がある。[1]

ライブラリは静的リンクされて使用される(実行ファイル内に取り込まれる)ため、問題のあるバージョンが中に使われていることが分かったとしてもライブラリ部分のみを修正済みのバージョンで置き換えたりはできない。

Game.exeのファイル情報を用いてウディタのバージョンを識別

Game.exeのファイル情報を取得して識別することにより、作品がどのバージョンで作られたかを識別することができる。同じバージョンで作られた作品は特定の不具合が共通して発生することがあり、バージョンを把握することが対処の助けになる。

バージョンを識別するには以下の一覧から(最終更新日時,ファイルサイズ,MD5の内)複数の項目が一致するものを探す。いずれにも当てはまらないものはベータ版段階で一時的に公開されていたものの可能性があり、最終更新日時によってどのバージョンが近いかを推定することができる。

最終更新日時とファイルサイズ

バージョン最終更新 [JST(UTC+9)]サイズ
2.242018/06/22 20:386,365,184
2.232018/06/06 00:366,365,184
2.222018/05/31 22:326,365,184
2.212017/04/10 19:316,303,744
2.202017/03/08 13:336,299,648
2.102013/08/02 18:003,702,784
2.02a2012/06/10 15:113,092,480
2.012011/11/22 16:362,764,800
2.002011/10/15 16:362,760,704
1.312010/10/09 14:452,404,352
1.302010/07/06 00:573,788,800
1.202010/04/28 13:383,784,704
1.162010/02/13 14:442,220,032
1.152009/12/12 23:082,215,936
1.142009/10/03 19:232,207,744
1.132009/07/25 15:282,199,552
1.122009/06/06 20:582,195,456
1.112009/04/11 18:582,199,552
1.102009/02/26 21:281,908,736

MD5

バージョンMD5
2.2485ba11518891dd904c109880e7406222
2.239b574400b070e7f7c701517472065f9c
2.22cf98fbe4fe46ea764571548e5530adc1
2.213e0cb342a274a6e738c1a47dfed2cc57
2.209d232a5dbb8d94aa3064508a78f4b6df
2.1014e087b81ab2befd8db2e0a98e2731aa
2.02aeda3f5522cbefc7f3351de8d182f6432
2.01deaa73ce64c7c63a9837bd48fa7a3194
2.00a3b9e040ee832abbb109ffaa32de7954
1.31b1996a7e4f8c2fc8a57fe0ee35fe46bd
1.30e7e8191354e5dee9e828d6ec1dd7b257
1.209c4cef4dd6bc274f6b6ac2dba7499055
1.16bff31170c41b393257268f8088fe8c04
1.15910fdfea9bdc08946608f54ec2937d72
1.14be9fbccce32f529003479336ac04d442
1.13c0ba1fb75a86556789e5d92b7e9c2109
1.1200c51b3ad9e73e588a1d46a908cf1cd1
1.1150defca421b83e46ba28f8876d2907b1
1.109ce17402084daede776859b344ffa5dd

幾つかの問題点とその対処

フォント関係

  • MS ゴシック (基本フォントとして使用)
  • Arial Black (サブフォントとして使用)

がエディタ側の既定の設定値となっており、多数の作品で用いられている。特に前者は、他の(互換性の悪い)フォントが用いられていると、作品によっては

  • テキストのレイアウトが崩れる (“MS ゴシック” などを前提としたレイアウト)
  • ごく一部の作品で、見やすい埋め込みビットマップがないフォントだと読みにくくなる (見やすい埋め込みビットマップを含んだ “MS ゴシック” などを前提としたインターフェース)

という場合があるため、互換性に優れたIPAモナーフォントと同フォントを用いたフォント置換を行うことを強く推奨する。後者のフォントは戦闘時のダメージ表示などで使用されることが多く、ない場合に見た目がWindows上と大きく異なったものとなってしまう。

これらはともにWinetricksでインストール可能で、前者はfakejapanese_ipamonaをインストールすることで置換設定までが行われ、後者はcorefontsをインストールすればよい。

(IPAモナーフォントのインストールとフォント置換設定のみ)
$ (WINEPREFIX=[Wine環境の場所]) winetricks fakejapanese_ipamona

(IPAモナーフォントに加えてcorefontsもインストールする場合)
$ (WINEPREFIX=[Wine環境の場所]) winetricks fakejapanese_ipamona corefonts

ただ、 “Arial Black” などを含んだフォント集であるcorefontsのパッケージはディストリのパッケージとして利用可能な場合(Debian/Ubuntuではttf-mscorefonts-installerというパッケージ名)もあり、その場合はどちらか片方でインストールすればよい。

下はIPAモナーフォントを使用したほうが正しく描画される例(2つ目の画像がIPAモナーフォント)。

Anelgear(別フォント使用時)

Anelgear(IPAモナーフォント使用時)

下の作品では全体的に見やすくなるが、文字の一部が欠けてしまう。

武神の目覚め(別フォント使用時)

武神の目覚め(IPAモナーフォント使用時)

バージョン2.2x系作品で一部の文字が描画されない問題と対処 (2017/10/6追記)

バージョン2.2x系で作られた作品では、イベントのメッセージやキーボードから文字列入力を行う場面の入力文字列において一部文字が画面に表示されないことがある。その場合、前者(今回確認した作品のメッセージ)は “メイリオ”, 後者(文字列入力)は “Meiryo UI” のフォント置換が必要となる。

今回、メイリオ系フォントの置換に使うフォントにどれが適しているかを吟味したのだが、最終的にVLゴシックフォントを(“メイリオ” および “Meiryo UI” の置換用フォントとして)使用することに決まり、このフォントのインストールと置換設定追加を行うWinetricks用の操作(verb)としてそれぞれvlgothicfakejapanese_vlgothicを実装するコードを提案し、2017年10月上旬に同ツールに取り込まれた。ただし、このフォントはMS系フォントの置換には適さず、置換処理も行われないように(意図的に)しているため、fakejapanese_ipamonaはこれまでと変わらずに使用を推奨する。

(VLゴシックのダウンロードと配置をした上で "メイリオ" と "Meiryo UI" を置換)
$ (WINEPREFIX=[Wine環境の場所]) winetricks fakejapanese_vlgothic

下は “夢見草の夜” という作品のメッセージの表示比較。

MIDI形式のBGMの再生

MIDI形式のBGMを用いている作品の多くは再生に “Microsoft Synthesizer” を用いており、[2]WineではそのままではMIDI形式のBGMが正常に再生されない。対処については

を参照。 “dsdmo” については作品によってはなくても問題ないが、(GuruGuruSMF4.dllではなくGuruGuruSMF.dllが付属している)古い作品で正常に再生するために必要となる。[3]

ゲームパッド接続時のキーボード操作の問題

ゲームパッド接続時にキーボードの矢印キーの操作がうまく動作しない不具合がある[4]が、これはコントロールパネルの “ゲーム コントローラ” で “接続済み” の項目を全て “無効化” ボタンで無効化しておくことで回避できる。この項目はWineのバージョン1.5.12から追加されている。

(ゲーム コントローラのコントロール パネル項目を開く)
$ (WINEPREFIX=[Wine環境の場所]) wine control joy.cpl

同様の問題として、DXライブラリを用いたプログラムでゲームパッド接続時にWaitKey()関数が正常に動かないが、同様に対処できる。

(2017/2/26)この件についてはバグ報告済みで、問題を修正するパッチも存在するが、テストプログラム実装などの事情でWineのバージョン2.0時点では公式のソースには含まれていない。

エラーメッセージを表示する作品

一部の作品では実行時に画面内に

【アクセスエラー】ファイルにアクセスできませんでした。 WindowsVistaの場合「管理者として実行」でゲームを起動することで問題が解消されます。 sc/title-2.jpg

のようなエラーメッセージが表示され、プログラムが落ちることはないがいちいち動作が止まるため、進行に支障が出る。端末には “Failed to create temporary file” と表示され、Wineのバージョン1.8でもエラーとなる。

このような作品はファイル群を仮想Cドライブの中に配置する(Zドライブなど、 “C” 以外の仮想ドライブ以下には配置しない)ことで正しく動作するようになり、Game.exeなどを含んだディレクトリが仮想Cドライブの外にあっても、それを指し示すシンボリックリンクを仮想Cドライブ内に作成してこれをたどって実行することでも正しく動作する。

(2017/2/26)より正確には、一部作品の特定の場面において、ドライブの直下へ一時ファイルを書き込んでこれに失敗した際に画像が表示されなかったり緑帯エラーが出たりゼロ除算(winegstreamer使用時に限る)で止まったりなどの不具合が出る。不具合は一部を除きWindows上でドライブ直下の階層に対する書き込み拒否のアクセス権設定をしても再現されるため、Wine固有の問題ではない。この現象の発生するバージョン2.10作品のGame.exeをバージョン2.20のベータ版のファイルで置き換える実験を行ったところ、ドライブ直下への書き込みはされなくなっており、不具合もなくなっているため、バージョン2.20以上の作品ではこの問題は起こらない可能性が高いと考えられる。古い作品ではこの問題は避けられないので、対策としては、やはり既定の仮想Zドライブ(直下へは一般ユーザでは書き込めない)以外のドライブ内に作品を配置する(もしくはドライブ割り当て自体を見直す)しかない。ゼロ除算が起こる現象についてはデバッグ情報を除去せずに実行することで発生箇所が表示されるため、これをもとに自分で修正したものが取り込まれてWineのバージョン2.1以上では起こらなくなっている。

(2017/4/23)ゼロ除算についてはバージョン2.0.1以上の2.0系バージョンでも修正済みとなっている。

バージョン2.10作品の3Dモード使用時の文字化け

バージョン2.10のWOLF RPGエディター(ウディタ)で作成された作品を3Dモード(GPUを用いた描画モード)で動かすと文字化けが発生[5]し、Wineのバージョン1.8時点ではバグは修正されていない。独自にWine側を修正することによる対処には(Wineの1.6系と1.8系の両方で)成功しているが、この件については長くなるので、別途扱う。

Wine 1.8上のバージョン2.10作品におけるサウンド全般の問題

バージョン1.7系(開発版系統)の終わり[6]に近い時期にWine版のxaudio2_8.dllの実装が新しく行われたのだが、これがWOLF RPGエディター(ウディタ)作品の起動時に落ちる原因となっていた時期があり、その後落ちることはなくなったものの、Wineのバージョン1.8から1.8.2(安定版系統)と1.9.0から1.9.2(開発版系統)ではバージョン2.10作品においてMIDI形式のBGMを除いて音が鳴らない現象が発生する。[7]

これを回避するにはxaudio2_8.dllを無効化すればよいが、具体的な手順については既に “1.7系の一部バージョンのWineでWOLF RPGエディター(ウディタ)作品が動かない問題と対処” で扱っているため、ここでは扱わない。

問題の修正 (2016/2/7追記)

この問題のバグ報告[8]後にバージョン1.9.3で一部未実装だった機能の追加が行われてWine版のxaudio2_8.dllを用いて正常に音が出るようになったのだが、バージョン1.9.3と同時期に公開された安定版のバージョン1.8.1には修正が入らなかった。

(2016/6/16)バージョン1.8.3で修正が入り、同バージョン以上の1.8系のWineでも正常に動作するようになった。

Config.exe使用時の作業ディレクトリについての注意点

作品の動作設定を行うConfig.exeは設定内容をGame.iniというファイルに書き出すが、このプログラム実行時の作業ディレクトリに出力されるため、実行する際には事前に作業ディレクトリを同ファイルのある階層に移動しておく。

(Config.exeで設定を行う)
$ cd [Config.exeとGame.exeのあるディレクトリ]
$ (WINEPREFIX=[Wine環境の場所]) wine Config.exe

もしくは、作業ディレクトリ内に出力されたGame.iniConfig.exeGame.exeのあるディレクトリへ移動する(古いファイルは上書きする)。

作品を起動するGame.exeについては作業ディレクトリを事前に移動しなくてもよく、実行時に読み込まれるGame.iniは作業ディレクトリではなく実行ファイルのディレクトリから探索される。

Gallium Nine使用時の不具合と回避方法 (2017/1/8追記)

画面が真っ黒になる問題

2016年末時点では、DXライブラリを使用したプログラム(WOLF RPGエディター含む)をGallium Nine対応Wineで動かすと画面が真っ黒になってしまう。ただ、音は鳴るなど、描画処理以外のところでは正常に動作していることが分かる。

長い間この原因が不明なままだったが、初期化処理に何か原因があるはずだと考えていたので、2016年12月にDXライブラリの描画関係のAPIの初期化処理のソースを見ていたのだが、最終的にDirectDrawのIDirectDraw7::SetCooperativeLevel()の中にGallium Nineと相性の悪い処理があることが分かり、更にその後DirectDrawのレンダラ指定をGDIにするだけで問題が回避できることも分かった。

(Game.exeという名前の実行ファイルに対してのみDirectDrawにGDIを用いる)
$ wine reg add "HKEY_CURRENT_USER\Software\Wine\AppDefaults\Game.exe\Direct3D" /v "DirectDrawRenderer" /t REG_SZ /d "gdi"

バージョン2.10作品の文字化け現象 (解決済み)

Gallium Nineには既にかなり前からst/nine: Only update dirty rect for UpdateTextureという修正が入っており、IDirect3DDevice9::UpdateTexture()が呼ばれる際に “ダーティ領域” と呼ばれる、GPU側のテクスチャに対してシステムメモリ側のテクスチャから更新(転送)処理を行う対象となる領域のみが転送されるように既になっているため、画面が真っ黒になる問題さえ何とかなれば文字化け(フォントキャッシュ破壊)は起きないと考えていたのだが、2016年12月中旬時点ではこれに対処してもWineのDirect3D実装(wined3d)と同様の崩れた描画になってしまった。

この件についてバグ報告を考えていたのだが、WineのDirect3D実装(wined3d)のほうが報告済みだったのでそちらの情報を更新した上でリンクをしようと考え、用意したテストプログラムや既存のハック(邪道な対処)などをアップロードしたり、助言に基づいてテスト処理を追加したり “ダーティ領域” の記録処理の実装を含んだ実験的な汎用パッチを書いたりしている中でGallium Nineで発生する不具合の発生原理が見えてきた。

Gallium Nineではダーティ領域は単一の矩形(座標群)として記録されるのだが、これを記録するIDirect3DTexture9::LockRect()IDirect3DTexture9::AddDirtyRect()のいずれかを複数回呼び出した場合に(後から追加されたものを含め)全ての領域を覆うように広げるようになっている。そしてこの “広げる” 処理を行うところでダーティ領域が空(つまりIDirect3DDevice9::UpdateTexture()が呼ばれた直後の更新対象がない状態)のときに座標値の関係で意図しない動作を起こし、これにより最初に記録される領域が引数で与えられるものよりも広くなってしまうのが文字化け(フォントキャッシュ破壊)の原因となっていることが分かった。

この処理のところで “ダーティ領域が空の場合” を判定して適切に処理するようなパッチを作って提出したところ、少し回り道にはなったものの修正の仕方が最善の形であることを双方が認識した上で完成形のパッチができ、最終的に取り込まれることになった。これにより、真っ黒画面問題の回避さえ行えばGallium Nineでウディタ作品が文字化けせずにかつ高速に動作するようになった。パッチはある程度古いMesaのソースにも適用可能で、バージョン12.0.3時点ではそのまま適用できる。

(2017/2/26)パッチはMesaのバージョン17.0.0以上で標準で適用されている。

以前wined3dを改造したときの “ハック” と比較すると、確実に高速/低CPU使用率になっていることが分かるが、CPU性能が十分に高い場合は大きな体感差はないかもしれない(CPUが低性能・低クロックの場合には差が実感できる可能性は高いと考えられる)。

その他の不具合

動作の支障になるような大きな不具合はないが、ウィンドウモードでフレームレートを表示したときにちらつく問題があるので、フレームレートを表示しながら動かし続けるのには向かない(全画面モードを推奨・ウィンドウ内でプレイしたい場合は仮想デスクトップを使用するのがよい)。

この他、一部のエフェクトの描画に関する不具合もあり、例として “アクアリウムス” のイベント戦闘で敵が使用する技 “システマティックディシース” のカットイン後のエフェクトが一部表示されない(3段階ある中の1つ以上が欠ける)。wined3d(文字化け修正の改造をしたもの)では正常に表示される。

(2017/2/26)2017年1月に公開された “アクアリウムス真ギュラリティ” では同エフェクトが少しだけ変わっており、正常に表示されたが、追加ストーリー後半に登場する一部ボス敵の技のカットイン部分が正常に表示されないことがあった。これらはwined3dでは正常に表示される。

ウディタ2.22以上におけるDirect3D 11対応とWineの動作 (2018/6/10追記)

WOLF RPGエディターのバージョン2.22からDirect3D 11が使用できるようになり、これに対応するGPUではWineでも同APIで動作する。手元のIntel HD Graphics 510でもサンプルゲームで動作を確認した。また、VulkanによるDirect3D 11実装のDXVKでもバージョン0.54時点では動作し、同GPUでサンプルゲームの動作を確認した(Wine標準の実装とDXVKのいずれもWine 3.9のstagingではない通常の開発版で確認)。

Direct3D 9にも引き続き対応しており、AMDやNVIDIAのGPUの内、Vulkanに対応していないGPUでGallium Nineを使用している場合は従来通りに動かすことができると思われる(手元では未確認)。設定変更はGame.exeと同じディレクトリにあるConfig.exeを実行して行う。

過去に修正済みの問題点

日本語の入力

ゲーム中でキーボードから(主人公の名前や謎解きの答えなどの)文字列を入力する場面のある作品があり、そこで日本語を入力しようとすると固まる現象が過去に起こっていたが、Wineのバージョン1.4系以上では問題なく動作する。

3Dモードの動作

一部の古いバージョンのWineでは3Dモードが動かない(画面が真っ黒になったり、未実装機能の関係で初期化に失敗してソフトウェア描画になったりする)現象が起こることがあったが、バージョン1.4系以上ではこのモードが使用できる。

一部のMP3ファイルが再生されない不具合 (2017/2/26追記)

Wineのバージョン2.0時点では一部のMP3ファイルが正しく再生されない。DXライブラリの音声再生関数を直接呼び出しても同様の挙動になったため、これを用いたテストプログラムを書いた上で正しく再生されないMP3ファイルを作品の付属テキストからたどって複数入手し、共通点(ビットレートが320kbps)を見付けた後、再生されないファイルがLAMEでエンコードされたものに限られることを偶然発見し、短いピー音の音声を作ってテストプログラム(DXライブラリとそのソース含む)とピー音のMP3を添えてバグ報告を出した結果短期間で解決し、Wineのバージョン2.2以上で正常に再生できるようになった(WOLF RPGエディター作品での再生も確認)。

(2017/4/23)バージョン2.0.1以上の2.0系バージョンでも修正済み。

効果音が数回鳴った後で鳴らなくなる (2018/6/10追記)

Wineのバージョン3.0-rc1でのみ発生していた不具合で、内蔵版のXAudio2使用時にカーソル音などの同一の効果音が数回鳴った後で鳴らない現象が発生するものだった。

DXライブラリで “メモリに読み込んだ音データを再生” する関数を繰り返し呼ぶプログラムを書いてみたところ現象が再現できたので、これを添付の上でバグ報告したところ、週明け後すぐに修正が入った。

XAudio2使用時に音量変更が反映されない (2018/6/10追記)

内蔵版のXAudio2使用時には音量指定が反映されておらず、音量バランスがおかしい場合がある他、作品によっては戦闘終了時に音量を下げることで再生を止めるような使われ方がされていて曲が止まらないという明らかにおかしな動作になっていた。

その作品では通常戦闘曲が音量操作によりフェードインするようになっているが内蔵版のXAudio2ではそれがなく、バグ報告後にある方にその点から音量の調整機能が動作していないのではないかという指摘を受けたので、DXライブラリの “メモリに読み込んだ音データの音量調整” 機能の挙動を小さなプログラムでテストした結果これがうまく動作しておらず、それが呼び出しているXAudio2内の多チャンネルの音量調整機能が未実装であることが分かり、指定された音量が全て同じ場合にだけその音量に変更する修正を試しに作ったらうまく動作したため、開発者に問題とその修正についてを知らせたところ、チャンネルごとに異なる音量を指定するプログラムは少数ではないかという考えから先述の形の修正でも受け付けるとのことだったので、途中で修正する点はあったものの、最終的にはその実装が取り込まれた。

これはバージョン3.1で修正済みだが、安定版の3.0.1では取り込まれなかったため、4.0が出るまでは開発版でしか修正されていない状態となる。

使用したバージョン:
  • Wine 1.8-rc4, 1.8, 3.9
  • Winetricks ca1a031 (2015/12/13)
[1]: ただし、2013年8月に公開されたバージョン2.10からの更新がずっとないため、2014年頃からはそのようなことは実際にはあまりない
[2]: エディタ側の仕様としてはMIDIデバイスに出力することも可能だが、同シンセサイザの使用が強く推奨されている
[3]: 以前に記事で扱った際にはこの方法が見つからず、バージョン1.31のファイル群で置き換えるといった対処をしていたが、不具合の原因となるためおすすめできない
[4]: Wineのバージョン1.2系時点では問題なかった
[5]: この不具合もDXライブラリのバージョン依存で、2015年時点ではバージョン2.10のみが影響を受ける
[6]: 1.7.55が最後の1.7系のバージョンとなり、安定版となるバージョン1.8のリリース候補を経て正式版の公開という流れとなった
[7]: バージョン2.10で用いられているDXライブラリ内の音声ファイル再生機能が正常に動作していない
[8]: DXライブラリの音声再生機能が正しく動作していないことが分かったので同ライブラリを用いた小さなテストプログラムを添えて既存のxaudio2_8関係のバグのページにコメントを入れていた