「バッファリング」を含む日記 RSS

はてなキーワード: バッファリングとは

2019-03-25

Stadia開発者インタビュー その3

ブツブツ切れる・・・

Youtubeマクロミクロレベルで数多くのネットワーク状況に対する情報提供してくれます。我々はそれらの情報も利用可能ゲーマー体験を調整、拡大が可能です。

しかユーザYouTubeの画質をゲーム内の品質だと思ってはいけませんよね?

その通りです。StadiaをYoutubeとは異ならせる2つの事象がありますYouTubeバッファ使用可能リアルタイムでもなく、ゲームのようにインタラクティブでもありません。Stadiaはバッファリングができません。Stadiaはフレーム数が絶対的に正確である必要があります

次に2つ目ですが、ユーザDoomやAssasin's Creedレベルの画質のゲームを遊ぶ場合、その期待はYouTube向けにユーザ作成したコンテンツよりもずっと高くなります

さらにもう1つお話する価値がある点として、YouTubeとStadiaの繋がりについて今後も多くのことを話し、デモをしていきますが、大前提としてゲームとはリンクであり、リンクは無数の方法で配布、探索、共有が可能であることが挙げられます

すると例えば土曜の夜10時にDoom Eternalを遊ぶ計画をしたとして、Webページボタンを押すだけで我々を貴方方に加えることが可能だと言えますか?

その通り、全く仰る通りです。あなたが仰った通りのシナリオになります。また例えばEurogamerが新しいゲームレビューしているとしたら、ユーザレビュー記事クリックするだけでダウンロードすることもなく、パッチを当てることもなく、インストールすることもなしに簡単にそのゲームを試すことが可能です。また他にはあなた記事が新しいマップキャラクターレベルについて記述している場合でもそうです。我々にはState Share(状態共有)と呼ばれる既存技術と一緒に働くとても強力な新技術を用意しています

State Shareは本当にとても強力な機能ユーザが最新のバージョンゲームを遊んでいる時に、同時に友人や私、または世界中にそのゲームストリーミング可能です。誰が相手でも問題ありません。またユーザゲーム内での最新の武器、例えばDoomのFlaming Swordや、とにかくそゲームで最高のアイテムを入手したとします。そして私が「カッコイイ! 私もそのFlaming Swordが欲しい!」と考えたとしましょう。私がそのビデオクリックすればそのメタデータがそれら全ての属性を直接私のゲームにも転送します。だから誰でもが他人ビデオストリームに飛び込めるだけでなく、その他人の状況全てと共にゲームに飛び込めるのです。これは開発者ゲームが設定可能です。これについては他にも例がありますが、1つはユーザゲーム特定の難しい状況に陥った場合に、ユーザコミュニティにその状況を解決できるか試してもらうことが可能です。全く同じ状況で渡すことができます

我々がYoutubeとの接続で行っている別の例は、典型的シナリオとして、私がパズルベースアドベンチャーゲームをやっている場合によくある状況があります。そのゲームのあるポイントで立ち往生してしまいました。その特定パズル、例えばトゥームレーダーのある墓や何かができないとしましょう。現状では電話を取り上げるかラップトップに向かいヒントをダウンロードするでしょう。それかYoutubeに向かって動画を探します。しかしStadiaではボタンを押して「Hey, Stadia. このボスはどうやってやっつければ良いんだい?」と聞きます。するとStadiaがYoutube動画を探してきてゲーム内で再生します。私はレベルの解答を見て続けることができます

先程、申しましたゲームとはリンクであるとの点ですが、任意Webサイトリンクを持つことができますDiscordFacebookTwitter電子メールテキストメッセージWhatsAppGoogle検索結果、さらにはGoogle Play Storeですらゲームの配布が可能になります

それはどのように動いていますか?

リンクです。

でも基本的に分離されたシステムですよね?

そうです。インターネット全体に渡り分散された広大な領域の利点を得ています。我々は開発者パブリッシャに対し、インターネットストレージであるとのコンセプトを広めています。もちろんStadiaは専用のストレージを持っていますしかし我々は開発者に対しゲームを自社のコミュニティへ持っていくことも、例えどこにコミュニティがあろうとも許可します。このことが配布と探索を開発者にとってとても良い意味で逆さにします。また我々にはとても高速なマーケティング技術がありますので、パブリッシャは体験をできる限り多くの人々にとても効率の良い手段で配布することが可能です。


もっと全体的なレベルで、抜本的にStadiaはYoutube統合しているのですね。ではプラットフォーム上の全てをどうやってモデレートしますか?

コミュニティに対するモデレーションにはとても強固なアプローチを取りますYouTubeは途方もない投資をこの領域に行ってきました。我々はそこに提携をし、さらに家庭レベルでも行います。我々はこの業界でも最も優れたペアレンタルコントロールゲーマー健康コントロール提供します。両親は子供が何を遊ぶか、誰と遊ぶか、いつ遊ぶかを管理可能です。

その点に関してはデータプライバシも気になります。それらは全て既存Googleインフラに紐付けられるのですか?

我々は全てをユーザ制御下に置くことを使命としていますGoogle提供する制御機能と同じレベルのものがStadiaでも提供されるとお考え下さい。

ユーザサイドでゲームを行うことやこれまでのコンソール文化は滅ぶでしょうか?

それは私共が答えることではありません。Stadiaはゲームの新しい開発の仕方、ゲームの新しい探し方、ゲームの新しい楽しみ方を提供します。我々には大きな未来への志があります。大規模に発展したいと考えています。それは一晩で起こることではありません。また我々はこれまでに存在し、我々をここまで導いて下さった物、全てを尊敬しています。私達は業界全体が成功し、成長することを望んでいます

Stadiaの開発者インタビュー その2

やっぱり途中で切れたので続きから


サービス提供を開始します。

するとシステムの準備は万端で、必要ソフトウェアの開発が必要ということでしょうか。Microsoftを見ますと、彼等はXBox OneのHWをサーバラックに積んでいるようです。あなたがたの手法とは異なりますか?

違います

するとGoogleインフラバックエンドのみでなくソフトウェアにも投資を考えていますか?

そうです。

自身の開発スタジオも考えていますか?

はい。Stadia Games and Entertainment組織を発表しました。これは我々の1stパーティスタジオです。

それが今起こっている?

はい

Google開発者に対し全てのツール支援しています。Stadia向けの開発は彼らにとって別のターゲットしか過ぎません。Visual Studioを用いる既存ツールや彼らが用いるツールの全てと共に、彼らのワークフロー統合されます。従ってStadia向けの開発はPlayStationXbox向けの開発と同じくらい簡単です。

我々はUnrealサポートします。UnityがStadiaサポートします。予想される多種多用な業界標準ツールミドルウェアが準備されます

意地悪な質問します。Googleコントロールを超えたものがありますよね。特にユーザサイド、クライアントサイドのインフラ家庭内安価ルータです。このような問題をどのように解決しますか?

とても良い質問です。我々はユーザに対し彼等のインフラの中で何が起こっているかをできる限り理解できるよう支援する必要があります。また我々はゲーマーに対し最適な体験を得られるようなチューニングを行うことが可能情報に対し投資を行うだけでなく、我々自身技術を用いて最良のパフォーマンスを実現するつもりです。Google技術の多くがインターネット網の基盤であることを思い出して下さい。我々はDCから情報がどのようにユーザに届くかを良く理解しております。できる限りの最適化を行うつもりです。

デベロッパパブリッシャは既存ゲームをStadia移植できるのですね。しかし同時にGoogleは新しい選択肢も数多く提供できると

その通りです。それこそが我々のプラットフォーム根本的な差別化ポイントです。既存ゲームカタログを持つデベロッパにとってStadia簡単で親しみ易いものです。我々はできる限り摩擦なくゲーム移植を行えるようにします。なぜならゲーマーは好きなゲームを遊びたいですし、彼らの愛するキャラクターストーリー世界を楽しみたいのです。しかし我々はまた開発者未来を描く新しいキャンバスをも提供します。ゲームを高速に配布し、プレーヤーと新しい手段で、特にYoutubeにて繋げます。そして開発者が持つアイデアを実現するための前例の無い技術提供します。


これまでのクラウドシステムクライアントサイドの限界基本的に画質やレイテンシに起こりました。明らかにこれらの問題インパクトはここ数年で新たにより良い技術を得ることとインフラ改善されることで緩和されてきました。しかローカル品質ストリーミング品質との間には今でも根本的なギャップ存在します。私はidソフトウェアZenimax特許を見たのですが彼らはh.264のモーションベクター効果的に用いてクライアントサイドのある程度の予測を立てレイテンシの知覚を減らしていました。Project Streamにも測定可能レイテンシ存在します。ギャップを閉じるために何をしていますか? これらの問題解決されたでしょうか。それとも少なくとも緩和はされましたか

解決されたと同時に緩和されています。まずデータセンターに対しより多くの人々がより良い経験を得られるようにするための投資が行われました。また圧縮アルゴリズムについては我々に抜本的な先進性が存在します。Google圧縮アルゴリズム標準仕様先駆者でありこの点がストリーミングの将来をより確実にします。残念なことですがGoogleでも制御できない点が光の速さです。そのためこの点が常に要因となりますしかし常に理解しなければならないこととして、我々は常にエッジ(終端)にもインフラを構築していることが挙げられますGoogleの中心にある巨大なデータセンタだけではありません。我々はできる限りエンドユーザの側にインフラを構築しています。それによって歴史上の幾つかの問題回避することが可能です。さらにまだ率直な、あまり洗練されていないProject Streamのストリーマーでも信じられない結果を出していますさらに我々はサービスリリース時に1080p60を超える品質を実現できるだけの根本的な改善を行いました。我々は8Kに至るでしょう。

それは素晴しい。それらの改善は全て圧縮に関連するものですか?

圧縮ネットワークです。我々はGoogleインフラに投入した数々の改善点に依っています。BBR、QUIC、WebRTCを基盤としてその上に構築がなされました。だからIPパケットの低レイテンシでの配信だけでなく、送信元へのフィードバックも行うことが可能です。ですのであなたが仰るZenimax使用した技術なら、彼らはここでも利用することが可能です。彼らは彼らのゲーム最適化を行うことができるでしょう。我々はフレーム毎のレイテンシ予測可能で彼らにそれに合わせて調整を行わせることができます


入力を受け取って、ゲームロジックを処理して描画を行うと、60Hzのゲームでは50ms程になります。続いてエンコード転送デコード、表示を行うとストリームではPC上のゲームに比べさらに60ms程かかります。これを改善することはできますか?

我々は改善を続けますStream最初バージョンです。我々は性能向上のために調査を行っており、レイテンシ適応していきますリリース時にはより良くなっているでしょう。

クラウドシステム接続可能性に従って成否が決まります。例えばRed Dead Redemption 2を数万、数十万、場合によっては数百万のプレーヤーオンラインにて同時に立ち上げるとします。システムの成否はアクセスによります。もしゲームプレイできないなら重大な障害となります

かにそのとおりです。そしてそれこそがGoogleが何年もかけて開発してきたスキルであり、抜本的なスケールする能力です。我々がどうやって実現しているのか、何をしてきたかについては今日は詳細にはお話しません。しかGMailMapYoutubeが同時に利用可能であるためと同じ基本的技術のいくつかが我々が依るものです。


我々は現在、現行世代が終了する移行の時を迎えています。これまではコンソールベースラインを定めてきました。Stadia次世代XboxPlayStationに対抗できると考えますか?

我々は競合他社が何をしているかは存じておりません。

でもGoogleには良い予測を立てられる優れた人々がいますよね?

我々の第一世代システムに導入されるGPU10Tflops以上の性能があり、さらスケールアップしま

GPUユーザ間で共有されますか? それとも1人のユーザが独占しますか?

単一インスタンスです。

NVIDIAGPUですか?

AMDです。

カスタムGPUだと思います

カスタムGPUです。

Google要件のために作られた訳ですね。他にも公開できる情報はありますか? Vegaですか? それともNavi、もしくはさら新世代ですか?

情報を公開したくない訳ではないのですが、このプラットフォーム進化することのほうがより重要です。そしてこの進化ユーザ開発者の双方に対しシームレスに行われることを確認して頂きたいのです。そして進化は常に継続し、誰もが常に最新で最高の物を手に入れます

クラウド確約する点ですね。ユーザはHWをアップグレードする必要がないと。

開発者にもこのように考えて欲しいのです。もちろん完全には抽象化されていません。特にゲーム開発者にとっては。しかし我々はそれでもこのプラットフォームが常に進化していると考えて欲しいのです。速さや容量、リソースには制限されていないのだと。

AMDGPUを使うことでStadiaと他のコンソールの間に共通な点ができました。開発者にとって利益となるでしょうか?

シェーダコンパイラツールをいくつか開発しました。これらは開発を楽にするでしょう。しか現在GPUはとても優れており開発者が既にVulkanに親しんでいれば、例えばid Softwareさんは既に全てVulkanに移行していますが、そのような開発者の方々には既存ゲームをStadia移植するのはとても簡単です。Doom Eternal4K、60フレームで動いでいるのは既にご覧になったと思います。非常に素晴しい状態です。これこそが我々にとって重要証明ポイントです。FPSグラフィックプレイアビリティの双方で要求が高いゲームです。 従ってこれは我々のプラットフォームの強力な証拠であり、idさんにも講演して頂きます

CPUについては何か公開できる話はありますか?

x86で2.7GHzで動作しています開発者にとり慣れのあるものです。開発全体を通して、CPUは制約となる要因ではありません。我々は全てのタイトル動作するに十分なCPU提供します。

コア数、スレッド数は?

沢山です。

8コア、16スレッド? それより多い? 少い?

公開できない情報です。ハイパースレッド使用しています

しかサーバ級のCPUです。Stadiaはこれまでのコンソールと違いパッケージングに制約を受けません。熱対策問題も異なりますコンソールとはサイズパッケージング動機が異なりますデータセンタの中でそれはとても汚なく見えるかもしれません。一方でとても帯域幅が高いメモリ使用可能で、とても高速なペタバイト級のローカルストレージ使用可能です。ご家庭のコンシューマデバイスよりも数百倍は速い物です。

するとそれが開発者が全く異なる体験のために利用可能な要因となる訳ですね。得られる機会はとても大きいことでしょう。しかし我々はマルチプラットフォーム時代生活していますGoogle先進的な機能は1stパーティのみが利用できるものですか?

パートナーには彼らが話せる時点で彼らの計画を教えてくれるよう伝えています。Stadiaをこの世界で最も偉大なゲーム開発者達に説明することにはとても興奮します。Stadiaは、開発コードではYetiと呼ばれていましたが、Stadiaビジョン説明すると、開発者リアクションは「これは私が期待したもののものだ。これはまさに我々の次のゲームのためのビジョンのものだ。elastic computingの考え、次世代レベルマルチプレーヤー環境ゲームを観ることと遊ぶことの境をあやふやにし1つの体験にすること」と話されます

イノベーションの1つの領域として、最初のほうで述べましたが、マルチプレーヤー環境において、単純にパケット複数プレーヤーリダイレクすることから原子時計レベルでのコンシステンシーを全ての状態遷移において定期的にクライアント間で更新する真のシミュレーションへの移行が挙げられます。これにより開発者はこれまでには不可能だった分散された物理シミュレーションを得ることができます。これだけでもゲーム設計イノベーションに対し大きく寄与します。このため多くの開発者が、大袈裟でなしに、実際にとても感動的なリアクションを我々のプレゼンに対して返して下さっています


多くの問題解決し、規準を上げる可能性がある訳ですね。

これこそがゲーム業界の素晴しい点です。技術が常に創造性を刺激し、ゲームに対しより大きな聴衆を作り、そのことがプレーヤー開発者に対しより大きな機会を作ってきました。エコシステム進化し、正の方向に回り続けるなら、それはゲームを遊ぶことにとって良いことです。

あなたは先程、スケーラビティとStadiaがどのようにしてより多くのリソースを立ち上げ増大する要求対応するかについて話して下さいました。しかし、同時に10TflopsのGPUサーバクラスCPU存在するとも仰いました。リソース拡張をどのように行うのですか?

3台のGPSが一緒に実行されるデモを行っています。私は上限が無いとは申しません。しかし我々は技術上の限界を上げています。そしてStadiaは静的なプラットフォームではありません。このプラットフォームは5年や6年の間、レベルが変わらない訳ではありません。開発者プレーヤー要求に従い、成長し、進化するプラットフォームです。なぜならStadiaデータセンタの中に構築されています進化させるのは我々にとって簡単なことです。

ここまで第一世代について多くのことを教えて頂きました。すると第二世代やその後の世代もあるでしょう。現状でもスケールアップできるわけですが、3台のGPU連携次世代でも可能ですか?

CPU/GPU/メモリ帯域幅の変更にはいくつかの自然な段階があります。これは家庭の物理な小売の端末よりももっとスムースでより継続的な進化です。しかし、より重要なことは基盤データセンタ網とそれに含まれネットワーク技術への投資です。この2つが一致して行われることが重要でどちらか1つではダメなのです。

先程、エッジ上のインフラについて触れられましたが、例えばNetflixISPキャッシュインストールしている状況があると思います。これがGoogleが行っていることですか? それとも既にYoutubeで行われていますか?

それは我々も既に行っていますGoogleが既に20年以上、行っていることです。我々が依って立つまた別の巨人の肩です。


Project Streamではユーザに対し最低で25Mbpsの帯域幅要件しました。これはストリーミングのみのためですか? それとも他のユーザが同時に同じインスタンス接続する場合を含みますか?

我々はStreamさらに強化させています。従ってユーザはこの制約が全体のスタックに対する改善最適化、また特に時間によって緩和されることを期待するでしょう。我々はその期待の上を行きます

4K60には相当の帯域幅がいるのでしょうね?

4K60はもちろんより要求が高くなります

1080p60は低くなる・・・

私は具体的な数値についてはコメントしません。しかし当然低くなります

インターネット接続環境はStadiaリリースする市場では全体的に上昇機運が見られます。つまりこのパフォーマンス特性ますます多くのユーザが利用可能になります

さらに繰り返しになりますが、BBRを初めとする我々の技術がありますさらに覚えておいて頂きたいのは我々のネットワークに対する理解そのままではありません。それらもまた時と共に改善されていきますYoutubeマクロ

Stadiaの開発者インタビュー

Eurogamerにより独占配信されたStadia開発者二人に対するインタビュー記事

https://www.eurogamer.net/articles/digitalfoundry-2019-google-stadia-phil-harrison-majd-bakar-interview

やっつけなので可能なら原文を読むことをお勧めします。

---

なぜ今なのでしょうか?

タイミング問題です。20年間の蓄積によりGoogleにはデータセンタ内のパフォーマンスに優位性が存在します。Googleデータセンタ内ではHWメーカーです。我々はデータセンタ内で何年もの間、高い性能で端末間を接続する基盤を構築してきました。Youtubeでの経験からプレーヤーサイドの観点からだけでなくデータセンタ内部から技術観点から技術統合を行ってきました。他社でもその視点存在していますGoogleにはその点に固有のアドバンテージ存在します。

これまでの箱をTVの下に置いておいたパラダイムに比べ、無限演算リソースによる可能性が現れます。これまで存在しなかったことをできる可能性があります

その通りです。我々にはレガシーがありません。全てが21世紀のために設計されています開発者制限の無い計算資源が利用でき、何よりもマルチプレーヤーサポートできます。これまでのマルチプレーヤー環境は一番遅い通信に影響を受け開発者は最も遅い接続に対し最適化必要でした。我々のプラットフォームではクライアントサーバも同じアーキテクチャの下にあります。これまではクライアントサーバの間のping支配されていましたが我々の環境なら最速でマイクロ秒で済みます。だからプレーヤーの数は単一インスタンスにて動的にスケールアップが可能です。バトルロイヤルなら数百から数千、数万のプレーヤーが集まることも可能です。それが実際に楽しいかどうかは置いておくとしても、新聞ヘッドラインを飾ることが可能技術です。

クライアントサーバの双方でこの利益を得られるのでしょうか

両方です。

すると開発者に対しStadiaホリデーシーズンにぴったりの最高の製品だと言えると。理に適った範囲無限計算資源が得られると。

ユーザが我々のプライベートLANからはみ出さないだけでもその効果は大きいものです。Googleは45万kmに及ぶ光ケーブルにより世界中データセンタ間を接続しています米国西海岸から東海岸まででも20ms、フランクフルトからマドリッドでも20ms。これにより開発者は最も極端な場合においてもレイテンシ予測可能でそれに従い設計を行うことができます


Youtbeとの統合について教えて下さい。

StadiaYoutube技術と深く結びついていますが、実際には一歩引いています今日ゲーム業界を考えてみて下さい。2つの世界共存しています。1つはゲームプレイする人々で、もう1つはゲームを見る人達です。2億人の人々がYoutubeゲーム毎日見ています2018年には述べで500億時間ゲームを視聴するのに費されています時間人口の双方で信じられない程の視聴が存在します。我々のビジョンはこの2つの世界を1つにすることでゲームを見ることができ、かつ、プレイもできる、双方向に楽しめることです。

まり重要なのはゲームシステムでもなくコンソールでもありません。噂とは異なり我々はコンソールビジネスには参入しません。我々のプラットフォームの要点はコンソールでは無いことで、皆が集まる場所を作ることです。我々は箱でなく場所を作る。今までと異なる体験を得られる場所です。ゲームを見るなり、遊ぶなり、参加する場所であり、かつユーザが楽しむ場所であり、ユーザ他人を楽しませる場所です。

から我々のブランドはStadiaといいます。これはスタジアム複数形です。スタジアムスポーツを行う場所ですが同時に誰もがエンターテイメントを楽しむ場所でもあります。だから我々はそれをブランドにしたかったのです。皆が遊んで、観て、参加して、さらにはゲームをする場所。一歩下がって見ることもできる場所。常にどのボタンを押したか意識しないでも良い場所。他のアーキテクチャでは実現できない場所です。

まりリアルタイムシミュレーションゲームで全ての駒が人々であるようなものですか?

その通りです。そして単純に技術的に深い点を求めて、我々は第一世代でも4K60fpsHDRサラウンドサポートしました。さら開発者必要インフラに従ってスケールします。それだけでなく、同時にYoutubeに常に4K60fpsHDR画像送信することが可能です。だからあなたゲーム体験の思い出は常に最高の状態になります

Googleは全てを記録するでしょうか?

プレーヤー次第です。Googleは全てを記録はしません。もしプレーヤーが望むならGoogle4Kストリームしま

共有が友達だけか、世界中に公開かも自由選択可能です。Googleユーザ制御を明け渡します。もしユーザYoutubeで公開すれば誰でもリンククリックすることでそのゲームを遊ぶことができます

するとユーザshareするだけで誰でもがその特定ゲームに参加することができる訳ですね。

そう。そしてこれはマルチプレーヤーゲームロビーの新しい形となりますYoutubeクリエイターなら誰でもがファンチャンネルのsubscriberを自分ゲームへと誘うことができます生主として、Youtubeクリエイターとして私は視聴者を私のゲームに瞬間的に招待できます。それが私と10人の友達でも、(訳注: セレブの)Matpatと彼の数百万の購読者でも、技術は同じです。

アカウントシステムベースYoutubeですか?

Googleアカウントの一部です。従ってGMailアカウントがStadiaへのログインに利用できます。他の基盤についても説明させて下さい。最初サービス立ち上げから全ての画面への対応を行いますTVPCラップトップタブレット携帯です。我々のプラットフォームの基本は画面に依存しないことです。これまで40年間、ゲーム開発は端末依存でした。開発者として私は制約の範囲内で、私の創造性を開発対象の端末に合わせてスケールダウンする必要がありました。

我々はStadiaでそれを逆にしたいのです。我々は開発者に対し彼らの考えをスケールさせ、どの端末の縛りから解放したいのです。パフォーマンスに優れ、リンククリックすればゲームは5秒以内に開始されますダウンロードもなく、パッチもなく、インストール必要なく、アップデートもありません。多くの場合、専用のHWも必要がありません。従って古いラップトップChromeブラウザ使用する場合にでも皆さんが既に持っているだろうHID仕様に準ずるUSBコントローラ動作します。そして、もちろん、我々自身コントローラも開発中です。

なぜ独自コントローラを作るのですか? USBコントローラはどこにでもあるじゃないですか

コントローラ自作する理由はいくつかあります。1つはTVへの接続です。我々はChromecastをストリーミング技術採用します。Stadiaコントローラの最も優れた機能の1つはそれがWiFi接続DC内のゲームに直接接続することです。ローカルデバイスとは接続しません。

それは面白い。するとほとんどそれ自体が端末な訳ですね。

その通りです。これこそが我々のブランドの実現であり、具現化です。そして独自コントローラにより最高のパフォーマンスが実現します。ゲームに直接接続するためにプレーヤーは画面を移動することが可能です。プレーヤーはどの画面でも自由に遊び、停止し、他の画面でゲームに復帰することが可能です。

そしてコントローラには2つの追加されたボタンがあります。1つはGoogle Assistantの技術マイクを用いますユーザ選択により、ユーザプラットフォームゲームの双方に対し、自然言語を用いて会話が可能です。例えば「Hey, Google。MadjとPatrickと一緒にGame Xをやりたいな」と言えばStadiaマルチプレーヤーゲーム指定した友人と共に直ぐに開始します。

するとGoogle伝統的なUI回避するのですね?

我々はゲーマー可能な限り素早くゲームに辿り着かせるよう考えています。数多くの研究を行いましたが、多くのゲーマーゲームを起動したら直ぐに友人とゲームを開始したいと考えていますゲーマーUI時間を費したくは無いのです。

誰かが言ったことですが、現在コンソールは起動した時にまるで仕事のように感じると言うのです。ゲーム自体更新や、ゲーム更新があります。我々はそれらを完全に取り除きたいと考えています。もう1つのボタンは、ちょっと趣が異なるのですが、Youtubeシェアできます

端末は何でも良いのですね? スマホスマートTVも?

Youtubeが観られるならどこでもStadiaは動きます

TVへの接続にはChromecastが使用されると。では実際にはどのように動きますか?Chromecastがスマホラップトップからストリーミングを受け取るのでしょうか?

Chromecastはスマホからストリームを受取はしません。Chromecastはスマホから命令のみ受けます画像NetflixYoutubeから直接受け取ります。Stadia場合、StadiaコントローラからChromecastへとこのゲームインスタンスへと接続せよと命令がなされ、Chromecastはゲームインスタンスから動画ストリームを受け取りますクライアントはとてもシンプルです。行うのはネットワーク接続ビデオと音声のデコードのみです。Chromecastは入力を処理しません。全て入力コントローラが扱いますビデオと音声とネットワーク接続Chromecastの基本動作で全て既に組込まれています

Stadiaの起動はどうするのですか? コントローラで?

そうです。とても良く出来ていますWiFiに繋ぐだけです。コントローラにはWiFiIDとPWを入れるだけです。それだけです。ホームボタンを押すと勝手Chromecastを探し直ぐにChromecast上でクライアントを起動します。UIが表示され直ぐにゲームを遊ぶことができますデジタルパッドでUI操作することも可能です。これが重い処理を全てクラウドへと移行する点の美しさです。Chromecastのような低消費電力の端末で説得力のある体験ができますChromecastは5W位下です。Micro-USBで給電可能です。典型的コンソール100から150Wもします。またこれまで説明しませんでしたが、例えスマホでも行うことは動画再生だけです。従ってAssassin's CreedDoomや他の重いゲームあなたスマホの上でモバイルゲームよりも低消費電力で動作します。だからスマホ10時間でも遊べます

スマートTVではStadiaYoutubeクライアントに組込まれるのでしょうか。それともStadia独立して起動させますか?

今の所、我々はChromecastのみに集中しています。でも技術的、機能的な観点からYoutubeがある場所ならどこでも動きます。我々はまだStadiaをどのようにユーザに届けるかは検討中です。

コントローラに話が戻りますが、モバイル端末にはやはり物理的なアタッチメント必要に思われます。例えばスマホコントローラ接続するような。MicrosoftのXCloudを見ていると操作には実際に問題があるようです。

Googleには解決手段があります

そうでしょう。スマホコントローラ取り付け以外にも、明らかな解決手段としてSwitchのようなクライアント端末を作るのでしょうか?

サービス開始時から提供されるサードパーティによる解決手段サポートしています。他にもアイデアがありますしかし今は話せません。

なるほど。GoogleUbisoftデモを行いましたが、これまでにDoom 2016でもデモを行いました。他にも開発企業はありますか?

良い質問です。私がこのプロジェクトに参加する前からチームは既に何社かと提携しここ何年かの間に技術提供していました。StadiaLinuxベースです。グラフィックAPIはVulkanです。開発企業クラウドインスタンス作成しますので、開発キットも今ではクラウドにありますしかクラウドだけでなく、開発社のプライベートDCでも、机上のPCでも可能です。

すると開発者物理的なHWを持つことが可能ですか?

もしそうしたいなら。でも我々は今後のトレンドが開発でも配布でもますますクラウドへと移行していくと考えています。従って今後数年で開発者にとってクラウド中心、クラウドネイティブゲーム開発での標準となるでしょう。

どの企業自身クラウドシステムを開発しているように見えます。例えばOriginクラウドがあるでしょう。しか必要とされるインフラ要件は、我々がここで話しているような内容を達成するには、3rdパーティには荷が重いように思えます。彼らは自身クラウド継続しながら、Googleシステムを導入するでしょうか。

デベロッパーパブリッシャーはとても賢くクラウドネイティブとなる新しいゲーム体験を達成するために必要ツール技術について考えていると思いますしかしそれは世界中で何千ものアクセスポイントを持つデータセンターを運営することや、それらの運営必要な莫大な投資資本とは異なるものです。Googleは今年単年でも$13Bの資本を投下しています

それはとても巨額ですね。しかしそれでも依然としてシステムを構築しインストールするのは根本的な問題です。多分野に渡る段階的なロールアウトになるのでしょうか?

米国では全ての必要場所に展開が終わっています。Project Stream試験必要環境2018年末には整いました。我々はGoogle社内で、Google社員対象2017年の始めから2年間の間、プライベートテストを行ってきました。2019年には米、加、西欧、英にて このエントリーをはてなブックマークに追加ツイートシェア

2018-05-24

anond:20180524150719

ダメだ! まだ細かくできるだろう!

ちゃん文字列を1ビットずつ取り込んで標準出力バッファリングして一文字ずつ出力する関数を書きなさい!

2013-06-28

http://anond.hatelabo.jp/20130627183517

確かに入出力にバッファーを挟む事で割り込み(Interrupt)が減るので(Stack処理されてるかもしれないが)Queueの処理速度は向上するかもしれません。

ただし

等といったExceptionに対して、特定のアクション(叱る)しか出来ていない事から、上位クラス(上司)が既に存在

本来バッファー存在しているハズだが上位クラスにも以下のようなバグが潜んでいる可能性が高く感じます

※資料不足の為要調査

また、この資料からは詳細はわかりませんが(恐らく)

様に見受けられます

以上の事から、上位クラスおよびFRIEND関係にあるクラスの間に、バッファリングスケジューリング、同期処理をするラッパークラスを挟み

似たようなワーカークラスを取りまとめればいいのではないか?と考えられます

2008-10-12

[][]Grass

Table of Contents: ||||||

オープンソースソフトウェアGISOpen Source software and GISOpen Source software and GIS 1 (6)
オープンソース概念Open Source concept1 (2)
オープンソースGISとしてのGRASSGRASS as an Open Source GIS3 (2)
ノースカロライナサンプルデータセットThe North Carolina sample data set 5 (1)
この本の読み方How to read this book5 (2)
GIS概念GIS conceptsGIS concepts 7 (14)
一般的なGIS原理General GIS principles 7 (6)
地理空間データモデルGeospatial data models 7 (4)
GISデータシステムの構成Organization of GIS data and system11 (2)
機能functionality
地図投影法と座標系Map projections and coordinate systems 13 (8)
地図投影原理Map projection principles13 (3)
一般的な座標系とdatumsCommon coordinate systems and datums 16 (5)
GRASSをはじめようGetting started with GRASSGetting started with GRASS 21 (32)
第一歩First steps21 (16)
GRASSダウンロードインストールDownload and install GRASS 21 (2)
データベースコマンド構造Database and command structure 23 (3)
GRASS6のためのグラフィカルユーザインタフェイス: Graphical User Interfaces for GRASS 6: 26 (1)
QGISgis.mQGIS and gis.m
ノースカロライナを用いてGRASSを開始Starting GRASS with the North Carolina 27 (3)
データセットdata set
GRASSデータディスプレイ3D可視化GRASS data display and 3D visualization30 (4)
プロジェクトデータ管理Project data management34 (3)
新しいプロジェクトGRASSを開始Starting GRASS with a new project37 (7)
aのための座標系の定義Defining the coordinate system for a 40 (4)
新しいプロジェクトnew project
空間投影されていないxy座標系Non-georeferenced xy coordinate system 44 (1)
座標系の変換Coordinate system transformations44 (9)
座標系のリストCoordinate lists 45 (2)
ラスタベクトル地図投影Projection of raster and vector maps 47 (1)
GDAL/OGRツールで、再投影Reprojecting with GDAL/OGR tools 48 (5)
GRASSデータモデルデータの交換GRASS data models and data exchange53 (30)
ラスタデータRaster data54 (16)
GRASS2Dの、3DラスタデータモデルGRASS 2D and 3D raster data models 54 (2)
領域の統合と境界Managing regions and boundaries raster map resolution
ジオコードされたラスタデータインポートImport of georeferenced raster data58 (8)
スキャンされた歴史地図インポートとジオコーディングImport and geocoding of a scanned66 (3)
ラスタデータエクスポートRaster data export 69 (1)
ベクトルデータVector data70 (13)
GRASSベクトルデータモデルGRASS vector data model70 (3)
ベクトルデータインポートImport of vector data73 (5)
xy CAD描画のための座標変換Coordinate transformation for xy CAD drawings 78 (2)
ベクトルデータエクスポートExport of vector data80 (3)
ラスタデータを使うWorking with raster data 83 (86)
ラスタ地図を表示、管理Viewing and managing raster maps 83 (22)
ラスタデータの表示と、カラーテーブルの割り当てDisplaying raster data and assigning a color table 83 (3)
ラスタ地図に関するメタデータを管理Managing metadata of raster maps 86 (2)
ラスタ地図クエリプロファイルRaster map queries and profiles88 (2)
ラスタ地図統計Raster map statistics90 (1)
ラスタ地図ズームと、部分集合の生成Zooming and generating subsets from91 (1)
簡単なラスタ地図の生成Generating simple raster maps92 (2)
再分類と再スケーリングReclassification and rescaling of94 (3)
ラスタ地図raster maps
ラスタ地図タイプの記録と値の置換Recoding of raster map types and value replacements 97 (2)
カテゴリベルの割り当てAssigning category labels99 (4)
マスキングとノーデータ値の取り扱いMasking and handling of no-data values 103(2)
ラスタ地図の計算Raster map algebra 105(10)
整数と浮動小数点データInteger and floating point data107(1)
基本的な計算Basic calculations 108(1)
“if"状態を使うWorking with ``if'' conditions109(1)
r.mapcalcのNULL値の取り扱いHandling of NULL values in r.mapcalc 110(1)
r.mapcalcでMASKを作成Creating a MASK with r.mapcalc 111(1)
特別なグラフ演算子Special graph operators112(1)
相対的座標での近傍演算Neighborhood operations with relative coordinates113(2)
ラスタデータの変換と内挿Raster data transformation and interpolation 115(11)
離散的ラスタデータ自動ベクトルAutomated vectorization of discrete raster data115(3)
連続フィールドの等値線の描画を生成Generating isolines representing continuous fields 118(1)
ラスタデータのリサンプリングと内挿Resampling and interpolation of raster data 119(5)
ラスタ地図オーバーレイマージOverlaying and merging raster maps 124(2)
ラスタデータの空間分析Spatial analysis with raster data126(29)
近傍分析とクロスカテゴリー統計Neighborhood analysis and cross-category statistics126(7)
ラスタフィーチャのバッファリングBuffering of raster features 133(2)
コストサーフェイスCost surfaces135(5)
地勢と分水界分析Terrain and watershed analysis 140(13)
ランドスケープ構造解析Landscape structure analysis 153(2)
ランドスケーププロセスモデリングLandscape process modeling 155(11)
文学的、地下水モデルHydrologic and groundwater modeling155(3)
浸食と宣誓証言モデルErosion and deposition modeling158(8)
ラスタベースモデルと解析に関するまとめFinal note on raster-based modeling and analysis166(1)
ボクセルデータを使うWorking with voxel data166(3)
ベクトルデータを使うWorking with vector data 169(94)
地図の表示とメタデータ管理Map viewing and metadata management169(4)
ベクトル地図を表示Displaying vector maps 169(3)
ベクトル地図メタデータ維持Vector map metadata maintenance172(1)
ベクトル地図属性管理とSQLサポートVector map attribute management and SQL support173(14)
GRASS6でのSQLサポートSQL support in GRASS 6 174(7)
サンプルSQLクエリ属性変更Sample SQL queries and attribute modifications 181(4)
地図再分類Map reclassification 185(1)
複数の属性があるベクトル地図Vector map with multiple attribute tables: layers 186(1)
ベクトルデータデジタルDigitizing vector data 187(5)
位相データデジタル化の一般原理General principles for digitizing topological data187(2)
GRASSでの対話的なデジタイジンInteractive digitizing in GRASS189(3)
ベクトル地図クエリ統計Vector map queries and statistics192(4)
地図クエリMap queries192(2)
ベクトルオブジェクトに基づくラスタ地図統計Raster map statistics based on vector objects194(2)
ポイントベクトル地図統計Point vector map statistics196(1)
幾何学操作Geometry operations196(20)
位相的な操作Topological operations 197(6)
バッファリングBuffering203(1)
フィーチャの抽出と境界のディゾルブFeature extraction and boundary dissolving204(1)
ベクトル地図を修理Patching vector maps 205(1)
ベクトル地図インターセクディングとクリッピングIntersecting and clipping vector maps206(3)
ベクトル幾何の変換と3Dベクトルの作成Transforming vector geometry and creating 3D vectors 209(2)
点からのコンベックスハルとトライアンギュレーションConvex hull and triangulation from points 211(1)
同じ位置の掘り出し物の複数のポイントFind multiple points in same location212(2)
一般的な多角形境界の長さLength of common polygon boundaries214(2)
ベクトルネットワーク分析Vector network analysis216(11)
ネットワーク分析Network analysis 216(5)
直線的な参照システム(LRS)Linear reference system (LRS)221(6)
ラスタへのベクトルデータ変化Vector data transformations to raster227(3)
空間的な内挿と近似Spatial interpolation and approximation230(19)
内挿方法を選択Selecting an interpolation method230(5)
RSTによる内挿と近似Interpolation and approximation with RST 235(2)
RSTパラメタの調整: テンションスムージングTuning the RST parameters: tension and smoothing 237(4)
RSTの精度を評価Estimating RST accuracy241(3)
セグメント化処理Segmented processing 244(3)
RSTとのトポグラフィー分析Topographic analysis with RST247(2)
ライダーポイントクラウドデータを使うWorking with lidar point cloud data249(8)
ボリュームに基づくは内挿Volume based interpolation 257(6)
3番目の変数の追加: 高度のある降水量Adding third variable: precipitation with elevation 258(3)
ボリュームとボリューム-時間内挿Volume and volume-temporal interpolation 261(1)
地球統計学とスプライGeostatistics and splines262(1)

2008-08-16

http://anond.hatelabo.jp/20080816083556

それはたぶん漫画における記号やら文脈やらを拾う慣れの違いと、

さらに拾った記号やらを脳内メモリーで再構築することの速度の違いなんだと思う。

同意。

3倍の速度で読んで、バッファリングして、3倍の速度で処理可能な漫画読み込みエンジンにかける感じじゃないだろうか。

たとえアニメが頭の中で脳内再生されるとしても、それは別に実時間であるとは限らない。感覚として気持ち悪いのは理解できるけど。

そして横だけど、「理解している」のと「楽しむ」のはちょっと違うよなーと思った。「深く理解する」ことを重要視するあたり、オタク的主張なんだと思うけど。

自分はコマの構図とかより全体の流れを楽しむ派だから、むしろ早く読んで一気に頭に入力してしまいたかったりする。まあ、このあたりも趣味的な話。

2008-01-06

回線が遅い

とっても遅い、インターネット

とっても遅い、インターネット

ようつべ見ても、かくかくぎこぎこ

とっても遅い、データ転送

とっても遅い、データ転送

ストリーミングが、役に立たない

とっても遅い、ダウンロード

とっても遅い、ダウンロード

再生止めて、バッファリング、るんるん♪

2007-11-23

BUFFERING…

バッファリングって「今、バファリン飲んでますよ=頭痛いですよ」って意味として流行るべきだと思った。

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん