[OpenGL] de toekomst?

[apNia]

Ik heb al enige tijd met een vriend van me de discussie tussen D3D of OpenGL programmeren. Nou is een van de zwaarst wegende punten dat OpenGL minder progressie lijkt te maken dan D3D. In dat opzicht vragen we ons eigenlijk af of OpenGL het wel zometeen blijft bijbenen. Kortom, wat is jullie mening over de toekomst van OpenGL?

_{Hoor graag ook van de mensen die er ook aan twijfelen ipv alleen mensen die het er niet mee eens zijn}

[NMe]

OpenGL heeft natuurlijk wel wat voordelen die D3D niet heeft. OpenGL is, de naam zegt het al, open. Open betekent in de meeste gevallen portable.

Daarnaast: waar baseer je het op dat OpenGL langzamer progressie maakt dan D3D?

[.oisyn]

Omdat er nogal een log consortium achter OpenGL zit, net zoals dat bij C++ het geval is. Maar de laatste jaren lijkt er een beetje schot in te komen.

Maar om de vraag te beantwoorden, zowel D3D als OpenGL zullen niet verdwijnen; de eerste maakt met versie 10 standaard onderdeel uit van windows (vista), en opengl zal gebruikt blijven worden op andere platformen. En op de gameconsoles zit je sowieso niet echt aan een API vast .

[apNia]

Nou ik denk omdat OpenGL toch afhankelijk is voor meer geavanceerdere features van fabrikanten van kaarten. Bij D3D is het the other way around. Maar correct me if I'm wrong!

Ik heb ook niet 't idee dat OpenGL zal verdwijnen, maar zal 't niet op een gegeven moment niet verloederen tot een matig alternatief voor cross-platform oplossingen? Net als je het 3DSmax hebt versus opensource Blender (alhoewel er vast mensen zullen zijn die zweren bij Blender )

[ Voor 3% gewijzigd door apNia op 29-03-2006 20:20 ]

[Zoijar]

Minder progressie? OpenGL is hot het laatste jaar met versie 2.0 en bijkomend GLSL. (nu GPGPU populairder wordt zal je nog vaker opengl zien. "Science" mensen gebruiken bijna allemaal een unix variant + opengl, uiteraard MS research uitgesloten...) Plus nog het feit dat vendors gewoon opengl extensions kunnen maken, bij d3d kan dat volgens mij niet

[ Voor 70% gewijzigd door Zoijar op 29-03-2006 20:37 ]

[apNia]

Vraag is, BLIJVEN vendors dat wel doen als D3D met deel 10 steeds meer marktaandeel begint te krijgen? Verloedert OpenGL inderdaad niet tot de grafische standaard voor professortjes en CAD-tekenaars, waardoor 't misschien in een neerwaards spiraal raakt?

[ Voor 4% gewijzigd door apNia op 29-03-2006 20:42 ]

[dawuss]

Zo lang DirectX beperkt blijft tot de platformen die Microsoft aanbiedt, zal dat wel niet zo'n storm lopen Vergeet niet dat bijvoorbeeld Quartz Extreme, de grafische acceleratie-engine van Mac OS X, gebruik maakt van OpenGL en dat ook Cairo en Xgl (die hetzelfde begen te doen voor X-desktops) dit doen.

Voor mensen die OpenGL te low-level vinden, heb je mooie schilletjes zoals het Simple Directmedia Library (SDL). Nee, OpenGL is nog lang niet dood en zo lang DirectX Microsoft-only blijft zal dat ook echt niet gebeuren.

[ Voor 10% gewijzigd door dawuss op 29-03-2006 20:52 ]

[Zoijar]

apNia schreef op woensdag 29 maart 2006 @ 20:42:
Vraag is, BLIJVEN vendors dat wel doen als D3D met deel 10 steeds meer marktaandeel begint te krijgen? Verloedert OpenGL inderdaad niet tot de grafische standaard voor professortjes en CAD-tekenaars, waardoor 't misschien in een neerwaards spiraal raakt?

Krijgt D3D dan meer markt aandeel? Ik weet het niet. Is dat echt zo, of denk je dat? Overigens vind ik de term "professortjes" een beetje neerbuigend voor mensen die zorgen dat deze industrie uberhaupt bestaat... Het belang en invloed van onderzoek wordt zo vaak onderschat, ik snap niet waarom. Het zijn echt niet alleen maar game developers daar buiten hoor; vendors luisteren (ook) naar suggesties in research papers. Onderschat niet het marktaandeel van medische en wetenschappelijke visualizatie applicaties, daar gaat veel geld in om. ik trek me dit een beetje persoonlijk aan, omdat het mijn gebied is... maar bedoel het niet als flame oid

[apNia]

Nee OK daar heb je gelijk in. Het was meer grappig bedoeld dan neerbuigend, maar duidelijk met een averechts effect. Dus m'n welgemeende excuses

Nouja ik heb het gevoel dat de meest vooruitstrevende groep de gamedevelopers zijn, en dus degenen zijn die het eerst stuiten op de beperkingen van een dergelijke API. Deze groep zou dus als eerst struikelen over de beperkingen van OpenGL (als dat dus intreedt). Silicon Graphics schijnt niet al te best te gaan, en dat kan er toch voor zorgen dat OpenGL een flinke deuk oploopt. Of zie ik dat helemaal verkeerd?

Ik krijg iig 't idee inmiddels. Tot dusver heeft nog niemand in dit topic de ontwikkeling (niet zozeer toekomst eigenlijk) van OpenGL in twijfel getrokken

[Anoniem: 43565]

apNia schreef op woensdag 29 maart 2006 @ 20:42:
-knip- Verloedert OpenGL inderdaad niet tot de grafische standaard voor professortjes en CAD-tekenaars, waardoor 't misschien in een neerwaards spiraal raakt?

Kun je het juist niet een enorme stabiele basis noemen dat professoren/onderzoekers en CAD-tekenaars bij OpenGL blijven? Alleen dat geeft al aan dat OpenGL geen gewisse dood tegemoet gaat. Dat OpenGL altijd blijft bestaan en alle nieuwe technologiën mee gaat maken. Vooral dat laatste, het meemaken van nieuwe technologiën blijft denk ik een groot voordeel voor OpenGL.

Neemt niet weg dat als je een game maakt voor op Windows en je over veel tijd en geld beschikt of geen rare eisen hebt D3D een betere keuze kan zijn.

op je laatste reactie: game-developpers lopen denk ik op een ander gebied tegen beperkingen aan dan onderzoekers. Zowel voor- als nadelen denk ik.

[ Voor 10% gewijzigd door Anoniem: 43565 op 29-03-2006 22:31 ]

[apNia]

Kan je wat voorbeelden noemen daarin?

En ik bedoel eigenlijk niet zozeer de toekomst, maar vooral het feit dat het ontwikkeld zal blijven worden dat het nog wel in hetzelfde vaarwater zit als DirectX.

[Zoijar]

apNia schreef op woensdag 29 maart 2006 @ 22:27:
Nee OK daar heb je gelijk in. Het was meer grappig bedoeld dan neerbuigend, maar duidelijk met een averechts effect. Dus m'n welgemeende excuses

Ok, geen probleem.

Nouja ik heb het gevoel dat de meest vooruitstrevende groep de gamedevelopers zijn, en dus degenen zijn die het eerst stuiten op de beperkingen van een dergelijke API. Deze groep zou dus als eerst struikelen over de beperkingen van OpenGL (als dat dus intreedt). Silicon Graphics schijnt niet al te best te gaan, en dat kan er toch voor zorgen dat OpenGL een flinke deuk oploopt. Of zie ik dat helemaal verkeerd?

Game developers gebruiken bepaalde dingen helemaal niet. Zoals stereo rendering, hoge precisie, en nog wat van die dingen. OpenGL doet dat ook allemaal. Kijk bv maar naar de specificaties van de nvidia Quadro serie. Gamers denken vaak alleen aan geforce, maar de wetenschappelijke wereld gebruikt voornamelijk quadros vanwege stereo rendering. Beperkingen in die hoek worden dus niet door game developers ontdekt. En ik denk voornamelijk nu dus ook aan generieke computaties op GPU's, zoals image processing en analyse, en eventueel lineaire algebra en het oplossen van stelsels vergelijkingen. GPUs kunnen veel meer dan "alleen" graphics renderen. Kijk bv maar eens naar OpenVidia http://openvidia.sourceforge.net/

Ik krijg iig 't idee inmiddels. Tot dusver heeft nog niemand in dit topic de ontwikkeling (niet zozeer toekomst eigenlijk) van OpenGL in twijfel getrokken

[Creepy]

1 van de grotere game developers ontwikkelt de engines voor wat betreft het 3d werk met OpenGL (ID Software). Nvidia lijkt redelijk actief mee te helpen aan de ontwikkeling van OpenGL (iets wat ze met D3D niet zo makkelijk kunnen). Het lijkt me niet dat deze partijen zich alleen maar zullen richten op D3D

[.oisyn]

Zoijar schreef op woensdag 29 maart 2006 @ 20:33:
Plus nog het feit dat vendors gewoon opengl extensions kunnen maken, bij d3d kan dat volgens mij niet

Officieel niet, maar het kan wel. Zo worden de hardware shadowmaps van nvidia bijvoorbeeld niet ondersteund door de d3d api, maar je kunt ze wel gebruiken (door je depth surface in te stellen als texture). Andere, wat minder gedocumenteerde, extensies activeer je door specifieke waarden in bepaalde render states in te stellen. We hebben tijdens de development van Tomb Raider: Legend wat nvidia lui over de vloer gehad, we hadden enorme stalls tijdens het inladen van shaders. Ze komen nu met een driver update waarmee we door een specifieke renderstate in te stellen een bepaald optimalisatie-pad in de driver kunnen triggeren.

Anoniem: 43565 schreef op woensdag 29 maart 2006 @ 22:29:
Neemt niet weg dat als je een game maakt voor op Windows en je over veel tijd en geld beschikt of geen rare eisen hebt D3D een betere keuze kan zijn.

Waarom moet je daarvoor dan over veel tijd en geld beschikken, of geen rare eisen hebben :?[/quote]

Zoijar schreef op woensdag 29 maart 2006 @ 22:42:
Game developers gebruiken bepaalde dingen helemaal niet. Zoals stereo rendering, hoge precisie, en nog wat van die dingen. OpenGL doet dat ook allemaal. Kijk bv maar naar de specificaties van de nvidia Quadro serie. Gamers denken vaak alleen aan geforce, maar de wetenschappelijke wereld gebruikt voornamelijk quadros vanwege stereo rendering.

offtopic:
Overigens zit het verschil tussen de Quadro en de GeForce 'm voornamelijk in de software en de support, niet zozeer in de hardware (ja de pipeline budgettering verschilt voornamelijk, een quadro moet veel meer vertices kunnen transformeren terwijl het voor de geforce voornamelijk op fillrate aankomt). Feature-support is iets voor de drivers.

[ Voor 3% gewijzigd door .oisyn op 29-03-2006 23:05 ]

[Gerco]

No-offence .oisyn, maar "bepaalde waardes in bepaalde renderstates" klinkt niet echt als een "extension". Meer als "als ik de ID in dezeStruct op -8 zet, gebeurt er zo-en-zo". In mijn oren klinkt het als inbouwen van undocumented features in een driver in een specifieke situatie het gedrag te laten afwijken van het gedocumenteerde.

Ik heb overigens totaal geen verstand van game- en directx development, dus misschien is het heel anders, maar het klinkt als wat rare hacks...

[ Voor 20% gewijzigd door Gerco op 29-03-2006 23:17 ]

[.oisyn]

Euh, ja, dat zeg ik toch ook? Eerste paar woorden . Dit komt best veel voor in professionele games, er wordt gepoogd om de API heen te werken. Ik zie het punt eigenlijk niet.

[Gerco]

Het punt is dat ik niet vind dat je dit kunt opvoeren als "extensions" in DirectX. Dat je op deze manier ondanks DirectX toch dit soort dingen kunt doen, spreekt niet bepaald voor het produkt DirectX.

Ik heb het niet over of het wel of niet professioneel is om te doen. Ik vind eigenlijk van niet, maar als het de enige manier is om goede performance te halen moet het maar.

[.oisyn]

A) ik beweer nergens dat het vóór DirectX spreekt, ik vind het zelfs een van de zwakkere punten, en B ) ik zeg ook niet dat het professioneel is, ik zeg dat het voor professionele games gebruikelijk is om op die manier langs de minpunten (!!!) van de API te werken . Excuus als het verkeerd overkwam.

[ Voor 9% gewijzigd door .oisyn op 30-03-2006 00:30 ]

[Gerco]

Als het gebruikelijk is voor bepaalde (grote) games, zitten die drivers dan niet inmiddels stampvol met code als:

C:

// Doe iets magisch om aan de waarde "game" te komen
switch(game) {
  case GAME_DOOM3:
    // Optimalisaties voor Doom 3
    break;

  case GAME_TOMB_RAIDER_LEGEND:
    // Optimalisatie voor TRL
    break;

  case GAME_UNREAL_TOURNAMENT_99:
    // Oude meuk voor UT'99
    break;

  // Insert nog 100 andere games
}

Wordt dat niet vreselijk unmaintainable op een gegeven moment? Op deze manier snap ik wel dat ze weigeren om de source of werking van de drivers vrij te geven, ik zou me er flink voor schamen Ik ben ook niet zo'n fan van vendor specifieke (OpenGL) extenties (mind you.. geen ervaring), maar dat lijkt me een stuk minder slechte oplossing

[ Voor 20% gewijzigd door Gerco op 30-03-2006 08:35 ]

[Zoijar]

OpenGL extensies zijn trouwens hardware extensies. Die worden dus niet gemaakt door software developers, maar door hardware developers. Nvidia heeft een leuke nieuwe feature op haar nieuwste chip, maar opengl ondersteunt daar geen calls voor; dan kan nvidia die als extension toevoegen.

[.oisyn]

Gerco schreef op donderdag 30 maart 2006 @ 08:32:
Als het gebruikelijk is voor bepaalde (grote) games, zitten die drivers dan niet inmiddels stampvol met code als:

Min of meer . Geen idee hoe die drivers geïmplementeerd worden, maar ik kan me voorstellen dat ze een hele zooi standaard optimalisatiepaths hebben en bepaalde games dus gewoon bepaalde paths aan of uit zetten.

Wordt dat niet vreselijk unmaintainable op een gegeven moment? Op deze manier snap ik wel dat ze weigeren om de source of werking van de drivers vrij te geven, ik zou me er flink voor schamen

Ik zie niet in waarom ze zich daarvoor moeten schamen. Je hebt als gamedeveloper alleen maar de D3D API, terwijl het wel op gigantisch veel hardware moet werken, en elke game heeft weer verschillende eisen. Je kunt als driver vendor dus niet zomaar een generieke optimalisatie maken omdat het dan niet altijd goed werkt, en als gamer wil je gewoon een goede performance. Game-specific optimalisaties zijn dan de enige uitweg.

En dit geldt niet alleen voor games, er wordt ook gigantisch veel geoptimaliseerd voor verschillende CAD/CAM applicaties.

Ik ben ook niet zo'n fan van vendor specifieke (OpenGL) extenties (mind you.. geen ervaring), maar dat lijkt me een stuk minder slechte oplossing

Extensies hebben zowel voor- als nadelen. Het voordeel is dat je een hardware feature meteen kan gebruiken, het nadeel is dat je gelijksoortige hardware-features op verschillende hardware in den beginne ook op verschillende manieren aan moet spreken. Dit was vooral een crime tijdens de introductie van de vertex- en pixelshaders; DX8 kwam vrijwel gelijk met de hardware en iedereen kon het op een standaard manier gebruiken. In OpenGL werkte het voor nVidia hardware op een andere manier dan op ATi hardware.

DX10 gaat overigens nog een stukje verder, je kunt dan niet eens meer een featurelist opvragen omdat er blind vanuit kan worden gegaan dat alle DX10 features gewoon te gebruiken zijn op elk stukje hardware (zo niet, dan geen DX10). Tegelijkertijd is MS van plan de volgende DX releases een stuk korter op elkaar te plannen, tussen DX11 en DX10 zal veel minder tijd zitten dan tussen DX9 en DX10 (of DX8 en DX9 for that matter). Voor de programmeur is dit wel fijn, in feite hoef je dan helemaal geen rekening meer te houden met wat verschillende hardware allemaal kan ondersteunen.

Overigens denk ik dat OpenGL enorm terrein gaat verliezen in de gamesmarkt na de introductie van DX10. Ze zitten nu net op 2.0, die eigenlijk gewoon de core features van DX8 implementeert. DX10 kijkt echter compleet op een andere manier naar de hardware met geometry shaders en resource management. De API verandert zo drastisch dat het niet eens mogelijk is om DX10 op pre-DX10 hardware draaiend te krijgen.

[terabyte]

apNia schreef op woensdag 29 maart 2006 @ 20:42:
Verloedert OpenGL inderdaad niet tot de grafische standaard voor professortjes en CAD-tekenaars, waardoor 't misschien in een neerwaards spiraal raakt?

Sorry, maar zou je deze flutopmerking verder willen toelichten? Omdat OpenGL de standaard is in de academische wereld voor wetenschappelijke visualisatie is OpenGL aan het verloederen?

edit:
Ach, ik zie dat het als 'grapje' bedoeld is. Toch raad ik je aan je even te verdiepen in het belang van wetenschappelijke visualisatie. Tweakertjes denken teveel in termen van spelletjes, maar vergeten dat in de academische wereld veel innovatiefs gebeurt, zeker op gebied van visualisatie.

[ Voor 26% gewijzigd door terabyte op 30-03-2006 11:31 ]

[.oisyn]

Misschien moet je de draad eerst doorlezen voordat je reageert: [rml]apNia in "[ OpenGL] de toekomst?"[/rml]

[ Voor 35% gewijzigd door .oisyn op 30-03-2006 11:31 ]

[terabyte]

.oisyn schreef op donderdag 30 maart 2006 @ 11:31:
Misschien moet je de draad eerst doorlezen voordat je reageert: [rml]apNia in "[ OpenGL] de toekomst?"[/rml]

Misschien moet je me even de kans geven mijn edit door te voeren

[Anoniem: 146043]

Zoijar schreef op woensdag 29 maart 2006 @ 20:33:
Minder progressie? OpenGL is hot het laatste jaar met versie 2.0 en bijkomend GLSL. (nu GPGPU populairder wordt zal je nog vaker opengl zien. "Science" mensen gebruiken bijna allemaal een unix variant + opengl, uiteraard MS research uitgesloten...) Plus nog het feit dat vendors gewoon opengl extensions kunnen maken, bij d3d kan dat volgens mij niet

Helemaal waar.

[Gerco]

.oisyn schreef op donderdag 30 maart 2006 @ 11:23:
Je kunt als driver vendor dus niet zomaar een generieke optimalisatie maken omdat het dan niet altijd goed werkt, en als gamer wil je gewoon een goede performance. Game-specific optimalisaties zijn dan de enige uitweg.

Dat snap ik en daar heb ik ook niets tegen. Wel tegen de manier waarop dat blijkbaar gebeurt. Misschien zou het beter zijn als DX een manier zou voorschrijven waarop dit soort optimalisaties getriggerd kunnen worden, blijkbaar is er behoefte aan dat soort dingen, dan kan het maar beter gestandaardiseerd worden ipv allerlei parameters/functies extra "valkuilen" te geven.

Extensies hebben zowel voor- als nadelen. Het voordeel is dat je een hardware feature meteen kan gebruiken, het nadeel is dat je gelijksoortige hardware-features op verschillende hardware in den beginne ook op verschillende manieren aan moet spreken.

Ik dacht eigenlijk dat 1 vendor dan een extentie zou definieren en andere vendors zouden besluiten om die extensie ook te implementeren als ze daar brood in zien. Dezelfde functionaliteit op verschillende manieren aanspreken zuigt natuurlijk.

Dit was vooral een crime tijdens de introductie van de vertex- en pixelshaders; DX8 kwam vrijwel gelijk met de hardware en iedereen kon het op een standaard manier gebruiken. In OpenGL werkte het voor nVidia hardware op een andere manier dan op ATi hardware.

Zoals gezegd, dat zuigt. Maar heb je hier niet altijd last van als een hardware vendor op eigen houtje een nieuwe feature gaat bedenken? Als ze allemaal achter de spec aan zouden lopen, had je nergens last van, maar dan hebben hardware vendors ook weer minder mogelijkheden om zich te onderscheiden.

DX10 gaat overigens nog een stukje verder, je kunt dan niet eens meer een featurelist opvragen omdat er blind vanuit kan worden gegaan dat alle DX10 features gewoon te gebruiken zijn op elk stukje hardware (zo niet, dan geen DX10).

Hier gaat de API dus de features van de hardware voorschrijven, MS bepaalt (in samenspraak met) welke features er in de nieuwe hardware komen te zitten dus. Op die manier kan OpenGL het natuurlijk nooit meer bijbenen kwa specs. Je krijgt dan een beetje een Win32 vs Wine situatie, de laatste zal altijd fors achterlopen op diegenen die de specs maakt.

Voor de programmeur is dit wel fijn, in feite hoef je dan helemaal geen rekening meer te houden met wat verschillende hardware allemaal kan ondersteunen.

Dat lijkt me ook wel ja, als je DX10 hebt, hoef je dus niet meer te vogelen wat er allemaal kan, maar gewoon doen. Je hebt de garantie dat het werkt.

Overigens denk ik dat OpenGL enorm terrein gaat verliezen in de gamesmarkt na de introductie van DX10.

Dat denk ik ook wel, OpenGL zal steeds verder gaan achterlopen. Vooral als MS de specs schrijft en (onder NDA) aan NVidia en ATi doorspeelt. Dan kan OpenGL pas gaan beginnen met inlopen als de specs gereleased zijn. Tegen de tijd dat OpenGL bij is, is DX11 (of 12) al uit.

Wat gaat er dan gebeuren als OpenGL zo ver achterloopt dat de nieuwste games er niet meer mee vooruit kunnen? Worden er dan gewoon geen games meer gemaakt voor niet-MS platformen (Win32, X-Box 360) of gaan die platformen dan ook DirectX (mogen) implementeren?

[ Voor 5% gewijzigd door Gerco op 30-03-2006 11:37 ]

[.oisyn]

Gerco schreef op donderdag 30 maart 2006 @ 11:34:
Worden er dan gewoon geen games meer gemaakt voor niet-MS platformen (Win32, X-Box 360) of gaan die platformen dan ook DirectX (mogen) implementeren?

De hele opengl/directx kwestie gaat alleen op voor win32. Sowieso komen er al erg weinig games uit op linux of Mac OS X omdat dat marketingwise niet heel erg loont (veel moeite voor relatief weinig klanten). Wat consoles betreft is het totaal geen issue, hoewel je een Direct3D variant voor de xbox en xbox360 kunt gebruiken wordt dat in de praktijk maar erg weinig gedaan. Waarom zou je een API gebruiken die bedoelt is om het een en ander te abstraheren als er niets te abstraheren valt omdat de hardware altijd bij iedereen hetzelfde is? Door zelf met die hardware te communiceren kun je dingen doen die de API eigenlijk niet toelaat. Onze PC renderer is geimplementeerd dmv DirectX 9, maar hij werkt net zo goed op de PS2 en Xbox en de PS3 en Xbox360 implementaties komen er binnenkort aan. API schmapi, gewoon lekker zelf met de hardware communiceren .

[Gerco]

.oisyn schreef op donderdag 30 maart 2006 @ 12:04:
De hele opengl/directx kwestie gaat alleen op voor win32. Sowieso komen er al erg weinig games uit op linux of Mac OS X omdat dat marketingwise niet heel erg loont (veel moeite voor relatief weinig klanten).
Wat consoles betreft is het totaal geen issue, hoewel je een Direct3D variant voor de xbox en xbox360 kunt gebruiken wordt dat in de praktijk maar erg weinig gedaan.

Aha, dat stukje begrip miste ik. Dat er weinig games voor Linux/MacOS gemaakt worden weet ik, maar als DirectX de standaard gaat voorschrijven zal dat vermoedelijk nog minder gaan worden. Als je op consoles OpenGL en DirectX helemaal niet nodig hebt, zie ik de game-toekomst van OpenGL somber in. Die zou dan dus alleen nog gebruikt worden in non-Windows games, waar er nu al bijzonder weinig van zijn en dat wordt alleen maar minder als OpenGL sterk gaat achterlopen.

[Zoijar]

Ik snap eigenlijk niet waarom je D3D zou gebruiken? Ik dacht altijd dat het was omdat consoles native DX ondersteunen, maar volgens oisyn is dat dus helemaal niet zo. Als je dan moet kiezen tussen twee APIs die ongeveer equivalent zijn, dan kies je toch voor degene die op het meeste platforms draait, ie. opengl? Bovendien snap ik niet waar het idee vandaan komt dat opengl ahterhaald is, of traag, of uit de tijd. Tot nu toe zie ik nieuwe nvidia hardware features sneller in opengl dan in DX. Vorige zomer kon je volgens mij alleen aan GPGPU doen met opengl, omdat DX geen goede floating point hardware buffering ondersteunde. OGL heeft een geintegreerde standaard shading language, framebuffer objects, multiple render targets en is volledig formeel gestandaardiseerd. Ik heb niks tegen DX, lijkt me in sommige opzichten best handig werken, maar ik snap gewoon niet waar het idee vandaan komt dat OGL niet state-of-the-art zou zijn?

(ik weet niet hoe dat bij DX zit, maar OGL heeft ook nog specificaties over correctheid en herhaalbaarheid. Games hoeven er "alleen" goed uit te zien, iets dat op zich erg moeilijk is tegenwoordig; respect voor de resultaten van game devers. Wetenschappelijke apps moeten echter voornamelijk correct zijn. Het ligt er allemaal maar net aan waar je de focus legt. Het een is niet meer of minder belangrijk dan het ander. Er wordt wel gewoon software rendering gebruikt omdat iets 64bit precies moet zijn, en hardware kan dat gewoon (nog) niet goed. Terwijl een game dus bv liever met 16bit half-floats werkt om net die paar extra frames er uit te persen)

[ Voor 27% gewijzigd door Zoijar op 30-03-2006 13:19 ]

[killercow]

.oisyn, ik weet dat je het niet tof vindt als ik ga vertellen dat open beter is, dus dat doe ik niet
Maaaar, zou zou jij pretty please misschien de gebruikte driver hacks en zo beschikbaar kunnen maken aan mensen als transgaming / wine?
Of zitten de getriggerde stukjes extra code alleen in de windows drivers?

Als de gemiddelde game dit soort hacks gebruikt kun je dus best verklaren waarom sommige dingen op linux via cedega inderdaad een stuk minder presteren dan op windows.

Ik neem aan dat dit soort dingen niet onder een NDA van nvidia vallen (want jullie engine mag waarschijnlijk ook gewoon verkocht worden zonder dat nvidia hier moeilijk over gaat doen), en aangezien nvidia jullie de tricks heeft gegeven is het ook niet echt intelectual property van jullie bedrijf te noemen toch?

[Gerco]

Ik hoop dat je dat niet serieus meent killercow. Ze zullen dan wel geen NDA hebben (al ben ik daar niet zo zeker van), maar je vraagt zoiets toch niet van een medewerker van een softwarebedrijf? Een developer zal nooit informatie over software van zijn baas naar buiten mogen brengen zonder toestemming, je moet het aan zijn baas vragen.

Als er hier tweakers toevallig bij Microsoft werken ga je die toch ook niet om de werking van Win32 vragen om Wine een beetje te helpen? Je weet dat dat niet kan.

[nero355]

.oisyn schreef op donderdag 30 maart 2006 @ 12:04:
API schmapi, gewoon lekker zelf met de hardware communiceren .

Mij is ooit verteld dat dit juist de reden is dat MS DirectX heeft gemaakt, omdat Windows zo in elkaar zat dat het dus niet mogelijk/stabiel was om direct de hardware aan te spreken ??

Verder weet ik dat er een flinke poos terug een leuk topic was over de toekomst van OpenGL en concurrentie met DirectX Ik ga even zoeken, hij is best nuttig om door te nemen !!!

[Zoijar]

nero355 schreef op donderdag 30 maart 2006 @ 13:50:
Mij is ooit verteld dat dit juist de reden is dat MS DirectX heeft gemaakt, omdat Windows zo in elkaar zat dat het dus niet mogelijk/stabiel was om direct de hardware aan te spreken ??

Klopt, maar die tijd zijn we wel voorbij. Dat was ook daarvoor de rede dat spellen bijna niet onder windows 3.11 draaiden, maar allemaal onder dos. Maar dat kwam voort uit onbegrip hoe protected mode juist en efficient gebruikt kon worden. OS's zijn wel iets verder nu dan in 1990 (wauw wat gaat het eigenlijk snel...15 jaar terug was er nog amper iets... nu wordt de "giga" al weer langzaam vervangen door de "tera"...)

[ Voor 12% gewijzigd door Zoijar op 30-03-2006 13:59 ]

[nero355]

[rml][ ALG] gamen onder Linux[/rml]

Niet 100% wat ik zocht maar wel veel nuttige info

Thnx @ Hierboven trouwens.

[killercow]

Gerco schreef op donderdag 30 maart 2006 @ 13:31:
Ik hoop dat je dat niet serieus meent killercow. Ze zullen dan wel geen NDA hebben (al ben ik daar niet zo zeker van), maar je vraagt zoiets toch niet van een medewerker van een softwarebedrijf? Een developer zal nooit informatie over software van zijn baas naar buiten mogen brengen zonder toestemming, je moet het aan zijn baas vragen.

Als er hier tweakers toevallig bij Microsoft werken ga je die toch ook niet om de werking van Win32 vragen om Wine een beetje te helpen? Je weet dat dat niet kan.

Gerco,

Waarom niet, ik vraag tenslotte geen algorithmes, of door dat bedrijf ontwikkelde ideeen..
Ik vraag alleen om de informatie die zij van Nvidia gehad hebben, en .oisyn is professioneel genoeg om er A netjes over te kunnen discussieren, en B het netjes aan zijn baas te vragen mocht hier inderdaad mogelijkheden in zien.

Ik denk wine en cedega er behoorlijk veel aan kunnen hebben op het moment dat ze aan tombraider gebinnen zodat ze niet uren aan raadselachtige vertragingen moeten besteden die alleen door middel van een driver hack opgelost konden worden in het origineel.

Toch? of denk ik nou echt te krom?

[.oisyn]

Zoijar schreef op donderdag 30 maart 2006 @ 13:09:
Ik snap eigenlijk niet waarom je D3D zou gebruiken? Ik dacht altijd dat het was omdat consoles native DX ondersteunen, maar volgens oisyn is dat dus helemaal niet zo. Als je dan moet kiezen tussen twee APIs die ongeveer equivalent zijn, dan kies je toch voor degene die op het meeste platforms draait, ie. opengl?

D3D werkt fijner op win32, de documentatie is duidelijker en eenzijdiger, en het heeft betere debugging support. Ook kun je wat beter bij je resources, wat voor OpenGL wat meer weggeabstraheerd is, en full screen applicaties zijn voor d3d veel beter ondersteund (in ogl maak je gewoon een fullscreen window over je desktop, het moet dus nog altijd samen blijven werken met GDI). Maar kwa API verschilt het idd niet zoveel, tot de komst van DX10 iig. Daarna ben je imho gewoon idioot als je voor games voor opengl kiest en je niet heel erg van plan bent voor linux en/of Mac te ontwikkelen.

Vorige zomer kon je volgens mij alleen aan GPGPU doen met opengl, omdat DX geen goede floating point hardware buffering ondersteunde.

d3d wel hoor, het probleem zat 'm denk ik in het feit dat nvidia hardware niet helemaal voldeed aan de eisen van d3d en daarom in d3d geen floating point buffers ondersteunde, terwijl ze in ogl wel mogelijk waren. Dit is later gefixed met een driver update.

OGL heeft een geintegreerde standaard shading language, framebuffer objects, multiple render targets en is volledig formeel gestandaardiseerd.

Let wel, nu pas. d3d ondersteunde die dingen al veel en veel langer. Ogl blijft een log consortium hebben (net als C++), d3d ligt nu even stil omdat er hard wordt gewerkt aan de volgende versie maar daarna zullen gestandaardiseerde updates veel sneller volgen.

(ik weet niet hoe dat bij DX zit, maar OGL heeft ook nog specificaties over correctheid en herhaalbaarheid.

DX heeft die ook hoor, hoewel het in benchmarks nog weleens aan de laars wordt gelapt door de drivers (maar dat zal met opengl net zo goed gebeuren)

[.oisyn]

killercow schreef op donderdag 30 maart 2006 @ 13:20:
Maaaar, zou zou jij pretty please misschien de gebruikte driver hacks en zo beschikbaar kunnen maken aan mensen als transgaming / wine?

Ik heb toch geen toegang tot de sourcecode van de drivers . Daarnaast zou ik ze zeker niet lekken.

[apNia]

.oisyn schreef op donderdag 30 maart 2006 @ 14:39:
[...]

*snip.... SNIP-SNIP*

Maar kwa API verschilt het idd niet zoveel, tot de komst van DX10 iig. Daarna ben je imho gewoon idioot als je voor games voor opengl kiest en je niet heel erg van plan bent voor linux en/of Mac te ontwikkelen.

*snip.... SNIP-SNIP*

Waarom vind je dat trouwens?

[Gerco]

.oisyn schreef op donderdag 30 maart 2006 @ 14:39:
Maar kwa API verschilt het idd niet zoveel, tot de komst van DX10 iig. Daarna ben je imho gewoon idioot als je voor games voor opengl kiest en je niet heel erg van plan bent voor linux en/of Mac te ontwikkelen.

Hierdoor heb ik dus sterk het idee dat OpenGL effectief uit de games markt zal verdwijnen. Geen enkele games ontwikkelaar ontwikkelt nu gericht voor Linux/MacOSX. Dat het erop werkt als het af is, is mooi meegenomen, maar daar blijft het dan wel bij.

Als DX10 veel gebruikt gaat worden en echt zo goed is als .oisyn beweert, is dat gewoon de doodsteek voor games op non-Windows OS'en (op PC hardware). Tenzij die OS'en toestemming krijgen om DirectX te implementeren (voor zover dat mogelijk is dan). Die OS'en zullen dan wel altijd hopeloos blijven achterlopen op de standaard, want die kunnen pas beginnen met implementeren wanneer de API niet meer onder NDA ligt en dus de nieuwe DX gereleased is.

[.oisyn]

apNia schreef op donderdag 30 maart 2006 @ 14:52:
[...]

Waarom vind je dat trouwens?

hierom
(Dit is de D3D10 presentatie van de GDC, die de afgelopen paar dagen gehouden is in San Jose)

D3d slaat nu een heel andere weg in dan ogl. Waar de API's voorheen nog vrij gelijk aan elkaar waren legt d3d de hardware nu veel meer bloot. Dat vereist wel een strictere compliance, iets wat ogl nooit kan bereiken omdat die veel meer hardware moet ondersteunen. Het een en ander kan natuurlijk bereikt worden met extensions maar ogl blijft een logge statemachine met teveel overhead, iets waar d3d ook altijd mee te kampen had maar wat nu radicaal gaat veranderen.

[ Voor 39% gewijzigd door .oisyn op 30-03-2006 15:41 ]

[killercow]

.oisyn schreef op donderdag 30 maart 2006 @ 14:40:
[...]

Ik heb toch geen toegang tot de sourcecode van de drivers . Daarnaast zou ik ze zeker niet lekken.

Nee dat lijkt me logisch,

Maar je weet misschien wel welke stukjes code lomp langzaam zijn tenzij je "boe12346" roept tegen de driver. dat is toch het meest waardevolle voor de wine gasten?
Dat ze niet uren lopen te turen op een of andere hickup omdat de windows driver er ondanks de juist geemuleerde API toch anders mee omgaat dan de linux driver.

Anyway, allemaal zwaar off-topic dit allemaal.

[Anoniem: 146043]

.oisyn schreef op donderdag 30 maart 2006 @ 12:04:
[...]


De hele opengl/directx kwestie gaat alleen op voor win32. Sowieso komen er al erg weinig games uit op linux of Mac OS X omdat dat marketingwise niet heel erg loont (veel moeite voor relatief weinig klanten). Wat consoles betreft is het totaal geen issue, hoewel je een Direct3D variant voor de xbox en xbox360 kunt gebruiken wordt dat in de praktijk maar erg weinig gedaan. Waarom zou je een API gebruiken die bedoelt is om het een en ander te abstraheren als er niets te abstraheren valt omdat de hardware altijd bij iedereen hetzelfde is? Door zelf met die hardware te communiceren kun je dingen doen die de API eigenlijk niet toelaat. Onze PC renderer is geimplementeerd dmv DirectX 9, maar hij werkt net zo goed op de PS2 en Xbox en de PS3 en Xbox360 implementaties komen er binnenkort aan. API schmapi, gewoon lekker zelf met de hardware communiceren .

De oplossing komt steeds dichterbij. CeDeGa is een voor Linux emulerende omegeving zodat er nog verassend veel DX games op draaien. Wellicht komen er nog verbeteringen op komst voor CeDeGa en Linux zodat ik eindelijk eens écht kan overstappen.

*Ik vind de NeoNova server (Linux base firewaller) nog de meest leuke server om mee te werken

[Zoijar]

.oisyn schreef op donderdag 30 maart 2006 @ 15:33:
(Dit is de D3D10 presentatie van de GDC, die de afgelopen paar dagen gehouden is in San Jose)

Oh is dat al geweest... ik heb hier nog steeds een uitnodiging liggen; nuttig Naja, het was toch ook erg ver weg

[Bloody NO!]

Vreemd dat ik niemand hoor over de Linux-tegenhangers van MS Aero? Namelijk XGL (later Xegl) en AIGLX. De GL in die namen refereert inderdaad naar OpenGL. Ik verwacht dat dit een steeds grotere rol op de Linux-desktop gaat spelen, want de bouwers van grafische kaarten verbeteren op het moment alleen maar het '3D-gedeelte' en laat het 2D-gedeelte hangen. OpenGL is bij uitstek de meest realistische optie om die kracht in iets nuttigs om te zetten. Onder andere voor eye-candy, maar ook een veel snellere rendering van desktopapplicaties. (dus voelt het allemaal wat sneller aan.)

Nee, als ik hiernaar kijk is OpenGL verre van dood.

[.oisyn]

Bloody NO! schreef op donderdag 30 maart 2006 @ 19:38:
Vreemd dat ik niemand hoor over de Linux-tegenhangers van MS Aero? Namelijk XGL (later Xegl) en AIGLX. De GL in die namen refereert inderdaad naar OpenGL. Ik verwacht dat dit een steeds grotere rol op de Linux-desktop gaat spelen, want de bouwers van grafische kaarten verbeteren op het moment alleen maar het '3D-gedeelte' en laat het 2D-gedeelte hangen.

Euh, wat moet er nog aan 2d bijkomen dan? Heb je een beetje een idee hoe je een videokaart aanstuurt met een API als ogl of d3d? Als dat zo was dan zou je je moeten realiseren dat dat prima mogelijk is met de huidige hardware, want het enige dat een videokaart kan is polygonen plotten en vectorberekeningen uitvoeren. En je scherm blijft 2D, of je er nou een 3D wereld op projecteert of niet . Dus zoveel '3d' dingen worden er niet echt ontwikkeld door de hardware vendors, wel betere technieken om vector graphics te renderen, maar dat is toch waar het uiteindelijk om gaat?

Dus waarom dat nou voor opengl spreekt snap ik niet helemaal...

[ Voor 15% gewijzigd door .oisyn op 30-03-2006 21:41 ]

[peke]

Ik vraag me af wat er gaat worden van OpenGL onder vista.
Eerdere berichten spraken van emulatie via DX omdat de gui van vista DX vereist.
Als het idd zo is dat OpenGL gewoon een fullscreen venster bovenop in de gui kan er dan nog sprake zijn van OpenGL rendering onder vista?
Als het van microsoft afhangt zal het antwoord neen zijn.

[.oisyn]

Wat weerhoudt de hardware vendors om met een ogl implementatie te komen, en waarom is het dan geen opengl rendering? Het is alleen maar een api hoor, hoevel lagen daar nog onder zitten maakt in principe geen zak uit (denk je dat opengl momenteel al direct op de hardware werkt?).

[EfBe]

.oisyn schreef op donderdag 30 maart 2006 @ 22:39:
Wat weerhoudt de hardware vendors om met een ogl implementatie te komen, en waarom is het dan geen opengl rendering? Het is alleen maar een api hoor, hoevel lagen daar nog onder zitten maakt in principe geen zak uit (denk je dat opengl momenteel al direct op de hardware werkt?).

Nee dat is niet zo makkelijk. Er is nl. een patentenkwestie aan de hand. Microsoft heeft nl. een of ander patent om een OpenGL rendercanvas te plakken op een window, dat gedoe via opengl32.dll wat je altijd moet doen, ongeacht de driver.

Een aantal jaren geleden heeft de arb al een volledige OpenGL 2.0 implementatie opgestuurd aan MS (notabene lid van de ARB) om de oude opengl32.dll te vervangen, maar dat is tot op heden nooit gedaan. En het nare is dat niemand anders dan MS een opengl32.dll kan leveren voor windows ivm dat patent (dat is althans de uitleg van de arb, in de opengl newsgroup gepost een aantal jaren terug).

nVidia (en ati ook dacht ik nu) hebben overigens 1 uniforme driver core waar ze met zowel dx als ogl tegenaanpraten, dus voor de drivers an sig maakt het niet uit, het is puur opengl's verbinding met windows wat alles tegenhoudt.

En op de frontpage mensen maar roepen dat ze Neelie niet snappen met der vista brief. Ik snap Neelie nooit maar deze keer wel

.oisyn schreef op donderdag 30 maart 2006 @ 14:39:
Maar kwa API verschilt het idd niet zoveel, tot de komst van DX10 iig. Daarna ben je imho gewoon idioot als je voor games voor opengl kiest en je niet heel erg van plan bent voor linux en/of Mac te ontwikkelen.

Ja maar ... Carmack vindt dat ... dat... Opengl wel gaaf is... !

[ Voor 13% gewijzigd door EfBe op 30-03-2006 23:16 ]

[apNia]

Woord op de straat dat Carmack met DX10 lekker overstapt juist

[dawuss]

Bloody NO! schreef op donderdag 30 maart 2006 @ 19:38:
Vreemd dat ik niemand hoor over de Linux-tegenhangers van MS Aero? Namelijk XGL (later Xegl) en AIGLX. De GL in die namen refereert inderdaad naar OpenGL. Ik verwacht dat dit een steeds grotere rol op de Linux-desktop gaat spelen, want de bouwers van grafische kaarten verbeteren op het moment alleen maar het '3D-gedeelte' en laat het 2D-gedeelte hangen. OpenGL is bij uitstek de meest realistische optie om die kracht in iets nuttigs om te zetten. Onder andere voor eye-candy, maar ook een veel snellere rendering van desktopapplicaties. (dus voelt het allemaal wat sneller aan.)

Nee, als ik hiernaar kijk is OpenGL verre van dood.

Volgens mij heb ik dat wel degelijk gemeld, tegelijkertijd met het onder de aandacht brengen van Mac OS X, waarbij vrijwel alles onder OpenGL gebeurt.

Ik vind DirectX met OpenGL vergelijken sowieso gelijk staan aan appels met peren vergelijken. DirectX is een compleet medialibrary vergelijkbaar met SDL, Direct3D is daarvan de grafische component, dus vergelijk dat ook met OpenGL

[.oisyn]

EfBe schreef op donderdag 30 maart 2006 @ 23:06:
[...]

Nee dat is niet zo makkelijk. Er is nl. een patentenkwestie aan de hand. Microsoft heeft nl. een of ander patent om een OpenGL rendercanvas te plakken op een window, dat gedoe via opengl32.dll wat je altijd moet doen, ongeacht de driver.

Nou ken ik de details niet van dat patent maar ik vraag me af of dat stand houdt in het nieuwe OS. Vista heeft natuurlijk een hele nieuwe grafische schil gebaseerd op vector graphics, en het lijkt me relatief makkelijk voor de videodrivers om daar een rendercontext overheen te painten. En het lijkt me niet dat MS een patent heeft op "een opengl implementatie in windows", en er zijn natuurlijk wel andere alternatieven dan opengl32.dll om de opengl api aan de man te brengen .

[Anoniem: 3142]

Ik denk dat dit gedoe in Vista vooral te maken heeft met het 'shared videokaart' idee van Vista. Onder andere omdat Vista bomvol zit met grafische elementen die hardware ondersteuning nodig hebben voor rendering, hebben ze van het 3D device een niet-exlusieve resource gemaakt in de D3D10 API, zodat het OS en verschillende grafische applicaties er tegelijk gebruik van kunnen maken. Een bijkomend voordeel hiervan is dat je device in principe nooit meer 'lost' kan raken, tenzij het hardwarematig tijdens het draaien van een 3D app/Vista eruit wordt getrokken (met GPUs in laptop docking stations bijvoorbeeld).

Om dit allemaal fatsoenlijk te laten werken kun je het natuurlijk niet hebben dat OpenGL een exclusieve 'lock' op het 3D device probeert te nemen, dus zal het inderdaad zeer waarschijnlijk zo zijn dat OpenGL bovenop D3D10 gelayerd wordt. Maar het is dus geen onwil dat MS van plan schijnt te zijn OpenGL niet meer 'normaal' te ondersteunen.

Wat betreft de toekomst (on-topic ), beide platformen zijn redelijk feature-equivalent, dus het is eigenlijk een kwestie van persoonlijke voorkeur. OpenGL is open, maar DirectX biedt een vaste standaard. DirectX is een complete API, voor OpgenGL zul je een beroep moeten doen op initiatieven als SDL voor deze functionaliteit. Omdat OpenGL meer lowlevel is, kunnen ze makkelijker inspelen op hardware veranderingen met hun extensions mechanism, maar daar staat tegenover dat DirectX met z'n vaste specs voor shader model generaties een uniforme implementatie van deze nieuwe features afdwingt bij de hardware fabrikanten.

Wat betreft commercieel gebruik, voor zover ik heb begrepen zal Sony voor de PS3 een vorm van OpenGL gaan gebruiken en gebruikt MS natuurlijk een vorm van DirectX op de XBox360. Omdat consoles iets van 90% van de games markt bestrijken, zullen beide platformen nog lang meegaan.

[EfBe]

.oisyn schreef op vrijdag 31 maart 2006 @ 01:43:
[...]
Nou ken ik de details niet van dat patent maar ik vraag me af of dat stand houdt in het nieuwe OS. Vista heeft natuurlijk een hele nieuwe grafische schil gebaseerd op vector graphics, en het lijkt me relatief makkelijk voor de videodrivers om daar een rendercontext overheen te painten. En het lijkt me niet dat MS een patent heeft op "een opengl implementatie in windows", en er zijn natuurlijk wel andere alternatieven dan opengl32.dll om de opengl api aan de man te brengen .

Tuurlijk, een ervan is MESA. Het gaat er echter om dat om opengl te gebruiken in je app ZONDER vendor specifieke ICD dlls te linken je tegen opengl32.dll aanpraat en die laadt dan de vendor ICD, mits je pixeldescriptor natuurlijk ondersteunt wordt door de ICD anders val je terug op swerelds snelste *cough* software renderer, opengl32.dll zelf. En dat is nu juist de ellende: die opengl32.dll wordt niet meer geupdate vanuit Redmond, terwijl SGI ze al jaren geleden de spullen heeft opgestuurd. (SGI's Jon Leech in google groups link). Dit zorgt er dus voor dat de opengl32.dll nog altijd opengl 1.1 is en je altijd en eeuwig met extensions moet kloten wil je wat leuks doen, terwijl opengl's core api, de standaard, allang verder is.

Hier nog een thread omtrent vermeend opengl termination in windows2000: SGI's Jon Leech in google groups thread (ja die snaak waar hij op reageert is ondergetekende .

Zoals je ziet heeft SGI in het verleden het werk allang gedaan maar is het nooit tot ook maar dat service pack met OpenGL 1.2 gekomen. En dat zal zo blijven denk ik.

In Vista wordt OpenGL over DX gelegd, wat erop neerkomt dat het dus een 2e rangs API wordt. Mja. Als oud OpenGL gebruiker moet ik zeggen dat ik nooit echt gecharmeerd ben geweest van D3D noch van de MS tactics op dit gebied, maar goed, je houdt het toch niet tegen.

[EfBe]

Anoniem: 3142 schreef op vrijdag 31 maart 2006 @ 09:55:
Om dit allemaal fatsoenlijk te laten werken kun je het natuurlijk niet hebben dat OpenGL een exclusieve 'lock' op het 3D device probeert te nemen, dus zal het inderdaad zeer waarschijnlijk zo zijn dat OpenGL bovenop D3D10 gelayerd wordt. Maar het is dus geen onwil dat MS van plan schijnt te zijn OpenGL niet meer 'normaal' te ondersteunen.

Om de dooie donder wel. In 1999 hadden ze de 1.2 source al binnen. Het is nu 2006. Nog altijd is opengl32.dll een 1.1 lib. Ook is het echt niet moeilijk om de hardware niet meer exclusive te maken voor opengl, iedere hw fabrikant maakt toch 1 driver die van 2 api's wordt voorzien.

Wat betreft commercieel gebruik, voor zover ik heb begrepen zal Sony voor de PS3 een vorm van OpenGL gaan gebruiken en gebruikt MS natuurlijk een vorm van DirectX op de XBox360. Omdat consoles iets van 90% van de games markt bestrijken, zullen beide platformen nog lang meegaan.

Volgens mij gebruikt menig console developer gewoon de hardware reference manuals van zn targetplatform en gaat vrolijk registers zitten vullen ipv het via OpenGL of D3D het allemaal aan te sturen.

[Anoniem: 3142]

Om de dooie donder wel. In 1999 hadden ze de 1.2 source al binnen. Het is nu 2006. Nog altijd is opengl32.dll een 1.1 lib. Ook is het echt niet moeilijk om de hardware niet meer exclusive te maken voor opengl, iedere hw fabrikant maakt toch 1 driver die van 2 api's wordt voorzien.

Volgens mij praten we langs elkaar door. Momenteel is het goed mogelijk dat je je device kwijt raakt aan een andere fullscreen app of als je windows workstation gelockt wordt bijvoorbeeld. In Vista zou dit volgens MS niet meer moeten gebeuren, omdat het videokaart Device niet meer direct gebruikt wordt door 3D apps, maar 'shared' ter beschikking wordt gesteld door de D3D10 runtime, waardoor het managen van het gebruik van deze kaart op een hoger level gebeurt dan nu met D3D9.

Voor zover ik weet werkt OpenGL wat dit betreft net zoals D3D9, dus om problemen hiermee in de Vista opzet te voorkomen zul je het ook van de D3D10 runtime gebruik moeten laten maken. MS zal van OpenGL natuurlijk geen top prioriteit maken, maar een groot deel van de PC games wordt nog altijd in OpenGL geschreven, ondersteuning voor games is een commercieel belangrijke feature voor Windows, dus ze zouden alleen hun eigen ruiten ingooien als de OpenGL ondersteuning van Vista niet voldeed aan de wensen van games developers.

Volgens mij gebruikt menig console developer gewoon de hardware reference manuals van zn targetplatform en gaat vrolijk registers zitten vullen ipv het via OpenGL of D3D het allemaal aan te sturen

Dat kan, daar heb ik geen zicht op, maar het lijkt me niet dat deze aanpak dan nou De Toekomst heeft. Bij PC games zie je tegenwoordig ook de focus verschuiven van bijvoorbeeld gpu assembly naar HLSL/GLSL, dus ik neem toch aan dat console developers hier ook naar verkast zijn, maar daar moet .oisyn z'n licht maar eens overlaten schijnen.

Van wat ik gehoord heb ondersteunt de XBox360 gewoon de DX9 API en krijgen we binnenkort (over een jaartje hopelijk) zelfs de mogelijkheid om het .NET platform op de 360 te gebruiken, dus het wordt alleen maar meer high-level. Als MS er brood in ziet om verder high-level te gaan, dan kan ik me niet voorstellen dat game developers hier geen gebruik van maken. Natuurlijk zullen er bepaalde dingen zo lowlevel moeten worden geoptimaliseerd, maar met de nadruk op kortere ontwikkeltrajecten voor games lijkt het me onwaarschijnlijk dat het merendeel van de developers de aanpak die jij beschrijft prefereert.

[.oisyn]

EfBe schreef op vrijdag 31 maart 2006 @ 10:09:In Vista wordt OpenGL over DX gelegd, wat erop neerkomt dat het dus een 2e rangs API wordt.

Niet meer dan een 2e rangs API dan het nu al is denk ik. Ogl baseren op de huidige d3d wordt idd wat vervelend, maar ik denk dat het met d3d10 goed te doen is. Met de geometry shaders kun je zelfs quadstrips/lists gaan supporten.

Als oud OpenGL gebruiker moet ik zeggen dat ik nooit echt gecharmeerd ben geweest van D3D

Waarom eigenlijk niet? Ok, pre d3d8 is het logisch, toen deed ik ook nog opengl . Maar vanaf d3d8 vind ik de API een stuk degelijker dan ogl, en met d3d10 lijkt het erop dat ogl voor mij definitief heeft afgedaan

[ Voor 30% gewijzigd door .oisyn op 31-03-2006 13:45 ]

[EfBe]

.oisyn schreef op vrijdag 31 maart 2006 @ 13:35:
[...]
Waarom eigenlijk niet? Ok, pre d3d8 is het logisch, toen deed ik ook nog opengl . Maar vanaf d3d8 vind ik de API een stuk degelijker dan ogl, en met d3d10 lijkt het erop dat ogl voor mij definitief heeft afgedaan

Nou het is ook wel weer een paar jaartjes geleden maar de functie oriented aanpak van OpenGL vond ik wel beter passen dan de D3D aanpak (tja, opgevoed met C, dan heb je dat ). Maar inderdaad, als je eenmaal over bent naar OO dan is D3D een stuk logischer. Ik heb (nog) niet naar dx10 gekeken, maar het schijnt dus stukken beter te worden? Maar in welk opzicht dan? Veel objects die eigenlijk dunne wrappers zijn om hardware elements waar je tegenaan praat en dus minder high-level abstractie?

Anoniem: 3142 schreef op vrijdag 31 maart 2006 @ 10:53:
[...]
Volgens mij praten we langs elkaar door. Momenteel is het goed mogelijk dat je je device kwijt raakt aan een andere fullscreen app of als je windows workstation gelockt wordt bijvoorbeeld. In Vista zou dit volgens MS niet meer moeten gebeuren, omdat het videokaart Device niet meer direct gebruikt wordt door 3D apps, maar 'shared' ter beschikking wordt gesteld door de D3D10 runtime, waardoor het managen van het gebruik van deze kaart op een hoger level gebeurt dan nu met D3D9.

Ja dat snap ik, maar dat geeft nog niet aan waarom een opengl programma dan door d3d heen moet. De hw wordt toch bestuurd door de videodriver core, en DIE snapt dat het een gesharede resource moet zijn in vista, en of de call nu van een opengl app afkomt of van d3d, lijkt mij voor die driver om het even, want het lijkt mij onwaarschijnlijk dat bv alle texture management van alle apps die draaien door een global layer verzorgt wordt die d3d10 heet, dat wil je toch per app houden lijkt me.

Voor zover ik weet werkt OpenGL wat dit betreft net zoals D3D9, dus om problemen hiermee in de Vista opzet te voorkomen zul je het ook van de D3D10 runtime gebruik moeten laten maken. MS zal van OpenGL natuurlijk geen top prioriteit maken, maar een groot deel van de PC games wordt nog altijd in OpenGL geschreven, ondersteuning voor games is een commercieel belangrijke feature voor Windows, dus ze zouden alleen hun eigen ruiten ingooien als de OpenGL ondersteuning van Vista niet voldeed aan de wensen van games developers.

Welke commerciele belangen kleven er aan OpenGL op dit moment dan nog? Alle 3D apps van betekenis draaien op d3d, behalve wellicht blender wellicht. En een 3D engine heeft tegenwoordig gewoon renderplugins dus die kan zo een andere api ondersteunen. Mits redelijk opgezet natuurlijk. Carmack programmeert wat dat betreft niet echt voor de extensibility.

[...]
Dat kan, daar heb ik geen zicht op, maar het lijkt me niet dat deze aanpak dan nou De Toekomst heeft. Bij PC games zie je tegenwoordig ook de focus verschuiven van bijvoorbeeld gpu assembly naar HLSL/GLSL, dus ik neem toch aan dat console developers hier ook naar verkast zijn, maar daar moet .oisyn z'n licht maar eens overlaten schijnen.

Volgens mij heeft ie dat al gedaan eerder in deze thread toen hij aangaf dat (althans dat lees ik er in) bij Nixxes ze de d3d api vrolijk overslaan op de console (en terecht)

Van wat ik gehoord heb ondersteunt de XBox360 gewoon de DX9 API en krijgen we binnenkort (over een jaartje hopelijk) zelfs de mogelijkheid om het .NET platform op de 360 te gebruiken, dus het wordt alleen maar meer high-level.

hehehe .NET op de xbox360. Ja ik las het ook, maar het is echt een marketing feature waar geen hond iets mee gaat doen, tenzij wellicht voor bejeweled achtige games die niet veel power nodig hebben of, waar ze wellicht op hopen, non-game apps voor op de xbox 360 die iets doen met 'multimedia'. Met WPF kun je wel op een hogere abstractieschaal toch leuke dingen gaan doen, dat moet gezegd, maar voor games geloof ik er echt niet in. Maar goed, vroeger waren er ook mensen die maakten hun amiga demos in AMOS basic.

Als MS er brood in ziet om verder high-level te gaan, dan kan ik me niet voorstellen dat game developers hier geen gebruik van maken. Natuurlijk zullen er bepaalde dingen zo lowlevel moeten worden geoptimaliseerd, maar met de nadruk op kortere ontwikkeltrajecten voor games lijkt het me onwaarschijnlijk dat het merendeel van de developers de aanpak die jij beschrijft prefereert.

denk je? Ik denk juist dat de gemiddelde engine developer (en dat is dus maar een klein segment van de game developers die meer in de game engine-taal game specifieke zaken bouwen) juist zo dicht mogelijk bij 'the metal' wil blijven want dan maak je pas echt meters. Alhoewel wel veel verschuift naar de shader-talen.

[ Voor 72% gewijzigd door EfBe op 31-03-2006 13:49 ]

[apNia]

.oisyn schreef op vrijdag 31 maart 2006 @ 13:35:
[...]

Waarom eigenlijk niet? Ok, pre d3d8 is het logisch, toen deed ik ook nog opengl . Maar vanaf d3d8 vind ik de API een stuk degelijker dan ogl, en met d3d10 lijkt het erop dat ogl voor mij definitief heeft afgedaan

Gaat met D3D10 de syntax nou erg veranderen ook? Of wordt 't een eitje voor D3D9 coders om over te stappen? (AKA gewoon meer features)

[.oisyn]

EfBe, apNia: browse http://download.microsoft...4/Intro_to_Direct3D10.ppt eens door zou ik zeggen

[Zoijar]

.oisyn schreef op vrijdag 31 maart 2006 @ 13:47:
EfBe, apNia: browse http://download.microsoft...4/Intro_to_Direct3D10.ppt eens door zou ik zeggen

Klinkt goed. Hoewel ik niet vind dat je dit zo maar met OGL mag vergelijken. Ze hebben het over shader model 4 video kaarten. Die zijn er nog niet, en als die er zijn zal OGL er ook zeker support voor uitbrengen. GLSL zal wel worden uitgebreid met geometry programs; hoe lang dit gaat duren... tsja. Maar een versimpeling is erg welkom... ik vind dat de programmeur nu te veel op kleine performance details moet letten. Drivers zouden dat automatisch slim moeten doen eigenlijk. Ook al dat gezeur met verschillende hardware buffers en formaten etc. Denk dat ik me maar eens ga verdiepen in d3d-10 wanneer het er is. Ik vind beide APIs eigenlijk slecht op het moment, je moet te veel details instellen. Maar dat zal wel voort komen uit de snelle vooruitgang in de hardware: alles kan tegenwoordig ineens.

[Anoniem: 3142]

Ok, nog een poging met het beetje dat ik weet

...maar dat geeft nog niet aan waarom een opengl programma dan door d3d heen moet. De hw wordt toch bestuurd door de videodriver core, en DIE snapt dat het een gesharede resource moet zijn in vista, en of de call nu van een opengl app afkomt of van d3d, lijkt mij voor die driver om het even, want het lijkt mij onwaarschijnlijk dat bv alle texture management van alle apps die draaien door een global layer verzorgt wordt die d3d10 heet, dat wil je toch per app houden lijkt me.

Ik weet niet specifiek hoe dit wordt vormgegeven, maar het zal denk ik niet zo worden dat OpenGL ge-emuleerd gaat worden door D3D10. De meest logische opzet lijkt mij dat D3D10 een extra laag van abstractie tussen de videokaart en de applicatie laag aanbrengt, waardoor het managen van de devices makkelijker wordt (kort door de bocht, je device object wordt een singleton binnen de D3D10 api). Ik weet natuurlijk niet hoe het allemaal precies onder de motorkap zit, maar ik denk dat OpenGL dus ook op de een of andere manier van dit shared device 'object' gebruik moet gaan maken.

Ik heb (nog) niet naar dx10 gekeken, maar het schijnt dus stukken beter te worden? Maar in welk opzicht dan? Veel objects die eigenlijk dunne wrappers zijn om hardware elements waar je tegenaan praat en dus minder high-level abstractie?

De abstractie blijft van ongeveer hetzelfde niveau als D3D9, met oa de volgende verbetering alleen al voor shaders:

• Geometry shaders, shaders voor triangles die in de pijplijn tussen vertex shaders en pixel shaders in komen te zitten. Naar verluid handig voor creating van geometry op de GPU
• Re-assingable shader stream, zodat je de output van je shaders op elk moment tijdens het renderen kunt omleiden. Handig voor permanente mesh transformaties op de GPU en voor het samenvoegen van meerdere render passes
• Predicate rendering, extreem handing voor volledige hardware occlusion culling

De abstractie gaat eigenlijk dus zelfs nog een beetje omlaag, omdat je nu de controle krijgt over de streams op de video kaart.

Welke commerciele belangen kleven er aan OpenGL op dit moment dan nog? ... Carmack programmeert wat dat betreft niet echt voor de extensibility.

Waar maak je je dan druk om? Maar als Doom III alleen al niet op Windows had gedraaid, dan hadden een hoop mensen weer een hoop kritiek geleverd. Dus het is gewoon uit principe al nodig dat Windows OpenGL ondersteunt, omdat ze toch proberen om een zo breed mogelijk platform te bieden, alle krtiek ten spijt.

[...]
Volgens mij heeft ie dat al gedaan eerder in deze thread toen hij aangaf dat (althans dat lees ik er in) bij Nixxes ze de d3d api vrolijk overslaan op de console (en terecht)

Ik weet niet of dat terecht is, maar ik zou er zowiezo graag meer over weten. Dus .oisyn, als je je geroepen voelt om een tipje van de GameDev sluier op te lichten, dan ga gerust je gang

hehehe .NET op de xbox360. Ja ik las het ook, maar het is echt een marketing feature waar geen hond iets mee gaat doen, tenzij wellicht voor bejeweled achtige games die niet veel power nodig hebben of, waar ze wellicht op hopen, non-game apps voor op de xbox 360 die iets doen met 'multimedia'.

Naja, we zullen het zien. Ik heb af en toe contact met degene die die Hexis demo heeft geschreven en voor 3 weken programmeren in z'n eentje ziet het er toch leuk uit, vooral omdat er schijnbaar ook nog een Flash authoring mogelijkheid in zit zodat ze de demo bij MS kunnen gebruiken om te testen.

Ik werk zelf nu een jaartje met Managed DirectX (MDX, DirectX in C#) en dat bevalt prima. De API's zijn feature equivalent en qua performance scheelt het zich ook niet veel, terwijl C# wel voor een flinke productivity boost zorgt (persoonlijke voorkeur misschien, maar dit vinden genoeg mensen). MS heeft zich met het XNA framework gecommit aan de toekomst van MDX, wat aangeeft dat het toch wel meer is dan een reclame stunt.

Trounwens, ooit gehoord van Geometry Wars? Je spel hoeft niet ultra-realistisch 3D te zijn om je rijk te maken

denk je? Ik denk juist dat de gemiddelde engine developer (en dat is dus maar een klein segment van de game developers die meer in de game engine-taal game specifieke zaken bouwen) juist zo dicht mogelijk bij 'the metal' wil blijven want dan maak je pas echt meters. Alhoewel wel veel verschuift naar de shader-talen.

Met de (vanaf D3D10 geschrapte) fixed function pipeline, zeg maar de oude API, heb je gelijk. Maar vanaf DX9 zit je met HLSL al rechtstreeks op "the metal", dus daar zijn maar marginale verbeteringen te behalen door extreem lowlevel te gaan. Naast dit renderen, wat over het algemeen toch de grootste resource hog is, komt het eigenlijk gewoon neer op structuur aanbrengen en met wat andere devices communiceren (audio, input etc) en daar is met low-level werk AFAIK al helemaal weinig eer te behalen.

[ Voor 1% gewijzigd door Anoniem: 3142 op 31-03-2006 14:22 . Reden: Zpelling ]

[.oisyn]

Anoniem: 3142 schreef op vrijdag 31 maart 2006 @ 10:53:
Voor zover ik weet werkt OpenGL wat dit betreft net zoals D3D9, dus om problemen hiermee in de Vista opzet te voorkomen zul je het ook van de D3D10 runtime gebruik moeten laten maken.

Nee, een opengl context kun je niet kwijtraken. OpenGL apps zijn ook nooit echt fullscreen, en hebben de videokaart dus ook niet in exclusive mode zoals fullscreen d3d aps dat wel hebben.

maar een groot deel van de PC games wordt nog altijd in OpenGL geschreven

Oh? Het zijn er nog maar erg weinig, en de verwachting is dat met de komst van d3d het er nog minder worden. En als de opengl implementatie idd niet aan de wensen voldoet, denk maar niet dat die developers dan maar ineens geen games meer gaan maken, of zich alleen richten op linux of mac, ze willen wel geld blijven verdienen. Die stappen dus vrolijk over.

Dat kan, daar heb ik geen zicht op, maar het lijkt me niet dat deze aanpak dan nou De Toekomst heeft. Bij PC games zie je tegenwoordig ook de focus verschuiven van bijvoorbeeld gpu assembly naar HLSL/GLSL, dus ik neem toch aan dat console developers hier ook naar verkast zijn, maar daar moet .oisyn z'n licht maar eens overlaten schijnen.

Je vergelijking klopt niet. De keuze wel of niet via een API werken heeft hele andere gevolgen dan de keuze wel of geen HLSL gebruiken. Een HLSL is in feite gewoon een C variant voor shaders, en met goede compilers zul je gewoon goede code krijgen. Door een high-level API te gebruiken wordt je echter wel een stuk meer gelimiteerd in je kunnen, het mist de mogelijkheid om bepaalde delen te finetunen aan je eigen wensen. Je vergelijking zou opgaan als je zegt dat er geen custom shaders meer geschreven worden maar er gebruik zou worden gemaakt van een toolkit waarmee je je shaders samen kunt stellen, preferably door de artists.

Dat is een kant die weldegelijk opgegaan wordt (bij ons ook), maar meer omdat shaders typisch iets zijn waar artists zich mee bezig willen houden, maar wat zonder toolkit niet kan omdat ze zich dan ook moeten verdiepen in allerlei triviale zaken waar ze geen verstand van hebben. Maar je zit er niet aan vast, als je een shader wilt maken dat met je toolkit niet te bereiken is kun je altijd terugvallen op handcrafted shaders, en dat lukt met een API niet helemaal, dat is vaak their way of the highway. Overigens wil ik niet zeggen dat er op een xbox(360) geen letter d3d gecode wordt, er zijn zat functies die je gewoon kunt gebruiken omdat ze exact doen wat je wilt, maar de d3d API op een xbox(360) is tevens zo gestript dat dat prima mogelijk is. Carmack heeft op de Quakcon van een jaar terug niet voor niets verklaard dat de X360 z'n favoriete platform van het moment is: je kunt dicht op de hardware programmeren, maar zonder dat dat veel hoofdpijn bezorgt.

Van wat ik gehoord heb ondersteunt de XBox360 gewoon de DX9 API

Nou nee hoor. Er zal vast een reguliere dx9 implementatie te gebruiken zijn die identiek is aan die op de PC om cross-platform-development mogelijk te maken (zit waarschijnlijk in dat XNA systeem), maar de officiele d3d api op de xbox360 is niet hetzelfde als d3d9.

en krijgen we binnenkort (over een jaartje hopelijk) zelfs de mogelijkheid om het .NET platform op de 360 te gebruiken, dus het wordt alleen maar meer high-level. Als MS er brood in ziet om verder high-level te gaan, dan kan ik me niet voorstellen dat game developers hier geen gebruik van maken.

Toch blijft het marketing mumbo jumbo, iets waar gamedevelopers niet zo heel erg gevoelig voor zijn

Anoniem: 3142 schreef op vrijdag 31 maart 2006 @ 14:20:
De abstractie blijft van ongeveer hetzelfde niveau als D3D9

En die aanname klopt dus gewoon niet

Anoniem: 3142 schreef op vrijdag 31 maart 2006 @ 14:20:
Met de (vanaf D3D10 geschrapte) fixed function pipeline, zeg maar de oude API, heb je gelijk. Maar vanaf DX9 zit je met HLSL al rechtstreeks op "the metal", dus daar zijn maar marginale verbeteringen te behalen door extreem lowlevel te gaan. Naast dit renderen, wat over het algemeen toch de grootste resource hog is, komt het eigenlijk gewoon neer op structuur aanbrengen en met wat andere devices communiceren (audio, input etc) en daar is met low-level werk AFAIK al helemaal weinig eer te behalen.

Ik denk dat je een wat verkeerd idee hebt van low-level programming (waarschijnlijk omdat je in C# programmeert). Het heeft geen zak te maken met het schrijven van shaders in assembly, maar met de aansturing van de hardware. In d3d roep je een functie aan om een texture te creëren, die jouw een texture object teruggeeft waar je, weer met een functie, data naartoe kunt sturen.
Als je het over een console hebt dan geef je gewoon letterlijk een pointer naar je texture data in memory en vertel je hoe ie die data moet interpreteren. In plaats van een draw call vul je een command buffer met commando's die de videokaart uit moet voeren, en die stuur je naar de videokaart. Dat is iets wat een API afschermt, maar daardoor ook concessies maakt voor de mogelijkheden die je hebt. Met een API kun je niet uit een stencil buffer lezen (pre d3d10 that is), zonder API map je dat stukje stencilbuffergeheugen gewoon als texture.

[ Voor 21% gewijzigd door .oisyn op 31-03-2006 15:37 ]

[Anoniem: 3142]

Oh? Het zijn er nog maar erg weinig, en de verwachting is dat met de komst van d3d het er nog minder worden. En als de opengl implementatie idd niet aan de wensen voldoet, denk maar niet dat die developers dan maar ineens geen games meer gaan maken

Die illusie had ik zowiezo al niet, maar ik dacht dat MS mischien toch nog OpenGL wilde blijven ondersteunen. Voor mij maakt het niks uit, want ik ben momenteel toch bezig met MDX, maar dat leek me een plausibele verklaring voor de vertraging van de OpenGL ondersteuning en de voorspelde toestanden met Vista.

Je vergelijking klopt niet ... Een HLSL is in feite gewoon een C variant voor shaders, en met goede compilers zul je gewoon goede code krijgen. Door een high-level API te gebruiken wordt je echter wel een stuk meer gelimiteerd in je kunnen, het mist de mogelijkheid om bepaalde delen te finetunen aan je eigen wensen.

Ok, maar als je het Effects framework er dan weer bij haalt, waar ik eigenlijk op doelde, dan lijkt m'n vergelijking toch weer wat kloppender, vooral met die verschrikkelijke TEXCOORD semantics voor van alles en nog wat Maar goed, daar kunnen we het lang en breed over hebben, waar het zich mij eigenlijk om ging is dat developers toch van deze API's gebruik kunnen maken en hoe de toekomst ervan eruit ziet. In D3D heb ik meer vertrouwen gekregen en in OpenGL juist minder en dat is waar de TS ook om vroeg.

In ieder geval bedankt voor je inzichten

Toch blijft het marketing mumbo jumbo, iets waar gamedevelopers niet zo heel erg gevoelig voor zijn

Maar wel goed in zijn Ik heb in ieder geval wel vertrouwen in MDX, dus we zien wel waar het schip strand.

En die aanname klopt dus gewoon niet

Weet ik, lees eens verder door naar beneden

Ik denk dat je een wat verkeerd idee hebt van low-level programming (waarschijnlijk omdat je in C# programmeert). Het heeft geen zak te maken met het schrijven van shaders in assembly, maar met de aansturing van de hardware. In d3d roep je een functie aan om een texture te creëren, die jouw een texture object teruggeeft waar je, weer met een functie, data naartoe kunt sturen.

En hier heb je volkomen gelijk. In MDX kom je zelfs in C# al wat dichter bij dit soort constructies (in unsafe contexten), maar ik keek idd niet door de API heen. Ik wist wel wat ie deed, maar ik had er nooit bij stilgestaan dat je zoiets 'handmatig' zou kunnen of willen doen... Dat willen weet ik nog steeds niet zeker, maar bedankt voor de eye-opener.

[Bloody NO!]

.oisyn schreef op donderdag 30 maart 2006 @ 21:39:
[...]
Euh, wat moet er nog aan 2d bijkomen dan? Heb je een beetje een idee hoe je een videokaart aanstuurt met een API als ogl of d3d? Als dat zo was dan zou je je moeten realiseren dat dat prima mogelijk is met de huidige hardware, want het enige dat een videokaart kan is polygonen plotten en vectorberekeningen uitvoeren. En je scherm blijft 2D, of je er nou een 3D wereld op projecteert of niet . Dus zoveel '3d' dingen worden er niet echt ontwikkeld door de hardware vendors, wel betere technieken om vector graphics te renderen, maar dat is toch waar het uiteindelijk om gaat?

Dus waarom dat nou voor opengl spreekt snap ik niet helemaal...

Ik heb het over de Linux-implentatie van X11 - voor zover ik weet maakt dat gebruik van het 2D-gedeelte van de kaart: Gewoon bitmaps weergeven die X11 naar de driver stuurt, om maar even kort door de bocht te gaan. Dit is op het moment voor Linux niet bepaald efficient, (te?) veel werk wordt nog door de CPU gedaan. Door gebruik te maken van OpenGL kan de GPU taken van de CPU overnemen.In mijn ogen gebruik je een "3D-API" voor iets wat in wezen altijd al 2D voor moest stellen, namelijk voor de desktop.(In tegenstelling tot bijvoorbeeld "3D"-shooters of CAD-applicaties.)

Om te antwoorden in hoeverre dit voor OpenGL spreekt: OpenGL heeft op dit moment drivers die de hardware nuttig aan kunnen spreken, dit in tegenstelling tot de voorganger (X11).

dawuss schreef op vrijdag 31 maart 2006 @ 00:06:
[...]

Volgens mij heb ik dat wel degelijk gemeld, tegelijkertijd met het onder de aandacht brengen van Mac OS X, waarbij vrijwel alles onder OpenGL gebeurt.

Sorry, dan heb ik dat over het hoofd gezien.

edit:
Maar Quartz-3D / 2D rendering staan op Mac OS X Tiger tegenwoordig toch standaard uit?

[ Voor 4% gewijzigd door Bloody NO! op 01-04-2006 01:00 ]

[flowerp]

Er is overigens nog een techniek waar OpenGL een grote rol speelt en dat is Java 3D (zie ook http://www.opengl.org/resources/java/ ). Nu is Java tegenwoordig voornamelijk een server side techniek en speelt het voor desktop applicaties bijna geen enkele rol, laat staan voor echte games.

Toch wordt Java wel degelijk veel voor games gebruikt, maar dan op beperkte platformen zoals mobiele telefoons. Aangezien er daar ook langzaam de stap naar 3D gemaakt wordt, zal OpenGL op deze ***MEGA*** markt zeer zeker een rol blijven spelen. Ook op de PC zijn er een paar Java 3D games die er toch best wel gelikt uitzien. Voorlopig zal geen enkele profesionele games studio zich aan Java 3D games wagen voor op de PC, maar voor op de mobiel is het zeker wel een interesante markt. We hebben het dan natuurlijk wel over absolute low-end 3D.

[.oisyn]

Java3D werkt net zo goed met d3d, dus ik snap je punt eigenlijk niet... Het is een wat higher level API dan ogl en d3d zijn, ik zou het knap stom vinden als het op een mobiele telefoon op ogl gebaseerd is omdat dat alleen maar extra overhead met zich meebrengt op een platform waar je dat juist niet wil. Het zal dus eerder wat directer op de hardware geïmplementeerd zijn.

[ Voor 69% gewijzigd door .oisyn op 03-04-2006 11:02 ]

[Anoniem: 42145]

.oisyn schreef op maandag 03 april 2006 @ 11:00:
Java3D werkt net zo goed met d3d, dus ik snap je punt eigenlijk niet...

Net zo goed? Ik snap niet echt wat je daar mee bedoeld???

Hoe kan het nou net zo goed werken als OpenGL? Een cornerstone van de hele Java scene is dat je software schrijft die overal kan draaien. OpenGL is in principe bijna op elk desktop platform aanwezig. D3D is dat niet. Zelfs al ZOU het beter werken op D3D, en is de Java 3D binding naar OpenGL, D3D of directe hardware volledig transparant, dan nog is OpenGL voor Java heel erg belangrijk. Sun en de hele java community blijven toch hechten aan het principe dat een Java app overal kan draaien, en met D3D gaat dat niet lukken.

Vergeet ook niet dat Linux + Mac OS X samen nu al zo'n 7% van de desktop markt hebben. Beiden zijn ook groeiend. Over een jaar of 5 zouden ze samen best boven de 10% kunnen zitten. 10% klinkt mischien weinig, maar is toch zeer zeker wel significant (ik heb wel platformen moeten ondersteunen met minder marktaandeel).

Of bedoelde je met "Java3D werkt net zo goed met d3d, dus ik snap je punt eigenlijk niet.." dat je D3D via Wine ook op Linux en Mac OS X kunt draaien en daar dan weer Java bovenop? Daar heb je mischien een punt mee. Wine wordt elke maand beter, en via die weg -zou- OpenGL mischien technisch gezien overbodig kunnen worden. Toch lijkt me het stug dat Sun expliciet op zo iets gaat bouwen voor de hele Java desktop lijn op alle platformen.

[Gerco]

Wat hij bedoelt is dat je ook een Java3D implementatie hebt die D3D gebruikt als back-end op Windows. Op die manier is OpenGL niet nodig om Java3D op Windows te draaien, alleen voor andere os-en.

[.oisyn]

Anoniem: 42145 schreef op maandag 03 april 2006 @ 20:48:
[...]


Net zo goed? Ik snap niet echt wat je daar mee bedoeld???

Zie Gerco. Flowerp kwam met het argument dat opengl heel erg belangrijk is voor Java3D. Dat is niet zo, Java3D is maar een schil om een andere API, en bij de windows installatie kun (kon iig) je altijd kiezen of je OpenGL of Direct3D als onderliggende aansturing wilde gebruiken.

Hoe kan het nou net zo goed werken als OpenGL?

Nou, de d3d en ogl API's verschillen momenteel niet zo heel veel van elkaar qua opzet.

Sun en de hele java community blijven toch hechten aan het principe dat een Java app overal kan draaien, en met D3D gaat dat niet lukken.

Je zult hoe dan ook platformspecifieke zut moeten implementeren om het samen te laten werken met je GUI (en hoe standaard OpenGL ook is, dat is op elk platform weer anders. Dingen als glut en SDL gaan natuurlijk ook maar tot een bepaalde grens). Daarnaast heeft Sun Java3D nogal laten vallen als ik zo naar de documentatie kijk, het is momenteel voornamelijk nog een community-project. Op de mobiele platforms doet de API er niet toe, en op de desktop is Java3D weer totaal niet interessant voor de ontwikkeling van OpenGL zelf.

Bovendien heb ik nergens in de draad beweerd dat het slecht gaat met OpenGL, ik heb zelfs beweerd dat ik zeker weet dat het wel blijft bestaan. Dus wat je met de rest van je relaas nou probeert te zeggen snap ik niet helemaal...

[Anoniem: 42145]

Gerco schreef op maandag 03 april 2006 @ 20:54:
Wat hij bedoelt is dat je ook een Java3D implementatie hebt die D3D gebruikt als back-end op Windows. Op die manier is OpenGL niet nodig om Java3D op Windows te draaien, alleen voor andere os-en.

We bedoelen denk ik wel hetzelfde, maar dat laatste is nu precies mijn punt.

Natuurlijk is D3D beter, mooier, heeft het meer toekomst en wordt het grofweg 10x zo veel gebruikt. Volgens dezelfde redenering kun je dan ook zeggen dan Linux en Mac OS X niet echt nodig zijn, je hebt immers Windows al, en Java kan prima Windows als OS gebruiken.

[.oisyn]

Wie "redeneert" (ik zie niet echt een redenering) er dan in hemelsnaam dat OpenGL niet nodig is

[ Voor 3% gewijzigd door .oisyn op 03-04-2006 23:01 ]

[Anoniem: 42145]

.oisyn schreef op maandag 03 april 2006 @ 23:01:
Wie "redeneert" (ik zie niet echt een redenering) er dan in hemelsnaam dat OpenGL niet nodig is

"Niet nodig"... tsja... laten we zeggen "minder belangrijk". Samen met de eerdere uitspraken kun je dan toch wel een beetje tussen de regels lezen dat OpenGL toch wel een beetje een 2de rangs API is. Dat is niet 'erg'. Op z'n minst is het een mening, en wellicht dat het wel waar is ook.

Zie bv:

.oisyn
Daarna ben je imho gewoon idioot als je voor games voor opengl kiest en je niet heel erg van plan bent voor linux en/of Mac te ontwikkelen.

flowerp
Er is overigens nog een techniek waar OpenGL een grote rol speelt en dat is Java 3D

.oisyn
Java3D werkt net zo goed met d3d, dus ik snap je punt eigenlijk niet...

Voor games ben je idioot als je met OpenGL aan de gang gaat en in Java werkt D3D net zo goed. Mischien is OpenGL daarmee nog niet "overbodig" maar het klinkt ook niet erg als "nodig". Niet nodig zit kwa gevoel toch wel dicht tegen overbodig aan.

Mijn punt is niet zo heel erg diep dat het zoveel tegensputteren waard is lijkt me Ik stel slechts dat OpenGL belangrijk is, omdat er tenminste 2 redelijk mainstream operating systemen zijn en 1 'platform' die natuurlijk ook toegang willen tot 3D technieken, maar die of helemaal geen D3D kunnen gebruiken (Linux en OS X dus) of waarbij het niet wenselijk is om als enigste basis dependency te hebben (Java).

Natuurlijk is het mooi dat Java op Windows D3D kan gebruiken, en daar is het waarschijnlijk ook verreweg de beste optie maar het feit dat Java geen Windows only techniek is en dus ook op Linux, Mac OS X en nog wat andere systemen moet draaien, alleen dat feit maakt dat OpenGL toch wel belangrijk is voor Java. De dag dat men verklaard dat Java alleen op Windows hoeft te draaien zal de dag zijn dat OpenGL ook voor Java niet meer belangrijk is.

[.oisyn]

Anoniem: 42145 schreef op maandag 03 april 2006 @ 23:36:
"Niet nodig"... tsja... laten we zeggen "minder belangrijk". Samen met de eerdere uitspraken kun je dan toch wel een beetje tussen de regels lezen dat OpenGL toch wel een beetje een 2de rangs API is.

Tja, nu heb je het eigenlijk alleen over het gamedevelopment gedeelte. Gamedevelopers willen gewoon elk beetje uit de hardware trekken, dat lukt gewoon niet als er een generieke HAL overheen ligt. Voor de PC zijn er eigenlijk maar 2 grote spelers, nVidia en ATi. Voor beide is de gamesniche ontzettend belangrijk voor hun totale omzet, en dus luisteren ze daarbij naar de developers. Microsoft natuurlijk net zo goed en wil die HAL op een betere manier organiseren, waarbij er minder overhead is en de API een betere throughput heeft (en serieus, je wilt niet weten hoeveel meer je uit een xbox kunt halen dan bij identieke hardware maar dan in een PC+ogl/d3d jasje). Een lichtere HAL vereist meer identieke hardware, iets wat MS voor hun D3D API voor elkaar kan krijgen. OpenGL heeft echter een veel uiteenlopendere userbase en kan zo'n verandering nooit zomaar doorvoeren. Dáárom ben je als gamedeveloper idioot als je na de inburgering van D3D10 nog OpenGL gaat gebruiken. Niet omdat die API nou zo mediocre is ofzo, met OpenGL 2.0 hebben ze een goede verbetering ondergaan.

en in Java werkt D3D net zo goed

Je snapt volgens mij nog steeds niet wat ik daarmee bedoel, want ik bedoel namelijk dat die java3d ontwikkelaars net zo goed aan een D3D implementatie werken. Waarom spreekt het Java3D argument dan vóór OpenGL? (Maar net zo goed ook niet tegen natuurlijk). Is dat niet gewoon een subset van het argument dat OpenGL op linux altijd nog actief blijft, wat natuurlijk al ter sprake is gekomen?

[Zoijar]

Anoniem: 42145 schreef op maandag 03 april 2006 @ 23:36:
Samen met de eerdere uitspraken kun je dan toch wel een beetje tussen de regels lezen dat OpenGL toch wel een beetje een 2de rangs API is. Dat is niet 'erg'. Op z'n minst is het een mening, en wellicht dat het wel waar is ook.

Mwa, niet tussen mijn regels hoor. Om mijn mening even bot te stellen (nofi): D3D is leuk om wat windows spellen te maken, maar alle serieuse apps gebruiken OpenGL. Ik snap ook nog steeds niet waarom die mening hier blijft hangen dat opengl tweederangs zou zijn. Met D3D-10 vergelijken is flauw, want dan moet je ook (het hypothetische) opengl 3.0 nemen.

[.oisyn]

Ik snap ook nog steeds niet waarom die mening hier blijft hangen dat opengl tweederangs zou zijn

Ik zie die mening ook nergens eerlijk gezegd. Ik deel 'm iig niet

[killingdjef]

"Wat consoles betreft is het totaal geen issue, hoewel je een Direct3D variant voor de xbox en xbox360 kunt gebruiken wordt dat in de praktijk maar erg weinig gedaan."

Dat is heel ver van de waarheid. Xbox(360) developers maken gewoon gebruik van Direct3D.
Deze Direct3D versie is welliswaar niet hetzelfde als de PC versie (zit dichter tegen de hardware aan), maar de veranderingen zijn voor het
leeuwendeel "under the hood"; de API zelf is vrijwel onveranderd, op toevoegingen/verwijderingen hier en daar na.
Daar komt bij dat Direct3D het enige is dat door Microsoft op de Xbox(360) volledig ondersteunt word.

[ Voor 3% gewijzigd door killingdjef op 04-04-2006 01:50 ]

[.oisyn]

killingdjef schreef op dinsdag 04 april 2006 @ 01:49:

Dat is heel ver van de waarheid. Xbox(360) developers maken gewoon gebruik van Direct3D.

Ah ja, en dat verklaart natuurlijk waarom wij onze eigen pushbuffers zitten te vullen in oa Tomb Raider: Legend . Natuurlijk wordt D3D voor een deel gebruikt, het is prima voor initalisatie en wat standaard functionaliteit. Maar op de performance-kritieke punten wil je net even wat verder dan de API je biedt.

Daarnaast heb ik ook ooit eens iemand gehoord over een eigen OpenGL implementatie op de xbox.

[ Voor 9% gewijzigd door .oisyn op 04-04-2006 02:21 ]

[Anoniem: 3142]

Maar op de performance-kritieke punten wil je net even wat verder dan de API je biedt.

Hoe doe je dit dan voor de PC port van Tombraider Legend? Lijkt me toch het meest handige dat het grootste deel van de ontwikkeling voor de XBox/Xbox360/PC in D3D wordt gedaan, met platform specifieke optimalisaties waar mogelijk.

Daarnaast heb ik ook ooit eens iemand gehoord over een eigen OpenGL implementatie op de xbox.

Iets zegt me dat je hiervoor niet op support van MS hoeft te rekenen

[.oisyn]

Anoniem: 3142 schreef op dinsdag 04 april 2006 @ 07:20:
Hoe doe je dit dan voor de PC port van Tombraider Legend? Lijkt me toch het meest handige dat het grootste deel van de ontwikkeling voor de XBox/Xbox360/PC in D3D wordt gedaan, met platform specifieke optimalisaties waar mogelijk.

Nee hoor, zo handig is dat niet. Een console staat kwa ontwikkeling natuurlijk stil, terwijl er op de PC continu nieuwe hardware en features uitkomen. We hebben een abstracte renderer waartegen je (kort door de bocht) gewoon zegt Render(model, matrices, lights) en die de rest van de resources (textures, materials, etc.) managed. Deze renderer is op elk platform apart geïmplementeerd, de xbox implementatie lijkt op de verste verte niet op de (prev-gen) PC implementatie. En zoals killingdjef al zei zijn de d3d's van de PC en de xbox verschillend, dus het is sowieso niet een kwestie van even hercompileren.

[flowerp]

.oisyn schreef op dinsdag 04 april 2006 @ 17:46:
Ik denk dat ze de xbox360 daarmee meer wat toegankelijker willen maken voor nieuwe developers,

Is het ook niet zo dat de complexiteit van de nieuwe systemen enorm aan het toenemen is. Een veel gehoorde klacht is dat machines het slechter doen omdat de hardware te moeilijk is om voor te programmeren. 1 van de eerste bekende voorbeelden was Sega's saturn, die uit zeer veel co-processors was opgebouwd die nauw moesten samenwerken.

Als je dit combineerd met het feit dat de doorloop tijd van consoles alleen maar korter lijkt te (gaan) worden en je komt uit op het feit dat developpers toch wel wat meer higher level lijken te willen werken.

Wellicht dat het te vergelijken is met de ontwikkelingen in andere gebieden van de software development. Wat langer geleden werden nog complete operating systemen en bedrijfs software in assembly geschreven. De performance winsten waren het gewoon waard. Vandaag de dag gebeurd dat niet meer. De eventuele performance voordelen wegen niet meer op tegen de nadelen kwa productivity en onderhoud. Tevens zijn moderne CPUs te complex geworden om nog fatsoenlijk handmatig voor te optimaliseren, vooral de optimale combinatie van instructies in het licht van superscalaire architecturen en pipelining is bijna niet meer bij te houden voor een mens (zeker niet voor grote lappen code). De hele CPU ABI is nu bijna geheel gericht op compilers en niet meer op de mens (hele oude CPUs zoals die VAX dingen hadden 'instructies' die redelijk high-level waren zoals complete string copies).

Deze hele ontwikkeling staat eigenlijk lijnrecht tegenover wat .oisyn beweerd dat game developpers juist WEL heel dicht / direct op de hardware willen blijven werken. Dat dat nu zo is zal ik niet willen ontkennen, maar hoe lang zal dat nog zo zijn?

[Anoniem: 172707]

Is er eigenlijk zoveel verschil tussen de kwaliteit van open GL en directx (om bijvoorbeeld games te maken)?

Ga ff ergens anders spammen aub.

[ Voor 29% gewijzigd door whoami op 05-04-2006 14:37 ]

[.oisyn]

XNA zut afgesplitst naar [rml][ Disc] is MS' XNA voor gamedevelopers echt nuttig?[/rml]

[Anoniem: 42145]

flowerp schreef op woensdag 05 april 2006 @ 00:28:
Is het ook niet zo dat de complexiteit van de nieuwe systemen enorm aan het toenemen is. Een veel gehoorde klacht is dat machines het slechter doen omdat de hardware te moeilijk is om voor te programmeren. 1 van de eerste bekende voorbeelden was Sega's saturn, die uit zeer veel co-processors was opgebouwd die nauw moesten samenwerken.

Wat is bekend? Oudere Arcade boards hadden dikwijls nog veel meer processors onboard en special effects chips voor van alles en nog wat, en daar was ook geen enkele software API voor beschikbaar.

[.oisyn]

Je wil de controle waar dat zinvol is. Op de playstation moest je geloof ik zelf de cddrive aansturen en zorgen dat de dma controller de data naar de juiste geheugenplek stuurt, dat is natuurlijk niet iets waar je als programmeur op zit te wachten, zeker niet omdat dat allemaal nogal complex werkt. Wat je echter wel weer wilt kunnen is zorgen dat de drive op spin is en dat je de laser alvast naar de goede locatie kunt sturen zodat streaming content sneller te laden is, maar dat lukt je weer niet met een API dat simpelweg het filesystem exposed. Het is een kwestie van de juiste balans vinden (en Carmack zei dat de x360 deze juiste balans had en dat ie het daarom een fijn platform vond om op te ontwikkelen).