Crytek wil CryEngine naar Linux porten

Gameontwikkelaar Crytek, bekend van Far Cry- en de Crysis-games, wil zijn CryEngine porten naar het Linux-platform. Dat is op te maken uit een vacature waarin het Duitse bedrijf zoekt naar een developer met de nodige Linux-ontwikkelervaring.

In de vacaturetekst op de website van Crytek is te lezen dat de gameontwikkelaar zijn CryEngine wil porten naar Linux en dat het daar een geschikte programmeur voor zoekt. Naast het porten zou de persoon ook verantwoordelijk zijn voor ondersteuning op het Linux-platform, bijvoorbeeld voor bedrijven die de CryEngine willen gebruiken voor 3d-games op het opensource-besturingssysteem. Onduidelijk is nog of Crytek al bezig is om zijn game-engine te porten of dat het project nog moet starten.

Met een port van de CryEngine is opnieuw een vooraanstaande gameontwikkelaar bezig om zijn software geschikt te maken voor het Linux-platform. Onder andere Valve heeft zijn Steam-client geschikt gemaakt voor het opensource-besturingssysteem en is inmiddels beschikbaar in bijvoorbeeld het Ubuntu Software Center. Ook heeft Valve zijn Source-engine geport en games als Portal en Left 4 Dead 2 compatibel gemaakt met Linux.

Reacties (127)

[Gps4l]

OpenGl is sneller dan DirectX.
Dat dit er in de praktijk niet (nog? ) uitkomt ligt aan de drivers.

De amd driver bijvoorbeeld doen het op windows en Linux even goed of even slecht, het is maar hoe je het bekijkt.

http://blogs.valvesoftware.com/linux/faster-zombies/

After this work, Left 4 Dead 2 is running at 315 FPS on Linux. That the Linux version runs faster than the Windows version (270.6) seems a little counter-intuitive, given the greater amount of time we have spent on the Windows version. However, it does speak to the underlying efficiency of the kernel and OpenGL. Interestingly, in the process of working with hardware vendors we also sped up the OpenGL implementation on Windows. Left 4 Dead 2 is now running at 303.4 FPS with that configuration.


OpenGL versus Direct3D on Windows 7

This experience lead to the question: why does an OpenGL version of our game run faster than Direct3D on Windows 7? It appears that it’s not related to multitasking overhead. We have been doing some fairly close analysis and it comes down to a few additional microseconds overhead per batch in Direct3D which does not affect OpenGL on Windows. Now that we know the hardware is capable of more performance, we will go back and figure out how to mitigate this effect under Direct3D.

[Verwijderd]

Kanttekeningen:

1) Ze hebben het hier over Direct3D9, een sterk verouderde versie, waarvan het bekend is dat deze beter loopt onder Windows XP dan onder Windows 7, omdat Windows 7 ontworpen is voor Direct3D10+.

2) Hun claims van betere performance zijn in de praktijk nooit gemeten, voor zover ik weet. Ik heb wel benchmarks gezien waarbij linux Windows 7 ongeveer wel bij kon houden, zolang je dingen als MSAA maar niet aanzette, want dan liep de performance onder linux harder terug dan onder Windows. Helaas kan ik die nu niet meer vinden. Wat op zich wel vreemd is... Als je zoekt op benchmarks, vind je ALLEEN maar referenties naar die Valve blog, en nergens harde getallen.

Ik ontwikkel zelf ook grafische software, zowel met Direct3D (Windows XP/Vista/7/8, Phone en RT), en OpenGL (OS X, iOS, Android, linux, FreeBSD), maar mijn ervaringen zijn anders dan de beweringen van Valve.
Voor het simpele renderwerk is Direct3D9 op XP niet te kloppen. Voor het wat meer geavanceerde werk kan Direct3D11 sneller zijn.
M'n OpenGL code kan op Windows redelijk in de buurt komen van D3D-performance, maar sneller heb ik het nooit gekregen, nog niet eens even snel.
En op andere OSen heb ik m'n OpenGL code ook nog nooit zo snel zien draaien als onder Windows.

Ik zie ook hetzelfde terug met bv de Unigine benchmarks. Ook daar is D3D11 toch net wat sneller dan OpenGL onder Windows, en de OS X en linux versies halen niet dezelfde performance als Windows.
Dus ik denk niet dat het aan mijn code ligt (een simpele variant van mijn OpenGL-code is overigens op SourceForge te vinden, mochten mensen de code willen inspecteren en evt optimalisaties voorstellen).

Ik heb het verhaal van Valve dus altijd maar met een flinke korrel zout genomen.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:50]

[johnbetonschaar]

Feitelijk zijn die getallen ook helemaal niet zo boeiend eigenlijk, onder de streep is de grafische performance die je haalt voor 70% hardware, voor 20% drivers, voor 5% OS/kernel, en van wat er overblijft misschien nog een procent of 2 API overhead van DirectX/OpenGL. De getallen zijn natuurlijk uit de duim gezogen en enigszins gechargeerd, maar bij moderne videokaarten doet de API in feite niet veel meer dan de juiste data naar de videokaarten sturen, shaders initialiseren en af en toe wat commando's aan de GPU geven als er iets gerendered moet worden, al het zware werk doen GPU's tegenwoordig helemaal in de hardware of de driver. Ik denk niet dat het veel zin heeft om je druk te maken over het verschil tussen DirectX en OpenGL tegenwoordig, die tijd zijn we al lang voorbij.

[Verwijderd]

Ik maak me vooral druk over het verschil tussen DirectX en OpenGL in termen van API-ontwerp en de kwaliteit van drivers. Dingen als render-to-texture zijn pas HEEL laat in de OpenGL API geintroduceerd, waardoor er nu nog vrij veel hardware in omloop is die er geen support voor heeft, omdat de drivers te oud zijn.

Sowieso is het nog steeds tenenkrommend hoe je met framebuffers om moet gaan in OpenGL. Zo kun je dus gewoon niet bij de default framebuffer en z/stencilsurface komen. Daar moet je dan weer allemaal special case code omheen schrijven.
In Direct3D is een rendertarget gewoon een rendertarget. In D3D9 had je dan al wel een 'implicit' swapchain die gemaakt werd voor het window waaraan je je device koppelde, dat was dan wel een gewone swapchain, waar je gewoon de buffers van kon opvragen.
In D3D10+ kun je gewoon alle swapchains en buffers zelf bouwen, dus heb je helemaal geen special cases meer nodig.

Performance lijkt me sowieso niet heel relevant. Ja, misschien is het ene OS wel 20% sneller op dezelfde hardware dan het andere OS. En wat dan nog? Je kunt het spel op allebei spelen, daar gaat het uiteindelijk om.

[johnbetonschaar]

Drivers zullen het grootste probleem zijn voor Linux games inderdaad, vooral op AMD hardware (en op Intel, als je dat al serieuze optie voor games beschouwt). De Nvidia drivers zijn eigenlijk al jaren praktisch identiek als die op Windows.

Ik weet verder niet veel van DirectX dus ook niet hoe makkelijk het is om bij framebuffers en stencil buffers te komen (dat laatste lijkt me ook niet erg vaak nodig trouwens). Wat ik wel weet is dat OpenGL al eeuwen relatief goed gestandaardiseerde vendor-specifieke extensies heeft die dit soort dingen mogelijk maken, dat klinkt misschien niet erg positief, maar als je bedenkt dat je eigenlijk alleen maar serieus rekening hoeft te houden met Nvidia en AMD, is het nou ook weer niet zo'n groot probleem om voor enkele dingen hardware-specifieke code paden te hebben. Wellicht is dit met OpenGL 4 überhaupt al niet meer aan de orde (ken daar de details niet van maar volgens mij zijn ze daar praktisch van scratch begonnen en hebben ze alle klunzige constructies uit het verleden overboord gezet en de API compleet opgeschoond met game toepassingen in het achterhoofd).

Edit:
Om trouwens ook nog even in te gaan op de performance verschillen die je hebt waargenomen tussen Linux/OpenGL en Windows/DirectX: vergeet ook niet dat gcc vs. Visual Studio een behoorlijke impact kan hebben! Visual Studio genereert nog altijd veel betere code dan gcc. Eigenlijk zou je op Linux de Intel compilers moeten gebruiken, het zou me verbazen als Valve etc. ook geen icc gebruiken voor hun Linux ports.

[Reactie gewijzigd door johnbetonschaar op 22 juli 2024 14:50]

[Verwijderd]

stencil buffers te komen (dat laatste lijkt me ook niet erg vaak nodig trouwens).

Het is een z/stencil (als in: depthstencil) buffer, beiden zitten samen in 1 buffer gepakt.
Het punt is vooral met het wisselen van die dingen. Als je render-to-texture doet, moet je dus andere pixelbuffer en andere z/stencilbuffer zetten.
Omdat je niet bij de impliciete buffers kunt, moet je dus andere code hebben om die buffers te zetten dan alle andere rendertargets.
Dat is gewoon dom, lelijk en omslachtig.
Verder kun je ook niet de z/stencil hergebruiken voor een andere pixelbuffer. In D3D kon dat altijd wel. Zolang de z/stencil maar groot genoeg was, werkte dat prima. Tegenwoordig vinden ze wel dat je ze allebei exact dezelfde grootte moet maken, maar het management is ook veranderd. De buffers worden nu meteen deallocated als je ze niet meer gebruikt, zodat het videogeheugen hergebruikt kan worden voor een andere buffer. Een buffer is nu dus meer een descriptor geworden dan een fysiek gealloceerde buffer.

Wat ik wel weet is dat OpenGL al eeuwen relatief goed gestandaardiseerde vendor-specifieke extensies heeft die dit soort dingen mogelijk maken

Helaas niet dus.
OpenGL loopt al heel lang enorm achter de feiten aan.
Zo heb ik een leuke Mac Mini G4 als speledingetje, met een Radeon 9200 erin.
Dat is dus een GPU die DirectX 8.1 volledig ondersteunt, en onder Direct3D absoluut geen problemen heeft met dingen als non-power-of-two textures, render-to-texture, programmeerbare pixelshaders en dat soort grappen.
Onder OS X heb ik de laatste versie geinstalleerd, dat is 10.5.8, uit 2009... maar de OpenGL driver laat me niets van dat alles gebruiken.

Als je de Halo-port draait op dat system, krijg je een lelijke shader-loze versie, die er ongeveer uitziet als op een Radeon DDR of GeForce2.
Dat terwijl je op dezelfde hardware onder Windows gewoon alle eyecandy aan kunt zetten.

maar als je bedenkt dat je eigenlijk alleen maar serieus rekening hoeft te houden met Nvidia en AMD, is het nou ook weer niet zo'n groot probleem om voor enkele dingen hardware-specifieke code paden te hebben.

Dat kan dus niet, want in het voorbeeld van m'n Radeon 9200 heb ik helemaal geen extensies voor dat soort dingen, ook niet vendor-specific.

ken daar de details niet van maar volgens mij zijn ze daar praktisch van scratch begonnen en hebben ze alle klunzige constructies uit het verleden overboord gezet en de API compleet opgeschoond met game toepassingen in het achterhoofd

Was het maar zo'n feest. De API is 'opgeschoond' door er een aantal functies uit te mikken, en een paar andere functies net even iets anders te laten werken in core mode dan in compatibility mode. Wat er eigenlijk op neerkomt dat je zonder goede reden nu twee verschillende codebases moet gaan bijhouden... OGL 4.x code is namelijk niet meer 100% backward compatible (wat nou juist 1 van de sterke punten had moeten zijn van OpenGL).

vergeet ook niet dat gcc vs. Visual Studio een behoorlijke impact kan hebben!

Zie hierboven je eigen post, waarin je uitlegt dat het vooral van de hardware afhangt, niet zozeer van de API/drivers/OS/etc. Ook compilers spelen vrijwel geen rol. Iig, niet in het soort code dat ik getest heb. Ik doe altijd zo veel mogelijk op de GPU.

[johnbetonschaar]

Ik ben het niet oneens met wat je zegt, maar als je heel eerlijk bent moet je toch ook toegeven dat we voor het ontwikkelen van moderne games niet meer geïnteresseerd zijn in hardware als een Radeon 9200 toch? Ik ga even uit van DX10 klasse hardware, en die ondersteunt in OpenGL eigenlijk alles wat je met DirectX kunt doen, al dan niet gebruik makend van extensies. Op een Radeon 9200 draait ook op Windows praktisch geen enkele moderne engine meer.

Was het maar zo'n feest. De API is 'opgeschoond' door er een aantal functies uit te mikken, en een paar andere functies net even iets anders te laten werken in core mode dan in compatibility mode. Wat er eigenlijk op neerkomt dat je zonder goede reden nu twee verschillende codebases moet gaan bijhouden...

Wat ik er van begrepen heb is dat OpenGL 4 veel meer op OpenGL ES 2 lijkt, enorm uitgekleed dus en niet meer backwards compatible (wat je zelf ook al zegt dus). Dat dit lastig is voor een bestaande cross-platform codebase begrijp ik, maar er van uitgaande dat je bij het porten van een DirectX game naar OpenGL geen rekening hoeft te houden met oudere OpenGL versies is dat niet echt een probleem. Moet je er natuurlijk wel van uitgaan dat je drivers OpenGL 4 ondersteunen (ik geloof dat 4.0 inmiddels volledig bruikbaar is op AMD en Nvidia. Maar 4.1/4.2/4.3 nog niet).

Zie hierboven je eigen post, waarin je uitlegt dat het vooral van de hardware afhangt, niet zozeer van de API/drivers/OS/etc. Ook compilers spelen vrijwel geen rol. Iig, niet in het soort code dat ik getest heb. Ik doe altijd zo veel mogelijk op de GPU.

Als je het puur over graphics performance hebt dan gaat het inderdaad vooral om de hardware en drivers, maar bij een complete game zal zoiets als de compiler zeker wel uitmaken. Als jouw code vrijwel volledig GPU bound is dan zal het weinig uitmaken, maar als je ook nog AI, physics, procedurele omgevingen etc. wil doen (ie: dingen die vaak CPU bound zijn) dan gaat het zeker meespelen. Visual Studio en icc genereren code die in sommige gevallen zomaar 20% sneller is.

[Reactie gewijzigd door johnbetonschaar op 22 juli 2024 14:50]

[Verwijderd]

maar als je heel eerlijk bent moet je toch ook toegeven dat we voor het ontwikkelen van moderne games niet meer geïnteresseerd zijn in hardware als een Radeon 9200 toch?

Nou ja, het is maar een voorbeeld van het probleem van OpenGL, waar de specificatie bepaalde features wel ondersteunt, maar dat garandeert nog niet dat drivers die features ook implementeren, zelfs op hardware die dat wel ondersteunt.

Ik ga even uit van DX10 klasse hardware, en die ondersteunt in OpenGL eigenlijk alles wat je met DirectX kunt doen, al dan niet gebruik makend van extensies.

Helaas... Hetzelfde probleem speelt ook bij Intel. Zo heb ik twee systemen met wat oudere Intel DX10 GPUs erin, en die hebben alleen maar basale ondersteuning voor OpenGL 2.0 of 2.1 in de drivers (dus ook maar een handjevol extensies, en zeker niet de extensies die je graag zou willen zien, zoals up-to-date GLSL en geometry shader).
Alleen de nieuwste GPUs van Intel ondersteunen ook OpenGL 4.x in de driver.

AMD en nVidia doen het wel wat beter wat dat betreft, maar het probleem zal altijd blijven. Iets oudere hardware krijgt geen driver-ondersteuning meer, en dan blijft dus ook OpenGL achter.

Bij Direct3D ben je niet van de driver afhankelijk voor de API-functionaliteit.

Wat ik er van begrepen heb is dat OpenGL 4 veel meer op OpenGL ES 2 lijkt, enorm uitgekleed dus en niet meer backwards compatible (wat je zelf ook al zegt dus).

Ja, maar dat moet je dus heel letterlijk nemen. Ze hebben gewoon een aantal functies geschrapt.
Bij Direct3D krijg je echt om de zoveel tijd een compleet nieuwe API. Direct3D10 lijkt in de verste verte niet op Direct3D9. Wat ook logisch is, de onderliggende hardware lijkt ook totaal niet meer op elkaar. Het is dus mooi als de API op deze manier met de hardware mee-evolueert. En dat doet OpenGL niet.
Daarom zijn sommige dingen op een enorm lelijke manier in de API erbij gehackt, en sta je ook vaak voor verrassingen... De API en de extensies zijn zo vaag gespecificeerd dat de ene fabricant nog wel eens een heel ander idee heeft over hoe het geimplementeerd moet worden dan de ander.
Code die perfect werkt voor vendor A, kan enorm traag zijn op vendor B, of compleet verkeerde resultaten opleveren.
Dat soort dingen gebeurt niet in Direct3D, omdat Microsoft zelf de implementatie van de API levert, en de shader compiler etc.

Visual Studio en icc genereren code die in sommige gevallen zomaar 20% sneller is.

In het geval van Valve kun je het ook omdraaien: de Windows-versie van bv Left 4 Dead 2 is uit 2009.
Dat zal dan waarschijnlijk met VS2008 gebouwd zijn, of misschien zelfs nog ouder. Dan loop je dus minstens 2 generaties achter (VS2010, VS2012), terwijl ze wel vergelijken met een van de nieuwste gcc's, waarschijnlijk.

[blouweKip]

Tja, als je een OS met een zeer oude opengl versie gebruikt (en dan ook nog eens amd) dan kun je ook niet beter verwachten.
Op linux met normale drivers is de opengl ondersteuning gewoon zeer goed.
Natuurlijk heeft windows op dit moment nog voordelen: dat zijn echter geen van alle OS-inherente voordelen: ze hebben alle met verregaande optimalisaties van 3th party ontwikkelaars te maken: een situatie die nu ook langzaam in een stroomversnelling komt op linux.

In een toekomst waar je als developer voor een toenemende hoeveelheid (mobiele)apparaten wilt kunnen ontwikkelen is het gewoon beter om opengl te gebruiken dan direct3d (ondanks het feit dat er ook goede dingen in direct3d zitten heeft het 1 grote flaw: singleplatform).
Die hernieuwde populariteit is volgens mij ook de primaire reden naast steam dat er nu meer developers naar linux komen: omdat in hun engines steeds meer met opengl gedaan wordt waardoor de marginale kosten van een port zeer laag zijn

[Verwijderd]

In een toekomst waar je als developer voor een toenemende hoeveelheid (mobiele)apparaten wilt kunnen ontwikkelen is het gewoon beter om opengl te gebruiken dan direct3d (ondanks het feit dat er ook goede dingen in direct3d zitten heeft het 1 grote flaw: singleplatform).

Nee, zeker niet.
Je gebruikt gewoon Direct3D wanneer dat voorhanden is, omdat je dan veel meer hardware ondersteunt, en veel minder problemen hebt met vage driverbugs etc (natuurlijk moet je sowieso D3D gebruiken voor Windows Phone, want daar is geen OpenGL).
Op consoles gebruik je ook de native API/bare metal.
OpenGL gebruik je alleen als het niet anders kan.

Op Windows blijf ik dus gewoon Direct3D gebruiken, ook al heb ik ook een OpenGL codebase die op Windows draait. Met de D3D code ondersteun je gewoon veel meer hardware, met betere performance en meer features.
Dat is dus *wel* een OS-inherent voordeel van Windows.

[blouweKip]

Ok, kleine edit: hangt er dus vooral van de developer af en het platform waar hij voor ontwerpt.

[Amanoo]

Ik zie een aanleiding voor Tweakers.net om eens leuke professionele benchmarks omtrent dit in elkaar te draaien.

[Reactie gewijzigd door Amanoo op 22 juli 2024 14:50]

[tuXzero]

Je moet ook niet vergeten dat Valve samen met de hardware fabrikanten heeft samengewerkt om de drivers voor Linux te optimaliseren. Dat zij met geoptimaliseerde / verbeterde drivers hebben gewerkt kan natuurlijk ook het verschil verklaren.

[Gps4l]

Dat verhaal van Valve hoef je niet met een korrel zout te nemen.
Wat niet naar voren komt in wat ik aan haal, is dat ook nvidia meer gewerkt heeft, en die dus het openGL gedeelte van hun driver ook verbetert heeft.
Dat is dus niet een driver die wij kunnen dowloaden.

Ik ben Valve dus ook heel dankbaar dat we op Linux, naast de games, echt goede (en vooral snellere) drivers gaan krijgen.

In de Linux wereld werd altijd geroepen, niemand gamed op Linux.
Er was dus ook geen behoefte aan echt snelle drivers.
Een andere mythe was dat mensen die Linux gebruiken, niet willen betalen voor software.
Valve heeft dit veranderd.

[HerrPino]

OpenGl is sneller dan DirectX. Dat dit er in de praktijk niet (nog? ) uitkomt ligt aan de drivers.

?? Dus het ligt aan de drivers? Hoe kun je dan zeggen dat OpenGL sneller is, omdat jouw gevoel dat zegt? Dus je wil zeggen dat aan de OpenGL drivers incompetente mensen werken en dat de DirectX drivers de ultieme snelheid bereiken omdat die drivers tot op het bot geoptimaliseerd zijn en absoluut niet verder geoptimaliseerd kunnen worden?

Er valt eigenlijk helemaal niets over te zeggen. OpenGL en DirectX zijn compleet anders qua API. OpenGL is procedureel en DirectX is OO. Als je liever een OO api gebruikt als basis dan gebruik je DirectX. Gebruik je liever een procedurele api dan gebruik je OpenGL. Volgens mij is het eigenlijk zo simpel als dat.

[FlyEragon]

Tof voor de Linux gamers, maar klopt het plaatje wel ? Far Cry 3 is toch door Ubisoft gemaakt ?

[Gijs007]

Klopt, alleen de eerste Far Cry is door Crytek gemaakt en uitgegeven door Ubisoft.
De overige Far Cry games zijn door Ubisoft gemaakt.

Crytek port dus de engine van Crysis naar Linux en niet de engine van Far Cry...

[Reactie gewijzigd door Gijs007 op 22 juli 2024 14:50]

[Tijn89]

Ind een treurige keuze gezien Far Cry 3 weinig meer te maken heeft met Crytek of haar cryengine:


The Dunia Engine is a game engine designed by Kirmaan Aboobaker while working at Crytek. It is based on the CryEngine but was heavily modified by the Ubisoft Montreal development team for use in Far Cry 2.
Far Cry 3 is the first game to use a new version of the engine called Dunia Engine 2.
http://en.wikipedia.org/wiki/Dunia_Engine

Hoeveel er nog over is van de eerste code is maar de vraag...

[SG]

Nou, het is gewoon een branch een fork van de crytech engine. Die devs shermen altijd met heavenly modified. Dat is meer imago om te laten weten dat ze competent zijn en geen game engine as is gebruiken.
Als ze nou aangeven wat voor percentage van de source code zelf ontwikkeld is exclusief alle refactoring. Want variable hernoemen of code schuiven met exact diezelfde funcionaliteit is geen heavenly modified.

Heb toch het gevoel dat er veel nog van de basis er in zit. Wetende dat zoon uitgebreide game enine uit heel veel componenten bestaat. En veel daarvan ook niet vernieuwd hoeft te worden. Als je de C4 engine software architectuur diagram zie dan is 3 tot 9 dozijn aan componentjes groot en klein heel normaal.

Een dev die vooral zelf door de jaren heen game engine ontwikkeld is er wat meer open over.Zoals John Carmack En zegt ook dat de nieuwere IDtech nog wat source code hebben van veel oudere engines.

Want in de wereld van software enginering is gaat men niet voor de lol het wiel weer eens opnieuw uitvinden.
Het is eerder als de component niet voldoet aan de feature eisen dat een component aangepast wordt naar de nieuwe feature set en feature eisen.

[markdm]

ik vond het al raar dat er een afbeelding van far cry 3 staat. Die heeft niks te maken met crytek, tweakers kon beter een afbeelding van crysis pakken, ziet er ook leuk uit.

edit: is zo te zien al aangepast

[Reactie gewijzigd door markdm op 22 juli 2024 14:50]

[Verwijderd]

Klopt. Crytek was niet bij de ontwikkeling van Far Cry 2 en Far Cry 3 betrokken. Die draaien ook niet op de CryEngine maar op Dunia.

[-Colossalman-]

is één programmeur niet wat weinig? ik heb zelf geen recente ontwikkel ervaring, maar dat lijkt me toch wel een hele klus.

[johnbetonschaar]

Iemand die serieuze ervaring heeft met OpenGL, DirectX, high-end graphics, en Windows/Linux development tools zou het volgens mij best in zijn eentje voor elkaar moeten kunnen krijgen om een dergelijke engine in redelijke tijd te porten naar Linux. Zeker als de engine enigszins fatsoenlijk geprogrammeerd is en niet vol zit met niet-compliant C++ code die alleen Visual Studio vreet. Beetje nette C++ code van Windows naar gcc porten is niet zo spectaculair. Het meeste werk zal in de DirectX render paths zitten die dan naar OpenGL moeten worden omgeschreven, maar ook dat zou ged te doen moeten zijn, shaders zijn bijna zonder aanpassingen over te zetten, en daar gebeurt toch bijna alles tegenwoordig.

[Verwijderd]

De C++ code zal het problem niet zijn. De engine draait ook op de PS3, waar gcc gebruikt wordt.

[Amanoo]

Er is een kans dat ze een programmeur willen die wat meer kennis heeft van Linux en hiermee makkelijker andere programmeurs kan sturen, of misschien hebben ze al redelijk wat programmeurs die hun Linux kennen en willen ze graag nog net een klein beetje meer mankracht. Het is niet gezegd dat die ene persoon nu de opdracht krijgt in zijn eentje hele games voor Linux in elkaar te draaien.

[svennd]

Van games is nog niet meteen sprake lijkt me, het gaat voornamelijk over de engine; Ik veronderstel dat de games voor een groot deel een layer bovenop de engine zijn, die eigenlijk per definitie reeds grotendeels cross-compatibel zijn; Gezien die games toch ook op consoles uitkomen en o.a. Sony's PS3 toch op een BSD/Linux structuur is gebouwd.

[Wolfos]

Nee, dat is niet te weinig. Ook Unreal Engine 3 is door een persoon naar Linux en OSX geport.

[goarilla]

Ryan Gordon I presume ?

[Electromonkey]

Ik meen ooit is ergens gelezen te hebben dat grafische kaarten veel beter presteren onder Linux omdat deze geen gebruik zou maken van DirectX. Daarmee werd dus bedoeld dat DirectX erg inefficient te werk zou gaan met de rekenkracht van een grafische kaart. Iemand die hier wat meer van weet?

On topic: Goed nieuws! Ik draai naast Mint alleen Windows omdat het moet voor games, kan dit dan ook alleen maar toejuigen

[blouweKip]

In de praktijk wordt er helaas vaak nog teveel gebruik gemaakt van direct3d en ook vooral teveel geoptimaliseerd in die richting, hierdoor is de opengl performance van veel engines niet echt optimaal.
Als je ziet dat je met suboptimale drivers in linux met opengl vaak al rond de performance van windows icm opengl zit dan valt er nog veel te winnen, windows is gewoon niet echt een ideaal OS voor games alleen heeft microsoft de boel heel succesvol kunnen vendor-locken door middel van direct3d (wat ook de primaire reden voor het bestaan van die api is imho).

De laatste tijd merk ik dat ik eigenlijk zelden meer naar windows boot, ik koop ook alleen nieuwe releases met multiplatform support en de rest laat ik mooi aan me voorbij gaan (vanwege de consoles is het aantal kwaliteits games ook flink aan het afnemen dus echt veel is er ook niet meer te koop)

[Reactie gewijzigd door blouweKip op 22 juli 2024 14:50]

[Verwijderd]

windows is gewoon niet echt een ideaal OS voor games

Ideeal is een heel lightweight OS, of eigenlijk vrijwel geen OS, zoals bij consoles. Maar dat is natuurlijk voor een general purpose OS niet realistisch.

Verder is Windows met afstand het beste OS voor games. De samenwerking tussen 3D API/drivers, GUI, en kernel gaat veel verder dan op bv linux. Windows kan een fullscreen-applicatie heel aggressief schedulen, en de hele desktop manager stilleggen.
Bij een OS als linux hangt alles meer als los zand aan elkaar. De kernel weet niet echt wat een applicatie aan het doen is, en kan daarom minder aggressief schedulen (afgezien van het feit dat linux sowieso niet uitblinkt in low-latency wat dat aangaat). En de GUI is dan weer als een apart server-proces geimplementeerd, waar dan weer libraries tegenaan praten uit een ander process... En daar haakt OpenGL dan nog ergens op in (in OpenGL is er niet eens zoiets als een exclusieve fullscreen mode)...

Nee, dat doet Windows een HEEL stuk beter. Dat verklaart ook waarom multiplatform benchmarks als Unigine nog steeds veel beter draaien op Windows dan op OS X of linux.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:50]

[blouweKip]

Nee, dat doet Windows een HEEL stuk beter. Dat verklaart ook waarom multiplatform benchmarks als Unigine nog steeds veel beter draaien op Windows dan op OS X of linux.

Toch, het is nog niet zo eenvoudig vast te stellen waar deze verschillen nu echt inziiten, als ik bijvoorbeeld zie dat een tijdje terug bij unengine maar marginale verschillen zaten tussen de verschillende scores (opengl natuurlijk) dan kan dit nog steeds aan de drivers of api gerichte optimalisaties zitten.
Overigens snap ik best dat windows naast alle externe support ook voordeel haalt uit de hechtere intergratie tussen de verschillende onderdelen (al zie ik daar niet veel van in osx bijvoorbeeld), dat is iets waar linux een nadeel kan hebben.
Ik ben benieuwd in welke mate dat nu effect heeft tov eventuele optimalisatie van drivers of applicaties.

Gezien het feit dat consoles de mogelijkheden van games tegenwoordig dicteren is performance overigens steeds minder van belang, ik merk dat ik er in ieder geval weinig last van heb als ik op linux speel, al is de performancehit met wine af en toe nog best groot (maar ja, dat is logisch)

[Verwijderd]

Toch, het is nog niet zo eenvoudig vast te stellen waar deze verschillen nu echt inziiten

Zo moeilijk is het niet hoor.
Als je gewoon nette OpenGL code schrijft, met voor ieder platform nette initialisatie van de context en windows etc (ipv standaard-meuk als GLUT of SDL ofzo, dat voor sommige platforms nogal gammel in elkaar zit), en je compileert dat met dezelfde compiler, dan zijn alle gemeten verschillen dus het gevolg van verschillen in OS/kernel/drivers.

Zeker bij nVidia kun je vrij mooie apples-to-apples vergelijkingen doen, omdat hun OpenGL-drivers op alle platforms grotendeels dezelfde code gebruiken, en dus gelijk lopen qua versie, qua features, en qua implementatie.

Op OS X kun je ook nog eens leuk het verschil meten tussen een 'lelijke' port van OpenGL code, die op X11 draait, en een 'nette' port, die Apple's eigen GLUT gebruikt met Quartz. Dat laatste is een stuk sneller.

Paar jaar terug een testje gedaan met m'n OpenGL code op een Mac met GeForce GTX460:

Windows 7 Home Premium 64-bit, 32-bit exe: ~6150 FPS
Windows 7 Home Premium 64-bit, 64-bit exe: ~6400 FPS
Mac OS X 10.6.8 X11/64-bit: ~3000 FPS
Mac OS X 10.6.8 Native/64-bit: ~5400 FPS

De Direct3D-variant deed overigens zo'n 9000 FPS als ik me goed herinner.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:50]

[wpoely86]

Bij een OS als linux hangt alles meer als los zand aan elkaar. De kernel weet niet echt wat een applicatie aan het doen is, en kan daarom minder aggressief schedulen (afgezien van het feit dat linux sowieso niet uitblinkt in low-latency wat dat aangaat). En de GUI is dan weer als een apart server-proces geimplementeerd, waar dan weer libraries tegenaan praten uit een ander process... En daar haakt OpenGL dan nog ergens op in (in OpenGL is er niet eens zoiets als een exclusieve fullscreen mode)...

Waarom zou alles als los zand aan elkaar hangen? Het is niet een monolitische blob zoals in Windows maar bv mesa en de kernel hangen heel nauw samen.
En wat denk je dat het interessante is in deze tijd van multicore systemen? Alles in 1 proces of opsplitsen? Het is niet omdat het aparte libraries zijn dat je systeem trager zou draaien, eenmaal in het geheugen geladen ga je geen verschil merken maar je krijgt er een enorme flexibiliteit boven.

Tegenwoordig kan een proces ook perfect een hoger priority aanvragen aan de schedular (zie bv rtkit)

Nee, dat doet Windows een HEEL stuk beter. Dat verklaart ook waarom multiplatform benchmarks als Unigine nog steeds veel beter draaien op Windows dan op OS X of linux.

Ik ken die benchmarks niet maar een verschil kan evengoed aan een specifieke optimalisatie liggen.

[Verwijderd]

Waarom zou alles als los zand aan elkaar hangen?

Omdat dat zo is.
De linux-kernel had vroeger helemaal geen weet van de UI. Een tijdje terug zijn er wat dingetjes geintroduceerd zodat UI-processen iets efficienter gescheduled kunnen worden: http://www.phoronix.com/s...em=linux_2637_video&num=1
Maar het blijft toch meer in de 'los zand'-categorie hangen dan bv Windows.
Bij Windows is er bv een directe link tussen dingen als keyboard/muis-input en de thread scheduler: Als er een keyboard/muis-event binnenkomt, geeft Windows een boost aan de thread met het actieve window, waar die events dus verwerkt moeten worden.

Het is niet omdat het aparte libraries zijn dat je systeem trager zou draaien, eenmaal in het geheugen geladen ga je geen verschil merken maar je krijgt er een enorme flexibiliteit boven.

Dat beweerde ik ook niet. Het ging mij erom dat er tussen de onderlinge onderdelen niet zo veel samenwerking is, zie bv voorbeeldje hierboven.

Tegenwoordig kan een proces ook perfect een hoger priority aanvragen aan de schedular (zie bv rtkit)

Dat is iets anders dan dat je een bepaalde thread een tijdelijke boost geeft om input te verwerken. Vooral het 'tijdelijk', daar gaat het om.

Kortom, bestudeer zelf de materie eens een beetje, dan zul je zien wat 'los zand' betekent.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:50]

[wpoely86]

Omdat dat zo is.
De linux-kernel had vroeger helemaal geen weet van de UI.

Linux heeft een ander ontwikkel model dan windows of FreeBSD dat idd niet centraal gestuurd is maar dat is nog altijd geen los zand. Het hele systeem zou ook moeilijk kunnen werken als elk onderdeel volledig los en apart zou worden ontwikkeld. Het is niet omdat er een manager bovenaan ontbreekt dat er geen samenwerking zou zijn.

Dat de kernel geen weet heeft van de UI lijkt me maar logisch. Dat een bepaalde process (toevallig de UI) een hoger priority kan vragen dan een ander is wel logisch. De kernel draait ook op talloze systemen zonder GUI in tegenstelling tot Windows.

Dat de schedular niet optimaal is om te gamen, dat kan ik wel aannemen. Ik betwijfel of dat 1 van de use case is die de kernel devel's gebruiken.

Dat is iets anders dan dat je een bepaalde thread een tijdelijke boost geeft om input te verwerken. Vooral het 'tijdelijk', daar gaat het om.

Wel? Niks hou je tegen om je input thread met dbus rt te maken en nadien weer ongedaan te maken?

[Verwijderd]

Linux heeft een ander ontwikkel model dan windows of FreeBSD dat idd niet centraal gestuurd is maar dat is nog altijd geen los zand.

Een stuk losser dan Windows in ieder geval.

De kernel draait ook op talloze systemen zonder GUI in tegenstelling tot Windows.

Windows Server kan ook al een aantal jaren zonder GUI gedraaid worden hoor.

Wel? Niks hou je tegen om je input thread met dbus rt te maken en nadien weer ongedaan te maken?

Okee, je begrijpt het duidelijk niet.
Als er user input binnenkomt, dan is het de kernel/driver die dat het eerste weet (hardware genereert interrupt, driver heeft via de kernel een interrupt handler geregistreerd). Daarna bubbelt dat event via driver/kernel/libraries omhoog totdat het uiteindelijk bij jouw input thread terecht komt.
Jouw input thread is dus letterlijk de laatste die hoort dat er input binnen was gekomen. Tegen die tijd is het dus ook al te laat om de thread een hogere prio te geven, je thread *is* op dat moment al gescheduled, en je hebt je input al binnen.Je thread boosten om sneller de input binnen te krijgen kan dus niet meer, je kunt niet meer terug in de tijd.

Wat Windows doet, is bij een event direct de juiste thread een priority boost te geven, waardoor ie dus zo snel mogelijk het event afhandelt (lagere latency dus). Dit gedrag is overigens ook uit te zetten, want voor bv servers is het niet altijd wenselijk, en heb je liever een 'fair' scheduler.

Afgezien van het feit dat rommelen met dbus veel te veel overhead heeft voor dit soort micro-management, is het dus ook nog eens niet mogelijk om dit te doen. Het MOET dus in de kernel ingebouwd zitten.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:50]

[wpoely86]

Okee, je begrijpt het duidelijk niet.
Als er user input binnenkomt, dan is het de kernel/driver die dat het eerste weet. Daarna bubbelt dat event via driver/kernel/libraries omhoog totdat het uiteindelijk bij jouw input thread terecht komt.
Jouw input thread is dus letterlijk de laatste die hoort dat er input binnen was gekomen. Tegen die tijd is het dus ook al te laat om de thread een hogere prio te geven, je thread *is* op dat moment al gescheduled, en je hebt je input al binnen.Je thread boosten om sneller de input binnen te krijgen kan dus niet meer, je kunt niet meer terug in de tijd.

Ik dacht eerder aan een aparte input thread die permanent rt heeft. Bij een game lijkt me dat logisch.

Afgezien van het feit dat rommelen met dbus veel te veel overhead heeft voor dit soort micro-management, is het dus ook nog eens niet mogelijk om dit te doen. Het MOET dus in de kernel ingebouwd zitten.

Ik ken windows absoluut niet goed maar dat zou betekenen dat de compositor in de kernel moet zitten want enkel de compositor kan weten voor wie de input is en welk process verantwoordelijk is voor dat window. Je zou in Linux dus X moeten integreren in de kernel en dat gaat gelukkig nooit gebeuren. En met goede reden.

[Reactie gewijzigd door wpoely86 op 22 juli 2024 14:50]

[Verwijderd]

Ik dacht eerder aan een aparte input thread die permanent rt heeft. Bij een game lijkt me dat logisch.

...
Bij mij niet?
Bij een game is de framerate bepalend voor hoe snel je input kunt verwerken. Je hoeft dus alleen maar aan het begin van een nieuw frame even de eventuele nieuwe input binnen te halen.
Als er tijdens de processing/rendering van dat frame nog nieuwe input binnenkomt, kun je er toch niks mee.
Pure verspilling van resources om daar een extra thread voor te bouwen.

Ik ken windows absoluut niet goed maar dat zou betekenen dat de compositor in de kernel moet zitten want enkel de compositor kan weten voor wie de input is en welk process verantwoordelijk is voor dat window.

Dat kun je makkelijk abstraheren hoor.
Hoezo zou een hele compositor (ik denk eerder dat je window manager bedoelt, maargoed) in de kernel moeten zitten?
Ooit gehoord van microkernels?
Zolang je maar aan de kernel kunt aangeven welke thread voor welk event een boost moet krijgen, hoeft de kernel verder niets te weten van wat zo'n thread doet, of wat dat event betekent.

Je zou in Linux dus X moeten integreren in de kernel en dat gaat gelukkig nooit gebeuren. En met goede redden.

Nee, linux zou meer kernel-functionaliteit moeten krijgen waarmee dit soort mechanismen te implementeren zijn. Zoals je ziet, is men daar min of meer wel mee bezig, maar het is wel een beetje lachwekkend dat dat nu nog in de kinderschoenen staat. Bij Windows NT zit het er al sinds de eerste versies in.

Nou ja, dat het er niet in zit, dat is nog tot daar aan toe. Maar dat de mensen die roepen dat linux zo'n geweldig desktop/gaming-OS is, niet eens een idee hebben van dit soort simple mechanismen, dat is wel schraal.

[wpoely86]

Bij mij niet?
Bij een game is de framerate bepalend voor hoe snel je input kunt verwerken. Je hoeft dus alleen maar aan het begin van een nieuw frame even de eventuele nieuwe input binnen te halen.
Als er tijdens de processing/rendering van dat frame nog nieuwe input binnenkomt, kun je er toch niks mee.
Pure verspilling van resources om daar een extra thread voor te bouwen.

Dan maakt die boost aan de thread toch weinig uit? Het is zelfs verspilling? Als het game op dat moment toch geen input uitleest? Je input lag is dan bepaald door de framerate die je gpu kan draaien? *

* Ik ken werkelijk niks van games programmeren

Nee, linux zou meer kernel-functionaliteit moeten krijgen waarmee dit soort mechanismen te implementeren zijn. Zoals je ziet, is men daar min of meer wel mee bezig, maar het is wel een beetje lachwekkend dat dat nu nog in de kinderschoenen staat. Bij Windows NT zit het er al sinds de eerste versies in.

Nou ja, dat het er niet in zit, dat is nog tot daar aan toe. Maar dat de mensen die roepen dat linux zo'n geweldig desktop/gaming-OS is, niet eens een idee hebben van dit soort simple mechanismen, dat is wel schraal.

Die patch waar jij naar verwijst is nog iets anders kan een thread boosten. Die patch steekt een hele tty in een task cgroup. De schedular kan dan mooi verdelen tussen de verschillende cgroups. Dat werkt enkel als je als je proces mooi kunt verdelen over schillende tty's. Dat helpt dus niet echt in het geval van games.

Wat wel leuk zou kunnen zijn is als je de compositor (de meesten onder ons draaien tegenwoordig een compositing window manager) zo ver zou kunnen krijgen om dynamisch de threads van de zichtbare windows in een aparte cgroup te steken die een wat hogere cpu share krijgt. Dat kan zelfs niet zo moeilijk zijn om te doen in gnome-shell, denk ik.


Als gaming-OS weet ik het niet (ik speel te weinig) maar als desktop-OS is Linux best wel aangenaam. Ik wil niet meer terug naar windows, ik zou mijn terminal te veel missen.

[Verwijderd]

Dan maakt die boost aan de thread toch weinig uit? Het is zelfs verspilling?

De *thread* is verspilling. Threads vreten resource, hoe minder threads, hoe beter.

Je input lag is dan bepaald door de framerate die je gpu kan draaien?

Nee, latency is iets anders dan frequentie.

Die patch waar jij naar verwijst is nog iets anders kan een thread boosten.

Iets beter de discussie lezen. Ik gaf aan dat Windows een betere integratie heeft tussen UI en de rest van het system, en noemde daarvan wat voorbeelden.
Ik heb niet beweerd dat:
1) Alle voorbeelden ook op toepassing zijn van games (slechts op desktop in de bredere zin).
2) Dat de gelinkte Linux-patch hetzelfde is als een voorbeeld noemde. Ik gaf slechts aan dat men in de linux-wereld aan het probleem werkt (waardoor het bestaan van het probleem dus is aangetoond).

Wat wel leuk zou kunnen zijn is als je de compositor (de meesten onder ons draaien tegenwoordig een compositing window manager)

Een compositor is een ding dat twee of meer windows samenvoegt ('to compose'). Da's dus slechts het deel dat grafische handelingen uitvoert.

als desktop-OS is Linux best wel aangenaam

Ja, da's vooral het gevolg van de commoditization van hardware.
Zelfs de meest simpele PC is totale overkill voor een simpele desktop, ook al is die niet zo efficient.
Problemen in linux komen dan ook vooral als je hard aan het multitasken bent (probeer eens iets te compileren met al je cores tegelijk). Dan kun je soms secondenlang wachten totdat een window op een muisklik reageert. In dat soort scenarios zul je gauw doorkrijgen wat een meerwaarde Windows heeft voor de desktop, met z'n handige priority boosts en dergelijke.

[goarilla]

Windows kan een fullscreen-applicatie heel aggressief schedulen, en de hele desktop manager stilleggen.
Bij een OS als linux hangt alles meer als los zand aan elkaar. De kernel weet niet echt wat een applicatie aan het doen is, en kan daarom minder aggressief schedulen (afgezien van het feit dat linux sowieso niet uitblinkt in low-latency wat dat aangaat). En de GUI is dan weer als een apart server-proces geimplementeerd, waar dan weer libraries tegenaan praten uit een ander process... En daar haakt OpenGL dan nog ergens op in (in OpenGL is er niet eens zoiets als een exclusieve fullscreen mode)...

Nooit gehoord van nice/renice ? En Windows heeft ook een displayserver hoor. Immers wie voorziet de applicaties van de nodige Window messages ?

[Verwijderd]

Nooit gehoord van nice/renice ?

Dat is HEEL wat anders. Dat is gewoon statisch de thread-prioriteit aanpassen. Ik heb het over *dynamische* aanpassing, op basis van events (gebeurtenissen op kernel-niveau).
Waarom begrijpt niemand dit? Zo moeilijk is het toch niet?
Hier, mooie uitleg op MSDN: http://msdn.microsoft.com...op/ms684828(v=vs.85).aspx

•When a process that uses NORMAL_PRIORITY_CLASS is brought to the foreground, the scheduler boosts the priority class of the process associated with the foreground window, so that it is greater than or equal to the priority class of any background processes. The priority class returns to its original setting when the process is no longer in the foreground.
•When a window receives input, such as timer messages, mouse messages, or keyboard input, the scheduler boosts the priority of the thread that owns the window.
•When the wait conditions for a blocked thread are satisfied, the scheduler boosts the priority of the thread. For example, when a wait operation associated with disk or keyboard I/O finishes, the thread receives a priority boost.
You can disable the priority-boosting feature by calling the SetProcessPriorityBoost or SetThreadPriorityBoost function. To determine whether this feature has been disabled, call the GetProcessPriorityBoost or GetThreadPriorityBoost function.

After raising a thread's dynamic priority, the scheduler reduces that priority by one level each time the thread completes a time slice, until the thread drops back to its base priority. A thread's dynamic priority is never less than its base priority.

En mensen dan nog roepen dat Windows niet gedocumenteerd is (want het is closed-source...?).
Het staat er gewoon, je moet natuurlijk wel even de moeite doen om het op te zoeken, te lezen en te begrijpen.

En het staat er duidelijk: de *scheduler* doet dit. Niet de gebruiker, niet de applicatie (dus niet nice/renice zelf aanroepen), maar de scheduler.

En Windows heeft ook een displayserver hoor. Immers wie voorziet de applicaties van de nodige Window messages ?

Niet een server in de zin van een proces dat via een netwerkverbinding werkt (en ja, tegenwoordig kunnen sommige X11-implementaties het ook via shared memory).
In Windows wordt het dan ook geen 'server' genoemd (want dat is het niet), maar een window manager.

De messages worden overigens via algemene message queues verstuurd. Een thread hoeft niet per se een window te hebben om een message queue te hebben. Het mechanisme is dus globaler dan alleen de GUI/window manager. Wat dus weer aangeeft hoe bij Windows de GUI netter aansluit op de onderliggende kernel en het daarbij behorende threading/messaging systeem.
In X11 wordt er een eigen messaging systeem geintroduceerd, dat los staat van de rest van het system: los zand.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:50]

[Gijs007]

Dat is volgens mij onzin aangezien er games zijn voor Windows die ook onder Linux draaien.
Hierbij draaien ze vaak beter onder Windows dan Linux (komt door de slechtere 3D driver ontwikkeling voor Linux t.o.v. Windows, maar hier zal wel verandering inkomen als er meer games voor Linux uitkomen)

Daarnaast kun je onder Windows soms kiezen tussen opengl en Directx, waarbij Directx vaak net iets sneller is.
Dus als dit echt het geval zou zijn dan werden veel meer games in Opengl ontwikeld inplaats van Directx.

[MrAmos]

Ik meen mij te heugen dat valve op heel andere dingen uitkwam dan jij hier beweert..

Op een windows systeem: 270 (Direct-X)/ 303 (OpenGL)
Op een linux systeem: 315 (OpenGL)

Oke, onderaan staat er in het artikel inderdaad dat DirectX sneller moet kunnen, maar wat jij zegt vind ik niet kloppen als ik kijk naar dit artikel, eigen ervaringen
(bron)
[url]http://http://tweakers.net/nieuws/83505/left-4-dead-2-sneller-onder-opengl-dan-onder-direct3d.html[/url]


Verder kan ik dit als linux fan alleen maar toejuichen..

[acemoo]

De windows versie was al best oud. De linux versie was volledig geoptimaliseerd en ze dachten dat ze de windows versie ook sneller konden krijgen.

[SG]

Nou het klopt valve heeft veel werk gestopt in opengl het liep ervoor al dikkestront. Nu zelfs beter dan windows. Maar ook opengl drivers onder windows lopen door valve beter.
Daarnaast loopt de engine van source al lang achter op andere game engines. Dus die games zijn niet zo veel eisend en leunen sterk op cpu en dat is drivers.

NVidia en AMD gpu driver team optimaliseren met profielen voor de populairste high profile games met game profielen.

Met elke driver release lopen de populairte moderne games weer stuk sneller op windows met direct X.

Directx vanaf dx10 dus vanaf Vista waarbij de kernel en driver model en directx api op de schop genomen is. Kan beter getest wirden met directx11 games en opengl 4,2.

Dan ouwe spul vn valve dat op niveau van de huidige consoles uit 2006 2007 stamt.

Moderne games die mij aanspreken is.

Stalker c.o.p
Metro series

Als de crytech engine overgaat naar linux dan kunnen we eindelijk moderne games die gebruik maken van de laaste render API de resultaten zien.

[goarilla]

Wow de volle ~ 3.9 % sneller.

[sfranken]

Dat ze slecht(er) draaien ligt vaak aan het feit dat de uitgevers lui zijn en "ff snel" een slechte port in elkaar gooien.

[Blokker_1999]

reeds in de jaren 90 draaiden games zoals UT en Q3A sneller onder Linux dan onder Windows. En ook Valve heeft tijdens het porten van L4D2 gemerkt dat het spel, ondanks de toenmalige test status van de code, sneller draaide onder Linux dan onder Windows. Daarbij moest wel aangemerkt worden dat er voor Linux optimalisaties werden gebruikt die ook weer gebackport konden worden naar Windows waardoor ook onder Windows de performance terug zou kunnen stijgen.

De reden waarom men veel voor DX kiest is simpelweg omdat dit platform enorm uitgebreid is. Niet alleen vereenvoudigd dit het portwerk tussen PC en Xbox, ook bied DX APIs voor geluid, netwerk, joystick, ... Onder linux moet je alles zelf bij elkaar puzzelen met OpenGL, OpenAL, ... hoewel je de laatste jaren bijvoorbeeld al wel merkt dat meer en meer devs delen van DX links laten liggen en het nog hoofdzakelijk gebruik vanwege D3D wat dus op zich wel vervangen kan worden door OpenGL

[madcow22]

Microsoft heeft zo ongeveer support gedropt voor alles behalve de direct3d api. Direct x is volgens veel devs gewoon een betere api dan opengl wat vooral kwam door zeer trage vooruitgang van opengl.
Met l4d2 draaide nog op directx 9 volgens mij microsoft heeft in 10 en 11 ook zeer uitgebreide api updates gedaan wat het veel sneller maakt.

[SG]

Directx is door de jaren heen ook verder ontwikkeld.

Opengl was beter vs dx2 tot dx6.
Directx 9 is nu ook ouwe API met ouwe windows XP os op 32 bit.

Als gamer kijk ik nasr de huidige stand van zaken. En dat is dx10.1 en hoger. Vs opengl 4.x.

Dat een game uit quake serie 1000++ fps draai is niet meer zo relevant.

Directx vanaf dx10.1 is ook een API verbetering tov vorige. Ook dev gerichter.

John Carmack zou in heden voor directx gaan ipv opengl.

Hou ook rekening mee dat performance niet altijd voor op staat.
De keuze voor scriptengine vs hardcoded is een enorme performance drop.
Dus ook de ease of development en productieve effeciente content pipeline is van heel groot belang.

[rob12424]

das geen onzin. Het zit wel anders in elkaar. Linux is van oorsprong server systeem. Dit zorgt er voor dat api calls soms sneller en anders worden afgewerkt (hoe het precies zit weet ik ook niet)

Wine kan daardoor dingen soms sneller doen dan windows zelf kan.Het is dus waar, maar niet altijd! En heeft niet specifiek met video te maken! Het ligt dus ook niet specifiek aan opengl of directx.

[bstard]

De tijd dat een spel in 1 versie uitkwam is lang verleden tijd. Mac's, consoles in diverse smaken, Linux, Windows, mobieltjes.. een bedrijf dat nu spellen maakt zorgt er maar beter voor dat het goed en snel portbaar en schaalbaar is. Als dan een illuster clubje als Valve achter Linux gaat staan lijkt het mij heel logisch dat de industrie volgt.

[Verwijderd]

De tijd dat een spel in 1 versie uitkwam is lang verleden tijd.

Is die tijd ooit geweest dan? In de jaren 80 kwamen de meeste spelletjes voor minimaal 3 platforms uit, vaak veel meer. Ik noem een C64, ZX Spectrum, Amiga, Atari ST, MS-DOS, en dan nog de nodige consoles, zoals NES, SNES, MegaDrive en noem maar op.
Neem bv de originele Prince of Persia, aardig lijstje platforms: http://en.wikipedia.org/w...a_(1989_video_game)#Ports

Vanaf midden jaren 90 was het vooral Windows en de consoles-du-jour, zoals PlayStations, XBoxen en Nintendo's.

Games die op meerdere platforms uitkomen is van alle tijden.

[Wolfos]

Maar nooit zoveel als nu. Iedere zelf-respecterende indie developer doet een shotgun approach, en released op z'n minst voor Windows, OSX, iOS en Android.

Vroeger waren er veel meer exclusives.

[svennd]

Prachtig ! Ik hoop dat meer bedrijven de markt zo zien; Ik heb al langer de overstap willen maken naar linux, maar games houden me in Windows; Hoewel Wine erg aantrekkelijk is geworden met de windows 8 fail (IMHO).

[Verwijderd]

Wat is er dan 'fail' aan Windows 8 voor games?
De standaard-rant over de Modern UI gaat niet echt op. Games draaien toch altijd fullscreen met hun eigen interface, dus wat voor soort desktop of andere interface het OS normaal gesproken gebruikt, is niet relevant.

Qua compatibiliteit en performance valt er op Windows 8 weinig aan te merken. Al je games werken prima, en halen ongeveer dezelfde prestaties als onder Windows 7: http://nl.hardware.info/r...ing-prestaties-vergeleken
Ik zie niet hoe dat Wine ook maar enigszins aantrekkelijk maakt...?
Hooguit is het niet zo aantrekkelijk om op Windows 8 over te stappen als je al Windows 7 draait. Wine is een heel ander verhaal natuurlijk.

[svennd]

Misschien was ik niet compleet duidelijk; Ik werk niet graag met windows 8, bijgevolg zou ik graag de vrijheid krijgen zoals dat in de meeste linux distro's het geval is; Maar games verhinderen mij daarbij;

Het alternatief wine, zoals je aangeeft is verre van perfect, maar komt steeds hoger te staan dankzij de niet leuk werkende interface; vandaar ik ook melde dat dit een persoonlijke opinie was;

[gassie123]

Heerlijk nieuws. Nog even doorgaan zo en ik kan volledig overstappen naar Linux.

[BrutalDave]

Kan nog wel een hele tijd duren voordat het een lucratief platform wordt voor ontwikkelaars.

[Amanoo]

Het is natuurlijk een kip-ei verhaal. Ik game op Windows. Waarom? Ik wil wel Assassin's Creed op mijn Linux zetten, maar Ubisoft wil dat niet. Misschien dat het nog met WINE kan, maar ik heb geen zin in mindere performance, glitches en vooral (mijn grootste pijnpunt wat betreft WINE) Windows problemen die naar Linux worden geport. Vervolgens maakt dit de Linux-markt weer kleiner. Niemand gaat gamen op een platform waarop de games die hij wil spelen niet draaien.

Overigens heb ik wel het idee dat mijn videokaart tegenwoordig meer opdrachten van Linux binnen krijgt dat van Windows, sinds Valve is begonnen om toch het een en ander te porten. Ik had al sinds de geboorte van Jezus toegang tot DOTA, en het nooit gespeeld omdat het geen Linux port had. Ook heb ik een preorder met beta-participatie in War for the Overworld, maar dit is juist HET type game dat ik op Linux zou willen spelen. Zolang de Linux versie nog niet gereleased is heb ik niet eens een behoefte meer om het te spelen. Enkel voor de grote kaskrakers (bijvoorbeeld Bioshock Infinite) wil ik nog een uitzondering maken.

[SG]

Ik kan dit eigenlijk niet zo goed volgen. Waarom die windows haat.
Nu is er zoiets als W8 heeft een flinke dosis gewenning nodig. Maar dat geld vooral voor die laaste OS. Of mag het voornamelijk geen bal kosten. Het krenten gedrag.
Is windows dus vooral pre W8 zoon wan product?

Als gamer gaat het om de games. Platform keuze is meer waar zijn je favo exclusives of iig de meeste daar van die platformen regel je dan.

Zoals bij cosoles is het je kiest voor de games. En waar je favo exclusives zijn.

Nou Wii(u) PS3 xbox360 hebben al hun exclusive die mij trekken als gamer heb ik ze allemaal.
Op PC is de keuze gelukig makkelijk. De bulk van de exclusives is vooral windows.
Mac linux benadeel je eerder zelf. Met je windows fobie. Hebben die iets van exclusive games. Waarschijnlijk wel maar tov windows een extreme verhouding.

Ik zie het zo als vooral gamer ben. Dan heb je voor PC exclusives. Windows.

Als linux fan cq windows hater. Want gezien vanuit gamers perspectief slaat het werkelijk nergens op je zo te beperken

Ik zal waarschijnlijk als gamer. Ook de PS4 & XB_One halen zodra er musthave exclusive zijn die mij aanspreken.

Dus als gamer vind ik de situatie zoals het nu is niet zo slecht. Al zou een dual boot met linux niet zoonproleem zijn. Het zo eerder een probleem zijn als Mac een zooi exclusive zou hebben waar je dus een duur mac PC moet regelen.

Aangezien ik geen retro gamer ben. Genres en thema meer het realistische rendering als voorkeur heeft. En mobiel gamen mij niet zo trekt. Geen tablet of smartphone gamer.
En ook geen indiescene gamer.
Speel vooral de grote titels.

Als gamer gaat het om de games.

[i-chat]

windows haat of gewoon linux voorkeur, apple maat toch ook prima producten al vind ik het bedrijf echt een walgelijk arrogant groepje hufters en zal ik tot in lengte der dagen geen iDingen willen bezitten (leasen lijkt het soms meer op), en windows je roept het zelf al pre-windows 8, maar er zijn ook gewoon mensen die vooruit krijgen en alvast aan linux willen wennen voordat er met windows 9 helemaal niet meer te wrken is, tipje van de sluier, in windows 9 zit echt geen startknop meer, (zelfs niet na die 8.1 update), ze gaan het heus opnieuw proberen en nu gewoon agressiever en 'innovatiever' al zet ik bij dat laatste vooral grote vraagtekens.

als dat de status van het moment is (en het heeft er alle schijn van) snap ik die andere voorkeur eigenlijk vrijwel direct, en daarmee ook de irritatie die een dualboot (enkel maar voor het gamen) oproept.

[Verwijderd]

Als ik het even vanuit de gaming bedrijven bekijk: Bij Linux heb je de mogelijkheid in principe alles zelf te sturen. Tot nu toe was de basis beperkt kwa grafische kaart ondersteuning, maar er lijkt de laatst paar jaren enige verschuiving plaats te vinden. De open-source drivers zijn ondertussen zover dat voor het normale OS gebruikt ze volstaan en de binary drivers zijn soms zelf in staat om betere prestaties te leveren onder Linux.

Ik kan ook nog twee andere redenen noemen waarom gaming bedrijven zich gaan herorienteren: betere ARM ondersteuning voor Linux en betere multi-core ondersteuning. Het grootste gedeelte van de top 500 super computers draait Linux en is uiteraard Multi-core. Die bedrijven hebben miljoenen gestoken in het optimaliseren van multi-core ondersteuning, Microsoft is gewoon te klein om dit in zijn eentje te bereiken. ARM ondersteuning heeft natuurlijk alles te maken met het mobiele platform. Lukt het de combinatie Windows/Intel om terug te komen op de mobiele markt dan geef ik Microsoft nog een kans (Intel overleeft het wel), anders zou ik als Game ontwikkelaar maar heel snel zorgen om je horizon te verbreden.

Het heeft wat mij betreft dus niet zo heel veel met Windows haat te maken, maar het is gewoon een natuurlijk gevolg.

[Verwijderd]

Die bedrijven hebben miljoenen gestoken in het optimaliseren van multi-core ondersteuning

Voor hun specifieke custom-hardware ja. Daar heeft de normale desktop-gebruiker niks aan.

Microsoft is gewoon te klein om dit in zijn eentje te bereiken.

Microsoft heeft anders ook gewoon een supercomputer-variant van Windows: http://www.microsoft.com/hpc/en/us/default.aspx
Doet het op zich niet onverdienstelijk: http://www.tomshardware.c...lf-tsubame-2.0,11643.html

It broke the Petaflop barrier and was on par with Linux at this scale.

ARM ondersteuning heeft natuurlijk alles te maken met het mobiele platform.

Windows ondersteunt al jaren ARM. Eerst met Windows CE/Embedded, nu ook met Windows RT/Phone.
Ontwikkelaars als Epic waren dan ook erg te spreken over Windows RT, omdat ze gewoon hun bestaande Windows/Direct3D11 makkelijk konden porten naar de nieuwe tablets: http://blogs.nvidia.com/b...windows-8-and-windows-rt/

By porting the full engine as opposed to a modified mobile version, NVIDIA and Epic have made it easy for UE3 developers around the world to bring their best content to Windows RT, Windows 8 and NVIDIA’s Tegra 3 processor.

Voor een iOS of een Android moet je toch je code herschrijven van gewone OpenGL naar OpenGL ES (als je al een OpenGL engine had... als je Direct3D hebt, zoals de meeste game engines, wordt het nog lastiger natuurlijk).
Ik heb zelf m'n Direct3D11 engine ook een paar weken terug naar Windows Phone geport, voor de grap (op ARM dus). En inderdaad, het stelt weinig voor. De engine-code op zich kun je 1:1 gebruiken. Het ging meer om bijzaken die niet goed werkten. Bv, op een telefoon kun je geen shaders van source compilen (wat in 8.1 wel weer geintroduceerd gaat worden, heb ik begrepen), dus moet je ze precompiled meepackagen. En Windows Phone ondersteunt alleen het .dds texture-formaat, dus moet je even je jpgs, pngs etc converteren.
Maar dat stelt allemaal niet zo veel voor. De Direct3D11 API is gewoon letterlijk hetzelfde op Windows Phone als op de desktop, en dat is toch wel heel prettig.

Ik had toch een stuk meer werk aan m'n port van desktop OpenGL naar iOS. Shaders moesten herschreven worden in het OpenGL ES-dialect, en ik gebruikte nog een aantal functies uit OpenGL die in OpenGL ES niet meer bestonden, waardoor ik delen van de pipeline opnieuw moest implementeren met eigen code, en aangepaste shaders.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 14:50]

[Verwijderd]

Ik heb ook niet gezegd dat Windows een slecht platform is. Ik heb alleen de punten genoemd waar Linux sterker is.

Voor hun specifieke custom-hardware ja. Daar heeft de normale desktop-gebruiker niks aan.

De wijzigingen voor custom-hardware brengen idd niets, maar dat zijn niet de enige wijzigingen. Google heeft een tijd lang aan een custom-kernel gebouwd totdat ze door kregen dat het in sync houden met hoofd-branch wel erg veel tijd koste. Daarom hebben ze besloten om de wijzigingen grotendeels door te voeren in de main branch. Multicore support is een belangrijk onderdeel, ook in een cluster. En daar heeft een desktop gebruiker zeker wel wat aan.

Natuurlijk is er ook een windows cluster en je hebt hoogstwaarschijnlijk gelijk als je zegt dat het makkelijker is om een applicatie van windows naar windows phone te porten. Helaas gaat het er in het leven niet altijd om wat het makkelijkste of het beste is, maar gewoon wat de massa gebruikt. En ik zie dat het gebruik van Windows Phone beperkt is. Als game bouwer op handys heb je dus nu een keuze: DirectX op een Windows Phone (wat waarschijnlijk geweldig werkt) of OpenGL op een WIndows,IOs,Android Phone (wat misschien minder werkt, maar je hebt vrijwel de hele markt te pakken).

[Verwijderd]

Windows Phone heeft geen OpenGL, dus de hele markt pakken lukt sowieso niet.

De vraag is wat er precies gaat gebeuren.
Het is in ieder geval makkelijker voor ontwikkelaars om games van Windows naar Windows Phone te porten, dan naar andere telefoons.
Wellicht dat dat betekent dat er een hoop games op Windows Phone/RT gaan komen binnenkort (Microsoft heeft zelf een game studio, met allerlei Xbox-titels, die geport zouden kunnen worden).

Dan zou het misschien wel eens kunnen omdraaien: dat er juist meer mensen voor een Windows Phone gaan kiezen omdat er meer/betere/leukere games voor zijn.
Windows Phone zit sowieso al behoorlijk in de lift: http://blogs.computerworl...windows-phone-start-shine
Het is een paar maanden geleden vanaf 0 begonnen natuurlijk, dus marktaandeel vergelijken is een beetje een vertekend beeld.
Zoals ze daar voorrekenen... als Windows Phone zo doorgaat, zitten ze in 2017 op het niveau van de iPhone.

[Verwijderd]

Zoals ze daar voorrekenen... als Windows Phone zo doorgaat, zitten ze in 2017 op het niveau van de iPhone.

Dat is dus ongeveer 33% van de markt .. op desktop hebben ze rond de 90%. Bij 90% is het redelijk duidelijk wat je doet als game-producent, bij slechts 33% is dat heel wat anders. En uiteraard zit de concurrentie niet stil...

[Verwijderd]

Ik dacht dus dat de iPhone het vrij redelijk deed qua games/apps... Zal wel aan mij liggen?

[Suspicion]

Bij mij is dat hoofdzakelijk omdat een Windows 8 licensie rond de 100 euro komt en mijn fedora 0. Ik vind beide even goed in wat ze doen, dus neem ik liever de goedkoopste van de 2 :-)

[tedades]

Volgens mij is het ook niet de vraag of mensen windows haten of het te duur vinden. Het is de keuze die je niet mag maken omdat microsoft opdringt dat je nieuwe computer alleen windows mag draaien. En al bouw je een eigen computer en zet je er linux op; kun je naast je werk geen spelletjes doen ondanks alle goede pogingen om ze werkend te krijgen (wine etc.).
Dan het antwoord op de vraag waarom je linux zou verkiezen boven windows (windows draait toch best lekker) is: ik vind een pc een werktuig dat moet doen wat ik wil. Een pc moet je kunnen tweaken voor het doel waarvoor hij gebruikt gaat worden, waarbij windows een soort 'alles kunner' is (doet veel maar niet altijd optimaal).
Ik heb dan ook nog steeds de hoop dat games onder linux nog keer gaat aanslaan, en het porten van game-engines is een stap in de goede richting.
Heb vroeger Quake4 gedraait onder linux (native!) en die ervaring was erg goed, terwijl windows op hetzelfde systeem er de grootste moeite mee had.

[w00t00w]

Microsoft afrekenen op de OS keuze van PC bouwers (terwijl sommigen zelfs Linux-bakken in hun aanbod hadden), of op de beschikbaarheid van games/software voor Linux? Als Linux echt zo'n viable, breed gedragen alternatief was voor Windows, dan had het al lang meer marktaandeel en ondersteuning gehad. Face it, 90% (even uit de dikke duim) van de PC gebruikers is of totaal niet geïnteresseerd in/bekend met Linux, of kan het überhaupt niets schelen welk OS op hun PC draait zolang ze de gewenste software maar kunnen draaien (ditto voor games: waarom zijn consoles zo populair, ten koste van PC gaming?)
Dat Linux is niet doorbreekt (ondanks dat het gratis is - een beter selling point kun je nauwelijks hebben), mag het zichzelf aanrekenen.

[Reactie gewijzigd door w00t00w op 22 juli 2024 14:50]

[tedades]

Is je conclusie nu dat het gros van de consumenten niet weet waar ze mee bezig zijn dus maar een windows computer kopen, en bedrijven voornamelijk applicaties maken voor het meest verkochte OS? Want dan denk ik dat we op één lijn zitten.
De stap die Crytek maakt is daarom volgens mij ook een morele met de hoop dat consumenten ooit gaan geven om linux systemen.
En iedereen koopt natuurlijk een console omdat hun games niet draaien op hun linux bak

[blehz]

Dat Windows bij nieuwe PC's komt is niet zo abnormaal als ze de PC bouwers onder druk zetten om dat te doen.
Zie Dell.
Het is al jaren bekend dat Microsoft zijn monopoliepositie misbruikt en niet vies is van bepaalde praktijken.
Hoeveel mensen gebruiken een alternatieve browser sinds ze de keuze of de info krijgen van alternatieven?
Zegt genoeg.

[goarilla]

Mensen willen niets dat gratis is, ze zijn Windows gewend, hetzelfde met hun software. Dan is er nog het feit dat buiten POSIX en een snuifje FHS er praktisch geen standaarisatie is en de verschillende distro-bouwers verschillende doelen nastreven.

Maar eigenlijk willen wij niet dat Linux doorbreekt (op de Desktop). We willen dat we genoeg marketshare hebben zodat er rekening mee wordt gehouden. Zodat wij niet geforceerd worden om een Windows machine aan te schaffen om onze belastingen te kunnen invullen, onze CV's op te stellen, onze rekeningen te kunnen betalen, etc ...

[Reactie gewijzigd door goarilla op 22 juli 2024 14:50]

[cdwave]

Ik heb de belastingaangifte dit jaar onder Linux gedaan, dat werkte prima.

[goarilla]

En daar mag je firefox en zijn populariteit voor bedanken.

[Zyppora]

Mwa, windows haat. Ik heb recentelijk (paar weken geleden) een nieuwe game laptop op de kop getikt, die standaard met W8 uitgerust was. Ik ben niet zo'n fan van W8 en zijn teletubbie view, dus ik dacht: laten die downgraden naar W7. Denk je dat ik dat voor elkaar heb gekregen? De installatie start, maar hangt op een gegeven moment en bij cold reboot krijg je vrolijk W8 weer voor je kiezen. Verschillende andere OS installs geprobeerd, geen van allen werkt. Zelfs dual-boot inregelen lukt niet, en ik krijg sterk het vermoeden dat dat voornamelijk te wijten is aan de W8 installatie.

Nou, dan toch maar proberen. Eerste bevindingen: de helft van de tijd krijg je een tijdelijk profiel. Ik heb na eerste boot netjes een profiel (zonder wachtwoord) aangemaakt, waarnaar opgestart moet worden, mooi achtergrondje, geinstalleerde programmas, instellingen etc. En dat doet het allemaal goed, ALS JE UBERHAUPT NAAR JE EIGEN PROFIEL GESTART WORDT >=(

En sommige games slaan de vooruitgang die je maakt op in je profiel. Zelfs adblock plus in FFx blijkt in mijn profiel te zitten wat dus resulteert in tig ads op websites als solomid.net. Installeren van abp is wel mogelijk, maar het tijdelijke profiel wordt bij shutdown vrolijk verwijderd, en bij startup weer opnieuw aangemaakt, dus dat is een tantalus kwelling.

65 updates downloaden en installeren duurt een EEUWIGHEID op W8. Letterlijk anderhalf uur bezig geweest, vanaf het moment dat ik de laptop het herstart commando geef, tot het moment dat de laptop weer operationeel was. Zowel via wifi (eerste update ronde) als via kabel (tweede update ronde) zorgt voor update doorlooptijden die ronduit teleurstellend zijn ten opzichte van zijn voorganger.

Ik been zeer tevreden over W7, laat daar geen twijfel over bestaan. Het was een verademing om W7 te mogen gebruiken na een tijdje op Vista te hebben gezeten, en ik heb het nu jarenlang gebruikt zonder veel problemen. Maar W8 lijkt wel de Win ME van de 21e eeuw. Het is nog een jong OS, en er zullen vast nog een hoop kinderziektes inzitten die eruit moeten, maar de indruk die het tot nu toe bij mij achterlaat is er een die niet zomaar verdwijnt.

Terug ontopic: ook ik zit te wachten tot een aantal games zich native op Linux laten draaien. Zodra dat zo is, stop ik met het prive gebruik van Windows. Ik doe verder geen dingen die niet ook op Linux kunnen.

[goarilla]

Disable secure boot en indien mogelijk de EFI OS chooser (BIOS).

[Sando]

Ik kan dit eigenlijk niet zo goed volgen. Waarom die windows haat.

Je kan het je waarschijnlijk niet voorstellen, maar best een aantal gebruikers (inclusief ikzelf) draaien gewoon al heel lang (bijna) exclusief Linux. Op meerdere computers. Privé en werk. Een helemaal ingericht systeem, muziek, foto's, rss downloads, alle tools etc waar je ze wilt en gewoon heel convenient.

En In tegenstelling tot een aanzienlijke groep Windowsgebruikers, zijn Linuxgebruikers juist niet van die krenten. Als ze commerciële software willen gebruiken dan betalen ze er ook gewoon voor. Veel Windowsgebruikers zetten overal een Windowskopietje op alsof het niets is. Waarom zo graag Windows overal opzetten als ze er alles aan doen om dat lastig te maken? Fedora/Ubuntu etc, zij helpen en motiveren je juist om Linux overal op te zetten. Zij waarderen dat juist, in plaats van dat ze je criminaliseren. En dat is voor Linuxgebruikers gewoon een collectieve high-five. In pay what you want acties zijn Linuxgebruikers steevast de best betalende groep. Maar ze hebben gewoon geen zin in Windows. Ze vinden het systeem niet relazed. Ze hebben misschien een licentie + dual boot op één van de drie computers. En dan moet je om te gamen zeker niet alleen naar die specifieke computer gaan, je moet ook je fijne omgeving verlaten en in een omgeving starten waar je eens in de maand bent, waar niks staat waar je gewend bent, waar je foto's/muziek/downloads niet beschikbaar zijn.

Naar Windows booten is dan alsof je je van gemakken voorziene huiskamer verlaat om ergens in een ongemakkelijke kroeg vanuit een vervelende hoek een voetbalwedstrijd op de te kleine openbare tv gaat volgen. Dat doe je gewoon zoveel liever thuis, en dat heeft helemaal niks met krenterigheid te maken. En dan zal ik je het verhaal over vrijheid en idealisme van FOSS besparen.

Daarom is het super dat steeds meer belangrijke engines naar Linux geport worden. Niet alle gamers willen rücksichtlos uit hun fijne omgeving booten. Bovendien heb je de casual gamer die tijdens het wachten op iets (waar de computer mee bezig is) of na het werk even een half uurtje wil gamen. Niet dualbooten alsof je opeens andere hardware op moet starten. Dan kan je net zo goed Xboxen.

[Reactie gewijzigd door Sando op 22 juli 2024 14:50]

[lezzmeister]

Het punt is, dat Windows zich totaal niet wil aanpassen aan wat ik wil. Dat is voor mij de primaire reden om FreeBSD te gebruiken. Het is niet dat ik per se vrije software moet hebben, anders had ik wel gekozen voor een linux distributie die de goedkeuring van Stallman kan wegdragen.

Windows 95 e.v., allemaal redelijk hetzelfde, tot we komen bij XP(eerste Windows die gewoon echt goed werkt), dan verandert er echt wat onder de motorkap, bij Vista helemaal, bij Win 7 lijkt het echt goed volwassen. En alles ongeveer hetzelfde, de indeling werkte goed. Dan komt 8 uit en moet er ineens dezelfde interface zijn voor tablets, telefoons, desktops, servers, alles er tussenin. Desktops hebben nu eenmaal geen touchscreen, en dat werkt gewoon niet lekker. Een flinke dot extra geld betalen zodat je over je bureau kan leunen om je scherm vet te maken met je vingers. Nee dank je. Dit werkt voor mij niet, ook niet na gewenning en ook niet als ik probeer een Wacom te gebruiken, en ik ben volgens mij de enige niet.

Goed, dus op de echt mobiele apparatuur is Metro een beter idee dan je grote bak thuis. Wat nu? Microsoft beslist dat je met Metro werkt en verder basta. Er word je geen keus gegeven. Als ik BSD installeer, of linux, kan ik kiezen wat voor desktop ik wil. Ik kan kiezen of ik om te beginnen al een desktop wil. Ik kan iedere window manager die ik kies een uiterlijk geven waar ik het mee eens ben. Ik kan alles. Bijna alles.

Wat games betreft, heb je een snelle videokaart nodig. Dat betekent geschikte snelle drivers. Voor linux zijn er de binaries, en veel open-source fanaten hebben daar een broertje dood aan, dat terwijl Nvidia en AMD daar wel moeite in steken. En dan nog moet je je verdiepen in Mesa, wel of geen Gallium, wat is KMS, x.org extensions, etc. Op Windows is dat gewoon DirectX en klaar, het grote voordeel wat je daar heb. Kijk je naar BSD, waar binary blobs een veel minder groot issue zijn, dan maken ze daar juist geen drivers voor. Ja Nvidia, en slechts alleen voor FreeBSD. Dit alles moet je dan wel willen zonder rare dingen als snel 3D op meerdere schermen, want dan kun je helemaal je lol op. Veel mensen zitten daar niet op te wachten, en hebben geen zin om zich er zo in te verdiepen.

[markdm]

Waarom altijd die windows haat, ik ben ook niet zo blij met windows. Op mijn vorige laptop draaide windows 7, goed besturingssysteem maar hij liep bepaald niet stabiel en op mijn nieuwe laptop draait windows 8, eerlijk gezegt vind ik het zwaar klote. De ene app start full-screen op, de andere ineens in het bureaublad, ik gebruik de metro-interface nooit terwijl je er niet omheen kan, hij rekent mijn wachtwoord altijd fout (ookal heb ik hem goed ingevult) en ik heb het gevoel dat games in windows 8 veel meer bugs hebben.

[blehz]

Als je nu zou weten wat het daadwerkelijke verschil is tussen Windows en Linux zou je wel anders praten.
Waarom duurt het 5 minuten voor mijn nieuwe installatie van Windows 7 volledig is opgestart terwijl dit in Linux nog geen minuut duurt?
En reken maar dat dat 10 minuten wordt als die Windows er al een aantal maanden op staat.

Windows XP kon je nog strippen, alle nutteloze services eruit halen. Maar probeer dat met Windows 7 en hij start niet meer. Die bloatware is 1 grote, aaneenplakkende brok troep.

Een aantal jaren geleden zijn er meer en meer MAC games gekomen. De stap naar Linux is dan niet groot niet meer, aangezien de engine dan toch al OpenGL gebruikt.
Dit is natuurlijke evolutie, een evolutie die Microsoft zichzelf heeft aangedaan. (zie het verhaal van Windows 8 )
En dat begrijpen meer en meer developers ondertussen ook wel. Gelukkig nu ook Crytek. Ze kunnen het zich natuurlijk ook veroorloven, net zoals Valve.

[Reactie gewijzigd door blehz op 22 juli 2024 14:50]

[goarilla]

Windows XP kon je nog strippen, alle nutteloze services eruit halen. Maar probeer dat met Windows 7 en hij start niet meer. Die bloatware is 1 grote, aaneenplakkende brok troep.

Waar haal je dat vandaan ? Met services.msc of het command line sc kan je ze toch nog altijd als van oudscher trimmen hoor.

[blehz]

Al geprobeerd dan? Heb 4 verschillende configuraties geprobeerd en telkens opnieuw dat er wel iets niet werkt of gewoon niet meer start.
Zet er 1 uit en de rest werkt ook niet meer.
En dat zijn dan services die nutteloos lijken, maar blijkbaar toch gebruikt worden door de services die onmisbaar zijn.
En snelheidswinst is ook zo goed als onbestaande.
Het is lang niet meer hetzelfde als in XP.
Los daarvan, waarom moet Windows zo traag en bloated zijn?
Dat Microsoft zijn OS eens echt modulair maakt ipv altijd te proberen op alternatieve manieren 'snelheid' te winnen (zie het verhaal van kernel hibernation in Windows 8 ).

[Reactie gewijzigd door blehz op 22 juli 2024 14:50]

[goarilla]

Ja ik heb een batch script die services trimmed. Sommige hebben inderdaad dependancies maar dat was met Windows XP ook zo. Check de event viewer logs voor details wanneer het mis loopt.

HIer is de mijne: http://pastebin.com/TyQzJhE2, dit moet gedraaid worden als administrator. Het disabled server, remote registry, upnp, wmpsvc en ALG.

[cdwave]

Ik draai Linux voor werk en hobby.

't Is gewoon lastig dat ik ook naar windows moet re-booten om een spelletje te spelen. En dat ik dus niet tegelijk kan compileren en gamen.

Heeft helemaal niks met geld of haat te maken, puur met gebruiksgemak.

[brugj03]

Ik heb weinig verstand van LInux maar waarom zou je in vredes naam tegelijkertijd willen compileren en gamen.

Afgezien van het feit dat de meeste games gewoon shit draaien op linux en dat je de processor tijd die het compileren kost absoluut voor je game nodig hebt.

[gassie123]

Je hebt helemaal gelijk. Kleine stapjes worden er gezet op dit moment. En dat is in ieder geval beter als helemaal geen stapjes.

[Conzales]

Ubuntu Europees? Canonical is in Engeland gevestigd ja, maar opgericht door Mark Shuttleworth, een Zuid-Afrikaan. Ubuntu is gebaseerd op OSS, vooral via Debian. Aan OSS wordt vanuit de hele wereld bijgedragen. Dus ik weet niet hoe je bij Europees komt.

[Peetke]

Canonical zit wel voornamelijk in Londen. Maar inmiddels kantoren overal over de wereld, met meer dan 500 werknemers. Voorzover ik kon vinden geen kantoor in Zuid-Afrika (ook al komt Mark Shuttleworth daar vandaan).

[Verwijderd]

Goed nieuws inderdaad
Volledig oversttappen kan alleen beperkt het hier en daar wat.

Zelf al tijden over op alleen linux, bevalt prima.
Maar dan speel ik ook meer indie games.

[D33F]

Ben ik het helemaal met je eens

[Mic2000]

En dat stapt de malware scene ook over op Linux...

[GiLuX]

ik snap al die reacties niet die stellen dat je nu niet zou kunnen gamen op linux..

de enige windows-games die niet fatsoenlijk aan de gang zijn te krijgen onder linux met wine/playonlinux zijn de games die zwaar op dotnet leunen.

net bijvoorbeeld eens world of tanks installed via playonlinux en ook dat gaat volledig automatisch en zonder problemen.

een spel wat ik dan weer niet aan de gang krijg is la noire omdat installatie van dotnet 3.5 sinds een tijdje niet meer werkt via wine.

kan overigens ook een teken zijn dat wine devs juist bezig zijn met eigen implementatie.. weet het niet.

hoe dan ook zolang windows games niet te vastgebakken zitten aan dotnet framework draaien ze over het algemeen zonder problemen.

[Verwijderd]

dot net is inderdaad een hardnekkig framework gemaakt puur om anderen dwars te zitten en om niet multiplatform te zijn. (Walled Garden concept) Hoop dat niet veel mensen deze framework zullen supporten en/of het naast zich neer zullen leggen.

Software moet straks gewoon op elk platform kunnen draaien. Er mogen geen monopolie posities meer voorkomen.

[RoestVrijStaal]

Ik troost je. Microsoft dumpt toch XNA.
nieuws: Microsoft stopt in april 2014 met XNA-platform

Wat ze voor in de plaats hebben weet ik niet, maar je zult gebruik moeten maken van andere game engines wil je games schrijven in C#

En ja, dat er een paar spellen erin geprogrammeerd zijn. Jammer dan maar helaas. Wine / Mono developers zullen er ook niet veel voor voelen om technologie waar de stekker uit getrokken is opnieuw te bouwen.

[_Thanatos_]

XNA stopt in 2014 niet opeens met werken. Het wordt gewoon niet meer doorontwikkeld.

Microsoft heeft wel vaker ergens de stekker uit getrokken, maar dat heeft nog nooit betekend dat datgene opeens compleet afgestorven is.

[Verwijderd]

Yup, de DirectX SDK is ook sinds juni 2010 niet meer geupdate.
Een deel is geschrapt (oa de D3DX API), een ander deel is in de Windows SDK opgenomen.

Maar je kunt die SDK nog steeds downloaden, en nog steeds gebruiken om te ontwikkelen, zelfs met VS2012.

XNA zal vast ook nog wel een paar jaartjes beschikbaar blijven op de Microsoft-servers (en daarna vast wel op sites als Oldapps.com oid).

Als je de SDK maar hebt, kun je er altijd mee blijven ontwikkelen. Ik heb zelf m'n oude DirectX SDKs bewaard, en er m'n eigen 'legacy SDK' van gebouwd. Kan nog gewoon Direct3D1 apps bouwen, en dat draait ook gewoon nog steeds op Windows 8.

[RoestVrijStaal]

Klopt, maar hiermee heeft Microsoft echter wel de doodverklaring van XNA ondertekend.

Als game studio zou je mooi in je hemd staan als je in 2014 een nieuwe game met XNA onder de motorkap uitbrengt, maar het spel kan niet draaien op Windows 9.

[_Thanatos_]

Dan lever je de binaries van XNA mee.
Gebeurt tenslotte ook met games die de C++ runtime libs nodig hebben.

[Reactie gewijzigd door _Thanatos_ op 22 juli 2024 14:50]

[HerrPino]

Software moet straks gewoon op elk platform kunnen draaien.

En waarom? Is platform onafhankelijk de heilige graal en altijd beter?

Is 4n4le s3x beter omdat het op alle platformen werkt, zowel man als vrouw? Het kan, maar benut niet alle mogelijkheden van de platformen, de vrouw in dit geval (voortplanting).

[Wyox]

Far Cry 3 is gebaseerd op de Dunia Engine dan wel gemaakt door / ontworpen door iemand van CryTek maar is een grote aanpassing op de CryEngine. Tevens is alleen FarCry 1 ontwikkeld door CryTek en zijn zowel Far Cry 2 als Far Cry 3 ontwikkeld door Ubisoft zelf.

[Richh]

Precies. Het onderstaande plaatje van Far Cry 3 is dus alles behalve bijpassend

[- peter -]

Mooi, je ziet al een beweging van Indie Developers die voor alle platforms standaard releasen. Het lijkt erop dat de tools er al wel zijn tegenwoordig, maar (grote) developers met bestaande tools en codebases zijn minder snel geneigd uiteraard om crossplatform te gaan werken. En natuurlijk zijn de echte grote engines niet allemaal beschikbaar op Linux. Dit is een mooie stap in die richting!

[SG]

De grote developers hebben ook grotere investeringen ennrichten zich op grotere publiek die op populaire platformen gamen. Als platform voldoende grote heeft dus aantrekkelijke afzet markt met voldoende volume sales potentie dan wordt daar voor mogelijk gekozen voor een port.

Een indie dev heeft die druk niet en doet wat hij zelf wil naar eigen inzicht en platform voorkeur.
Met grote investeringen moet bepalde keuzes vaak ook verantwoorden. Gezien porten ook geld kost.

De reden dat men massaal voor windows developed. En niet MAC en linux is de afzet market is in verhouding een heel stuk kleiner.

Linux wint terrein. Maar het is nog steeds groot vershil.