it-swarm-eu.dev

Proč vývojáři her dávají přednost Windows?

Je to, že DirectX je jednodušší nebo lepší než OpenGL, i když OpenGL je multiplatformní? Proč nevidíme skutečné výkonné hry pro Linux, jaké existují pro Windows?

396
M.Sameer

Mnoho odpovědí je opravdu, opravdu dobré. Ale problém OpenGL a Direct3D (D3D) by měl být pravděpodobně vyřešen. A to vyžaduje ... lekci historie.

A než začneme, vím mnohem více o OpenGL než o Direct3D . Ve svém životě jsem nikdy nenapsal řadu kódu D3D a na OpenGL jsem napsal návody. Takže to, co chci říct, není otázka zaujatosti. Je to prostě otázka historie.

Zrození konfliktu

Jednoho dne, někdy na začátku 90. let, se Microsoft rozhlédl. Viděli, že SNES a Sega Genesis jsou úžasné, spouští spoustu akčních her apod. A viděli DOS . Vývojáři kódovali hry pro DOS, jako jsou konzolové hry: přímo na kov. Na rozdíl od konzolí, kde však vývojář, který vytvořil hru SNES, věděl, jaký hardware by měl uživatel, museli vývojáři systému DOS psát pro více možných konfigurací. A to je mnohem těžší, než to zní.

A Microsoft měl větší problém: Windows. Podívejte se, Windows chtěli vlastnit hardware, na rozdíl od DOSu, který vývojářům téměř umožnil dělat cokoli. Vlastnictví hardwaru je nezbytné pro spolupráci mezi aplikacemi. Spolupráce je přesně to, co herní vývojáři nenávidí , protože vyžaduje úžasné hardwarové prostředky, které by mohli používat.

Aby bylo možné podpořit vývoj her na Windows, Microsoft potřeboval jednotné API, které bylo nízké úrovně, běžel na Windows, aniž by byl zpomalen, a hlavně křížový hardware . Jedno API pro veškerý grafický, zvukový a vstupní hardware.

Narodilo se tedy DirectX .

3D akcelerátory se narodily o několik měsíců později. A Microsoft narazil na místo problémů. Viz DirectDraw, grafická součást DirectX, se zabývala pouze 2D grafikou: přidělování grafické paměti a provádění bitových bitů mezi různými alokovanými částmi paměti.

Microsoft tedy koupil trochu middlewaru a vytvořil jej v Direct3D verze 3. Bylo to všeobecně zjeveno. A z dobrého důvodu; dívat se na kód D3D v3 je jako dívat se do archy smlouvy.

Old John Carmack ve společnosti Id Software se jednou podíval na odpadky a řekl: „To je! a rozhodli se napsat do jiného API: OpenGL.

Podívejte se, další část šelmy, která je Microsoftem, byla práce s SGI na implementaci OpenGL pro Windows. Myšlenka zde byla soudit vývojáře typických GL aplikací: aplikace pracovních stanic. CAD nástroje, modelování, takové věci). Hry byly nejvzdálenější věcí na jejich Toto byla především věc Windows NT, ale Microsoft se rozhodl přidat ji také do Win95.

Jako způsob, jak přilákat vývojáře pracovních stanic do systému Windows, se Microsoft rozhodl zkusit je podplatit přístupem k těmto nově vytvořeným 3D grafickým kartám. Společnost Microsoft implementovala protokol Installable Client Driver: Instalátor grafických karet by mohl přepsat implementaci softwaru OpenGL společnosti Microsoft hardwarově. Kód by mohl automaticky použít pouze hardwarovou implementaci OpenGL, pokud by byla k dispozici.

V prvních dnech však grafické karty na spotřebitelské úrovni nepodporovaly OpenGL. To nezabránilo Carmackovi, aby na své pracovní stanici SGI přenesl Quake do OpenGL (GLQuake). Jak můžeme číst z readme GLQuake:

Teoreticky bude glquake běžet na jakémkoli kompatibilním OpenGL, který podporuje rozšíření objektů textury, ale pokud to není moc silný hardware, který urychluje vše potřebné, nebude hra přijatelná. Pokud musí projít jakoukoli cestou emulace softwaru, bude výkon pravděpodobně pravděpodobně pod jedním snímkem za sekundu.

V současné době (březen 97) je jediným standardním openglovým hardwarem, který dokáže rozumně hrát blikání, intergrafový realizátor, což je VELMI drahá karta. 3dlabs významně zlepšují svůj výkon, ale s dostupnými ovladači to ještě nestačí hrát. Některé ze současných ovladačů 3dlabs pro desky glint a permedia mohou také selhat NT při ukončení z běhu na celé obrazovce, takže nedoporučuji běžet na hardwaru 3dlabs.

3dfx poskytla opengl32.dll, který implementuje vše, co glquake potřebuje, ale nejedná se o úplnou implementaci opengl. Je velmi nepravděpodobné, že by s ním další aplikace s openglem spolupracovaly, považujte jej tedy v zásadě za „řidiče záblesku“.

To bylo zrození řidičů miniGL. Tyto se nakonec vyvinuly do plných implementací OpenGL, protože hardware se stal dostatečně výkonným pro implementaci většiny funkcí OpenGL do hardwaru. nVidia byla první, která nabídla plnou implementaci OpenGL. Mnoho dalších dodavatelů bojovalo, což je jeden z důvodů, proč vývojáři upřednostňovali Direct3D: byli kompatibilní na širší škále hardwaru. Nakonec zůstaly pouze nVidia a ATI (nyní AMD) a obě měly dobrou implementaci OpenGL.

OpenGL Ascendant

Tím je nastavena fáze: Direct3D vs. OpenGL. Je to opravdu úžasný příběh, vzhledem k tomu, jak špatný byl D3D v3.

OpenGL Architectural Review Board (ARB) je organizace odpovědná za údržbu OpenGL. Vydávají řadu rozšíření, spravují úložiště rozšíření a vytvářejí nové verze API. ARB je výbor složený z mnoha hráčů grafického průmyslu a také z některých tvůrců OS. Apple a Microsoft byli v různých časech členy ARB.

3Dfx přichází s Voodoo2. Toto je první hardware, který umí multitexturing, což je něco, co OpenGL nemohl udělat dříve. Zatímco 3Dfx byl silně proti OpenGL, NVIDIA, výrobci dalšího grafického čipu s více texturami (TNT1), ho milovali. ARB tedy vydal rozšíření: GL_ARB_multitexture, které by umožnilo přístup k multitexturování.

Mezitím vyjde Direct3D v5. Nyní se D3D stala skutečným [~ # ~] api [~ # ~] , spíše než něčím, co by kočka mohla zvracet. Problém? Žádné multitexturing.

Jejda.

Teď by ten člověk neublížil tak moc, jak by měl, protože lidé mnohostránkování nepoužívali. Ne přímo. Výkon multitexturingu bolel výkon trochu, a v mnoha případech to nestálo za to ve srovnání s vícenásobným absolvováním. A samozřejmě vývojáři her rádi zajišťují, aby jejich hry fungovaly na starším hardwaru, který neměl multitexturing, takže mnoho her bylo dodáno bez něj.

D3D tak dostal odklad.

Čas plyne a NVIDIA nasazuje GeForce 256 (ne GeForce GT-250; úplně první GeForce), což je do značné míry končící konkurence v grafických kartách pro další dva roky. Hlavním prodejním bodem je schopnost provádět transformaci a osvětlení vrcholů (T&L) v hardwaru. Nejen to, NVIDIA milovala OpenGL natolik, že jejich T&L engine efektivně byl OpenGL. Téměř doslova; jak jsem pochopil, některé z jejich registrů ve skutečnosti berly OpenGL enumerátory přímo jako hodnoty.

Direct3D v6 vyjde. Konečně více textů, ale ... žádný hardware T&L. OpenGL měl vždy potrubí T&L, i když před 256 byl implementován do softwaru. Pro NVIDIA bylo tedy velmi snadné převést implementaci softwaru na hardwarové řešení. To by nebylo až do D3D v7, dokud by D3D konečně neměla hardwarovou podporu T&L.

Dawn of Shaders, Twilight of OpenGL

Potom vyšel GeForce 3. A spousta věcí se stala současně.

Microsoft se rozhodl, že už nebudou pozdě. Takže místo toho, aby se podívali na to, co NVIDIA dělala, a poté ji zkopírovali, zaujali úžasnou pozici, když jeli s nimi a hovořili s nimi. A pak se zamilovali a společně měli malou konzoli.

Nesprávný rozvod následoval později. Ale to je jindy.

To pro PC znamenalo, že GeForce 3 vyšel současně s D3D v8. A není těžké pochopit, jak GeForce 3 ovlivnil shadery D3D 8. Shadery pixelů modelu Shader Model 1.0 byly extrémně specifické pro hardware NVIDIA. Nebyl proveden žádný pokus o abstraktaci hardwaru NVIDIA; SM 1.0 bylo přesně to, co udělal GeForce 3.

Když ATI začala skočit do závodů s grafickými kartami s Radeon 8500, nastal problém. Potrubí pro zpracování pixelů 8500 bylo výkonnější než věci NVIDIA. Microsoft tedy vydal Shader Model 1.1, což bylo v podstatě „Ať už dělá 8500“.

To může znít jako porucha ze strany D3D. Neúspěch a úspěch jsou však záležitostí stupňů. A epické selhání se stalo v OpenGL-land.

NVIDIA miloval OpenGL, takže když GeForce 3 zasáhlo, vydali zabitý OpenGL rozšíření. Proprietární OpenGL rozšíření: Pouze NVIDIA. Když se objevil model 8500, přirozeně to nemohl použít.

Podívejte se, přinejmenším v zemi D3D 8, byste mohli spustit shadery SM 1.0 na hardwaru ATI. Jistě, museli jste napsat nové shadery, abyste využili chladu 8500, ale alespoň váš kód fungoval .

Aby byly na Radeonu 8500 v OpenGL shadery jakéhokoli druhu, musela ATI napsat několik rozšíření OpenGL. Proprietární OpenGL rozšíření: Pouze ATI. Takže jste potřebovali kodepath NVIDIA a ATI codepath, abyste měli shadery vůbec.

Nyní se můžete zeptat: „Kde byla OpenGL ARB, jejímž úkolem bylo udržovat OpenGL aktuální?“ Tam, kde často končí mnoho výborů: je to hloupé.

Viz, výše jsem zmínil ARB_multitexture, protože to vše hluboce ovlivňuje. Zdálo se, že ARB (z pohledu outsidera) se chce úplně vyhnout myšlence shaderů. Usoudili, že pokud by na potrubí s pevnou funkcí narazili dostatečně konfigurovatelně, mohli by se vyrovnat schopnosti potrubí shaderu.

ARB tedy vydal rozšíření po rozšíření. Každé rozšíření se slovy „texture_env“ v něm bylo dalším pokusem o opravu tohoto stárnutí. Zkontrolujte registr: mezi ARB a EXT rozšířeními bylo vytvořeno osm těchto rozšíření. Mnoho z nich bylo povýšeno na základní verze OpenGL.

Microsoft byl v této době součástí ARB; oni odešli kolem času D3D 9 udeřil. Je tedy zcela možné, že nějakým způsobem pracovali pro Sabotage OpenGL. Osobně pochybuji o této teorii ze dvou důvodů. Za prvé, museli by za tímto účelem získat pomoc od ostatních členů ARB, protože každý člen dostane pouze jeden hlas. A co je nejdůležitější, ARB nepotřeboval Microsoft k pomoci věci. Uvidíme o tom další důkazy.

Nakonec ARB, pravděpodobně pod hrozbou od ATI a NVIDIA (oba aktivní členové) nakonec vytáhli hlavu ven dost dlouho na to, aby poskytli skutečné shadery ve stylu Assembly.

Chceš něco ještě hloupějšího?

Hardware T&L. Něco OpenGL mělo první . Je to zajímavé. Chcete-li získat maximální možný výkon z hardwarové T&L, musíte ukládat svá data na GPU. Koneckonců je to GPU, které skutečně chce používat svá data.

V D3D v7 společnost Microsoft představila koncept Vertex Buffers. Jsou jim přiděleny řádky paměti GPU pro ukládání dat vrcholů.

Chcete vědět, kdy OpenGL získalo ekvivalent? Ach, NVIDIA, která je milovníkem všech věcí OpenGL (pokud jsou vlastnictvím rozšíření NVIDIA), vydala rozšíření rozsahu vrcholů, když GeForce 256 poprvé zasáhla. Ale kdy se ARB rozhodl poskytnout podobnou funkčnost?

O dva roky později . To bylo poté, co schválili shluky vrcholů a fragmentů (pixel v jazyce D3D). Tak dlouho trvalo ARB vyvinout řešení napříč platformami pro ukládání vertexových dat do paměti GPU. Opět něco, co hardware T&L potřebuje k dosažení maximálního výkonu.

Jeden jazyk je zničit všechny

Vývojové prostředí OpenGL bylo tedy na nějaký čas zlomeno. Žádné cross-hardwarové shadery, žádné cross-hardware GPU vertexové úložiště, zatímco D3D uživatelé si užili oba. Mohlo by to být horší?

Ty ... to bys mohl říct. Zadejte D laboratoře.

Kdo jsou, můžete se zeptat? Jsou to zaniklá společnost, kterou považuji za opravdové zabijáky OpenGL. Obecná nečinnost ARB zajistila, že OpenGL byl zranitelný, když měl vlastnit D3D. Ale 3D Labs jsou snad jediným největším důvodem pro můj současný stav trhu OpenGL. Co mohli udělat, aby to způsobili?

Navrhli stínovací jazyk OpenGL.

Podívejte, 3D laboratoře byly umírající společností. Jejich drahé GPU byly marginalizovány rostoucím tlakem NVIDIA na trh pracovních stanic. A na rozdíl od NVIDIA se 3D laboratoře nezúčastnily běžného trhu; pokud vyhrál NVIDIA, zemřeli.

Což udělali.

Takže ve snaze zůstat relevantní ve světě, který nechtěl jejich produkty, se 3D laboratoře ukázaly na konferenci Game Developer Conference, která měla prezentace za něco, čemu říkali „OpenGL 2.0“. To by bylo úplné přepsání rozhraní OpenGL API od začátku. A to dává smysl; v té době bylo v rozhraní OpenGL API šarže (poznámka: tento kříž stále existuje). Stačí se podívat na to, jak funguje načítání textury a vazba; je to polořadovka.

Součástí jejich návrhu byl stínovací jazyk. Přirozeně. Na rozdíl od současných rozšíření platformy ARB napříč platformami však byl jejich stínovací jazyk „na vysoké úrovni“ (C je na vysoké úrovni pro stínovací jazyk. Ano, opravdu).

Nyní Microsoft pracoval na svém vlastním stínovacím jazyce na vysoké úrovni. Což v celé kolektivní představivosti Microsoftu nazvali ... Vysoký stínovací jazyk (HLSL). Jejich přístup byl však zásadně odlišný.

Největším problémem shaderu jazyka 3D Labs bylo to, že byl vestavěn. Viz, HLSL byl jazyk definovaný společností Microsoft. Vydali pro něj kompilátor a vygenerovali Shader Model 2.0 (nebo novější shader modely) Assembly code, který byste vložili do D3D. Za D3D v9 dní se HLSL nikdy nedotkla přímo D3D. Byla to pěkná abstrakce, ale byla čistě volitelná. A vývojář měl vždy příležitost jít za kompilátor a vyladit výstup pro maximální výkon.

Jazyk 3D Labs toho neměl žádný . Dali jste řidiči jazyk podobný C a vytvořil shader. Konec příběhu. Nejsou shadery Shromáždění, ne něco, co krmíte něčím jiným. Skutečný objekt OpenGL představující shader.

Co to znamenalo, že uživatelé OpenGL byli otevřeni mlhavým vývojářům, kteří se právě dostali na kompilaci sestavovacích jazyků. Chyby kompilátoru běhaly nekontrolovaně v nově pokřtěném OpenGL Shading Language (GLSL). A co je horší, pokud se vám podařilo získat shaderu, aby správně kompiloval na více platformách (bez průměrného výkonu), stále jste byli podrobeni optimalizátorům dne. Které nebyly tak optimální, jak by mohly být.

I když to byla největší chyba v GLSL, nebyla to jediná vada. Podle daleko .

V D3D a ve starších sestavovacích jazycích v OpenGL byste mohli míchat a porovnávat shadery vrcholů a fragmentů (pixelů). Dokud budou komunikovat se stejným rozhraním, můžete použít jakýkoli shader vrcholů s jakýmkoli kompatibilním shaderem fragmentů. A existovaly dokonce i úrovně nekompatibility, které mohly přijmout; vrchol shader mohl napsat výstup, který fragment shader nečetl. A tak dále.

GLSL nic z toho neměla. Vertex a shadery fragmentů byly spojeny dohromady do toho, co 3D laboratoře nazvaly „programový objekt“. Takže pokud jste chtěli sdílet vertexové a fragmentační programy, musíte vytvořit více programových objektů. A to způsobilo druhý největší problém.

Vidíte, 3D laboratoře si myslely, že jsou chytří. Na kompilačním modelu GLSL založili C/C++. Vezmete .c nebo .ppp a zkompilujete je do objektového souboru. Pak vezmete jeden nebo více objektových souborů a propojíte je do programu. GLSL tedy kompiluje: svůj shader (vrchol nebo fragment) zkompilujete do objektu shaderu. Poté tyto objekty shaderu vložíte do programového objektu a propojíte je dohromady, aby vytvořili svůj skutečný program.

I když to umožňovalo potenciální skvělé nápady, jako například mít „knihovní“ shadery, které obsahovaly zvláštní kód, který by hlavní shadery mohly volat, v praxi to znamenalo, že shadery byly kompilovány dvakrát . Jednou ve fázi kompilace a jednou ve fázi propojení. Zejména kompilátor NVIDIA byl známý tím, že kompilaci v podstatě dvakrát spustil. To nevytvořilo nějaký druh zprostředkovatele objektového kódu; to jen jednou zkompilovalo a odhodilo odpověď, pak ji znovu sestavilo v době spojení.

Takže i když chcete propojit svůj vrcholový shader se dvěma různými fragmentovými shadery, musíte udělat mnohem více kompilace než v D3D. Zejména od kompilace jazyka typu C bylo vše hotové offline , nikoli na začátku provádění programu.

Byly další problémy s GLSL. Možná se zdá špatné položit vinu na 3D laboratoře, protože ARB nakonec jazyk schválil a začlenil (ale nic jiného z jejich iniciativy „OpenGL 2.0“). Ale to byl jejich nápad.

A tady je opravdu smutná část: 3D laboratoře měly pravdu (většinou). GLSL není vektorový stínovací jazyk, jakým byl HLSL v té době. Důvodem bylo to, že hardware 3D Labs byl skalární hardware (podobný modernímu hardwaru NVIDIA), ale nakonec měli pravdu ve směru, kterým mnoho výrobců hardwaru šlo s jejich hardwarem.

Měli pravdu, když šli s online kompilačním modelem pro jazyk „na vysoké úrovni“. D3D na to nakonec přešel.

Problém byl v tom, že 3D laboratoře měly pravdu v nesprávný čas . A ve snaze svolat budoucnost příliš brzy, ve snaze o budoucnost, odhazují přítomný přítomný . Zní to podobně, jako OpenGL vždy měla možnost pro T&L funkčnost. S výjimkou toho, že potrubí T&L OpenGL bylo ještě užitečné před hardwarovou T&L, zatímco GLSL byla odpovědnost před tím, než ho svět dohnal.

GLSL je nyní dobrý jazyk . Ale prozatím? Bylo to strašné. A OpenGL za to trpěla.

Padající na apoteózu

I když tvrdím, že 3D laboratoře zasáhly fatální ránu, byl to právě ARB, kdo vyhnal poslední hřebík v rakvi.

Toto je příběh, o kterém jste možná slyšeli. V době OpenGL 2.1 se OpenGL dostalo do problému. Měl šarži staršího cruftu. Použití API nebylo snadné. Bylo 5 způsobů, jak dělat věci, a žádný nápad, který byl nejrychlejší. Mohli byste se „naučit“ OpenGL pomocí jednoduchých výukových programů, ale opravdu jste se nenaučili rozhraní OpenGL API, které vám poskytlo skutečný výkon a grafickou sílu.

ARB se tedy rozhodl zkusit další nový vynález OpenGL. Bylo to podobné 3DG OpenGL 2.0, ale lepší, protože za tím byl ARB. Říkali tomu „Longs Peak“.

Co je tak špatného na tom, že si nějakou dobu vylepšíte API? To bylo špatné, protože Microsoft se nechal zranitelný. Podívejte se, to bylo v době přechodu na systém Vista.

V systému Vista se Microsoft rozhodl zavést některé tolik potřebné změny v ovladačích zobrazení. Přinutili řidiče, aby se podrobili OS pro virtualizaci grafické paměti a různé další věci.

I když je možné diskutovat o výhodách tohoto nebo o tom, zda to bylo skutečně možné, faktem zůstává toto: Microsoft považoval D3D 10 za Vista (a výše). I kdybyste měli hardware, který byl schopný D3D 10, nemohli byste spustit aplikace D3D 10 bez spuštění systému Vista.

Možná si také pamatujete, že Vista ... um, řekněme jen, že to nefungovalo dobře. Takže jste měli špatně fungující operační systém, nové API, které fungovalo pouze v tomto operačním systému, a novou generaci hardwaru, který potřeboval , aby API a OS udělaly něco víc než rychlejší než předchozí generace .

Vývojáři však mohli přistupovat k funkcím třídy D3D 10 prostřednictvím OpenGL. Mohli by, kdyby ARB nebyl zaneprázdněn prací na Longs Peak.

ARB v podstatě strávil dobrý rok a půl až dva roky prací na vylepšování API. V době, kdy OpenGL 3.0 skutečně vyšel, adopce Vista byla nahoře, Win7 byl za rohem, aby Vista za nimi, a většina vývojářů her nezajímalo D3D-10 třídy funkce stejně. Koneckonců, hardware D3D 10 provozoval aplikace D3D 9 v pořádku. A s nárůstem portů mezi počítači a konzolami (nebo vývojáři počítačů na lyžích z lodi na vývoj konzolí. Vyberte si), vývojáři nepotřebovali funkce třídy D3D 10.

Nyní, pokud vývojáři měli přístup k těmto funkcím dříve přes OpenGL na počítačích WinXP, pak vývoj OpenGL mohl dostat tolik potřebnou ránu do paže. Ale ARB neměli příležitost. A chcete vědět to nejhorší?

Navzdory tomu, že se dva drahocenné roky pokusily znovu vybudovat API od nuly ... stále selhaly a právě se vrátily zpět do stavu quo (kromě mechanismu pro odpisy).

ARB tak nejenže postrádal klíčové okno příležitosti, ale ani neudělal úkol, díky kterému by jim tato šance chyběla. Docela epické selhání všude kolem.

A to je příběh OpenGL vs. Direct3D. Příběh promarněných příležitostí, hrubá hloupost, úmyslná slepota a jednoduchá pošetilost.

1154
Nicol Bolas

Připadalo mi divné, že se všichni soustředili na uživatelskou základnu, když je otázkou „vývojáři her“, nikoli „editoři her“.

Jako vývojář je pro mě Linux krvavý nepořádek. Existuje tolik verzí, správců desktopů, sad uživatelského rozhraní atd. Pokud nechci distribuovat svou práci jako open source, kde uživatel může (pokusit se) překompilovat, aby vyhovoval jeho jedinečné kombinaci balíčků, knihoven a nastavení, je to noční můra!

Na druhou stranu Microsoft poskytuje (většinou) neuvěřitelnou zpětnou kompatibilitu a stabilitu platformy. Je možné zacílit na celou řadu počítačů pomocí jednoho instalátoru s uzavřeným zdrojem, například na počítače se systémem Windows XP, Vista a 7, 32 a 64 bitů, bez správného DX nebo VC nainstalované redistribuovatelné soubory, atd...

Ještě poslední věc PROSÍM VŠECHNO NA INTERNETU STOP POROVNÁNÍ OPENGL A DIRECTX! Buď porovnejte Direct3D vs OpenGL, nebo to nedělejte . DirectX poskytuje podporu vstupu, podporu zvuku, přehrávání filmu atd., Které OpenGL ne.

133
jv42

Je to proto, že na planetě je více uživatelů Windows než Linux a Mac. Pravda je, že lidé dělají věci pro toho, kdo má největší trh.
Totéž platí pro mobilní telefony: Android a iPhone mají úžasné hry, ale Windows Mobile a Symbian ...

88
Arjun Bajaj

Protože Windows má více než 90% podíl na trhu a Linux (protože jste se konkrétně ptali na Linux) má pověst mnoha uživatelů, kteří nechtějí platit za software. Zda nebo ne, je to pravda nebo jak pravdivé to není relevantní; vnímání je tam a ovlivňuje rozhodnutí lidí.

50
Mason Wheeler

Protože Windows je podporována obrovskou organizací, o které se před více než deseti lety rozhodlo chtějí, aby se na jejich platformě objevil vývoj her .

Pro Mac to neplatilo a nyní to není pravda. Ani pro iOS. Apple neposkytuje nástroje pro vývoj her pro iOS. Ale je to obrovský trh (existuje tam více iPhonů než v roce 1995 u PC) s relativně malou konkurencí, takže to lidé stejně dělají.

Pokud jde o Linux, neexistuje ani nějaká centrální instituce, která by mohla stanovit jakýkoli druh priorit. Směr, kterým se Linux ubírá, je mnohem méně určován partií velmi dobrých, ale mírně neobvyklých programátorů.

K vytvoření počítačové hry dnes potřebujete hodně umělců 2d/3d, návrhářů her, skriptů, herců, testerů a co ne. Pokud jde o skutečné programování, můžete jednoduše použít skutečný herní engine (CryEngine, Unreal Engine, Quake Engine, Source Engine). Takže byste mohli být schopni dělat celou věc bez skutečných programátorů.

Z tohoto důvodu a vzhledem k povaze podniků nemají programátoři jen malou šanci, na které platformě je vybrána. Manažeři obvykle hledají podporu, což je něco, co společnost Microsoft tvrdí, že nabízí, a vypořádat se s věcmi, které jsou nějakým způsobem využitelné pro jejich myšlenkové poklepání, což open source není.

Z tohoto důvodu se většina komerčního softwaru pro koncového uživatele vyvíjí na Windows.
Pracuji pro společnost, která vytváří flash hry, a proto není vázána na konkrétní platformu. Všichni se však vyvíjíme na Windows, protože většina nástrojů, které používáme, není pro Linux k dispozici.

11
back2dos

Jak již někteří uvedli, nejdůležitější částí je uživatelská základna. 95% uživatelů PC používá Windows. PC hráči používají téměř výhradně Windows. Dokonce i ti, kteří Mac nebo Linux používají nejčastěji, provozují hry Windows prostřednictvím nějaké virtualizace nebo emulace (až na velmi malé výjimky).

Demografická situace však není všechno. Nepodceňoval bych část, kterou Microsoft dělá, aby byla platforma pro vývojáře atraktivnější. V zásadě dostanete plně vybavený sadu nástrojů zdarma , a hlavně ) XNA Game Studio . To umožňuje nejen vývoj pro Windows, ale také pro Xbox360 . A s nejnovější verzí i pro telefony WP7. Je zřejmé, že je to nástroj společnosti Microsoft a používá DirectX, nikoli OpenGL.

10
vartec

Ewwww, nemám. Linux používám téměř výhradně. I duální boot do Windows, aby Windows sestavení, a používat Mac pro Mac sestavení, ale to je vše.

Trik je multiplatformní rámec, který jsme vyvinuli v průběhu let. Naše hry jsou postaveny na vrcholu toho, a chovat se identicky v Linuxu/OpenGL, Mac/OpenGL a Windows/Direct3D (a brzy v iOS/OpenGL).

Je pravda, že moje společnost nedělá tituly AAA, takže se na ně nemusí vztahovat, ale děláme špičkové hry pro volný čas (viz web - CSI: NY, Murder She Wrote a dva nadcházející roky 2011 jsou příklady titulů používajících důležité licence, Ztracené případy Sherlocka Holmese 1 a 2 byly také docela úspěšné)

Já bych se nevzdal gedit + gcc + gdb + valgrind za nic jiného.

6
ggambett

Nástroje, nástroje, nástroje.

To je to, na co jde. Vyvíjejte na Windows a získáte přístup k některým z nejlepších vývojových nástrojů na této planetě. Nic není vzdáleně blízko debuggeru Visual Studio, DirectX Debug Runtimes jsou úžasné, PIX je úžasné a srovnatelné ekvivalenty prostě neexistují na jiných platformách/API. Jistě, tam jsou nějaké dobré věci; Neříkám, že nástroje na jiných platformách jsou špatné, ale ty, které poskytuje MS, jsou tak daleko před balením (čestná výjimka: Valgrind), že to není ani vtipné.

Pointa je, že vám tyto nástroje pomohou. Pomáhají vám dělat věci, pomáhají vám být produktivní, pomáhají vám soustředit se na chyby ve vašem vlastním kódu, spíše než zápasit s API, které se nikdy nechová tak, jak je dokumentováno.

4
Maximus Minimus

Takže jsem prošel všechny tyto odpovědi a jako vývojář her, který má kód pro konzolové hry, které byly na policích Walmart, mám velmi odlišnou odpověď.

Rozdělení.

Podívejte se, pokud chcete být na konzole Nintendo, musíte získat povolení Nintendo, koupit od továren Nintendo, zaplatit režijní náklady Nintendo, jednat s Walmartem, zabývat se skladováním, potřebovat peníze dopředu na výrobu, na tisk krabic, na dopravu , dělat všechno pojištění, et cetera.

Pokud chcete na XBox, určitě existuje XBLA, ale stále potřebujete požehnání od Microsoftu, musíte počkat, až bude řada v řadě, je to desítky tisíc dolarů, jen aby se uvolnila náplast atd.

V systému iOS stále potřebujete Apple v pořádku a oni vás mohou (a mohou) opatrně vytáhnout.

Ve službě Steam stále potřebujete Valveovo povolení nebo zelené světlo a spoustu peněz.

.

Na Windows? Nastavili jste web a tlačítko pro stažení.

.

Neříkám, že ostatní platformy nejsou cenné. Ale existuje tak * mnoho * strašných věcí, které se dějí, když se snažíte vyvinout hru, to pro mě, slib, že bude schopen jen plácnout binární na web a zaměřit se na práci - alespoň začít - opravdu snižuje mnoho možných překážek selhání.

„Můžeme udělat port XBLA později, až budou věci stabilní“ mentalita.

A v menší míře je to v pořádku i pro Linux, a pokud je sedm zákazníků dobrý, můžete tam začít.

Ale Windows má tři obrovské výhody: skutečně otevřený vývoj, skutečně otevřené nasazení a velmi velká, velmi aktivní zákaznická základna, která má zájem o nepředvídatelné věci.

Je těžké si představit, kde jinde bych raději začal.

4
John Haugeland

Odpověď je zřejmá. Cílem psaní hry je vydělat peníze. Windows provozuje více koncových uživatelů, proto existuje větší trh a očekávali byste, že vyděláte více peněz ze hry pro Windows než ze hry pro Linux. Je to tak jednoduché.

Pokud si někdy položíte otázku „Proč někdo dělá ...“, pamatujte, že peníze způsobují, že svět obchází.

4
Russell Horwood
  1. Setrvačnost. Pokud jste Windows používali v minulosti, pak přechod na něco jiného je problém. Pokud používáte Windows DirectX, je snazší a pravděpodobnější, že bude fungovat dobře než OpenGL.
  2. Podíl na trhu. Podíl systému Windows na ploše na trhu je větší než podíl systému OS X, který je zase větší než podíl systému Linux. Peníze rozhovory.
  3. Značka. DirectX je lépe známý než věci jako SDL (což je věc, kterou byste potřebovali replikovat některé funkce DirectX, které přesahují OpenGL).
  4. Méně zmatek. Bude Linux Linux podporovat pouze do OpenGL 1.4 nebo OpenGL 2+? Můžete použít výukový program OpenGL 2.0 jako Úvod do moderního OpenGL. Kapitola 1: The Graphics Pipeline ve vaší verzi Linuxu?

V dnešní době je Linux spíše kuriozitou, pokud jde o vývoj her, a většina vývojářů by se raději fiskálně vydala verzi portu OS X před verzí Linuxu (viz věci jako Steam). I v tomto případě má konzolový trh hodnotu více než tyto dvě platformy kombinované pro hry ...

Pokud jste chtěli mono platformu DirectX je v pořádku. Pokud chcete být multiplatformní, existuje velká šance, že budete muset jít s OpenGL alespoň na některé z dalších platforem.

4
Anon

Myslím, že byste si měli přečíst více o historii DirectX a tento článek .

Myslím, že MS si vybrala DX před openGL, protože chtěla lidi zamknout v používání vlastního OS.

3
Mahmoud Hossam

Hodně souvisí s politikou a kontrolou. Na konci 90. let se SGI a MS skutečně dohodly na kombinaci úsilí:

http://en.wikipedia.org/wiki/Fahrenheit_graphics_API

SGI do projektu investovala značné prostředky, ne. SGI potřeboval MS více než MS potřeboval SGI. Zbytek je historie.

D3D a OpenGL jsou dvě velmi odlišná API, je na vývojáři, aby si vybral, který je pro vaše potřeby.

1
quellish

Jednoduše proto, že Linux hrozně selhal jako stolní systém. Jak už někdo zdůraznil dříve, Linux je nepořádkem pro vývojáře (různé knihovny, sady nástrojů ui atd.)

Dalším problémem je freetardismus a nedostatečná podpora proprietárního softwaru. Nvidia vždy poskytuje jemné (proprietární) ovladače pro Linux, Ubuntu a další distribuce to ale neposílají. Pro systém Linux není k dispozici také žádné rozhraní binárních ovladačů. (Ve zdrojích jádra je textový soubor s názvem binaryApiNonsense.txt nebo něco). Řekl jsem však, že v systému Linux je správně podporován pouze hardware Nvidia. Většinu her ID softwaru můžete hrát pomocí hardwaru Nvidia v systému Linux.

Další nástroje pro vývoj věcí. MSFT poskytuje vynikající podporu C++ a debugger Visual Studio je lepší než gdb s ohledem na C++. V neposlední řadě chybí další nástroje, jako je Photoshop. Rovněž vám umožňuje rychle vytvářet nástroje gui. Mnoho herních studií kóduje své nástroje pro interní použití pomocí rozhraní .net.

Téměř jsem zapomněl: Grafický systém je strašně zpátky, v dobách, kdy právě přenesli X11, protože to fungovalo nejjednodušší. Nepodařilo se jim správně navrhnout a implementovat moderní grafický systém, který mají OSx a Win.

0
Nils