ゲーム開発者はなぜWindowsを好むのですか？
OpenGLがクロスプラットフォームであっても、DirectXはOpenGLよりも簡単ですか、それとも優れていますか？ WindowsのようにLinux向けの本当の強力なゲームが見られないのはなぜですか？
ここでの答えの多くは本当に、本当に良いです。しかし OpenGL および Direct3D（D3D） の問題はおそらく対処する必要があります。そして、それには...歴史のレッスンが必要です。
そして、始める前に、私は Direct3D よりも OpenGL についてはるかに知っています。私は人生でD3Dコードの行を書いたことがなく、OpenGLでチュートリアルを書いたことがあります。だから私が言おうとしているのは、偏見の問題ではありません。それは単に歴史の問題です。
紛争の誕生
ある日、90年代前半のある時点で、Microsoftは周りを見回しました。彼らは [〜＃〜] snes [〜＃〜] および Sega Genesis が素晴らしく、たくさんのアクションゲームなどを実行しているのを見ました。そして、彼らは [〜＃〜] dos [〜＃〜] を見ました。開発者はコンソールゲームのようなDOSゲームをコーディングしました。ただし、コンソールとは異なり、SNESゲームを作成した開発者はユーザーが使用するハードウェアを知っていたため、DOS開発者は複数の可能な構成を作成する必要がありました。そして、これは思ったよりかなり難しいです。
そして、Microsoftにはさらに大きな問題がありました。Windowsです。ほら、Windowsはハードウェアを所有したかったのですが、DOSは開発者がほとんど何でもできるようにしています。アプリケーション間で連携するには、ハードウェアの所有が必要です。協力とは、まさにゲーム開発者hateです。それは、彼らが素晴らしいものにするために使用できる貴重なハードウェアリソースを消費するためです。
Windowsでのゲーム開発を促進するために、Microsoftは低レベルで統一されたAPIを必要としており、速度が低下することなくWindowsで実行され、ほとんどすべてのcross-hardwareが必要でした。すべてのグラフィックス、サウンド、および入力ハードウェア用の単一のAPI。
したがって、 DirectX が誕生しました。
3Dアクセラレータは数か月後に誕生しました。そして、マイクロソフトは問題のスポットに遭遇しました。 DirectXのグラフィックコンポーネントであるDirectDrawは、2Dグラフィックのみを扱います。グラフィックメモリの割り当てと、割り当てられたメモリの異なるセクション間でビットブリットを実行します。
したがって、Microsoftはミドルウェアを少し購入して、Direct3Dバージョン3に作りました。それはuniversally悪意のあるものでした。そして、正当な理由があります。 D3D v3コードを見るのは、契約の箱を見つめるようなものです。
Id Softwareのオールドジョンカーマックは、そのゴミを一目見たところ、「それをねじ込んでください！」そして、別のAPI：OpenGLに向けて書くことにしました。
Microsoftである多頭野獣のもう1つの部分は、WindowsのOpenGL実装でSGIとの作業で多忙でした。ここでのアイデアは、典型的なGLアプリケーションの開発者を裁判にかけることでした：ワークステーションアプリ。 CADツール、モデリング、そのようなこと。ゲームは彼らの心の中で最も遠いものでした。これは主にWindows NTのものでしたが、MicrosoftはそれをWin95にも追加することを決定しました。
ワークステーション開発者をWindowsに誘惑する方法として、Microsoftはこれらの新しい3Dグラフィックスカードへのアクセスを提供して買収を試みることにしました。 MicrosoftはInstallable Client Driverプロトコルを実装しました。グラフィックカードメーカーは、MicrosoftのソフトウェアOpenGL実装をハードウェアベースの実装でオーバーライドすることができます。コードは、利用可能な場合、ハードウェアOpenGL実装を自動的に使用します。
当初、消費者レベルのビデオカードはOpenGLをサポートしていませんでした。 CarmackがSGIワークステーションでQuakeをOpenGL（GLQuake）に移植するのを止めることはできませんでした。 GLQuakeのreadmeから読むことができるように：
理論的には、glquakeは、テクスチャオブジェクト拡張をサポートするすべての準拠OpenGLで実行されますが、必要なすべてを高速化する非常に強力なハードウェアでない限り、ゲームプレイは受け入れられません。ソフトウェアエミュレーションパスを経由する必要がある場合、パフォーマンスは1秒あたり1フレームをかなり下回ります。
現時点（'97年3月）で、適切にglquakeを再生できる唯一の標準的なopenglハードウェアは、非常に高価なカードであるグラフ間現実化です。 3dlabsはパフォーマンスを大幅に改善していますが、利用可能なドライバーでは、まだ十分にプレイできません。 glintボードおよびpermediaボード用の現在の3dlabsドライバーの一部は、フルスクリーン実行を終了するとNTをクラッシュさせる可能性があるため、3dlabsハードウェアでglquakeを実行することはお勧めしません。
3dfxは、glquakeに必要なすべてを実装するopengl32.dllを提供していますが、完全なopengl実装ではありません。他のopenglアプリケーションが動作する可能性は非常に低いため、基本的には「glquakeドライバ」と見なしてください。
これがminiGLドライバーの誕生です。ハードウェアがほとんどのOpenGL機能をハードウェアに実装するのに十分強力になったため、これらは最終的に完全なOpenGL実装に進化しました。 nVidiaは、完全なOpenGL実装を提供した最初の企業です。他の多くのベンダーが苦労しました。これが、開発者がDirect3Dを好んだ理由の1つです。それらは、幅広いハードウェアで互換性がありました。結局、nVidiaとATI（現在はAMD）だけが残り、どちらもOpenGLの実装が良好でした。
OpenGLアセンダント
したがって、ステージが設定されます：Direct3D対OpenGL。 D3D v3の悪さを考えると、これは本当に素晴らしい話です。
OpenGL Architectural Review Board（ARB）は、OpenGLの保守を担当する組織です。彼らはいくつかの拡張を発行し、拡張リポジトリを維持し、APIの新しいバージョンを作成します。 ARBは、グラフィック業界の多くのプレーヤーと一部のOSメーカーで構成される委員会です。 Appleおよびマイクロソフトは、さまざまな時期にARBのメンバーでした。
3DfxはVoodoo2に付属しています。これは、マルチテクスチャリングを実行できる最初のハードウェアです。これは、OpenGLが以前はできなかったものです。 3DfxはOpenGLに強く反対していましたが、NVIDIAは次のマルチテクスチャリンググラフィックチップ（TNT1）のメーカーであり、それを愛していました。そのため、ARBは拡張機能GL_ARB_multitextureを発行しました。これにより、マルチテクスチャリングへのアクセスが可能になります。
一方、Direct3D v5が出てきました。現在、D3Dは、猫が吐くようなものではなく、実際の[〜＃〜] api [〜＃〜]になっています。問題？マルチテクスチャリングなし。
おっとっと。
人々がマルチテクスチャリングをあまり使用しなかったので、今、それはそれがあるべきほど多くを傷つけることはないでしょう。直接ではありません。マルチテクスチャリングはパフォーマンスにかなり悪影響を及ぼし、多くの場合、マルチパスに比べて価値がありませんでした。そしてもちろん、ゲーム開発者は、マルチテクスチャリングがなかった古いハードウェアでゲームが機能することを望んでいるため、多くのゲームはそれなしで出荷されました。
したがって、D3Dは猶予されました。
時が経ち、NVIDIAはGeForce 256（GeForce GT-250ではなく、最初のGeForceではありません）を展開し、今後2年間のグラフィックスカードでの競争をほぼ終わらせます。主なセールスポイントは、ハードウェアで頂点変換とライティング（T＆L）を実行できることです。それだけでなく、NVIDIAはOpenGLを非常に愛していたため、T＆Lエンジンは事実上wasOpenGLでした。ほとんど文字通り。私が理解しているように、それらのレジスタの一部は実際にはOpenGL列挙子directlyを値として取りました。
Direct3D v6が登場。ついにマルチテクスチャーが…ハードウェアのT＆Lなし。 OpenGLにはalwaysがあり、T＆Lパイプラインがありましたが、256より前はソフトウェアで実装されていました。そのため、NVIDIAがソフトウェアの実装をハードウェアソリューションに変換するのは非常に簡単でした。 D3DがハードウェアT＆Lを最終的にサポートするようになるまでは、D3D v7まではありません。
シェーダーの夜明け、OpenGLのトワイライト
その後、GeForce 3が登場しました。そして、多くのことが同時に起こりました。
マイクロソフトは、彼らが再び遅れることはないだろうと決定していました。そのため、NVIDIAが行っていることを見て、事実の後でそれをコピーする代わりに、彼らは彼らに行き、彼らに話しかけるという驚くべき立場を取った。そして、彼らは恋に落ちて、小さなコンソールを一緒に持っていました。
乱雑な離婚が後に続いた。しかし、それはまた別の時間です。
これがPCに意味したことは、GeForce 3がD3D v8と同時にリリースされたことです。そして、GeForce 3がD3D 8のシェーダーにどのように影響したかを確認することは難しくありません。 Shader Model 1.0のピクセルシェーダーは、NVIDIAのハードウェアに固有のextremelyでした。 NVIDIAのハードウェアを抽象化する試みは一切行われませんでした。 SM 1.0は、GeForce 3が行ったこととまったく同じでした。
ATIがRadeon 8500でパフォーマンスグラフィックカードレースに参入し始めたとき、問題がありました。 8500のピクセル処理パイプラインは、NVIDIAのものよりも強力でした。そのため、MicrosoftはShader Model 1.1を発行しました。これは、基本的には「8500が行うこと」です。
それはD3D側の障害のように聞こえるかもしれません。しかし、失敗と成功は学位の問題です。そしてepic失敗はOpenGLランドで起こっていました。
NVIDIAはOpenGLを愛していたため、GeForce 3がヒットすると、多数のOpenGL拡張機能がリリースされました。ProprietaryOpenGL拡張：NVIDIAのみ。当然、8500が登場したときには、それらのいずれも使用できませんでした。
少なくともD3D 8ランドでは、SM 1.0シェーダーをATIハードウェアで実行できます。確かに、8500のクールさを利用するには新しいシェーダーを作成する必要がありましたが、少なくともコードはworkedです。
OpenGLのRadeon 8500でany種類のシェーダーを使用するために、ATIはいくつかのOpenGL拡張機能を作成する必要がありました。ProprietaryOpenGL拡張：ATIのみ。したがって、NVIDIAコードパスとATIコードパスが必要でした。shadersを使用するためだけです。
ここで、「OpenGL ARBはどこにありましたか？多くの委員会がしばしば終わるところ：愚かであることから。
上記のARB_multitextureについては、これらすべてに深く関わっているので参照してください。 ARBは（部外者の観点から）シェーダーの考えを完全に避けたいように見えました。彼らは、固定機能パイプラインに十分な構成可能性を適用した場合、シェーダーパイプラインの機能と同等になると考えました。
したがって、ARBは拡張機能の後に拡張機能をリリースしました。 「texture_env」という単語が含まれているすべての拡張機能は、この古い設計にパッチを当てようとするもう1つの試みでした。レジストリを確認します。ARB拡張とEXT拡張の間に、これらの拡張のうちeightが作成されました。多くはOpenGLコアバージョンに昇格しました。
マイクロソフトは現時点ではARBの一部でした。彼らはD3D 9がヒットした頃に去った。したがって、彼らが何らかの方法でOpenGLを妨害している可能性は十分にあります。私は二つの理由でこの理論を個人的に疑っています。 1つ目は、各メンバーが1票しか得られないため、他のARBメンバーから支援を得なければならなかったということです。そして最も重要な2つは、ARBは、物事を台無しにするためにMicrosoftの助けを必要としなかったということです。そのことのさらなる証拠を見るでしょう。
最終的にARBは、おそらくATIとNVIDIA（両方のアクティブメンバー）からの脅威にさらされているため、最終的には実際のアセンブリスタイルのシェーダーを提供するのに十分な時間頭を引き出しました。
何かもっと愚かしたいですか？
ハードウェアT＆L。 OpenGLの何かにfirstがありました。まあ、それは面白いです。ハードウェアT＆Lから可能な最大のパフォーマンスを得るには、頂点データをGPUに保存する必要があります。結局のところ、頂点データを実際に使用したいのはGPUです。
D3D v7では、マイクロソフトは頂点バッファーの概念を導入しました。これらは、頂点データを格納するためにGPUメモリの割り当てられたスワスです。
OpenGLがこれに相当するものをいつ入手したか知りたいですか？ああ、NVIDIAは、OpenGL（プロプライエタリのNVIDIA拡張機能である限り）のすべての愛好家であり、GeForce 256が最初にヒットしたときに頂点配列範囲拡張機能をリリースしました。しかし、ARBが同様の機能を提供することを決定したのはいつですか？
2年後。これはafterでした。頂点シェーダーとフラグメントシェーダー（D3D言語のピクセル）を承認しました。これは、ARBが頂点データをGPUメモリに格納するためのクロスプラットフォームソリューションを開発するのにかかった時間です。繰り返しますが、最大のパフォーマンスを達成するには、ハードウェアにT＆Lneedsが必要です。
1つの言語ですべてを台無しにする
そのため、OpenGL開発環境は一時的に機能しなくなりました。クロスハードウェアシェーダーもクロスハードウェアGPU頂点ストレージもありませんが、D3Dユーザーは両方を楽しんでいました。悪化する可能性はありますか？
あなた...あなたはそれを言うことができました。 D Labsと入力します。
彼らは誰ですか、あなたは尋ねるかもしれませんか？彼らは私がOpenGLの真の殺し屋であると私が考える消滅した会社です。確かに、ARBの一般的な不備により、OpenGLはD3Dを所有しているはずのときに脆弱になりました。しかし、OpenGLの現在の市場の状態について、3D Labsがおそらく私の最大の最大の理由です。それを引き起こすために彼らは何をしたのでしょうか？
彼らはOpenGLシェーディング言語を設計しました。
3D Labsは瀕死の会社でした。彼らの高価なGPUは、ワークステーション市場に対するNVIDIAの圧力の高まりによって取り残されていました。 NVIDIAとは異なり、3D Labsは主流市場に存在していませんでした。 NVIDIAが勝った場合、彼らは死んだ。
彼らがした。
そのため、3D Labsは、自社製品を望まない世界での関連性を維持するために、「OpenGL 2.0」と呼ばれるもののプレゼンテーションを行うゲーム開発者会議に出席しました。これは、OpenGL APIのゼロからの完全な書き直しです。そしてそれは理にかなっています。当時、OpenGLのAPIにはlotの残骸がありました（注：その残骸はまだ存在しています）。テクスチャのロードとバインディングがどのように機能するかを見てください。それは半難解です。
彼らの提案の一部は網掛け言語でした。当然。ただし、現在のクロスプラットフォームのARB拡張とは異なり、それらのシェーディング言語は「高レベル」でした（Cはシェーディング言語の高レベルです。本当に、あります）。
現在、マイクロソフトは独自の高級シェーディング言語に取り組んでいました。マイクロソフトの総体的な想像力の中で、彼らはこれを... High Level Shading Language（HLSL）と呼んだ。しかし、それらは言語に対する根本的に異なるアプローチでした。
3D Labsのシェーダー言語の最大の問題は、組み込みであることです。 HLSLはマイクロソフトが定義した言語でした。彼らはそのためのコンパイラをリリースし、D3DにフィードするShader Model 2.0（またはそれ以降のシェーダーモデル）アセンブリコードを生成しました。 D3D v9の時代には、HLSLがD3Dに直接触れることはありませんでした。それは素晴らしい抽象化でしたが、それは純粋にオプションでした。また、開発者は常にコンパイラの背後に行き、出力を調整して最大のパフォーマンスを得る機会がありました。
3D Labs言語にはnoneがありました。ドライバーにCライクな言語を指定すると、シェーダーが生成されます。話の終わり。アセンブリシェーダーではなく、他に何かをフィードするものではありません。シェーダーを表す実際のOpenGLオブジェクト。
これが意味することは、OpenGLユーザーは、アセンブリのような言語のコンパイルのコツを得たばかりの開発者の気まぐれにオープンだったことです。コンパイラのバグは、新しく命名されたOpenGLシェーディング言語（GLSL）でrampantを実行しました。さらに悪いことに、複数のプラットフォームでシェーダーを正しくコンパイルすることができた場合（平均的な偉業ではない）、それでもその日のoptimizersの影響を受けていました。それらは可能な限り最適ではありませんでした。
それはGLSLの最大の欠陥でしたが、それだけが欠陥ではありませんでした。farによって。
D3DおよびOpenGLの以前のアセンブリ言語では、頂点シェーダーとフラグメント（ピクセル）シェーダーを混在させて一致させることができました。同じインターフェイスと通信している限り、任意の頂点シェーダーと互換性のある任意のフラグメントシェーダーを使用できます。そして、彼らが受け入れることができる非互換性のレベルさえありました。頂点シェーダーは、フラグメントシェーダーが読み取らない出力を書き込む可能性があります。などなど。
GLSLにはそれがありませんでした。頂点シェーダーとフラグメントシェーダーは、3D Labsが「プログラムオブジェクト」と呼ぶものに融合されました。したがって、頂点プログラムとフラグメントプログラムを共有する場合は、複数のプログラムオブジェクトを作成する必要がありました。そして、これは2番目に大きな問題を引き起こしました。
3D Labsは、彼らは賢いと思っていました。彼らはC/C++に基づいたGLSLのコンパイルモデルに基づいています。 .cまたは.cppを受け取り、それをオブジェクトファイルにコンパイルします。次に、1つ以上のオブジェクトファイルを取得して、プログラムにリンクします。これがGLSLのコンパイル方法です。シェーダー（頂点またはフラグメント）をシェーダーオブジェクトにコンパイルします。次に、これらのシェーダーオブジェクトをプログラムオブジェクトに入れ、それらをリンクして実際のプログラムを形成します。
これにより、メインシェーダーが呼び出すことができる追加のコードを含む「ライブラリ」シェーダーのような潜在的なクールなアイデアが可能になりましたが、実際には、シェーダーがtwiceでコンパイルされるということです。 1回はコンパイル段階で、もう1回はリンク段階です。特にNVIDIAのコンパイラは、基本的にコンパイルを2回実行することで知られていました。なんらかのオブジェクトコードの仲介を生成しませんでした。一度コンパイルして答えを捨て、リンク時に再度コンパイルしました。
したがって、頂点シェーダーを2つの異なるフラグメントシェーダーにリンクする場合でも、D3Dよりもはるかに多くのコンパイルを行う必要があります。特に、C言語に似た言語のコンパイルはすべて、プログラムの実行の最初ではなく、offlineで行われたためです。
GLSLには他にも問題がありました。 ARBが最終的に言語を承認および組み込んだため（ただし、「OpenGL 2.0」イニシアチブ以外は何もない）、3Dラボに責任を負わせるのはおそらく間違っているようです。しかし、それは彼らの考えでした。
そして、これは本当に悲しい部分です：3D Labsはright（ほとんど）でした。 GLSLは、当時のHLSLのようなベクトルベースのシェーディング言語ではありません。これは、3D Labsのハードウェアがスカラーハードウェア（最新のNVIDIAハードウェアと同様）であったためですが、最終的には多くのハードウェアメーカーがハードウェアを使用する方向に向いていました。
彼らは、「高水準」言語用のコンパイルオンラインモデルを使用するのは当然でした。 D3Dは最終的にはそれに切り替えました。
問題は、3Dラボが間違ったtimeで正しかったことでした。そして、未来を早めに呼びだそうとするとき、将来を保証するために、彼らはpresentを捨てます。これは、OpenGLが常にT＆L機能の可能性を持っていた方法に似ています。 OpenGLのT＆LパイプラインがハードウェアT＆Lの前にはまだusefulだったのを除いて、世界がそれに追いつく前のGLSLは責任でした。
GLSLは良い言語nowです。しかし、当分の間？恐ろしいことでした。そして、OpenGLはそれに苦しみました。
神格化に向かって落下
3D Labsが致命的な打撃を被ったと私は主張していますが、棺桶の最後の釘を打ち込んだのはARB自体でした。
これはあなたが聞いたことのある話です。 OpenGL 2.1の時点で、OpenGLは問題に直面していました。lotのレガシークルーフトがありました。 APIは使いやすくなりませんでした。物事を行うには5つの方法があり、どれが最速かはわかりませんでした。簡単なチュートリアルでOpenGLを「学習」することはできましたが、実際のパフォーマンスとグラフィックスパワーを提供するOpenGL APIを実際には学習しませんでした。
したがって、ARBはOpenGLの別の再発明を試みることを決定しました。これは3D Labsの「OpenGL 2.0」に似ていますが、ARBが背後にあるためより優れています。彼らはそれを「ロングピーク」と呼んだ。
APIの改善に時間をかけることの何がそれほど悪いのですか？マイクロソフトが脆弱なままにしていたので、これは悪かった。thisはVistaの切り替え時のものです。
Vistaでは、Microsoftはディスプレイドライバーに待望の変更を加えることを決定しました。彼らは、ドライバーにグラフィックスメモリの仮想化やその他のさまざまなことをOSに依頼するよう強制しました。
これのメリットやそれが実際に可能であったかどうかを議論することはできますが、事実はこれのままです：MicrosoftはD3D 10をVista（およびそれ以上）のみと見なしました。 D3D 10のcapableであるハードウェアがあったとしても、Vistaを実行せずにD3D 10アプリケーションを実行することはできません。
Vistaを覚えているかもしれません...ええと、それがうまくいかなかったとだけ言っておきましょう。つまり、パフォーマンスの低いOS、そのOSでのみ実行される新しいAPI、および前の世代よりも高速である以上に何かをするためにそのAPIとOSがneededする新しい世代のハードウェアがありました。
ただし、開発者couldはOpenGLを介してD3D 10クラスの機能にアクセスします。まあ、ARBがLongs Peakで忙しく働いていなかったなら、彼らはそうすることができました。
基本的に、ARBはAPIを改善するために1年半から2年分の作業に費やしました。 OpenGL 3.0が実際に登場する頃には、Vistaの採用が進んでおり、Win7はその背後にVistaを置き、ほとんどのゲーム開発者はD3D-10クラスの機能を気にしていませんでした。結局のところ、D3D 10ハードウェアはD3D 9アプリケーションを問題なく実行しました。また、PCからコンソールへの移植（またはPC開発者が出荷してコンソール開発に移行します。お好きなものを選択してください）の登場により、開発者はD3D 10クラスの機能を必要としませんでした。
現在、開発者が以前にWinXPマシンのOpenGLを介してこれらの機能にアクセスできていた場合、OpenGL開発は非常に必要とされていました。しかし、ARBはその機会を逃しました。そして、あなたは最悪の部分を知りたいですか？
APIをゼロから再構築しようとする貴重な2年間を費やしたにもかかわらず、それらはstill失敗し、現状に戻りました（非推奨メカニズムを除く）。
そのため、ARBはcrucialの機会枠を逃しただけでなく、そのチャンスを逃した原因となったタスクも完了しませんでした。ほとんどすべての叙事詩は失敗します。
そして、それはOpenGLとDirect3Dの物語です。チャンスを逃した、ひどい愚かさ、故意の失明、そして単純な愚かさの物語。
質問が「ゲーム編集者」ではなく「ゲーム開発者」である場合、誰もがユーザーベースに焦点を合わせているのは奇妙だと思いました。
私にとって、開発者としてのLinuxは流血の混乱です。非常に多くのバージョン、デスクトップマネージャー、UIキットなどがあります。自分の作業をオープンソースとして配布したくない場合は、ユーザーが（コンパイルしようと）再コンパイルして、パッケージ、ライブラリ、設定、それは悪夢です！
一方、Microsoftは（ほとんどの場合）信じられないほどの後方互換性とプラットフォームの安定性を提供しています。適切なDXまたはVC再配布可能ファイルがインストールされていない、Windows XP、Vistaおよび7、32ビットおよび64ビットフレーバーを実行しているコンピューターなど、1つのクローズドソースインストーラーでマシンの全範囲をターゲットにすることが可能です。等...
最後に1つ、OPENGLとDIRECTXの比較をインターネットで停止してください！ Direct3DとOpenGLを比較するか、これを行わないでください。 DirectXは、OpenGLが提供しない入力サポート、サウンドサポート、動画再生などを提供します。
これは、LinuxやMacよりも地球上に多くのWindowsユーザーがいるためです。真実は人々が最大の市場を持つもののために物を作るということです。
携帯電話でも同じです：AndroidおよびiPhoneには素晴らしいゲームがありますが、Windows MobileとSymbianにはありません...
Windowsの市場シェアは90％を超えており、Linux（Linuxについて具体的に質問したため）は、ソフトウェアにお金を払いたくない多くのユーザーがいることで定評があります。それが本当であるかどうか、または本当であるかどうかは関係ありません。知覚はそこにあり、それは人々の決定に影響を与えます。
Windowsは巨大な組織に支えられているため、10年以上前にそのことが決定されました 彼らはプラットフォーム上でゲーム開発を実現したいと考えています 。
これはMacには当てはまりませんでしたが、現在は当てはまりません。 iOSでもです。 AppleはiOSゲーム開発用のツールを提供していません。しかし、それは巨大な市場であり（1995年のPCの数よりもiPhoneの数が多い）、比較的競争が少ないため、人々はとにかくそれを行います。
Linuxに関しては、なんらかの優先順位を設定できるような中央機関さえありません。 Linuxの方向性は、非常に優れているが、やや世俗的でないプログラマーの集団によって決定されることはあまりありません。
今日のPCゲームを作成するには、多くの2D/3Dアーティスト、ゲームデザイナー、スクリプト作成者、俳優、テスターなどが必要です。実際のプログラミングに関しては、実際のゲームエンジン（CryEngine、Unreal Engine、Quake Engine、Source Engine）を使用するだけかもしれません。したがって、実際のプログラマーがいなくてもすべてを実行できる可能性があります。
そのため、そしてビジネスの性質上、プログラマーはどのプラットフォームを選択するかほとんど言いません。そして通常、マネージャーはサポートを探します。これはMicrosoftが提供すると主張しているものであり、オープンソースではない思考パターンに何らかの形で差し押さえられるものに対処するためのものです。
そのため、ほとんどの商用エンドユーザーソフトウェア開発はWindowsで行われます。
私はFlashゲームを作成する会社で働いているため、特定のプラットフォームに拘束されません。ただし、使用するほとんどのツールはLinuxでは利用できないため、すべてWindowsで開発しています。
すでに述べたように、最も重要な部分はユーザーベースです。 PCユーザーの95％がWindowsを使用しています。 PCゲーマーはほとんどWindowsのみを使用します。 MacやLinuxを使用する人でさえ、ほとんどの場合、Windowsゲームを仮想化またはエミュレーションで実行します（例外はほとんどありません）。
しかし、人口動態はすべてではありません。ゲーム開発者にとってプラットフォームをより魅力的にするためにマイクロソフトが行っている部分を過小評価しないでください。基本的に、完全な機能を備えた 無料のツールセット 、最も重要な XNA Game Studio 。これにより、Windowsだけでなく、Xbox360の開発も可能になります。そして、WP7電話のための最新版で。明らかにMicrosoftツールであるため、OpenGLではなくDirectXを使用しています。
Ewwww、私はしません。私はほとんどLinuxを使用しています。私はWindowsをデュアルブートしてWindowsビルドを作成し、MacビルドにMacを使用していますが、それだけです。
トリックは、長年にわたって開発してきたクロスプラットフォームのフレームワークです。私たちのゲームはその上に構築されており、Linux/OpenGL、Mac/OpenGL、Windows/Direct3D（そしてまもなくiOS/OpenGL）でも同様に動作します。
確かに私の会社はAAAタイトルを提供していないため、これらは適用されない可能性がありますが、私たちはトップカジュアルゲームを作成しています（ website -CSI：NYを参照）、Murder She Wroteと次の2つの2011は例です重要なライセンスを使用したタイトルのうち、シャーロックホームズのロストケース1と2も非常に成功しました）
それ以外の場合は、gedit + gcc + gdb + valgrindをあきらめません。
ツール、ツール、ツール。
それが結果です。 Windowsで開発すると、地球上で最高の開発ツールにアクセスできます。 Visual Studioのデバッガーにリモートで近いものはありません。DirectXデバッグランタイムは素晴らしいです。PIXは素晴らしいです。他のプラットフォームやAPIには同等の同等のものは存在しません。もちろん、良いものはいくつかあります。他のプラットフォームのツールが悪いと言っているわけではありませんが、MSが提供するツールはパックよりはるかに進んでいるため（名誉の例外：Valgrind）、それも面白くありません。
結論としては、これらのツールがあなたを助けるということです。これらは、物事を成し遂げるのに役立ち、生産性の向上に役立ち、ドキュメントどおりに動作しないAPIに取り組むのではなく、独自のコードのエラーに集中するのに役立ちます。
だから私はこれらすべての答えを検討しましたが、ウォルマートの棚にあったコンソールゲームのコードを持っているゲーム開発者として、私はまったく異なる答えを持っています。
分布。
任天堂のコンソールになりたい場合は、任天堂の許可を得て、任天堂の工場から購入し、任天堂の諸経費を支払い、ウォルマートと交渉し、倉庫保管に対処し、製造、箱の印刷、出荷にお金が必要です。 、すべての保険などを行うため。
XBoxを使いたい場合は、XBLAが必要ですが、それでもMicrosoftの祝福が必要です。順番を待つ必要があります。パッチをリリースするだけでも数万ドルかかります。
IOSでは、まだAppleの大丈夫が必要であり、彼らは気まぐれにあなたを引っ張ることができます（そしてそうします）。
Steamでは、Valveの許可または承認が必要です。
。
Windowsでは？ Webサイトとダウンロードボタンを設定します。
。
他のプラットフォームが価値がないと言っているのではありません。しかし、ゲームを開発しようとしているときにso *非常に*恐ろしいことが起こっています。それは、サイトでバイナリを平手打ちして作業に集中できるという約束です。 -少なくとも始めに-多くの潜在的な障害の障壁を本当に低くします。
「物事が安定しているときは、後でXBLA移植を行うことができます」という考え方。
また、ある程度はLinuxでも問題ないことを確認してください。7人の顧客が良ければ、そこから始めることができます。
しかし、Windowsには3つの大きな利点があります。それは、真にオープンな開発、真にオープンな展開、そして風変わりなものに興味を持つ非常に大規模で非常にアクティブな顧客ベースです。
他にどこから始めたらいいのか想像するのは難しい。
答えは明白です。ゲームを書く目的はお金を稼ぐことです。より多くのエンドユーザーがWindowsを実行するため、より大きな市場があり、LinuxゲームよりもWindowsゲームからより多くのお金を稼ぐことが期待されます。とても簡単です。
「なぜ誰かがやるのか...」と自分に問いかけたとしても、お金が世界を動かすことに注意してください。
- 慣性。過去にWindowsを使用したことがある場合、別のものに切り替えるのは面倒です。 Windowsを使用している場合、DirectXの方がOpenGLよりも簡単で、うまく機能する可能性が高くなります。
- 市場占有率。デスクトップ上のWindowsの市場シェアは、Linuxよりも大きいOS Xの市場シェアよりも大きくなっています。お金の話。
- ブランド。 DirectXは、SDL（OpenGLを超えるDirectXの機能の一部を複製するために必要なもの）のようなものよりもよく知られています。
- 混乱が少ない。ユーザーのLinuxはOpenGL 1.4またはOpenGL 2+までしかサポートしませんか？ Intro in modern OpenGL。Chapter 1：Graphics Pipeline のようなOpenGL 2.0チュートリアルをLinuxで使用できますか？
最近のLinuxはゲーム開発に関しては骨の折れるものであり、ほとんどの開発者はLinuxバージョンより前にOS Xポートバージョンを財政的に行うほうがよいでしょう（Steamなどを参照）。それでも、コンソール市場は、これらの2つのプラットフォームをゲーム用に組み合わせるよりも価値があります...
モノプラットフォームにしたい場合は、DirectXで問題ありません。クロスプラットフォームになりたい場合は、他のプラットフォームの少なくとも一部でOpenGLを使用する必要がある可能性が高いです。
多くのことが政治と統制に関係しています。 90年代後半、SGIとMSは実際に取り組みを組み合わせることに同意しました。
http://en.wikipedia.org/wiki/Fahrenheit_graphics_API
SGIはプロジェクトに多額の投資をしましたが、MSはしませんでした。 SGIは、MSが必要とするSGIよりも多くのMSを必要としました。残りは歴史です。
D3DとOpenGLは2つの非常に異なるAPIであり、ニーズに合ったものを選択するのは開発者の責任です。
Linuxがデスクトップシステムとしてひどく失敗したからです。誰かが以前のLinuxが開発者にとって混乱であると指摘したように（異なるライブラリ、UIツールキットなど）
もう1つの問題は、フリーターディズムとプロプライエタリソフトウェアのサポートの欠如です。 Nvidiaは常にLinux用の優れた（独自仕様の）ドライバーを提供していますが、Ubuntuや他のディストリビューションはそれを出荷していません。 Linuxで利用できるWindows用のバイナリドライバーインターフェイスもありません。 （カーネルソースには、binaryApiNonsense.txtなどのテキストファイルがあります）Linuxでは、Nvidiaハードウェアのみが適切にサポートされていると述べました。 LinuxでNvidiaハードウェアを使用して、ほとんどのIDソフトウェアゲームをプレイできます。
次のもの開発ツール。 MSFTは優れたC++サポートを提供し、Visual StudioデバッガーはC++に関してgdbより優れています。最後に重要なことですが、Photoshopなどの他のツールがありません。また、.netでは、GUIツールをすばやく作成できます。多くのゲームスタジオは、.netフレームワークを使用して内部で使用するためにツールをコーディングしています。
私はほとんど忘れていました：グラフィックシステムは恐ろしく、X11を移植したばかりの時代に戻ってきました。彼らは、OSxとWinが持っている最新のグラフィックシステムを適切に設計して実装することに失敗しました。