アカウント名:
パスワード:
MSの発表を見る限り、中身はほぼAMDのMantleにしか聞こえないのだけどMantleのAPIは未定義 [impress.co.jp]で開発任せな現状らしいのでAMDは始めからMSにDX12を作らせる目的でMantleを発表したのではないか、と思ってしまう。DX12の後ろにいるのはAMDのようだし。
>DX12の後ろにいるのはAMDのようだし。nVidiaじゃない? nVidiaはMantleに相当するものが無い(作ろうと思えば作れるでしょうけど各社ばらばらなAPIを作ったら開発者からそっぽを向かれてしまいます)からMicrosoftにお願いしてAMD、nVidiaどちらも使えるAPIを策定してもらったのだと思っています。
ミドルウェアの開発元にMantle対応をお願いするときに、DX12も同じだから今やっておけば他社に先行できますよ、とか言ってそう。しかし、OpenGLはIntelががんばってるし、今回のDX12はAMDの影響が強い。NVIDIAはどうしちゃったんだろう。モバイルと科学技術計算以外は興味なくなったのかな。
NVIDIAもOpenGL方面に力入れてると思いますよ。SteamOSが発表されたあたりでValveと協力してOpenGL最適化がんばるって言ってたんで。
Quadro の存在価値がなくなるから、GeForce での対応をまじめにやるとは考えがたいんだけど
少なくともモバイルでは、OpenGLしかないんで真面目にやるんじゃないかな。Quadroは従来の動作認証に加え、今後GPU仮想化に対応したファームウエアやら。CUDA/OpenCLやらで差別化を進めるんじゃないか
AMDは過去にRadeonで独自実装していたテッセレーションをDirectX11にほぼそのまま採用させたことがあるので今回のMantleとDirectX12もその時と同じようなものでしょうね
4亀の記事だとAMDが上手くやったのかしてやられたのか不明でしたけど、Impressの記事だとどうも上手くやった方みたいですね。
【GDC 2014】米MS、DirectX 12を発表。より“ダイレクト”な3D APIへ進化 [impress.co.jp]
これに引き続き、各CPU/GPUベンダーが対応を報告。AMDではDirect X12そのもの開発にも協力しており、Xbox Oneにも採用されたGCNアーキテクチャー世代のGPUにて、ユーザーはDirectX 12のリリースの瞬間からその利点を享受できるようになるとしている。
NVIDIAやIntelも「現行アーキテクチャで対応」と言ってるけど、Mantleで先行してる分AMDが有利？
これ [impress.co.jp]をみると、マルチスレッドに幾分最適化されているようですし、以前のようなシングルスレッド性能偏重なゲームは減ることをAMD派の私なんかは期待しています。
ついでに、Xbox oneにも水平展開するということは、今は劣勢なMSもシェア奪回のキーだと考えているんでしょうね。こうなってくると、（一応）同じAPUを使っているPS4がどのように対応してくるのかと、素人ながら期待しています。
PS4にはDirectX11互換的なAPIもあるらしいですよ。たぶん12にも対応するんじゃないでしょうか。
もちろん出してくるでしょうが、時間差があるはずなので、その間はXBox有利かも。
Xbox one の場合は対応するだけで、性能面での直接的向上はないそうですよ。
それよりもDirectX12が、Kinect2とVR関連へ対応しなかったのは正直驚きました。
（Windowsとゲームを含む）PC業界の停滞を打破するためにもXbox one 支援のためにも、標準機能として実装は固いと言われていたので。。。
キネクト対応しなかった意味が分からん。というか折角のチャンスだったのに、勿体無い…
APIが未定義で開発任せ、ってどういう状況なのかさっぱり分からないんだが…
リンク先には
Mantleはやっかいで、何も定義されてない。ゲーム機のAPIと似てはいるけど互換じゃない。
とは書いてありますが、APIが未定義とは書いてないように思いますが…。実際、Wikipediaには
Mantle is a graphics API specification developed by AMD as an alternative to Direct3D and OpenGL, primarily for use on the PC platform.
とあります。
「Mantleはやっかいで、何も定義されてない」という記載は意味不明です。というか、専門家気取りの半可通がいいかげんなことを言ってる記事で、ARM 32-bitの箇所とか、読んでてこっちが気恥ずかしくなってきますね。
MantleはGPUへのアクセスを提供するだけで、その結果は保証されない。GPUの実装に依存する。という意味でないの。
ふむ。どのように間違ってるんでしょ？＞ARM32bitの箇所
自分は半可通どころか努素人なので、ほほーと思って読んでたけど、いいかげんな話だったのか…。割り算命令無いとか、前世紀のリレー式計算機かよって思ったもんな。
でも、32bitのARMv7Aではハードウェア整数除算器が標準でないのは確かよ。Cortex-A9まではハードウェア整数除算器がないのが普通。この辺が参考になりそう。http://blog.kmckk.com/archives/4164432.html [kmckk.com]http://blog.kmckk.com/archives/4170081.html [kmckk.com]
元記事の表現が、いいおじさんがしゃべってると思うと恥ずかしくなっちゃうのは確かだけど、書いてある内容自体はまともなことです。ARMv8は64bit化というよりも、ARMv7までの継ぎ足し変態仕様が解消されるのを喜ぶ人は多いと思う。
いやー、RISCってそういうものじゃないの？ハードウェア除算器とかそういう複雑な回路は排除して、単純な命令の組み合わせでそういう処理を行わせるのとあわせて個々の単純な命令の処理サイクルは最低にとどめて全体の実行速度の向上を図るという方向性。
なのに「ハードウェア除算器がない」とか言われても。
RISCの思想を分かってないから、半可通ってことですか？そりゃ古のRISCはそういう思想だったけど、ここ5年～10年のCPUでRISCだから単純になんて考えてるCPUはない。ハードウェア除算器が回路が大きいって言われたのは昔の話で、Out-of-Order実行のA9でそんな話を振られても意味が分からないよ。
ARM自身にしたって、より規模が小さい組み込み向けのMシリーズにはハードウェア除算器載ってるし、AシリーズでもA15からは採用してる。
あれかなあ、プロセスルールの進化でトレードオフの評価が変化したのかなあ
ARM自身にしたって、より規模が小さい組み込み向けのMシリーズにはハードウェア除算器載ってるし、
Cortex-M0 は除算命令なかった気がしたし AVR もそうじゃなかったかな?
規模的には除算機を組み込めても、組み込み用途では割り込みのレスポンスが悪くなるので敢えて採用しない、みたいなケースもあるんじゃないかと思いますね。
プロセスルールが変化しても除算が1サイクルでできることはないのでRISCの思想に合わないことに変わりはないが?
今時、原理主義でRISCの思想に合わんから使わないなんて設計しないでしょ。
ほほーと思ったんと違うんかい
【山田】つまり今のARMの32bitはひどいと。【後藤】ひどい。だって、僕の知り合いでネイティブARM 32bitに触れた人は皆「変態命令セット」って言ってるし(笑)。
【山田】つまり今のARMの32bitはひどいと。
【後藤】ひどい。だって、僕の知り合いでネイティブARM 32bitに触れた人は皆「変態命令セット」って言ってるし(笑)。
自分でプログラム組んだことない素人でしょ
後藤さんがプログラム組めるかどうかは知らないけど、彼の記事、いつもは結構参考になるんだけどな。あとARMの命令セットが変わってるのは事実でしょう。自分は結構好きだけど、あれコンパイラは最適化しにくいんじゃないかと思う。
あとARMの命令セットが変わってるのは事実でしょう。
条件実行や3オペランドはARM以前のプロセッサと比べては変わってると思うけど、レジスタの数については騒ぐようなものではないと思う。
コンピュータを使うと言うことがそのままプログラムを組むと言う事だった時代からこの界隈でライターやってる二人を捕まえて素人とは恐れ入った
だったら自分の言葉で語れって話だよなあ、直接 ARM 使った経験なかったとしても、他のアーキテクチャ習熟してれば「RISCなのに汎用レジスタが16本しかない」なんて馬鹿発言はそうそう出ない筈。
何がひどいか? RISCなのに汎用レジスタが16本しかない、その内の3本はプログラム関連で使っちゃうので、汎用に使えるのはたった13本。これで、ロード/ストアアーキテクチャのハンドリングをしなきゃならない。そうするとコンパイラが効率的なコードを吐けない。ので、コードステップが非常に長くなる。
確かにこれはひどいね。素人以下。
ので、コードステップが非常に長くなる。
なるほどわからん。レジスタ不足だから、主記憶に退避でもしているのだろうか。
レジスタに割り付けられないローカル変数はスタックフレーム(主記憶)に割り付けられる、が、ARM の仕様でそれほと問題になることは実際大してない。thumb ならまた別だが。
確かに生成されたコードを見ると、レジスタが足りなくてロード、ストアが頻出するってことは少ない気はする。ただ、x86-64の例を見ると、汎用レジスタが増えるのはやっぱり効いてくるんではないかと思う。Apple A7の性能向上も64-bit化自体が効いてるとは考え難いし。
ただ、x86-64の例を見ると、汎用レジスタが増えるのはやっぱり効いてくるんではないかと思う。
IA-32 → x86-64 で汎用レジスタが何個から何個になったかご存知?
知ってるけど、それが何か？もともとCISCの設計思想、かつスタックベースの命令が多いx86と、RISCの流れのARMとのレジスタの絶対数を比較してもあんまり意味が無いんじゃない？PPCやMIPSは32本のGPRを持ってるよね？あとA7については憶測だけど、レジスタの増加がパフォーマンスに全く効いてないとは考え難い。コンパイラで使うレジスタの数を制限するフラグでもあれば比較できて面白いかも。
もともとCISCの設計思想、かつスタックベースの命令が多いx86と、RISCの流れのARMとのレジスタの絶対数を比較してもあんまり意味が無いんじゃない？
汎用レジスタはいくつくらいあればまあ不足はないかというのを判断するのにRISCもCISCもあんま関係ないのでは?
「スタックベースの命令が多いx86」ということだけど、汎用レジスタ上にデータ置くのとスタックフレーム上に置くのとで違いがないのであれば(あり得ないが)、x86-64 で汎用レジスタの数を増やしたメリットはないですね。
x86のシステムレベルのアセンブリコード書いたことある？オフトピだからこれで最後にするけど、x86はメモリアクセスの遅延の影響を避けるために相当の資源を割いているよね。レジスタリネーミングはご存じ？実際のレジスタの数は、その辺のRISCよりよほど多いんじゃなかろうか。
x86はメモリアクセスの遅延の影響を避けるために相当の資源を割いているよね。
それでもレジスタアクセスより遅いしコードも長くなりますね。何が言いたいんでしょうか?
レジスタリネーミングはご存じ？実際のレジスタの数は、その辺のRISCよりよほど多いんじゃなかろうか。
あなたがレジスタリネーミングについて理解されてないことは分かりました。
x86のシステムレベルのアセンブリコード書いたことある？
話題の流れとして何か関係のある話ですか?
どうとでもとれる中途半端な書き方をして、明言を避ける。質問で返して、相手の揚げ足をとろうとする。知ったかぶり同士の会話は微笑ましいね。
実際のレジスタの数は、その辺のRISCよりよほど多いんじゃなかろうか。
自分も上のACと同じ理解してるけど間違ってるの？
まあ、これでも読んでくれhttp://yarchive.net/comp/linux/x86.html [yarchive.net]
レジスタに割り当てられるデータの数に影響する技術じゃないよ
OoOで、同時に使われるレジスタは実質的には増えますが？
コード上でのレジスタに割り当てられるデータの数は増えないよ
なんだ、トロールか。真面目に聞いて損した。
RISCでもSPARCは汎用レジスタは実質7本扱いじゃなかったっけ？あとはコールスタックとかレジスタウィンドウとかの絡みで色々と面倒な数え方だったかと。
ARMより後発のSuperHでも16個
これのことじゃないかな？ (Wikipediaより)：> As of March 2014, the Mantle specification and development materials remain unavailable to the general public.
仕様が一般には公開されてないってことだけど、実はまだいろいろ決めてる段階なんじゃないの？
だとしても現にそれで動作してるゲームがある状況で「何も定義されてない」はないよねえ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
Mantleは当て馬？ (スコア:0)
MSの発表を見る限り、中身はほぼAMDのMantleにしか聞こえないのだけど
MantleのAPIは未定義 [impress.co.jp]で開発任せな現状らしいので
AMDは始めからMSにDX12を作らせる目的でMantleを発表したのではないか、と思ってしまう。
DX12の後ろにいるのはAMDのようだし。
Re: (スコア:0)
>DX12の後ろにいるのはAMDのようだし。
nVidiaじゃない? nVidiaはMantleに相当するものが無い(作ろうと思えば作れるでしょうけど各社ばらばらなAPIを作ったら開発者からそっぽを向かれてしまいます)からMicrosoftにお願いしてAMD、nVidiaどちらも使えるAPIを策定してもらったのだと思っています。
Re: (スコア:0)
ミドルウェアの開発元にMantle対応をお願いするときに、DX12も同じだから今やっておけば他社に先行できますよ、とか言ってそう。
しかし、OpenGLはIntelががんばってるし、今回のDX12はAMDの影響が強い。NVIDIAはどうしちゃったんだろう。
モバイルと科学技術計算以外は興味なくなったのかな。
Re:Mantleは当て馬？ (スコア:1)
NVIDIAもOpenGL方面に力入れてると思いますよ。SteamOSが発表されたあたりでValveと協力してOpenGL最適化がんばるって言ってたんで。
Re: (スコア:0)
Quadro の存在価値がなくなるから、
GeForce での対応をまじめにやるとは考えがたいんだけど
Re: (スコア:0)
少なくともモバイルでは、OpenGLしかないんで真面目にやるんじゃないかな。
Quadroは従来の動作認証に加え、今後GPU仮想化に対応したファームウエアやら。CUDA/OpenCLやらで差別化を進めるんじゃないか
Re: (スコア:0)
AMDは過去にRadeonで独自実装していたテッセレーションをDirectX11にほぼそのまま採用させたことがあるので
今回のMantleとDirectX12もその時と同じようなものでしょうね
Re: (スコア:0)
4亀の記事だとAMDが上手くやったのかしてやられたのか不明でしたけど、Impressの記事だとどうも上手くやった方みたいですね。
【GDC 2014】米MS、DirectX 12を発表。より“ダイレクト”な3D APIへ進化 [impress.co.jp]
NVIDIAやIntelも「現行アーキテクチャで対応」と言ってるけど、Mantleで先行してる分AMDが有利？
Re:Mantleは当て馬？ (スコア:1)
これ [impress.co.jp]をみると、マルチスレッドに幾分最適化されているようですし、
以前のようなシングルスレッド性能偏重なゲームは減ることをAMD派の私なんかは期待しています。
ついでに、Xbox oneにも水平展開するということは、今は劣勢なMSもシェア奪回のキーだと考えているんでしょうね。
こうなってくると、（一応）同じAPUを使っているPS4がどのように対応してくるのかと、素人ながら期待しています。
Re: (スコア:0)
PS4にはDirectX11互換的なAPIもあるらしいですよ。
たぶん12にも対応するんじゃないでしょうか。
Re:Mantleは当て馬？ (スコア:1)
もちろん出してくるでしょうが、時間差があるはずなので、その間はXBox有利かも。
本家でも話題になってましたけれど (スコア:0)
Xbox one の場合は対応するだけで、性能面での直接的向上はないそうですよ。
それよりもDirectX12が、Kinect2とVR関連へ対応しなかったのは正直驚きました。
（Windowsとゲームを含む）PC業界の停滞を打破するためにも
Xbox one 支援のためにも、標準機能として実装は固いと言われていたので。。。
Re: (スコア:0)
キネクト対応しなかった意味が分からん。
というか折角のチャンスだったのに、勿体無い…
Re: (スコア:0)
APIが未定義で開発任せ、ってどういう状況なのかさっぱり分からないんだが…
Re: (スコア:0)
リンク先には
Mantleはやっかいで、何も定義されてない。ゲーム機のAPIと似てはいるけど互換じゃない。
とは書いてありますが、APIが未定義とは書いてないように思いますが…。
実際、Wikipediaには
Mantle is a graphics API specification developed by AMD as an alternative to Direct3D and OpenGL, primarily for use on the PC platform.
とあります。
「Mantleはやっかいで、何も定義されてない」という記載は意味不明です。
というか、専門家気取りの半可通がいいかげんなことを言ってる記事で、ARM 32-bitの箇所とか、読んでてこっちが気恥ずかしくなってきますね。
Re:Mantleは当て馬？ (スコア:1)
MantleはGPUへのアクセスを提供するだけで、その結果は保証されない。GPUの実装に依存する。という意味でないの。
Re: (スコア:0)
ふむ。どのように間違ってるんでしょ？＞ARM32bitの箇所
自分は半可通どころか努素人なので、ほほーと思って読んでたけど、いいかげんな話だったのか…。
割り算命令無いとか、前世紀のリレー式計算機かよって思ったもんな。
Re:Mantleは当て馬？ (スコア:1)
でも、32bitのARMv7Aではハードウェア整数除算器が標準でないのは確かよ。
Cortex-A9まではハードウェア整数除算器がないのが普通。
この辺が参考になりそう。
http://blog.kmckk.com/archives/4164432.html [kmckk.com]
http://blog.kmckk.com/archives/4170081.html [kmckk.com]
元記事の表現が、いいおじさんがしゃべってると思うと恥ずかしくなっちゃうのは確かだけど、
書いてある内容自体はまともなことです。
ARMv8は64bit化というよりも、ARMv7までの継ぎ足し変態仕様が解消されるのを喜ぶ人は多いと思う。
Re: (スコア:0)
いやー、RISCってそういうものじゃないの？
ハードウェア除算器とかそういう複雑な回路は排除して、単純な命令の組み合わせでそういう処理を行わせるのとあわせて
個々の単純な命令の処理サイクルは最低にとどめて全体の実行速度の向上を図るという方向性。
なのに「ハードウェア除算器がない」とか言われても。
Re: (スコア:0)
RISCの思想を分かってないから、半可通ってことですか？
そりゃ古のRISCはそういう思想だったけど、ここ5年～10年のCPUでRISCだから単純になんて考えてるCPUはない。
ハードウェア除算器が回路が大きいって言われたのは昔の話で、Out-of-Order実行のA9でそんな話を振られても意味が分からないよ。
ARM自身にしたって、より規模が小さい組み込み向けのMシリーズにはハードウェア除算器載ってるし、
AシリーズでもA15からは採用してる。
Re: (スコア:0)
あれかなあ、プロセスルールの進化で
トレードオフの評価が変化したのかなあ
Re: (スコア:0)
ARM自身にしたって、より規模が小さい組み込み向けのMシリーズにはハードウェア除算器載ってるし、
Cortex-M0 は除算命令なかった気がしたし AVR もそうじゃなかったかな?
規模的には除算機を組み込めても、組み込み用途では割り込みのレスポンスが悪くなるので敢えて採用しない、みたいなケースもあるんじゃないかと思いますね。
Re: (スコア:0)
プロセスルールが変化しても除算が1サイクルでできることはないのでRISCの思想に合わないことに変わりはないが?
Re: (スコア:0)
今時、原理主義でRISCの思想に合わんから使わないなんて設計しないでしょ。
Re: (スコア:0)
ほほーと思ったんと違うんかい
Re: (スコア:0)
自分でプログラム組んだことない素人でしょ
Re: (スコア:0)
後藤さんがプログラム組めるかどうかは知らないけど、彼の記事、いつもは結構参考になるんだけどな。
あとARMの命令セットが変わってるのは事実でしょう。
自分は結構好きだけど、あれコンパイラは最適化しにくいんじゃないかと思う。
Re: (スコア:0)
あとARMの命令セットが変わってるのは事実でしょう。
条件実行や3オペランドはARM以前のプロセッサと比べては変わってると思うけど、レジスタの数については騒ぐようなものではないと思う。
Re: (スコア:0)
コンピュータを使うと言うことがそのままプログラムを組むと言う事だった時代から
この界隈でライターやってる二人を捕まえて素人とは恐れ入った
Re: (スコア:0)
だったら自分の言葉で語れって話だよなあ、直接 ARM 使った経験なかったとしても、他のアーキテクチャ習熟してれば「RISCなのに汎用レジスタが16本しかない」なんて馬鹿発言はそうそう出ない筈。
Re: (スコア:0)
確かにこれはひどいね。素人以下。
Re:Mantleは当て馬？ (スコア:2)
なるほどわからん。
レジスタ不足だから、主記憶に退避でもしているのだろうか。
Re: (スコア:0)
レジスタに割り付けられないローカル変数はスタックフレーム(主記憶)に割り付けられる、が、ARM の仕様でそれほと問題になることは実際大してない。thumb ならまた別だが。
Re: (スコア:0)
確かに生成されたコードを見ると、レジスタが足りなくてロード、ストアが頻出するってことは少ない気はする。
ただ、x86-64の例を見ると、汎用レジスタが増えるのはやっぱり効いてくるんではないかと思う。
Apple A7の性能向上も64-bit化自体が効いてるとは考え難いし。
Re: (スコア:0)
ただ、x86-64の例を見ると、汎用レジスタが増えるのはやっぱり効いてくるんではないかと思う。
IA-32 → x86-64 で汎用レジスタが何個から何個になったかご存知?
Re: (スコア:0)
知ってるけど、それが何か？
もともとCISCの設計思想、かつスタックベースの命令が多いx86と、
RISCの流れのARMとのレジスタの絶対数を比較してもあんまり意味が無いんじゃない？
PPCやMIPSは32本のGPRを持ってるよね？
あとA7については憶測だけど、レジスタの増加がパフォーマンスに全く効いてないとは考え難い。
コンパイラで使うレジスタの数を制限するフラグでもあれば比較できて面白いかも。
Re: (スコア:0)
もともとCISCの設計思想、かつスタックベースの命令が多いx86と、
RISCの流れのARMとのレジスタの絶対数を比較してもあんまり意味が無いんじゃない？
汎用レジスタはいくつくらいあればまあ不足はないかというのを判断するのにRISCもCISCもあんま関係ないのでは?
「スタックベースの命令が多いx86」ということだけど、汎用レジスタ上にデータ置くのとスタックフレーム上に置くのとで違いがないのであれば(あり得ないが)、x86-64 で汎用レジスタの数を増やしたメリットはないですね。
Re: (スコア:0)
x86のシステムレベルのアセンブリコード書いたことある？
オフトピだからこれで最後にするけど、x86はメモリアクセスの遅延の影響を避けるために相当の資源を割いているよね。
レジスタリネーミングはご存じ？
実際のレジスタの数は、その辺のRISCよりよほど多いんじゃなかろうか。
Re: (スコア:0)
x86はメモリアクセスの遅延の影響を避けるために相当の資源を割いているよね。
それでもレジスタアクセスより遅いしコードも長くなりますね。何が言いたいんでしょうか?
レジスタリネーミングはご存じ？
実際のレジスタの数は、その辺のRISCよりよほど多いんじゃなかろうか。
あなたがレジスタリネーミングについて理解されてないことは分かりました。
x86のシステムレベルのアセンブリコード書いたことある？
話題の流れとして何か関係のある話ですか?
Re: (スコア:0)
どうとでもとれる中途半端な書き方をして、明言を避ける。
質問で返して、相手の揚げ足をとろうとする。
知ったかぶり同士の会話は微笑ましいね。
Re: (スコア:0)
実際のレジスタの数は、その辺のRISCよりよほど多いんじゃなかろうか。
あなたがレジスタリネーミングについて理解されてないことは分かりました。
自分も上のACと同じ理解してるけど間違ってるの？
Re: (スコア:0)
x86はメモリアクセスの遅延の影響を避けるために相当の資源を割いているよね。
それでもレジスタアクセスより遅いしコードも長くなりますね。何が言いたいんでしょうか?
まあ、これでも読んでくれ
http://yarchive.net/comp/linux/x86.html [yarchive.net]
Re: (スコア:0)
レジスタに割り当てられるデータの数に影響する技術じゃないよ
Re: (スコア:0)
OoOで、同時に使われるレジスタは実質的には増えますが？
Re: (スコア:0)
コード上でのレジスタに割り当てられるデータの数は増えないよ
Re: (スコア:0)
コード上でのレジスタに割り当てられるデータの数は増えないよ
なんだ、トロールか。真面目に聞いて損した。
Re: (スコア:0)
RISCでもSPARCは汎用レジスタは実質7本扱いじゃなかったっけ？あとはコールスタックとかレジスタウィンドウとかの絡みで色々と面倒な数え方だったかと。
Re: (スコア:0)
ARMより後発のSuperHでも16個
Re: (スコア:0)
これのことじゃないかな？ (Wikipediaより)：
> As of March 2014, the Mantle specification and development materials remain unavailable to the general public.
仕様が一般には公開されてないってことだけど、実はまだいろいろ決めてる段階なんじゃないの？
Re: (スコア:0)
だとしても現にそれで動作してるゲームがある状況で「何も定義されてない」はないよねえ。