本来なら先月のウマ娘ネタの続きな記事を書く筈だったのですが…。 下のサイト移転告知で書いたとおり, サイトの空き容量がなくなり書けなくなってしまいました。 何しろ, 最低 1 GB 単位での容量増加は避けられず, 手元 PC 上で割当容量をオーバーしている状況では, 例え計算上大丈夫そうでも無理は出来ません。 (^^;)
そういった状況の ある日…。 旧 Twitter で Wine のネタが TL に流れてきました。 自身が拙作ソフトの動作確認用環境として VMware な仮想 PC で拵えているのは, Ubuntu 20.04 LTS + Wine 6.3 です。 極々普通の Windows ソフトですから, Ubuntu や Wine が どれだけ更新されようと状況は変わりません。 「32 ビット版アプリが使えなくなった」とかなら話は変わってきますが, 少なくとも現状は Wine 自体が寧ろ 32 ビット前提での運用となっているくらいですので。
とはいうものの, 4 年半近くも経つだけあって, OS は Ubuntu 24.04 LTS に, Wine も 10.9 と そろそろ 11.0 が登場しそうな気配です。 なので, テスト用環境を昨今のもので構築し直す事にしました。 ただ, Ubuntu のほうは 22.04 LTS を使う事にします。 というのも, 24.04 LTS は Ubuntu Japanese Team の 日本語 Remix ISO が用意されていないのですよね。 「今では ZIP 周りくらいしか弄るところがない」といった理由らしいのですが, 今までの経験や巷で聞こえてくるネタからは, 「いやぁ~, そんな事はないよね…」という感が強いのでした。 いや, 1 番の理由は, Live CD が英語環境専用になったり, インストーラー形式が変わったりした事ですけれども…。
という訳で, 今回の手順を大ざっばに纏めれば「VMware 12.5.9 上で Ubuntu 22.04 LTS 環境を構築の上 Wine 10.0 をインストールし, Winetricks で必要な処置を講じた後に各種 (動作確認用) ソフトをインストールして実行」という文になり, 冒頭右画像が その構築した環境で, 要は その状態へもっていくまでについて書いていこう…というわけなのでした。
Ubuntu と Wine のインストールについては端折ります。 Ubuntu は CD ブートしてインストールを選択するだけですし, Wine も WineHQ のダウンロードページの手順どおり…と言いますか, 寧ろ そちらに従わないと正しくインストールできなかったりしますから。 その中で, 今回は安定版を使いますので, 手順の中のインストール自体は, 最新版なら次のような指定となります。
sudo apt install --install-recommends winehq-stable
その点を頭に置いておいて, まずは大前提です。 4 年前な記事での環境である Ubuntu 20.04 LTS + Wine 6.0 と異なり, 今回試す Ubuntu 22.04 LTS や 24.04 LTS, そして Wine 8.0 以降では vulkan が必須で, さらに, Windows で言えば「DirectX 12 レベルが可能で当たり前」という前提で, OS・Wine が ある意味ノーチェックでインストールされます。
なので, 例えば 4 年半前に構築した Ubuntu 20.04 LTS + Wine 6.3 環境 (その後 1 番安定した 6.3 まで上げている。) について, Wine を 10.0 など 8.0 以降のものへ更新しようとすると:
画像を見てのとおり, OS 用の DirectX 12 対応モジュールをセットでインストールしようとします。 因みに, 当該環境は VMware と Wine 双方について OpenGL レンダラーを指定してあるのと, 元々 VMware 12.5 のゲスト PC 実行モジュール自体が DirectX 11 までしか対応していませんので, 更新 (インストール) を強行すると, 途中でアップデーターが Ubuntu 環境を破壊しアボートしてしまいます。 一旦そうなったが最後, OS を新からインストールし直すしかありません。 もっとも, ショットを録ってあれば, そこまで戻るだけですけれども…。
さらに, そろそろ Wine 11.0 も近い, 開発版で 10.9 まで進んでいる現状のリポジトリでは, 同じ vulkan 必須の Wine 8.0 以降のインストールについては, 例えば本体が Wine 8.0 でも, その下地となる各種モジュールについては Wine 10.0 のものがインストールされたりと, 頭から Wine 10.0 を入れるのと大差がなかったりします。 ダウングレード等を行っても, 純粋な Wine 8.0 等には出来ませんので御注意を。
現行でインストール可能な Stable 版は以下のとおり:
- Wine 10.0.0.0
- Wine 9.0.0.0
- Wine 8.0.0.0
- Wine 7.0.1
8.0 までは普通にインストールなりダウングレードなり出来ますが, 7.0 については, インストールの有無に拘わらず, 8.0 辺りで依存関係を構築し直さないと, 「見つからない」と怒られる可能性が高いです。 因みに, 例えば 8.0.x など Wine 8.0 で言えば 8.0.0 より後の Stable 版が, 各メジャー版で公開されていますが, 少なくとも現行リポジトリから直接指定してのインストールは行えませんでした。 7.0 の前の 8.0 のように, 色々と依存関係を調整するとインストールできるのかもしれませんが, そこまでは試していません。
先へ進む前に前提ですが, Winetricks で以下についてネイティブ版を適用しておきます:
あとは日本語環境ですが, お好みでフォントを選択した上で それにあった fakejapanese を適用してください。 ただ, 今では VLGothic を使えないので注意, ダウンロードに失敗します。 ほかにも重要そうなものを含めてダウンロードに失敗するものが多々あります。 今では必要ないからなのか英語環境では大丈夫なのか, 放置されているのでした。 なので all fonts のような一括系のダウンロードは総じて行えません。 下手に実行すると途中でスクリプトがアボートして, Wine 環境を初期化せざるを得なくなります。 (^^;)
さて, ここから順次ソフトを試していく訳ですが, まずは通常のソフトで Wine の動作を確認しておきます:
拙作の LHMelt です。 自己解凍書庫を実行すると展開先を聞いてきますが, 特に何も考えず そのまま「OK」を選択…と行きたいところなのですが, Wine は WinSFX32M のショートカット作成方法…つまり Windows 3.1 時代の DDE には未対応ですので, 関連付けはともかく, スタートメニューへの登録については無効化しておく必要があります。 (いくつもプログラムマネージャが起動され, 場合によってはエラーや警告も表示される。)
ファイルの展開自体は普通に行われますので, 展開先の LHMELT.EXE を実行すると普通に起動しました。 Wine 6.0 で大丈夫だった通常ソフトが 10.0 でダメだったりすると困ってしまいます。 (笑) それはともかく, 通常ソフトすらダメだった場合は, Wine か それこそ OS 自体の環境構築に問題があるということになります。
続いて, ここからが本番…Direct3D のテストです。 まずは DirectX 6.1 世代のソフトな Diablo Ⅱ から始めます。 この頃のソフトは DirectDraw と Direct3D を選択できたりと, テストには何かと都合が良いのでした。 DirectDraw が可能かどうかで「DirectX 自体が機能しているか否か」の切り分けも可能ですし。
先に書いておくと, ここが今回最大の難所でした。 なので少々詳しく説明します。 紆余曲折を経ていますので, ここから先では Wine 7.0 など別環境の画像も登場します。
Diablo Ⅱのインストーラはインストール時に 3 つのテストを行う関係上ログが煩雑になりますので, 単純化のために ここでは『大図書館の羊飼い』に御登場願っています。 上のほうで書いたように, 現状の Ubuntu や Wine は vulkan 必須ですので, 未対応の環境では左画像のように「libvulkan.so.1」…つまり libvulkan1 ドライバーがないと言ってきます。
ここで困りものなのは, Ubuntu 22.04 LTS 自体が vulkan 前提である事から, OS のインストール時に, その対応度に応じて環境が構築されてしまっている点です。 要は OS…つまり 64 ビット環境用としては, 未対応な環境なら, 既にソフトウェア処理な MESA 版 vulkan ドライバーが組み込まれてしまっているのでした。 そのため, ここで libvulkan1 をインストールしようとしても, 「インストール済」と怒られるか, MESA 版がインストールされるだけです。
「それなら Winetricks で OpenGL レンダラーを指定すれば良いのでは?」と指定してみると…。 右画像のとおり今度は libGL1…つまり OpenGL ドライバーがないと言ってきます。 嫌な事に, ここで libGL1 をインストールしても, vulkan 前提なので, OpenGL への対応如何に拘わらず, こちらも MESA 版がインストールされてしまうのでした。 OpenGL レンダラー自体拒否されていないのが救いでしょうか?
因みに, その Winetricks での OpenGL レンダラー指定…。 今はレガシー項目で推奨されていませんので, 今後指定できなくなる可能性が高いです。 (^^;)
Wine 10.0→9.0→8.0 とダウングレードしても状況は変わりませんでした。 「こりゃ OpenGL 時代の 7.0 まで下げないとダメかしら?」と Wine 7.0 で やってみたのが左画像です。 同じように libGL1 がないと言ってくるのでインストールしてみたら…, ここでも MESA 版でした。 OS インストールレベルでパターンが決定づけられてしまっているので, どうしようもありません。
と, ここで思いついたのが「OS が 64 ビットなのに対して Wine は 32 ビット」という点です。 「OS (64 ビット) が絡んでダメなのなら, 32 ビットだけ反映させれば良いのでは?」と やってみたのが次のとおり:
sudo apt install libGL1:i386
i386 指定で 32 ビットに限定します。 結果は…見事 VMware のドライバーを使用する形に構築できました。 それを そのまま Wine 10.0 環境で行えれば良かったのですが, 残念ながら そのままでは出来ませんでした。 OS インストール時の環境構築が影響して, i386 を指定しても MESA 版がインストールされてしまいます。 …残念。 (笑)
そこから さらに紆余曲折を経て辿り着いたのが右画像です。 OS や Wine 上は vulkan なまま, VMware のゲスト環境設定ファイルのほうのみ弄っています:
mks.enable3d = "TRUE"
svga.graphicsMemoryKB = "786432"
mks.enableDX11Renderer = "FALSE"
mks.enableD3DRenderer = "FALSE"
mks.enableGLRenderer = "TRUE"
関連性があることから一緒に並べてありますが, 上 2 行は設定ダイアログでの指定値です。 それはともかく何をやっているかというと, 順番に:
- 仮想環境の 3D 機能を有効化 (ダイアログ指定)
- VRAM 容量をメインメモリー 2GB での推奨値である 768MB に設定 (ダイアログ指定)
- (VMware の) DirectX 11 によるレンダリングを無効化
- DirectX 9.0 によるレンダリングを無効化
- OpenGL 3.3 によるレンダリングを有効化
といった感じです。 DirectX 11 でのレンダリング無効化は VMware 12 時代の定番設定です。 が, ここでは DirectX 方面無効化の一環として指定しています。 DirectX 9.0 でのレンダリング無効化は「そもそも DirectX を使用しないため」の指定で, その代わりとして OpenGL 3.3 によるレンダリングを有効化しています。
それを頭に置いて右画像を見てみると…。 OS や Wine 上では あくまでも vulkan 使用なので, libvulkan1 がないと言ってきています。 レンダラーも指定していないので特に申告なしで vulkan レンダラーが使用されます。 その上で, 組み込まれている VMware 環境用ドライバー段階で OpenGL が必要になったことから, libGL1 の警告が この段階で登場しています。
「お~? 何やら状況が変わってきたぞ~?」と:
sudo apt install libvulkan1:i386
sudo apt install libGL1:i386
で 32 ビット版ドライバーのみインストールしてみたところ…見事双方について VMware ゲスト向けドライバーがインストールされました。
こちらで libvulkan1 が VMware 環境用 32 ビット版ドライバーのみインストールできたのは, 上のほうの画像で見えた:
wined3d_dll_init Using the Vulkan renderer.
の行が こちらでは存在しない…つまりドライバー段階へ移る前に使用レンダラーが決定されていない辺りが関係しているのだと思います。 勿論 Wine 自体は vulkan 使用前提で処理が進んでいたでしょうけれどね。
ドライバーさえ組み込まれれば, 左画像のとおり DirectDraw と Direct3D の双方とも有効になります。 さらに, VMware ゲストの環境設定ファイルで再び DirectX 11 レンダラーを有効…つまり元に戻しても, Wine 10.0 上で Direct3D が可能なのでした。 綱渡りも良いところですね。 (笑)
この辺は環境次第です。 実機なら GeForce や Radeon などのドライバーを指定する事になるでしょう。 現行の VMware なら vulkan 動作なので最初から上手くいくかもしれませんし, 逆にトラブった場合に DirectX や OpenGL 指定が行えなくて詰むかもしれません。
Direct3D 関係が解決したのでソフト自体の話に戻って, 『Diablo II』は DirectX 6.0 世代のソフトで, DirectDraw と Direct3D の どちらでも動作しますが, 左画像のとおりインストール時の検査で Direct3D が認識され, 製品版でも ちゃんと Direct3D で動作します。 もっとも, 右画像の体験版に限っては, テスト結果に拘わらず強制 2D (DirectDraw) での動作となりますけれど…。 なので上手く動作しないのは DirectDraw レベルでダメという事になります。
左画像の『FINAL REALITY』は DirectX 6.1 時代の古なベンチマークです。 そして右画像は 3DMark 99 Max…なのですが, 残念ながら動作しません。 もっとも, 件のベンチは実機でも Windows Vista か Windows 9x でないと動作しませんけれど…。 「Win でダメでも Wine では動作」といったソフトがあったりしますので御登場願った訳ですが, Wine 6.0 時代と変わらずダメみたいですね。 わりと好きなベンチなので, 動作してくれると嬉しいのですけれど…。 (笑)
そうそう。 右画像で やたらとレジストリ絡みでエラーログを吐いているのは, 後ろのほうでネタが登場しますが, WMP 10 のインストール時に微妙に Wine 環境を壊されているからです。 (^^;)
続いては DirectX 7.0a 世代のソフトです:
まずは左画像の『3DMark2000』ですが, この辺りが動作してくれないと途方に暮れる事となります。 気分的には, 上の Diablo Ⅱが動作しなかったのと殆ど同じですね。 なので, ダメだった場合は根本的な部分から原因を探す事になります。 もっとも, Diablo Ⅱのテストで Direct3D が通って, 体験版も正常動作するのであれば, 恐らく 3DMark2000 も あっさり動作すると思います。 ダメな場合は…製品版の Diablo Ⅱでも Direct3D は使えない事でしょう。
続いて右画像の『恋色空模様』…。 プログラム上で そうなのかは別として, DirectDraw レベルで動作するイメージがありますので, 本編自体は 3DMark2000 が動作するなら, こちらも難なく動作する筈です。 フォントの関係で日本語表示が上手くいかないくらいでしょうね。
当該ソフトは実はインストーラーが ちょっとだけ曲者で, 日本語フォントへのエイリアスが不完全だと, InstallShild 系のインストーラーでの日本語表示が豆腐文字だらけになってしまいます。 そうなっていた際には, 場合によっては 3 種類ある中の別口な fakejapanese を Winetricks で組み込む必要があるかもしれません。 さらに本編でも, アクセラレーターの効きが弱いなど問題を抱えていると, 右画像のオープニング動画辺りがカクカクになってしまいます。 そういった意味で, 当該ソフトは 2D のアクセラレーターが効いているかどうかのチェックに使えます。
まずは左画像…。 『秋色恋華』を含めて「何故パープルソフトウェアの体験版ソフトをテスト用として使っているのか?」の答えが これです。 判る方には判るのですが, これは WinSFX32M…つまり拙作 UNLHA32.DLL が作成する LZH の Win32 ANSI 版自己解凍書庫なのでした。 初期の Wine では通常の Windows プログラムさえ動作しなかったりしたのもありますが, 自身の作るテスト用書庫と他者の使ってくれている書庫とでは, 状況が大きく異なりますので…。
右画像の『秋色恋華』本編は, 上の『恋色空模様』と同じく, DirectDraw だとか Direct3D だとかを気にせず起動できるクチです。 こちらは (過去において) 自己解凍書庫のテストが本命だったので, それで良いのです。 (^^;) ともあれ, この『秋色恋華』や上の『恋色空模様』といった辺りが動作しないようなら, 何か根本的な部分で問題を抱えていることになります。
ただ, 現在の Ubuntu や Wine は DirectX 9.0 世代以降しか気にしていない嫌いがありますので, 次の DirectX 8.0 世代を含めて, 「DirectX 9.0 未満だから」という理由で単純に動作しない可能性はあります。 それらの組み込みが, Wine 6.0 な頃と違って拒否されたり失敗したりしますし…。
お次は DirectX 8.0b 世代のソフトです:
『3DMark2001 SE』は, 上で挙げた『3DMark2000』が動作するのであれば, まず正常に動作します。 ちなみに, このベンチのデモを起動しようとすると右画像のように例外が発生します。 DirectX 8.0 世代ということもあって DirectSound 周りで引っかかっているのだと思いますが, これは Windows 7 以降の実機でも同じです。 自身の使っているホストなどでも同じで, それらの環境では元々互換性アシスタント機能で互換性設定を「Windows XP」にしないと動作しませんから, Wine 側に非はありません。 ちなみにサウンドをオフにすると あっさり動作しますが, 音なしのデモに意味があるのかは謎です。 (笑)
なお, Wine 上では Winecfg で Windows XP 等を指定しても動作しませんので, 念のため。 Wine が DirectX 周りを含む全 API での挙動を Winecfg の OS 設定に従って変えてくれるのなら可能なのでしょうが, そこまで対応される事は過去も未来もありませんから。 それ以前にソフトの個別指定が効きませんけれど。 (笑)
このベンチは 3D 機能への対応レベルを図る意味で多少なりとも活躍します。 対応度が足りないと, 一見正常動作しているように見えて, dragotic テストでドラゴンの角が白抜き・黒抜きになったり, Bump Mapping テストがスキップされたり色がおかしくなったりします。 後者は単に当該機能に対応できているか否かで, 前者はドライバー段階でのピクセルシェーダーへの対応度が影響して発生します。
昨今の実機で引っかかることは まずないと思いますが, VMware などの仮想 PC 環境では, 使用ソフトの版やホストとの相性で遭遇することがあるかもしれません。 VMware の linux ゲストで お目に掛かったことはありませんが, どうしても お目に掛かりたいなら VMware 6.0 + Windows ゲストで試すと良いでしょう。 (^^;)
左画像の『FORTUNE ARTERIAL』, 右画像の『夜明け前より瑠璃色な』共に, DirectX の存在を忘れるほど あっさりと何も問題なく動作しますが, 動作要件自体としては DirectX 8.0b を必要としますし, 実際エフェクトの表示などで専用機能を使っています。 ちなみに TECH GIAN 版の登場が多い理由は, その当時に献本を受けていたからです。 (笑) 編集部からの問い合わせは無かったはずですが, 一般ユーザー (読者) からの問い合わせには何度も遭遇しましたので, 献本自体には ちゃんと意味があったようです。 (元々それ用の献本で別冊系なしな本誌のみ。)
『Prism Rhythm』も あっさりと動作するクチではあるのですが, このソフトには「DirectX 9.0 レベルまで含めて, ほかのソフトは大丈夫なのに, 何故か このソフトだけ異常に描画が遅くなる」という現象の発生する環境が出るので, 御登場願っています。 当該環境では大丈夫でしたが, 実機でも発生する不具合だったりします。
以上, ここまでは 3DMark の類いを除いて 3D 機能への対応度が比較的低い Wine 環境でも動作するソフトばかりでした。 一方, ここからは OS や Wine が ちゃんと 3D に対応していないと動作しないソフトばかりとなります。
まずは一部の機能について DirectX 9.0c を必要としているソフトです:
『Wiz ANNIVERSARY』はエフェクト表示などで DirectX 9.0 の機能が使用されていて, 対応度が低いと起動時のシステムチェックで跳ねられてしまいます。 それをクリアーしたとしても, 起動直後のブランドロゴやタイトル画面での表示がおかしいようなら, さらに環境を整える必要があるということになります。 余談ですが, Wine 7.0 環境では最後まで このソフトで正常な描画を行えませんでした。
ちなみに, この体験版には ちょっと癖があって, 付属の DirectX 9.0c をインストールしないと正常動作しない環境が多々発生するのでした。 その辺りもあって, ちょくちょく仮想 PC 環境の動作確認用として御登場願っています。 (笑)
右画像ですが, ドライバーと DirectX それぞれの版の違いによる相性問題が発生したり, 微妙に対応度が足りなかったりすると, セーブ・ロード画面でのサムネイル表示が黒抜きになったりします。
『プリミティブリンク』でも画面の拡大や縮小を伴ったスクロール, 特定領域でのクリッピングや座標変換を伴っての複数動画再生 (要は いろいろな方向を向いたテクスチャー上での再生), エフェクト, そして それらの透過を伴った重ね合わせ…といった特定用途のために DirectX 9.0 や Direct3D の機能が使用されています。 この世代では「DirectX = Direct3D」といった雰囲気がありますので, ちゃんと 3D 機能にも対応していないと DirectX 自体が上手く動作しません。
ちなみに, 対応度が足りないと左画像のプロローグ冒頭ブランドロゴすら正常に表示されません。 そして, このソフトも Wine 7.0 環境では最後まで正常動作しませんでした。
一見 Wine 10.0 では正常動作しているように見えたプリリンですが, 画像のとおりセーブ・ロード画面でサムネイルの黒抜きになってしまう不具合が発生しています。 上で説明した『Wiz ANNIVERSARY』と同じパターンの相性問題でしょうから, 取りあえずは放置しています。
吉里吉里系を代表して『のーぶる☆わーくす』です。 吉里吉里といえば例の「Windows 8 以降の x64 版 OS で動作しない」という有名どころの不具合があり, それは x64 環境の Wine でも同じだったりします。 (対処法も同じ) その一方で今回は x86 環境ですから普通に動作します。
このソフトでは初回起動時に GDI/DirectDraw/Direct3D が自動認識されます。 そして, ブランドロゴから本編まで, GDI なら GDI, Direct3D なら Direct3D で全て等しく描画される関係上, 一旦転けると全てにおいて転けてしまうのでした。 右画像のとおり, あとから描画方法を変更できますので, 問題の切り分けに使えるでしょう。
この表示方式の変更メニューはチェックとしても使えます。 例えば, 最初このメニューを表示した際に Direct3D が選択…つまり初回起動時に Direct3D が認識されていたとします。 次に ここで自動設定を選択したとして, 再起動後に同じ Direct3D が自動設定として選択されていなければ, その環境の DirectX には, どこかに問題の種が潜んでいる事になります。
あ, そうそう。 『のーぶる☆わーくす』限定ですが, 体験版と異なり, 製品版では Windows 8 以降の x64 版 OS でも例の不具合は生じず普通に動作します。 要は吉里吉里本体ではなくプロテクトを含めたプラグイン系の問題ということですね。
『Pia♥キャロ動作検証版魔女っ娘ア・ラ・モードII』です。 何を言っているのか解らなくなるソフト名ですが, 要は「『Pia♥キャロットへようこそ G.O.』で採用予定のゲームシステムを使って, 体験版の魔女っ娘ア・ラ・モードIIを焼き直して作った」ソフトです。 動作確認用のソフトなので, オリジナルの体験版とは ちょっと内容が異なっているのでした。
それはともかく, このソフト…。 Direct3D に対応し始めたばかりだった VMware 5.0 の「Direct3D 関係について, 骨組みだけで およそ何も実装されていない」環境でも完動したりします。 その一方で, 実は何気に DirectX 9.0 を必要とし, さらに全体的に安定していないと転けたりする, 意外にも安定度を確かめるのに使えるソフトだったりします。
画像のシーンでも, ヒロイン達の後ろで別の 2 つの動画が左右 2 分割で流れ続けていますし, その上でメニューの一部が Direct3D の機能で表示されていたりするのでした。
最後は DirectX 9.0c を必要とする Direct3D 対応ソフトです:
左画像が『3DMark03』で右画像は『3DMark05』です。 この 2 つは最新版を使用しないと「Invalid Float Operation」の一般保護エラーが発生してデモやテストを実行できません。 その点を除けば意外とあっさり動作します…と書きたいところだったのですが, 残念ながら Wine 10.0 な当該環境では 3DMark05 が落ちてしまうのでした。 それも OS レベルではチェックが入らず, VMware の仮想 PC 実行モジュール段階でチェックが入り, 仮想 PC 自体が強制終了される重傷パターンです。
幸い, VMware により制御されたエラーなので, それに至った詳細ログも記録されますし, ゲスト環境が壊れる事もありません。 Ubuntu 内でエラーにならないのは, ここまでで何度も書いているとおり, DirectX 12 レベルが前提なので, その辺りのチェックを そもそも行っていないからです。 OS にしろ Wine にしろ, そのインストール時にチェックを行って, ダメなら無効化や MESA 版を適用している訳ですから。 無理矢理抜け道を使って VMware 用ドライバーを機能させている こちらに非があります。 (VMware 12.5 は DirectX 11 止まり)
ちなみに, 3DMark2001 と異なり 3DMark03 以降のデモは普通に正常動作します。 (笑) あと, 3DMark03 はネイティブ版の DirectX だと そこかしこで色がおかしくなりますので, 内蔵版を使ったほうが安定します。 可能なら設定を使い分けると良いでしょう。 もっとも, 殆どのソフトで Wincfg での個別設定が効かず, x64 環境なぞは全滅だったりしますけれど…。 (^^;)
VMware を巻き込んでエラーとなってしまう 3DMark05 でしたが, その一方で左画像のとおり『3DMark06』は あっさりと動作してしまいました。 (笑) 結果論ですが, Wine 6.0 時代と比べて問題があるのは 3DMark05 だけですし, 過去に Windows 環境の実機やゲストでも「3DMark05 だけ落ちる」という状況に遭遇した覚えがありますので, 取りあえず様子見で放置する事にしました。 恐らく相性問題のレベルでしょうし…。
右画像は FINAL FANTASY Ⅸの『Vana'diel Bench 3』です。 DirectX 9.0 レベルが大丈夫なら あっさり動作するクチですが, ホストやゲストの能力が高くないと重いのだけは どうしようもないですね。 (笑)
左画像の『STREET FIGHTER IV Benchmark』は比較的あっさりと動作する代わりに, 「まともに使えるのか?」の指標として使えます。 この画像の例も該当しますが 60 FPS に届かないとゲームにならず, このベンチでは それが「台詞 (のサウンド) とキャラの動きがずれる」という形で表面化します。 (サウンドでは とっくに喋り終わっているのに, キャラ (の描画) が喋り続ける。) さらに, Direct3D への対応度が低いと, 対戦 3 つを終えた後の, キャラ達が円陣を組んでグルグル回るベンチの段階で落ちたり描画が崩れたりします。
一方, 右画像の『メギドベンチ』は, 3DMark06 と同様に比較的テクスチャーなどの使用量が多いことから, 機能の可否ではなく その能力的指標を計るものとして使えます。 能力が不足すると, まずはベンチ後半でのテクスチャーの ちらつきや (色の) 反転といった形で表面化し, さらに不足しているようだと 2 週目ベンチの切り替わりタイミングでエラー終了してしまいます。 当該ベンチでは高低 3 段階の画質として負荷のレベルを変えられますので, いろいろ試してみると良いでしょう。
左画像の『「ぐるみん」ベンチ』は, Direct3D の要求度合いは『3DMark03』以降と同レベルながら, それらの中で最軽量組の指標として使えます。 これの平均スコアが 10000 を切るようなら, それが可能だったとして, Wine で Direct3D 対応ソフトを使うのはゲームでなくとも無理と言えるでしょう。 ちなみに, このベンチは DirectX 9.0 と DirectX 8.0 を選べますので, 「DirectX 8.0 世代のソフトが遅い」といったような現象に遭遇したケースなどには, ヒントになるかもしれません。
そして右画像の『タイムリープぶーとべんち』は, 総合的な対応度の指標として使えます。 対応度が問題外に低いと, 最初に表示される設定ダイアログにすらたどり着けません。 次に動画方面がダメだとタイトルロゴ等が正常描画されません。 さらに Direct3D の対応度が低いと, ストーリーモード開始時でタイトルが綺麗に流れなかったり, そもそも上手く描画されなかったりします。
それらをクリアーしたなら意外と あっさりベンチ自体は動作すると思いますが, 当然ながら ここで設定どおりの描画が行われないなら, 個別処理に問題ありということになります。 アンチエイリアス, HDR, セルフシャドウ, ソフトフィルタ, 被写界深度, そしてバックハイライトと色々指定できますので, オンオフして試してみると良いでしょう。 もっとも, ピクセルシェーダー 2.0 以上で機能するものばかりなので, あまり凝ったレベルの確認は行えませんけれど…。
あと, 当該ベンチはウイルス対策系ソフトに良く引っかかるクチですので御注意を。 例えば Norton 系で引っかかる可能性は高いです。 現行の 360 では検疫で強制削除や隔離までは されないようですけれど。 (^^;)
…と各種のソフトを試した後のラスボスに君臨するのが『千の刃濤、桃花染の皇姫』と『SCHOOL DAYS』(HQ 含む) です:
まず千桃ですが, 対応度が低いと右画像など各種場面変更時に一般保護エラーで落ちます。 ダメな環境では開始早々から遭遇する事になるでしょう。 そこまで行かずとも黒抜き画面になってしまったりしますので, 最終的な対応度の確認に使えます。 エフェクトなどはゲーム自体を知っていないと, 描画されていなくとも「そんなものか」とスルーしてしまうかもしれませんね。 寧ろ描画の乱れてくれたほうが有り難いかもしれません。
そして, ある意味最大の難関…『School Days HQ』です:
オリジナルは今では体験版が入手できませんから, HQ のほうで試しています。 いや, 自宅内に限定しても, どこかを探せば発掘可能ではある筈なのですけれどね…。 (^^;)
それはともかく, このゲームは「最初から最後まで ほぼ全てが動画」と言っても過言ではないレベルでアニメ進行しますので, Direct3D を要求するソフトとは言っても大きく毛色が異なります。 そういった意味を含めてのラスボス認定です。
というわけで左画像ですが, このタイトル画面が表示された時点では何も安心出来ません。 対応度が足りないと, 直後の右画像…つまり 1 話が始まった途端, 黒画面のまま むなしく車や電車の音だけが聞こえてくる悲しい事態に陥ります。 端末のほうに吐き出されているログを見ると判るのですが, 結果論としては WMP をインストールして ASF…つまり WMP ファイルのデコーダーを組み込むしかありません。
大昔の Wine 6.0 時代から そうなのですから, 対応して欲しいところではあるのですが, 動画関係はデコードにしろエンコードにしろコーデックが権利で縛られまくっていますので, 形式別に本家筋や広く一般に公開されているモジュールをインストールするしかありません。
因みに, Wine 6.0 時代は WMP9…つまり Windows Media Player 9 をインストールできたのですが, 今ではダウンロードに失敗してしまうので使えません。 逆に WMP 11 をインストールしようとすると, スクリプトが途中でアボートする上に Wine 環境が OS ごと破壊されます。 OS からインストールし直さないと, Wine レベルのみでの復旧は出来ないので注意が必要です。
その間の WMP10 ですが, こちらも WMP10 用下地モジュールのインストールに失敗し, スクリプトこそ中断されませんが, 環境が微妙に破壊されます。 要は Winetricks を使う限り WMP を正常にインストールする手段はないという事ですね。 (^^;) なので, 自前で直接インストールするしかない訳ですが, 依存関係を解決するように下地モジュール (WMP 関連の個別コーデックなど) のインストールと (Win としての) 登録を行うのは やっかいなので, 簡単には行かないと思います。 その辺りもあって, WineHQ や海外サイトのコミュニティーでも「これ」といった解決策は全く挙がっていないのでした。
動画方面が全てのように思える SDHQ ですが, 右画像のようにメニュー表示などで Direct3D の機能を使用していますので, 動作要件的には DirectX 9.0c を必要としますし, 実際入っていないと正常動作しません。 もっとも, Wine 内蔵のモジュールで大丈夫なので手間は掛からないわけですけれど…。 ある意味「通常シーン (の動画) とメニュー以外凝ったことをやっていない」と言えますので, それらさえ大丈夫なら, あとは正常に動作し続けます。
ここまで挙げた各種ソフトが動作する環境を整えられれば, あまり Direct3D 方面で困ることは なさそうです。 次の関門は DirectX 10 かしら? Wine が OpenGL 3.3 レベルで やりくりしてくれると何とかなりそうなのですが, それ以上を必要とするのであれば逆立ちしても無理ですね。 VMware 12.5 は OpenGL 3.3 までしか対応していませんから…。 DirectX 12 レベルを要求する現状では無理な相談でしょう。 新機種購入以降に期待するしかなさそうです。 (笑)
余談ですが, BD 再生ソフトも試してみたのですが駄目でした。 WinDVD はインストーラー自体が異常終了しますし, PowerDVD はインストールは可能でもアクティベートできません。 root 環境を構築する方法もありますが, それで動作しないソフトも多々ありますから, 大きいリスクを払うほどの価値があるとは思えません。
少々脱線して余談モードです:
まず上段左画像ですが, 古な Windows 用 OpenGL ベンチである『GL Excess』です。 何の問題もなく普通に動作する訳ですが, 当該環境で行われる「OpenGL→vulkan→OpenGL→DirectX」な変換が, 無駄といいますか笑えてしまいます。 (笑) つまり「OpenGL (GL Excess) → vulkan (OS・Wine) → OpenGL (SVGA ドライバー) → DirectX (VMware)」という流れですね。
一方の上段右画像…。 体験版の『穢翼のユースティア』ですが, 当該ソフトは AGP メモリー必須なので動作しません。 OS インストール時に組み込まれる VMware 用ドライバーが対応すれば可能になりますが, こと Ubuntu 22.04 LTS に組み込まれているオープンソースな VMware 用ドライバーは, 対応していないという事なのでしょう。 VMware 自体は 7.1 以降の仮想 PC 実行モジュールで対応しています。 (WDDM 版ドライバーで可能)
体験版はダメですが, 製品版では AGP メモリーが必須ではなくなっていますので, 下段画像のとおり普通に動作します。 必要な対応度は千桃と同じ程度かしら?
話を戻して, 複数のソフトを同時動作させると, こんな感じの冒頭で挙げた画像になります:
個別ソフトでのテストが終了したら, 最後に複数の Direct3D 対応ソフトに加えて非対応ソフトも同時に動作させてみましょう。 少々重くなるのは仕方がないとして, その状態で ある程度色々やって大丈夫なら, Direct3D への対応は概ね問題ないと言えます。 後は相性など個別の問題や調整ですね。
で, これらが正常かつ快適に動作するような環境を整えられて, そこから初めて巷のゲームソフトなどに手を出せる事になります。 もっとも, 自身に限って言えば, 自作ソフトの動作確認が主目的で, Direct3D 関係は興味で試しているだけですから, ここから先へ進む事はありません。 (笑)
…といった感じで, 今回は Ubuntu 22.04 LTS + Wine 10.0 な環境を構築してみました。 Staging な 10.9 だと少々描画が崩れたりしますが, それが修正項目や新機能の関係で起こっているのかは判りません。 逆に, 8.0 や 9.0 については, 最初のほうで書いたように 10.0 を入れるのと あまり変わりません。 OpenGL レベルな 7.0 は今回の 10.0 と殆ど同じレベルな対応度ですが, winegstreamer DLL への移行途中なこともあって, Wine 6.0 よりは安定度が劣っているようでした。
Ubuntu 20.04 LTS + Wine 6.3 時代と比べても, 3DMark05 くらいしか明確な不具合は発生していませんので, テスト環境としては, 今後は こちらを主体として使っていく事になりそうです。
|