Sampler Feedback Streaming の威力が如何にものすごいかについて

立て続けにゲームハードウェアに関する考察です。
今回は Series X|S の密かな技術革新、Sampler Feedback Streaming (SFS) について。

SFS が如何にスゲーか、の考察に入る前に、2つの技術要素についてまず考察します。

その1:Texture Streaming

昨今、ゲームはいよいよ高解像度化し、次世代では True 4K が一つの大きな柱となります。
しかし、一口に4Kと言っても、ジオメトリを4K解像度レンダリングすることはエッジの精細さにおいて重要ですが、仮にそこに2Kのテクスチャを適用すれば、画面のほぼ大半を占める「エッジ以外のサーフェース」は、結局2Kレベルの情報量にとどまってしまいます。(PS4 Pro の4Kはこの状態でした)
したがって、4K時代にはテクスチャの解像度も4Kであることが必要です。4Kテクスチャは2Kテクスチャに比べて4倍のサイズとなり、1枚で8MBのメモリを使用します。シーンに必要なテクスチャの枚数は据え置いたとしても4倍サイズとなると、PS4/Xbox One世代の8GBメモリから次世代で16GBと倍になっても、まるで足りねえということになります。つまり、テクスチャをそのまんま全部メモリに格納するのは、効率が悪い。

テクスチャマップがミップマップされているのは今般既に常識として、Mipレベルを1つ上げるごとに容量は1/4になり、通常、最も詳細な (4K解像度の) Mipレベル0が必要なのは最も手前のオブジェクトだけで、中距離~遠景のテクスチャはもっとMipレベルの高いものが参照されます。
つまり、中距離~遠景のオブジェクト用のテクスチャを4K解像度のままメモリにロードしても、ほとんど無駄になってしまうということです。
この無駄を削減するには、シーンに必要なMipレベル以上のデータ(これを部分Mipチェーンと呼びましょう)だけをメモリにロードすればよく、さらに詳細なMipレベルのデータが必要になった時点で、ロードしなおせばよいという効率化が考えられます。
これら一連の処理が、テクスチャストリーミングです。

テクスチャストリーミング自体は、別段次世代の技術ではなく、PS4/Xbox One 世代でも Unreal Engine 4 などで機能提供されていて普通に使われています。

https://docs.unrealengine.com/ja/Engine/Content/Types/Textures/Streaming/index.html

が、UE採用タイトルで、シーンの切り替わり直後などに一部のオブジェクトのテクスチャが荒く、徐々に詳細なテクスチャに置き換えられる、という現象を見たことがあると思います。(テクスチャがポップインするなどと言われますね)
あれは「必要なMipレベルの決定」をソフトウェア制御で行っているために、シーンの変化に応じてすぐに最適化しきれていないのが可視化されているわけです。
で、荒いレベルから徐々に詳細なレベルに移り変わるということは、逆もしかりで、もう詳細レベルが不要になったものも、荒いレベルに置き換えられるまでメモリに残留するということになります。

※話は変わりますが、アセット制作においては想定する最高解像度でテクスチャを作成しておけば、上記のしくみで1080pターゲットの場合でも「アセットを作り分ける必要なく」かつ「実行時に無駄なメモリリソースを使ってパフォーマンスが無駄に劣化することなく」動作することがお分かりいただけると思います。〇〇が足を引っ張る!とか言い張っていた方々は、こういう現行世代で普通に使われている技術をご存じないんだと思います(笑)

その2:Tiled Resource

テクスチャストリーミングは必要なMipレベルのテクスチャを選択的にロードする仕組みですが、別のオブジェクトに遮蔽されたり、オブジェクトの裏側部分のテクスチャなど、1枚のテクスチャの中にも描画に必要なものと必要でないものがあります。
MicrosoftXbox One X に特別なHWを追加して「実際に参照されたテクスチャデータ」の統計を取ったところ、ロードしたうちの1/3以下しか参照しないケースが多かったということが判明したそうです。
Tiled Resource は、ミップマップを含むテクスチャを例えば8x8の64個の小さなタイルに分割して、描画時に必要な「各Mipレベル」の「各タイル」だけを組み合わせたものをメモリ(VRAM)に格納し実際の描画にはこちらを使用することで、メモリをさらに効率化するしくみです。
PCであれば、通常は追加で詳細テクスチャの読み込みが必要になった場合は、必要な Mip レベル以下をまるっとメインメモリから転送する必要がありますが、タイル化することで、詳細Mipレベルのうち本当に必要な部分のみに限って転送すればよく、効率化できるようになるわけです。
また、元のテクスチャとの対応は下記の図のように、タイルごとのメインメモリとVRAMとの変換テーブルを介しており、必要なタイルのみをメインメモリから簡単に転送できるようになっています。
https://www.4gamer.net/games/135/G013536/20120106063/SS/006.jpg

※若干話がジャンプしますが、Xbox Series X|S の場合は UMA なのでメインメモリとビデオメモリ間での転送は不要ですが、元のテクスチャをメモリ上に置いていては意味がないので、おそらくこの部分が「仮想メモリとしてメモリマップされたSSD」との変換テーブルとなり、タイル単位で必要なデータのみSSDからロードする形になるものと思われます。(PCのDX12Uでは、タイルをHDDからロードすることもできる)

ここまでの2つの機能は、DX12 アプリケーションであれば、Sampler Feedback がなくても利用可能です。
また、CheckAccessFullyMapped オプションをつけることで、タイリングしたテクスチャに残留しているテクスチャを検知してより最適化することもできるそうです。

ただ、これはソフトウェアでの制御になるため、より積極的に「最適なMipレベルの必要なタイルだけをロードする」ようにするためには、それらを特定するための追加の処理コストがかかるということになります。
また、ミップマップのどのMipレベルから実際にテクスチャをサンプルするかはGPUの処理内で決定されるので、ゲームアプリケーション側からはそれを知ることが難しく、通常はレンダーターゲットの大きさとオブジェクトの奥行きに応じて、「推測で」部分Mipチェーンを生成するしかなかった。
ましてや、テクスチャのどの部分が実際にサンプルされたか (必要なテクスチャタイルを決定する)、についてはさらに推測が難しく、推測するにもGPUコストがもっとかかるので、Tiled Resource については、実は CGN1.0 の世代 (2012年ごろ) から導入された技術にもかかわらず、ほとんど活用されてきませんでした。

実際、Unreal Engine でも、先ほどのテクスチャストリーミングにタイル分割を組み合わせた Streaming Virtual Texturing という機能があります。

https://docs.unrealengine.com/ja/Engine/Rendering/VirtualTexturing/Streaming/index.html

ただし、ソフトウェア処理なので、↑のドキュメントにも書いてあるように、
必要なテクスチャタイルを決定するために「可視性は標準の深度バッファを使用して GPU で計算」される必要があるために、「常に、仮想テクスチャは従来のテクスチャサンプルよりも負荷がかかります。常に、少なくとも 2 回のテクスチャのフェッチと、ある程度の計算命令が発生します。ただし、その負荷の一部は、同じ UV とサンプラーソースを使う VT テクスチャサンプルのスタック (最大8個) をまとめることで削減できます。 」というオーバーヘッドが生じます。
要するに、メモリ効率は良くなるけど、その代わり追加のGPUコストがかかるということです。

ここでようやく、Sampler Feedback の出番となります。

SFSは、DX12と対応GPUの組み合わせで、実際にGPU側でサンプリングされたテクスチャのMipレベルと位置情報をフィードバックすることで上記2つの仕組みのオーバーヘッドを解消し、「1ステップで理想のMipレベルと対象タイルを検出してFeedback Map に書き出す」プロセスを、GPUドライバレベルで最適化することができるのです。(つまり、ゲーム側でソフトウェア的に検知/推測する必要がないということ!)

これがすなわち、Sampler Feedback 付きの Texture Streaming、縮めて Sampler Feedback Streaming なのであります。
SFSでは実際に、前フレームでのテクスチャサンプリング情報をもとに、1フレームの遅延で最適なMipレベルと必要なテクスチャタイルを特定することが可能です。
したがって、目に見えるようなテクスチャのポップインは起きないし、理論値に近いテクスチャメモリの効率化が行えます。

で、実際に SFS を適用しますと、普通にテクスチャをロードするのに比べて、実際のゲームアプリケーションのワークロードでメモリ利用効率が2.5~3.5倍になり、メモリ使用量は3~4割で済むとのことです。
少々古いですが、バイオハザード5でビデオメモリの6~7割がテクスチャ予算に割り当てられたということなので、Xbox Series S で当てはめてみると、10GBのうちゲーム部分が8GBとし、ざっくり半分の4GBをGPU用メモリとしましょう。
このケースでは、4GB中6割のテクスチャメモリは生では2.4GBですが、SFS を適用して1/3の部分読み込みで済めば800MBで事足りるということになります。
(ちょうどこの瞬間くらい https://youtu.be/fYtJWIxt3-M?t=173 )
https://i.gyazo.com/eddb3e329a4ee96fdaa67c0cdf91936b.jpg

逆に、2.4GBにフルにテクスチャを詰め込むとすれば、利用効率3倍と考えて、7.2GBの生のテクスチャメモリ相当となる。
これは、物理搭載メモリ16GBとしてGPUに8GB、そのうち6割がテクスチャとした場合の 4.8GB よりも多いテクスチャメモリ予算となります。

16GB搭載したマシンで普通にテクスチャをロードしたのと同じクオリティを、SFS ありでは10GBメモリで十分実現できるということになりますし、となれば実際に16GBのメモリを搭載しているマシンでは…言わなくても分かりますね。

また、実質800MBをロードすればよいのであれば、Xbox Series S|X の SSD の 2.4GB/sec(RAW) という読み込み性能で計算すると、BCPack 圧縮によりテクスチャが50%に圧縮されているとして、圧縮状態で400MBの readで 済むため、0.16秒でロード可能となります。(これは60fpsであれば10フレーム相当)
実際には、シーンが大きく変わらない限りは全てのタイルを読み直す必要はないはずで、「全てのテクスチャタイルをSSD (上の仮想メモリ) から読み込む」というケースを考えた場合でも、60fpsの場合で1フレームごとに800MBのうち1割をロードしなおすことができます。(1タイル64KBになるようにタイル分割した場合で、1250タイル)

https://youtu.be/fYtJWIxt3-M?t=179

上記のデモでテクスチャタイルの状態が可視化されていますが、これを見てもタイルの読み込み直しは「目で追える」レベルなので、毎フレームごとに1割も読み直すことはほぼ起きえないと思います。
(めっちゃ速い移動みたいなシーンで追いつかない可能性はありますが、そんなスピードで画面が流れていたら普通はモーションブラーをかけてテクスチャのディティールは潰れますし、かけなくたってほぼ目で追うことはできないと思われます)

さて、ここまでで、Sampler Feedback Streaming が想定通りの威力を発揮すれば、大量の物理メモリを積まなくても、十分な品質のテクスチャをSSDからストリーミングできるということが分かると思います。
(Series S に限らず、PS5 や Series X の 16GB というメモリも今のゲーミングPCの実情からするとけっこう少な目なんですが、"SSDからのストリーミングで十分いけるのでメモリはそんなに大量じゃなくていい" というのが次世代の共通思想なんだと思います)

また、速度面に着目すれば、PS5 では Kraken で圧縮されたデータの前提で、実効8GB/sのreadとなり、この前提で仮にテクスチャデータ8GB分の読み込み時間はちょうど1秒となります。
一方、XSS|XではテクスチャをBCPackで圧縮した前提で実効4.8GB/sのreadとなり、8GBそのものを読み込む場合は1.67秒かかる計算となるが、ここでSFSにより効率が2.5倍になるとすれば3.2GBのロードでよく、この場合の読み込み時間は0.67秒となります。仮に効率が下がったとしても、1.6倍の効率まで落ちて読み込み1秒です。

実際には、PS5 においても先ほど挙げた Unreal Engine の Streaming Virtual Texturing のようなソフトウェアベースのテクスチャロード効率化テクニックを使うことはできます。
しかし、SFSのキモは繰り返しますがこの「可視テクスチャタイルの特定」オーバーヘッドをハードウェア側(GPU)でほぼ追加コストなしに実行できる (フィードバックするしないに関わらず、Mipレベルの決定とテクスチャの特定位置からのサンプルは当然ながら GPU が行うので、あとは Feedback Map の更新のコストだけで) ために、理論値に近い効率かつ、通常1~2フレームの遅延でゲーム側が「本当に必要なテクスチャタイル」を検出できるという部分にあります。

同じAMDのRDNA世代なので、もしかするとサンプラーフィードバックの機能自体はPS5のGPUにも搭載されている可能性がありますが、グラフィックスAPIGPUハードウェアの組み合わせでこれを行うという仕組みについては Microsoft が特許を抑えているらしいので、HWベースで同じことを行うのは、ひょっとすると難しいかもしれません。
あるいは、同じRDNA世代でもPS5のGPUは Primitive Shader をサポートし、Series X|S では Mesh Shader をサポートするという違いもあるので、そもそもサポートしていないかもしれません。
また、Sampler Feedback Streaming はあくまでテクスチャに関する技術なので、昨今のゲームにおいてテクスチャ容量がとにかく肥大しているためにますます有効になる技術ではあるのですが、当然、テクスチャ以外のロードに関しては効かないため、8GB/secと4.8GB/secというI/O性能の差はそれ以外の部分には出てくるものと思われます。
この辺は、実際に両ハードが発売されてからのお楽しみというところでしょうか。

なお、DirectX12の機能なので、PCでも対応しているGPU (現時点では Turing 世代の GeForce) との組み合わせで利用できます。

というわけで、PS5 の超高速SSDとの差を埋めつつ、Series S のメモリ搭載量の少なさもカバーしてくれるかもしれない、Streaming Feedback Sampler についての考察でした。

Xbox Series S と X の間のスケーラビリティについて

先日ごちゃごちゃ書いた、「Xbox Series S のスペックが、世代交代時の縦マルチと同様、次世代全体の足を引っ張るのだ、だから早晩SSもSXも横マルチから外されてますますPS5のみのタイトルが増えるだろうねゲハハハハ」というクソゲハ的な煽りに対する技術的考察について、IGNにとてもよくまとまったインタビュー&解説記事が出てたので、参考までに。

掲示板やSNSで引用/援用されたものを含む、開発者たちの反応をまとめたスレ
https://www.resetera.com/threads/devs-react-to-the-xbox-series-s-specs.284204/


XboxデベロッパーがXbox Series Sに制限されることはないと明かす――ビジュアルがスケールダウンするだけでSeries Xと同等のゲーム体験を提供可能」
https://jp.ign.com/xbox-scarlet-xbox-4/46926/news/xboxxbox-series-sseries-x

要約しつつ若干補足も入れると、

  • ビジュアルは普通にスケールする(これがまず大前提)
  • 前世代より8倍強力なCPUと40倍(raw)~80倍(圧縮時)高速なストレージI/Oという部分は S も X も同じ
  • 可変レートシェーディング、DirectXレイトレーシングXbox Velocity Architecture という DX12U 世代の機能も同じ
  • 劇的に高速化したI/Oは「長いロード時間を隠すための長い廊下や不必要なエレベーターといったものがもはや不要になることから、開発元がレベルデザインなどにアプローチする方法も変わる」という変化を生み出し、この部分は Series X とも PS5 とも同じ (※PS5の方がより高速化されているという違いはあります)
  • (筆者補足) このように、ゲームの核となるデザインやレベルデザインに関わる部分はほぼ同等性能なので、あとは想定出力ターゲットが 4K なのか 1440p なのかという部分で、これは GPU パワーの差により普通にスケールする
  • そして、想定ターゲットが低解像度ということは、Series Sではゲームのインストールサイズが小さくなるということ

Xbox Series SのゲームサイズXbox Series Xよりも小さくなる」
https://jp.ign.com/xbox-series-x/46927/news/xbox-series-sxbox-series-x

  • Series SのゲームサイズはSeries Xのものよりも約30%ほど小さくなる
  • 1440p 60 fpsのパフォーマンスのXbox Series Sについては、デベロッパーは最高レベルのミップマップにはしないでしょうから、ゲームサイズは小さくなります
  • デベロッパーが柔軟性を持って、適切なアセットをインストールできる

インストールサイズは3割ほど小さくなる、ということで内蔵のSSDの 1TB 対 512GB という差を埋めるほどではないですが、インストールサイズが小さいということは当然アセットの類が小さくなってるということで、Xのメモリ16GBに対してSのメモリが10GBで3割強小さくなっているところも、アセットサイズの縮小によりおおよそ問題ないということが分かります。
(それでも少し溢れるのであれば、SSD仮想メモリとして使うことも可能。Xbox One/PS4 世代以降の hUMA メモリの場合、仮想部分も物理メモリと同じくメモリマップドで完全透過的にアクセスることができます)

最後の部分で少し煽るとすれば、「デベロッパーが柔軟性を持って、適切なアセットをインストールできる」構造になってますし開発キットでもそれをサポートしてますので、「AAAタイトルではアセットを作り分けるとかやってないんだ」という例のご意見は、「できない、やってないのではなく、お前んとこができない/やってないだけだ」といったところでしょうか(笑)
https://cdn.discordapp.com/attachments/515617838984069121/753748806570344468/unknown.png
※もとのTwitterでの発言は既に消されているようです

また、現行世代と次世代で大きくパワーアップしたCPUについては、現行世代でも「ボトルネックになってるのはCPU」という開発者の話がいくつかあります。
「Gears 5ではどうやって4K/60fpsを実現したのか、CPU負担を減らすためにやったこと。」
https://wpteq.org/xbox/post-52832/

Xbox One Xは2017年に非常にパワフルな性能で登場し、従来の4倍の性能を備えたGPUを搭載しました。 しかしCPUは変化が比較的少なかったこともありCPU性能がボトルネックとなっているタイトルも少なからずありました。 マイクロソフトはProject Scarlettではさらなる改善と成長を予定していますが、Rayner氏はXbox One Xで4K/60fpsを実現するためにCPUの負担を如何に減らし、処理を合理化するかの取り組みについても語っています。

「シミュレーション速度は2倍以上となりました。 同じリアリティ、そしてプレイヤー数を維持できるようにCPUの最適化が非常に多く行われたんです。 多くのシステムがCPUの計算からGPUの計算へと移動させています」とRayner氏は語ります。

「SCORN開発者「最大のゲームチェンジャーはSSDではなく、Xbox Series XとPlayStation 5のCPU。」」
https://hidebusa1.com/2020/05/17/scorn%E9%96%8B%E7%99%BA%E8%80%85%E3%80%8C%E6%9C%80%E5%A4%A7%E3%81%AE%E3%82%B2%E3%83%BC%E3%83%A0%E3%83%81%E3%82%A7%E3%83%B3%E3%82%B8%E3%83%A3%E3%83%BC%E3%81%AFssd%E3%81%A7%E3%81%AF%E3%81%AA%E3%81%8F/

誰もがSSDを次の大きなものとして売り込んでいますが、確かにSSDはアセットの読み込みと転送に大いに役立ちます。しかし、現在の世代で1番の問題を引き起こしている最大の原因はCPUです。これが、現在の世代と比較した次世代の最大の違いです。実際、PlayStation 4Xbox Oneに使用されているJaguarベースのCPUと、PS5(最高3.5GHz)とXbox Series X(最高3.8GHz)のZen 2ベースのCPUへの飛躍は、非常に大きなものになるでしょう。

ということで、CPUの差とストレージI/Oの差にはボトルネックとなるような埋めがたい差があるが、GPUとアセット周りはかなりスケールさせやすい、ので Series S と X で S が足かせになるということはない、と前回、前々回に書いたこととほぼ同内容ですが、改めて。

多種多様なスペックのPCで動かす前提のPCタイトルでは、テクスチャ解像度とかジオメトリのディティールとか解像度とかプリセットから選んで、どういうPCでもそれなりのfpsが出せるよう、つまりはスケールするように作られてますよね。以前からずっと。

次世代ゲームコンソールについて云々

またまたゲハっぽい話題を。

西川善司の3DGE外伝:GIJE技術担当と次世代ゲームについてざっくばらんにトークしてみる」
https://jp.gamesindustry.biz/article/2009/20090701/

西川善司さんの記事が出てたので、記事に対する感想をざっくばらんに。

Series S の詳細スペックが出てから、特にやはりみなさん GPU の性能差について喧々囂々たる反応が見られたわけですが(笑)、私もCPUについてはあまり着目してませんでした。今の世代なりにだいぶ早くなったなー、という程度で。
しかし、記事中の下記にあるように、

PS5:32 FLOPS×8コア×3.5GHz=896GFLOPS
XSX:32 FLOPS×8コア×3.8GHz=972.8GFLOPS
となる。ちなみに現行機PS4Xbox OneのCPUの理論性能値は,
PS4:8 FLOPS×8コア×1.6GHz=102.4 GFLOPS
Xbox One:8 FLOPS×8コア×1.75GHz=112GFLOPS
だ。

改めて比較してみると、わずか0.3GHzの違いとは言え、76.8GFLOPSの差があるんですね。
これをPS4の102.4GFLOPSを基準にすれば、PS4の0.75台の差があるということで、そう考えると小さくもないかなという印象でした。

しかも、PS5 についてはCPU3.5GHzというのはこれ自体今のCPUとして特段高クロックではないですが、GPU側と熱設計枠を共有して片方が高負荷の場合はもう片方は自動的にクロックが下がる SmartShift という仕組みなわけで、現時点の 7nm プロセスのGPUとしてはだいぶ高い boost clock 2.23GHz で動作するタイミングでは CPU 側クロックが落ちる可能性もあるのではないかと。(というか落とす必要がないならわざわざ SmartShift しないで両方 boost ではなく定格クロックにすればいいわけで)
(7nm でなく 7nm enhanced だとしてもそこは同じ)

それから、メモリについては私もちょっと気になっていたんですが、

https://news.microsoft.com/ja-jp/2020/09/11/200911-introducing-xbox-series-s/

に、

AMD の RDNA 2 グラフィックス アーキテクチャを採用することで得られた高効率な処理性能に加え、Xbox Velocity Architecture によるバーチャル メモリ乗算器を活用することで、Xbox Series S は単純なスペックを大幅に超えたパフォーマンスや体験を皆さんへお届けします。

という記述があるんですね。(原文では "With the increased efficiency we get from the next generation AMD RDNA 2 graphics architecture combined with the virtual memory multipliers enabled through the Xbox Velocity Architecture, Xbox Series S will deliver performance and experiences well beyond the raw specs." )

16GBでもちょっと心もとない中、アセットはFullHD相当でかなりメモリ消費量を抑えるとしても、10GBはやっぱりちょっと足りないのでは、という印象はあったのですが、

それと,今回はPS5もXSXも,SSDのための専用バスシステムを持っていて,そのSSDへのアクセスシステムが進化していますよね。PS5のアーキテクトのMark Cerny氏も「PS5のSSDはRAM的に使える」みたいなことを力説していましたから,RAMはこのくらいで手を打とうということなんでしょう

っていう事なんでしょうか、やはり。
現行世代では基本的に「今この瞬間には必要でなくても近々必要になるアセット」はすべてメモリ上に載せておく必要があり、また HDD のランダムアクセス性能のため、同じオブジェクトでもシーン内に必要な分データをコピーして置いておく、みたいな作りが一般的でした。
これが、(一番遅い Series S だとして) 224GB/s のメモリアクセスに比べたら全然遅い圧縮4.8GB/s の Storage I/O でも、現行世代の HDD への I/O よりは40倍くらいは早いんで、メモリに乗りきらない分はSSDを「仮想メモリ」的に取り扱い、必要なデータを必要な瞬間に、かつ SSD のランダムアクセス性能を生かして、事前複製など無しにロードするという事であれば、Series S の10GBでも何とかなかるのかもしれません。(仮想メモリへのアクセス依存度が高くなれば、X に比べたらフレームレートが少し落ちたりするでしょうが)

https://www.eurogamer.net/articles/digitalfoundry-2020-xbox-series-x-silicon-hot-chips-analysis

DF の Hot Chip のレポートを読んでも、メモリのコスト低下は以前は年30%くらいで推移してたのが、今は5%も落ちないので、Xbo360 の 512MB メモリが Xbox One で 8GB に増えたみたいなお大尽は、もうできないと。
そんかし、テクスチャは既に4K解像度の時代になってるが、サンプラーフィードバックにて本当に必要な Mip レベルのものだけロードするようにすれば、メモリが2.5倍になったような効果があると。
そして、HDD ではなく SSD を採用することで初期にはコスト高になりますが、NAND flash は年23%くらい低コストになってるんで、長い目で見ればコストカットになると。
これらが Xbox Velocity Architecture や DirectStorage の前提であり考え方なのであると。

また、MS はこの辺を DirectX12Uの仕様として取り込んで、PC 側のアーキテクチャが置いてきぼりにならないようにしてると。
(ちょっと飛びますが、西川善司さんの記事で、「圧縮展開DMA転送付きSSDパイプライン」機能が,結局のところ「業界全体の取り組み」としている部分ですね)

※Series S のメモリが10GBという点を指して、10GBの制約に収まるようにアセットを用意しないといけないから、16GB積んでる X や PS5 はそれに足を引っ張られるんだ!みたいなアホな話が一部界隈で騒がれていましたが、
https://news.microsoft.com/ja-jp/2020/09/11/200911-introducing-xbox-series-s/
の解説にあるように

次世代に向けて開発されているゲームタイトルは、Xbox Series X と Xbox Series S のどちらに向けても最適化される予定です。

CPU や I/O 性能において、Xbox Series S は Xbox Series X と同等の性能が実現されており、抑えられた解像度でレンダリングを行いながらも、素晴らしいゲームをより簡単に Xbox Series X と Xbox Series S 向けに送り出せるように配慮してあります。

Smart Delivery に対応したタイトルは皆さんがプレイしているデバイスを認識し、それが Xbox Series X、Xbox Series S、Xbox One のどれであっても、対象のコンソールに最適化されたバージョンが用意され、タイトルの購入を 1 回で済ませられるようになっています。

Xbox Series X と Xbox Series S は同じ開発環境とツールや機能性があり、開発者はより容易に、複数の次世代コンソール機の性能に沿う形でコンテンツの開発とリリースを行えるようになります。

とちゃんとスケールするように考慮されており開発環境でもサポートされていることが明記されていますし、サンプラーフィードバックとかがまさにこの辺の差異を吸収するための仕組みですし、どうしても10GBに収まらなければfpsは落ちるかもしれませんがSSD仮想メモリ的に使えるし、SSDのランダムアクセス性を前提にアセットを調整すれば、これまでみたいにシーケンシャルリードのためにデータを無駄に複製したりしなくて済むので、アセットのサイズはむしろ小さくなる可能性すらありますから、仕組みをちゃんと理解していればそんな心配をする必要はほとんどないということが理解できると思います。

あとDFの記事ではクイックレジュームについても触れられていますが、Xbox One X タイトルで実行時の最大メモリ使用量は9GB、SSDに保存してあるこのイメージのレジューム復帰に6.5秒とのことでした。早い!

戻って、メモリシステム詳細の余談のとこで、16ビット×20チャンネルで320ビット幅と書かれてたので、560GB/s の帯域幅から逆算すると、QDR のメモリクロック3.5GHzだと思われます。
とすれば Series S のメモリ構成は、同じ1バンク16ビットとすれば 8GB ぶんは8チャンネルの128ビット幅で 224GB/s、2GBぶんは2チャンネルの32ビット幅で56GB/sでしょうか。
(帯域幅はさておきレイテンシまで異なると色々大変そうなので、クロックとメモリモジュールは同じで、チャンネル数で調整ってのはそんなに外れてないと思います)

続いて、GPU のお話ですが、VRS については、これまでの可変解像度をさらに進めて、全画面一律的に解像度を落とす、というのを、イメージ的には「描画されるものの視覚的重要度に応じて、部分的に解像度を落とす」という処理なので、記事にあるように、Direct X の機能に組み込まれる前提で、ドローコールごとの Tier 1 の処理は結構使われていくのではないかと思います。
プリミティブ単位 or タイル単位となる Tier 2 は使いどころが難しそうですが、タイル単位については、ごく単純に、レースゲームや FPS 等で基本的に注視点が画面真ん中になる場合、画面外周部は解像度落としてもそんな気づかないよね、というシナリオでは使えそうですよね。(あとは特にこれは VR について有効)
シェーダ負荷の方がドローコールよりボトルネックになってる場合で、VRS を使うと30%から場合によっては50%くらいフレームレートが改善したという例もあるようです。

レイトレーシングについては、記事中にあるように、正直実行性能がまだ不明なので何とも言えないけど、基本的にはこれまでのシェーダ描画を基本にしつつ鏡面反射や屈折表現のみをレイトレースで行うハイブリッドレンダリングなのは間違いないところだと思われるので (GeForce RTX 2080 でさえフルレイトレースする性能は持ってない)、RDNA2.0 でのレイトレース性能が Turing の何倍もありますっていう事が起きない限り、やはり部分的な鏡面反射や屈折表現の「演出」に使われるに留まるだろうということは想像に難くありません。
あとはRTハードウェアを活用した大域照明のリアルタイム演算。(これは Halo 5 が SLIPSPACE ENGINE で目指している、事前計算の大域照明やベイキングを排した完全リアルタイムのライティングシステムにも密接に関わってくるはずです)

で、PS5 の GT7 のデモを見ても、パドックに格納されるシーンのこれでもかの鏡面反射は、DF の見立てによると鏡面反射部分はゲーム全体の4K描画に対して1/4解像度の1080pレンダリングになっているようなので、XSX にしてもまともに4Kでレイトレース描画は厳しかろうと思います。
https://www.youtube.com/watch?v=Azl772uylh4

またそうなってくると Series S ではさらに解像度を落として鏡面反射描画を行わざるを得ない (レイアクセラレータはCUごとに1つあり、X の52CUに対し20CUでダウンクロックもされてるので、レイトレース性能も1/3) ので、さすがに 540p とかまで行くと (1ピクセルあたりの視覚への寄与が大きくなるぶん) かなりアラが目立ちそうですし、BVH や KD-Tree と言ったレイトレ用の空間構造データを持つためにさらにメモリも必要になるので、タイトルによっては、いっそのことなし、とされる可能性は否定できません。
(※HWとしては持ってるので、Series S ではレイトレースは一切サポートしないって意味ではもちろんないです、念のため。いまのスクリーンスペースリフレクションがレイトレースリフレクションになるくらいは普通にできると思います)

この辺はデベロッパの腕の見せ所となりそうですが、PCとのマルチ展開を考えると RTX 以上が必要な表現はどちらにせよ今しばらくは「オプショナル」な扱いにとどまるものと思われます。
つまり、レイトレの在り無しでゲーム内容に差が出るようにはしないだろうと。(例えば FPS で遮蔽物に隠れてる敵がその後ろのガラスとか水たまりに反射して見える、とか)

個人的には一刻も早く Minecraft RTX の Xbox Series X 版が見たいですね。Series X 上で、1080p で 30~60fps くらいで動作しているそうです。

Unreal Engine 5 の解説についてはだいぶ興味深いですね。
マイクロポリゴン (1ポリゴンが1ピクセル以下) と言われるとそれって映画のレンダリングじゃんと思ってしまうんですが、マイクロポリゴンで何が言いかというと↓この記事にあるように
https://www.4gamer.net/games/999/G999902/20130824013/
「現実的なメッシュで複雑なアニメーションを作って」
「クロースシミュレーションとかソフトボディシミュレーションとかもがっつりかけて」
が現実的な作業時間で行えて、それでいて
レンダリングの瞬間にマイクロポリゴンまでテッセレーションするので見た目も素晴らしくなる」
ということのはずなので、最初からマイクロポリゴン化したデータをSSDからストリーミングで読み込んでレンダリングする、という手法に、どの程度のアドバンテージがあるのかは微妙に思いました。
記事中にあるように、ボーン変形とかさせるには頂点数が膨大すぎて実時間で終わらないでしょうし、物理シミュレーションにも向かなさそうです。
指摘の通り、「静的な背景オブジェクト」や「移動と回転くらいのオブジェクト」あたりに用途は限定されそうです。
実際、マイクロポリゴンレベルのメッシュから作った高精細なノーマルマップがあれば、それから AO を計算することもできるはずですし、ハイトマップにしてレンダリング時にテッセレーションかけるのと比べてどういうメリット・デメリットがあるんでしょうね。

なお、Nantie 自体は、DX12U に対応していないGPUでもソフトウェアラスタライザとして (GPGPU で) 動作しますが、PS5 の場合は Primitive Shader を使ったハードウェア実装の方が早かったのでそうなっているということです。
https://www.eurogamer.net/articles/digitalfoundry-2020-unreal-engine-5-playstation-5-tech-demo-analysis
キモは「LoDなしのマイクロポリゴンデータから早期カリングで描画に必要なものだけに超ガッツリ落とす」ところだと思われ、それをソフトウェアラスタライザで実現しているとあります。
メッシュシェーダも「タスクシェーダ (Amplification シェーダ) でのLoD管理・LoDオブジェクト生成、Meshlet単位でのカリング」と「メッシュシェーダーによるMesh単位のカリング」なので、大枠、似たような機能ではありますから、XSX の GPU でもメッシュシェーダによるハードウェア実装が出来ないってことはなさそうに思います。

テッセレーションだと分割後の形状が完全コントローラブルとは言いにくいので、予期せぬ形状になったりシャドウマップでアーティファクトが発生してしまう可能性がありますが、Nantie ではその辺の問題は起きにくいですかね。

Lumen については SLIPSPACE ENGINE などと方向性は同じで、事前計算なしの大域照明を目指すもので、これについては明確にメリットがあると思うので、実際のゲームへの組み込みが楽しみです。

音については、Series X|S では「Project Acoustic」技術で3D空間での反響を含む音の伝播をシミュレートし、それを「Dolby Atmos」で360度定位させて、ホームシアターであれば7~34(!!)チャンネルのサラウンドに落とし込み、ヘッドフォンであればHRTFで2chに落とし込む、という流れですかね。
https://www.dolby.com/gaming/

記事中ではランタイム処理はCPU処理だろうとありましたが、Series X では音声処理用に専用のチップを載せてるという話があります。
https://twitter.com/JamesStanard/status/1241113225757724672
https://news.xbox.com/en-us/2020/03/16/xbox-series-x-glossary/

Project Acoustics – Incubated over a decade by Microsoft Research, Project Acoustics accurately models sound propagation physics in mixed reality and games, employed by many AAA experiences today. It is unique in simulating wave effects like diffraction in complex scene geometries without straining CPU, enabling a much more immersive and lifelike auditory experience. Plug-in support for both the Unity and Unreal game engines empower the sound designer with expressive controls to mold reality. Developers will be able to easily leverage Project Acoustics with Xbox Series X through the addition of a new custom audio hardware block.


10年以上にわたってマイクロソフトのリサーチによってインキュベートされたProject Acousticsは、今日の多くのAAA体験に採用されているミックスリアリティやゲームにおける音の伝搬物理学を正確にモデル化しています。複雑なシーン形状での回折などの波動効果をCPUに負担をかけることなくシミュレートすることができ、より没入感のあるリアルな聴覚体験を可能にします。UnityとUnrealの両方のゲームエンジンへのプラグインをサポートしているため、サウンドデザイナーは表現力豊かなコントロールでリアリティを作り上げることができます。開発者は、新しく追加されたカスタムオーディオハードウェアブロックを通じて、XboxシリーズX で Project Acoustics を簡単に活用することができます。

そいで最後、西川善司さんが、PS5 Digital Edition は単なるドライブレス版ではなく、ソニー版の GamePass のようなサブスクサービスと合わせて提供するのではないか、と予想しているところは少々驚きました。
僕はそこからは一歩引いて、Series S に単なるドライブレス版で価格的に対抗するのは無理なので、PS Plus で「毎月いくらいくら払う」というチャンネルはあるから、携帯の割賦払いのようにあるいは Xbox All Access のように、24回払いとかで買える施策を出してきそうだな、と妄想していたので。

PS Now については一部のPS4タイトルはストリーミングではなくダウンロードして遊べるようにはなってますが、土台がやはり「ストリーミングサービス」であり(&どっちかというとPS3以前の後方互換の代用の印象が強い)、GamePass のようにファーストパーティータイトルやインディータイトルがリリース日初日から(なんだったらアーリーアクセスまである)遊べるというサービスではないため、もし、PS陣営が GamePass のようなサブスクリプションサービスを準備しているとすれば、個人的にもめっちゃ大歓迎です。

と、ほんとにつらつらと書いていたら滅茶苦茶に長くなってしまいました。

かなり乱暴にまとめると、PS5 はストレージ速度で少しアドバンテージ、Xbox Series X は CPU/GPU 性能的に少しアドバンテージがあるけど、双方目指している姿はだいたい同じ!
Xbox Series S と Xbox Series X は、基本的にはちゃんとスケールする!
ハードウェアだけじゃなく、サービスの部分でも GamePass みたいなサブスクが PS 陣営でも始まるといいな!!
といった感じです。

とりあえず、いろんな意味で17日の映像イベントが楽しみですね! (Xbox 側のエジンバラについても水曜に何かあるっぽかったし)

Xbox Series S のメモリ帯域幅の話

はい、Xbox Series S (以後 XSS と表記) のスペックのお話(妄想)です。
※めちゃくちゃ長い上に文字だけです!

発表されたスペックを見ますと、GPUXbox Series X (以後XSXと表記) の約12TFLOPS に対し、4TFLOPS とされています。
で、XSX はターゲット解像度が4K、XSS はターゲット解像度が 1440p とされていまして、単純に、シェーダ負荷は同じで解像度だけでスケーリングするとなると、ピクセル数の比率で言えば

  • 4K が 3840 x 2160 = 8294400
  • 1440p で 2560 x 1440 = 3686400

となるので、4K に対して約 0.44 倍の負荷となります。
んで、この比率を 12TFLOPS に当てはめると、5.3TFLOPS ないと足りないはず。

なので恐らくですが、ネイティブ解像度は 1920 x 1080 あたりで、そこから DirectML によるAIアップスケーリングで1440p に持っていくのではなかろうか、と思われます。

その前提だとピクセル数比率で言えば4Kに対して0.25倍となりますので、12TFLOPSに対し3TFLOPSあればよろしいという計算に。
そして HotChips 2020 で発表された GPU ブロックダイアログを見る限り、RDNA2 の GPU には GeForce で言うところの Tensor コアのようなものはないようで、推論計算は CU の SIMD32 ALU で行うようです。

https://cdn.videocardz.com/1/2020/08/Xbox-Series-X-Slide13.jpg

RDNA2 では FP32 に INT8/INT4 をパッキングして計算できるので、例えば INT8 であれば4つパッキングして処理、FP32 で 1TFLOPS のところ、INT8 なら 4TOPS の処理が可能です。
そして推論計算では INT8/INT4 のオペレーションが主のようなので、計算上あまった 1TFLOPS 分の処理能力を使って、INT8で4TOPS、INT4で8TOPS の推論処理を行って DirectML べースのAIアップスケーリング処理を行うと。(全て推測ですがね)

このへん、nVidia の DLSS では例えば GeForce RTX 2070 の Tensor コアが INT8 で 119.4TOPS の能力があってこれを使って計算してるんで、ちょっと桁が違うわけですが、DirectML ベースのAIアップスケーリングがどのくらい重たいかが分からないので、現時点では何とも言えません。

と、ここまではいいとして、次はメモリのスペック差です。

XSX はトータル16GBのGDDR6メモリのうち、

と発表されています。
で、後者の 6GB のうち 2.5GB ぶんが OS とフロントエンドシェル (平たく言えば Xbox ダッシュボード) に使われて、残りの3.5GBがGPU用以外のオーディオとかスタックメモリとかプログラム本体とかの雑多な用途のメモリということです。
https://www.eurogamer.net/articles/digitalfoundry-2020-inside-xbox-series-x-full-specs

で、流石に容量も大きいし帯域幅も広いなあ、と思っていたわけですが、XSS の発表されたメモリ周りのスペックを見ると、トータル10GBのGDDR6で、内訳が 8GB@224GB/s、2GB@56GB/s だというではありませんか!

えっ、56GB/s !?
56GB/s…うーん…あの遅かった Xbox One の主メモリですら 68GB/s なんだけど…遅ない!? という。
かつ、GPU用が 10GB から 8GB と20%しか容量が減ってないわりに、それ以外用が1/3になっているという比率の違いがすごく引っ掛かります。

想定レンダーターゲットが 1/4 になって、恐らくテクスチャも XSX では4Kターゲットのテクスチャ、XSS ではそこから1段ミップマップした 1080p ターゲットのテクスチャを使うだろうと考えると GPU メモリにロードするテクスチャ容量も1/4になるわけで、頂点データとかは XSXでもXSSでも変わらないとして、GPU用には多くて3~4GBもあれば足りそうなところ、GPU用のみに8GBとするとなんか不自然にリッチです。
一方帯域幅としては 560GB/s → 224GB/s と6割減。なにか釈然としない。

で、XSS の想定解像度で考え直すと GPU に 4GB、オーディオデータ等は変わらないと思われるので CPU その他用には XSX と同じく 3.5GB と考えると、合計して7.5GB。ふむ、早いほうの 8GB に収まるではないですか???
とすると、56GB/s しかない 2GB の方は、完全に OS とシェル用で、8GB@224GB/s の方でゲーム部分を賄う設計なのかな、という気がしてきませんか???

XSX では OS+シェルに 2.5GB 取るといってたので、0.5GB 足んないじゃん、という気がしますが、そこはきっと何か色々削って帳尻を合わせているのではないかと思います。クイックレジュームまわりとか。(超適当)

なんだか結論ありきの話の展開になってしまいましたが、いや実際、そうだと思わないと 2GB@56GB/s というのはなかなかに驚きの数字でして。
単純に数字間違ってましたー、っていう可能性もあるんですが、そうすると逆にGPU用/CPU用の比率で考えたときにいびつすぎる。

ということで推測通りだとすると今度は、XSX と XSS でメモリ管理まわりが変わってくるということで、なんとなく、Xbox One X でのフラットな 12GB GDDR5 に対する Xbox One の eSRAM の特殊性、みたいなことが思い出されるわけですが、MS が言うには「パフォーマンスがちょっと変動するだけで、Unified Memory であることには変わりないよ」つーことなので、あまり問題にならないのかもしれません。

そう考えると、OS+シェル分の2.5GBを差っ引けば、

  • XSX ではゲーム用に13.5GBのUnifiedメモリがあって帯域幅は (加重平均すれば) 約502GB/s
  • XSS ではゲーム用に8GBのUnifiedメモリがあって帯域幅は 224GB/s

と考えられ、4K→1440pでの描画負荷0.44倍に対し、メモリ帯域幅も約0.45倍と、なんとなく納得できそうな感じに!

とはいえ、GPU側は解像度でスケーリングするので0.45倍で良いですが、CPU側から見てメモリアクセスが遅くなるのは問題になりそうです。
(敵のAIの思考が遅くなったりしたらゲーム性変わってしまう)

が、実際のところ、CPUから見たメインメモリの帯域として考えると (XSX の) GDDR6 336GB/s というのがべらぼうに早くて太いというだけで、ゲーミングPCでもメインメモリの主流は GDDR4、帯域幅は規格上最高の PC4-34100 のデュアルチャネルでも高々 68.2 GB/s です。
なので、ゲームのCPU側のメモリ帯域に対する要求が急に何倍にもならない限り、そこんところは大丈夫そうです。
(※一般論として、CPUからのメモリアクセス速度は解像度ではなくどちらかというとfpsに効いてくる)

まあ、ホントのところは実際に発売された上で同じゲームを XSX, XSS で比較しないと分かりませんが、机上であれこれ考えるぶんには、XSS も十分に高性能な気がします。

問題は「予約できるか」ですよ。本当に。
なんとなく、SNS 等での反応を見ていると、フォートナイトとかそういうの普通に遊べて、Game Pass というのもあるらしいし、カジュアルゲーマーなら XSX で十分なんじゃね? という風に今まで Xbox ユーザでなかった方が気づき始めているようなので、マジで、マジで、転売屋の餌食にならないことを、本当の本当に祈る次第であります!!!!

PS5 では米国にて、これまでの PSN でのアクティビティにより、「徳の高い方」を優先的に予約ご招待みたいなプログラムを実施するとのことですが、Xbox 陣営も、今既に Game Pass Ultimate に入っている人とか、実績の解除数が多い人を優先するとか、そういう感じで現行ユーザーをなんとか救済していただけると本当に助かるなあ!!と、勝手なことを願ったりしています。

あと、XSS って書くとなんかクロスサイトスクリプティングみたいでアレですね。(今更)

超いまさら ZTE M Z-01K の話

しばらく前に変態2画面スマホこと ZTE の M Z-01K がイオシスで投げ売りになっていたのでおもしろ全部で買ってみたのですが、

  • とにかく重い
  • 形状の特殊性からTPUケース等の選択肢が皆無に等しく、唯一あるドコモの純正ハードケースは値段が4千円くらいする上に在庫なし。そのため自動的に裸運用になる

という条件のために「落としたら最後」感が極めて高く、そのため結局バッグの中にしまったまま(ポケットに入れるには厚すぎて重すぎる)となり、たまに思い出してバッテリー切れ状態から充電してまたバッグの中にそっとしまう、みたいな運用になってしまっています。(もはや運用とは言わない気が)

そもそも、裏も表も画面のため、テーブルに置く時ですら気を使いますからね…。

んで、重さはスペック的には226gで、昔全然普通に使ってたズルトラで 214g、それと比べても +12g の差しかないわけですが、なんでしょうね、持ってみると明らかにずっしりと重い。

ズルトラの場合は大きくて平べったい感じだったので感覚的や重心といった部分で数字ほどの重さを感じなかったのかもしれませんが、Z-01K はサイズ的には一般的な5.2インチクラスのサイズで、厚みが2倍弱という感じなので、体感的にスニッカーズばりのみっしり感を感じてしまいます。

あと、メイン端末はいま ZenFone Max Pro (M2) なのですが、これのサブ機として考えるに、メインで賄えないおサイフとか、防水といったところが補完できればよいのですが、Z-01K はどちらも非対応なので、出番がないんですね。いや、そこは買う前から分かっていたけども。

肝心かなめの2画面のところですが、確かに、Youtube 見ながらもう一方でブラウザ使ったりTwitter見たりという用途には、大変によろしいです。
ただこれ、1台持ちであれば Z-01K じゃないとできない(画面分割すればできるけど実用的じゃない)けど、スマホ2台持ちであれば別に普通にできてしまうので、僕にとっては Z-01K でないとならん理由としては弱い。

唯一、Youtube の URL をコピーして Twitter などに貼っ付ける、みたいなオペレーションに関しては、とても便利です。

ただ、その程度の便利さのためにわざわざメイン端末使ってる時にバッグから取り出すかというと、そこまでじゃないんだよなあ。

あとはバッテリーが地味に持たないのも辛い。メイン端末が 5000mAh というバッテリー容量が売りの機種のため、それと比較して余計に持たなく感じてしまいます。数値上では 2930mAh と一般的なスマホ程度のバッテリー容量ですが、2画面分の表示を考えると一般的なスマホより稼働時間が短くなってしまうのは当然で、どうせこれだけ重いのならいっそ3500mAh以上は欲しかったところです。

なんとなく、捨ておくには惜しい魅力は感じつつ、でも実際には使いどころがないというこの端末。
(メイン端末がこれしかない、なら何とか頑張って使っていたかもしれませんが、サブ機としては本当にもう…)
なにかよい使い道がありませんかねー。

THE LAST REMNANT Remastered 購入、ほか色々

ec.nintendo.com

年末セールにてラストレムナントを購入しました。

Xbox360版も当時買ってて、あの頃スクエアは「Xbox360にもJRPGを!!」みたいな感じだったのでFFとかみたいなのを期待してたら全然ちゃうやんって感じでかなり序盤で積んでしまいましたが、今改めて「これってロマサガとかの系譜なんやな」ということを理解してプレイすると、結構なかなか面白い。

セリフ回しとかはいかにもスクエアらしいというか学芸会っぽさ全開でちょっとアレだけど、戦闘システムがやっぱり歯ごたえがありますね。

最序盤のガスリン洞窟ボス戦でちょっと適当にやったらあっさり全滅しましたもんね。で、そのまま装備も何も変えず再戦したら、圧勝。

こういう、戦術レベルで一手間違うだけで戦局がこれだけ変わるバランスって、やはり当時としてもなかなか珍しかったのではないでしょうか。

 

と言うことで、例によってディアブロ3も全くまだまだ途中ながら、一旦切り替えてしばらくはラストレムナントを進めようかと思います。

 

あとは気になってたけど結局消化しきれずに積むだけだなあと思いつつ今回年末セールなので結局買っとくか、と言う感じで

を購入。

ティースカイラインは Steam 版を持ってるし、なんなら Xbox Game Pass で Xbox One 版も遊べるのですが、やはり家でゲームする時間がなかなか取れないので、通勤中に都市建設したいわな、ということで。

 

あと気になってるところとしては、

と言ったあたりで、この2本は結局年末年始で買ってしまいそう。

 

あとやっぱり通勤中にも頭蓋骨ぶち抜きのキルカメラ見たいよねということで Sniper Elite 3 Ultimate Edition とか、往年のセガマニアとしては ToeJam & Earl: Back in the Groove! はもはや購入の義務があるだろと思いつつ、ただ、後者についてはこないだ Xbox One 版買ってしまったんですよね。

で、大学生から社会人なりたての頃、正月に実家に帰省するたびに、弟と二人でビール飲みながらダラダラ4時間くらい初代トージャム&アールを遊んでた思い出に浸ろうと思ったんですが、初代が BPM60 くらいのオールドスクールなブーンバップだったとすれば、Back in the Groove は感触としてはやはりブーンバップなんですが BPM が 90 くらいになった感じで微妙に忙しくなり、これはこれで愛すべき感じではあるんですが、若干やはりコレクターズアイテム感が拭えないというのも正直なところだったり、あとボーナスステージ的なものがあるんですがこれが例のMD版の2みたいな横スクロールしかも高速で、背景のチープサイケ感も相まってジェネシス版の Panic on Funkotron のパッケージ内に入ってた地獄みたいなピンク色のグミ? ガム?(あまりの見た目に、食ったら死ぬんじゃないかと思いつつ一口齧りましたが、地獄のような味がしたので後は捨てた) を思い出させて若干「GROSS!!」な感じだったりして、まあともかく、Switch 版もさらに買うほどでもないかな…というところだったりします。

 

そんなこんなであと Xbox Game Pass の方では今

  • The Outer Worlds
  • Subnautica
  • Sniper Elite 4

をプレイしててそれぞれまだ全くの途中なのですが、そこに加えてウィッチャー3も来てしまったため、完全に時間が足りない状態となっています。

ウィッチャー3、噂に聞いてた通り、ストーリー主軸で、導入から演出まで、かなり濃厚ですごいですね。ほんとまるで映画のよう。んで、現在は最序盤でマップを自由に動けるようになった瞬間、メインクエの「リラとスグリの香り」を放置して、墓場に突撃して悪霊に殺されそうになったり、ホワイト・オーチャード各地の力の場を開放して回ったり、ババアのフライパンをピカピカにしたり、川辺のドラウナーを自由気ままに狩ったりしています。(正直、オープンワールド系って最初のここが一番楽しい)

 

あと Untitled Goose Game もちょろっとプレイして、非常に可愛くていいんですが、思ったよりパズル的な知恵を使う感じですね。私の今のモードとしては、知恵はあんまり使わずに、深海に潜って素材採取したり、チマチマと海中基地を建設して、安全に活動できる範囲を広げていきたい感じです。

いやマジで、サブノーティカは序盤の鮮烈なゲーム体験 (ゲームで心底恐ろしいと思ったり不安になったり美しい景観に感動したのマジ久しぶりです) とともに、ゲームプレイ的にもここ数年レベルにマジで面白くて目下大ハマり中です。

Steam でのレビューがまたすごくいいんですよね。

投稿日: 7月1日
初めてこの惑星に降り立った時の不安
初めてシーモスを手に入れた時の昂揚
初めて深海エリアに潜る時の恐怖
初めてリーパーリヴァイアサンに出会った時の絶望
初めてロストリバーを探検した時の感動

最後にこの惑星を見送る時の郷愁

初回プレイでしか味わうことができない様々な感情。
出来る事なら記憶を消してまたこのゲームを最初からプレイしたい。
そう思えるぐらいの素晴らしいゲーム。
この手のジャンルで一番濃いゲーム体験ができた。
興味があってまだ未プレイという人は是非。
投稿日: 12月12日
久しぶりにゲームらしいゲームをやり終えた心地である。
このゲームには、激しい戦闘も煩わしい協力()プレイも存在しない。
静かな水の音と呼吸音。邪魔にならないCPのナレーションと素敵なBGMが、プレイヤーを包み込んでくれる。
後半、やや冗長な部分や壁抜け等のバグに見舞われる事もあったが、ゲームを余暇として、また少年の様にドキドキする心地で楽しめたのは何時以来の事であろうか。
週末は異星の海に潜ろう、自分だけの秘密基地で過ごす為に。

ということで、家でゲームできる可処分時間が完全に足りてないんで、今回の Steam ウィンターセールも、Xbox のセールも1本も買っておらず、PS Store のセールに至っては見てすらいない有様。

(PS4 はバッカーリワードのシェンムー3で手いっぱいで、20時間くらいプレイしてまだ白鹿村をウロウロしている始末です)

 

Steam では、Hand Simulator: Survival とか、遂にセールに入った Kenshi、Noita あたりが気になりますねー。Noita とか、ぜひ Switch にも移植して欲しいと思うんですけども。(似たような感じのアガルタ・S も面白かったです。)

 

今年の年末年始は帰省とかしない予定になったので、さーてどのくらい積みを崩せるかなあ!

携帯モード専用グリップコントローラーを買った

hori.jp

 

デモンエクスマキナは買ってないくせに、HORI の携帯モード専用グリップコントローラだけ発売日に買いました!

(初期出荷を逃して品切れしたらしばらく買えなさそうだったので)

 

僕の場合もっぱら通勤中にバイオ4やったりバイオHDリマスターやったりマイクラやったりしていて、ジョイコンもすごくいいんですけどもやっぱり右スティックの位置が微妙で親指が疲れがちなので、プロコンみたいなグリップ形状の互換コントローラが欲しいナァと1年半くらい前からずっと思ってまして、この DXM コンが発表されたときからこいつぁ完璧に望み通りのブツだと、ずっと狙っていたわけであります!

 

 

事前情報で振動には対応しないというのは分かっていたので、分かっていたのですが、実際に使ってみて携帯モード用プロコンとしては本当にもう完璧でこれ以上何を求める?という感じだったので、逆に本当に、ああ、あと振動さえ対応していれば完璧だったのに… *1 と思ってしまった次第であります。

 

事前情報ではよく分からなかった点として、装着したままドックに入るのか? という疑問がありましたが、これについては全く問題ありませんでした。

 

背面ボタンについては、割り当てられるのは左側コントローラでは左側コントローラのボタン、右側コントローラでは右側コントローラのボタンという仕様なので、例えば FPS でよくある左十字キーでのサブ操作を右側コントローラの背面ボタンに割り当て、とかはできません。

これについては現時点でまだ追加ボタンが欲しくなるような複雑な同時押しをするタイトルを遊んでないので、困ってもないし恩恵も受けてないのですが、FPS でよくある、左スティック押し込みでダッシュ、と言うのが実はけっこう苦手なので、いわゆる L3 ボタンを左側コントローラの背面ボタンに割り当てる、とかは結構イケんじゃないかなと思っています。

 

あと現物届いて色々分かった点として、本体とジョイコンを合体させるレールコネクタ、金属なのでそこそこ丈夫だとは思うんですけど、DXM コンでは背面側の一番後ろに追加のガードパーツがあって、仮に反った時にそこが支えになるような感じになっていて、安心感があります。(そいでもって、これがドックにも干渉しないようになってる)

 

f:id:tripleshot:20190919164606p:plain

右上の所の黒いポッチ

あと、需要があるのかは分かりませんが、これ自体は無線接続じゃないのでレールコネクタで合体しての携帯モード専用ですが、取り付けた状態でさらにジョイコンやプロコンを2番目、3番目のコントローラとして接続することは可能です。

なので、一人は本体持って、もう一人はプロコンで、二人で画面覗き込みながらスマブラで対戦、とかも一応可能でした。

 

基本的には自分用として購入しましたが、ウチのボウズたちの Switch に取り付けて使わせてみたところ、すげー使いやすい! おれ次の誕生日プレゼントこれにしようかな…と言ってました。携帯モードでスマブラやるにはかなり具合が良いようです。お子様へのプレゼントとしても良いかもしれません。

 

また、ウチの子供たち用 Switch のジョイコン、落としてR側ジョイコンのR1ボタンが壊れておりまして*2、よそのご家庭でもあるかと思いますが、故障してしまったジョイコンの買い替えに…となると、純正ジョイコンが希望小売価格ベースで¥7,480、こちらの DXM コンが¥4,780 なので、

  • ジャイロやNFCはなくても割り切れる
  • ないしはプロコンがあるので必要な場合はそちらでどうにかする
  • HDどころかSDの振動もないが、そこは気付かなかったフリができる

のであれば、ジョイコンとはやはりレベルの違う使い心地の良さというメリットで、十分選択肢に入ってくるのではなかろーか、とも思います。

(なお、重量についてはジョイコンより当然重いんですが、数十グラムの話だし、本体297gに左右80g足しても457gで、Wii U ゲームパッドの500gよりまだ軽いため、個人的にはほぼ気になりませんでした)

 

目下の所最大の課題はとにかくデカいというところで、そんなもん買う前から1200%承知ではあるのですが、現実問題としてやはりデカい。

 

従前は GAMETECH のソフトポーチを愛用しており、程よい厚みで保護しつつ他のハードケースのように厚みも出ず、しかも収納状態で充電ケーブルも挿せるという優れものでして、これにスポッと収納した上で通勤リュックのインナーポケットへ格納しておりました。

 

gametech.co.jp

 

が、DXM コンを装着した状態だと、当然、全然入らねえ。はみ出るとかいうレベルじゃなく、先っぽ (※DXMコン) がもう入らねえ。

苦肉の策として左DXMコンを外した状態で入れて見たところ、入ることは入るが右コンは盛大にはみ出るし、外した左コンはどーすんだという。

 

そんなわけで、HORI さんにはぜひ、この携帯モード専用グリップコントローラを装着した状態で全体をすっぽり格納できるソフトポーチをぜひ出していただきたい。(GAMETECH さんでも構いません!)

その際はついでに、DXM コンの厚みに対して Switch 本体が薄くて空間が空くはずなので、そこに標準ジョイコンL/Rも格納できるインナーポケットも付いていたら完璧じゃねえかと考える次第であります。

*1:ジャイロとNFCはまあ、個人的にあまり必要とするタイトルをプレイしていないのでいっかなって

*2:分解してみたらR1ボタンのタクタイルスイッチパーツが基盤からもげてしまっており、素人レベルでは再はんだ付け不能