「ゲーム」の版間の差分

提供: ArchWiki
ナビゲーションに移動 検索に移動
imported>Alad
(rm cedega, dead project)
 
細 (1版 をインポートしました)
(相違点なし)

2015年1月10日 (土) 00:11時点における版

関連記事

このページではゲームの実行と関連するシステム設定に関する情報のみを集めています。GNU/Linux 向けの人気ゲームの一覧は List of Games を見て下さい。

ゲーム環境

Linux でゲームを遊ぶための環境は様々なものが存在します:

  • ネイティブ – Linux 向けに書かれたゲーム (大抵はフリーでオープンソース)。
  • ブラウザ – この種のゲームをプレイするのに必要なのはブラウザとインターネット接続だけです。
    • プラグインベース – 遊ぶためにはプラグインのインストールが必要です。
      • Java Webstart – クロスプラットフォームのゲームを簡単にインストールするのに使われます。
      • Flash ゲームはウェブ上で最も一般的なゲームです。
      • Unity – ブラウザ向けに特化されたゲームプラグイン。現在は Google Chrome 上だけで動作します。ほとんどのゲームは商用だったりクローズドソースです。
    • HTML 5 によるゲームは新しい canvas と WebGL テクノロジーを使います。全てのモダンブラウザで動作しますがマシンの性能が低いと実行が非常に遅くなります。
  • 専用環境 (ソフトウェアエミュレータ) – 他のアーキテクチャや環境のために作られたソフトウェアを実行するのに必要です (あなたの国の著作権法に注意)。詳しくはエミュレータのリストを見て下さい。
    • Wine – 膨大な Windows ソフトウェアだけでなく、Windows のゲームの実行も可能にします。Wine ではゲームのパフォーマンスが下がらないため (むしろ高速に動作することもあります)、Windows で動作するシステム要件が低いゲームならば大抵は Wine でも動作します。ゲームごとの互換性の情報は Wine AppDB を見て下さい。
    • Crossover Games – Codeweavers チームのメンバーは Wine の主要なサポーターです。Crossover Games を使うことでゲームのインストールや設定を楽にしたり、他の方法を使うのと比べて信頼性を高めたりすることができます。Crossover は有料の市販品ですが、開発者がコミュニティと対話できるように フォーラム が用意されています。
    • DosBox – DOS エミュレータ。
    • scummvm – 多数のクラシックなアドベンチャーゲームで使われていた SCUMM ゲームエンジンのゲームをエミュレートします。
  • ハードウェアエミュレータ – ソフトウェア環境ではなくデバイス全体をエミュレートします。著作権については同じです。

ゲームの取得

ネイティブ

公式リポジトリや AUR からかなりの数が入手できます。Loki はいくつかのゲームのインストーラーを提供しています。

デジタル配信

  • Desura — インディーゲームに特化したデジタル配信プラットフォーム。豊富なゲームがあると考えてよいでしょう (セキュリティやバグがあまり気にならないならば)。
http://www.desura.com/ || desuraAUR
  • Steam — Valve によって開発されている著名なデジタル配信とコミュニケーションのプラットフォーム。最近 Linux に (開発会社によって) 移植された有名ゲームが揃っています。Source (Half-Life 2) や Goldsource (HL1) エンジンのゲーム, Serious Sam 3, Brutal Legend, 多数の Humble Bundles のゲームやその他のインディータイトルなどを含んだ巨大なライブラリが存在します。
http://store.steampowered.com || steam

Flash

巨大な Flash ゲームポータルがいくつか存在しています、例えば:

Java

Wine

  • Wine におけるゲーム (やその他のアプリケーション) の実行については Wine AppDB に情報が集積されています。
  • Category:Wine も参照。

playonlinux を使うのが (特に初心者には) おすすめです。必要な依存パッケージが全てインストールされ、最初の起動時に Windows ツールを自動でダウンロード、ネイティブの windows アプリケーションが正しく実行されるように設定を行います。詳しくは、公式ウェブサイトを見て下さい。

ゲームの実行

特定のゲームや、ゲームのタイプによっては実行するのに特別な設定を必要としたり、または設定されていることが前提になっていることがあります。大抵のゲームは、何も設定をしなくても Arch Linux で動作し、コンパイル時の最適化によって、他のディストリビューションよりもパフォーマンスが出ることもあります。しかしながら、特別な環境を使っている場合、希望通りにゲームをスムーズに実行するために多少の設定やスクリプトが必要になるでしょう。

マルチスクリーン環境

マルチスクリーン環境ではフルスクリーンのゲームで問題が発生することがあります。そのようなときは、別の X サーバーを実行するのが一つの解決方法になりえます。他の方法は NVIDIA の記事を見てみて下さい (NVIDIA 以外を使っているユーザーも見る価値があります)。

キーボード操作

多くのゲームはキーボードの入力を横取りするため、ウィンドウの切り替え (alt-tab) ができなくなることがあります。

SDL のゲーム (例: Guacamelee) では Ctrl-g を押すことでキーボードの占有を無効にすることが可能です。

また、sdl-nokeyboardgrabAUR をダウンロードすることでも SDL のゲーム中にキーボードコマンドを使えるようにすることができます。さらに、libx11-nokeyboardgrabAUR を使うことで X11 レベルでキーボードの占有を無効にしたり、libx11-ldpreloadnograbAUR で LD_PRELOAD を使って特定の占有を止めるようにしてアプリケーションを実行するなど細かい制御をすることもできます。Wine/lib32 ユーザーは各 lib32 ライブラリにも気をつけて下さい。

ノート: SDL はときどき入力システムを使うことができなくなることが知られています。そのような場合は、数秒間待機すると入力できるようになることがあります。

別の X サーバーでゲームを起動する

上記のような場合だと、別の X サーバーを実行するのが必要もしくは望ましいかもしれません。二番目の X サーバーを実行することには複数の利点が存在します。より良いパフォーマンス、Ctrl+Alt+F7/Ctrl+Alt+F8 を使ってゲームを"最小化"することができる、ゲームがグラフィックドライバーと問題を起こしてもメインの X サーバーはクラッシュしないなどです。新しい X サーバーは ALSA へのリモートアクセスログインと同じく、ユーザーは音声を聞くために audio グループに入っている必要があります。

別の X サーバーを起動するには次のようにします (例として Xonotic を使っています): 

$ xinit /usr/bin/xonotic-glx -- :1 vt$XDG_VTNR

さらに、別の X 設定ファイルを使うことでちょっとしたスパイスを振りかけることができます: 

$ xinit /usr/bin/xonotic-glx -- :1 -xf86config xorg-game.conf vt$XDG_VTNR

別の xorg.conf を使う理由としては、メインの設定では、NVIDIA の Twinview を使って Xonotic のような 3D ゲームをマルチスクリーンの中央、全ての画面にまたがって、レンダリングしているのが考えられます。これが望ましくない場合は、二番目の X を起動してセカンドスクリーンを無効にした設定を使うようにするというのが良いでしょう。

Openbox を利用してホームディレクトリや /usr/local/bin でゲームを起動するスクリプトは以下のようになります: 

~/game.sh
if [ $# -ge 1 ]; then
        game="$(which $1)"
        openbox="$(which openbox)"
        tmpgame="/tmp/tmpgame.sh"
        DISPLAY=:1.0
        echo -e "${openbox} &\n${game}" > ${tmpgame}
        echo "starting ${game}"
        xinit ${tmpgame} -- :1 -xf86config xorg-game.conf || exit 1
else
        echo "not a valid argument"
fi

chmod +x したら、次のようにしてスクリプトを使うことが可能です: 

$ ~/game.sh xonotic-glx

マウス検出の調整

マウスの素早い操作が鍵を握るゲームの場合、マウスのポーリングレートを調整することで精度を上げられます。

OpenAL とバイノーラル音声

OpenAL を使っているゲームでは、ヘッドフォンを使用している場合、OpenAL の HRTF フィルターを使ってより良いポジショナルオーディオを得ることができます。有効にするには、次のコマンドを実行して下さい: 

echo "hrtf = true" >> ~/.alsoftrc

または、AUR から openal-hrtfAUR をインストールして、/etc/openal/alsoftrc.conf のオプションを編集して下さい。

Source エンジンのゲームの場合、HRTF を有効にするにはゲーム内設定の `dsp_slow_cpu` を `1` に設定します。設定しなかった場合は代わりに自前の処理がゲームによって有効にされます。また、ネイティブランタイムを使うように Steam を設定するか、または openal.so のネイティブランタイムのコピーをローカルコピーにリンクさせる必要があります。完全性のために、以下のオプションを使って下さい: 

dsp_slow_cpu 1 # Disable in-game spatialiazation
snd_spatialize_roundrobin 1 # Disable spatialization 1.0*100% of sounds
dsp_enhance_stereo 0 # Disable DSP sound effects. You may want to leave this on, if you find it doesn't interfere with your perception of the sound effects.
snd_pitchquality 1 # Use high quality sounds

Pulseaudio の調整

Pulseaudio を使っている場合、最適な動作をさせるためにデフォルト設定から変更することができる部分がいくつかあります。

realtime プライオリティと負の nice レベルを有効にする

Pulseaudio はオーディオデーモンとしてリアルタイムの優先度で実行されるようにビルドされます。しかしながら、システムがロックアップする可能性があるというセキュリティ上のリスクのため、デフォルトでは標準のスレッドと同じようにスケジューリングされます。これを変更するには、まずユーザーを audio グループに追加してください。そして、/etc/pulse/daemon.conf の以下の行をアンコメント・編集してください: 

high-priority = yes
nice-level = -11

realtime-scheduling = yes
realtime-priority = 5

編集したら pulseaudio を再起動します。

高品質なリミックスを使ってサウンドを良くする

Arch の Pulseaudio ではリミックスチャンネルにデフォルトで speex-float-0 を使っていますが、これはやや低品質なリミックスとされています。あなたのシステムに負担を増やす余裕がある場合は、以下のどちらかの設定をすることでサウンドを良くすることが可能です: 

resample-method = speex-float-10
resample-method = src-sinc-best-quality

ハードウェアバッファを Pulse のバッファリングに合わせる

バッファをあわせることで音の途切れを減らし、ほんの僅かですがパフォーマンスを向上させることができます。詳しくは ここ を見て下さい。

Cgroups

Cgroups はプロセスをグループでまとめてユーザースペースで優先順位を付けて、レイテンシーを最小限にすることができるカーネルのアジャストメントです。IO の優先順位や CPU の優先順位など、複数のファクターを調整することができます。

方法 1 - systemd (推奨)

Systemd は Cgroups を暗示的に管理することができ、多数のスレッドが実行しているシステムをスムーズに動作させます。

インストールするだけでこの動作の改善が行われます。

CPU 周波数スケーリングの設定を確かめる

適切な cpu 周波数スケーリングドライバーを使うように正しく設定されている場合、システムはデフォルトの governor を Ondemand に設定します。デフォルトでは、この governor はシステムが CPU の 95% を利用しているときのみ、非常に短い時間だけ、クロックを変更します。この設定では、電力が節約され熱が少なめですむ代わりに、パフォーマンスにかなり影響を与えることになります。システムの governor をチューニングすることで、ダウンクロックするのをアイドル状態の時だけに限ることが可能です。詳しくは Cpufrequtils#ondemand governor を調整する を参照。

スケジューリングポリシーによってフレームレートやレスポンスを改善する

カーネルがタスクに優先順位をつけるのに適切なスケジューリングポリシーを設定することはほとんどのゲームで有利に働きます。しかしながら、デーモンの助けを借りない場合、この再スケジューリングは手動で実行するかポリシーごとに複数のデーモンを使う必要が出てきます。これらのポリシーはアプリケーション自身によってスレッドごとに設定されるのが理想的なのですが、全ての開発者がポリシーを実装しているわけではありません。なんとかポリシーを正しく使うための方法というのが複数存在します:

Wine プラグラムの場合

wine-rtAUR はスレッドごとの基準によるスケジューリングポリシーを実装したパッチがあてられた Wine で、Windows の開発者が意図したスレッドの動作方法と同じように動きます。デフォルトのパッチはどちらかというとプロフェッショナルオーディオのユーザーを対象としており、ゲームを遊ぶためとしては手に余るところがあります。nice レベルが含まれ複数のポリシーを使用する、このパッチ を使用したほうが良いかもしれません。このパッチは Linux-ck でしか実装されていない SCHED_ISO を使用し、あなたのシステムにサポートがない場合は、代わりに THREAD_PRIORITY_ABOVE_NORMAL スレッドの renice を行うので注意してください。

その他の場合

スケジューリングポリシーを実装していないプログラムのために、schedtool というツールとそのデーモンである schedtooldAUR でタスクを自動的に処理させることができます。プログラムをどのポリシーに交代するのか編集するには、/etc/schedtoold.conf を編集してプログラムを追加してください。

ポリシー

何よりもまず、スケジューリングポリシーを SCHED_ISO に設定することで、プロセスが CPU の最大80%まで使用できるようになるだけでなく、できるかぎり遅延を減らすことにつながります。SCHED_ISO を使うには Linux-ck が必要です。SCHED_ISO は linux-ck でしか実装されていません。Linux-ck 自体にも遅延を減らす工夫があるので、インストールするべきでしょう。全てではなくとも多くのゲームで効果が得られます: 

bit.trip.runner -I

For users not using Linux-ck, SCHED_FIFO provides an alternative, that can even work better. You should test to see if your applications run more smoothly with SCHED_FIFO, in which case by all means use it instead. Be warned though, as SCHED_FIFO runs the risk of starving the system! Use this in cases where -I is used below: 

bit.trip.runner -F -p 15

Nice レベル

Secondly, the nice level sets which tasks are processed first, in ascending order. A nice level of -4 is reccommended for most multimedia tasks, including games: 

bit.trip.runner -n -4

コアアフィニティ

There is some confusion in development as to whether the driver should be multithreading, or the program. In any case where they both attempt it, it causes drops in framerate and crashes. Examples of this include a number of modern games, and any Wine program which is running without GLSL disabled. To select a single core and allow only the driver to handle this process, simply use the -a 0x# flag, where # is the core number, e.g.: 

bit.trip.runner -a 0x1

uses first core. Some CPUs are hyperthreaded and have only 2 or 4 cores but show up as 4 or 8, and are best accounted for: 

bit.trip.runner -a 0x5

which use virtual cores 0101, or 1 and 3.

一般的なケース

For most games which require high framerates and low latency, usage of all of these flags seems to work best. Affinity should be checked per-program, however, as most native games can understand the correct usage. For a general case: 

bit.trip.runner -I -n -4
Amnesia.bin64 -I -n -4
hl2.exe -I -n -4 -a 0x1 #Wine with GLSL enabled

etc.

Optimus やその他の便利なプログラム

As a general rule, any other process which the game requires to operate should be reniced to a level above that of the game itself. Strangely, Wine has a problem known as reverse scheduling, it can often have benefits when the more important processes are set to a higher nice level. Wineserver also seems unconditionally to benefit from SCHED_FIFO, since rarely consumes the whole CPU and needs higher prioritization when possible. 

optirun -I -n -5
wineserver -F -p 20 -n 19
steam.exe -I -n -5

別のカーネルの使用

ノート: Linux-ck を使用していると、全体的なフレームレートは向上しつつも、フレームレートが安定しなかったり他のパフォーマンスに問題が起こったりするということを多数のユーザーが報告しています。それでも BFQ を使ってみたい場合は BFS スケジューラを無効にして Linux-ck をコンパイルしてみると良いかもしれません。

標準の Arch カーネルは一般的な使用のためのベースラインとしては十分です。しかしながら、あなたのコンピュータに搭載されたコアが16未満で、主にワークステーションとして使っている場合、バッチ処理のスループットを多少犠牲にして Linux-ck を使用することで大幅なレスポンスの向上を得ることができます。自分でカーネルをコンパイルしたくないのならば、Repo-ck を追加して、このリポジトリに入っているカーネルを使うこともできます。事前に最適化済みのカーネルを使用することは、結果として生じる可能性のあるスループットのロスとの相殺に必ずなるので、あなたが使っているアーキテクチャに相応しいカーネルを選択するようにしてください。

BFQ を使う

BFQ は Linux-ck に付いている io スケジューラであり、シンプルになるように最適化されており、サーバー以外のワークロードに対してよりよい応答性とスループットを実現します。有効にするには、linux-ck#BFQ I/O スケジューラを有効にする方法を見て下さい。多くのガイドでは SSD には noop や deadline を使うことが推奨されていますが、複数のスレッドがデバイスにアクセスしようとしたときに応答性に悪影響を及ぼすことがあるので注意してください。スループットのアドバンテージがどうしても必要というわけでもない限り bfq を使用するのがベストです。

参照

  • LinuxGames - linux ゲームのニュース
  • OSGameClones - オープンソースのゲームクローンリスト
  • Free Gamer - オープンソースゲームのブログ
  • FreeGameDev - フリー・オープンソースゲームの開発コミュニティ
  • SIG/Games - Fedora の wiki にある OS/Linux ゲームニュースサイトとゲームの一覧
  • live.linux-gamers - Arch ベースのライブゲームディストロ
  • Games on Linux - Linux の商用ゲーム
  • Gaming on Linux - アクティブな Linux ゲームニュースとソース、コミュニティ
「https://wiki.archlinux.jp/index.php?title=ゲーム&oldid=990」から取得