Microsoft voegt zich bij Khronos Group en WebGL working group

Microsoft is lid geworden van de Khronos Group, de organisatie die onder andere verantwoordelijk is voor de OpenGL-standaarden. De softwaregigant zal ook zitting nemen in de werkgroep die de WebGL-standaard ontwikkelt.

Het toetreden van Microsoft tot de Khronos Group is bekendgemaakt op de Web3D-conferentie die in het afgelopen weekend in Vancouver werd gehouden. Microsoft is inmiddels ook te vinden in de lijst van bedrijven die deel uitmaken van de Khronos Group.

Naast het lidmaatschap bij de Khronos Group is Microsoft toegetreden tot de WebGL working group. Deze ontwikkelt de WebGL-standaard. WebGL wordt inmiddels door veel browsers ondersteund en maakt het mogelijk om 3d-beelden in browsers te tonen zonder dat er een plug-in nodig is.

Door deel uit te gaan maken van de werkgroep is Microsoft in staat om de verdere ontwikkeling van WebGL mede vorm te geven, terwijl de softwaregigant WebGL in 2011 nog gevaarlijk noemde en hintte op een eigen variant. Microsoft heeft in Internet Explorer 11 ondersteuning voor WebGL opgenomen. Of Microsoft ook ambities heeft om actief bij te dragen aan OpenGL, OpenGL ES en andere standaarden van de Khronos Group is nog niet duidelijk.

Reacties (60)

[Niemand_Anders]

Blijft toch grappig hoe iedereen Microsoft als 1 bedrijf blijft zien. Microsoft TFS komt standaard al met een git plugin (als vervanger van TF Source Control). De asp.net webstack en Entity Frameworks worden actief ontwikkelt op CodePlex en inmiddels accept Microsoft ook pull requests.

De development tak van Microsoft is al vele jaren zeer liberaal in vergelijking met de rest van het bedrijf. Afdelingen zoals die van Windows, office en de server (sql, exchange, biztalk, etc) producten zijn veel conservatiever als het gaat om kijkjes in de keuken en het vrijgeven van de roadmap.

Ironisch genoeg is het nu juist MSIE welke zich veel meer aan de standaarden houd dan de andere browsers. Dat het MSIE dan ook WebGL heeft toegevoegd kwam voor mij eigenlijk niet als zo'n grote verrassing. Eind jaren 90 ging de web evolutie erg hard door de concurrentie strijd tussen MSIE en Netscape. Na de eeuw wisseling is het allemaal een beetje in slaap gevallen tot in 2004 Mozilla met de lightweight browser Firebird kwam, later omgedoopt naar Firefox in 2005. Inmiddels kreeg Sarari met webkit ook steeds meer voeten aan de grond en langzaam maar zeker kwam web development weer in een stroomversnelling. Ajax technologie kreeg pas een echte boost met de komst van jQuery in 2006 waardoor er min of meer een abstractie laag kwam voor het werken met de verschillende browsers. In 2008 kwam Google met zijn Chrome browser. Initieel had Microsoft veel moeite om weer up to date te worden met de laatste technieken, maar de sprongen welke Microsoft in 5 jaar tijd tussen MSIE 8 en MSIE 11 heeft gemaakt zijn gewoon knap.

Mozilla heeft al meerdere malen aangegeven dat het moeite heeft om goede programmeurs binnen te halen en te houden. In het verleden hebben al meerdere developers de overstap van Mozilla na de concurrentie gemaakt. Firefox is inderdaad opensource, maar net als de Linux kernel is het aantal developers welke grote herstructureringen binnen dergelijke projecten kunnen voltooien maar dun gezaaid.

Veel developers zullen weleens geprobeert hebben een eigen javascript engine te schrijven. Hoe dicht kwam de performance van jouw engine in de buurt van bijvoorbeeld SpiderMonkey? Opera heeft zijn eigen engine al gedropped. Chrome en webkit zijn al lange tijd gefuseerd waardoor er momenteel maar drie browser engines zijn (trident, gecko en webkit).

Om goede concurrentie te behouden is het belangrijk dat er minimaal drie grote partijen op het toneel aanwezig zijn. Als dan een van de partijen de race even niet kan bijhouden, zijn de gevolgen minder groot. Dit is niet alleen zichtbaar op software niveau, maar ook op hardware niveau. Lange tijd heeft AMD de Intel processors kunnen bijhouden of zelfs vooruit te lopen. Toen Intel de overstap maakte naar de core series, had AMD eigenlijk geen antwoord en is eigenlijk steeds verder achterop geraakt. Nu Intel eigenlijk geen concurrentie meer heeft zie je ook dat de performance vooruit gang bij elke generatie steeds minder groot is..

[vinx77]

Volgens http://html5test.com/results/desktop.html heeft IE11 van de 55 te behalen punten een score van 376. Chrome, Firefox, Opera en Safari hebben alle vrier meer. Dus ik begrijp je punt niet helemaal dat IE11 zich meer aan de standaarden houdt dan de andere browsers.

Je vergelijking met proceaaoren is niet helemaal een juiste, behalve las je wou benadrukken hoe complex een browser is geworden doro al die toevoegingen. Qua procesoren speelt er meer af op multi-core en low-power dan in het begin van de Core-tijd, omdat er sinds 2006 de frequentie niet meer omhoog kon. De omslag duurt erg lang, omdat men een nieuwe wiel heeft moeten uitvinden. Daarbij is ondertussen het concurrentieveld is erg ingewikkeld met nieuwe concurrenten als ARM, Imagination en Qualcomm low-power chips, maar ook AMD/ATI en Nvidia GPUs. Grid-processoren als die van Parallella en Kalray proberen ook nog een graantje mee te pikken, terwijl FPGAs het afgelopen jaar ook grote stappen hebben gemaakt.

[alt-92]

Volgens http://html5test.com/results/desktop.html heeft IE11 van de 55 te behalen punten een score van 376.

Waarbij ze zelf al aangeven dat ze ook op non-standardized browser-specific dingen een score toekennen en daardoor automatisch een vertekend beeld geven.

Het lijkt verdomde veel op de EuroNCAP en verbruikscijfer trickery uit de auto industrie.

[Reactie gewijzigd door alt-92 op 23 juli 2024 06:14]

[vinx77]

Ok, dan luister ik naar Niemand_Anders die het gewoon uit de lucht grijpt.

Heb je http://html5test.com/compare/browser/chrome-36/ie-11.html bekeken en vergeleken met http://www.w3.org/TR/html5/? Ik niet, maar ik roep dan ook niet meteen dat de test niet deugt. Wat je wel kan doen is IE12 downloaden via http://www.winbeta.org/ne...internet-explorer-12-ie12 en kijken of de score hoger is.

[Verwijderd]

Microsoft is de laatste jaren inderdaad een heel stuk opener geworden. De vraag is of dit komt door een plotseling moreel besef, of dat deze openheid door marktomstandigheden tot stand is gekomen. Ik denk grotendeels het laatste.

In dit specifieke geval was Microsoft eerst tegen de komst van WebGL en deed niet aan de ondersteuning mee. Wat nu anders is tov 10 jaar geleden is dat het de wereld een stuk minder interesseert wat Microsoft/IE ondersteund. Als alle niet-IE browsers WebGL tot semi-standaard bombarderen, en Microsoft doet niet mee, dan is dat jammer, maar we gaan gewoon door. IE ondersteuning is nog steeds belangrijk, maar het is niet langer doorslaggevend. Bovendien is de wereld het al vele jaren gewend dat wanneer een feature ergens niet werkt, dit bijna altijd IE betreft.

[Loller1]

Correctie, 4 engines: Trident, Gecko, Webkit en Blink.

En als we dan toch bezig zijn, kunnen we ook nog alle varianten op Webkit en Blink die wijd gebruikt worden in verschillende Android versies er ook nog bij toevoegen.

[itarix]

Ik weet het niet. Microsoft heeft zelf Direct X en dat was / is altijd de grote concurrent van OpenGL geweest. Het aansluiten bij WebGL lijkt dan een vreemde zet. Misschien proberen ze op deze manier Direct X technologie de standaard in te pushen?

[miklas]

Microsoft was ook lang lid van de OpenGL group. (Het is zelf hun ongenoegen met OpenGL die hun heeft aangezet tot het ontwikkelen van DIrectX). Aangezien IE11 ondersteuning heeft voor WebGL lijkt het mij handig om mee te helpen aan de ontwikkeling er van (al dan niet om features in je eigen voordeel geïmplementeerd te krijgen).

DirectX technologie in de WebGL standaard krijgen lijkt mij moeilijk (gezien WebGL een subset van OpenGL is) en niet echt nuttig voor Microsoft als bedrijf.

[Reactie gewijzigd door miklas op 23 juli 2024 06:14]

[Verwijderd]

Hier meer info over de vroege jaren van OpenGL en Direct3D op Windows, van Alex St John, een van de ontwikkelaars van de eerste versies van DirectX: http://www.alexstjohn.com...he-evolution-of-direct3d/

[Verwijderd]

WebGL moet juist onafhankelijk zijn van de onderliggende platform technologie en dus niet van bijvoorbeel opengl of directz dus in dat opzicht lijkt me het juist geen probleem.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:14]

[cyberstalker]

Nee. WebGL is gebaseerd op de OpenGL ES 2.0 specificatie en heeft ook dezelfde semantiek. Aangezien de meeste drivers hier gewoon ondersteuning voor bieden is DirectX hierbij dus helemaal niet in the picture.

http://www.khronos.org/we...GL_and_OpenGL_Differences

[DrBearhands]

Niet helemaal waar. De WebGL standaard legt alleen de API vast, niet de daadwerkelijke implementatie.
Vaak worden (of werden in ieder geval, wellicht is dat recent veranderd) o.a. in Chrome en Firefox WebGL functies en shaders via ANGLE (https://code.google.com/p/angleproject/) omgezet naar DirectX code omdat OpenGL onder windows op vooral on-board GPU's niet altijd goed ondersteund werd.

[Verwijderd]

Behalve dan dat onder Windows zowel Chrome als FireFox gebruik maken van ANGLE: http://code.google.com/p/angleproject/
Dit vertaalt WebGL (dat dus heel erg op OpenGL lijkt) naar Direct3D.
Veilige aanname dat IE11 ongeveer hetzelfde doet, maar dan met code van MS zelf. MS was immers degene die als eerste aangaf dat het een groot veiligheidsprobleem was om geen laag tussen applicatie en driver te hebben.

[HooksForFeet]

En waarom zou het slecht zijn als DirectX-technologie in een open standaard werd gebruikt?

[ronaldmathies]

Omdat het dan geen standaard is, een standaard is juist zo bedacht dat je alleen afspraak maakt over de interface ( API ) en dat verachillende partijen een implementatie kunnen maken. DirectX werkt alleen op Microsoft operating systemen en het is een gesloten systeem.

OpenGL daarintegen is een open systeem wat op alle platformen ondersteund wordt wat het mer geschikt maakt om als standaard te functioneren.

[Caelorum]

En wat denk je dat er gebeurt als er wel dingen van DirectX in WebGL (een open standaard) komen? Wordt die dan minder open ofzo? Nee, dat betekent alleen dat MS delen weggeeft. Daarnaast vertaald Microsoft in IE11 al de WebGL calls naar Direct3D (wat wordt gebruikt voor rendering in IE) Het maakt hun dus niet uit of WebGL nu een subset is van OpenGL of niet.

[Reactie gewijzigd door Caelorum op 23 juli 2024 06:14]

[vinx77]

Als dat gebeurt, dan zijn de verschillende partijen overeen gekomen dat een bepaald onderdeel van DiectX overgenomen mag worden. Het is dan inderdaad niet minder open.

[acemoo]

Ze kunnen toch proberen om functies die hun fijn vinden uit direct x in de webgl standaard te krijgen en als hun dit lukt dan daarna kunnen ze dit implementeren en dan is het nog netjes open en standaard?

[freaky]

Als de functies die je nodig hebt om API call X te implementeren niet compleet dicht getimmerd zijn met patenten en andere juridische ellende wellicht wel.

[acemoo]

Als deze wel met patenten dicht getimmerd zijn, dan komen ze toch niet in de open webgl standaard?

[HooksForFeet]

Omdat het dan geen standaard is, een standaard is juist zo bedacht dat je alleen afspraak maakt over de interface ( API ) en dat verachillende partijen een implementatie kunnen maken. DirectX werkt alleen op Microsoft operating systemen en het is een gesloten systeem.

OpenGL daarintegen is een open systeem wat op alle platformen ondersteund wordt wat het mer geschikt maakt om als standaard te functioneren.

Ik maak hieruit op dat je niet begrijpt wat het werken aan een standaard precies inhoudt. Als Microsoft delen uit DirectX in de standaard stopt, dan worden die delen van DirectX juist open, door iedereen vrij te gebruiken en te implementeren. De standaard is dan dus net zo open, maar heeft ook meteen voordeel van de jaren aan tijd, geld en research die in dat deel van DirectX zijn gestoken. Alleen maar positief dus.

[Verwijderd]

1 nadeel, de ontwikkeling en voortgang ligt dan bij Microsoft. Krijg je IE praktijken van vroeger weer waar innovatie totaal niet vooruit te branden is.

[HooksForFeet]

Absoluut niet. Iedereen mag zelf ontwikkelen met en voortborduren op de delen die in de standaard staan.

[alt-92]

Ik noem één woord. Webkit.

[Fireshade]

Omdat het dan geen standaard is, een standaard is juist zo bedacht dat je alleen afspraak maakt over de interface ( API ) en dat verachillende partijen een implementatie kunnen maken. DirectX werkt alleen op Microsoft operating systemen en het is een gesloten systeem.

Wat niet is, kan zijn
PDF was ooit Adobe-only, nu reeds jaren een standaard (ISO 19005-1:2005).
Het 'beruchte' Open XML formaat van Microsoft als tegenhanger van ODF ook (ISO/IEC 29500-1:2011).

Microsoft neemt in dit geval natuurliik zitting in de groep om ook hun ideeen in de ontwikkeling te laten opnemen. Met de huidige strategie van Nadella heeft het weinig met Windows te maken, volgens mij -daar hebben ze vaak wel hun eigen oplossing voor. Ze zien in dat standaarden nodig te zijn om bepaalde marktontwikkelingen mogelijk te maken en zij willen niet (weer?) de achterlopers zijn.

[Reactie gewijzigd door Fireshade op 23 juli 2024 06:14]

[Verwijderd]

Indirect wordt dat al gedaan: Onder Windows maken zowel Chrome als FireFox gebruik van ANGLE: http://code.google.com/p/angleproject/
Dit vertaalt WebGL (dat dus heel erg op OpenGL lijkt) naar Direct3D.
WebGL wordt in de praktijk dus meestal op Direct3D gedraaid (mede vanwege betere driver-compatibiliteit en security (er zit nu een laag tussen applicatie-code en de driver, waardoor het veel lastiger is om exploits voor de driver te schrijven, want die zijn er wel: http://www.contextis.com/...ore-webgl-security-flaws/)

[Vayra]

Het gaat MS nooit lukken om DirectX universeel te krijgen zoals dat met OpenGL zou kunnen. Daar gaat de rest van de wereld niet aan beginnen. En MS wil wel platform-onafhankelijk innoveren. Dus ze moeten wel.

[acemoo]

Als Microsoft een linux implementatie van DirectX maakt komen ze al een heel eind.
De wereld is niet helemaal tegen DirectX, veel plekken kan je het gewoon niet gebruiken omdat Microsoft DirectX niet zo platform on afhankelijk wil hebben.

[Verwijderd]

Als Microsoft een linux implementatie van DirectX maakt komen ze al een heel eind.

Of een willekeurige andere organisatie.
Die is er al min of meer, met Wine, maar echt goed is die implementatie niet (alleen DX9 en lager werkt redelijk).
Waarschijnlijk is MS daar niet eens tegen, want ze hebben nooit de ontwikkelaars van Wine verboden om dit te doen, of ze aangeklaagd (sowieso is er al jurisprudentie dat je een API niet kunt copyrighten, dus MS zou sowieso niet zo sterk staan).
Carmack heeft ook al eens opgeroepen om gewoon DirectX goed te ondersteunen op linux: http://www.guru3d.com/new...form_for_video_games.html

Dus ik vraag me eigenlijk af waarom er nooit een organisatie is opgestaan die eens serieus is gaan werken aan de DirectX-implementatie in Wine.
Daarmee zouden veel games een stuk makkelijker naar linux, OS X etc geport kunnen worden, en dan wordt het misschien interessant genoeg voor een nVidia of een AMD om native DirectX drivers voor linux uit te gaan brengen ipv een vertaallaag op OpenGL.

[wpoely86]

Waarschijnlijk is MS daar niet eens tegen, want ze hebben nooit de ontwikkelaars van Wine verboden om dit te doen, of ze aangeklaagd (sowieso is er al jurisprudentie dat je een API niet kunt copyrighten, dus MS zou sowieso niet zo sterk staan).

Een serieuze veronderstelling. Zoiets doen zonder minstens de impliciete goedkeuring van Microsoft lijkt me geen goed idee. Wine is zo beperkt dat het totaal geen bedreiging voor MS vormt. Ik vraag me wat hun reactie zou zijn moest nVidia of AMD zoiets proberen.

Daarnaast is het implementeren van een API die volledig beheerd wordt door 1 bedrijf al vrij lastig. Je loopt altijd achter de feiten aan (zie mono, moonlight,...).

[Verwijderd]

Een serieuze veronderstelling. Zoiets doen zonder minstens de impliciete goedkeuring van Microsoft lijkt me geen goed idee.

Ik zeg ook niet dat ze het zonder goedkeuring moeten doen. Maar niemand heeft ooit uberhaupt onderzocht of Microsoft hier open voor staat. Daar gaat het al fout. Er is niet eens de intentie om DirectX naar linux te halen (naar de Mac overigens wel: http://www.macdx.com/)
Als ze de goedkeuring van MS niet krijgen, zouden ze het alsnog kunnen doen (Google heeft ook een groot deel van de Java-API van Oracle gebruikt zonder goedkeuring, en komt daar ook mee weg).

Daarnaast is het implementeren van een API die volledig beheerd wordt door 1 bedrijf al vrij lastig. Je loopt altijd achter de feiten aan (zie mono, moonlight,...).

DirectX niet... Daar komen maar eens in de paar jaar updates van uit, die bovendien allemaal onafhankelijk naast elkaar bestaan.

[blouweKip]

Aangezien direct3d (als onderdeel van directx) primair ontwikkeld is als verdediging/aanval op de platformonafhankelijkheid van opengl lijkt het me bij voorbaat al zinloos om het te proberen.
Daarnaast is de meerwaarde van direct3d op andere platformen nauwelijks aanwezig maar de nadelen zijn wel duidelijk, niemand zit te wachten op een mono variant van direct3d, opengl is daar verreweg superieur aan.

[Verwijderd]

Aangezien direct3d (als onderdeel van directx) primair ontwikkeld is als verdediging/aanval op de platformonafhankelijkheid van opengl lijkt het me bij voorbaat al zinloos om het te proberen.

Uhh, helemaal niet: http://www.alexstjohn.com...arly-direct3d-com-opengl/
Oorspronkelijk was het zelfs de bedoeling dat D3D het lowlevel-driver model was, en dat OpenGL 1 van de APIs was die daarop kwam te draaien.
Mensen die roepen dat OpenGL en D3D altijd al concurrenten van elkaar zijn geweest, hebben geen idee waar ze over praten.
OpenGL had een hele andere doelgroep: vooral de zakelijke mark met CAD/CAM etc, en hele dure high-end videokaarten.
Dat was ook het probleem met games: consumentenhardware was veel te beperkt om OpenGL te ondersteuenen. Daarom wilde MS eerst OpenGL uitbreiden met een soort caps-model, om ook low-end hardware te ondersteunen. Maar dat leidde tot een wildgroei aan mogelijkheden, en besloot men dus een nieuwe lowlevel API te ontwerpen: Direct3D.

Daarnaast is de meerwaarde van direct3d op andere platformen nauwelijks aanwezig

Niet?
Betere drivers, betere performance, betere documentatie, betere tools, veel meer software die geschikt is voor D3D.

maar de nadelen zijn wel duidelijk, niemand zit te wachten op een mono variant van direct3d, opengl is daar verreweg superieur aan.

Oh? Wat voor nadelen dan? En waar is OpenGL superieur dan?
OpenGL is enorm buggy, performance is doorgaans slecht, waardeloze documentatie, probleem is dat alles in de drivers zit ingebouwd, dus niet iedereen werkt met dezelfde versie van de runtime, en noem maar op.

[CH4OS]

Als Microsoft een linux implementatie van DirectX maakt komen ze al een heel eind.

De Linux-wereld leunt momenteel heel erg op OpenGL, omdat het een open standaard is. Laat MS dan eerder hun Windows OS beter laten aansluiten op OpenGL. OpenGL is op Windows namelijk veel minder performant dan op Linux.

Voor game ontwikkelaars wordt dan vervolgens de lat lager gelegd om over te stappen naar OpenGL en dus crossplatform games te maken voor Windows, Mac en Linux.

[Verwijderd]

OpenGL is op Windows namelijk veel minder performant dan op Linux.

Hoe kom je daar nu weer bij?
Benchmarks als Unigine tonen toch keer op keer aan dat OpenGL het snelste is op Windows.
Ik ontwikkel zelf ook OpenGL code voor meerdere platforms (oa Windows, OS X, linux, FreeBSD, Android en iOS), en mijn code is ook altijd het snelst op Windows.
Ik heb ook een deel ervan als voorbeeld-progje voor een opensource project van mij gebruikt: http://sourceforge.net/p/bhmfileformat/code/ci/default/tree/
Kun je zelf op allerlei systemen compileren en benchmarken.
Windows is het snelst, hoewel er totaal geen Windows-specifieke optimalisaties in zitten.

Ik word een beetje moe van die FUD.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:14]

[CH4OS]

Hoe kom je daar nu weer bij?

Kijk eens naar de performance van Source-games op Linux vs Windows? Zie bijvoorbeeld dit filmpje op YouTube: https://www.youtube.com/watch?v=2pdEftFFG_I 50 fps voor Windows, 100 fps voor Ubuntu... En dan zeg jij dat OpenGL op Windows beter presteerd dan op Linux?

[Verwijderd]

Uhhh... ten eerste zijn Source-games op Windows geen OpenGL, maar Direct3D (al claimt Valve dat hun OpenGL-port onder Windows sneller zou zijn dan hun verouderde D3D9-code).
Ten tweede, de benchmarks van tweakers:
reviews: SteamOS: nieuw gameplatform bouwt druk op
en Rootgamer (nota bene een linux gamingsite, dus zal wel niet pro-Windows zijn):
http://rootgamer.com/2737...er-strikesource-benchmark
geven hele andere resultaten.
Die zijn sowieso heel wat realistischer... Left 4 Dead 2 is is een heel verouderd en licht spel, en je gelooft toch zeker zelf niet dat je echt maar 50 fps haalt onder Windows?
Op mijn systeem haal ik vaak 300 fps in L4D2 in de lichtere stukken. Onder de 150 fps kom ik nauwelijks volgens mij.

Dus ja, voortaan even beter jezelf verdiepen in de materie, en iets betere bronnen zoeken dan een of andere random YT video van een of andere linux-fanboy.

[CH4OS]

Op jouw link, geeft Linux en Windows vergelijkbare performance, het verschil is althans minimaal en dus gelijk. Dat is ook niet zoals jij dan weer beweerde, dat OpenGL beter presteert op Windows. Je haalt met deze post dus wel je eerdere stelling naar beneden.

Dus leuk dat je mij nu de les wilt lezen, maar zelf heb je jouw eigen materie ook niet goed voor elkaar.

Als je zelf dan ook even googled, dan kom je nog wel meer sites tegen (ook gerenomeerde sites als arstechnica) die ook het een en ander hebben geschreven over sommige games die op Linux veel beter presteren dan op de Windows variant. Heb jij ook iets, om je in te verdiepen alvorens iemand na 1 filmpje te beoordelen als fanboy.

En in een aantal Source-based games kun je gewoon aangeven welke renderer er gebruikt moet worden. DirectX of OpenGL, maar dan ga je nog verder terug geloof ik.

[Reactie gewijzigd door CH4OS op 23 juli 2024 06:14]

[Verwijderd]

Op jouw link, geeft Linux en Windows vergelijkbare performance, het verschil is althans minimaal en dus gelijk. Dat is ook niet zoals jij dan weer beweerde, dat OpenGL beter presteert op Windows. Je haalt met deze post dus wel je eerdere stelling naar beneden.

Ik had al gezegd dat Source games op Windows niet op OpenGL draaien, maar op D3D9, dus je doet geen vergelijking van OpenGL.
Verder had ik m'n eigen code gelinkt. Heb je die al geprobeerd op een Windows-systeem en een linux-systeem?

Dus leuk dat je mij nu de les wilt lezen, maar zelf heb je jouw eigen materie ook niet goed voor elkaar.

Nee, ik reageerde slechts op het filmpje dat jij postte, dat ging over Source games.
Ik zou zelf nooit over een Source-game beginnen, om de simpele reden dat ie op Windows geen OpenGL gebruikt, zoals ik al meerdere keren heb gezegd.

Als je zelf dan ook even googled, dan kom je nog wel meer sites tegen (ook gerenomeerde sites als arstechnica) die ook het een en ander hebben geschreven over sommige games die op Linux veel beter presteren dan op de Windows variant. Heb jij ook iets, om je in te verdiepen alvorens iemand na 1 filmpje te beoordelen als fanboy.

Nogmaals, ik ben ZELF OpenGL developer. Ik hoef niet te googlen naar benchmarks, ik heb VEEL meer kennis en ervaring dan die mensen die af en toe een benchmarkje draaien.
En ja, ik weet ook wel dat er games bestaan die onder linux sneller draaien. Ik weet ook waarom dat zo is, en dat heeft niet per se met OpenGL te maken.

En in een aantal Source-based games kun je gewoon aangeven welke renderer er gebruikt moet worden. DirectX of OpenGL, maar dan ga je nog verder terug geloof ik.

Ja, HEEL lang geleden kon dat ja. De originele Half-Life kon dat bv. Maar dat is zo stokoud, dat dat niet echt relevant is.
De Source engine kan dat niet. Valve heeft hun OpenGL-port nooit op Windows uitgebracht, dus op Windows zit je nog steeds met die sterk verouderde D3D9-engine. Ondanks dat is het nog steeds sneller dan OpenGL op hun eigen SteamOS.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:14]

[Vayra]

Er is nu ook ARM, daar doelde ik vooral op. Ik zie DirectX nog niet zo snel op Android devices bijvoorbeeld.

[Reactie gewijzigd door Vayra op 23 juli 2024 06:14]

[Verwijderd]

DirectX is juist 1 van de redenen waarom Windows Phone apparaten op ARM soc's zo'n vloeiende interface hebben.

[Verwijderd]

Ja, voor Qualcomm SoCs met Adreno GPUs zijn de DirectX-drivers er in ieder geval al, en die SoCs zijn ook voor Android heel populair.
nVidia Tegra wordt gebruikt in Windows tablets, dus ook daar zijn DirectX drivers voor.
Misschien dat er wel meer ARM SoCs zijn met DirectX drivers.

[Caelorum]

En toch werkt DirectX wel gewoon goed op Windows draaiend op ARM. En eigenlijk al gedeeltelijk sinds 2010 toen WP7 uit kwam
Nog beter is zelfs dat DirectX ook gedeeltelijk (deel van Direct3D) wel werkt onder linux: http://cgit.freedesktop.o...258f0c3863d09c1b8903d438b

[Reactie gewijzigd door Caelorum op 23 juli 2024 06:14]

[kidde]

Het aansluiten bij WebGL lijkt dan een vreemde zet. Misschien proberen ze op deze manier Direct X technologie de standaard in te pushen?

Nee, Microsoft en Windows worden komend decennium gewoon totaal irrelevant voor 3D-"content"-makers. De nieuwe 3D-ontwerp programma's zijn "cloud first".

Zie bijv. http://gfxspeak.com/2012/...akes-mcad-into-the-cloud/ :
AutoDesk maakt een "nieuwe AutoCAD" die werkt via de cloud / browser met behulp van WebGL. Dit werkt dus prima op ALLE platformen BEHALVE oudere IE op Windows. Dus nogmaals, ik kan op alle platformen uit de voeten, al is het Android of desnoods iOS, maar NIET op (oudere) Windows welke vaak bij bedrijven in gebruik zijn. De AutoDesk-cloud gaat ook versie-beheer en toegangsrechten regelen, dus dan neemt de vraag naar de peperdure Sharepoint-servers van MSFT ook af.

Dus de omslag is daar: Van AutoCAD en SolidWorks "alleen op Windows" naar "op alle platformen en ietsje slechter / langzamer / gedateerder op Windows". De enigste manier dat Microsoft deze achterstand kan inlopen is door DirectX te laten vallen. Want AutoDesk en Dassault gaan zich in de toekomst niet meer afhankelijk opstellen van deze vendor-lock-in technologie. Dus MSFT moet op WebGL inzetten.

Dassault - maker van Solidworks - gaat hier ook naar toe. Ik kan het interview niet vinden, maar in dat interview geeft de CEO van Dassault PLM software onomwonden aan dat ze de afhankelijkheid van Microsoft beu zijn en daaromheen gaan werken. Dat kan haast niets anders betekenen dan een WebGL / cloudoplossing.

Nu zijn er een heleboel bedrijven die totaal afhankelijk zijn van Windows en IE (denk grote "minder wendbare" bedrijven die qua IT niet bepaald voorop lopen), en voor hun zou het lastig zijn dat de nieuwste 3d-programma's niet "gewoon in hun gedateerde IE-versies" werken.

En wat doet bijv. Adobe: In CC kan je Flash omzetten naar WebGL content.

Dus het is duidelijk: De wereld ontwikkelt verder, met of zonder MSFT aan boord. Het is kiezen of delen, en als MSFT niet meedoet doen vele 3D-ontwikkelaars (van bedrijven die wél een wendbare IT-afdeling hebben) straks baai-baai zwaai-zwaai naar Windows, en niet lang daarna hun systeembeheerders naar Exchange en Sharepoint.

[Caelorum]

Microsoft gaat heel DirectX laten vallen vanwege een paar vendors die WebGL gaan gebruiken? Nog afgezien van dat op Windows de browsers allemaal van WebGL naar Direct3D vertalen (IE11, firefox en chromium) ga je hier ook voorbij aan de enorme game markt die zeker (ook) nog steeds DirectX gebruikt en zal gaan blijven gebruiken. OpenGL zal zeker weer relevanter worden net als WebGL, maar MS gaat echt niet DirectX ineens laten vallen als een steen vanwege deze twee trends. Hooguit dat MS ook meer aandacht gaat besteden aan OpenGL (en nu dus ook WebGL) en dat ze DirectX ook crossplatform maken (wat het prima kan zijn als ze zouden willen).

[kidde]

ga je hier ook voorbij aan de enorme game markt

Klopt, ik had het over mensen die iets maken, niet over gamers dus, die sleept u erbij.

Maw, de scope van mijn reactie is beperkt tot 3D-CAD. Er staat immers "om _deze_ achterstand in te lopen moeten ze DirectX laten vallen", en dat is niet dat MSFT dat zelf moet doen, maar Dassault / AutoDesk doen dat vroeg of laat _voor_ hun.

Overigens, als u het toch over gamers wil hebben, ook daar wordt Microsoft en dus DirectX steeds irrelevanter.

[graey]

Ehm, oude versies van Windows bedoel je dan, als ze alleen IE draaien? Want Chrome draait nog steeds op heel veel versies van Windows en ondersteunt dit prima... Oh, en het vertaalt WebGL-calls naar DirectX, dus dat blijft ook gewoon nodig.

[WokeBroke]

Ik denk dat programmeurs die metero app's willen maken meer zin hebben in WebGL dan directX. Al betwijfel ik of het uberhoubt in is om metero app's te maken.

[Caelorum]

Wat is metero? En als je een Windows 8 app maakt heb je vaak helemaal 100% niets te maken met of dat nou uiteindelijk met opengl of directx op je scherm wordt getoverd (of überhaupt een van die twee).

[blorf]

WebGL wordt inmiddels door veel browsers ondersteund en maakt het mogelijk om 3d-beelden in browsers te tonen zonder dat er een plug-in nodig is.

Via de browser naar de hardware betekent een vinger in de pap. Zeker voor een stuk software waar standaard een browser bij zit. Zoiets willen ze niet missen, denk ik.

[WokeBroke]

Ik hoop dat het 'standaar'" ook eens echt standaard gaat worden, als het de grote jongens als epic games en jagex, al niet lukt om een HTML game voor meerdere browsers te maken, hoe moet een kleine ontwikkelaar het dan gaan doen.

[Reactie gewijzigd door WokeBroke op 23 juli 2024 06:14]

[Verwijderd]

De standaard is niet erg duidelijk.
Zo is het niet vastgelegd hoe shaders gecompileerd moeten worden, of hoeveel instructies die shaders mogen hebben.
Hierdoor komt het vaak voor dat shaders in de ene browser wel goed compileren, maar in de andere niet (ik heb ook wel meegemaakt dat Chrome na een update ineens bepaalde shaders niet meer kon draaien, en ik ze moest inkorten).

Bij DirectX speelt dit probleem niet, omdat MS de compiler levert, en daardoor dus exact vastligt hoe shaders gecompileerd worden, ongeacht op welk systeem je dat doet. De hardware moet vervolgens gewoon voldoen aan de DirectX-standaarden qua minimum aantal instructies/registers/etc. En dus werken shaders altijd op iedere kaart/driver/applicatie.

Khronos is dus helaas gewoon niet goed in hun taak van standaarden opstellen.

[freaky]

ongeacht op welk systeem je dat doet

En dan bedoel je? Windows, windows of windows?

Wellicht dat daar het probleem ligt. Een echte standaard moet iets meer platformen overbruggen ben ik bang en die hebben helaas ook (bijna) allemaal al een historie.

[Verwijderd]

En dan bedoel je? Windows, windows of windows?

Je begrijpt het verhaal niet?
De drivers implementeren alleen een bytecode-taal, maar compileren zelf niet van source.
Die source-compiler en bytecode-taal kun je op alle systemen gebruiken.

Wellicht dat daar het probleem ligt.

Ik zie maar 2 problemen:
1) De mensen in de niet-Windows-wereld doen geen moeite om een goede DirectX-implementatie te ontwikkelen (zie mijn post elders over Wine).
2) Khronos faalt waar het gaat om het goed opstellen van standaarden. Als OpenGL net zo was opgebouwd als DirectX, dan speelde dit probleem daar ook niet (er is wel het Gallium3D-project die een DirectX-achtige opzet van OpenGL heeft, maar dat wordt niet gesteund door Khronos).

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:14]

[vinx77]

1) Niet nodig, want we hebben OpenGL. Anders krijg je dat op Wine alles achterloopt, elke keer als MS een update doet. MS zou DirectX onder kunen brengen bij een organisatie als Khronos, als ze echt willen dat het op alle platforms draait.

2) De standaarden zijn helaas niet bepaald duidelijk. Ze luisteren gelukkig steeds meer naar de gebruiker om in een volgende versie de limieten duidelijker te maken.

Begrijp dat Khronos twee doelen nastreeft bij haar standaarden: features mogelijk maken en portabiliteit. De features hebben toch de nadruk, want ze willen niet achter komen te liggen. Dat komt ook omdat het lastig is om een low-end GPU uit 2008 niet uit te sluiten.

[Verwijderd]

1) Niet nodig, want we hebben OpenGL. Anders krijg je dat op Wine alles achterloopt, elke keer als MS een update doet. MS zou DirectX onder kunen brengen bij een organisatie als Khronos, als ze echt willen dat het op alle platforms draait.

OpenGL loopt nu ook achter bij iedere DirectX-update, dus wat dat betreft maakt het niks uit.

2) De standaarden zijn helaas niet bepaald duidelijk. Ze luisteren gelukkig steeds meer naar de gebruiker om in een volgende versie de limieten duidelijker te maken.

Begrijp dat Khronos twee doelen nastreeft bij haar standaarden: features mogelijk maken en portabiliteit. De features hebben toch de nadruk, want ze willen niet achter komen te liggen. Dat komt ook omdat het lastig is om een low-end GPU uit 2008 niet uit te sluiten.

Uhhh, ik weet niet wat voor excuusverhaal je nu probeert aan te voeren... maar OpenGL bestaat al langer dan DirectX, en nog steeds is het een puinhoop.
Dit gaat hem gewoon niet worden.
Daarnaast, misschien moet je je eens in DirectX verdiepen? Die hebben namelijk features en portability VEEL beter onder controle. Lees bv ook eens wat de gedachte achter COM is geweest: http://www.alexstjohn.com...arly-direct3d-com-opengl/

But as troublesome as COM was, it played an important role in the ultimate success of DirectX. COM provided a way for the API to evolve with rapid releases of new versions of the DirectX API without BREAKING the previous versions of DirectX and the games that depended on it. If Carmack had adopted Direct3D for Quake, his game would have run without modifications on DirectX 2 through to DirectX 9 all the way to Windows XP because every subsequent generation of DirectX which often included radical API changes from its predecessor would have recognized Quake as a DirectX 2 game and exposed only DirectX 2 API’s for it to use while newer games could use very different DirectX 9 API’s on new Windows OS’s without conflict. The COM architecture ensured that game developers who targeted DirectX could ship a game and forget about it, reaping profits from its sales years later even as the OS technology evolved rapidly and incompatibly with older games. This FEATURE of DirectX gave games that used it tremendous longevity without requiring constant maintenance at the expense of more work initially. That tradeoff wasn’t ideal but also was not without its advantages. The need for constant backwards compatibility hamstrung the evolution of open API’s like OpenGL that had to try to maintain backwards compatibility over generations at the expense of innovation which is why OpenGL support remains such a scattered and inconsistently supported API across platforms and devices to this day.

Wat hij zegt over DirectX2 is trouwens waar... sterker nog, het gaat verder dan de Windows XP die hij noemt.
Een tijdje geleden heb ik namelijk m'n oude PowerVR PCX2-kaart eens uit het stof getrokken, en wat van m'n oude Direct3D-code erbij gesleurd... Heb een roterend donutje erop gemaakt, met DirectX2 dus, eerste versie met D3D: http://bohemiq.scali.eu.org/D3DDonut.zip
Dat draait dus op een Win9x-machine (voor de PowerVR heb je alleen Win9x-drivers... en geen OpenGL support natuurlijk), met de eerste generatie hardware.
Maar, het draait nog steeds op mijn Windows 8.1 Pro x64-machine.
Dankzij COM dus, en het feit dat ze niet alle verschillende versies in dezelfde interface proberen te proppen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:14]

[vinx77]

Het is tijd voor OpenGL NG (compleet herontwerp), welke iets als COM gebruikt. Ik ben het met je eens dat er meer nadruk moet komen op portabiliteit, zoals je beschrijft in je COM-verhaal.

DirectX kan me niets schelen, omdat het nooit een standaard zal worden. En als dat wel zal gebeuren, dan krijgt het veel van dezelfde kuren als OpenGL.

[Verwijderd]

Om er nog maar over te zwijgen dat het gerenderde resultaat ook niet consistent is over verschillende shaders (als je op pixel-niveau kijkt).

[Coen Rijkaart]

If you can't beat them join them...

[HashIT]

Embrace, extend and extinguish...

Ik heb ondetussen wel iets meer vertrouwen in Microsoft dat ze braaf meedoen en nuttige toevoegingen doen.