Carmack: Wine-emulatie voor games op Linux logischer dan native ports
John Carmack, programmeur en mede-oprichter van id Software, stelt dat emulatie met behulp van de Wine-emulator binnen Linux voor developers praktischer is dan het uitbrengen van native ports van populaire Windows-games. Ook zou Wine-emulatie veel goedkoper zijn.
Carmack geeft op Reddit uitleg op een eerdere tweet van zijn hand. Daarin stelde de id Software-directeur dat er beter meer tijd gestoken kan worden in het verbeteren van de gamingsupport van de Windows-emulator Wine, dan om individuele ontwikkelaars te vragen native ports voor Linux uit te brengen.
In zijn toelichting schrijft Carmack dat er onvoldoende geld verdiend kan worden door Linux officieel te ondersteunen in mainstream-games. De kosten zouden niet zozeer zitten in de ontwikkeling van een native port voor het Linux-platform, maar in de verdere ondersteuning. Enkele proeven met het uitbrengen van native Linux-titels door id, zoals Quake Arena en Quake Live, zouden Carmacks mening hebben versterkt.
Volgens Carmack is het voor ontwikkelaars beter om Wine te gebruiken voor het porten van Windows-games naar het Linux-platform. De diverse input-api's van de Wine-emulator zouden op voldoende niveau zijn en de graphics kunnen via OpenGL worden afgehandeld. Voor het afhandelen van D3D-graphics naar OpenGL zouden nog wel de nodige optimalisaties nodig zijn in Wine.
Met zijn visie op Linux-gaming reageert Carmack onder andere op de plannen van Valve. Dit bedrijf is bezig om zijn Steam-platform beschikbaar te maken op Ubuntu, terwijl er ook enkele native games beschikbaar zijn gemaakt voor Linux. Ook heeft Valve plannen om een op Linux draaiende Steam Box uit te gaan brengen. Verder vragen Linux-gebruikers steeds vaker aan gamedevelopers om native ports uit te brengen, met name omdat deze beter zouden presteren dan geëmuleerde Windows-code.
Reacties (94)
Volgens mij is WINE echter nog steeds geen emulator, zoals de naam zelf ook benadrukt.
http://nl.wikipedia.org/wiki/WineEmulator of niet?
Volgens de ontwerpers kan Wine geen emulator genoemd worden. Deze stelling veroorzaakt op internet vaak lange discussies. De ontwerpers definiëren een emulator namelijk als een virtuele machine en aangezien Wine geen virtuele machine is, is het dus geen emulator, zoals bijvoorbeeld VMWare Player. Bij een ruimere definitie van emulatie, zoals "het simuleren van een omgeving bovenop een bestaande omgeving", kan Wine wel een emulator worden genoemd.
De meningen zijn dus verdeeld zullen we maar zeggen.
[Reactie gewijzigd door Soldaatje op 5 februari 2013 19:09]
Dan zou ik het eerder een "simulator" dan een "emulator" noemen. Het simuleert namelijk de Windows omgeving voor de applicatie.
Een simulator is een machine die iets nabootst.
Een emulator is een simulator voor een ander computersysteem.
Een emulator is een simulator voor een ander computersysteem.
Het is nog eerder een windows API vertaler. Hij doet namenlijk niet alsof het een windows PC is, het is alleen een laag tussen Linux en het programma dat alleen Windows praat.
Overigens is mijn ervaring met WINE een redelijk slechte. Ook "goed" ondersteunde games geven vaak problemen. Applicaties werken vaak maar dikwijls niet bepaald snel.
Overigens is mijn ervaring met WINE een redelijk slechte. Ook "goed" ondersteunde games geven vaak problemen. Applicaties werken vaak maar dikwijls niet bepaald snel.
ik heb zelf een dikke fps boost op linux ten opzichte van dezelfde game op windows
Is het ook duidelijk hoe dat komt, heb je bijvoorbeeld exact dezelfde kwaliteit? Als Wine bijvoorbeeld (ik zeg niet dat het zo is) bepaalde shaders niet zou ondersteunen of bepaalde OpenGL extensies mist. Dan kun je je voorstellen dat het aantal fps omhoog gaat.
Ik heb dezelfde ervaring met sommige titels, maar kon grafisch geen verschil zien. Dit werkte alleen met games die al op OpenGL draaiden. Ik vermoed dat het te maken heeft met het feit dat de videocard driver in windows wellicht meer directx oriented was en minder opengl.
Geloof ik vrij weinig van.
Mijn ervaring met Wine is dat het soms ongeveer even snel is als een windows game maar in veel andere gevallen enorm traag of buggy.
Hoe je het ook wil rechtlullen, Wine doet windows API calls afvangen en vertalen en doet hetzelfde voor D3D.
Dat is overhead.
Carmack heeft een punt m.b.t. dat het efficienter is om moeite te steken in de API.
Het is alleen een doodlopende weg.
Games worden nu gemaakt voor D3D en Windows en Microsoft kan ZO roet in het eten gooien van Wine.. die dan altijd achter de ontwikkelingen binnen Windows aan zit te hobbelen.
Das toch gewoon een ruk positie?
Ik zou dus inderdaad VOOR native ports kiezen.
Dat hele Wine is een denkfout.
Mijn ervaring met Wine is dat het soms ongeveer even snel is als een windows game maar in veel andere gevallen enorm traag of buggy.
Hoe je het ook wil rechtlullen, Wine doet windows API calls afvangen en vertalen en doet hetzelfde voor D3D.
Dat is overhead.
Carmack heeft een punt m.b.t. dat het efficienter is om moeite te steken in de API.
Het is alleen een doodlopende weg.
Games worden nu gemaakt voor D3D en Windows en Microsoft kan ZO roet in het eten gooien van Wine.. die dan altijd achter de ontwikkelingen binnen Windows aan zit te hobbelen.
Das toch gewoon een ruk positie?
Ik zou dus inderdaad VOOR native ports kiezen.
Dat hele Wine is een denkfout.
grappig dat jij denk dat hij staat te liegen...
terweil ik bij enkele titels ook die indruk had, en voor zover ik weet ging het idd om openGL titels, aangezien OpenGL standaard gewoon ondersteund wordt hoeft daar niets voor vertaald te worden.
verder nog het volgende, er zijn HEEL veel talen die moeten worden vertaald, in de game engine zit vaak iets dat op bijv python de in-game scripts afhandeld, andere games worden domweg in java geprogrammeerd (bijv minecraft laat prima zien dat het zou kunnen, weer anderen software (al weet ik niet of daar games tussen zitten), draaien op .NET
als je wine ziet als een .WIN omgeving, zoals C# het .NET nodig heeft, dan vallen al die vertaalslagen best mee,
het grootste probleem voor wine is dat er heel wat specs simpelweg NIET beschikbaar zijn, en dat het dus altijd maar weer reverse engenearen word, OF je moet ms omkopen (licentie gelden) met een kleine vrachtwagen-lading aan 1000$ bills..
als je het zo goed zou willen beschouwen denk ik dat carmac hier de beste oplossing mist, namelijk bouw een nieuwe programmeer omgeving speciaal om games in te schrijven, denk aan iets dat op java lijkt maar met de nodige voordelen voor de eigen industrie.
zo'n framwork kan dan zelf bepalen of het opjecten door d3d of door opengl of zelfs door (kindertjes in india) wil laten renderen
(note: neem aub die laatste mogelijkheid niet al te sirieus dank u)
terweil ik bij enkele titels ook die indruk had, en voor zover ik weet ging het idd om openGL titels, aangezien OpenGL standaard gewoon ondersteund wordt hoeft daar niets voor vertaald te worden.
verder nog het volgende, er zijn HEEL veel talen die moeten worden vertaald, in de game engine zit vaak iets dat op bijv python de in-game scripts afhandeld, andere games worden domweg in java geprogrammeerd (bijv minecraft laat prima zien dat het zou kunnen, weer anderen software (al weet ik niet of daar games tussen zitten), draaien op .NET
als je wine ziet als een .WIN omgeving, zoals C# het .NET nodig heeft, dan vallen al die vertaalslagen best mee,
het grootste probleem voor wine is dat er heel wat specs simpelweg NIET beschikbaar zijn, en dat het dus altijd maar weer reverse engenearen word, OF je moet ms omkopen (licentie gelden) met een kleine vrachtwagen-lading aan 1000$ bills..
als je het zo goed zou willen beschouwen denk ik dat carmac hier de beste oplossing mist, namelijk bouw een nieuwe programmeer omgeving speciaal om games in te schrijven, denk aan iets dat op java lijkt maar met de nodige voordelen voor de eigen industrie.
zo'n framwork kan dan zelf bepalen of het opjecten door d3d of door opengl of zelfs door (kindertjes in india) wil laten renderen
(note: neem aub die laatste mogelijkheid niet al te sirieus dank u)
Het kan misschien wel overhead zijn, maar als het onderliggende systeem vele malen sneller is, zou je netto gezien toch een performance winst zien.
Je hele argumentatie berust op intuïtie, roddels en onderbuikgezever. Kom alsjeblieft met feiten voordat je dingen bestempelt als denkfout.
Je hele argumentatie berust op intuïtie, roddels en onderbuikgezever. Kom alsjeblieft met feiten voordat je dingen bestempelt als denkfout.
En waarom zou dat per definitie overhead zijn?
Zowel In Windows als in Wine zijn de functies ge(her)implementeerd op een zo efficient mogelijk manier. Het is niet zo dat Wine de originele windows dll's realtime gaat zitten interpreteren en vertaalt naar 'Linux' code.
De applicatie roept functies aan die native geimplementeerd zijn, alleen de functie namen komen 1:1 overeen met de win32 api. Dat is geen emulatie, of Xfree86 zou Xorg emuleren (en vice versa). OpenAL voor Windows is ook geen emulatie, libSDL ook niet. Ze gebruiken dezelfde functie namen, maar dat is dan ook de enige overeenkomst. De implementatie voor beide platformen is (voor een groot deel) anders.
En dat zou je zo kunnen stellen voor alle libraries die cross-platform zijn. Wine heeft van de win32 api gewoon een cross-platform implementatie gemaakt. Beetje zoals Mono dat met .NET gedaan heeft. Maar men zegt toch hopelijk ook niet dat Mono .NET emuleert??
Zowel In Windows als in Wine zijn de functies ge(her)implementeerd op een zo efficient mogelijk manier. Het is niet zo dat Wine de originele windows dll's realtime gaat zitten interpreteren en vertaalt naar 'Linux' code.
De applicatie roept functies aan die native geimplementeerd zijn, alleen de functie namen komen 1:1 overeen met de win32 api. Dat is geen emulatie, of Xfree86 zou Xorg emuleren (en vice versa). OpenAL voor Windows is ook geen emulatie, libSDL ook niet. Ze gebruiken dezelfde functie namen, maar dat is dan ook de enige overeenkomst. De implementatie voor beide platformen is (voor een groot deel) anders.
En dat zou je zo kunnen stellen voor alle libraries die cross-platform zijn. Wine heeft van de win32 api gewoon een cross-platform implementatie gemaakt. Beetje zoals Mono dat met .NET gedaan heeft. Maar men zegt toch hopelijk ook niet dat Mono .NET emuleert??
Wat omhelst dan volgens jou het wel daadwerkelijk "doen of iets een Windows PC is". Hoe definieer je een "Windows PC" überhaupt?Het is nog eerder een windows API vertaler. Hij doet namenlijk niet alsof het een windows PC is
Het zal een applicatie een worst wezen in wat voor omgeving hij draait, zolang hij z'n API calls maar gewoon kan doen. Zowel Windows zelf als Wine voorzien daarin. En ja, Wine emuleert daar weldegelijk het gedrag van Windows mee (inclusief alle bugs die in der loop van de tijd in de API geslopen zijn en waar applicaties van afhankelijk zijn geworden).
Wat de makers van Wine bedoelen met "it's not an emulator" is dat ze willen aangeven dat het geen VM is die CPU instructies emuleert. Maar het is weldegelijk gewoon een emulator in de volle betekenis van het woord - het nabootsen van een ander systeem.
http://dictionary.referen...75&src=ref&ch=dic
Dat noemt men dus gewoon een abstractielaag. Wine is eerder een port van de windows API naar linux te noemen dan een emulator.
De API is de abstractie. De implementatie van die API van Wine is een emulatie van de implementatie van het origineel in Windows.
De reden dat we deze discussie überhaupt hebben is omdat mensen blijkbaar bepaalde eigenschappen aan de term "emulatie" toedichten die helemaal niet relevant zijn. Emuleren is gewoon een synoniem voor immiteren, niets meer en niets minder. Het zegt geen drol over de implementatie en performance ervan.
De reden dat we deze discussie überhaupt hebben is omdat mensen blijkbaar bepaalde eigenschappen aan de term "emulatie" toedichten die helemaal niet relevant zijn. Emuleren is gewoon een synoniem voor immiteren, niets meer en niets minder. Het zegt geen drol over de implementatie en performance ervan.
[Reactie gewijzigd door .oisyn op 6 februari 2013 12:36]
Wine is een API-translator.
"Wine translates Windows API calls into POSIX calls on-the-fly."
"Wine translates Windows API calls into POSIX calls on-the-fly."
[Reactie gewijzigd door poktor op 6 februari 2013 10:34]
Volgens het woordenboek is het verschil tussen de betekenis van die woorden hooguit subtiel:Dan zou ik het eerder een "simulator" dan een "emulator" noemen. Het simuleert namelijk de Windows omgeving voor de applicatie.
Emuleren
Het nabootsen van iets anders
http://www.encyclo.nl/begrip/emuleren
Simuleren
Iets nadoen
http://www.encyclo.nl/begrip/simuleren
het emuleert windows drivers, wat dat betreft is het wel een emulator.
zo heb je voor OSX CrossOver welke het zelfde principe hanteert.
http://www.codeweavers.com/products/
zo heb je voor OSX CrossOver welke het zelfde principe hanteert.
http://www.codeweavers.com/products/
CrossOver zou inderdaad hetzelfde moeten doen, aangezien CrossOver gebaseerd is op wine.
http://www.codeweavers.com/about/
"CrossOver is powered by an amazing open-source technology called Wine, and we are proud supporters of The Wine Project."
http://www.codeweavers.com/about/
"CrossOver is powered by an amazing open-source technology called Wine, and we are proud supporters of The Wine Project."
Je hebt wine 
CrossOver en Transgaming maken gebruik van wine. En gebruiken wine-prefix ofwel een wine-bottle om per applicatie een unieke installatie te maken. Zij vereenvoudigen de installatie door bijv. de juiste directx of vbruntime files te installeren. Wat toepassing x vereist.
Codeweavers en Transgaming zijn commercieel, en kun je ook op ondersteuning rekenen. En zij leveren (sommige) van hun bevindingen en truukjes terug aan de community; wine - hun oorspronkelijke bron van succes.
Dan heb je nog PlayOnLinux en GOL die bieden qua mogelijkheden ongeveer hetzelfde als codeweaver en transgaming, maar zijn 100% opensource. En support komt daarvan uit de community.
Gebruik graag adobe photoshop onder linux middels wine. Bevalt me prima, wacom werkt en daarmee verviel de windows desktop. Maar op gebiedt van gaming ... de meeste (oudere)directx9 games draaien wel. En met de specs van hedendaagse computers verschild dat niet veel met windows. Denk aan world of warcraft die draait zo goed als 1:1. Maar Path of Exile heeft het duidelijk moeilijker. Prestatie is via wine vaak wat minder, en mem/cpu worden lekker zwaar belast.
Maar als je naar benchmarks kijkt van Team Fortress, dan lijkt optimalisatie en native linux port zelfs een voordeel te hebben tozv windows. Zo komen straks ook half-life, counterstrike etc. native op linux beschikbaar. Alle dezelfde engine.
DE grote ontwikkelaars gebruiken toch wel een inhouse engine, maar heel veel goeie games worden nog steeds gemaakt dmv een 'universele engine'. Denk aan Unreal van epic, daarmee zijn veel games gebakken.
De slag voor linux als game platform zal dan ook vallen of staan door die game engine. Als john, epic, valve die basis eenmaal goed neerleggen. Dan kunnen andere ontwikkelaars daarvan mee profiteren. Het recente Unit3D heeft zich inmiddels bewezen, populariteit en winst is met versie 4.0 gestegen: die gaf ons linux support
Kan meneer wel een test hebben gedaan met quake-live, maar is die test niet te vroeg geweest? Want lag het niveau en acceptatie van de desktop zoals vandaag? Had ati uberhoubt goeie drivers? (/me runs)
het lult dus rechtstreeks met api's en voert code direct uit op een mac/unix systeem zonder tussenkomt van een virtuele machine (zoals virtualbox/vmware)Instead of simulating internal Windows logic like a virtual machine or emulator, Wine translates Windows API calls into POSIX calls on-the-fly, eliminating the performance and memory penalties of other methods and allowing you to cleanly integrate Windows applications into your desktop
CrossOver en Transgaming maken gebruik van wine. En gebruiken wine-prefix ofwel een wine-bottle om per applicatie een unieke installatie te maken. Zij vereenvoudigen de installatie door bijv. de juiste directx of vbruntime files te installeren. Wat toepassing x vereist.
Codeweavers en Transgaming zijn commercieel, en kun je ook op ondersteuning rekenen. En zij leveren (sommige) van hun bevindingen en truukjes terug aan de community; wine - hun oorspronkelijke bron van succes.
Dan heb je nog PlayOnLinux en GOL die bieden qua mogelijkheden ongeveer hetzelfde als codeweaver en transgaming, maar zijn 100% opensource. En support komt daarvan uit de community.
Gebruik graag adobe photoshop onder linux middels wine. Bevalt me prima, wacom werkt en daarmee verviel de windows desktop. Maar op gebiedt van gaming ... de meeste (oudere)directx9 games draaien wel. En met de specs van hedendaagse computers verschild dat niet veel met windows. Denk aan world of warcraft die draait zo goed als 1:1. Maar Path of Exile heeft het duidelijk moeilijker. Prestatie is via wine vaak wat minder, en mem/cpu worden lekker zwaar belast.
Maar als je naar benchmarks kijkt van Team Fortress, dan lijkt optimalisatie en native linux port zelfs een voordeel te hebben tozv windows. Zo komen straks ook half-life, counterstrike etc. native op linux beschikbaar. Alle dezelfde engine.
DE grote ontwikkelaars gebruiken toch wel een inhouse engine, maar heel veel goeie games worden nog steeds gemaakt dmv een 'universele engine'. Denk aan Unreal van epic, daarmee zijn veel games gebakken.
De slag voor linux als game platform zal dan ook vallen of staan door die game engine. Als john, epic, valve die basis eenmaal goed neerleggen. Dan kunnen andere ontwikkelaars daarvan mee profiteren. Het recente Unit3D heeft zich inmiddels bewezen, populariteit en winst is met versie 4.0 gestegen: die gaf ons linux support
Kan meneer wel een test hebben gedaan met quake-live, maar is die test niet te vroeg geweest? Want lag het niveau en acceptatie van de desktop zoals vandaag? Had ati uberhoubt goeie drivers? (/me runs)
[Reactie gewijzigd door himlims_ op 5 februari 2013 22:01]
Een virtuele machine is geen emulator, zoals Parallels onder OSX stuur het OS ook native aan.
Carmack gebruikt emulatie en Wine dan ook niet in dezelfde zin, het gebruik van het woord emulatie staat ook helemaal los van Wine gebruik. Voor de term Wine-emulatie mag je dan ook bij Dimitri zelf aankloppen...Volgens mij is WINE echter nog steeds geen emulator, zoals de naam zelf ook benadrukt.
WINE is geen emulator. Het emuleert namelijk niet. Het is gewoon een implementatie van de windows libraries. Simpel en eenvoudig. Hier zijn geen ellenlange discussies voor nodig.
Verder heeft Carmack helemaal gelijk. Het is veel slimmer om te zorgen dat WINE net zo goed gebruikt kan worden als Windows. In plaats dat je als Game ontwikkelaar een port maakt naar Linux, zorg je er voor dat WINE 100% compatible is met de Windows implementatie van je game.
Verder heeft Carmack helemaal gelijk. Het is veel slimmer om te zorgen dat WINE net zo goed gebruikt kan worden als Windows. In plaats dat je als Game ontwikkelaar een port maakt naar Linux, zorg je er voor dat WINE 100% compatible is met de Windows implementatie van je game.
Als het hele gebeuren maar niet ten koste gaat van de gameplay (lees alles een stuk trager gaat) dan maakt het niet uit toch. Als je alleen al 50% van je performance kwijt bent dan lijkt me native toch intressanter, ik heb alleen geen ervaring met Wine...
En een N64-emulator is gewoon een implementatie van de N64-libraries, toch? 
Ik snap het verschil (nog) niet zo goed.
Ik snap het verschil (nog) niet zo goed.
[Reactie gewijzigd door woekele op 6 februari 2013 08:22]
Nee, want daar moet er een andere CPU ge-emuleerd worden en allemaal andere hardware ge-emuleerd worden. WINE vertaalt API calls real-time en voert de code voor de rest vrijwel direct uit, aangezien er geen vertaalslag nodig is voor de applicatie want die is al in x86 (of x86-64) machinetaal, en de gemiddelde Linux doosch heeft ook gewoon zo'n CPU. WINE zou ik geen emulator noemen, meer een vertaallaag.
[Reactie gewijzigd door Plofkotje op 6 februari 2013 10:08]
Het probleem is dat enerzijds mensen hardware-emulatie gelijk willen stellen aan emulatie in het algemeen, waar anderen juist vinden dat het emuleren van een andere API/library/etc ook onder emulatie valt.
Ik vind persoonlijk dat WINE gewoon ongelijk heeft. Ik denk dat ze met de naam te krampachtig wilden benadrukken dat er geen CPU/hardware-emulatie uitgevoerd werden (wat destijds nogal een stigma had qua traagheid), en daarmee hun doel voorbij zijn geschoten.
Nee, WINE is geen hardware-emulator, maar het valt wel degelijk onder de term emulatie in de bredere zin van het woord. Degene die de naam WINE heeft bedacht, heeft waarschijnlijk niet zo goed opgelet tijdens de colleges Computer Organization waar de termen emulatie en simulatie uitgelegd werden.
Zie ook de link van .oysin hierboven.
Ik vind persoonlijk dat WINE gewoon ongelijk heeft. Ik denk dat ze met de naam te krampachtig wilden benadrukken dat er geen CPU/hardware-emulatie uitgevoerd werden (wat destijds nogal een stigma had qua traagheid), en daarmee hun doel voorbij zijn geschoten.
Nee, WINE is geen hardware-emulator, maar het valt wel degelijk onder de term emulatie in de bredere zin van het woord. Degene die de naam WINE heeft bedacht, heeft waarschijnlijk niet zo goed opgelet tijdens de colleges Computer Organization waar de termen emulatie en simulatie uitgelegd werden.
Zie ook de link van .oysin hierboven.
Als de API rechtreeks de machinecode aanspreken dan zou ik niet meer willen spreken over emulatie.
Het gaat wel om iets meer dan alleen machinecode natuurlijk.
Windows is een compleet OS, met verschillende lagen. Applicaties praten alleen tegen de API-laag aan. Daaronder heb je nog subsystemen, en daaronder dan de kernel en drivers.
WINE opereert op API-niveau, en dat houdt in dat WINE dus tegen de kernel en drivers van linux (of ander *nix-OS) moet praten. Hierdoor moet dus oa D3D vertaald worden naar OpenGL.
En dan praat je dus wel degelijk over een vorm van emulatie.
D3D en OpenGL opereren immers op hetzelfde niveau, en er wordt een vertaalslag gemaakt om de laag van het ene OS af te beelden op het andere.
Als WINE nu direct met de hardware zou praten, dan zou je kunnen zeggen dat het geen emulatie is. ReactOS is hier een goed voorbeeld van: daar is geen sprake van emulatie, maar is de Windows API direct geimplementeerd.
Maar bij WINE gebruik je gewoon de onderliggende kernel en drivers van linux, en de daarbij behorende grafische omgeving etc.
Windows is een compleet OS, met verschillende lagen. Applicaties praten alleen tegen de API-laag aan. Daaronder heb je nog subsystemen, en daaronder dan de kernel en drivers.
WINE opereert op API-niveau, en dat houdt in dat WINE dus tegen de kernel en drivers van linux (of ander *nix-OS) moet praten. Hierdoor moet dus oa D3D vertaald worden naar OpenGL.
En dan praat je dus wel degelijk over een vorm van emulatie.
D3D en OpenGL opereren immers op hetzelfde niveau, en er wordt een vertaalslag gemaakt om de laag van het ene OS af te beelden op het andere.
Als WINE nu direct met de hardware zou praten, dan zou je kunnen zeggen dat het geen emulatie is. ReactOS is hier een goed voorbeeld van: daar is geen sprake van emulatie, maar is de Windows API direct geimplementeerd.
Maar bij WINE gebruik je gewoon de onderliggende kernel en drivers van linux, en de daarbij behorende grafische omgeving etc.
Het probleem zit em inderdaad vooral in de Direct3D en DirectX-functionaliteit, die angstvallig beschermd wordt door Microsoft. De omzetting van die commandos naar OpenGL is een gigantische ramp, en gebeurt op basis van redelijk gokwerk. Performance daar is dan ook het grote probleem, terwijl spellen die normaal al van OpenGL gebruikmaken het vaak echt beter doen. Helaas zijn die in de minderheid, omdat D3D en XNA en andere Microsoft-only tools gepushed worden naar game-developers. Als men dat verandert (en dat is aan de game-studios), wordt Linux supporten een heel stuk makkelijker.
Het is nou eenmaal zo dat Direct3D veel meer geoptimaliseerd is (specifiek voor Windows), en daarom vaak ook de voorkeur heeft bij developers, lijkt mij.
Nee, FreezeXJ heeft gelijk, MS heeft D3D jaren hard gepusht, het is niet alsof developers daar serieus enige invloed op gehad hebben; OpenGL was afhankelijk van (hw-accelerated) driver implementaties door GPU fabrikanten, terwijl MS afdwong dat GPU fabrikanten D3D ondersteuning inbouwde (ze hadden ook voor OpenGL kunnen kiezen; dat was tot die tijd de dominante 3D techniek, maarja, daar werd MS niet beter van); dus in theorie was er wel keuze-vrijheid, maar geen level-playing field.
Sterker nog; het was - ironisch genoeg - juist John Carmack die in 1997 publiekelijk D3D hekelde. Nee, de dominante van D3D heeft niets met developer-voorkeuren te maken hoor
Sterker nog; het was - ironisch genoeg - juist John Carmack die in 1997 publiekelijk D3D hekelde. Nee, de dominante van D3D heeft niets met developer-voorkeuren te maken hoor
Onzin. Het zijn juist ook vooral de developers geweest die DirectX gepushed hebben, zowel de hardware als software developers.
De ontwikkeling in OpenGL gingen tergend langzaam. Men dacht alleen aan de professionele industrie, en de game industrie werd buiten beschouwing gelaten. Alle nieuwe ontwikkelingen zaten in proprietaire extenties, die dus eigenlijk helemaal geen standaard vormen!
Zowel hard- en software developers waren dus heel erg blij met een moderne 3D standaard, die specifiek op hun wensen was gericht!
ATI heeft aan de basis gestaan van de programmeurbare shaders van Direct 9. Juist omdat zij van de proprietaire zut afwilden. En dat heeft ATI geen windeieren gelegd... Hun Radeon was in DX9 tweemaal zo snel als NVidia en veroverde de markt. En er zaten nauwelijks nog ongebruikte feature in. Daarna heeft DirectX gewoon de hardware ontwikkeling bepaald.
Ook de game developers hebben heel hard DX9 gepushed. Voor hun was het heel belangrijker om: Eén standaard te hebben die voor alle hardware werkt, en die de programmeur volle flexibliteit geeft, en up-to-date is met de hardware mogelijkheden.
DirectX levert ze dat, en OpenGL simpelweg niet.
OpenGL stond gewoon stil... en DirectX is er simpelweg voorbij gereden, en over de horizon verdwenen.
De ontwikkeling in OpenGL gingen tergend langzaam. Men dacht alleen aan de professionele industrie, en de game industrie werd buiten beschouwing gelaten. Alle nieuwe ontwikkelingen zaten in proprietaire extenties, die dus eigenlijk helemaal geen standaard vormen!
Zowel hard- en software developers waren dus heel erg blij met een moderne 3D standaard, die specifiek op hun wensen was gericht!
ATI heeft aan de basis gestaan van de programmeurbare shaders van Direct 9. Juist omdat zij van de proprietaire zut afwilden. En dat heeft ATI geen windeieren gelegd... Hun Radeon was in DX9 tweemaal zo snel als NVidia en veroverde de markt. En er zaten nauwelijks nog ongebruikte feature in. Daarna heeft DirectX gewoon de hardware ontwikkeling bepaald.
Ook de game developers hebben heel hard DX9 gepushed. Voor hun was het heel belangrijker om: Eén standaard te hebben die voor alle hardware werkt, en die de programmeur volle flexibliteit geeft, en up-to-date is met de hardware mogelijkheden.
DirectX levert ze dat, en OpenGL simpelweg niet.
OpenGL stond gewoon stil... en DirectX is er simpelweg voorbij gereden, en over de horizon verdwenen.
Inderdaad.
De tijd dat D3D enorme horror was, dat was lang geleden.
Daar is destijds (in de jaren 90) zelfs een petitie voor getekend onder ontwikkelaars. (incl ID soft)
Tegenwoordig is D3D een goede API met een met name erg goede SDK.
Carmack zelf heeft die een aantal keer al geprezen, dezelfde carmack die in de jaren 90 dus D3D (terecht) verguisde.
OpenGL/Linux zealots worden vermoeiend.
Windows is geen winME meer.... direct3D is niet meer de D3D van vroeger...
Anno 2013 is Windows i.c.m. D3D een uitstekend game platform.
De tijd dat D3D enorme horror was, dat was lang geleden.
Daar is destijds (in de jaren 90) zelfs een petitie voor getekend onder ontwikkelaars. (incl ID soft)
Tegenwoordig is D3D een goede API met een met name erg goede SDK.
Carmack zelf heeft die een aantal keer al geprezen, dezelfde carmack die in de jaren 90 dus D3D (terecht) verguisde.
OpenGL/Linux zealots worden vermoeiend.
Windows is geen winME meer.... direct3D is niet meer de D3D van vroeger...
Anno 2013 is Windows i.c.m. D3D een uitstekend game platform.
En later heeft Carmack D3D juist geprezen, omdat de prestaties van D3D in de loop der tijd sterk zijn verbeterd.Sterker nog; het was - ironisch genoeg - juist John Carmack die in 1997 publiekelijk D3D hekelde. Nee, de dominante van D3D heeft niets met developer-voorkeuren te maken hoor
Glide op en OpenGL konden al textures renderen toen D3D niet verder kwam dat flat shaded polygonen. D3D telt pas serieus mee sinds Directx 8.
Wat een onzin.
Ik heb zelf nog met Direct3D1 gewerkt (met een Apocalypse 3Dx kaartje), en die eerste versie kon al lang per-vertex shading (gouraud) en textures aan.
Hier een filmpje ervan: http://youtu.be/1BWbuUg8yvA
Ik vond Carmack's kritiek ook wel wat overdreven... Nee, D3D was niet de makkelijkste API, maar zo'n enorm ingewikkeld was het nou ook weer niet. Een beetje console-programmeur doet op XBox en PS3 nog steeds ongeveer hetzelfde als die oude D3D-versies: een command-buffer opbouwen en daar met de hand dingen in patchen. Het idee van MS was dan ook dat de D3D-commands direct in hardware geimplementeerd zouden gaan worden. Dan was D3D net zo lowlevel geweest als consoles. Maar dat gebeurde uiteindelijk niet, en is D3D een hogere abstractielaag gaan toepassen.
En OpenGL was helemaal nog niet beschikbaar voor consumenten toen Direct3D uitgebracht werd.
Lees de GLQuake readme er maar op na:
"At this time (march ’97), the only standard opengl hardware that can play
glquake reasonably is an intergraph realizm, which is a VERY expensive card."
Ik heb zelf nog met Direct3D1 gewerkt (met een Apocalypse 3Dx kaartje), en die eerste versie kon al lang per-vertex shading (gouraud) en textures aan.
Hier een filmpje ervan: http://youtu.be/1BWbuUg8yvA
Ik vond Carmack's kritiek ook wel wat overdreven... Nee, D3D was niet de makkelijkste API, maar zo'n enorm ingewikkeld was het nou ook weer niet. Een beetje console-programmeur doet op XBox en PS3 nog steeds ongeveer hetzelfde als die oude D3D-versies: een command-buffer opbouwen en daar met de hand dingen in patchen. Het idee van MS was dan ook dat de D3D-commands direct in hardware geimplementeerd zouden gaan worden. Dan was D3D net zo lowlevel geweest als consoles. Maar dat gebeurde uiteindelijk niet, en is D3D een hogere abstractielaag gaan toepassen.
En OpenGL was helemaal nog niet beschikbaar voor consumenten toen Direct3D uitgebracht werd.
Lees de GLQuake readme er maar op na:
"At this time (march ’97), the only standard opengl hardware that can play
glquake reasonably is an intergraph realizm, which is a VERY expensive card."
[Reactie gewijzigd door Scalibq op 7 februari 2013 11:58]
MS heeft de directX standaard zelf ingevoerd, dus nogal wiedes dat die voor hun geoptimaliseerd is.
OpenGL is/was, net als de VESA(voor gewoon 2D resoluties) standaard in eerste instantie in de hardware geregeld. Aan het einde van het dos-tijdperk loste men dit op met TSR's zoals univbe, maar met matig tot slechte resultaten qua performance op kaarten die de functionaliteit niet in hardware hadden.
Ik ga pas echt hard lachen als WINE een betere performance geeft op dezelfde machine als Native windows.
OpenGL is/was, net als de VESA(voor gewoon 2D resoluties) standaard in eerste instantie in de hardware geregeld. Aan het einde van het dos-tijdperk loste men dit op met TSR's zoals univbe, maar met matig tot slechte resultaten qua performance op kaarten die de functionaliteit niet in hardware hadden.
Ik ga pas echt hard lachen als WINE een betere performance geeft op dezelfde machine als Native windows.
Juist helemaal niet.
OpenGL is ooit ontstaan uit IrisGL, wat in eerste instantie een software-renderer was.
SGI is daarna delen van de rendering pipeline gaan versnellen met hardware (in eerste instantie gewoon wat FP co-processors, later meer custom rasterizer hardware etc).
Uiteindelijk draaide het vrijwel volledig in hardware... op extreem dure custom SGI-hardware dan.
De gemiddelde PC-accelerator ondersteunde nog niet de helft van de standaard OpenGL-functionaliteit, in de jaren 90.
Daarom had 3d-acceleratie in eerste instantie ook meer succes met Glide, een API die wel dicht op de hardware stond. Later kwam er GLQuake, en ging men 'MiniGL'-drivers maken. Drivers die een subset van OpenGL implementeerden, net genoeg om GLQuake te kunnen draaien (en later ook afgeleiden daarvan, zoals Half-Life). Dat is dus GEEN OpenGL.
Direct3D van Microsoft was dan ook niet in de markt gezet als concurrent van OpenGL, maar juist als hardware-onafhankelijk alternatief voor Glide (en andere native APIs, zoals PowerSGL voor PowerVR).
Maar de 3d-hardware ontwikkelde zich snel, en vooral nVidia maakte zich sterk voor volledige OpenGL-ondersteuning. Na een aantal jaren was het dus wel mogelijk om OpenGL te draaien op een normale PC.
Bij Microsoft ging het de andere kant op: in plaats van dat de hardware naar de API toe groeide, maakte Microsoft een aantal behoorlijk rigoreuze updates aan de API, om steeds me de hardware mee te groeien.
Uiteindelijk heeft D3D het van OpenGL gewonnen omdat de drivers van betere kwaliteit zijn (voornamelijk omdat de API geimplementeerd is in een shared runtime, en de drivers alleen een hele lowlevel interface naar de hardware implementeren, waar iedre OpenGL driver een eigen runtime heeft, en er nogal wat verschillen/bugs/etc kunnen zijn tussen verschillende vendors), en omdat Microsoft D3D heel gebruiksvriendelijk heeft gemaakt, met een SDK vol met bruikbare voorbeelden, achtergrondinformatie, tools etc.
OpenGL is ooit ontstaan uit IrisGL, wat in eerste instantie een software-renderer was.
SGI is daarna delen van de rendering pipeline gaan versnellen met hardware (in eerste instantie gewoon wat FP co-processors, later meer custom rasterizer hardware etc).
Uiteindelijk draaide het vrijwel volledig in hardware... op extreem dure custom SGI-hardware dan.
De gemiddelde PC-accelerator ondersteunde nog niet de helft van de standaard OpenGL-functionaliteit, in de jaren 90.
Daarom had 3d-acceleratie in eerste instantie ook meer succes met Glide, een API die wel dicht op de hardware stond. Later kwam er GLQuake, en ging men 'MiniGL'-drivers maken. Drivers die een subset van OpenGL implementeerden, net genoeg om GLQuake te kunnen draaien (en later ook afgeleiden daarvan, zoals Half-Life). Dat is dus GEEN OpenGL.
Direct3D van Microsoft was dan ook niet in de markt gezet als concurrent van OpenGL, maar juist als hardware-onafhankelijk alternatief voor Glide (en andere native APIs, zoals PowerSGL voor PowerVR).
Maar de 3d-hardware ontwikkelde zich snel, en vooral nVidia maakte zich sterk voor volledige OpenGL-ondersteuning. Na een aantal jaren was het dus wel mogelijk om OpenGL te draaien op een normale PC.
Bij Microsoft ging het de andere kant op: in plaats van dat de hardware naar de API toe groeide, maakte Microsoft een aantal behoorlijk rigoreuze updates aan de API, om steeds me de hardware mee te groeien.
Uiteindelijk heeft D3D het van OpenGL gewonnen omdat de drivers van betere kwaliteit zijn (voornamelijk omdat de API geimplementeerd is in een shared runtime, en de drivers alleen een hele lowlevel interface naar de hardware implementeren, waar iedre OpenGL driver een eigen runtime heeft, en er nogal wat verschillen/bugs/etc kunnen zijn tussen verschillende vendors), en omdat Microsoft D3D heel gebruiksvriendelijk heeft gemaakt, met een SDK vol met bruikbare voorbeelden, achtergrondinformatie, tools etc.
Een goed verhaal, maar de laatste alinea verdient een update: Direct3D heeft het natuurlijk gewonnen op de Windows PC-markt, maar er is geen sprake van een definitieve winnaar. Op Windows zullen Direct3D drivers misschien ook beter zijn dan OpenGL drivers, maar het is natuurlijk niet zo dat Direct3D drivers per definitie beter zijn dan die voor OpenGL.
Er is niks mis met Direct3D op Windows. Ga je verder kijken dan alleen Windows - iets wat de gehele markt momenteel aan het doen is - dan kom je onvermijdelijk bij OpenGL uit.
@Scalibq hieronder: Wat ik probeer duidelijk te maken is dat de wereld groter is dan Windows alleen. Dat zorgt er dus ook voor dat mensen voor OpenGL kiezen zelfs als ze voor Windows ontwikkelen omdat ze niet alleen maar voor Windows willen ontwikkelen.
Als voorbeeld, Windows Phone wordt bij de ontwikkelen van spellen gehinderd omdat ze Direct3D gebruiken terwijl games voor Android en iOS OpenGL gebruiken. Dit is precies omgekeerd aan hoe de Mac en Linux gehinderd worden door hun gebrek aan Direct3D op de desktop markt.
Ja, Direct3D heeft gewonnen wat betreft PC's, maar niet wat betreft de markt als geheel.
Er is niks mis met Direct3D op Windows. Ga je verder kijken dan alleen Windows - iets wat de gehele markt momenteel aan het doen is - dan kom je onvermijdelijk bij OpenGL uit.
@Scalibq hieronder: Wat ik probeer duidelijk te maken is dat de wereld groter is dan Windows alleen. Dat zorgt er dus ook voor dat mensen voor OpenGL kiezen zelfs als ze voor Windows ontwikkelen omdat ze niet alleen maar voor Windows willen ontwikkelen.
Als voorbeeld, Windows Phone wordt bij de ontwikkelen van spellen gehinderd omdat ze Direct3D gebruiken terwijl games voor Android en iOS OpenGL gebruiken. Dit is precies omgekeerd aan hoe de Mac en Linux gehinderd worden door hun gebrek aan Direct3D op de desktop markt.
Ja, Direct3D heeft gewonnen wat betreft PC's, maar niet wat betreft de markt als geheel.
[Reactie gewijzigd door arendjr op 6 februari 2013 18:44]
Ben ik het niet mee eens. DirectX werkt alleen op Microsoft-platforms, en daar heeft het de strijd met OpenGL duidelijk gewonnen. Op andere platforms is DirectX nooit een optie geweest, dus kun je ook niet spreken van een strijd, en kan er ook geen winnaar zijn.
Je zin "Er is niets mis met Direct3D op Windows" is dan ook een beetje raar. Er is geen Direct3D op niet-Microsoft platforms. En als het er niet is, kan er ook niets mis mee zijn. En als Direct3D er wel was op andere platforms, dan had het vanzelfsprekend ook dezelfde voordelen ten opzichte van OpenGL op die platforms.
De opkomst van mobiele devices en OpenGL ES heeft wel duidelijk gemaakt dat OpenGL uit een HELE diepe winterslaap moest ontwaken, en een deel van de updates aan de API in 3.x en 4.x zijn dan ook meer om de legacy uit OpenGL te verwijderen en meer gelijk te trekken met OpenGL ES (en indirect ook met Direct3D: alles puur gebaseerd op shaders en buffer-objecten).
Vooralsnog heeft deze 'comeback' van OpenGL nog geen effect gehad op Windows (en dus vrijwel de hele PC-gaming markt). OpenGL games op Windows zijn nog steeds hoge uitzondering.
Verder kun je inderdaad niet stellen dat Direct3D-drivers per definitie beter zijn (wat ik dus ook niet gedaan heb: ik verwees naar de praktijk op Windows). Maar, je kunt wel stellen dat het Direct3D-model van een shared runtime en minimale driver voordelen heeft bij het ontwikkelen van kwalitatief goede drivers. Je ziet dan ook in de OpenGL-wereld dat men met Gallium3D een vergelijkbaar ontwerp aan het introduceren is.
Je zin "Er is niets mis met Direct3D op Windows" is dan ook een beetje raar. Er is geen Direct3D op niet-Microsoft platforms. En als het er niet is, kan er ook niets mis mee zijn. En als Direct3D er wel was op andere platforms, dan had het vanzelfsprekend ook dezelfde voordelen ten opzichte van OpenGL op die platforms.
De opkomst van mobiele devices en OpenGL ES heeft wel duidelijk gemaakt dat OpenGL uit een HELE diepe winterslaap moest ontwaken, en een deel van de updates aan de API in 3.x en 4.x zijn dan ook meer om de legacy uit OpenGL te verwijderen en meer gelijk te trekken met OpenGL ES (en indirect ook met Direct3D: alles puur gebaseerd op shaders en buffer-objecten).
Vooralsnog heeft deze 'comeback' van OpenGL nog geen effect gehad op Windows (en dus vrijwel de hele PC-gaming markt). OpenGL games op Windows zijn nog steeds hoge uitzondering.
Verder kun je inderdaad niet stellen dat Direct3D-drivers per definitie beter zijn (wat ik dus ook niet gedaan heb: ik verwees naar de praktijk op Windows). Maar, je kunt wel stellen dat het Direct3D-model van een shared runtime en minimale driver voordelen heeft bij het ontwikkelen van kwalitatief goede drivers. Je ziet dan ook in de OpenGL-wereld dat men met Gallium3D een vergelijkbaar ontwerp aan het introduceren is.
Kun je niet gewoon een nieuwe reactie plaatsen? Dat is veel leesbaarder dan edits.
Verder weet iedereen al lang dat de wereld groter is dan Windows alleen, games op linux is immers het topic hier.
Daarnaast heb je het helaas fout. Mensen kiezen zelfs als ze voor meerdere platforms ontwikkelen meestal toch voor Direct3D onder Windows. Ironisch genoeg is Carmack hierop de uitzondering.
De grote game-engines zoals Source, FrostBite, CryEngine en Unreal ondersteunen allemaal meerdere platforms, maar de Windows-versie is Direct3D.
Voor mezelf geldt dit ook: ik heb een OpenGL ES-engine voor Android en iOS, en een 'gewone' OpenGL-variant voor linux, FreeBSD en OS X (een simpele variant hiervan is ook opensource onder BSD-licentie). In theorie werkt deze ook op Windows, maar ik gebruik hem daar niet. Ik heb daar een Direct3D variant.
Ik denk dat jij graag wil dat er voor OpenGL wordt gekozen op Windows, maar dat maakt het nog niet waar.
Windows Phone werd gehinderd, maar nu niet meer, omdat Windows 8 'gewone' D3D9 code mogelijk maakt op telefoons en tablets. En D3D9 engines zijn er meer dan genoeg.
Zie bv dit artikel: http://www.theverge.com/2...e-8-directx-mobile-gaming
Verder weet iedereen al lang dat de wereld groter is dan Windows alleen, games op linux is immers het topic hier.
Daarnaast heb je het helaas fout. Mensen kiezen zelfs als ze voor meerdere platforms ontwikkelen meestal toch voor Direct3D onder Windows. Ironisch genoeg is Carmack hierop de uitzondering.
De grote game-engines zoals Source, FrostBite, CryEngine en Unreal ondersteunen allemaal meerdere platforms, maar de Windows-versie is Direct3D.
Voor mezelf geldt dit ook: ik heb een OpenGL ES-engine voor Android en iOS, en een 'gewone' OpenGL-variant voor linux, FreeBSD en OS X (een simpele variant hiervan is ook opensource onder BSD-licentie). In theorie werkt deze ook op Windows, maar ik gebruik hem daar niet. Ik heb daar een Direct3D variant.
Ik denk dat jij graag wil dat er voor OpenGL wordt gekozen op Windows, maar dat maakt het nog niet waar.
Windows Phone werd gehinderd, maar nu niet meer, omdat Windows 8 'gewone' D3D9 code mogelijk maakt op telefoons en tablets. En D3D9 engines zijn er meer dan genoeg.
Zie bv dit artikel: http://www.theverge.com/2...e-8-directx-mobile-gaming
[Reactie gewijzigd door Scalibq op 6 februari 2013 22:22]
Kwam DirectX en net zoals vele andere programma's niet mee met Windows zelf? Ik denk dat je daar je antwoord hebt. MS wil zijn OS kunnen blijven verkopen. Als alles straks op Linux uit te voeren valt (Gratis, en goede alternatieven vindbaar) dan raakt MS dit ook aangezien dit impact heeft op verkopen. Je zou immers een PC in de toekomst kunnen kopen met een Linux (Gratis) licentie, en betaal je bijv alleen voor een setup-disk die de gehele installatie uitvoert voor je op je PC.
Wine is een goed alternatief. Ik denk zowiezo dat Linux voor mij ook interessant is. Zonder toeters en bellen, gewoon doen waarvoor een PC bedoeld was.
Mischien ligt het aan mijn leeftijd, maar ik ben niet echt te porren geweest voor een OS met metro interface en dergelijk.
Ik denk dat je daar je antwoord hebt. MS wil zijn OS kunnen blijven verkopen. Als alles straks op Linux uit te voeren valt (Gratis, en goede alternatieven vindbaar) dan raakt MS dit ook aangezien dit impact heeft op verkopen. Je zou immers een PC in de toekomst kunnen kopen met een Linux (Gratis) licentie, en betaal je bijv alleen voor een setup-disk die de gehele installatie uitvoert voor je op je PC.Wine is een goed alternatief. Ik denk zowiezo dat Linux voor mij ook interessant is. Zonder toeters en bellen, gewoon doen waarvoor een PC bedoeld was.
Mischien ligt het aan mijn leeftijd, maar ik ben niet echt te porren geweest voor een OS met metro interface en dergelijk.
Hoezo? Bij Windows 95/98 werd DirectX sowieso bij elk spel gewoon meegeleverd. Wat in windows zat was tegen de tijd dat je er een spel op installeerde al dusdanig verouderd dat het toch geen nut meer had (volgens mij werd 98 standaard met Dx5 of Dx6 geleverd terwijl 7 al uit was).
Fabrikanten van games hadden ook prima OpenGl mee kunnen leveren bij games, maar ze kozen toch massaal voor DirectX. Omdat het gewoon beter was voor games, niet omdat MS het liep te pushen.
Fabrikanten van games hadden ook prima OpenGl mee kunnen leveren bij games, maar ze kozen toch massaal voor DirectX. Omdat het gewoon beter was voor games, niet omdat MS het liep te pushen.
Bij DirectX kon en kan dat omdat je de runtime (API-implementatie) update. De onderliggende drivers werken via een lowlevel driver-interface, en hierdoor kun je (meestal) een nieuwere versie van DirectX draaien op oudere drivers (zij het dat je dan natuurlijk niet alle nieuwe features kunt gebruiken).
Bij OpenGL zit de runtime in de display driver zelf. De enige manier om OpenGL te updaten is dus om je display drivers te updaten. Dat zou betekenen dat bij iedere game ook de display drivers voor iedere mogelijke videokaart meegeleverd moeten worden. Dat is dus niet echt een handige optie.
Sowieso is het een stuk rigoreuzer om een display driver te updaten dan een nieuwe API-runtime te introduceren. Microsoft's DirectX APIs zijn COM-interfaces, en de oude interfaces blijven dus gewoon ongewijzigd bestaan. Hierdoor zal een update geen problemen introduceren bij bestaande applicaties. Bij een nieuwe display driver komt het nogal eens voor dat bestaande applicaties niet goed meer werken.
Bij OpenGL zit de runtime in de display driver zelf. De enige manier om OpenGL te updaten is dus om je display drivers te updaten. Dat zou betekenen dat bij iedere game ook de display drivers voor iedere mogelijke videokaart meegeleverd moeten worden. Dat is dus niet echt een handige optie.
Sowieso is het een stuk rigoreuzer om een display driver te updaten dan een nieuwe API-runtime te introduceren. Microsoft's DirectX APIs zijn COM-interfaces, en de oude interfaces blijven dus gewoon ongewijzigd bestaan. Hierdoor zal een update geen problemen introduceren bij bestaande applicaties. Bij een nieuwe display driver komt het nogal eens voor dat bestaande applicaties niet goed meer werken.
[Reactie gewijzigd door Scalibq op 6 februari 2013 13:04]
Je vergeet alleen dat als Microsoft geen geld meer verdient aan D3D, dat ze het dan uiteindelijk gewoon zullen droppen. En dan kun je met Wine ook nergens meer heen, want al wat die doen is achter Microsoft aanhobbelen.
"Follow the leader" werkt alleen zolang de leader nog aan de race meedoet.
"Follow the leader" werkt alleen zolang de leader nog aan de race meedoet.
Native is toch altijd sneller dan het omzetten van DirectX instructies naar OpenGL? Het lijkt me daarom dat je in Linux een snellere CPU / GPU nodig hebt, om met Wine eenzelfde framerate nodig hebt, dan in Windows. Zelfs als Wine perfect is en werkt, moeten er nog instructies worden omgezet.
Bovendien kan je met DirectX alleen op Windows en de Xbox developen, met OpenGL op (vrijwel) alle moderne platforms.
Bovendien kan je met DirectX alleen op Windows en de Xbox developen, met OpenGL op (vrijwel) alle moderne platforms.
Sneller voor je cpu is het wel. Maar niet voor de developers.
De keuze voor hun is simpel:
- De open soucre community geld geven om 1 keer wine beter te maken
- Voor elke game apart de engine enz. aanpassen voor linux.
Hierdoor is de mening van id zeer begrijpelijk.
De keuze voor hun is simpel:
- De open soucre community geld geven om 1 keer wine beter te maken
- Voor elke game apart de engine enz. aanpassen voor linux.
Hierdoor is de mening van id zeer begrijpelijk.
Alleen zijn het vaak zelfs niet de gamedevs zelf die de port maken. 3D engines worden vaak aangekocht van een externe partij (zoals de engines van id) en daarbij koopt men dan ondersteuning voor bepaalde platformen.
In het verleden kwamen de Quake en Unreal titels beschikbaar onder Linux net omdat dit een mooie demo vomde om te tonen dat de engine op die platformen ook goed presteerd. Ik vind het dan ook vreemd dat iemand die zelf zijn eigen engine in het verleden met Linux gepromoot heeft nu ineens tegen het porten is.
In het verleden kwamen de Quake en Unreal titels beschikbaar onder Linux net omdat dit een mooie demo vomde om te tonen dat de engine op die platformen ook goed presteerd. Ik vind het dan ook vreemd dat iemand die zelf zijn eigen engine in het verleden met Linux gepromoot heeft nu ineens tegen het porten is.
idSoftware is een tijdje geleden zijn programmeur die de Linux ports verzorgde kwijtgeraakt (de exacte reden is me niet precies duidelijk), dus nu id niet meer de (individuele) mankracht heeft om Linux ports te maken vindt Carmack dat ze dan maar Wine moeten gebruiken. Gecombineerd met z'n statement dat de Linux-versies van hun games nooit winst hebben opgeleverd is z'n standpunt wel begrijpelijk.
De andere kant van het verhaal is wel dat Carmack z'n mening op dit vlak zwaar achterloopt op de huidige realiteit. De laatste game die ze uitgebracht hebben voor Linux was de originele editie Doom 3, dus ze hebben uberhaupt geen cijfers over recente Linux ports. Bovendien werden de Linux ports vaak ter download aangeboden zonder de data files, wat betekende dat je de Windows-versie moest kopen, daar de data files uit moest kopieren naar je Linux-installatie en dan kon je het aan de praat krijgen. Vrij omslachtig dus, en het is me dan ook niet duidelijk hoe ze hier ooit betrouwbare cijfers aan hebben kunnen ontlenen omdat Linux-gebruikers nog steeds de Windows games moesten kopen.
Tenslotte is de aanpak die Valve neemt met een compleet distributiekanaal en de aanstaande push van de Steambox natuurlijk totaal niet vergelijkbaar met het uitbrengen van een handjevol individuele games met slechte support.
Ik heb veel respect voor John Carmack als programmeur, speel graag de games van idSoftware, en ben ook dankbaar voor de Linux ports die ze in het verleden hebben uitgebracht. Maar het is wel duidelijk dat Linux support nooit veel prioriteit voor ze heeft gehad. Dus als Carmack het heeft over 3D-technologie en games ben ik erg geinteresseerd, maar op dit vlak heeft 'ie niet veel autoriteit.
De andere kant van het verhaal is wel dat Carmack z'n mening op dit vlak zwaar achterloopt op de huidige realiteit. De laatste game die ze uitgebracht hebben voor Linux was de originele editie Doom 3, dus ze hebben uberhaupt geen cijfers over recente Linux ports. Bovendien werden de Linux ports vaak ter download aangeboden zonder de data files, wat betekende dat je de Windows-versie moest kopen, daar de data files uit moest kopieren naar je Linux-installatie en dan kon je het aan de praat krijgen. Vrij omslachtig dus, en het is me dan ook niet duidelijk hoe ze hier ooit betrouwbare cijfers aan hebben kunnen ontlenen omdat Linux-gebruikers nog steeds de Windows games moesten kopen.
Tenslotte is de aanpak die Valve neemt met een compleet distributiekanaal en de aanstaande push van de Steambox natuurlijk totaal niet vergelijkbaar met het uitbrengen van een handjevol individuele games met slechte support.
Ik heb veel respect voor John Carmack als programmeur, speel graag de games van idSoftware, en ben ook dankbaar voor de Linux ports die ze in het verleden hebben uitgebracht. Maar het is wel duidelijk dat Linux support nooit veel prioriteit voor ze heeft gehad. Dus als Carmack het heeft over 3D-technologie en games ben ik erg geinteresseerd, maar op dit vlak heeft 'ie niet veel autoriteit.
Welke (mainstream game-) developer heeft wat dat betreft dan wel autoriteit?Dus als Carmack het heeft over 3D-technologie en games ben ik erg geinteresseerd, maar op dit vlak heeft 'ie niet veel autoriteit.
ID heeft ten minste nog eens wat van hun games naar linux gepoort, en heeft er dus wel ervaring mee. De meeste developers beginnen er niet eens aan.
De ervaring van Valve is misschien te jong om van waarde te zijn, dus dan zou je naar de Humble Indie Bundles moeten kijken. Die laatsten zijn wel niet heel erg mainstream, maar hebben wel goede (en positieve!) ervaringen met Linux opgedaan.
De ervaring van idSoftware is echter zo'n 8 jaar outdated (release van Doom 3 port voor Linux), dus dat is niet echt veel meer waard.
De ervaring van idSoftware is echter zo'n 8 jaar outdated (release van Doom 3 port voor Linux), dus dat is niet echt veel meer waard.
WINE in een keer beter maken? WINE staat tot Achilles als Windows staat tot schildpad (wie dit niet herkent, zoek Zeno's paradoxen even op). WINE zal altijd achterlopen op Windows. Elke keer als Windows weer met iets nieuws komt zal het verouderd zijn. Naast dat het heel veel giswerk is en gepier, omdat men niet zomaar de API's van Microsoft mag reverse engineeren.
Het is inderdaad sneller om het native te doen, maar je moet niet vergeten dat het nauwelijks een zware klus is voor de CPU om die emulatie slag te maken. Momenteel is er nog redelijk wat overhead, dit komt vooral doordat MS zijn api erg beschermd. Als genoeg developers dit serieus willen gaan doen dan kan het niet anders dan dat MS hierin toch een beetje gaat meewerken (al is het maar omdat er steeds meer reverse-enginered zal worden en MS dan als good-guy wil opstellen door alsnog mee te werken).
De games van tegenwoordig leunen vooral op de GPU performance van je computer en zouden dus best een beetje CPU kunnen missen voor een emulatie laag.
Uiteraard heb je games als Far Cry 3 die dan toevallig erg veel van je CPU lusten, maar ik heb het hier over toekomstmuziek hè!
De games van tegenwoordig leunen vooral op de GPU performance van je computer en zouden dus best een beetje CPU kunnen missen voor een emulatie laag.
Uiteraard heb je games als Far Cry 3 die dan toevallig erg veel van je CPU lusten, maar ik heb het hier over toekomstmuziek hè!
[Reactie gewijzigd door chaoscontrol op 5 februari 2013 19:34]
Ik zie Wine eigenlijk alleen als noodoplossing voor games die niet veel vragen van je PC, op GPU en CPU gebied. Maar juist de games die niet heel veel van je PC vragen zijn meestal indie games en binnen de indie gemeenschap is de adoptie van OSx en Linux juist veel groter dan bij de big budget games die een veel groter budget hebben en meer baad hebben bij een native OSx of Linux poort.
Ik zou er niet aan moeten denken dat we bv. Planetary Annihalation straks via Wine op Linux zouden moeten laten draaien, als Supreme Commander enige indicatie is zou dat een killer zijn voor je CPU. Maar juist die ontwikkelaar produceert ook een OSx en Linux poort, net zoals een hoop andere succesvolle Kickstarter projecten...
Persoonlijk denk ik dat er meer ontwikkeld moet worden voor engines zoals bv. Unity, die maken porten zoveel makkelijker.
Ik zou er niet aan moeten denken dat we bv. Planetary Annihalation straks via Wine op Linux zouden moeten laten draaien, als Supreme Commander enige indicatie is zou dat een killer zijn voor je CPU. Maar juist die ontwikkelaar produceert ook een OSx en Linux poort, net zoals een hoop andere succesvolle Kickstarter projecten...
Persoonlijk denk ik dat er meer ontwikkeld moet worden voor engines zoals bv. Unity, die maken porten zoveel makkelijker.
[Reactie gewijzigd door Cergorach op 6 februari 2013 15:47]
Wat ik me afvraag, is of het wel efficiënt is om via Wine te werken. Ik hoop dat er een grote engine gaat komen in OpenGL zodat ontwikkelaars een beter basis hebben voor hun opkomende games.
Uiteindelijk is native het snelste dan de omzetting van DirectX naar OpenGL.
Uiteindelijk is native het snelste dan de omzetting van DirectX naar OpenGL.
[Reactie gewijzigd door Martindo op 5 februari 2013 19:06]
Ja, maar nu zijn er amper spellen voor Linux.
Als je kunt kiezen tussen bijna geen spellen, ondanks dat ze goed draaien, of bijna alle spellen die Windows ook heeft, maar met 10% minder performance, dan is de keus voor veel gamers snel gemaakt denk ik.
Als je kunt kiezen tussen bijna geen spellen, ondanks dat ze goed draaien, of bijna alle spellen die Windows ook heeft, maar met 10% minder performance, dan is de keus voor veel gamers snel gemaakt denk ik.
Het zal ook lang duren voordat grote developers naar Linux overstappen. Het begin moet i.m.o. gemaakt worden door de indie ontwikkelaars.
Was WINE maar zo ideaal dat je bijna alle spellen kon draaien (al was het met 90% prestatieverlies), en 10% verlies is ook erg optimistisch. Dan heb ik het nog niet over bugs die WINE veroorzaakt en het feit dat de boel na een patch van Microsoft alweer helemaal moet worden aangepast. WINE is gewoon geen oplossing. Het is altijd verouderd, op elk willekeurig moment, zelfs al zat Carmack in eigen persoon samen met nog wat goeroes er nonstop aan te prutsen, het is altijd vol met bugs zolang Microsoftzijn bbroncode niet openbaar maakt en het is altijd ducttape-/gokwerk, ook zolang die broncode niet openbaar wordt (gaat nooit gebeuren). Of Microsoft moet zelf WINE gaan ontwikkelen, en hier serieus mee bezig gaan. Alleen dan acht ik het nog enigszins kansrijk (en zelfs dan eigenlijk nog niet, krijg je nog meer MS-typische bugs en gaten in je beveiliging mee dan je nu al met WINE hebt, ik ben juistaan LLinux begonnen om hier van weg te raken).
die zijn er al, bijna alle grote engines hebben ook opengl als mogelijkheid.. oa ivm bv de ps3 die wel opengl ondersteund, maar geen directx.
Behalve dan dat de PS3 geen OpenGL ondersteunt...
Hooguit OpenGL ES 1.1 (die nog niet eens shaders ondersteunt), met een hoop custom extensions erbovenop, wel PSGL genoemd. Totaal niet compatible met OpenGL op een PC:
http://en.wikipedia.org/wiki/PSGL
De meeste PS3 games gebruiken echter een meer lowlevel interface, LibGCM, of direct op de hardware programmeren.
Ik word een beetje moe van dat klok-en-klepel gedoe over PS3 en OpenGL.
Hooguit OpenGL ES 1.1 (die nog niet eens shaders ondersteunt), met een hoop custom extensions erbovenop, wel PSGL genoemd. Totaal niet compatible met OpenGL op een PC:
http://en.wikipedia.org/wiki/PSGL
De meeste PS3 games gebruiken echter een meer lowlevel interface, LibGCM, of direct op de hardware programmeren.
Ik word een beetje moe van dat klok-en-klepel gedoe over PS3 en OpenGL.
Investeert ID dan in WINE? Lijkt me toch dat ze zelf wel door hebben dat een emu niet echt de oplossing is voor iets wat high performance is.
Dat hangt er maar vanaf, een goeie emu die misschien een paar procent power kost is een uitstekende vervanging van het volledig opnieuw compilen en supporten van je userbase. Ook bij moderne games wordt er slordig omgesprongen met aanwezige supplies, en trucs als de inverse sqrt moeten al in de software zitten, anders boeit het niemand. Kost namelijk tijd, en games hadden gisteren af moeten zijn. Met de huidige complexiteit is er dan ook veel efficiency te winnen vaak (zie Crysis 2, dat 10+% sneller werd na een patch, hoogstwaarschijnlijk wegens sloppy code).
ps, vergelijk maar eens een Java VM met een C-programma op snelheid. Maakt weinig meer uit hoor, tenzij je high performance computing doet, en zelfs daar...
ps, vergelijk maar eens een Java VM met een C-programma op snelheid. Maakt weinig meer uit hoor, tenzij je high performance computing doet, en zelfs daar...
Waarom niet? Het is niet zo dat Wine een virtual machine is (hoewel dat met HW ondersteuning tegenwoordig ook rap is) of dat het een OS op een OS is. Wine is gewoon een Windows API implementatie, niet anders dan Posix dat is voor Linux. Eigenlijk het spiegelbeeld van Cygwin op Windows wat een Posix implementatie is op Windows.
Echter Wine gaat verder en implementeert ook het hele Windows eco systeem met het register, in Windows bekende directory structuur en paden en Windows I/O. Maar bij een goede implementatie zou het net zo snel moeten kunnen als Windows op dezelfde hardware, op een paar dingen na.
Ten eerste de efficiëntie van de Kernel. Windows kernel vs Linux kernel. Ik kan niet zeggen welke sneller is maar wel dat het anders is, zeker de scheduler bijvoorbeeld. Ten tweede de window manager. Uiteindelijk komt het uit bij Xwindows en open GL en die werkt gegarandeerd anders dan de manager in Windows. Wederom niet gezegd welke sneller is, maar anders in elk geval.
Maar wat het verschil ook is, de verschillen komen niet door een emulatie met vertaling naar wat anders maar door verschillen in het fundament van beide OSsen. Zowel Posix als WinApi zijn libraries die direct praten met de Linux kernel drivers en API.
Echter Wine gaat verder en implementeert ook het hele Windows eco systeem met het register, in Windows bekende directory structuur en paden en Windows I/O. Maar bij een goede implementatie zou het net zo snel moeten kunnen als Windows op dezelfde hardware, op een paar dingen na.
Ten eerste de efficiëntie van de Kernel. Windows kernel vs Linux kernel. Ik kan niet zeggen welke sneller is maar wel dat het anders is, zeker de scheduler bijvoorbeeld. Ten tweede de window manager. Uiteindelijk komt het uit bij Xwindows en open GL en die werkt gegarandeerd anders dan de manager in Windows. Wederom niet gezegd welke sneller is, maar anders in elk geval.
Maar wat het verschil ook is, de verschillen komen niet door een emulatie met vertaling naar wat anders maar door verschillen in het fundament van beide OSsen. Zowel Posix als WinApi zijn libraries die direct praten met de Linux kernel drivers en API.
Wat veel anderen niet door hebben is dat het veel tijd en geld kost om een efficiente game API te ontwikkelen.Investeert ID dan in WINE? Lijkt me toch dat ze zelf wel door hebben dat een emu niet echt de oplossing is voor iets wat high performance is.
Natuurlijk kan het efficienter dan dmv Wine - maar hoe lang wil je daar op wachten, of hoeveel miljoenen euros wil je doneren?
Ondanks de vele middelen die MS heeft en ondanks dat ze voor hun eigen OS ontwikkelen heeft het heeft MS 5 jaar gekost om directx goed bruikbaar te maken (directx 1 ~ directx
. http://en.wikipedia.org/wiki/DirectX#History
Het grote probleem dat er momenteel bij Wine is dat je vaak bestanden moet gaan aanpassen om een game werkend te krijgen. (Hoewel de support van de community heel groot is) kan dit voor een leek heel moeilijk zijn.
Verder is het vaak zo dat na een update van de game, de game niet meer werkt in Wine.
Van FPS en Lag heb ik bijna nooit last gehad met Wine. (speelde dan wel niet echt grafisch sterke games).
Ik zou liever een goede port zien eerlijk gezegd dan het allemaal via Wine te moeten instellen en prullen.
Verder is het vaak zo dat na een update van de game, de game niet meer werkt in Wine.
Van FPS en Lag heb ik bijna nooit last gehad met Wine. (speelde dan wel niet echt grafisch sterke games).
Ik zou liever een goede port zien eerlijk gezegd dan het allemaal via Wine te moeten instellen en prullen.
Die aangepaste instellingen komen omdat Wine niet mag reverse-engineren, en dus alle code zelf moet uitvogelen. Hele grote stukken van wat er zou moeten zijn bestaan nog uit <stub>, oftewel: komt nog als iemand er tijd voor heeft en het noodzakelijk wordt. Als men nu 1x de zaak goed aanpakt hebben we een stuk minder gebroken games, en is iedereen blij (op Microsoft na, want die zien de gamers vertrekken).
Grootste probleem is dat Windows een platform is dat continue in beweging is. Wine zal altijd achterlopen op dit platform en er zullen altijd gaten in zijn. Je kan dus niet 1x de zaak goed aanpakken en zeggen dat je klaar bent want bij de volgende patch tuesday van MS kan alles al weer om zeep zijn.
Maar goed, welk probleem heeft Wine dan als ze het wel reverse-engineeren? Wie moet microsoft aanklagen? Open-source, dus geen eigenaar, en er kán dus helemaal niemand aangeklaagd worden.
Wine mag wel reverse engineren, en dat doen ze ook (net zoals het Samba team jaren gedaan heeft, tot dat de EU besloot dat Microsoft moet meewerken). In veel landen, o.a. de VS en Nederland, is er een speciale uitzondering in de wet voor reverse engineren.
OpenGL games kunnen toch ook onder windows native draaien. Ik heb me altijd al afgevraagd waarom ze dat niet gewoon doen.
Microsoft heeft Directx behoorlijk gepusht destijds en tegenwoordig heb je ook nog de xbox die geen opengl ondersteunt.
D3D is meer gericht op game ontwikkelaars dan OpenGL, wat een van de reden was dat Microsoft zo makkelijk iedereen voor zich kon winnen: hun platform stond, en staat, gewoon voor op OpenGL. Er hebben zelfs petities de ronden gedaan op D3D weid verspreid te krijgen.
Voor Mac zijn er ook zogeheten 'Cider' ports die met Wine werken. Zit echt een walgelijk bedrijf achter en de ports zijn meestal belachelijk slecht. Bij Spore Galactic Adventures werkte zelfs de halve functionaliteit van de game niet.
Toch heeft bijvoorbeeld Guild Wars 2 juist WEL goede performance, en draaien Source games op de Mac sneller in Wine dan de native versies.
In ieder geval zou ik geen slechte ports aanmoedigen, native is meestal gewoon beter.
Toch heeft bijvoorbeeld Guild Wars 2 juist WEL goede performance, en draaien Source games op de Mac sneller in Wine dan de native versies.
In ieder geval zou ik geen slechte ports aanmoedigen, native is meestal gewoon beter.
[Reactie gewijzigd door Wolfos op 5 februari 2013 19:19]
Ik ben dit niet met carmack eens.
Hoewel ik graag een Wine oplossing in steam zie verschijnen voor de non native games die er prima op werken gaat er natuurlijk niets boven een native oplossing.
Het is juist de kunst aan de engine bouwers zoals Unreal Engine en Unity om met een goede linux ondersteuning te komen (unity heeft dit zelfs nu al).
Je investeerd 1 keer in een engine met een universe script taal en hebt er vervolgens voor alle projecten profeit van en het zou dan ook niet meer development time moeten kosten.
Van carmack had ik als engine pioneer dan ook wel beter verwacht tenslotte zijn er al goede ports voor linux van zijn oude engines and het zou goed zijn als hij zijn talent zou gebruiken om het linux gamen te verbeteren inplaats van de emulators hiervoor.
Hoewel ik graag een Wine oplossing in steam zie verschijnen voor de non native games die er prima op werken gaat er natuurlijk niets boven een native oplossing.
Het is juist de kunst aan de engine bouwers zoals Unreal Engine en Unity om met een goede linux ondersteuning te komen (unity heeft dit zelfs nu al).
Je investeerd 1 keer in een engine met een universe script taal en hebt er vervolgens voor alle projecten profeit van en het zou dan ook niet meer development time moeten kosten.
Van carmack had ik als engine pioneer dan ook wel beter verwacht tenslotte zijn er al goede ports voor linux van zijn oude engines and het zou goed zijn als hij zijn talent zou gebruiken om het linux gamen te verbeteren inplaats van de emulators hiervoor.
Carmack verkoopt zijn engines en die zijn allemaal op Open-GL gebaseerd, voor de rest kan het hem helemaal niets uitmaken.
En bedankt.. Dit is weer zo'n reactie waarmee je als prominent in de bussiness, een belangrijke vooruitgang om zeep kan helpen ten behoeve van niks.
Ja, ik besef mij helemaal de ID software meer dan genoeg ervaring heeft met opensource (met name Linux) dan menig ander game developer.. Maar juist door dit soort uitspraken terwijl op het moment open source echt op de kaart staat, mensen het echt ook willen gebruiken omdat er ook grote namen in de game industrie echt effort er ook energie en geld erin willen steken. maar dit zodanig neer aan het sabelen bent vanwege redenen die mij onbekend zijn, ben je naar mijn inziens niet zuiver bezig.
Ja, ik besef mij helemaal de ID software meer dan genoeg ervaring heeft met opensource (met name Linux) dan menig ander game developer.. Maar juist door dit soort uitspraken terwijl op het moment open source echt op de kaart staat, mensen het echt ook willen gebruiken omdat er ook grote namen in de game industrie echt effort er ook energie en geld erin willen steken. maar dit zodanig neer aan het sabelen bent vanwege redenen die mij onbekend zijn, ben je naar mijn inziens niet zuiver bezig.
Op dit item kan niet meer gereageerd worden.
Onderwerpen
© 1998 - 2013 Tweakers.net B.V. onderdeel van De Persgroep, ook uitgever van Computable.nl, Autotrack.nl en Carsom.nl • Hosting door True
