Na GitHubu se objevil kód pro překlad aplikací Direct3D do OpenGL vytažený přímo ze zdrojového kódu Dota 2. Projekt je pod svobodnou MIT licencí a prozatím je dostupný bez jakékoli dokumentace. Za zveřejněním stojí Valve, provozovatel největší platformy pro distribuci her a softwaru Steam.
Implementace vrstvy by mohla pomoct herním studiím v portaci her na Linux, urychlit nástup operačního systému Steam OS a posunout tak hraní na Linuxu zase o kousek dál.
(Zdroj: Gaming on Linux)
DX9 je deset let stará technologie, a DX10 je v řadě věcí odlišné. Jak dlouho asi bude trvat implementace DX11 a DX12? Bude pokrývat dostatečný subset DirectX? A bude v tu dobu MS už vydávat DX15? :)
Dota je psaná pro DirectX 9, a vzhledem k tomu pohledu shora je graficky celkem nenáročná.
Když hovoříte o minimu funkcionality... Ještě pořád na Linuxu používáte X11, které je neskutečně pomalé, neřeší tisk ani jiná zařízení, je špatně dokumentované, nebezpečné (proto se tuneluje přes SSH), a po odpojení session se ani nelze připojit zpátky? Asi ano, a jste tedy o cca dvacet let pozadu proti Windows. Pokud MS dodává "jen nezbytné minimum", tak distra Linuxu zjevně nedodávají ani to minimum, což je dobře vidět na (ne)rozšíření linuxového desktopu.
Neřeší tisk, tunelování zvuku, USB ani jiná zařízení... jestli to ale není proto, že display server tohle dělat nemá;-) BTW ještě pořád je na RDP session pod windows nemyslitelné nasměrovat zvuk na jiný stroj, než obraz? Tohle Linux uměl už před 30 lety díky NAS a teď je to díky PA relativně transparentní vlastnost;-) A mimochodem... proč vlastně RDP tuneluje USB a ne třeba FireWire nebo ethernet nebo PCI-E nebo sériovou linku nebo PS/2? Vždyť tím vším se připojují periferie. Nepřijde vám to řešení tak nějak nekoncepční?
Proč by to display server neměl dělat? Koukněte na situaci ve Windows. Například kód pro zobrazení a tisk stránky je totožný, prostě jen pracuje nad jiným device contextem. To velmi usnadňuje implementaci WYSIWYG aplikací. Na Unixech máte pro zobrazování Xlib, a pro tisk leda print spooler. Aby se s tím vůbec dalo nějak pracovat, musíte nad X11 a print spooler postavit další vrstvu, která řeší zobrazování a tisk dvěma odlišnými code paths. Celé je to důsledkem toho, že při návrhu X11 se na grafický tisk vůbec nemyslelo.
Osobně jsem nikdy neměl potřebu přesměrovávat zvuk na jiný stroj než obraz. Ve Windows to zvládnou drivery třetích stran, ale nikdy jsem je ani nezkoušel. Předpokládám lehké problémy s tím, že zvuk je ve Windows per-session. Kdybych používal Linux, daleko víc by mě trápilo, že nemůžu prostě otevřít aplikaci, napsat hostname, připojit se, a mít i zvuk.
Přesměrování USB je v RDP proto, aby uživatel mohl připojit USB klíčenku nebo čtečku čipových karet. To se při práci celkem hodí. Srovnejte s X11, které je nepoužitelně ukecané a pomalé, neumožní vám použít klíčenku, přesměrovat zvuk, nemůžete provádět copy-paste (s výjimkou textu)...
Co se týče tisku, tak právě většinou se tiskne něco jiného, než co se kreslí na monitor. A hlavně jiným způsobem. Posílat tiskárně bitmapu je koncept hodný levných inkoustovek. Solidní tiskárny zvládají postscript, některé přímo PDF. Tyto formáty jsou podstatně úspornější na pásmo a přenášejí se do tiskárny výrazně rychleji, než velká bitmapa. Takže si nemyslím, že display server má něco společného s tiskem. Alespoň ne obecně a ne dnes - možná v časech dávno minulých...
Zrovna přesměrování zvuku občas používám. Je fajn mít zvuk na desktopu s připojenou reprosoustavou a obraz na tabletu v posteli z aplikace spuštěné z NTB na stole:-) Stejně tak je fajn mít možnost pustit si audio stream z jiného stroje na síti nebo naopak přesměrovat svůj audio stream na jinou stanici. A věřím tomu, že moje fantazije je v tomto směru hodně omezená. Jinak s tou aplikací pro připojení se zvukem máte pravdu - ještě jsem ji na Linuxu nepotkal. Ono prostě stačí připsat jeden parametr ssh a jeden další řádek to terminálu na hostovi, tak to asi nikdo nepovažoval za užitečné dávat do klikátka.
To, že RDP umí zpřístupnit vzdálene klíčenku, je rozhodně dobré. Ale proč zrovna USB klíčenku? Proč ne disketu? Nebo disk na firewire? Nebo optický disk? A jak to souvisí se zobrazováním? Přijde mi to prostě jako nekoncepční řešení. V Linuxu a nejen tam je na tunelování USB samostatná služba - tu si buďto pustím, když chci USB tunelovat a nebo nepustím, když nechci. Stejně tak pokud chci tunelovat nějaké další rozhraní. A zase mám svobodu v tom, že tunelování rozhraní není spjato se zobrazováním, takže může běžet z jiného stroje - třeba když chci flashku z NTB, zatímco na telefonu si zobrazuji okno aplikace.
Je to dany primarne tim, ze widle nepracujou s USB jako s diskem - proto trebas na widlich nemuzes na USBcku vytvorit vice oddilu ... holt nekdo u M$ myslel az vymyslel ... kdyby to totiz udelali tak, ze se to jako disk chovat bude, tak pak neni problem uplne stejne pripojit libovolnej disk.
Windows samozřejmě s USB klíčenkami pracují jako s diskem. Koncepčně ale mají nahrazovat diskety, takže Windows nabízí vytvoření jediné partition, a mountuje jen jednu partition.
Přes RDP lze připojit libovolný disk. Jenže je to pochopitelně potřeba pro každý disk potvrdit na klientovi. V případě USB klíčenek lze povolit jen USB port, a uživatel pak může kdykoliv připojit klíčenku - a nejen tu.
Má to jen jeden drobný problém. Tiskárna není displej. X11 samozřejmě tohle umělo (Xprint), ale nakonec to bylo odstraněno. Právě z toho důvodu, že tiskárna není displej, na tištěné stránky např. nepatří tlačítka, dekorace oken, menu a podobně. Pokud ale chcete zobrazit to, co se bude tisknout (WYSIWYG), tak to X11 umí pomocí Cairo.
Proč RDP neumí přesměrovat libovolné zařízení? Když si dovolím citovat: Celé je to důsledkem toho, že při návrhu RDP se na další zařízení vůbec nemyslelo.
Xprint uměl na tiskárně původně vytisknout jen dump bitmapy X11 serveru. Podpora dalších typů výstupu přišla velmi pozdě, a jako u všeho spojeného s X11 to bylo utrpení.
Tiskárna není display, ale chcete po ní přece kreslit totéž. Jak jsem psal, ve Windows si prostě vyžádáte device context tištěné stránky namísto okna, a kreslíte do něj. Nevidím důvod na stránku kreslit tlačítka a dekorace - ty přece většinou nekreslíte ani do okna WYSIWYG aplikace.
Při návrhu RDP se přemýšlelo nad tím, co uživatelé potřebují pro vzdálený přístup. Přesměrování síťového interface mezi těmi věcmi nebylo. Nicméně RDP je rozšiřitelné, takže máte volné ruce :)
Xprint uměl na tiskárně původně vytisknout jen dump bitmapy X11 serveru. Podpora dalších typů výstupu přišla velmi pozdě, a jako u všeho spojeného s X11 to bylo utrpení.
Protože je nesmysl tisknout pomocí příkazů pro kreslení oken. Obsah WYSIWYG oken klidně můžete vykreslit v PostScriptu a zobrazit je přes Cairo nebo (v době Xprintu) DPS.
Tiskárna není display, ale chcete po ní přece kreslit totéž
vs.
Nevidím důvod na stránku kreslit tlačítka a dekorace
?
Nejde o příkazy pro kreslení oken, ale o příkazy pro kreslení grafiky do těch oken. Vyberete si context (obsah okna, kontejner v okně, okno desktopu, dekorace okna), a zavoláte
e.Graphics.DrawBezier(blackPen, start, control1, control2, end);
Tyhle příkazy vám umožňují kreslit a psát text úplně stejně po tištěné stránce, jako po obrazovce. Liší se jen v tom, jestli je objekt Graphics obsah okna, tiskárna, plotr, nebo něco jiného.
Ve Windows navíc poskytují i drivery grafické karty a tiskárny stejné funkce. Vykreslení křivky (DrvFillPath) přece může mít stejný interface, ať jde o jakékoliv zařízení. Konkrétní implementace se samozřejmě liší podle zařízení: driver grafické karty může říct "neumím" a nechat si od GDI SW vyrastrovat bitmapu, driver plotteru to může přeložit na HPGL sekvenci, PS driver to převede na PS sekvenci atd.
BTW projekt Cairo se snaží přesně o tohle. Bohužel ale místo driverů s jednotným API musí používat tak odlišné back-endy jako X11, DirectFB, OpenGL, PostScript, SVG a kdo ví co ještě. Kde jsou Windows už dvacet let elegantní a praktické, Unixy to dnes zuřivě lepí sadou hacků vzešlou ze špatného návrhu.
Mno.. a co když budu chtít vykreslit NURBS křivku, nebo povrchovou reprezentaci objektu v podobě polygonů? To taky každý driver podporuje? A co když chci vykreslit CSG strom? A objekt reprezentovaný voxely? To driver každého zařízení všechno podporuje? Nebo se použije také knihovna - tedy stejný přístup, jako když se použije Cairo? A co když je to driver pro jehličkovou tiskárnu, co umí jen znakový režim? To prostě vykreslení selže, protože to driver neumí? Nebo drivery takových tiskáren mají generovat ASCII art? A co Brailův terminál? Přijde mi, že ta elegance pramení hlavně z omezených možností Windows - prostě v době, kdy ten návrh vznikal, se počítalo s monitorem a grafickou tiskárnou a ostatní věci se jaksi znásilňují na úrovni driverů, které pak mají velké a náročné procesy, každý to dělá po svém a každý jinak. Mě přijde elegantnější to vykreslit v knihovně nějakým způsobem pro různé "hloupé" backendy a těm to pak poslat. Výhodou takového řešení je i to, že oprava chybného vykreslování se vyřeší restartem aplikace s novou verzí knihovny a nemusí se reloadovat driver. Navíc jsou pak drivery malé a lépe udržovatelné. A rasterizaci počítá CPU tak i tak. Naopak tam, kde to jde, se použije chytřejší backend, jako OpenGL a pro rasterizaci se použije backend 1:1.
Jinak jako "bonus" jsou drivery na windows proprietární a zcela uzavřené a tedy oprava chyby v rasterizaci závisí na dobré vůli výrobce zařízení/driveru. Navíc kromě windows jsou i jiné OS s vlastním řešením - X server, Quartz, adnroidí display server, co nevím, jak se jmenuje;-) V důsledku toho pak mnohé aplikace rasterizují knihovnou - například ono Cairo, nebo QT raster engine a do elegantních driverů sypou už jen hotovou bitmapu v naději, že na ní už není moc co pokazit.
Ten vás strach z nemožnosti si opravit zdroják je až komický. Kdy jste si naposledy opravoval chybu v OpenOffice nebo MySQL? Asi nikdy. Autor driveru vám samozřejmě může dát zdroják, pokud chce. Jenže on většinou nechce - opravy chyb řeší support. Uvědomte si také to, že na otevřeném Linuxu vám ty drivery i po více dvaceti letech fungují neskutečně mizerně, kdežto ve Windows prostě fungují. Na Linuxu se totiž z možnosti opravy často stává nutnost opravy (kterou stejně nakonec neuděláte, protože by to bylo velmi drahé).
Samozřejmě existuje více OS. Pokud máte tu smůlu, že musíte psát pro více platforem, budete zřejmě potřebovat nějaký wrapper. Například Cairo má jako jeden z back-endů GDI. Pochopitelně není potřeba rastrovat všechno v Cairu, i když například v případě použití OpenGL se asi spousta věcí bude řešit přesně takhle.
Ano, ve windows drivery prostě fungují - prostě nějak... ale že by fungovaly dobře, nebo dokonce bez problémů, tak to je spíše vroucné přání. Navíc na rozdíl od opensource driverů se ale reálně moc neudržují a problémy se řeší pořízením nového hardwaru s aktuálními drivery. Jestli vám tohle řešení přijde jako ideální, pak samozřejmě respektuji váš názor, na který máte nárok - ale souhlasit nemohu.
Ve Windows je situace s drivery uspokojivá. Jsou k dispozici drivery pro ohromnou spoustu zařízení a existuje funkční program testování a certifikace driverů. Na Linuxu je podpora HW výrazně menší, často nejsou vůbec testované na HW na kterém mají fungovat, nikdy nevíte jestli daný HW bude fakt fungovat, a hlavně často nefungují, nebo fungují napůl. Problémy jsou i s tak základním HW, jakým je grafická karta. O občasných příhodách s bricknutím HW raději ani nemluvit.
Souhlas, některé drivery pro Windows nejsou k dispozici pro novější verzi OS. Někdy se tomu dá pomoct. Jindy ne, a to zamrzí.
Len tak informacne, schopnost restartovat driver pri jeho pade bola pridana ako podmienka, alebo dosledok tej certifikacie? :D
Lael, ja z Vas mam obcas pocit, ze svoje prispevky pisete pre nahodnych okoloiducich. Nemozete snad predpokladat, ze nikto z ucastnikov diskusie realne nezazil Windows a niektoru z jeho typickych ukazok driveru :)
Tady si o tom můžete přečíst.
http://msdn.microsoft.com/en-us/Library/Windows/Hardware/ff570088(v=vs.85).aspx#E2
Typická ukázka vypadá tak, že driver prostě funguje. Samozřejmě se najdou výjimky. Když má zařízení procesor, zdá se, že nemůže fungovat bez chyby. Většina problémů s drivery je ovšem způsobená necertifikovanými drivery.
Ovladače ve Win8 jsou v pohodě. Stovky MB bloatware netvoří drivery, ale software instalovaný s nimi. Zkuste si instalační balík rozbalit, a uvidíte, že driver jako takový je malý. Instalace driveru ve Windows obecně nevyžaduje restart; samozřejmě ty podpůrné utility mohou naběhnout až po restartu prostředí.
Aplikace kreslí vždy stejně pomocí API, a o víc se nestará. Windows (typicky z GDI) pak pro většinu operací volají drivery. Drivery mají capabilities, kterými hlásí podporované operace. Například grafická karta asi bude umět nakreslit obdélník vyplněný barvou, PCL tiskárna nakreslit čáru a text, GDI nebo jehličková tiskárna (a všechna ostatní zařízení, snad vyjma HPGL plotterů) umístit bitmapu - těch operací je celá řada. Pokud driver nějakou věc neumí, tak jí nemá hlášenou jako podporovanou operaci, a Windows požadované volání API rozloží na volání, kterým driver rozumí. A mimochodem aplikace může sekvenci volání API serializovat do souboru typu EMF, a kdykoliv ten soubor nechat vyrastrovat na jiném stroji.
API pochopitelně nenabízí kreslení symbolu yin-yang, Utah teapot a dalších high level objektů. Pokud chcete vykreslit NURBS křivku, tak prostě použijete to, co vám API umožňuje. V tomto případě zřejmě Bezier curves a nějaké výplně.
Quartz na MacOS funguje dost podobně, akorát používá grafická primitiva postavená na PDF. To vychází z NextSTEPu, který měl DisplayPostscript. Ve Windows nebyl použit PS, protože byla potřeba licence od Adobe, a jeho rastrování bylo příliš pomalé.
Jak jsem už psal, Cairo se snaží o podobný přístup: aplikace kreslí voláním API po různých surfaces, a Cairo se stará o zbytek. Jenže to přišlo o 20 let pozdě, a navíc Cairo nekomunikuje s drivery, ale s X11, OpenGL, DirectFB, pluginem pro PDF, SVG apod. Jestli vám to přijde lepší, tak jste asi jediný.
Nikdy jsem neviděl použití Display PostScript na Linuxu. Údajně byla nějaká podpora v X.Org. Otázkou je na jaké úrovni, a jestli byl vůbec podporovaný tisk.
Super, Cairo si umí popovídat i s OpenGL knihovnou. Bohužel ty back-endy jsou každý pes jiná ves, což zvyšuje složitost kódu a přináší dodatečný overhead. Něco jako Cairo nebo DPS (bez toho nákladního vlaku historie z éry děrných štítků a textových terminálů) mělo být defaultním grafickým API před dvaceti lety, podobně jako GDI ve Windows.
BTW aby toho nebylo málo, situace se nezlepší a nevzniknou žádné Cairo-drivery. Přichází totiž Wayland a Mir, a Cairo je pokud jsem si všiml nepodporuje. Takže Cairo bude volat knihovnu libX11, ta bude volat xwayland nebo XMir, odtud na Wayland nebo Mir, a pak to snad už propadne na driver. Wow - to bude určitě rychlejší a spolehlivější, než to ošklivé X11 :/
DPS je API, které používá primitiva PostScriptu. Jinak na Macu se netiskne v PS. MacOS X používá pro kreslení po obrazovce i tisknuté stránce PDF primitiva, a drivery to pak převádějí například na PCL - je to něco úplně jiného, než na Linuxu.
http://en.wikipedia.org/wiki/Display_postscript#Modern_derivatives
Velikost spool file záleží na více věcech:
- Samozřejmě velikost originálního souboru. Stostránkové PDF plné fotek asi bude mít velký spool file.
- Mizerně napsaný driver tiskárny.
- Samotné PDF. V PS generovaném některými šílenými aplikacemi jste mohl najít místo šedé výplně výplň z malých písmen "X", a podobné speciality, které se mohou reprezentovat dost obtížně. U PDF můžou nastat podobné problémy.
- Aplikace ze které se tiskne. Chce to například neprovádět resizing bitmap do cílového rozlišení, protože 100kB JPEG natažený přes celou stránku bude po převodu na 9600 dpi jistě zabírat daleko více místa.
Pokud tiskárna nesežere spool file, tak bych to viděl na driver. U HP jsem několikrát musel přejít na Basic Drivers (což je knihovna s popisem parametrů pro MS driver), protože ty Full Drivers byly nepoužitelné.
Myslim, ze si sam odpovidate - nemel by to resit, protoze je to DISPLAY server.
Na rozdil od ostatnich se tu nebudu zlobit, ze neco neni systemove, RDP nikdy k problemum systemove nepristupoval a jednotlive funkce byly postupne bastleny tak, jak to MS prislo, ze by je bylo hezke umet.
Univerzalni presmerovani USB zarizeni skrz RDP neni technicky mozne, protoze nelze obecne dodrzet casovani. Proste nemuzete mit ovladac na serveru a ovladat jim hw na klientovi. Tudiz je to cele nesmysl nazyvat presmerovanim USB zarizeni.
Dalsi vec je tisk. Kdyby to fungovalo tak uzasne, jak to popisujete, tak by server nepotreboval ovladace k tiskarne klienta. Dale by bylo uplne jedno, kde se tiskarna klienta nachazi, vykreslovani by totiz probihalo az na klientovi a tisk by byl z jeho pohledu tedy lokalni. Ale neni tomu tak. Nevytisknete nic na sitove tiskarne (LPR apod.), nevytisknete nic ani na tiskarne, kterou ma klient nasdilenou z jineho pocitace (pokud na ni server take nevidi).
Sdileni disku je pomerne prijemna vec, nicmene je to o dost pomalejsi, nez SMB, takze je to spise nouzovka. A urcite by to chtelo jeste trosku usili, protoze pouzivani subst pro mapovani pouze urcite podslozky je drbani se levou rukou za pravym uchem.
Vysmivat se X11 za to, ze neco neumi, nebo resi hure, nez RDP, je z meho pohledu hloupe. Souhlasim s tim, ze je RDP na sitovy pristup lepsi. Ale podivejte se o kolik je mladsi. Je odpovedi na X11 a kdyby se nepoucilo z jeho chyb, tak by to bylo ale sakra trapne, nemyslite? MS si za sebou ostatne taky vlaci peknych par kouli na noze, kuprikladu nesmyslne zamykani souboru a case-insensitivity. Trosku pokory prosim.
OK, takže nejlepší je kreslit po obrazovce jedním API a po tiskárně úplně jiným, protože... proč?
RDP je určené pro vzdálený přístup, takže MS přidává věci, které jsou důležité pro tento scénář.
Při tisku na klientskou tiskárnu přes RDP potřebuje server znát parametry tiskárny - podavače, velikosti papíru, netištitelné okraje atd. To že RDP fuguje pouze s lokálními tiskárnami klienta je by design.
Souhlas, sdílení disku je nouzovka.
X11 patří čestné místo v muzeu slepých cest osmdesátých let, nikoliv místo na desktopu.
A procpa mi ve widlich po pripojeni pres RDP zmizej vsechny GPU? Procpak je nemuzu vyuzit trebas k nejakemu vypoctu ... neb pro widle prestanou existovat? Procpak nemuzu pres RDP nainstalovat trebas novou verzi ovladace ... protoze mi vynada, ze takovou grafarnu nezna? Procpak nemuzu na realny mnitor poslat nejakou aplikaci a pritom si na RDP delat neco sam pro sebe?
Fakt uzasna vymozenost, muset chodit ke stroji kterej je pripojenej k projektoru/tv osobne, a osobne na nem poustet prezentace, protoze na dalku to nejde ...
RDP nepodporovalo GPU, protože může být připojeno více sessions najednou, a virtualizace GPU pro více uživatelů není dvakrát jednoduchá. Nicméně už cca pět let existuje RemoteFX vGPU.
Novou verzi ovladače samozřejmě můžete nainstalovat. Pokud tomu něco brání, bude to nejspíš aplikace daného výrobce grafické karty - ovšem instalaci z Device Manageru můžete provést bez ní.
K projektoru nemusíte chodit osobně, můžete použít Remote Control na libovolnou session (případně použít broadcasting vestavěný v PowerPointu). Případě X11 se stejně budete hrabat s konfigurací na terminálu tak dlouho, že byste ten projektor během té doby fyzicky připojil desetkrát, i kdyby byl na stropě a měl jste jen 20cm kabel :)
Vice sesion najednou na desktopu rozhodne bez hackovani pripojeno byt nemuze ... takze nemel nesmysle. Instalaci ovladace brani predevsim to, ze widle ovladaci sdeli, ze takove zerizeni v systemu neexistuje. Stejne jako to zdeli libovolne aplikaci v ramci projektu boinc. K projektoru musim dojit osobne proto, ze v pripade pripojeni pres RDP jaksi aplikace nevidi zadnou jinou grafickou kartu a tudiz ani zadny vystup. Na linuxu spustim trebas pres ssh mplayer -display ... a pustim si vystup na libovolny z N monitoru.
RDP na serveru i desktopu je stejná technologie, na desktopu jen drobně ořezaná z licenčních důvodů. Nicméně vám nic nebrání použít Terminal Server, který sdílení session umí. Vyjma toho můžete také spustit prezentaci na jiném stroji vzdáleně.
Ještě jednou k instalaci driveru: jděte do Device Manageru, tam si najděte grafickou kartu, a nechte aktualizovat driver. Vychte ho vyhledat na webu, nebo si ho nainstalujte z lokálního stroje. Pokud to nepůjde, přijďte zpátky.
RDP vytváří virtuální driver pro každou session, a domlouvá s klientem, co vlastně umí. Pokud se aplikace zajímá, na jakém driveru jede, tak to samozřejmě není grafická karta serveru, ale ten virtuální driver. To může zabránit instalaci driver package přes setup, protože výrobce instalaci zastaví, když kartu nevidí. Přes Device Manager na tom ale nezáleží.
GPU akcelerace je ve Windows původně věc Direct3D shaderů. Samozřejmě pokud jedete na virtuálním driverů, který nemá 3D akceleraci, tak jí těžko použijete. Ale jak jsem psal, můžete použít RemoteFX vGPU. Pro výpočty na pozadí je navíc nesmysl používat Remote Desktop - napište si to jako Windows Service.
BTW většinu toho, co tu píšu, jsem vám psal už před pěti týdny.
To jistě ano. Jenže tituly pro XBox 360 jsou z obchodního hlediska mrtvé. Kdo si je chtěl zahrát, udělal to na XBoxu nebo Windows. Jejich port na Linux obnáší daleko víc problémů, než jen překlad DirectX na OpenGL. A podle všeho z toho nekoukají žádné velké peníze, dost možná spíš ztráta.
Zajímavé jsou budoucí tituly velikosti GTA*, FarCry*, BioShock*, Call of Duty apod. Takové GTA V sebralo na tržbách 800M USD během jediného dne, a to vyšlo "jen" pro konzole. Nové áčkové hry budou vycházet jen na DX 11 a vyšší, protože WinXP právě končí podpora, a nové konzole jsou postavené na DX 11.
Tak to jsou vývojáři asi magoři, protože naprostá většina PC her dál jede pod DirectX. Port na konzole řeší engine, nejspíš odlišnými code paths pro různá zařízení.
BTW PlayStation 4 nepoužívá OpenGL. Používá high level API GNMX, které je dost podobné DirectX, a low level API GNM, které na Windows nemá ekvivalent (možná AMD Mantle). Na shadery se používá PlayStation Shader Language.
PlayStation 4 umí... OpenGL 4 - zdroj? Mě se to nepodařilo nikde dohledat. Wikipedie i Sony na GDC zmiňují jen GNM a GNMX. Ještě jsem dohledal poznámku, že PlayStation Shader Language je velmi podobný HLSL v DirectX 11.
http://en.wikipedia.org/wiki/PlayStation_4_system_software#Technology
http://www.eurogamer.net/articles/digitalfoundry-inside-playstation-4
Například zde.
PlayStation Shader Language je podobný HLSL z DirectX. Nebo nVidia Cg. Nebo GLSL z OpenGL. Protože to vše si je velmi podobné :-)
Aha. Článek psaný skoro rok před uvedením PS4, a nejspíš někým, kdo to API v životě neviděl, a GNM a GNMX kupodivu nezmiňuje. Naopak ti co portovali hru na PS4 píšou, že má dvě API pro grafiku, a to GNM a GNMX; o OpenGL ani slovo. Srovnejte relevanci vašeho a mého linku.
http://www.eurogamer.net/articles/digitalfoundry-how-the-crew-was-ported-to-playstation-4
PlayStation 4 bylo oznámeno 20. února 2013, takže ten článek není předčasný. V té době spíš ještě nebylo vytvořeno GNMX pro snažší portaci Direct X her z Xboxu. Tady máte článek ze stejné doby, kde Sony zmiňuje OpenGL na PlayStationu, ale nezmiňuje GNM(X) (Zmiňuje i DirectX, ale to Sony asi těžko bude licencovat od Microsoftu.)
U hry napsané v Direct X je jistě velice bude zajímat podpora OpenGL :-)
Váš link uvádí, že PS4 má DirectX 11 a OpenGL 4.0. O tom dost pochybuji. Autor sám píše, že neví o čem píše. Pokud v diskusi padlo něco jako "GPU is DirectX 11 and OpenGL 4.0 capable", dost možná z toho vylezlo právě tohle.
Osobně za daleko relevantnější považuji to, co tvrdí lidé z Ubisoft Reflections, kteří mají přístup k dokumentaci a úspěšně portovali hru. Nějak se mi nezdá, že by přehlédli podporu OpenGL na PS4.
No ci to bude strata nechajte prosim na vyrobcov hier.
Co sa tyka zaujimavych hier tak vam dlho tato myslienka nevydrzala: http://www.root.cz/zpravicky/crytek-potrvzuje-cryengine-bude-podporovat-linux/
Hadajte ktora z vami menovanych hier pouziva cryengine? A nebudu posledny.
To je hezky naivni dotaz. O VS by se dalo povidat hodiny. Mam sem preposlat ty litanie meho kolegy, ktery se stara o prechody na novou verzi MSVS? Jsou to dlouhe smutne pribehy o tom, co vsechno prestalo fungovat na urovni zdrojaku, projektu, pluginu, GUI. Pokazde travi tydny se supportem, psanim podpurnych toolu aby nahradil chybejici vlastnosti. Uz se za ty roky dostal docela hluboko ve strukture MS, takze dostava uprimne odpovedi. Vetsina se da shrnout tak, ze to proste ted v Indii delaj "jinac"...
Menil se scope ridici promenne ve for cyklu, menily se namespacy statickych metod, menily se pravidla inlinovani COM deklaraci v cpp. V GUI byla takova hezka vec, ze se dala konfigurace vyberu projektu svazat se startup projektem, ale voni rekli ne. A tak bych mohl pokracovat dlouho.
Ostatne, kdyz mam pouzivat VS editor, tak si pripadam, jako bych se vracel 15 let zpatky a bral do ruky kladivo a dlato, ale to je na jiny povidani.
Na druhou stranu, debugger uz ma docela slusnou podporu pro COM objekty, sice 10 let pote, co je ta technologie mrtva, ale je tam!
On se měnil scope ridici promenne ve for cyklu? Pokud jsem si všimnul, tak se minimálně deset let nastavuje v compiler options. Nicméně vyjma "konfigurace vyberu projektu svazat se startup projektem" se to týká jazyka, nikoliv vlastního VS.
Já si připadám jako ve středověku vždycky když spustím Eclipse. Asi to bude o zvyku.
Ohledne toho scope se neco zmenilo takovym zpusobem, ze najednou nepomohlo ani zapnuti ani vypnuti bez toho, ze by se musely menit zdrojaky nebo to hazelo warningy nebo tak neco. Uz si to presne nepamatuju, je to hodne let.
Kazdopadne ja to psal jen jako priklady, faktem zustava, ze kazdy prechod na nove studio vyzaduje zhruba tak jeden clovekomesic, takze my prechazime obverzi abysme se z toho nezblaznili.
Ten editor neni o zvyku. To si rychle vsimnete, ze v mistech kde treba netbeans doplnuje vyrazy s ohledem na typ, coz je vetsinou jen jedna moznost a v drtive vetsine ta co chci, tak VS bud zaryte mlci nebo nabizi kdejakej balast co kde po projektech najde. A je to opet jen jeden priklad z mnoha vlastnosti co ve VS proste nejsou. A to ne ze nejsou tim zpusobem, ze jsem nenasel zkratku. To jakoze nula, nic, neexistuje to.
Jeste jsem si vzpomnel na goto definition, to me taky hodne bavi. Skocite jednou, je to hned, podruhy, je to hned, potreti - a 20s premejsli kde to asi tak muze byt. A ejhle, ono ve vedlejsim tabu.
Vzhledem k tomu, ze VS vlajkova lod MS to vypovida mnohe o te spolecnosti.
To se měsíc učíte, jako vypadá menu v nové verzi VS? :) Asi ne. Je to o změnách v implementaci jazyka. Pokud na problémy s přechodem na nový kompilátor narážíte často, tak je váš kód zřejmě v dost mizerné kvalitě.
Osobně píšu v .NETu, a IntelliSense si nemůžu vynachválit. V C++ bych doporučil se kouknout na troubleshooting section.
http://msdn.microsoft.com/en-us/library/vstudio/ms235519(v=vs.100).aspx
Goto definition mi funguje rychle a spolehlivě. Neznám rozsah vašeho projektu, velikost paměti počítače atd., ale typicky bývá problém způsobený nevytvořeným iPCH adresářem, případně vadnými PCH soubory. To by vám BTW řekli i na MS supportu :)
Vzdyt pisu, ze jde o zmeny na vsech vrstvach. Zdrojak, nastaveni a format projektu, buildy, pluginy, gui. V nejakem hracickovem projektu se vam to neprojevi, ale kdyz budete delat vetsi aplikaci, tak narazet budete na vsech tech vrstvach.
A kdyz ctu dale, tak budiz vam odpusteno, netusite co mluvite, asi proto ze jste jeste nezazil srazku s realitou. Ve velikosti ram problem nebude, protoze to na disk nehrabe, ale problem bude v tom pouzivani pch pro hledani definice. U nasi aplikace totiz po buildu zabiraji *.pch neco pres 40GB a to studio se v tom asi totalne ztrati. Ve skutecnosti to teda prochazi i headery atd., o neco se to snazi, ale blbe. Pritom je to treba vedlejsi soubor v projektu, skoda no.
Jinak k tomu editoru, zkuste si nekdy psat v jave treba v netbeans, pak pochopite, ze na IntelliSense je nejnamakanejsi ten nazev.
Na vašem místě bych si přečetl link níže, případně kontaktoval MS support.
http://blogs.msdn.com/b/vcblog/archive/2011/03/29/10146895.aspx
Java i .NET jsou pro IntelliSense výrazně průhlednější, než C++. NetBeans jsem nepoužíval nikdy, těch pár řádků psaných v Javě mám v Eclipse.
Porovnavam C# v MSVS2010 (popravde nevim jak je to v posledni verzi) a javu v netbeans, editor, doplnovani, refactoring atd. to je proste nebetycnej rozdil. Ted to zkousim, i na jednoduchym kusu kodu musim v tom c# zmacknout 2x tolik klaves abych dostal to samy. Treba kdyz pisu for each, tak nb zkusi najit co by se dalo projit a samo to doplni vcetne typu atd. Vetsinou jen zmacknu enter ze to beru, kdyz ne, zmenim kolekci a ono to samo predela zbytek. Kdyz se mi nelibi nazev promenne, je to na dva uhozy. To studiu se musi vsechno poctive napovedet.
A to prosim se velikost instalacky muze smele porovnavat s velikosti patchu na VS a .net.
Ackoliv jsem toho nazoru, ze VS je naopak vynikajici produkt, ktery nechal konkurenci daleko za sebou, tak s intellisense ma Vas oponent pravdu. Skutecne by VS mohlo vyber promennych filtrovat ci radit dle ocekavaneho typu - a ano, rec je o C#. Ostatne je nekolik (pekne drahych) rozsireni VS, ktera toto a dalsi veci resi.
