ページ

2013年9月28日土曜日

SteamOS のおさらい

さて今日もValveの発表がある訳ですが、こちらも負けずに妄想全開でその時を待ちたいと思います。と言っても、もう大した話題もないんですけど。取り敢えず今までの妄想を纏めてみますかね。
OS = Ubuntu 12.04 LTS (Ubuntu Coreバージョン)
UI = Steamクライアント (ビッグピクチャーモード固定?)
推奨ライブラリー = Valve Runtime(Valveが推奨するオープンソースなゲーム開発ライブラリー群?)
ウィンドウシステム = X.Org Server(Valve Runtimeに含まれているSDLをフロントエンドとして使用? バックエンド「MirかWaylandかX.Orgか」は開発者が意識する必要性は無い?)
これがこの前までの妄想です。で、今出ている妄想を足すとこんな感じですかね。
ホームストリーミング = NVIDIAのストリーミング技術がベース? 将来的にはNVIDIA GRIDによるクラウドゲームサービスも導入? もしかしたら、「LittleFoot」ととして「NVIDIA SHEILD」や「Tegra Note」とのストリーミングもあり?
音楽、テレビ、映画 = デフォルトで「Spotify」に対応? もしかしたら「Netflix」も?
「Steam Machines」はこんな感じでしょうか?
Steam Machines = x86アーキテクチャかつ汎用のPCパーツで構成されるゲーム機?
リファレンス機 = Valve自らが制作する試作機で、パーツ構成はAMDのCPUにNVIDIAのGPU? WiFiも必須? もしかしたら「認証制度」が設けられるかもしれない? 性能的にはそれ程でも無さそう?
取り敢えず、こんなところですかね? OSのベースが「Ubuntu 12.04」なのは、かなり信憑性が高いと思います。何故かというと、Valve公式サイトに、Steam Machines向けっぽいリポジトリが公開されているからです:-) まぁこれがSteam Machines用なのかは確認された訳ではないのですけど……。

それによると、ベースのOSは「Ubuntu 12.04.2」らしいです。既に12.04.3が出てますが、こちらはまだ「.2」みたいですね。それとNVIDIAのプロプライエタリドライバーとツール群ですね。あと「bcmwl-kernel-source」というパッケージも追加されていますが、これの説明を読むと以下のようなパッケージらしいです。
This package contains Broadcom 802.11 Linux STA wireless driver for use with Broadcom's BCM4311-, BCM4312-, BCM4313-, BCM4321-, BCM4322-, BCM43224-, and BCM43225-, BCM43227- and BCM43228-based hardware.
どうやら「Broadcom」製のWiFiが導入されるみたい? やっぱり、WiFi必須ってのは本当なのかもしれませんね。面白い所では「valve-wallpapers」のもありますね。まぁ普通に壁紙でしたが:-)

上記の情報で少し臭いかなって思うのはCPUがAMD製って所なんですが、リークによると単にコストの関係らしいので、有り得るって言えばありうるのかも……。本当ならNVIDIAがCPUも含めたワンストップ・ソリューションを提供出来ればベストだったのでしょうが、残念ながらNVIDIAは単独でのx86コアを手配出来ませんからね。その為にも「Project Denver」という高性能64bit ARMコアをGPUと統合する計画を急ピッチで進めている最中なんでしょうが、噂では2015年に実戦投入されるらしいので、あと2年は掛かるますし……。

自分の妄想では、NVIDIAとしては、このARM機でSteam Machinesを展開して欲しいという狙いもあって参加しているのでしょうね。x86からARMという流れは最近のトレンドですし、ValveもSDL2.0やその他のオープンソースなクロスプラットフォームライブラリーを多用している所を見ると、実性能より抽象度を優先して移植しやすい環境を推奨してきそうですし。それに将来的にはNVIDIA GRIDのようなクラウドゲームサービスでヘビィなゲームは互換性を取りそうな気もしますし。そうなると最悪、Steam Machinesは「ビューワー」のようなスペックでも良い訳ですし。まぁ実際にストリーミングでゲームをするとなると、各家庭にそこそこの回線が無いといけない訳でまだまだ時間は掛かりそうですが……。

それとNVIDIAのOpenGL対応ですが、カーマック先生が面白いリンクをリツイートしていました。任天堂のGCとWiiのエミュレーターである「Dolphin」の開発チームが現状の各社OpenGL3.0対応のドライバーをエミュレーターを用いてテストしたらしいのですが、数ある中でNVIDIAのLinux用プロプライエタリドライバーが最高評価の「Excellent」らしいです:-) 

次いで「Mesa」が「Good」。MesaというのはOpenGLのオープンソースな実装で、基本的にIntelの公式ドライバー、AMDとNVIDIAのコミュニティによるドライバーの事だと思います。唯一Intelは公式でオープンソース実装なので、コミュニティと分化してないのです。少し意外でしたが「Nouveau」(NVIDIAのGPUドライバーのオープンソース実装)の評価が高いですね。Nouveauは、今まで完全なリバースエンジニアリングで実装するという、ある意味、修行僧の荒行状態で困難が予想されているのですけど……。この前NVIDIAが方針を改めて一部のドキュメントを公開するらしいので、今後は多少、楽になりそうですが……。

そして「Mediocre(平凡、二流……)」の評価なのがAMDのLinux向けプロプライエタリ・ドライバーですね。まぁ何となく世間の評価通りですが……。ここで話が終わればまだ良かったのですが、世の中には更に悲惨な事があるんですね。二流以下の「Bad」がARM自らのGPU「Mali」向けのプロプライエタリ・ドライバーで、更に低い「Horrible」がQualcommの「Adreno」のプロプライエタリ・ドライバーらしいです……。もうひとつ「PowerVR」というメジャーなGPUがあるのですが、こちらは「Unknown」らしいです。OpenGL ES 3.0向けのドライバーがまだ無いのがその理由らしいですが。

こうやってみると、如何に現状のARM向けGPUドライバーが悲惨なのかがよく分かりますね:-( 恐ろしい事に各モバイルOS(FirefoxOS、Sailfish OS等々)がAndroid向けのドライバーを流用するらしいですね……。そして「Ubuntu」も「Mir」でその輪の中に加わろうとしているようです:-( 私の知識が中途半端なので、もしかしたら間違っているのかもしれませんけど。

なんて余計な事を書いてたら、あと20分でValveの3つ目の発表です。まぁイイ暇つぶしにはなったかな:-) 一体何の発表なんですかねぇ。噂じゃSource2エンジンの「Left4Dead3」じゃないかって話ですが、もしかしたら独自コントローラーかも。それともLittleFoot?

#外部リンク
http://repo.steampowered.com/hometest/dists/stable/steam/binary-amd64/Packages
http://repo.steampowered.com/hometest/dists/stable/steam/binary-amd64/Packages

Official Dolphin Emulator Website - Dolphin Emulator and OpenGL drivers - Hall of Fame/Shame
https://ja.dolphin-emu.org/blog/2013/09/26/dolphin-emulator-and-opengl-drivers-hall-fameshame/?cr=ja

2013年9月27日金曜日

Steam Machines のパートナーは、やっぱりNVIDIA?

昨日のValveの発表が、思ったより大人しい内容だったので少し残念でしたね。もう少し突っ込んだ発表があるのかと思っていたのですが……。一応、NVIDIAからもSteamOSに関する発表があったので、NVIDIAがValveに協力しているのは間違いないみたいですね。

あと昨日書いたAMDがLinuxに関して何か発表するかもって話ですが、GCN向けのDirectXにもOpenGLにも依らないPC向けの低レベルAPIの発表でしたね。多分ですが、PS4の開発からフィードバックされたAPIですかね? スライドによると、一応は「クロスプラットフォーム」なAPIらしいですが、何処にもLinux対応とは書いてませんでした……。11月に詳細を発表するとか何とか書いてあったきがしますが……。

カーマック先生のツイートによると、もしもAMDがこの新しいAPI「Mantle」をSteamOSにも移植したら、より多くのAAAタイトルがSteamOS向けに移植されるかもしれないって書いていましたが、このMantleをAMDと共同開発したバトルフィールド・シリーズで有名なDICEは、ある意味Steamのライバルである「Origine」を運営しているエレクトロニック・アーツの関連会社ですからねぇ……。それにエレクトロニック・アーツ系のゲームはLinuxにほとんど? 移植された事が無いですし……。

それに、個人的にはSteamOS向けのゲームは、SDLのように抽象化の度合いが強いライブラリーが推奨されるでしょうし、ある意味、逆路線の低レベルAPIであるMantleは、今後の展開(例えばARM機への移植等)を考えると、Valveとしては、あまり推奨したく無いのかなって思いますし。

私個人としては、PS4のやり方がある意味理想的だと思っているので、もし据え置きゲーム機として考えるなら、やはりAMDのAPU一機種に限定して、汎用APIのOpenGLと低レベルAPIのMantleの二本立てにするのがベストかなとは思うのですけどね……。

完全にネタレベルの話ですが、某所に投稿された匿名のValve社員を名乗る書き込みが話題になっていました。それによると、やはりパートナーはNVIDIAらしいです。勿論、AMDが排除されているという訳ではないですが、一緒になって開発しているのはNVIDIA一社だけみたい?

その人によると、Linuxは単純にWindowsより速いらしいです。平均して約25%くらい速いらしいです。次にLinuxは自分達でチューニング出来るのが良いらしいです。GPU関連だけじゃなくて、カーネル部分にまで手を入れる事が出来るのが素晴らしいそうです。しかもMSやアップルにお伺いを立てなくてもいいいので、1日で劇的にゲームを改善させる事が可能なのが特に気に入っているそうです。最後にWindowsはMSがゲームに対して、あんまりヤル気が無いのが嫌だそうです(えっ!

またSteamOSについてですが、NVIDIAのGPUは3世代前まで、AMDは2世代前までがサポート対象らしいです。ただし、Valve自らが制作する「リファレンス機」は、NVIDIAのGPUとAMDの「CPU」を載せたモノになるだろうとの事です。GPUは解るけど、なんでCPUがAMD? って思いましたが、単純に「お金」の問題らしいです。というか、INTELはSteamOSにあんまり興味が無いらしいです……。それに何かにつけてお金を請求されるので諦めたっぽいです:-(

AMDは特にコメントされていませんでしたが、これといって協力的という訳でもなさそうですね。コスト面では問題無さそうですが、ドライバーの作り込みとかの意味で……。それに比べると、NVIDIAは凄い協力的だったそうです。Valveのチームと一緒になってOpenGLドライバーの改善に取り組んでくれたし(残念ながらプロプライエタリなモノですが)、逆に例のNVIDIAのストリーミング技術を使ってみないかと売り込んできたみたいです:-) もしかしたら、NVIDIA SHIELD自体がValveの為のデモ機だったのかもしれませんね。その売り込みのお陰かSteamOSに「ホームストリーミング」がデフォルトで搭載されているのかもしれませんし。「このホームストリーミングは、AMDのビデオカードでも使わなくちゃいけないんだけど、それでもいいの?」とまで聞いたらしいです:-)

今の所、ホームストリーミングがどのような原理なのか判りませんが、NVIDIAのGPUはKepler世代から「NVENC」というハードウェアによるエンコードが可能になっているらしいので、多分ですがこれを使ってストリーミングするのだと思います。それ以前の世代やAMDのGPUの場合、同様なハードウェア機能がついているのか調べていませんが、もし無かったらソフトウェアで実装しないといけないので、正直快適なホームストリーミングは出来ないかもしれませんね……。もしこの情報が本当なら、リファレンス機に搭載されるGPUはKepler世代以降って事になりそうですね。

またSteam Machinesですが、基本的には汎用のPCパーツを使ったモノですが、おそらく何らかの「認証制度」が設けられるのではないかと……。これはValveがゲーム開発者に対して、最低限のスペック保証をしなければならないかららしいです。またリビングルームに置く製品なので、安いからと言って、あまりに粗悪品な電源を積んで燃えましたとかじゃ話になりませんし……。

勿論、OS自体は自由にダウンロード出来るので、自分で組み立てた超スペックなタワー型PCにSteamOSをインストールしても、おそらく問題もなく動作してゲームも遊ぶ事が出来ますが、それはValveが想定している「Steam Machines」の役割ではないそうです。ここまでの話を総合すると、やはりSteam Machinesはリビングルーム向けのセットトップボックスに近い位置づけなのかもしれませんね。少し違うかもしれませんが、「PS4」というよりも「PS Vita TV」的な位置づけなのかも。PS4相当はメインPCのWindows版クライアントって感じで……。

3つあるうちの最後の発表ですが、Valveが開発しているコントローラーか「Source 2」エンジンなんじゃないかってのが大方の見方みたいですね。コントローラーは確実に開発中みたいですけど、今回発表までするかは微妙な感じ?

ここまで長々と書いてきましたが、情報元が「4Chan」の匿名情報なので信ぴょう性はかなり怪しいところです:-( まぁ暇つぶしって事で、あんまり本気にしないで発表を待ちたいと思います。でも、実際にSteamOSについて、公式に祝福してるのってNVIDIAだけなんですよね……。もしかしたら他の企業も何らかのメッセージを公表しているのかもしれませんが……。

#追記
書き忘れましたが、Steam Machinesの条件? には、低レイテンシなワイヤレスネットワークも必要らしいです。「Wi-Fi Direct」の事なのかな?

#外部リンク
Steam Rolling Into Your Living Room
http://blogs.nvidia.com/blog/2013/09/25/steam-rolling-into-your-living-room/

米AMD、次世代GPU「Radeon R9」&「Radeon R7」シリーズを発表 | マイナビニュース
http://news.mynavi.jp/news/2013/09/26/171/

4Gamer.net ― NVIDIAの新機軸を理解する(1):GeForce GRIDが描く「ゲームスタジオが独自のゲームプラットフォームを描く時代」
http://www.4gamer.net/games/076/G007660/20120911008/

第504回:Wi-Fi Direct とは - ケータイ Watch
http://k-tai.impress.co.jp/docs/column/keyword/20110223_428718.html

#内部リンク
BLOG.MINAWA.NET: Steam Box の謎 その5
http://blog.minawa.net/2012/04/steam-box-5.html

2013年9月26日木曜日

SteamBox のサイズって?

発表まで、まだ時間があるので暇つぶし。SteamBoxってどのくらいの大きさになるのですかね? 一応「リビングルーム」向けを謳っているので、まさ普通のPCケースって訳でもないでしょうし……。有り得るとしたら「Mini-ITX」くらいですかねぇ。完全に据え置きゲーム機って感じなら、汎用性なんか気にせず一品モノで見栄え良くしてくるかもですが、どうせなら、ある程度汎用性がある規格に拘って欲しいですね。せっかくPC的な自由さがあるOSなんですし。

3年前くらいに妄想していた時はAMDって事で、まさかの「Mini-DTX」かもって思ったりもしたのですが、これだけモバイル機器が謳歌している時代、もう少し小さいサイズが妥当なのかもしれませんね。てか、AMDが推奨してたDTX規格自体、完全に忘れさられてますけど……。

今の時代だと、Intelが推奨している「NUC」レベルも考えられなくもないかなぁ。まぁある程度のGPUを積まないといけないから、そこまで小さいのは難しいかもですが……。値段との折り合いもありますしねぇ。PS4が4万円で出すっていうのが、Valveとしてはかなり厳しい条件ですよね。個人的には3万円、出来れば2万五千円くらいで、そこそこの性能のPCモドキみたいなのがギリギリのラインかなって気がするんですけどね。ゲーム機としてしか使えなければですけど……。

以前の話じゃ、SteamBoxはオープンなハードになるだろうって噂でしたし。この場合の「オープン」というのは、既存のPCのような意味ですかね。自分で他のOS、例えばWindowsを入れても構わないとか、そういう感じです。まぁぶっちゃけ、ただのPCな気がしてるんで、当たり前っちゃ、当たり前ですけど。

ただ、個人的には通常のBIOSの代わりに「CoreBoot」を採用した機器を見てみたいんですよね。以前も書いた事あるのですが……。APUならCoreBootに対応している可能性も高いんすけどね。Intelもですが……。実際、「ChromeBook」にはCoreBootが採用されてますし。ただCoreBootは「SeaBios」っていうペイロードで、デフォルトのOSイメージ? 以外も起動させる事が可能らしいんですが、残念ながらWindowsはACPIの制限が厳しくて、他のOSみたいに簡単に起動させるってレベルじゃないらしいんですよね。一応Windows7まではテストさてるらしいですが……。

そうなると普段はゲーム機として「SteamOS」を立ち上げてて、Windowsでしか遊べないゲームや、普段使いにWindowsOSを立ちあげたい時は、そちらを起動させるってのが、CoreBootだと、ちょっと不安な感じなんですよね。かといって、普通のBIOSのデュアルブートってのもどうかなって……。個人的にはUbuntuとかのLinuxを使えばいい気もしますが、それじゃ駄目な人も居ますしね……。とか無駄話書いてたら、あと1時間ですか。

#追記
やっぱりAMDのAPUだったら面白いんだけどなぁ。現行世代はまだまだ力不足だけど、次世代の「Kaveri」からはDDR3だけじゃなくてPS4と同じGDDR5もデフォルトで対応するらしいし。まぁ汎用品だとPS4みたいにGPUの能力を大幅にスペックアップさせてるって訳じゃないから、性能はかなり差があるだろうけど、その分値段的には有利だろうし……。

個人的には、SteamBoxはAndroidと似たような進化を遂げていくのかなって思うんですよね。既存の据え置き機みたいに最初でガツンとハードウェアの性能を上げるんじゃなくって、毎年あるいは3年毎くらいに、値段据え置きで徐々に性能が良くなっていくみたいな。SDLみたいに抽象化の強いライブラリーで互換とるんだから、そっちの方が良さそうな気がしますし……。まぁ今更妄想書いてもどうなるもんでもないんですが……。あと20分ですし。

#外部リンク
DTX - Wikipedia
http://ja.wikipedia.org/wiki/DTX

AMDが小型PC用フォームファクタDTXを提案
http://pc.watch.impress.co.jp/docs/2007/0115/ces15.htm

AMDの省電力APU「Kabini」搭載のMini-ITXマザーが発売、PS4と同系統の「Jaguar」コア採用 - AKIBA PC Hotline!
http://akiba-pc.watch.impress.co.jp/docs/news/news/20130822_612116.html

インテル® ネクスト・ユニット・オブ・コンピューティング
http://www.intel.co.jp/content/www/jp/ja/motherboards/desktop-motherboards/nuc.html

coreboot - Wikipedia
http://ja.wikipedia.org/wiki/Coreboot

Chromebooks - coreboot
http://www.coreboot.org/Chromebooks

#内部リンク
BLOG.MINAWA.NET: LinuxBIOS
http://blog.minawa.net/2007/03/linuxbios.html

BLOG.MINAWA.NET: LinuxBIOS with X11 server
http://blog.minawa.net/2007/03/linuxbios-with-x11-server.html

BLOG.MINAWA.NET: SteamとFusion APUの可能性
http://blog.minawa.net/2011/05/steamfusion-apu.html

BLOG.MINAWA.NET: Steam Box の謎 その6
http://blog.minawa.net/2012/04/steam-box-6.html

SteamBox って結局?

さてさて、今日も妄想全開で頑張ろうと思います。何と言っても、後3時間くらい(現在、25日の夜11時)で、Valveの「2つ目」の発表が控えてますからね。一体何なのでしょうか:-) 大方の予想では、やはり「SteamBox」なのではないかと……。自分もそう思いますし。という事で、勝手にSteamBoxについて妄想したいと思います……。

ぶっちゃけ、「何で作るの?」って事ですよね……。えぇ、「NVIDIA」か「AMD」か……。大穴で「INTEL」? この前も書きましたが、ハードウェア「だけ」を見れば、AMD、というか「APU」一択だと思います。PS4もXBONEもAPUですしね。ただ、ドライバーの出来や政治的? な理由でNVIDIAなのかもなぁと漠然と思っていました。まぁNVIDIAだけでは「GPU」はともかく、「x86」の「CPU」を用意出来ないので、INTELのCPUもって事になるのでしょうけど……。

実際、ツイッターでこんな発言が話題になっています。

代表的なゲームエンジンである「Unreal Engine」の偉い人が、「NVIDIAが作ったトンデモナイもの見せてもらったよ。GPUじゃないけどゲーマーが喜びそうなヤツ(意訳)」。うーん、確かに気になる情報です……。ただ何となくお茶を濁されているような、いないような……。と思っていたら、今度はこんなツイートが……。

これは……。「AMDが今日、Linuxユーザーとゲーム開発者をハッピーにさせる発表をするよ!(意訳)」。正直、Chris Pirillo氏の事は全く知らなかったのですが、かなり有名なジャーナリスト? みたいですね。そんな人がこんな事言ったら……。もう確定してるようなモノじゃないですかね……。

まぁ別にAMD一社からSteamBoxが出るとは誰も言ってないので、NVIDIAもINTELも、もしかしたらVIA!からも……。いや、流石にそれはないかな:-( でも、NVIDIAは以前、ValveがSource EngineをどうLinuxへ移植したのかっていう発表をValveとNVIDIA共同で行った事があるくらいなんで、絶対に一枚絡んでるとは思うのですけどね。例の「togl」の解説です。

何だかんだ言って、AMDとNVIDIAの協力は絶対に欠かせない部分なので、両者とも協力を取り付けているのならば、SteamOSとしては、ひとまず成功と言えるのかもしれませんね:-) まぁあと2時間ちょいで判明する事ではありますけど……。とか言って、SteamBoxの発表じゃなかったらズッコケそうですが。

あぁ、そうだ。何故か今日になって、NVIDIAが「Nouveau」(NVIDIAのGPUドライバーのオープンソース実装)に、GPUのドキュメントの一部を開示しても良いと通達してきたみたいですね。この件で以前、リーナスさん(Linuxの偉い人)に「ファ○ク・ユー!」されちゃった事もあったもんですが……。一体何故このタイミングで?

#YouTube
▶ Linus Torvalds - Nvidia F_ck You! - YouTube
http://youtu.be/IVpOyKCNZYw



#外部リンク
2014年、Steam の世界が広がります
http://store.steampowered.com/livingroom/?l=japanese

4Gamer.net ― ValveはなぜSource EngineをLinux+OpenGL環境へ移植したのか。GTC 2013のValveセッションレポート
http://www.4gamer.net/games/107/G010729/20130322107/

Porting Source to Linux - Porting Source to Linux.pdf PDFの為、閲覧注意
https://developer.nvidia.com/sites/default/files/akamai/gamedev/docs/Porting%20Source%20to%20Linux.pdf

Nvidia seeks peace with Linux, pledges help on open source driver (Updated) | Ars Technica
http://arstechnica.com/information-technology/2013/09/nvidia-seeks-peace-with-linux-pledges-help-on-open-source-driver/

#内部リンク
BLOG.MINAWA.NET: リーナス氏がNVIDIAに宣戦布告?
http://blog.minawa.net/2012/06/nvidia.html

2013年9月25日水曜日

SteamOS 発表!

いやぁ、昨日は怒涛の妄想ラッシュで自分でも呆れるくらい毒電波を垂れ流してしまいましたが、やっぱり発表されましたね! その名も「SteamOS」。具体的な内容はまだ判りませんが「Linux」ベースである事だけははっきりしました:-)

現在、明らかにされている内容から判る事は明確に「リビングルーム」向けって言う事ですね。普通に考えれば、大画面テレビに繋ぐ為に最適化されたUI、つまり「ビッグピクチャーモード」か、それに準ずるような既存のゲーム
機、セットトップボックスに似た操作感のUIって事になりますかね。どうしてもPCスタイルのゲームをやりたいって時にオプションで従来のクライアントのUIも選択出来るかってのが個人的に気になる所ですが……。

他に気になる特徴としては、ゲーム以外のコンテンツ、音楽や映画も取り扱うらしいですね。まぁこれは想定内ではありましたけど。それらを視聴する為のソフトが専用アプリなのか、あるいはChromiumのようなウェブブラウザー内なのかってのが多少気になる所ですかね。

話によると、既に「Spotify」は確定しているそうですが、何と言っても「Netflix」ですね。日本だと、あまり知名度はありませんが、米国だとダントツ一位の人気ですし。Netflixは「Chromebook」でもFlashと同じような待遇で特別なプラグインが用意されているくらい重要度が高いサービスですからね。

変更されていなければ、SteamクライアントもCEFというChrome(Chromium)の亜種? を使用しているので、ウェブブラウザーとしては似たような事が出来る? と個人的には思っているのですが、実際はどうなのかわかりません……。もし出来るのなら、様々なウェブアプリにも対応し易いでしょうから、意外と面白くなりそうではあります。例えばウェブアプリのゲームとか……。

一番驚いたのは「ホームストリーミング」ですね。Steam公式のアナウンスでは以下のように書かれています。
お持ちの Windows や Mac ゲームの全てを SteamOS マシーンでプレイできます。今まで通りにコンピュータを起動してSteam を実行すれば、家庭内ネットワークを経由してSteamOS マシーンでストリーム可能になり、これらのゲームをテレビでお楽しみいただけます!
うーん、これって家庭内「GAIKAI」みたいな事なんですかね? もしくはPS4の「リモートプレイ」的な? SteamOS側がクライアントになるって事は、既存のWin/MacのSteamクライアントを立ち上げてサーバー的に使うって事なんでしょうかね? PS4やWii Uのように、元から織り込み済みのハードウェアならともかく、性能もマチマチなPC用Steamクライアントじゃ、ハイスペックなPCじゃないと結構厳しい気がするんですけど……。てか、そこまでハイスペックなPCがあるなら、わざわざ貧弱? なSteamOS機なんか要らない気もしますが:-( まぁ出来ないよりは出来た方がいいですけどね。

個人的には、このホームストリーミングってのがキーワードな気がします。うろ覚えですが、元々の「SteamBox」構想って、据え置き型の「Bigfoot」とモバイル型? の「Littlefoot」の2つだった気がします。Littlefootってのは、情報が錯綜していて、一説には「ウェアラブルコンピュータ」なんじゃないかとも言われていましたしね。個人的には単なる携帯型ゲーム機? かスマホ、タブレット型なんじゃないかと思いますが……。ちなみにビッグピクチャーモードは「Tenfoot」らしいです。

まぁ簡単に言っちゃえば、PS4におけるPSPみたいな位置づけなんじゃないのかなぁと。実際、前述したリモートプレイとホームストリーミングって被ってそうですし。って、ここまで書いて思ったのですが、やっぱりSteamBoxのパートナーって「NVIDIA」なのかもしれませんねぇ。

昨日書いたNVIDIAのAndroidベースの携帯ゲーム機「SHIELD」や7インチタブレット「Tegra Note」っていうドンピシャなアイテム出してますし、特にSHIELDの方はクラウドゲーミングサービス「GRID」のデモ機でもありましたし。GRIDの真の力はGAIKAIのようなクラウドサービス向けですが、下のリンク先を見るとPCを母艦にしてH.264によるストリーミングプレイもデモしてたらしいですし……。

今はまだホームストリーミングですが、将来的にはPS4のGAIKAIのように、ある程度以上のパワーが必要なゲームや、どうしてもWindows専用しか用意出来ない大作や古いゲームなどの互換性維持にクラウドサービスとして使いたいのかも……。SteamBoxのメインターゲット的には、超弩級なゲーミングPCってのは意識してなさそうですし、昨日書いたようにSDL2.0のような性能よりも移植性を念頭に置いたライブラリーを使う方針なら、将来的にはNVIDIAが目指しているARMベースの高性能SoCに切り替える事も比較点簡単でしょうし……。

以前、Amazonが高性能コンピューティング (HPC)のウェブサービス向けに、NVIDIAのサーバーを大量に導入したらしいって話をどこかのウェブサイトで見た気がするんですが、ソースを失念してしまいました……。確かかなり安く買えたとかなんとか……。Valveも似たような条件で導入出来たらNVIDIA GRIDは結構有効な武器になりそうな気がします。まぁ今直ぐって訳にはいかないでしょうが……。

クラウドからのゲームストリーミングが出来ればリビング向けの機器は、そこそこの性能でネイティブは軽めのクロスプラットフォーム向けゲームが動けば良いって割り切りが出来るかもしれませんしね。超大作や古いWindowsゲーがやりたければ、有料? で、ストリーミングでって流れで……。

まぁ何にせよ、明日発表されるかもしれないSteamBox次第ってところですかねぇ。特に何処のチップメーカーと組んだのかって事でその後の話が変わってきそうです。てか、全然別の発表だったり?

#追記
しつこいですが、今考えても「SteamOS」って自分が以前妄想してた内容とソックリなんだよなぁ。最初に書いたの「2010年3月」ですよ? 別に何処かみてパクった訳でもないし……。自分でもビックリしますね。

#外部リンク
クラウドゲーミング – Gaming as a Service (GaaS) | NVIDIA GRID | NVIDIA
http://www.nvidia.co.jp/object/cloud-gaming-jp.html

【後藤弘茂のWeekly海外ニュース】 ゲーム機に挑戦するNVIDIAのGPU仮想化
http://pc.watch.impress.co.jp/docs/column/kaigai/20120529_536151.html

E3 2013: Project SHIELDにGRIDサーバ、万全の体制で挑むNVIDIAのゲームソリューションをチェック | Game*Spark - 国内・海外ゲーム情報サイト
http://www.gamespark.jp/article/2013/06/16/41505.html

Netflix - Watch TV Shows Online, Watch Movies Online
https://signup.netflix.com/global

Music for every moment - Spotify
https://www.spotify.com/int/

Netflix の映画を視聴する - Chrome OS ヘルプ
https://support.google.com/chromebook/answer/1401467?hl=ja

#内部リンク
BLOG.MINAWA.NET: Steam & Source on the Linuxの可能性 #05
http://blog.minawa.net/2010/03/steam-source-on-linux-05.html

BLOG.MINAWA.NET: Steam Box の謎 その4
http://blog.minawa.net/2012/03/steam-box-4.html

2013年9月24日火曜日

ぼくのかんがえたすちーむぼっくす その4

前回までの妄想をまとめると以下のような感じです。一応ですが全て私の妄想の産物です。多分に誤りが含まれている可能性がありますのでご注意下さい。
OS = Ubuntu 12.04 LTS (Ubuntu Coreバージョン)
UI = Steamクライアント (ビッグピクチャーモード固定?)
ウィンドウシステム = X.Org Server(Valve Runtimeに含まれているSDLをフロントエンドとして使用? バックエンド「MirかWaylandかX.Orgか」は開発者が意識する必要性は無い?)
推奨ライブラリー = Valve Runtime(Valveが推奨するオープンソースなゲーム開発ライブラリー群?)
取り敢えず、こんな感じでしょうか? って、自分で書いてますが、本当に適当だなぁ。本職の人からみたら噴飯物かもしれませんが、祭りって事でご容赦下さい:-(

次に肝心のハードウェアについてですが、基本的にはPS4やXBONEと同じPCアーキテクチャ(x86)になると思います。問題はどこのチップメーカーなのかって事ですよね……。私の以前の予想では「AMD」の「APU」こそがSteamBoxの中の人なのではないかと妄想していたのですが、最近になって違うのではないかと思い始めています。では何処なのか?

基本的には「インテル」で、もしかしたらディスクリートなGPUとして「NVIDIA」のGPUが追加されているのではないかなって最近は思い始めています……。いや、ハードウェアだけ見れば、AMDのAPUがベストなのは、マイクロソフトとソニーというゲーム機メーカーが揃って次世代機に採用している時点で間違いはないんですよね。自分もそう思っていますし。

ただAMDというかRADEONのLinuxにおけるプロプライエタリなドライバーサポートがどうしても、他の2社と比べると劣りそうってのが……。以前も書いた気がしますが、もはやゲーム界のご意見番とも言える大御所「John Carmack」氏のツイッターでのコメントが全てを表していると思うので掲載しておきます。

これは必ずしもLinuxにおけるドライバーの出来を指している発言ではないですが、一般的にRADEONのLinuxドライバーはWindowsのソレよりも出来としては劣るとされるのが定説ですし……。それに、APUがPS4とXBONEに採用されて発売前の追い込みに追われているドライバー担当チームがLinux版の開発にまで手が回るのかっていう不安もありますしね。ただでさえ、AMDのドライバー担当チームは人数が少ないという噂ですし……。

それに以前からチラホラ流れてくるSteamBoxの噂によると、Valveのチームが想定しているハードウェアがインテルのCPUとNVIDIAのGPUの組み合わせであるという情報が圧倒的に多いですし。まぁこれはSteamBoxがというより、SteamのLinux版の平均的ユーザーが、この組み合わせのPCをよく使っているというデータに基づいて検証しているに過ぎないのかもしれませんが……。

またインテルはともかく、NVIDIAとしては上客であったソニーのPS4のGPUをAMDに奪われ、なおかつAndroidのリファレンス機とも言うべき「Nexus7」の次世代機でも不採用になるというイメージ的にも悪いめぐり合わせの時期ですしね。まして据え置きゲーム機に関しては、マイクロソフトのXBONEと任天堂のWii UもAMD採用という事で、正直「全敗」といっていい状況ですし……。ここまで追い詰められると、Windowsでのゲーム開発のリファレンスもNVIDIAからRADEONへと流行が移ってしまいかねませんしね……。

NVIDIAも、この状況は相当マズいと思ってか、積極的に自社製品を売り込んでいるように思えます。既に忘却の彼方になりつつありますが、異色のAndroid据え置きゲーム機として一時期話題になった「OUYA」にも相当安価にTegra3チップを供給したという噂もありますし、最近になってNVIDIA自らがAndroidベースの携帯ゲーム機「SHIELD」を売りだしたり、Nexus7対抗なのか7インチタブレット「Tegra Note」を200ドルという採算度外視の値段で計画中だったりしますし……。

また少し前のイベントでCEOジェン・スン・フアン氏自らが高性能ARMコアを開発統合する「Project Denver」のデモをUbuntuを使ってアピールしてたりと、最近Windows以外にも頻繁にアピールしている機会が目立ってきています。また、今まで封印していたKeplerコアのIPライセンス提供ビジネスを開始したのも見逃せないなと個人的には思っています。

これは基本的にARM向けの措置らしいですが、もしもValveがNVIDIAから「安価」でKeplerコアのIPライセンスを購入して、インテルのCPUと組み合わせた製品を作ったのなら、AMDのAPUと迄はいきませんが、初代XBOX的な「ゲーム機」が作れないとも言い切れないなと思っているのですが妄想し過ぎですかね……。

それにSDLのようなライブラリーでゲームの互換性を維持するつもりなら、大幅な最適化が出来ない代わりに、将来的にはNVIDIAが相当力を入れている前述の「Project Denver」、あるいはインテルの内蔵GPUのスペックが十分に上がった時にも、互換性の問題は他企業のプラットフォームよりは起きにくいのではないかなぁと思っているのですが、これも妄想のし過ぎかもしれませんね……。

他にも幾つか書こうかなって思っていたのですが、そろそろ時間がなくなってきたので、このあたりで終わろうかと思います。正直言って時間が無さ過ぎて、いつも以上にグタグタな内容になってしまいましたが、まぁ仕方ないですね。発表まで、あと1時間切ってますし。

さて、実際の「SteamBox」構想が一体どういう内容なのか期待半分不安半分で、その時を待ちたいと思います:-)

#追記
あ、書こうと思ってて忘れてましたが、Linux版のSteamクライアントをビッグピクチャーモードで動かした時に内蔵のウェブブラウザーでウェブ閲覧が出来るのですが、そのウェブブラウザーのUAって「Chrome」のバージョン18.xなんですよね。これってCEF使ってるからだと思うのですが、セキュリティ的には修正されてるのかなぁ? 流石に最低限の修正はされているとは思いますけどね。

ついでに書くと、ビッグピクチャーモードを起動した時にでる動画って、「WebM」なんですよね。こういう所もオープンソース愛好家からすると嬉しいところですね:-) PS4もせっかくFreeBSD使うなら積極的にオープンソースを活用、支援してくれたらいいんだけどなぁ。

#外部リンク
2014年、Steam の世界が広がります
http://store.steampowered.com/livingroom/?l=japanese

NVIDIA,KeplerコアのIPライセンス提供ビジネスを開始 - 4Gamer.net
http://www.4gamer.net/games/049/G004964/20130619001/

【後藤弘茂のWeekly海外ニュース】64-bit ARMコアをGPUに統合するNVIDIAのDenver計画の全貌
http://pc.watch.impress.co.jp/docs/column/kaigai/20130606_602510.html

NVIDIA,自社設計のTegra 4搭載Androidタブレット「Tegra Note」を発表。価格は199ドルで,2~3か月以内にパートナー企業から出荷 - 4Gamer.net
http://www.4gamer.net/games/049/G004964/20130919005/

NVIDIA SHIELD | Ultimate Gaming and Portable Entertainment
http://shield.nvidia.com/

NVIDIAの「SHIELD」分解レポート。299ドルの「ゲーム機型Android端末」にはけっこうコストがかかっていた - 4Gamer.net
http://www.4gamer.net/games/198/G019883/20130824005/

おまけ インテルでインタビューに答えるゲイブ氏:-)
Gabe Newell of Valve on Game Development and Perceptual Computing | Intel® Developer Zone
http://software.intel.com/en-us/blogs/2013/06/17/gabe-newell-of-valve-on-game-development-and-perceptual-computing

ぼくのかんがえたすちーむぼっくす その3

前回はSteamBoxのOSについて妄想しました。まとめると以下のような感じですかね。
OS = Ubuntu 12.04 LTS (Ubuntu Coreバージョン)
UI = Steamクライアント (ビッグピクチャーモード固定?)
まず何故Ubuntu 12.04なのかですが、Linuxディストリビューションの中で最もアクティブなユーザー数が多い事と、12.04は長期サポート (LTS) 版である事が理由だと思います。またUbuntu Coreという組み込み向け(といっても、本来の組み込みというより、Windowsのエンベデッド版に近い感じ)で最小構成で利用可能だからだと思います。

UIは正直まだ判りませんが、Valveの発表を見ると「リビングルーム」を強調しているので、もしかしたら通常のSteamクライアントのUIは封印されてビッグピクチャーモードのみで運用するのかもしれませんね。通常のSteamクライアントが使えるとしても、Ubuntu上でSteamクライアントを立ち上げるような感じではなく、ブートして、そのままSteamクライアントへログインするという感じになるかもしれません。感覚としてはChromeOSに近いかもと思っているのですが、正直全然判りません。

ウィンドウシステムは12.04という事でデフォルトの「X.Org Server」の確率が高いでしょうね。今話題の「Mir」あるいは「Wayland」は、商用のシステムで実戦投入するには時期尚早ですしね。12.04はLTSなので「2017年4月」がサポートの最終期限ですし。恐らく2015年くらいには、MirかWaylandも落ち着いてくるでしょうし(適当ですが)。

ちなみにSteamは、この厄介な次世代ウィンドウシステム戦争をどう考えているのかというと、ValveにいろいろとアドバイスをしているプログラマーのRyan C. Gordon(icculus)氏は以下のようにツイッターでコメントしています。

またicculus氏は、この厄介な問題の解決策として、Valveは「SDL2.0」を積極的に使って対処するだろうともコメントしています。
This isn't strictly true. Most of the current titles are using SDL, which uses GLX behind the scenes. One could swap out the game's included SDL library with a build that targets Wayland or Mir, and the game would run without an X server and not know or care that it's not using X11. This can happen without updating the game binaries directly.

For games that don't ship their own copy of SDL (and thus use the one included in the Valve Runtime by default), you don't even have to touch the game's depot at all. Valve just needs to update their Runtime package and it's good to go.

SDL is smart enough to try to use Wayland or Mir first, and if they aren't available, use X11, so one copy of SDL will work on whatever the current system has.

This is an oversimplication; there are probably games that use SDL but will cheat and try to talk to an X server directly for various reasons--but this is rare--and there's at least one big game on Steam that's talking to GLX directly without using SDL. But by and large, switching the Linux Steam library from X11 to Wayland and/or Mir is not only doable, it's probably relatively easy.

--ryan.
要約すると、WaylandかMirかX.orgかと言った厄介な問題はイチイチ考えず、Valveが配布している「Valve Runtime」に含まれているSDL2.0を開発者が使ってくれれば、後はValve Runtimeが面倒見てくれるよと……。もしかしたら大幅に間違っているかもしれませんが、取り敢えずValve Runtimeを使っておけばOKみたいな感じですかね(適当)。

ちなみにValve Runtimeは今の所、以下のようなパッケージ内容になっているようです。これって、Valveが推奨しているゲーム制作用のライブラリー群って事で良いんですかね? 正直、理解不足なんですけど……。ちなみにValveのGitHubでDL可能みたいです:-)
acl libacl1 libacl1-dev
alsa-lib libasound2 libasound2-dev
alsa-plugins libasound2-plugins
atk1.0 libatk1.0-0 libatk1.0-dev
attr libattr1 libattr1-dev
avahi libavahi-common3 libavahi-common-dev libavahi-client3 libavahi-client-dev
bzip2 libbz2-1.0 libbz2-dev
cairo libcairo2 libcairo2-dev
cups libcups2 libcups2-dev
curl libcurl3 libcurl3-gnutls libcurl4-gnutls-dev
cyrus-sasl2 libsasl2-2 libsasl2-dev
d-conf dconf-gsettings-backend
dbus libdbus-1-3 libdbus-1-dev
dbus-glib libdbus-glib-1-2 libdbus-glib-1-dev
dummygl dummygl-dev
e2fsprogs libcomerr2 comerr-dev
expat libexpat1 libexpat1-dev
flac libflac8 libflac-dev
fltk1.1 libfltk1.1 libfltk1.1-dev
fontconfig libfontconfig1 libfontconfig1-dev
freeglut freeglut3 freeglut3-dev
freetype libfreetype6 libfreetype6-dev
gcc-4.6 libgcc1 libstdc++6 libstdc++6-4.6-dev libstdc++6-4.6-pic libgomp1 gcc-4.6-base
gconf libgconf-2-4 libgconf2-dev
gdk-pixbuf libgdk-pixbuf2.0-0 libgdk-pixbuf2.0-dev
glew libglew1.6 libglew1.6-dev
glib2.0 libglib2.0-0 libglib2.0-dev
gmp libgmp10 libgmp-dev
gnutls26 libgnutls26 libgnutls-dev
gst-plugins-base0.10 libgstreamer-plugins-base0.10-0 libgstreamer-plugins-base0.10-0-dev
gstreamer0.10 libgstreamer0.10-0 libgstreamer0.10-0-dev
gtk+2.0 libgtk2.0-common libgtk2.0-0 libgtk2.0-dev
gtk2-engines gtk2-engines
gtk2-engines-murrine gtk2-engines-murrine
gtk2-engines-pixbuf gtk2-engines-pixbuf
heimdal libasn1-8-heimdal libgssapi3-heimdal libhcrypto4-heimdal libheimbase1-heimdal libheimntlm0-heimdal libhx509-5-heimdal libkrb5-26-heimdal libroken18-heimdal libwind0-heimdal
jack-audio-connection-kit libjack0 libjack-dev
jasper libjasper1 libjasper-dev
json-c libjson0 libjson0-dev
keyutils libkeyutils1 libkeyutils-dev
krb5 libkrb5-3 libkrb5-dev libk5crypto3 libkrb5support0 libgssapi-krb5-2 krb5-multidev
lcms2 liblcms2-2 liblcms2-dev
libappindicator libappindicator1 libappindicator-dev
libasyncns libasyncns0 libasyncns-dev
libav libavcodec53 libavcodec-dev libavfilter2 libavfilter-dev libavformat53 libavformat-dev libavutil51 libavutil-dev libswscale2 libswscale-dev
libcanberra libcanberra0 libcanberra-dev libcanberra-gtk0 libcanberra-gtk-dev libcanberra-gtk-module
libcap2 libcap2 libcap-dev
libdbusmenu libdbusmenu-glib4 libdbusmenu-gtk4
libexif libexif12 libexif-dev
libffi libffi6 libffi-dev
libgcrypt11 libgcrypt11 libgcrypt11-dev
libgpg-error libgpg-error0 libgpg-error-dev
libgsm libgsm1 libgsm1-dev
libice libice6 libice-dev
libidn libidn11 libidn11-dev
libindicator libindicator7 libindicator-dev
libjpeg6b libjpeg62 libjpeg62-dev
libjpeg-turbo libjpeg-turbo8
libmad libmad0 libmad0-dev
libmikmod libmikmod2 libmikmod2-dev
libnotify libnotify4 libnotify-dev
libogg libogg0 libogg-dev
#libogre-1.7.4 libogre-1.7.4 libogre-dev
libpng libpng12-0 libpng12-dev
libsamplerate libsamplerate0 libsamplerate0-dev
libsdl1.2 libsdl1.2debian libsdl1.2-dev
libsdl2 libsdl2 libsdl2-dev
libsdl2-image libsdl2-image libsdl2-image-dev
libsdl2-mixer libsdl2-mixer libsdl2-mixer-dev
libsdl2-net libsdl2-net libsdl2-net-dev
libsdl2-ttf libsdl2-ttf libsdl2-ttf-dev
libselinux libselinux1 libselinux1-dev
libsm libsm6 libsm-dev
libsmpeg0 libsmpeg0 libsmpeg-dev
libsndfile libsndfile1 libsndfile1-dev
libtasn1-3 libtasn1-3 libtasn1-3-dev
libtheora libtheora0 libtheora-dev
libtool libltdl7 libltdl-dev
libusb-1.0 libusb-1.0-0 libusb-1.0-0-dev
libva libva1 libva-dev
libvorbis libvorbis0a libvorbisfile3 libvorbisenc2 libvorbis-dev
libvpx libvpx1 libvpx-dev
libx11 libx11-6 libx11-dev libx11-xcb1 libx11-xcb-dev libx11-data
libxau libxau6 libxau-dev
libxaw libxaw7 libxaw7-dev
libxcb libxcb1 libxcb1-dev libxcb-shm0 libxcb-shm0-dev libxcb-render0 libxcb-render0-dev libxcb-glx0 libxcb-glx0-dev
libxcomposite libxcomposite1 libxcomposite-dev
libxcursor libxcursor1 libxcursor-dev
libxdamage libxdamage1 libxdamage-dev
libxdmcp libxdmcp6 libxdmcp-dev
libxext libxext6 libxext-dev
libxfixes libxfixes3 libxfixes-dev
libxi libxi6 libxi-dev
libxinerama libxinerama1 libxinerama-dev
libxml2 libxml2 libxml2-dev
libxmu libxmu6 libxmu-dev
libxpm libxpm4 libxpm-dev
libxrandr libxrandr2 libxrandr-dev
libxrender libxrender1 libxrender-dev
libxss libxss1 libxss-dev
libxt libxt6 libxt-dev
libxtst libxtst6 libxtst-dev
libxxf86vm libxxf86vm1 libxxf86vm-dev
mesa libglu1-mesa libglu1-mesa-dev
ncurses libncursesw5 libncursesw5-dev libtinfo5 libtinfo-dev
network-manager network-manager-dev libnm-util2 libnm-util-dev libnm-glib4 libnm-glib-dev
nspr libnspr4 libnspr4-dev
nss libnss3 libnss3-dev
nvidia-cg-toolkit nvidia-cg-toolkit libcg
openal-soft libopenal1 libopenal-dev
openldap libldap-2.4-2 libldap2-dev
openssl libssl1.0.0 libssl-dev
orc liborc-0.4-0 liborc-0.4-dev
p11-kit libp11-kit0 libp11-kit-dev
pango1.0 libpango1.0-0 libpango1.0-dev
pcre3 libpcre3 libpcrecpp0 libpcre3-dev
pixman libpixman-1-0 libpixman-1-dev
pulseaudio libpulse0 libpulse-dev
rtmpdump librtmp0 librtmp-dev
schroedinger libschroedinger-1.0-0 libschroedinger-dev
sdl-image1.2 libsdl-image1.2 libsdl-image1.2-dev
sdl-mixer1.2 libsdl-mixer1.2 libsdl-mixer1.2-dev
sdl-ttf2.0 libsdl-ttf2.0-0 libsdl-ttf2.0-dev
speex libspeex1 libspeex-dev libspeexdsp1 libspeexdsp-dev
sqlite3 libsqlite3-0 libsqlite3-dev
tbb libtbb2 libtbb-dev
tcp-wrappers libwrap0 libwrap0-dev
tdb libtdb1 libtdb-dev
tiff libtiff4 libtiff4-dev
udev libudev0 libudev-dev libgudev-1.0-0 libgudev-1.0-dev
util-linux libuuid1 uuid-dev
x11proto-composite x11proto-composite-dev
x11proto-core x11proto-core-dev
x11proto-fixes x11proto-fixes-dev
x11proto-input x11proto-input-dev
x11proto-kb x11proto-kb-dev
x11proto-randr x11proto-randr-dev
x11proto-render x11proto-render-dev
x11proto-scrnsaver x11proto-scrnsaver-dev
x11proto-xext x11proto-xext-dev
x11proto-xf86vidmode x11proto-xf86vidmode-dev
xft libxft2 libxft-dev
xtrans xtrans-dev
zenity zenity
zlib zlib1g zlib1g-dev
私の浅い解釈だと、Valveは互換性維持の為にオープンソースなライブラリー、とりわけSDL2.0を強く推奨しているようですね。以前もこのブログで書きましたが、SDLのメイン開発者である「Sam Lantinga(Slouken)」氏がValve入りしていますし。

誤解を恐れずSDLを説明すると、オープンソースかつクロスプラットフォームな「DirectX」って説明が一番近いですかね。Direct3DはOpneGLですが、他の例えばキーボードやコントローラーの出入力や2Dのサウンド、フォントの取り扱いとかですか? プログラマーじゃないんで適当で申し訳ないんですが:-(

実際、SDL2.0になってから、コントローラーの取り扱いはかなり改善されているようです。以前のバージョンだと、コントローラーの扱いがあんまり良くなかったので、例えば有名なエミュレーターである「Mednafen」なんかは、SDLから他のライブラリーに1年前くらいから変更してしまいましたし……。実際に最近になってValveはWindows版の「Team Fortress 2」でのコントローラーの取り扱いをSDL2.0に変更していますし。

この事から考えられる事は、ValveはSteamBoxに置いて、PS4のように独自APIを追加するのではなく、逆にSDLやOpenGL、その他のオープンソースなクロスプラットフォームを多用して、クロスプラットフォームでの互換性を最大限に優先するのではないかと思われます。

この事はオープンソース愛好者からすると、嬉しい事ではあるのですが、SteamBoxがPS4のような次世代機と「ガチ」な性能競争ではかなり不利になる事にもなりかねないので、ゲーム機ファンとしては、少し残念ではありますけどね:-( 互換性と性能の両立というのは、なかなかに難しいものです……。

またまた長くなったので一旦終わります。次はハードウェアについて書きたいのですが、正直2時までに間に合うかわかりません……。

#外部リンク
[Phoronix] Valve's Steam Box Will Most Likely Use An X.Org Server
http://www.phoronix.com/scan.php?page=news_item&px=MTMxODc

steam-runtime/README.md at master · ValveSoftware/steam-runtime · GitHub
https://github.com/ValveSoftware/steam-runtime/blob/master/README.md

Mednafen Forum: Development => Mednafen 0.9.25-WIP
http://forum.fobby.net/index.php?t=msg&goto=2694&

2013年9月23日月曜日

ぼくのかんがえたすちーむぼっくす その2

続きです。さて昨日はSteam Box構想のきっかけについて妄想しましたが、今日は具体的な内容です。Valveが独自のゲームプラットフォーム、あるいは専用ハードウェアを開発するとしたら、どうなるのか? という所まで書きました。個人的には、Windwosベースの組み込みOS「Windows Embedded」を使用したゲームプラットフォームかLinuxをベースにしたゲームプラットフォームのどちらかになるのかなぁと思っていました。

Windows Embeddedを使う利点は既存Windowsゲームの移植が簡単である事です。最近はMacやLinuxといったOSにも対応しマルチプラットフォーム化したSteamですが、元々Windows環境のユーザーが9割以上、Windows専用ゲームがラインナップがほとんどという事実は覆せません。専用ハードウェアへの移行という意味では前回紹介したセガのWindows Embedded 8ベースの次世代業務用ゲーム基板「Nu」のようなプラットフォームの方が簡単だと思います。

一方、過去の互換性は考えず将来的な自立を考えた場合はWindows以外のOSを使ったゲームプラットフォームを1から構築する方が良いかもしれません。折しもソニーのPS4もPS3との互換性を捨ててまでPCベースのハードウェアとオープンソースな汎用OS「FreeBSD」ベースのゲームプラットフォームへと大きく変化しましたし。

ゲームプラットフォームという訳ではないですがグーグルの「Android」や「ChromeOS」もベースとなる部分はLinuxを活用しています。Androidは大半がカーネル部分のみでユーザーランドは純粋なLinux環境とは言えませんが、ChromeOSの方はかなり素? のLinux環境に近いですし。更に言えばAmazonのモバイルOS「KindleOS」はAndroidをベースしているOSですしね。このようなビッグプレイヤーがLinuxを流用して商用プラットフォームを立ち上げるのも時代の流れなのかもしれません。

そう考えればLinuxOSをベースとしたPCアーキテクチャを使ったゲームプラットフォームというのは荒唐無稽な話ではないと思います。特にある意味競合してくるPS4がFreeBSDベースのPCアーキテクチャというのはかなり大きいと思います。それを言ったら、もう1つのライバルであるマイクロソフトの「Xbox One」もPS4と同じPCアーキテクチャを使用していますけど。こちらWindowsベースのOSという違いはありますが:-)

話が長くなりましたが、Valveのゲーム機が他社と同じPCアーキテクチャ(x86)なのは、ほぼ既定路線だと思います。問題はOSですが、こちらもゲイブ氏がLinuxのイベントに出席し、その場でアナウンスをした時点でLinuxベースなのも、ほぼ確定したと思います。本当にコレは大きなターニングポイントになると思います。

ここからが本題。では肝心のOSは具体的にどうなるのか? という疑問。勿論ベースのOSはLinuxですがLinuxといっても様々です。例えばAndroidもカーネル部分はLinuxですが、ウワモノは既存のディストリビューションと互換性がない全く別のOSと言っても差し支えないと思います。同じくグーグルのChromeOSはAndroidよりも既存のディストリビューションと近いですが、こちらもChromeというウェブブラウザーを大幅に拡張したOSで基本的には他ディストリビューションと互換性はないですし。

PS4もカーネル部分は「FreeBSD」ベースですがGPUドライバーはPS4専用で使用するAPIも専用となりそうです。またUI等もソニー独自のモノを使用しており、残念ながら既存のFreeBSDには還元されるようなシロモノでは無さそうです……。その分、ゲーム機として見れば既存のゲーム機と違和感無く使えそうですけどね。

そう考えるとValveがSteamBox(仮称)でLinuxを使用するとしても、グーグルやソニーのように主にカーネル部分に限定してユーザーランドは専用設計のゲーム機らしいモノに仕上げるか、あるいはユーザーランドも既存のディストリビューションと同様な汎用的OSにして、その上で1アプリケーションとしてSteamを動かすか、ChromeOSのように土台は既存ディストリビューションと同じで、直接Steamアプリのみを使えるようにするといった使い方が考えられると思います。

Valveが「ガチ」でPS4やXboxOneと張り合うような据え置きゲーム機戦争に参加する場合、取る選択肢はPS4のようなLinuxカーネルを使用しユーザーランドは専用設計のゲーム機という事になると思いますが、個人的には現時点では望み薄だと思っています。何故かというと、このやり方は強力なライバルとの直接対決という事になり、Valveの体力で、この2社とガチで戦うのはあまりに危険でしょう。ハードウェアの完成度が高いPS4と比べるとValveが用意出来るSteamBoxのスペックは貧弱なものでしょうし、コストも割高になるのは目に見えていますしね。

そんなPS4ですらプラットフォームの仕切りなおしによる互換性切り捨ての弾不足は不安材料ですし、Windwos用ゲームが大半のSteamの場合、弾不足はPS4以上でしょう。噂されるValve自らの新作「HalfLife3」や「Left4Dead3」などがリリースされたとしても、今すぐにハードウェアを買ってまでやろうというユーザーは少ないでしょうし……。

またPS4は汎用的なOpenGLのようなAPIの代わりに独自設計の「GNM」「GNMX」といったAPIを使うとされています。ライバルより強力なハードウェア(XBONEより50%強力なGPUや8GBのGDDR5メモリ)の上にDirect3DやOpenGLのような汎用的なAPIには無いハードの能力を最大限引き出すように設計された独自APIというのはスペックが固定される据え置き機では、かなり魅力的でしょうし。

勿論、ValveもPS4に倣って強力なハードかつ独自のAPIを用意する事も可能でしょうが、いくらx86アーキテクチャとはいえ、GDDR5を8GBのようなカスタマイズを施せばそれだけ汎用性が薄れてコストが跳ね上がってしまいますし、また独自APIはクロスプラットフォームが売りのSteamには断片化の要因になりかねませんしね……。PS4は一機種限定なのでAPIの断片化は問題にはなりにくいでしょうし。まぁ当分はPS3版も併売するでしょうが……。

という事で、少なくとも今回発表されるSteamBoxはPS4やXBONEに対抗するような強力なゲーム機にはならないのではと考えています。UIは既存のSteamクライアントか、あるいは「ビッグピクチャーモード」のみに限定したモノになるのではないかと……。

そうなるとOSは基本的にLinux版クライアントの対象であるUbuntuをベースにしたものが妥当だと思います。以前、私はUbuntuのLTS、現行だと「Ubuntu 12.04」になると予想しました。それも普通のLTSではなく、Ubuntuの組み込み機器向けとも言える「Ubuntu Core」を使用するのではないかと妄想しました。

自慢話で申し訳ないですが、私が書いた後にPhoronixの記事で(中の人の話では)SteamBoxのOSは「Ubuntu 12.04LTSのUbuntu Core」になるのではないかと書かれておりました。Valveの中の人にUbuntu Coreの話をしたら面白いと食いついてきたそうです:-) その後、実際にどうなったかまでは今現在に至るまでリークされていませんが……。

現行のSteam「クライアント」は、Chromiumブラウザー(ChromeのOSS版)を埋め込んで使えるようにした「Chromium Embedded Framework(CEF)」を使用したモノにIEベースのモノから切り替えられているので、基本的には最小限のUbuntu Coreを使用して、CEFを動かせるライブラリー等を追加すればSteamのクライアント「だけ」は動作させる事が可能です。それだけだと基本的に動くゲームは殆ど無いですが後はゲームに必要なライブラリーをパッケージジングしてあげれば、一応ゲームを動かす事は可能になるでしょう。

長くなったので、一旦終わります。残りはSteamの発表までに間に合うかなぁ……。確か火曜日の午前2時発表だったよなぁ……。

ぼくのかんがえたすちーむぼっくす

Valveが来週に何か発表するらしいというニュースが飛び込んできてから約一週間。来週と言っても「どうせ週末だろ」って思っていたのですが、何と明日(月曜日の深夜)には発表するらしいですね。正確に言うと24日(火曜日)の午前2時らしいです。早すぎる……。長々と書くつもりでいたネタでしたが、もう間に合いそうもないですね……。取り敢えず妄想を書けるだけ書いて、その日を迎えたいと思います……。

えーと、まず何でValveがLinux、ひいてはSteam Boxなる独自プラットフォームを今頃になって始めるのだろうかという根本的なお題から妄想してみたいと思います。例の如く、単なる素人のおっさんが適当に考えたネタなので、あまり本気にしないで下さい。それと何故か物語調です……。

昔々「MS(仮名)」という超巨大企業がありました。そのMS社が経営している「MSデパート」のテナントに「スチーム」という玩具店が出店していました。スチームの経営者は元々MS社の社員でMS創業者とも顔馴染みの古参社員です。MSデパートの軒先を借りたスチームの売上はかなり好調でした。MS社との仲も悪くありません。

数年後、MSは新たにゲーム専門店「XB」社を立ち上げ、老舗ゲーム専門店である「NTD」と「PS」社と激しい戦いを繰り広げ始めました。同じくゲームを取り扱っているスチームですが、若年層のゲームファンが客層のゲーム専門店とデパートに買い物にきたついでにゲームを買いにくる客が主力のスチームとは微妙に客層が違っていたので(実際はコアなゲームファンも含まれますが)、それほど影響はありませんでした。

それから更に数年、MS社のライバルである「A」社が、本業であるデパートとは別にコンビニ「i」を立ち上げ、またたく間にシェアを広げていきました。最初は業種違いと、あまり気に留めていなかったMS社ですが、時代の趨勢は巨大なデパートより身近なコンビニへと移り変わりつつあったのです。

これはマズイかもと思い始めたMS社も以前からあったコンビニ「WM」をテコ入れしますが、どうも上手く行きません。そうこうしている内に、A社のコンビニiはまたたく間にシェアを広げて、いまや本業のデパート「M」よりコンビニ「i」を全面に押し出してMS社を追い立てます。また今までは小売りに参入していなかった巨大広告企業「G」も新たにコンビニ業に進出してきました。

デパートでは圧倒的強さを誇るMSですが、コンビニ経営となるとどうも上手く行きません。偉大な創業者も引退してしまい、このままではマズイと思ったMSは思い切った手段に出ます。イマイチ上手くいかないコンビニを立て直すよりも、圧倒的シェアを誇るデパートを若者向きに改装する方針に変更したのです。

その際、利益を出せそうなテナントを追い出し、代わりにMS自らが直営店を出したほうが美味しいのではないかとMSは考えだしました。そうなると困るのは「スチーム」のような老舗テナントです。今までは大家と店子で上手く競合せずに蜜月関係を続けていられたのに、急に一等地から追い出されてしまっては売上がガタ落ちしてしまいます。

ましてスチームが取り扱っている商品の中身は、ほとんどがMS社製の部品を使っているので、MS本家が本気になってゲームを取り扱うようになっては、単なる代理店に過ぎないスチーム(といっても、いくつか自社製品は出してます)に対抗できる術は殆どありません。「このままではジリ貧……」そう考えたスチームの創業者「ゲイブ」氏は万一の対抗策として、MS社のライバルA社のデパートMにもテナントを出すことにしました。デパートMではMS社の製品を使った玩具は取扱えないので、品ぞろえは貧弱ですが仕方ありません。

一応の対抗策をうったスチームですが、どうもA社はデパート経営に本腰ではなく、今流行りのコンビニ経営に全力を注いているようです。デパートMへの進出を果たしたスチームですが、コンビニiはA社自らが選別した商品しか置けずスチームが出店出来る可能性はかなり低そうです。何と言ってもA社は「垂直統合」で業績を伸ばしてきた企業です。顧客もそんなA社の方針を支持しています。そうなるとスチームの付け入る隙は余りないかもしれません……。

またMSの子会社が運営しているゲーム専門店「XB」の経営も順調でライバルのS社が運営している「PS」ともども次世代店舗では取り扱う商品もインディーズやゲームに限らない商品が増えてきてスチームと被ってくる内容が増えてきそうです。とはいっても、ゲーム専門店もコンビニで売られているお手軽な製品にシェアを奪われてはいるのですが……。

来年にはMSデパートでスチームの売上トップである「XP」支店が老朽化により閉鎖される事が確実視されており、徐々に新型店舗へと移行する流れは止められそうにありません……。今はまだMSの軒先を何とか借りられているが、それも何時まで続くか判りません。体力のある今のうちに新たな手を打たなければスチームの未来は暗いものになるかもしれません。

そこでゲイブ氏は賭けにでます。XP支店が閉鎖される前に新たなデパートへの進出を決めました。ただし新しいデパートは新興住宅地にあり、運営している企業も歴史が浅く知名度も資本力も乏しい「U」社です。またA社と同様、スチームが多く取り扱っているいるMS社の部品は規格が違うので使う事が出来ません。ほぼ1からの立ち上げとなってしまいます。市場シェアで言えばMSが90%以上、Aが8%弱、Uに至っては1%が精々でしょう。これでは苦労して新店舗を立ち上げても厳しい未来しかありません。しかしUは他社と比べ、テナント経営に関してあまり縛りが無いので労力は掛かりますが、一度店舗を作り上げればその後の経営は自由に行えそうです。

これと並行してゲイブ氏はデパートのテナント以外の出店も視野にいれていました。店舗の形態がどのようになるかは未だ判りませんが、おそらく何処かの軒先を借りるのではなく、独立した店舗になるのではないかと思われます。その際に考えられる策は少なくとも2つ。

一つは以前より距離があるとはいえ、スチームが取り扱っている商品と互換性があるMSの土地を借りて、店舗自体は自前で作る策。具体的に言うと「Windows Embedded」のライセンスを購入して、Windows OSベースのゲームプラットフォームを構築する事。最近でもセガがWindows Embedded 8ベースの次世代業務用ゲーム基板「Nu」 を発表しています。まぁアーケード向けと家庭向けという違いはありますが、スチームで取り扱っているゲームの大半がWindows向け、というかDirectXベースであるのを考えれば、そう悪い策でも無いと個人的には思います。デメリットとしては、結局マイクロソフトの呪縛から永遠? に解き放たれる事がない事ですかね。

もう一つの策としてはU社のテナント出店でノウハウを蓄積しつつ、新しい土地を取得して店舗も自前で作ってゲーム専門店? を運営していく策。具体的には、Ubuntuをベースとして、スチーム自らが新しいゲームプラットフォームを運営していくって感じですかね。一見すると荒唐無稽な話ですが、実はそうおかしい話でもないかなと個人的には思っています。長くなったので一旦終わります。

#追記
今調べたら、スチームのサービス開始より初代XBOXの発売の方が早かったですね……。……この物語はフィクションで(ry

#外部リンク
セガ,次世代アーケードゲーム基板「Nu」を発表。採用タイトル第1弾は「初音ミク Project DIVA Arcade Future Tone」に - 4Gamer.net
http://www.4gamer.net/games/999/G999902/20130904019/

2013年9月16日月曜日

LinuxCon 2013 でゲイブ・ニューウェル氏が基調演説

お久しぶりです。せっかくの3連休だっていうのに台風のせいで全国的の大荒れでしたね。明日から仕事の人は後片付けが大変そうですね……。

さて、寝る前に一言だけ。現在開催中の "LinuxCon 2013" で、Steamで有名なValveの設立者ゲイブ・ニューウェル氏が基調講演を行うそうです。開催は現地時間で "9:25am - 9:45am" らしいので、もう終わっちゃったのかな? まぁ明日の朝迄には何らかの情報が得られるかもしれませんね。そろそろ噂の "Steam Box" について語ってくれないですかねぇ?

#追記
コメント欄で教えてもらった通り、来週に何か発表するらしいですね:-) それまでに自分なりの妄想を書こうかと思っているのですが、久々に書こうと思うと、なかなか上手くまとめられないものですね:-( 週末には何とか駄文を書き終わりたいと思っているのですが……。

#YouTube
Gabe Newell at LinuxCon 2013 9/16/2013 - YouTube
http://youtu.be/Gzn6E2m3otg



取り敢えず、日本語の記事をリンクに追加しときます。

#外部リンク
LinuxCon North America/CloudOpen North America: Keynote: Linux and Gaming - Gabe Newell,...
http://linuxconcloudopenna2013.sched.org/event/f010bb8f23da1c6291fd60584cac0c04#.UjcNAbyOy3R

ゲイブ・ニューウェル - Wikipedia
ゲイブ・ニューウェル - Wikipedia

ValveがLinuxベースのゲーム専用機SteamBoxを発売か?CEO曰く: ゲームの未来はLinuxにあり | TechCrunch Japan
http://jp.techcrunch.com/2013/09/17/20130916valve-ceo-gabe-newell-says-linux-is-the-future-of-gaming-hints-at-steambox-announcement/