OpenGL of DirectX: wat beter is, vergelijkende kenmerken, functies, tips. Videokaarten

Blijkbaar weten veel gebruikers, vooral degenen die liever een computer gebruiken om moderne, resource-intensieve games te installeren en te spelen, dat je in de grafische instellingen kunt gebruiken speciale middelen versnel de beelduitvoer en verbeter de beeldkwaliteit OpenGL of DirectX. Waar kun je het beste voor gebruiken volledig gebruik alle verborgen bronnen computersysteem en bereiken maximale prestaties? Deze vraag is behoorlijk controversieel en het is meestal niet mogelijk om ondubbelzinnig ten gunste van een bepaald platform te antwoorden, omdat alles afhangt van het specifieke doel dat de gebruiker of ontwikkelaar zichzelf stelt, en van elk platform. specifieke situatie, wat gedeeltelijk verband kan houden met hardware in de vorm van een grafische versneller, zijn software-ondersteuning in de vorm van chauffeurs en zo aanvullende aspecten. Laten we proberen erachter te komen wat beter is - OpenGL of DirectX - door ons te wenden tot officiële informatiebronnen en te vertrouwen op de meningen van gebruikers en softwareontwikkelaars die mogelijk ondersteuning voor dergelijke technologieën nodig hebben.

Wat zijn OpenGL en DirectX?

Laten we beginnen met het feit dat er onder gewone gebruikers een misvatting bestaat dat deze twee beschreven componenten grafische motoren zijn. Dit is waar onjuiste vragen rijzen over welke engine beter is: OpenGL of DirectX?

Feit is dat deze platforms slechts gedeeltelijk verband houden met deze motoren, aangezien ze dat exclusief zijn software, waarmee de programma- (game-) engine kan communiceren geïnstalleerde apparatuur(meestal met video en geluidskaarten) via hun chauffeurs, die als tussenpersoon optreden. In feite maken OpenGL en DirectX deel uit van de interfaces programmeren van applicaties Met benodigde kits bibliotheken, klassen, definities, structuren, constanten en functies die worden gebruikt om te zorgen voor werk met externe softwareproducten die zijn geïnstalleerd besturingssysteem.

Waar worden deze technologieën voor gebruikt?

Natuurlijk kun je heel vaak vragen tegenkomen over welke grafische afbeeldingen beter zijn: OpenGL of DirectX? Deze bewering is ook gedeeltelijk onjuist, omdat we niet alleen kunnen praten over het gebruik van de bronnen van videokaarten, maar ook over geluid of andere 'hardware' en virtuele apparaten multimediaal. Maar meestal hebben we het eigenlijk over grafische versnellers. Tegelijkertijd moet u duidelijk begrijpen dat de keuze voor een of andere "brug" die de interactie van de videokaart met geïnstalleerd spel of enig ander programma waar nodig kan afhangen van hoe verplicht dergelijke ondersteuning is.

IN moderne spellen Met complexe texturen en zorgvuldig getekende dynamische scènes is dergelijke ondersteuning uiterst noodzakelijk. Maar het probleem is dat niet alle grafische versnellers dergelijke ondersteuning correct kunnen gebruiken. In dit geval hangt alles af van de stuurprogramma's. Hoe trendy de kaart ook is, met verouderde besturingssoftware (drivers) zal hij niet alle mogelijkheden kunnen benutten die oorspronkelijk door de fabrikant waren aangegeven. In de meeste games of in programma's voor het werken met multimedia (bijvoorbeeld voor videoverwerking) is het echter heel vaak nodig om in de instellingen te kiezen welke ondersteuning je wilt installeren, waarbij het ene platform tegen het andere wordt geplaatst (in de Engelse versie ziet dit er meestal zo uit “OpenGL versus DirectX”).

Belangrijkste verschillen tussen DirectX en OpenGL

Wat betreft de belangrijkste verschillen, zonder daar op in te gaan technische aspecten functioneren, kan onmiddellijk worden opgemerkt dat het DirectX-platform, een exclusieve ontwikkeling van Microsoft Corporation, uitsluitend bedoeld is voor gebruik op Windows-systemen en gedeeltelijk op Xbox, en dat OpenGL een vrij gedistribueerde platformonafhankelijke technologie is die toepasbaar is in andere besturingssystemen ( zelfs mobiele). GNU-licentie staat iedereen toe om bij te dragen aan de componenten van deze API eigen veranderingen en toevoegingen met betrekking tot de verbetering ervan om de prestaties van dezelfde videokaarten te verbeteren, terwijl DirectX-verbeteringen alleen kunnen worden verwacht als er nieuwe versies van het platform worden uitgebracht. Tegelijkertijd produceren grafische versnellers, zelfs met de nieuwste stuurprogramma's, bij gebruik op oudere versies van de bridge niet de door de fabrikant aangegeven indicatoren.

Belangrijkste voor- en nadelen

Nu we het er toch over hebben wat beter is: OpenGL of DirectX 11 (12), het is de moeite waard om op te merken dat het eerste platform alleen bedoeld is voor grafische afbeeldingen, en het tweede in het algemeen kan worden gebruikt voor alles wat met multimedia te maken heeft (voor grafische afbeeldingen in in dit geval de Direct3D-component is verantwoordelijk).

Bovendien merken veel experts dat in zeer hoge graad de keuze voor de ene of de andere brug kan ook afhankelijk zijn van het type grafische kaart. Maar als we de vergelijking met een open geest benaderen, wordt aangenomen dat OpenGL er qua platformdekking beter uitziet, maar dat DirectX wint als kant-en-klaar softwareproduct van de Plug&Play-klasse. We mogen echter niet vergeten dat de toolkit DirectX nieuwste versies zijn al beschikbaar in OpenGL, maar ondersteuning voor feedback Nee.

OpenGL of DirectX: wat is beter voor games?

Wat games betreft, zelfs hier is het onmogelijk om een definitief antwoord te geven. Je kunt bijvoorbeeld vaak opmerkingen vinden over het feit dat grafische chips Radeon 9800-lijn beste resultaten in tests laten ze zien op basis van DirectX, en GeForce-kaarten 5XXX-serie - bij gebruik van OpenGL. Maar DirectX heeft nog één ding onmiskenbaar voordeel.

Omdat de OpenGL-bridge oorspronkelijk voor andere platforms is gemaakt, kunnen er in Windows verschillende soorten bugs in voorkomen, maar met DirectX kun je games redelijk draaglijk gebruiken, zelfs op relatief verouderde computers zonder remmen ( lichtend voorbeeld Daarom het spel Age Of Empires).

Andersom gebeurt het ook. Sommige gebruikers merken bijvoorbeeld op dat DOOM 3 op kaarten uit de Radeon X1XXX-serie beschikbaar is gebruik van OpenGL het ‘vliegt’ gewoon, en Half-Life 2 ‘vertraagt’ heel vaak. Maar hier hangt alles blijkbaar ook af van de chauffeurs.

Maar als de game het gebruik van beide technologieën ondersteunt, is het over het algemeen het beste om te zien wat het resultaat van de videokaart zal zijn als elke modus afwisselend wordt gebruikt. Het spreekt voor zich dat om optimale prestaties te bereiken, zowel de platforms zelf als de stuurprogramma's voor de grafische versneller maximaal moeten worden bijgewerkt nieuwste versies.

Wat is beter voor BlueStacks: DirectX of OpenGL?

Vaak kom je vragen tegen over het gebruik van een van de populairste Android-systeememulators, BlueStacks genaamd. Welk platform heeft de voorkeur in BlueStacks - OpenGL of DirectX? Helaas is het ook hier onmogelijk om een definitief antwoord te geven.

Het is echter onuitgesproken dat als je games via deze emulator installeert, je beter OpenGL kunt gebruiken, maar als de game langzamer gaat, dan zul je moeten overstappen naar DirectX. Maar nogmaals, dit alles betreft alleen grafische afbeeldingen van games. In het geval van professionele verwerking en videoweergave zal een aantal serieuze experimenten vereisen.

Als we het tenslotte hebben over wat beter is - OpenGL of DirectX - voor een ontwikkelaar die deze technologieën nog maar net onder de knie begint te krijgen en zijn eerste stappen zet, merken de meeste experts op dit gebied op dat het beter is om eerst vertrouwd te raken met de werkingsprincipes en toolkit van DirectX, aangezien dit platform er eenvoudiger uitziet voor een beginner, en er voortdurend goede SDK-kits voor worden uitgebracht, ontworpen om de aanpassing te vereenvoudigen softwareproducten naar de hardware, en pas daarna verder met het bestuderen van OpenGL.

Veel kan echter afhangen van welk einddoel u zichzelf stelt en welke specifieke functionaliteit van elk platform in elk specifiek geval zal worden gebruikt (alleen afbeeldingen, alleen geluid of een soort gecombineerde oplossingen).

Korte conclusies

Samenvattend is het, zoals al duidelijk is, vrij moeilijk om een ondubbelzinnige conclusie te trekken ten gunste van een of ander onderdeel. Er is voortdurende concurrentie tussen deze platforms. Soms nieuwe versie DirectX loopt wat betreft parameters voor op OpenGL, maar naarmate het verouderd raakt en er enkele innovaties in OpenGL worden geïntroduceerd, begint het te verliezen. Over het algemeen moet men bij het kiezen uitsluitend uitgaan van het bekende principe dat de waarheid bekend wordt door middel van vergelijking. Probeer beide! Pas na het verkrijgen van specifieke resultaten en voor elk specifiek geval zal duidelijk zijn naar welke kant van de schaal uw keuze zal neigen.

Blijkbaar weten veel gebruikers, vooral degenen die liever een computer gebruiken om moderne, resource-intensieve games te installeren en te spelen, dat je in de grafische instellingen speciale tools kunt gebruiken om de beelduitvoer te versnellen en de beeldkwaliteit OpenGL of DirectX te verbeteren. Wat is de beste manier om alle verborgen bronnen van een computersysteem te gebruiken en maximale prestaties te bereiken? Deze vraag is behoorlijk controversieel en het is meestal niet mogelijk om ondubbelzinnig ten gunste van een bepaald platform te antwoorden, omdat alles afhangt van het specifieke doel dat de gebruiker of ontwikkelaar zichzelf stelt, en van elke specifieke situatie, die gedeeltelijk kan zijn gerelateerd aan “hardware in de vorm van een grafische versneller, de software-ondersteuning in de vorm van stuurprogramma’s en enkele aanvullende aspecten. Laten we proberen erachter te komen wat beter is - OpenGL of DirectX - door ons te wenden tot officiële informatiebronnen en te vertrouwen op de meningen van gebruikers en softwareontwikkelaars die mogelijk ondersteuning voor dergelijke technologieën nodig hebben.

Wat zijn OpenGL en DirectX?

Feit is dat deze platforms slechts gedeeltelijk verband houden met deze motoren, omdat het uitsluitend software is waarmee de software-engine van het programma (game) via hun stuurprogramma's kan communiceren met de geïnstalleerde apparatuur (meestal met video- en geluidskaarten), waardoor optreden als tussenpersoon. In feite maken OpenGL en DirectX deel uit van apmet de noodzakelijke sets bibliotheken, klassen, definities, structuren, constanten en functies die worden gebruikt om te zorgen voor werk met externe softwareproducten die in het besturingssysteem zijn geïnstalleerd.

Waar worden deze technologieën voor gebruikt?

Natuurlijk kun je heel vaak vragen tegenkomen over welke grafische afbeeldingen beter zijn: OpenGL of DirectX? Deze formulering is ook gedeeltelijk onjuist, omdat we niet alleen kunnen praten over het gebruik van de bronnen van videokaarten, maar ook over geluid of andere 'hardware' en virtuele multimedia-apparaten. Maar meestal hebben we het eigenlijk over grafische versnellers. Tegelijkertijd moet u duidelijk begrijpen dat de keuze voor een of andere "brug" die de interactie van de videokaart met een geïnstalleerd spel of een ander programma garandeert, waar nodig, ook kan afhangen van hoe verplicht dergelijke ondersteuning is is.

In moderne games met complexe texturen en zorgvuldig getekende dynamische scènes is dergelijke ondersteuning uiterst noodzakelijk. Maar het probleem is dat niet alle grafische versnellers dergelijke ondersteuning correct kunnen gebruiken. In dit geval hangt alles af van de stuurprogramma's. Hoe trendy de kaart ook is, met verouderde besturingssoftware (drivers) zal hij niet alle mogelijkheden kunnen benutten die oorspronkelijk door de fabrikant waren aangegeven. In de meeste games of in programma's voor het werken met multimedia (bijvoorbeeld voor videoverwerking) is het echter heel vaak nodig om in de instellingen te kiezen welke ondersteuning je wilt installeren, waarbij het ene platform tegen het andere wordt geplaatst (in de Engelse versie ziet dit er meestal zo uit “OpenGL versus DirectX”).

Belangrijkste verschillen tussen DirectX en OpenGL

Wat de belangrijkste verschillen betreft, kunnen we, zonder in te gaan op de technische aspecten van de werking, onmiddellijk opmerken dat het DirectX-platform, een exclusieve ontwikkeling van Microsoft Corporation, uitsluitend bedoeld is voor gebruik op Windows-systemen en gedeeltelijk op Xbox, en OpenGL is een vrij gedistribueerde platformonafhankelijke technologie die toepasbaar is in andere besturingssystemen (zelfs mobiel). Dankzij de GNU-licentie kan iedereen bijdragen aan de componenten hiervan API's bezitten veranderingen en toevoegingen met betrekking tot de verbetering ervan om de prestaties van dezelfde videokaarten te verbeteren, terwijl DirectX-verbeteringen alleen kunnen worden verwacht als er nieuwe versies van het platform worden uitgebracht. Tegelijkertijd produceren grafische versnellers, zelfs met de nieuwste stuurprogramma's, bij gebruik op oudere versies van de bridge niet de door de fabrikant aangegeven indicatoren.

Belangrijkste voor- en nadelen

Over wat beter is gesproken: OpenGL of DirectX 11 (12), het is de moeite waard om op te merken dat het eerste platform alleen bedoeld is voor grafische afbeeldingen, en het tweede in het algemeen kan worden gebruikt voor alles wat met multimedia te maken heeft (de Direct3D-component is verantwoordelijk voor grafische afbeeldingen in dit geval).

Bovendien merken veel experts op dat de keuze voor de ene of de andere brug in zeer hoge mate kan afhangen van het type grafische kaart. Maar als we de vergelijking met een open geest benaderen, wordt aangenomen dat OpenGL er qua platformdekking beter uitziet, maar dat DirectX wint als kant-en-klaar softwareproduct van de Plug&Play-klasse. We mogen echter niet vergeten dat de nieuwste versies van de DirectX-toolkit al beschikbaar zijn in OpenGL, maar dat er geen omgekeerde ondersteuning is.

OpenGL of DirectX: wat is beter voor games?

Wat games betreft, zelfs hier is het onmogelijk om een definitief antwoord te geven. Je kunt bijvoorbeeld vaak opmerkingen tegenkomen over het feit dat grafische chips van de Radeon 9800-lijn de beste resultaten laten zien in tests op basis van DirectX, en kaarten uit de GeForce 5XXX-serie de beste resultaten laten zien bij gebruik van OpenGL. Maar DirectX heeft nog een onmiskenbaar voordeel.

Omdat de OpenGL-bridge oorspronkelijk voor andere platforms is gemaakt, kunnen er in Windows verschillende soorten bugs in voorkomen, maar met DirectX kun je games redelijk goed gebruiken, zelfs op relatief verouderde computers, zonder enige vertraging (een sprekend voorbeeld hiervan is het spel Age Of rijken).

Andersom gebeurt het ook. Sommige gebruikers merken bijvoorbeeld op dat DOOM 3 op kaarten uit de Radeon X1XXX-serie die OpenGL gebruiken gewoon "vliegt", en Half-Life 2 heel vaak "vertraagt". Maar hier hangt alles blijkbaar ook af van de chauffeurs.

Wat is beter voor BlueStacks: DirectX of OpenGL?

Het is echter onuitgesproken dat als je games via deze emulator installeert, je beter OpenGL kunt gebruiken, maar als de game langzamer gaat, dan zul je moeten overstappen naar DirectX. Maar nogmaals, dit alles betreft alleen game-graphics. In het geval van professionele videoverwerking en -weergave zul je behoorlijk serieus moeten experimenteren.

Als we het tenslotte hebben over wat beter is - OpenGL of DirectX - voor een ontwikkelaar die deze technologieën nog maar net onder de knie begint te krijgen en zijn eerste stappen zet, merken de meeste experts op dit gebied op dat het beter is om eerst vertrouwd te raken met de werkingsprincipes en toolkit van DirectX, omdat dit platform er eenvoudiger uitziet voor een beginner, en er voortdurend goede SDK-kits voor worden uitgebracht, precies ontworpen om de aanpassing van softwareproducten aan hardware te vereenvoudigen, en pas dan verder te gaan met het leren van OpenGL.

Korte conclusies

Samenvattend is het, zoals al duidelijk is, vrij moeilijk om een ondubbelzinnige conclusie te trekken ten gunste van een of ander onderdeel. Er is voortdurende concurrentie tussen deze platforms. Soms nieuw DirectX-versie qua parameters loopt het voor op OpenGL, maar naarmate het verouderd raakt en er enkele innovaties in OpenGL worden geïntroduceerd, begint het te verliezen. Over het algemeen moet men bij het kiezen uitsluitend uitgaan van het bekende principe dat de waarheid bekend wordt door middel van vergelijking. Probeer beide! Pas na het verkrijgen van specifieke resultaten en voor elk specifiek geval zal duidelijk zijn naar welke kant van de schaal uw keuze zal neigen.

Er bestaan vaak verschillende misvattingen over deze twee API’s.

Ik heb geprobeerd in dit artikel de basisfeiten te schetsen die zowel ontwikkelaars als eindgebruikers moeten weten.

Omdat het onderwerp erg holivar is, heb ik geprobeerd de toon zo neutraal mogelijk te houden.

Vogelvlucht

Beide API's bieden toegang tot functies hardwareversnelling 3D-afbeeldingen.

Veelvoorkomende misvattingen

OpenGL blijft achter bij Direct3D en is over het algemeen, te oordelen naar zulke trage wijzigingen in de specificatie, waarschijnlijk al helemaal dood.

Eigenlijk is de reden voor deze misvatting onwetendheid over extensies. Over het algemeen kan OpenGL dat wel en vaak ook vooruit(!) Direct3D qua innovatie, want... een fabrikant kan een extensie aan OpenGL toevoegen zonder op iemand te wachten, terwijl wijzigingen in Direct3D alleen door Microsoft kunnen worden aangebracht.

OpenGL is voor professionele grafische programma's en Direct3D is voor games.

Deze misvatting heeft een historische reden. OpenGL is oorspronkelijk ontworpen als een 3D grafische bibliotheek die hardwarematig versneld kan worden, maar NIET MOET. Dit verklaart ook de aanwezigheid van enkele features, zoals het renderen van stereobeelden, die games niet nodig hebben. Direct3D werd veel later ontwikkeld, onmiddellijk met GPU-versnelling in gedachten. Toen veel pakketten verschenen, bestond professioneel werk met Direct3D-graphics eenvoudigweg niet.

Microsoft wordt meegeleverd Windows-stuurprogramma's zonder OpenGL-ondersteuning. OpenGL wordt zonder versnelling weergegeven of emuleert via DirectX. Dus als u OpenGL-ondersteuning onder Windows nodig heeft, moet u het stuurprogramma installeren vanaf de website van de fabrikant. De redenen voor deze afwijzing van OpenGL zijn hoogstwaarschijnlijk wederom puur politiek.

Dus wat te doen, hoe te leven?

Opmerking: dit deel is zeer subjectief.

Als u een ontwikkelaar bent en besluit welke API u wilt gebruiken, overweeg dan het volgende:
Voor OpenGL - enorm platformonafhankelijk, in het bijzonder de beschikbaarheid van alle nieuwe functies op Windows XP, waar Direct3D 10/11 dat niet is en dat ook nooit zal zijn.
Tegen OpenGL: stuurprogramma's in Windows hebben standaard geen OpenGL-ondersteuning, dus u moet ze vanaf de website van de fabrikant installeren.

Als u nieuw bent bij het ontwikkelen van 3D-applicaties en dit gebied onder de knie wilt krijgen, dan raad ik u aan dit te doen: begrijp eerst Direct3D (de reden hiervoor is eenvoudig - Microsoft biedt een SDK van zeer hoge kwaliteit), en begrijp dan OpenGL (dit zal zeer eenvoudig zijn na Direct3D). Helaas bestaat er niet zoiets als een SDK voor OpenGL. Daarom zal het moeilijker zijn om het helemaal opnieuw onder de knie te krijgen.

Dat is alles. Veel succes met jouw ontwikkeling!

Je vraagt: wie zijn dat? Ze zijn een dood bedrijf dat ik beschouw als de echte OpenGL-moordenaar. Natuurlijk zorgde de algemene onbekwaamheid van de Commissie ervoor dat OpenGL kwetsbaar werd, terwijl het D3D aan flarden had moeten scheuren. Maar naar mijn mening is 3D Labs misschien wel de enige reden huidige situatie OpenGL op de markt. Wat hebben ze hiervoor gedaan?

Ze ontwikkelden een shader-taal voor OpenGL.

3D Labs was een uitstervend bedrijf. Hun dure GPU's werden uit de werkstationmarkt verdreven door toenemende druk van Nvidia. En in tegenstelling tot nVidia was 3D Labs niet aanwezig op de consumentenmarkt; een overwinning voor nVidia zou de dood betekenen voor 3D Labs.

Dat is wat er uiteindelijk gebeurde.

In een poging om het hoofd boven water te houden in een wereld die hun producten niet nodig had, verscheen 3D Labs op de Game Developer Conference met een presentatie van wat zij "OpenGL 2.0" noemden. Het was de OpenGL API die helemaal opnieuw werd geschreven. En dit was logisch, want in die tijd OpenGL-API het zat vol met afval (dat er echter tot op de dag van vandaag nog steeds ligt). Kijk maar eens hoe esoterisch het laden en binden van texturen is.

Een deel van hun voorstel was een shader-taal. Ja, dat is het. In tegenstelling tot bestaande platformonafhankelijke extensies was hun shader-taal echter "hoog niveau" (C is hoog niveau voor shader-taal).

Tegelijkertijd werkte Microsoft aan zijn eigen shader-taal. Wat ze met al hun collectieve verbeeldingskracht... High Level Shader Language (HLSL) noemden. Maar hun benadering van taal was fundamenteel anders.

Het grootste probleem met de 3D Labs-taal was dat deze kon worden ingebed. Microsoft definieerde zijn taal volledig onafhankelijk. Ze brachten een compiler uit die assemblagecode genereerde voor SM 2.0 (of hogere) shaders, die op zijn beurt naar D3D konden worden gevoerd. Ten tijde van D3D v9 heeft HLSL D3D nooit rechtstreeks aangeraakt. Het was een goede, maar onnodige abstractie. De ontwikkelaar heeft altijd de mogelijkheid gehad om de uitlaatgassen van de compiler te gebruiken en deze aan te passen voor maximale prestaties.

In taal van 3D Labs Niets dit was niet het geval. Je geeft de bestuurder een C-achtige taal en er ontstaat een shader. Dat is alles. Geen montage-arcering, niets dat aan iets anders kan worden gevoerd. Alleen het OpenGL-object dat de arcering vertegenwoordigt.

Voor OpenGL-gebruikers betekende dit dat ze onderworpen waren aan de grillen van OpenGL-ontwikkelaars die net leerden hoe ze assembler-achtige talen moesten compileren. Er waren veel bugs bij de compilers van de pasgeboren shader-taal OpenGL (GLSL). Wat nog erger is, als het je lukt om de shader correct te laten compileren verschillende platforms(wat op zichzelf al een grote prestatie was), waaraan hij nog steeds onderworpen was optimalisaties die tijden die niet zo optimaal waren als ze hadden kunnen zijn.

Dit was een groot, maar niet het enige nadeel van GLSL. Ver niet de enige.

In D3D kon je, net als in de oude OpenGL-assembleertalen, vertex- en fragment-shaders op alle mogelijke manieren mixen en matchen. Het was mogelijk om elke vertex-shader te gebruiken met elke compatibele fragment-shader, zolang ze maar via dezelfde interface communiceerden. Bovendien was zelfs enige incompatibiliteit toegestaan: de vertex-shader kon bijvoorbeeld een waarde uitvoeren die niet door de fragment-shader werd gebruikt.

Er was niets dergelijks in GLSL. De vertex en de fragmentarcering werden samengesmolten tot iets dat 3D Labs een ‘softwareobject’ noemde. Daarom voor delen meerdere vertex- en fragment-shaders in diverse combinaties, moest ik verschillende softwareobjecten maken. Dit veroorzaakte het tweede grootste probleem.

3D Labs dacht dat ze de slimste waren. Ze gebruikten C/C++ als basis voor het GLSL-compilatiemodel. Dit is wanneer u één c-bestand neemt en dit in een objectbestand compileert, en vervolgens verschillende objectbestanden neemt en deze aan een programma koppelt. Dit is hoe GLSL compileert: eerst compileer je een hoekpunt of fragment-shader in een shader-object, daarna plaats je die objecten in software-object en voeg ze samen om uiteindelijk een programma te vormen.

In theorie maakte dit coole dingen mogelijk, zoals 'bibliotheek'-shaders, die code bevatten die wordt aangeroepen door de hoofdshader. In de praktijk resulteerde dit in het niet compileren van shaders tweemaal: een keer in de compileerfase en een tweede keer in de linkfase. Vooral de compiler van nVidia stond hier bekend om. Er werd geen tussenliggende objectcode gegenereerd; het compileerde aan het begin, gooide het resultaat weg en compileerde opnieuw in de linkfase.

Om een vertex-shader aan twee verschillende fragment-shaders te koppelen, moest je dus veel meer compileren dan in D3D. Vooral gezien het feit dat alle compilatie is voltooid offline, en niet vóór de daadwerkelijke uitvoering van het programma.

GLSL had ook andere problemen. Het zou verkeerd kunnen zijn om alle schuld op 3D Labs te leggen, aangezien de ARB uiteindelijk de shader-taal in OpenGL heeft goedgekeurd en opgenomen (maar niets anders uit de voorstellen van 3DLabs). Het oorspronkelijke idee lag echter nog steeds bij 3D Labs.

En nu het treurigste: dat waren 3D Labs hebben gelijk(grotendeels). GLSL is geen vectortaal zoals HLSL destijds was. Dit kwam doordat de hardware van 3D Labs scalair was (zoals moderne nVidia-hardware), en ze hadden volkomen gelijk toen ze de richting insloegen die veel hardwarefabrikanten later volgden.

Ze hadden gelijk wat betreft de keuze van het compilatiemodel voor de ‘high-level’-taal. Zelfs D3D kwam hier uiteindelijk op uit.

Het probleem is dat 3D Labs gelijk had tijd. En door te proberen voortijdig de toekomst in te gaan, door te proberen voorbereid te zijn op de toekomst, zetten ze het heden opzij. Dit lijkt op de T&L-functionaliteit in OpenGL die er altijd is geweest. Behalve dat de OpenGL T&L-pijplijn dat wel was bruikbaar en vóór de komst van hardware-T&L, en GLSL was een probleem voordat de rest van de wereld dat inhaalde.

GLSL is goede taal Nu. Maar wat gebeurde er destijds? Hij was verschrikkelijk. En OpenGL had hier last van.

Op weg naar apotheose

Ik steun de opvatting dat 3D Labs de doodsteek voor OpenGL heeft uitgedeeld, maar dat ARB zelf de laatste spijker in de kist heeft geslagen.

Misschien heb je dit verhaal wel eens gehoord. Ten tijde van OpenGL 2.1 had OpenGL dat ook grote problemen. Hij sleepte mee enorm compatibiliteit belasting. De API was niet langer eenvoudig te gebruiken. Met vijf kan één ding worden gedaan op verschillende manieren en het is niet duidelijk welke sneller is. Het was mogelijk om OpenGL te "leren" door eenvoudige handleidingen, maar je hebt OpenGL niet bestudeerd, wat echte grafische kracht en prestaties geeft.

ARB besloot een nieuwe poging te doen om OpenGL opnieuw uit te vinden. Het leek op "OpenGL 2.0" van 3D Labs, maar beter omdat ARB achter de inspanning stond. Ze noemden het "Long's Peak".

Wat is er zo erg aan om wat tijd te besteden aan het verbeteren van de API? Het slechte nieuws is dat Microsoft zich in een behoorlijk precaire positie bevindt. Dit was de tijd van de overgang naar Vista.

IN VistaMicrosoft besloten om langverwachte wijzigingen aan te brengen grafische stuurprogramma's. Ze dwongen de stuurprogramma's om zich voor virtualisatie tot het besturingssysteem te wenden grafisch geheugen en vele anderen.

Je kunt lang discussiëren over de voordelen van deze aanpak, en of het überhaupt mogelijk was, maar het feit blijft: Microsoft heeft D3D 10 alleen voor Vista en hoger gemaakt. Zelfs aan ondersteunend Het was onmogelijk voor D3D-hardware om een D3D-applicatie te draaien zonder Vista.

Je herinnert je misschien dat Vista... laten we zeggen dat het niet zo goed werkte. Dus we hadden een ontspannen besturingssysteem, nieuwe API, dat alleen op dit besturingssysteem werkte, en de nieuwe generatie hardware, die nodig in deze API en OS om meer te doen dan alleen beter presteren dan de vorige generatie.

Echter, de ontwikkelaars zou kunnen Gebruik D3D-functionaliteit op 10-niveau via OpenGL. Dat wil zeggen: dat zou kunnen als ARB niet bezig was met het werken aan Long Peaks.

ARB heeft ruim anderhalf tot twee jaar gewerkt aan het verbeteren van de API. Tegen de tijd dat OpenGL 3.0 uitkwam, was de overgang naar Vista voorbij, was Windows 7 onderweg en gaven game-ontwikkelaars niet langer om functionaliteit op D3D 10-niveau het tempo van pc-poorten nam toe, console (of met de overgang van pc-ontwikkelaars naar de consolemarkt) hadden ontwikkelaars steeds minder D3D 10-functionaliteit nodig.

Als ontwikkelaars zelfs op Windows XP toegang zouden hebben tot deze functionaliteit, zou de OpenGL-ontwikkeling een impuls kunnen krijgen. Maar ARB miste deze kans. Wil je weten wat het ergste is?

ARB kon niet een API helemaal opnieuw bedenken, ondanks dat je twee kostbare jaren hebt verspild aan het proberen om het te doen. Dus keerden ze terug naar de status quo en voegden alleen een mechanisme toe om de functionaliteit af te schaffen.

Hierdoor miste ARB niet alleen sleutel kansen, maar hebben ook niet het werk gedaan dat tot deze omissie heeft geleid. Het was een epische mislukking op alle fronten.

Dit is het verhaal van verzet tegen OpenGL en Direct3D. Een verhaal over gemiste kansen, grote domheid, opzettelijke roekeloosheid en banale absurditeiten.

Oh, was het maar zo eenvoudig met OpenGL. Nu zijn er op de een of andere manier 6 incompatibele standaarden in gebruik (2.1,3.3,4.x, ES 1.0, ES 2.0, ES 3.0), die verschillende shader-talen hebben en gedeeltelijk (en soms bijna volledig) verschillende API's . Nog erger, geen referentie-implementatie en zeer weinig kwaliteitscontrole. Als gevolg hiervan wordt OpenGL op het grootste deel van de pc-markt (Intel en AMD) scheef geïmplementeerd, en op mobiele telefoons zijn, naast vaak scheve stuurprogramma's (voor Adreno (ex-ATI, wat wil je nog meer), benaderingen van optimalisatie heel anders

DiDi

Mikhail, je hebt het een beetje mis. Slechts in één enkel geval hoeft u voor DirectX te kiezen. Als u uw doelgroep niet alleen wilt beperken tot het Windows-platform, maar ook tot één versie van Windows en een exacte match van de fabrikanten en series computercomponenten die voor de ontwikkeling worden gebruikt. En hoewel niemand zal beweren dat wat direct is geschreven, ook op andere componenten en zelfs op sommige versies van Windows zal werken, zal het beeld toch, in geval van enige discrepantie, verschillen in de slechtste kant evenals prestaties. In alle andere gevallen, als een ontwikkelaar zijn creatie wil overbrengen in de vorm waarin hij het heeft gedaan, moet hij eenvoudigweg OpenGL kiezen.

crib

DiDi, je zegt vreemde dingen. Allereerst is D3D9 overal beschikbaar vanaf XP, en, verrassend genoeg, ook op de XBox en sommige Windows Mobiele telefoons. D3D11 is beschikbaar op alle pc's met Vista+, WinRT, WP8. Blijkbaar zal het in de volgende generatie XBox zijn.

OpenGL werkt extreem slecht op pc. De kans is klein dat alles werkt op AMD. Ik zal helemaal niets over Intel zeggen. De gebruiker, vooral het varken, beschikt mogelijk niet over stuurprogramma's die hem voorzien van coole softwareweergave en ondersteuning voor API 1.1. Tegelijkertijd is de kans groot dat de D3D-game prima werkt.

DiDi

crsib, ik hoop dat je je eigen gameprojecten hebt.. het is voor mij genoeg dat ik genoeg code heb gezien om te schrijven, zodat de afbeelding gewoon overal zou zijn waar deze D3D9 is. Ik zal niet beweren dat de meeste programmeurs die deze gebruiken DirectX zijn geen luie mensen, in tegenstelling tot degenen die de voorkeur geven aan OpenGL, maar het voegt geen enkele waarde toe aan DirectX zelf. Uiteindelijk zijn voor mij persoonlijk de maatstaf de kosten van de ontwikkelaars, en in het geval van direct zijn ze onevenredig hoger met uiteindelijk veel minder nuttige output.

crib

Ik heb het gewoon. En op OpenGL ES. Ik begreep de grap over de arbeidskosten helemaal niet. Het monitoren van de staat van de pijpleiding op OpenGL is nog steeds een marteling, omdat om de een of andere reden een aanzienlijk deel ervan is ingekapseld in grafische 'primitieven'. Het is over het algemeen moeilijk om de code draagbaar te houden. ES 1 heeft helemaal geen vereisten voor compressieformaten voor hardwaretexturen, ES 2.0 heeft slechte ETC. Als gevolg hiervan moet je voor dezelfde Android een pakket builds samenstellen met texturen erin verschillende formaten. Ik heb het niet eens over het feit dat PowerVR en Mali en Adreno op sommige plaatsen een direct tegenovergestelde benadering van optimalisatie op OpenGL-niveau hebben (met zijn benadering van hardware-abstractie). Ik wil het niet eens over de pc hebben. Omdat OpenGL moet werken, zullen mijn computers altijd een nVidia-accelerator hebben. Ik heb echt geen keus. Ik kan bijna garanderen dat code geschreven in overeenstemming met de standaard op Intel GMA/HD niet dom zal werken, zelfs als ik 10 stuurprogramma's installeer. Nou ja, of het zal zo werken dat het beter zou zijn als het eerlijk gezegd niet zou werken. Het is bijna hetzelfde verhaal met ATI/AMD, de situatie is alleen iets beter.

Over het algemeen klinken uw opmerkingen in de geest van een beginnende ontwikkelaar die eenvoudigweg geen tijd heeft gehad om alle cirkels van de hel van de productieontwikkeling op OpenGL te doorlopen.