Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 39 reacties
Submitter: The Flying Dutchman

De Khronos Group, de ontwikkelaar van de Opengl-specificatie, heeft versie 3 van zijn cross-platform-api voor 2d- en 3d-toepassingen vrijgegeven. Opengl 3.0 is in de ontwikkelgemeenschap echter uiterst lauw ontvangen.

OpenglVersie 3.0 biedt onder andere vier nieuwe manieren voor het comprimeren van textures, ondersteuning voor het sRBG-kleurenmodel en een vereenvoudigde manier om vertex-objecten te maken. Verder is de nauwkeurigheid bij het renderen van textures met floating-pointoperaties vergroot naar 32bit en is Glsl opgekrikt naar versie 1.30. Met het oog op de toekomst is in versie 3.0 het deprecated model ingevoerd, een methode om aan te gegeven welke functies in de volgende Opengl-versie niet meer zullen worden ondersteund.

De derde versie van Opengl zou oorspronkelijk al in september 2007 worden opgeleverd, maar de release werd wegens 'technische problemen' een aantal keren uitgesteld. Aanvankelijk werd verwacht dat de grafische api grotendeels zou worden herschreven tot een compacter en sneller geheel, maar de Opengl-ontwikkelaars, die Opengl 3.0 omschrijven als een 'evolutionaire stap voorwaarts', zeggen dat daar vanaf is gezien omdat de api met voorgaande versies compatibel moest blijven. Daarnaast zouden te grote veranderingen grote problemen opleveren bij de software- en hardware-ondersteuning. Volgens de ontwikkelaars zouden er momenteel zestig miljoen grafische kaarten gebruikt worden die Opengl-applicaties en -games ondersteunen.

Veel ontwikkelaars zijn echter niet blij met de 'vernieuwde' api. Volgens een aantal van hen zou de architecture review board van de Khronos Group de eerder beloofde fundamentele wijzigingen niet hebben doorgevoerd en kan de nieuwe versie beter het etiket 2.2 opgeplakt krijgen. Anderen leggen op het Opengl-forum de schuld deels neer bij conservatieve cad-gebruikers, die vernieuwing zouden tegenhouden, en stellen dat zij zich gedwongen voelen om over te stappen naar Microsofts propriŽtaire Direct X 10.1-api.

John Carmack, 3d-specialist en medeoprichter van id Software, kan zich deels in de kritiek vinden. Tijdens de Quakecon-conferentie liet Carmack weten dat Opengl in de loop der tijd erg rommelig is geworden en dat versie 3 daar geen verandering in brengt. Volgens de id-topman is een sterk afgeslankte 3d-api de enige juiste keuze voor de toekomst, terwijl bijvoorbeeld cad-gebruikers prima uit de voeten zouden kunnen met de huidige specificatie.

Moderatie-faq Wijzig weergave

Reacties (39)

Leuk plaatje erbij, maar ik mis de link met OpenGL even?
Plaatje komt uit de beroemde Amiga demo Boing, maar ik kan me niet herinneren dat dat een vroege versie was van OpenGL? :)
Wel een van de eerste stoere grafische apps uiteraard.
Voor die ene tweaker ;) die niet weet waar je het over hebt:

http://nl.youtube.com/watch?v=-ga41edXw3A

P.S. die demo heeft inderdaad weinig/niks met OpenGL te maken

[Reactie gewijzigd door borchen op 13 augustus 2008 15:22]

Persoonlijk ontwikkel ik in beide, en vind inderdaad OpenGL een beetje rommelig geworden, maar ik vind wel dat OpenGL nog altijd 'makkelijker' te besturen is dan DirectX, opengl heeft over het algemeen een veel eenvoudigere API dan DirectX.

Nu met op opkomst van XNA, die eigenlijk DirectX wrapped en managed maakt, is het ondertussen ook weer makkelijker geworden om 'XNA'-DirectX aan te sturen.

Ik kan er volledig inkomen dat voor CAD tekenen OpenGL zoals hij nu bestaat perfect voldoende is, voor echte game/simulatie platformen vind ik DirectX dan weer beter.

OpenGL zou perfect een nieuwe API kunnen krijgen, als ze de oude bestaande houden...
En dat zou hen dan weer wat meer marktvoordeel kunnen opbrengen...
Enerzijds is het jammer dat de beloofde api, die modern, object georienteerd, dichter bij de hardware en eenduidiger zou zijn, er nog niet gekomen is. Aan de andere kant maakt deze versie wel de weg vrij om een hoop oude functionlaliteit te verwijderen in een volgende versie. Je kunt nu in OpenGL 3.0 een forward-compatible profiel gebruiken waarbij je geen gebruik maakt van depricated functies. Programma's die gebruik maken van zo'n profiel hebben mogelijk wat performance voordeel, omdat de drivers op dat moment niet alle oude (nu depricated) functies hoeven te ondersteunen.

Wel blijft het zo dat de api veroudert is en niet kan tippen aan DirectX 10. Wel heb je DirextX 10 hardware nodig om OpenGL 3 te kunnen draaien (vanaf Ati R600 of nVidia NV80). Veel nieuwe functionaliteit zit nu standaard in OpenGL 3. Wat wel in de core mist zijn geometry shaders, deze zijn echter beschikbaar via het systeem van OpenGL extensies. Nadeel hier weer van is, dat hardware fabrikanten niet beslist driver ondersteuning hoeven te geven op de extensies. Het is dus maar afwachten of geometry shaders op hardware van alle fabrikanten beschikbaar zal zijn.

Daarnaast hebben enkele leden van Khronos (de instantie die OpenGL beheert) aangegeven dat de nieuwe moderne object georienteerd api nog niet van de baan is. Het vertrouwen bij de community is echter vrijwel verdwenen omdat Khronos een jaar lang niets van zich heeft laten horen over de vertraging die OpenGL 3.0 heeft opgelopen en vervolgens met iets heel anders komt dan in eerste instantie beloofd.

Het is echter ook nog afwachten wat er de komende dagen bekend wordt gemaakt over OpenGL 3.0, de toekomst van OpenGL en driver ondersteuning van hardware fabrikanten tijdens Siggraph 2008 in Los Angelos (een conferentie voor graphics developers en graphics hardware fabrikanten).
De uitleg van Barthold Lichtenbelt, voorzitter van de ARB:

What happened to Longs Peak?

In January 2008 the ARB decided to change directions. At that point it had become clear that doing Longs Peak, although a great effort, wasn't going to happen. We ran into details that we couldn't resolve cleanly in a timely manner. For example, state objects. The idea there is that of all state is immutable. But when we were deciding where to put some of the sample ops state, we ran into issues. If the alpha test is immutable, is the alpha ref value also? If we do so, what does this mean to a developer? How many (100s?) of objects does a developer need to manage? Should we split sample ops state into more than one object? Those kind of issues were taking a lot of time to decide.

Furthermore, the "opt in" method in Longs Peak to move an existing application forward has its pros and cons. The model of creating another context to write Longs Peak code in is very clean. It'll work great for anyone who doesn't have a large code base that they want to move forward incrementally. I suspect that that is most of the developers that are active in this forum. However, there are a class of developers for which this would have been a, potentially very large, burden. This clearly is a controversial topic, and has its share of proponents and opponents.

While we were discussing this, the clock didn't stop ticking. The OpenGL API *has to* provide access to the latest graphics hardware features. OpenGL wasn't doing that anymore in a timely manner. OpenGL was behind in features. All graphics hardware vendors have been shipping hardware with many more features available than OpenGL was exposing. Yes, vendor specific extensions were and are available to fill the gap, but that is not the same as having a core API including those new features. An API that does not expose hardware capabilities is a dead API.

Thus, prioritization was needed, and we made several decisons.

1) We set a goal of exposing hardware functionality of the latest generations of hardware by this Siggraph. Hence, the OpenGL 3.0 and GLSL 1.30 API you guys all seem to love ;\)

2) We decided on a formal mechanism to remove functionality from the API. We fully realize that the existing API has been around for a long time, has cruft and is inconsistent with its treatment of objects (how many object models are in the OpenGL 3.0 spec? You count). In its shortest form, removing functionality is a two-step process. First, functionality will be marked "deprecated" in the specification. A long list of functionality is already marked deprecated in the OpenGL 3.0 spec. Second, a future revision of the core spec will actually remove the deprecated functionality. After that, the ARB has options. It can decide to do a third step, and fold some of the removed functionality into a profile. Profiles are optional to implement (more below) and its functionality might still be very important to a sub-set of the OpenGL market. Note that we also decided that new functionality does not have to, and will likely not work with, deprecated functionality. That will make the spec easier to write, read and understand, and drivers easier to implement.

3) We decided to provide a way to create a forward-compatible context. That is an OpenGL 3.0 context with all deprecated features removed. Giving you, as a developer, a preview of what a next version of OpenGL might look like. Drivers can take advantage of this, and might be able to optimize certain code paths in the forward-compatible context only. This is described in the WGL_ARB_create_context extension spec.

4) We decided to have a formal way of defining profiles. During the Longs Peak design phase, we ran into disagreement over what features to remove from the API. Longs Peak removed quite a lot of features as you might remember. Not coincidentally, most of those features are marked deprecated in OpenGL 3.0. The disagreements happened because of different market needs. For some markets a feature is essential, and removing it will cause issues, whereas for another market it is not. We discovered we couldn't do one API to serve all. A profile encapsulates functionality needed to meet the needs of a particular market. Conformant OpenGL products may implement one or more profiles. A profile is by definition a subset of the whole core specification. The core OpenGL specification will contain all functionality, including what is in a profile, in a coherently designed whole. Profiles simply enable products for certain markets to not ship functionality that is not relevant to those markets in a well defined way. Only the ARB may define profiles, individual vendors may not (this in contrast to extensions).

5) We will keep working on object model issues. Yes, this work has been put on the back burner to get OpenGL 3.0 done, but we have picked that work up again. One of the early results of this is that we will work on folding object model improvements into the core in a more incremental manner.

6) We decided to provide functionality, where possible, as extensions to OpenGL 2.1. Any OpenGL 3.0 feature that does not require OpenGL 3.0 hardware is also available in extension form to OpenGL 2.1. The idea here is that new functionality on older hardware enables software vendors to provide upgrades to their existing users.

7) We decided that OpenGL is not going to evolve into a general GPU compute API. In the last two years or so compute using a GPU and a CPU has taken off, in fact is exploding. Khronos has recognized this and is on a fast track to define and release OpenCL, the open standard for compute programming. OpenGL and OpenCL will be able to share data, like buffer objects, in an efficient manner.

There are many good ideas in Longs Peak. They are not lost. We would be stupid to ignore it. We spent almost two years on it, and a lot of good stuff was designed. There is a desire to work on object model issues in the ARB, and we recently started doing that again. Did you know that you have no guarantee that if you change properties of a texture or render buffer attached to a framebuffer object that the framebuffer object will actually notice? It has to notice it, otherwise your next rendering command will not work. Each vendor's implementation deals with this case a bit differently. If you throw in multiple contexts in the mix, this becomes an even more interesting issue. The ARB wants to do object model improvements right the first time. We can't afford to do it wrong. At the same time, the ARB will work on exposing new hardware functionality in a timely manner.

I want to ask you to take a deep breath, let this all sink in a bit, and then open up the OpenGL 3.0 and GLSL 1.30 specifications we just posted that have all new stuff clearly marked. Hopefully you'll agree with me that there's quite a lot of new stuff to be excited about.

http://www.opengl.org/reg....20080811.withchanges.pdf
http://www.opengl.org/reg...l.1.30.08.withchanges.pdf

This is certainly not the end of the OpenGL API. OpenGL will evolve and will become better with every new revision. I welcome constructive feedback.

Regards,
Barthold Lichtenbelt
OpenGL ARB Working Group chair
Ik vind het ook erg jammer dat OpenGL 3.0 niet is geworden wat ze (de ARB) beloofd hadden. Ik ben zelf game/graphics programmer en ik werk tot nu toe met Direct3D, maar wil graag openGL uitproberen. Ik heb altijd begrepen dat OpenGL een minder steile learning-curve heeft omdat de API plat en overzichtelijker is (in tegenstelling tot COM wat voor D3D gebruikt word). Een minpunt zijn de ietwat rommelige Extensions.

Een ander voordeel van OpenGL is, dat het minder API-calls nodig heeft om hetzelfde voor elkaar te krijgen. Die API calls zien er IMHO ook veel beter uit (geen functies met meer dan 6 parameters enzo). Hoewel ik nog niet kan zeggen dat ik er ervaring mee heb, lijkt OpenGL een lekkere API om mee te werken. Daarom is dit erg jammer.

Ik heb ook begrepen dat de 3.0 specificatie makkelijker implementeerbaar zou zijn voor de driver-bakkers. Dat is ook iets wat openGL nodig heeft, aangezien het soms hier en daar wel aan fatsoenlijke driversupport ontbreekt (vooral op windows).

Ik hoop dat het nog wat word met OpenGL en Windows. :| *sigh*

Edit: Nu ik deze post hierboven gelezen heb, begrijp ik de situatie wel. Ga nu even die specs lezen... :)

[Reactie gewijzigd door chronozphere op 12 augustus 2008 17:17]

open GL begint toch langzaam bestaans recht te verliezen.
direct x kan inmiddels alles wat open GL kan. maar dan makkelijker sneller en efficienter.
afgezien van het callen van acties dan.
hoop dat er inderdaad een goede afgeslankte versie van de api komt.
anders is het direct x all the way...
Het is alleen erg jammer dat Microsoft zijn DirectX platform alleen nog maar voor Vista en hoger uitbreidt.

Vroeger was ik altijd erg happy als een spel OpenGL ondersteunde, dat ging toen mooier en sneller dan DirectX (rond versie 6.0), maar als ik tegenwoordig zie hoeveel lichter en sneller DirectX (9.0c) is, dan vind ik het ronduit jammer dat OpenGL voor op het Windows platform in ieder geval geen antwoord heeft.

Juist een project als OpenGL zou cross-platform ontwikkelen zoveel aantrekkelijker moeten en kunnen maken, aangezien het al bijna een oudgediende is in de PC wereld.

Toch een puntje voor Microsoft met deze ontwikkeling.
OpenGL is tov DX9.0C nog steeds sneller hoor, vooral op Nvidia kaarten.

DirectX is een mainstream op PC's en Microsoft consoles. Jammer dat DirectX10 verder niet vlugger is dan DX9.0c.
OpenGL is tov DX9.0C nog steeds sneller hoor, vooral op Nvidia kaarten.
Cijfers? En kom niet af met een theepot of een draaiende kubus....
Het is op zich niet zo raar. Het komt uiteraard niet door de API zelf, maar op de manier hoe de backends van beide API's in Windows door de driver aangesloten worden. OpenGL calls worden vrijwel direct naar de driver doorgegeven, en op die manier is er dus een vrij korte weg van applicatie naar GPU. Bij D3D9 en eerder zitten er echter nog een paar lagen aan abstractie en kernelspace tussen, waardoor individuele calls zoals tekencommando's en state changes veel duurder zijn. De rendering performance blijft uiteraard gelijk, maar de applicatie interfaced wat sneller met de GPU middels OpenGL dan met D3D. Met de komst van D3D10 geldt dit overigens niet meer.

[Reactie gewijzigd door .oisyn op 12 augustus 2008 16:28]

Daarom dat ik refereer naar die theepot of draaiende kubus, waar ik me kan voorstellen dat die lagen abstractie relatief gezien meer invloed hebben op de performance dan bij complexe scene's. (waar ik verwacht dat door vertex buffers en het gebruik van shaders er minder chatty communicatie is doorheen de API, itt tot elke vertex doorheen glVertex pleuren)
Het is nou juist andersom :). Complexe scenes vereisen veel statechanges en dus veel draw calls, terwijl een simpele kubus of theepot slechts met 1 call overweg kan.
het kan natuurlijk ook aan de implementatie liggen van Autodesk, maar op mijn Nvidia Quadro kaart loopt 3dsmax toch echt een stuk soepeler in directX mode dan OpenGL.
Daarnaast ziet het er ook nog beter uit (shadingwise) en krijg ik een betere indruk hoe mijn scene eruit gaat zien als ik hem render.

Ook zijn de Maxtreme drivers van Nvidia, speciaal voor 3dsmax ontwikkelde drivers, ook overgestapt op DirectX waar die een paar jaar terug nog juist OpenGL gebruikten.

Dit is natuurlijk alleen de ervaring met 1 programma, maar daarbij merk ik wel duidelijk verschil in het voordeel van DirectX.
Maar met een daadwerkelijke verbetering in 3.0 had OpenGL weer een stuk richting mainstream kunnen gaan. Op dit moment is het voor gamedevelopers veel aantrekkelijker om "gewoon" DirectX te gebruiken.

Het is een beetje zoals elk "Open-" verhaal, zolang het geen enorme verbetering is zal men het niet overnemen, en zolang het niet overgenomen wordt, wordt het geen algemeen goed. Zelfs als OpenGL een paar procentjes winst pakt, is het nog niet aantrekkelijk genoeg om over te stappen gezien de moeite die in een overstap gestoken moet worden.
Uhm... op Windows wel ja. OpenGL draait op alle platforms.
stellen dat zij zich gedwongen voelen om over te stappen naar Microsofts propriŽtaire Direct X 10.1-api.
Dat zou jammer zijn. Nog meer software dat moeilijker cross-platform te maken is.
Het feit dat er weinig crossplatform (als in win32 - linux - mac) games zijn, waar je waarschijnlijk op doelt, heeft echt geen zak te maken met de gebruikte API. Dat is namelijk wel het minste probleem als je een game gaat porten. Het aantal linux en in mindere mate mac gebruikers maken het gewoon oninteressant om in die platforms te investeren. Het is niet even een kwestie van een game porten. Het meeste werk gaat zitten in Q&A en support voor die platforms, en dat kost gewoon een hoop geld, terwijl je er relatief weinig voor terug krijgt. Het is niet zo dat een game niet geport wordt omdat de developers voor een bepaalde API hebben gekozen. Bij het kiezen van een API houden ze juist rekening met bepaalde factoren, waarvan het plan om te porten er een van is (de anderen zijn documentatie, support, tools en ervaring van je personeel met die API). Als je je game toch al niet uit gaat brengen op linux of mac, dan valt het crossplatform voordeel van OpenGL al meteen weg (en dat is zo'n beetje het enige voordeel dat OpenGL heeft tov D3D op de PC)

Daarnaast is het helemaal niet zo moelijk om de grafische API van een applicatie te wijzigen, zeker niet voor games die sowieso vaak al ook op de consoles draaien en dus op een degelijke manier ontworpen zijn zodat de low-level grafische schil relatief makkelijk te vervangen is. Bovendien spreken beide API's (D3D en OpenGL) dezelfde hardware aan, dus ze zijn ook vrijwel identiek aan functionaliteit.

[Reactie gewijzigd door .oisyn op 12 augustus 2008 14:12]

Het feit dat er weinig crossplatform (als in win32 - linux - mac) games zijn, waar je waarschijnlijk op doelt, heeft echt geen zak te maken met de gebruikte API. Dat is namelijk wel het minste probleem als je een game gaat porten. Het aantal linux en in
Ik weet dat de API niet het enige probleem is en het kan best zijn dat het niet het belangrijkste probleem is bij het porten. Mijn punt is dat dit een tegenslag is voor de motivatie om software cross-platform te maken. Het vereist namelijk niet alleen het vervangen van de API maar ook de bijbehorende know-how die dus 2x aanwezig moet zijn (DX en OGL). Verder betekent het meer testen etc. Dit goed doen kost meer tijd dan je denkt en er valt veel tijd (en geld) te besparen door het direct te schrijven met een API die op ale beoogde platformen werkt.

Voor de hele code-base geldt dat als het goed is ontworpen/geschreven met cross-platform-conversie als eis, het vervangen van API relatief weinig werk is. Dus niet alleen video. Maar nog steeds een hoop werk.

Dit opgeteld bij de overige kosten kan het erop of eronder zijn voor de keuze om het cross-platform uit te brengen. Zelfs als het uitgebracht wordt met minimale support (vnl alleen door communitie) zoals bv bij Quake III is gebeurd.

P.s. ik dacht niet alleen aan games, hoewel daaraan het meest.

[Reactie gewijzigd door ritsjoena op 12 augustus 2008 14:30]

Het feit dat er weinig crossplatform (als in win32 - linux - mac) games zijn
D'r wordt weinig naar Linux geport sinds Lokigames dood is, maar als ik kijk hoe 't op de mac gaat: wauw. Meestal wordt de mac poort tegelijkertijd met de windows versie ontwikkeld. (transgaming is daar erg bij betrokken geloof ik)
Nu ben ik geen kenner in de diepe materie van de verschillende implementaties echter ik kan me goed voorstellen dat de CAD gebruikers vanuit hun professionele oogpunt waar precisie van belang is conservatiever zijn. Echter het doet er niet aan onder dat zij net zo graag goede support willen voor nieuwere varianten met name van het 2d naar 3d dankzij de verschillende Autodesk pakketten wat het ontwikkelen in 3d steeds makkelijker maakt.
Mij lijkt het dan ook kort door de bocht om te stellen dat deze grote groep geen belang heeft bij een nieuwere release. Het doet echter niet aan af dat deze vernieuwing misschien geen 3.0 waardig is maar of dit nou zo belangrijk is...
---edit---
@BreezahBoy, het komt inderdaad wel eens voor dat er enthousiastelingen in LISP nog oud spul draaiende houden echter een beetje bureau werkt heden ten dagen ook keurig met Acad2005 die zonder problemen de laatste OpenGL versie ondersteunt. Ik kan me dan ook moeilijk voorstellen dat zeker grote drijfveren van met name Autodesk 3.0 dwarsbomen vanwege hun software aangezien zij zeker baat erbij hebben als bv Maya of 3ds de laatste OpenGl ondersteunt.

[Reactie gewijzigd door n4m3l355 op 12 augustus 2008 13:51]

CAD gebruikers moeten gewoon OpenGL 2 blijven gebruiken. Het is niet zo dat opeens alle oude OpenGL2 specificaties van alle harddisks in de wereld gewist zijn. Bovendien, als je in die CAD programma's de nieuwe videokaart features wil gebruiken, dan werkt je CAD programma niet meer op oude workstations.


Voor nieuwe software wil je die oude cruft niet meer hebben. Het is ook niet erg dat je nieuwe games niet meer op een Pentium II werken. Ook nieuwe CAD programma's kunnen uitgaan van nieuwe hardware. Open GL3 had daarom op die groep moeten mikken.
Als bijv. driverontwikkelaar zit je er echter ook niet op te wachten dat je dadelijk twee of meer OpenGL standaarden moeten gaan blijven ondersteunen.

De CAD wereld maakt zich natuurlijk zorgen dat ze oude software dadelijk niet meer mee kunnen nemen naar nieuwe hardware, indien nieuwe OpenGL drivers niet backwards compatible zouden zijn. Dat is een terechte zorg. Je kunt niet zomaar zeggen dat de CAD-wereld "fout" zit. Het echte probleem is dat OpenGL in twee verschillende omgevingen gebruikt wordt: de CAD wereld die conservatief is en de game-wereld die snel ontwikkelt. DirectX bedient eigenlijk alleen de game-wereld en heeft dus meer vrijheid. (En het helpt dat het beheerd wordt door een monpolist die geen compromissen hoeft te sluiten.)
CAD en OpenGL zijn feitelijk niet onlosmakelijk met elkaar verbonden. Autodesk Inventor (maar ook Alibre) gebruikt bijvoorbeeld vanaf versie 2008 bij voorkeur Direct3D.

Oudere 3d CAD software (ProENGINEER, CATIA, Unigraphics, SolidWorks) zullen nog heel wat moeten doen om deze stap te gaan maken. Mogelijk dat HOOPS daarbij nuttig kan zijn.

[Reactie gewijzigd door MOmax op 12 augustus 2008 14:27]

het gaat niet zozeer om de cadgebruikers maar om de programmeurs die jarenoude software beheren voor die cad gebruikers. veel van die software zijn codebases van 20 jaar en ouder en die moeten blijven werken met opengl. die backwards compatibility houdt de vooruitgang van opengl dus tegen.
ik snap niet waarom OpenGL niet het pad van DirextX10 kiest.

De nieuwe versie supersnel en compact maken zonder rekening te houden met backwards compatibility. Vervolgens bouwen ze een OpenGL-Legacy-Wrapper zoals de dx9>dx10 wrapper die in vista zit.

Deze Legacy-Wrapper kan ook snel en compact gemaakt worden maar deze keer met 100% backwards compatibility.
Na de release vraag je de community om over te stappen op de nieuwe OpenGL versie.

De nieuwe OpenGL versie zou de capaciteiten van de videokaart kunnen uitlezen of uit een database halen en op die manier de juiste calls maken.

Met een Hype erachter over de FPS increase zouden veel mensen willen mee helpen lijkt mij
Dat was het originele plan achter OpenGL 3: om eerst de hele API op te schonen, en vervolgens de nieuwe functionaliteit erin te bouwen. Die nieuwe API zou object oriŽnted zijn, en geen fixed function pipeline meer hebben. De fixed function pipeline zou echter wel beschikbaar zijn voor backwards compatibility, alleen zou deze geÔmplementeerd zijn op de nieuwe API.
Het probleem lijkt mij hier dat de Khronos Group probeert twee volledig verschillende doelgroepen blij te maken met hetzelfde product, terwijl ze beide heel andere wensen hebben.

Zoals John Carmack al zegt: cad gebruikers kunnen prima uit de voeten met de versie 2. Een aantal extra features en wat updates zou leuk zijn, maar de basis van openGL 2 is goed. Dan heb je aan de andere kant de (game) developers die graag from scratch een volledig nieuwe API gebouwd zien. Er is hier geen gulden middenweg, het is kiezen of delen.

Ik weet niet wat voor (financiele) middelen de Khronos Group tot zijn beschikking heeft, maar anders zou ik zeggen opsplitsen die handel en verder gaan met twee API's.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True