DirectX/OpenGL

[Cyphax]

roy-t schreef op woensdag 07 mei 2008 @ 22:48:
Verder snap ik het puntje van de Topic Starter niet dat OpenGL games mooier zijn? eerlijk waar kan ik me niet indenken waarom dat (technisch gezien) zo zou zijn.

Het is ook onzinnig om te stellen dat OpenGL-games mooier zijn. Mooie games maak je imo door de tools die je hebt goed te gebruiken. OpenGL en DirectX (de vergelijking die nieteens klopt) bieden alle mogelijkheden om grafische pracht op je scherm te toveren.

Microsoft heeft denk ik gewoon een goed product met DirectX. Het handelt itt OpenGL niet alleen beeld, maar ook geluid en input af en dat alles in een pakket, met de ontwikkeltools die allemaal op elkaar afgestemd zijn. Dat is gewoon een vreselijk krachtig verkoopargument, en wees eerlijk; dat doet Microsoft gewoon goed.

Nu ben ik Linuxgebruiker, dus je begrijpt dat ik het jammer vind dat niet wat meer games OpenGL gebruiken. Ik ben aangewezen op Wine, en aangezien ik geen diehard gamer ben kom ik daar wel overheen. Toch is het jammer.

Verder is OpenGL of D3D een bewuste keuze. Iemand die D3D kan programmeren is in een paar weekjes om te scholen naar OpenGL (kijk maar naar HLSL en GLSL het lijkt allemaal erg op elkaar)

Ik heb niet zo heel gek veel ervaring met OpenGL maar ik heb er weleens mee gewerkt. Volgens mij steekt dat ontzettend anders in elkaar qua programmeren dan DirectX (waar ik niets mee gedaan heb). Wat wel hetzelfde zou moeten blijven (maar ik weet niet of dat zo is) is het hele belangrijke facet van de wiskunde achter je game.

Als ik nu grafisch te werk zou gaan zou ik kiezen voor OpenGL, simpelweg omdat ik geen zin heb om Windows te installeren om wat te programmeren.

[roy-t]

Cyphax schreef op woensdag 07 mei 2008 @ 22:57:
[...]

Ik heb niet zo heel gek veel ervaring met OpenGL maar ik heb er weleens mee gewerkt. Volgens mij steekt dat ontzettend anders in elkaar qua programmeren dan DirectX (waar ik niets mee gedaan heb). Wat wel hetzelfde zou moeten blijven (maar ik weet niet of dat zo is) is het hele belangrijke facet van de wiskunde achter je game.

Zelf 'werk' ik meestal afgeschermd van het daadwerlijke API, dmv XNA en ik heb ook even gespeeld met een variant daarvan voor OpenGL maar daar ben ik de naam van kwijt

En verder heb ik dat statement gebruikt omdat ik vaak GLSL en HLSL code door elkaar heen vind, en dat lijkt erg op elkaar, ben er echter net achter gekomen dat OpenGL eigenlijk geen standaard High Level Shader Language heeft, en dat GLSL slechts een van de implementaties is. Dus ja dat argument gaat nu ook minder op.

Op die manier lijkt het dan best op elkaar maar het zou zeker kunnen dat als je direct tegen de API aan programmeert het heel anders is.

[beany]

Cyphax schreef op woensdag 07 mei 2008 @ 22:57:
Ik heb niet zo heel gek veel ervaring met OpenGL maar ik heb er weleens mee gewerkt. Volgens mij steekt dat ontzettend anders in elkaar qua programmeren dan DirectX (waar ik niets mee gedaan heb).

D3D en OGL zijn niet zo heel verschillend. Op het 1e gezicht wel, maar als je erin duikt zal je zien dat het concept van beide aardig overeenkomen.

Wat wel hetzelfde zou moeten blijven (maar ik weet niet of dat zo is) is het hele belangrijke facet van de wiskunde achter je game.

En dat klopt.

D3D en OGL zijn (met inmiddels wel wat ondersteunings-libraries voor de ontwikkelaar) eigenlijk niks meer dan een generieke manier om een videokaart aan te spreken. Of eigenlijk: om een driver van een video kaart aan te spreken, zonder dat de programmeur kennis nodig heeft van elke driver. Daarom verschillen OGL en D3D ook niet zo gek veel van elkaar, ze doen het zelfde namelijk(min of meer).

[Cyphax]

roy-t schreef op woensdag 07 mei 2008 @ 23:03:
Op die manier lijkt het dan best op elkaar maar het zou zeker kunnen dat als je direct tegen de API aan programmeert het heel anders is.

Dat verklaart dat dan ook.
* Cyphax heeft alleen wat tegen OpenGL direct aangeprogt

beany schreef op woensdag 07 mei 2008 @ 23:04:
D3D en OGL zijn (met inmiddels wel wat ondersteunings-libraries voor de ontwikkelaar) eigenlijk niks meer dan een generieke manier om een videokaart aan te spreken. Of eigenlijk: om een driver van een video kaart aan te spreken, zonder dat de programmeur kennis nodig heeft van elke driver. Daarom verschillen OGL en D3D ook niet zo gek veel van elkaar, ze doen het zelfde namelijk(min of meer).

I know, ik had het alleen over de manier van programmeren. Maar het is van mijn kant meer van horen zeggen hoor, ik heb nooit DirectX voor iets anders gebruikt dan een spelletje spelen.

[ Voor 50% gewijzigd door Cyphax op 07-05-2008 23:06 ]

[Avalaxy]

roy-t schreef op woensdag 07 mei 2008 @ 22:48:
[...]

De laatste game die ik me kan herinneren die OpenGL had was Doom3 (of UT2004), maar als OpenGL 2.0 er niet snel komt vrees ik dat het aanbod nog minder gaat worden, ontwikkelaars wordt het moeilijk gemaakt om grafische krachtpatser neer te zetten doordat ze veel functionaliteit missen of moeten rekenen op extensies die er niet altijd zijn.

Quake 4, Prey

beany schreef op woensdag 07 mei 2008 @ 13:16:

Linux is opensource, Windows is dat niet. Volgens jouw redenering zou Linux dus de absolute marktleider op het gebeid van besturingsystemen moeten zijn omdat het zo geweldig is(volgens jou).

Dat is een beetje woorden verdraaien, want dat is niet wat hij zei. Daarnaast zie ik de link tussen populariteit en het maken van opensource of closed source software niet helemaal. Microsoft heeft een ongelooflijk marketingbudget, de ontwikkelaar van verschillende Linux (of andere UNIX varianten) distro's hebben dat niet, omdat ze het meer als hobby doen.

Daarnaast heeft closed source software in de vorm van Windows het grote voordeel dat je een professionele helpdesk hebt, en dat je niet bent aangewezen op documentatie die met open source software mee komt.

Dus of Linux is prut ondanks dat het opensource is of misschien kan een closed source besturingsysteem ook best wel erg goed zijn

Ik zie de link niet helemaal. Daarnaast is dat ook niet wat MarCreative zei, want hij zei dat open source software een voordeel kan hebben, niet dat het per definitie beter is.

Wat betreft het DirectX versus OpenGL verhaal, de developers kiezen natuurlijk waar ze aan gewend zijn en wat toereikend is. Natuurlijk is het ook zo dat Microsoft nauw samenwerkt met hardwarefabrikanten om te bepalen welke features er in nieuwe updates van DirectX komen, en dat het een uitgebreid pakket is van zowel API's (waaronder natuurlijk DirectSound3D en Direct3D) als ontwikkeltools.

[Gomez12]

Ach, ik denk dat er maar 1 argument echt opgaat en dat is dat directx ook geluid meeneemt. Als jij een windows game gaat maken met geluid dan gebruik je 9 vd 10 keer directsound volgens mij. Dan kun je wel leuk een compleet andere taal gebruiken voor je gfx, maar als dit geen belangrijke voordelen biedt houdt je het gewoon binnen hetzelfde pakket ( directx ).

Plus dat opengl een paar jaar terug bijna op zijn gat lag, hierdoor is de hardware ondersteuning flink teruggelopen en ging de hardware zich richten op directx. En nu heb je dat opengl en direct3d technisch hetzelfde kunnen ( of ongeveer ) maar praktisch verschilt de hardware ondersteuning van opengl heel erg per merk, waardoor je niet alles kan gebruiken/kunstgrepen moet toepassen als je niet 40% van je potentiele windows klanten wilt verliezen...

[.oisyn]

[quote]MarCreative schreef op woensdag 07 mei 2008 @ 12:47:
Mede tweakers,

Ik loop al enige tijd met de vraag: Waarom worden bijna alle spellen in DX10 geschreven en niet in OpenGL? Als ik het bekijk (zoals nu) is OpenGL gewoon een veel slimmere keuze, namelijk:

• Cross-platform

Cross platform? Op de PC ja. Lekker boeiend. Als je het over cross-platform games hebt, dan gaat dat in 99.999% van de gevallen niet over games die naast Windows ook op Linux en OS X draaien, maar om games die ook op de consoles van MS, Sony en Nintendo draaien. En die doen geen van allen OpenGL. Daar sta je dan met je zogenaamde cross platform API . Daarnaast is het koppelen van de backend van je renderer met een API wel met minste werk van het porten van een game, zeker gezien de gelijkenis van de APIs (logisch, want ze spreken dezelfde hardware aan). En op een console wil je sowieso platform-specifieke optimalisaties maken, waarbij je vaak ook nog eens direct de hardware aanspreekt en de API alleen nog gebruikt voor wat handige functionaliteit.

[q]• Open-Source
Er is niets open source aan OpenGL. Open != open source.

[q]• Ziet er mooier uit -> Mening, maar opzich wel een feit.
Een feit Klinklare onzin . Het is een API om hardware aan te sturen. Direct3D is een vergelijkbare API dat exact dezelfde hardware aanstuurt. De hardware zorgt voor het plaatje.

[q]• Snelhied <- Kan ik niet onderbouwen, is denk ik gevoel.
Op Windows klopte dat enigszins. Op XP en voorgaande Windowsen is de weg van API naar GPU onder OpenGL wat korter dan onder Direct3D. Hardware fabrikanten komen meestal met een driver die direct OpenGL ondersteunt (e.g., je vervangt de opengl dll). Als je een Direct3D implementatie wilt maken dan maak je effectief een back-end voor D3D. Er zit dus een extra abstractielaag in. Onder Vista gaat dat verhaaltje echter niet meer op.

Dus waarom niet OpenGL?

Omdat OpenGL achter de feiten aanloopt en extensions een hel zijn om tegenaan te programmeren. Het voordeel dat je direct nieuwe features van hardwarefabrikanten kunt gebruiken is direct ook het nadeel - vergelijkbare features gebruiken voor verschillende vendors ook verschillende extensions die allemaal net iets anders werken, totdat er een log apparaat als de ARB eroverheen is gegaan om het te standaardiseren.

Er is 1 heel groot voordeel om voor Windows Direct3D te verkiezen boven OpenGL, en dat is support, documentatie en development tools. Heeft OpenGL een shader debugger? Heeft OpenGL een analyser zoals PIX? Hell, heeft OpenGL eigenlijk sowieso een standaard shader taal en compiler? Nee, nee en nee. Het is volledig afhankelijk van de community die dat soort tools aanleveren.

[ Voor 7% gewijzigd door .oisyn op 08-05-2008 00:33 ]

[Comp_Lex]

Gomez12 schreef op woensdag 07 mei 2008 @ 23:12:
Ach, ik denk dat er maar 1 argument echt opgaat en dat is dat directx ook geluid meeneemt.

Klik

[.oisyn]

De rest van DirectX doet er niet toe, je kunt prima gebruik maken van DirectX zonder Direct3D te gebruiken. Het is geen complete package. Je kunt voor elke module (Direct3D, -Input, -Sound, -Show, etc.) individueel kiezen of je 'm meelinkt of niet. Het is niet alles of niets. Direct3D gebruiken omdat je ook graag DirectInput gebruikt is dus een non-argument.

[ Voor 13% gewijzigd door .oisyn op 08-05-2008 00:28 ]

[Sebazzz]

En voor de input SDL.

[Elledan]

FYI, we zitten nu al op OpenGL 2.1: Wikipedia: OpenGL

OpenGL 3.0 komt er dit jaar ook aan.

[roy-t]

Elledan schreef op vrijdag 09 mei 2008 @ 20:47:
FYI, we zitten nu al op OpenGL 2.1: Wikipedia: OpenGL

OpenGL 3.0 komt er dit jaar ook aan.

Hmm ik loop achter

[.oisyn]

OpenGL ook, dus dat scheelt

[Ilmar]

.oisyn schreef op donderdag 08 mei 2008 @ 00:22:
[...]

Cross platform? Op de PC ja. Lekker boeiend. Als je het over cross-platform games hebt, dan gaat dat in 99.999% van de gevallen niet over games die naast Windows ook op Linux en OS X draaien, maar om games die ook op de consoles van MS, Sony en Nintendo draaien. En die doen geen van allen OpenGL. Daar sta je dan met je zogenaamde cross platform API .

Ik weet niet wat Nintendo doet, maar de PS3 gebruikt OpenGL ES. Het voordeel is natuurlijk dat het op iedere console geïmplementeerd kàn worden.

[...]

Omdat OpenGL achter de feiten aanloopt en extensions een hel zijn om tegenaan te programmeren. Het voordeel dat je direct nieuwe features van hardwarefabrikanten kunt gebruiken is direct ook het nadeel - vergelijkbare features gebruiken voor verschillende vendors ook verschillende extensions die allemaal net iets anders werken, totdat er een log apparaat als de ARB eroverheen is gegaan om het te standaardiseren.

Er is 1 heel groot voordeel om voor Windows Direct3D te verkiezen boven OpenGL, en dat is support, documentatie en development tools. Heeft OpenGL een shader debugger? Heeft OpenGL een analyser zoals PIX? Hell, heeft OpenGL eigenlijk sowieso een standaard shader taal en compiler? Nee, nee en nee. Het is volledig afhankelijk van de community die dat soort tools aanleveren.

OpenGL loopt alleen met de nieuwe D3D10 features achter de feiten aan omdat die door MS bedacht zijn en pas later door GPU fabrikanten overgenomen, doordat het makkelijk is uit te breiden wordt OpenGL juist gebruikt door die laatsten om nieuwe features uit te testen. Dat standariseren daarna wat langer duurt is nu eenmaal het nadeel van consus zoeken, tov één bedrijf wat de dienst uit maakt, maar de hoeveelheid 'dubbele extensies' is zeer gering, aangezien de fabrikanten liever elkaars ontwerp overnemen (zie de lange lijst GL_EXT_ extensies).

Wat betreft tools heb je gelijk dat MS daar een goed alles in een pakket levert terwijl voor OpenGL inderdaad verschillende tools gezocht moeten worden, maar nVidia biedt toch ook een SDK met documentatie en verschillende tools en als je een beetje game maakt vast ook wel support. GLSL is tegenwoordig trouwens wel degelijk gestandariseerd! Er zijn alleen meerdere compilers, zoals ook voor C++.

IMHO is het grootste verschil echter dat OpenGL ontwikkelt wordt door de fabrikanten (vanuit hardware-perspectief) als standaard API om hun hardware te kunnen gebruiken, terwijl Direct3D door MS (dus vanuit programmer-perspectief) ontwikkelt wordt als API voor 3D hardware voor met name games.

[ Voor 5% gewijzigd door Ilmar op 14-05-2008 16:58 . Reden: laatste alinea toegevoegd ]

[Verwijderd]

MarCreative schreef op woensdag 07 mei 2008 @ 12:47:
Ik loop al enige tijd met de vraag: Waarom worden bijna alle spellen in DX10 geschreven en niet in OpenGL?

Met deze stelling ben ik het niet eens. Vaak zie je dat de (commeriele) engines vaak een D3D en OpgenGL backend hebben. Als voorbeeld de Unreal engine, die al vanaf dag 1 meerdere render backends ondersteund. Hierboven zit een extra abstractielaag zodat de daadwerkelijke backend afgesloten is van de rest van de engine. Het grote voordeel hiervan is dat een nieuwe render backend toevoegen relatief gezien simpel is, een klein nadeel is de (kleine) overhead door deze abstractielaag.

[abort_]

de online games met de beste feeling zijn toch echt games gebasseerd op opengl (q3 engine)!

[beany]

abort_ schreef op woensdag 14 mei 2008 @ 17:22:
de online games met de beste feeling zijn toch echt games gebasseerd op opengl (q3 engine)!

Dat is jouw persoonlijke mening, het zegt NIETS over de kwaliteiten van OGL of D3D !!!

Waarom willen mensen dit nou nooit snappen

[roy-t]

abort_ schreef op woensdag 14 mei 2008 @ 17:22:
de online games met de beste feeling zijn toch echt games gebasseerd op opengl (q3 engine)!

Waar CS1.6 weer kut liep op OpenGL en prima op D3D

OpenGL of D3D heeft niets te maken met Online Game feeling, alles wat kan in OpenGL is mogenlijk in D3D en omgekeerd, het is dezelfde hardware, alleen Dx10.1 voegt wat nieuwe truuks toe die je waarschijnlijk ook wel kan doen met wat extra code werk (Alleen geeft dat misschien teveel overhead)

Dus..

[.oisyn]

Ilmar schreef op woensdag 14 mei 2008 @ 16:49:
[...]


Ik weet niet wat Nintendo doet, maar de PS3 gebruikt OpenGL ES. Het voordeel is natuurlijk dat het op iedere console geïmplementeerd kàn worden.

Maar wat niet het geval is, waardoor je dus alleen op de PS3 in OpenGL ES gebruikt. Dit nog even naast het feit dat zelfs als de andere consoles ook OpenGL ES zouden gebruiken, en de PC ook, dan nog heb je geen crossplatform code omdat de hardware niet gelijk is. Je optimaliseert namelijk voor de hardware, waardoor keuzes die je voor de PS3 maakt niet dezelfde keuzes hoeven te zijn als die voor de Xbox 360.

Jouw argument zou ook opgaan voor Direct3D. Dat draait immers op de PC en op de Xbox 360. Toch is dat niet zo, om de redenen die ik zojuist gaf.

OpenGL loopt alleen met de nieuwe D3D10 features achter de feiten aan omdat die door MS bedacht zijn en pas later door GPU fabrikanten overgenomen

Wat is nou het punt dat je wilt maken? Het blijft toch gewoon zo dat OpenGL achter de feiten aanloopt? Dat kun je wel gaan verdedigen maar dat verandert de situatie niet. Ik ben verder ook niet pro-D3D of anti-OpenGL dus een fanboy discussie hoeven we niet te beginnen. Mijn stelling is echter dat Direct3D op de PC vaak praktischer is dan OpenGL.

Bovendien is het niet puur MS die de koers zet hoor. Ze zitten echt wel met nVidia en ATi om de tafel. MS is namelijk geen hardware fabrikant en hebben de expertise helemaal niet om te bepalen wat wel kan en wat niet kan.

maar de hoeveelheid 'dubbele extensies' is zeer gering, aangezien de fabrikanten liever elkaars ontwerp overnemen (zie de lange lijst GL_EXT_ extensies).

Ja dat verklaart ook wel waarom elke developer klaagt over dat ze nieuwe vergelijkbare features N keer moeten implementeren omdat ze nog vendor-specifiek zijn

[ Voor 4% gewijzigd door .oisyn op 15-05-2008 14:18 ]

[Ilmar]

.oisyn schreef op donderdag 15 mei 2008 @ 14:17:

Jouw argument zou ook opgaan voor Direct3D. Dat draait immers op de PC en op de Xbox 360. Toch is dat niet zo, om de redenen die ik zojuist gaf.

Wat ik hier bedoel is dat OpenGL een open standaard is en D3D niet, waardoor het voor Sony, Nintendo (en tegenwoordig ook Nokia en consorten) etc. te implementeren is, zonder juridisch getouwtrek met MS.

Wat is nou het punt dat je wilt maken? Het blijft toch gewoon zo dat OpenGL achter de feiten aanloopt? Dat kun je wel gaan verdedigen maar dat verandert de situatie niet. Ik ben verder ook niet pro-D3D of anti-OpenGL dus een fanboy discussie hoeven we niet te beginnen. Mijn stelling is echter dat Direct3D op de PC vaak praktischer is dan OpenGL.

[...]

Ja dat verklaart ook wel waarom elke developer klaagt over dat ze nieuwe vergelijkbare features N keer moeten implementeren omdat ze nog vendor-specifiek zijn

Mijn punt is dat OpenGL op het moment achter de feiten aan loopt, een situatie die over een jaar ofzo best anders kan zijn (zomaar een voorbeeld: ik zou mij kunnen voorstellen dat je kiest voor een OpenGL applicatie met wel/niet gebruik van een aantal extensies ipv een volledige abstraction layer voor D3D9/D3D10 om D3D10 features te kunnen gebruiken, zonder Vista te vereisen - als AMD nu eens opschiet met die features ook in hun OpenGL driver te stoppen ).

Ik ben het verder wel met je eens dat D3D vaak praktischer is, maar naar mijn idee omdat het minder flexibel is en je als developer dus met minder verschillende situaties rekening hoeft te houden (ook een van de voordelen van ontwikkelen voor consoles). Ik vind het voordeel van OpenGL dus juist die flexibiliteit en probeer aan te geven dat OpenGL meer is dan een bij elkaar geraapt zooitje en er dus zeker wel redenen zijn om voor OpenGL te kiezen ipv. D3D.

[.oisyn]

Ilmar schreef op donderdag 15 mei 2008 @ 17:28:

Wat ik hier bedoel is dat OpenGL een open standaard is en D3D niet, waardoor het voor Sony, Nintendo (en tegenwoordig ook Nokia en consorten) etc. te implementeren is, zonder juridisch getouwtrek met MS.

En wat ik bedoel is dat je daar vrijwel niets aan hebt omdat je toch wel voor dat platform gaat optimaliseren, waarbij het voordeel van een gelijke API zo goed als wegvalt.

Overigens spreken wij voor een groot deel direct de hardware aan op de meeste platforms. Onze Xbox 360 renderer backend lijkt in de verste verte niet op onze PC renderer backend, ookal is Direct3D op beide platforms beschikbaar.

Juridisch getouwtrek is trouwens een nonargument. Er is niets wat je tegenhoudt om een API te implementeren. Sterker nog, ik ken een bedrijf dat dat met D3D op de PS3 gedaan heeft

[ Voor 12% gewijzigd door .oisyn op 15-05-2008 18:03 ]

[EfBe]

.oisyn schreef op donderdag 15 mei 2008 @ 14:17:
[...]

Wat is nou het punt dat je wilt maken? Het blijft toch gewoon zo dat OpenGL achter de feiten aanloopt? Dat kun je wel gaan verdedigen maar dat verandert de situatie niet. Ik ben verder ook niet pro-D3D of anti-OpenGL dus een fanboy discussie hoeven we niet te beginnen. Mijn stelling is echter dat Direct3D op de PC vaak praktischer is dan OpenGL.

Bovendien is het niet puur MS die de koers zet hoor. Ze zitten echt wel met nVidia en ATi om de tafel. MS is namelijk geen hardware fabrikant en hebben de expertise helemaal niet om te bepalen wat wel kan en wat niet kan.

Nou, daar sla je de plank mis. opengl32.dll is al jaren niet geupdate door MS naar opengl2.0. Dit is om een reden en die kunnen we allemaal wel raden.
De ARB heeft al jaren geleden een geupdate opengl32.dll naar MS gestuurd, maar het nadeel wil dat de binding van de rendercanvas aan een Hdc nu juist proprietary code is en je dus dat niet zelf kunt releasen als ARB zijnde. (voor de leken: opengl32.dll is essentieel om iets met OpenGL te doen op windows, het regelt de verbinding tussen de opengl driver en het windows window, waar de render canvas op ligt)

Het gevolg is dus dat iedere OpenGL programmeur met lijsten met function pointers en typedefs zit om die extensions aan te spreken. Maar zo'n ramp is dat nou ook weer niet, want veelal is dat 1 keer oplossen en dan is het eigenlijk gelijk aan een api callen.

Dat MS de hardware op de PC stuurt door hun design van DX is een realiteit, dat zegt overigens niets over de functionaliteit van OpenGL op andere platforms, immers, hoe je het ook wend of keert: veel spullen zit tegenwoordig in shaders en het zware werk is echt 3D api generic spul. Polies pompen door een 3D api is nog wel realiteit maar niet dermate zwaarwegend dat dat nou een significante stempel drukt op een beetje project.

[ Voor 4% gewijzigd door EfBe op 15-05-2008 22:02 ]

[.oisyn]

Misschien ligt het aan mij maar ik zie totaal niet de relevantie van jouw post met die van mij

Het gevolg is dus dat iedere OpenGL programmeur met lijsten met function pointers en typedefs zit om die extensions aan te spreken

Daar heb je libraries voor. Volgens mij zelfs van de OpenGL site zelf te downloaden

Dat MS de hardware op de PC stuurt door hun design van DX is een realiteit

Dat ontken ik ook niet. Maar wat ik beweer is dat MS dat heus niet in zijn eentje doet, en daar hulp van de grote hardware vendors bij heeft. Of denk jij dat het concept shaders (een van de fundamentele vernieuwingen in hardware rendering land) puur en alleen door MS bedacht is?

[ Voor 46% gewijzigd door .oisyn op 15-05-2008 23:19 ]

[EfBe]

.oisyn schreef op donderdag 15 mei 2008 @ 23:16:
Misschien ligt het aan mij maar ik zie totaal niet de relevantie van jouw post met die van mij

De ARB (en ik deel die mening) is van mening dat de acceptatie van OpenGL op windows voor een groot deel is tegengewerkt door MS dmv het niet updaten van hun opengl32.dll, waardoor het lastiger wordt om opengl te programmeren op windows dan Dx. Het leek alsof jij van mening bent dat het aan OpenGL zelf ligt dat de acceptatie van OpenGL op windows niet zo groot is.

[...]
Dat ontken ik ook niet. Maar wat ik beweer is dat MS dat heus niet in zijn eentje doet, en daar hulp van de grote hardware vendors bij heeft. Of denk jij dat het concept shaders (een van de fundamentele vernieuwingen in hardware rendering land) puur en alleen door MS bedacht is?

Geen idee, ik denk het eerlijk gezegd niet (nvidia was dacht ik de 1e).

[ Voor 6% gewijzigd door EfBe op 16-05-2008 10:31 ]

[.oisyn]

EfBe schreef op vrijdag 16 mei 2008 @ 10:30:
[...]

De ARB (en ik deel die mening) is van mening dat de acceptatie van OpenGL op windows voor een groot deel is tegengewerkt door MS dmv het niet updaten van hun opengl32.dll, waardoor het lastiger wordt om opengl te programmeren op windows dan Dx. Het leek alsof jij van mening bent dat het aan OpenGL zelf ligt dat de acceptatie van OpenGL op windows niet zo groot is.

Daar ben ik het ook wel mee eens. Maar dit staat los van het feit dat OpenGL een nogal log consortium achter zich heeft waardoor updates sowieso lang op zich laten wachten. Ik bedoel, hoe lang heeft het wel niet geduurd voordat OpenGL 2.0 er was? Maar goed, dat is natuurlijk ook inherent aan het feit dat het open is en daardoor iedereen een zegje kan (en wil) hebben. Dat zie je bijvoorbeeld ook met C++. Maar welk argument je er ook bij plaatst waarom het zo is, het feit blijft wel dát het zo is, en dat is in het nadeel van OpenGL .

[EfBe]

.oisyn schreef op vrijdag 16 mei 2008 @ 10:47:
[...]

Daar ben ik het ook wel mee eens. Maar dit staat los van het feit dat OpenGL een nogal log consortium achter zich heeft waardoor updates sowieso lang op zich laten wachten. Ik bedoel, hoe lang heeft het wel niet geduurd voordat OpenGL 2.0 er was? Maar goed, dat is natuurlijk ook inherent aan het feit dat het open is en daardoor iedereen een zegje kan (en wil) hebben. Dat zie je bijvoorbeeld ook met C++. Maar welk argument je er ook bij plaatst waarom het zo is, het feit blijft wel dát het zo is, en dat is in het nadeel van OpenGL .

Nou, dat van dat logge is wel een beetje waar, maar laten we ook niet vergeten dat MS ook lid is van de ARB

[Zenix]

1 van de laatste opengl games is toch wel Enemy Territory Quake Wars en daarin zie je dat je met opengl zeker mooie games kan maken. Ik vind zelf opengl stuk fijner gamen, heb ervaring met Q3 engine vooral en nu dan Enemy Territory Quake Wars. Wat ik wel groot nadeel vind van opengl is dat het stuk minder en goed werkt met ATi kaarten, dat ligt eigelijk aan ATi vind ik maar het is toch een nadeel wat niet goed is voor OpenGL.

[.oisyn]

Zenix schreef op vrijdag 16 mei 2008 @ 15:33:
1 van de laatste opengl games is toch wel Enemy Territory Quake Wars en daarin zie je dat je met opengl zeker mooie games kan maken. Ik vind zelf opengl stuk fijner gamen, heb ervaring met Q3 engine vooral en nu dan Enemy Territory Quake Wars.

Sorry maar dat heeft toch echt geen zak met OpenGL te maken, maar alles met de gebruikte engine (id tech 4 als ik me niet vergis) . Met D3D kun je exact hetzelfde plaatje met exact dezelfde feel tevoorschijn toveren. 't Is de hardware die het werk doet, niet de gebruikte API.

[Elledan]

Zenix schreef op vrijdag 16 mei 2008 @ 15:33:
1 van de laatste opengl games is toch wel Enemy Territory Quake Wars en daarin zie je dat je met opengl zeker mooie games kan maken. Ik vind zelf opengl stuk fijner gamen, heb ervaring met Q3 engine vooral en nu dan Enemy Territory Quake Wars. Wat ik wel groot nadeel vind van opengl is dat het stuk minder en goed werkt met ATi kaarten, dat ligt eigelijk aan ATi vind ik maar het is toch een nadeel wat niet goed is voor OpenGL.

Een groot probleem is denk ik dat review sites totaal geen aandacht besteden aan OGL performance als ze een kaart reviewen. Ik gebruik zelf OGL vrij veel in mijn eigen en 3rd-party applicaties (cross-platform), en daarom zou ik het enorm op prijs stellen als ik kaarten op die punten kan vergelijken. Dankzij m'n werk aan de 3D engine weet ik nu dus dat ATI inderdaad knap waardeloos is als het op OpenGL aankomt, wat ook komt omdat ze bijvoorbeeld een suggestie voor een nieuw onderdeel van OGL te laat verzonden hebben, zodat nVidia ermee aan de haal is gegaan, en ATI nu met een net niet helemaal compitable implementatie zit. Ook zijn hun tools voor shader programming en zo niet echt flitsend.

Er is een reden waarom ATI voornamelijk met Windows systemen gebruikt word

[XGmode]

leonpwner1 schreef op woensdag 07 mei 2008 @ 23:11:
[...]


Quake 4, Prey
[...]

Serious Sam!

[Sebazzz]

Elledan schreef op vrijdag 16 mei 2008 @ 16:07:
[...]

Er is een reden waarom ATI voornamelijk met Windows systemen gebruikt word

Je moet het anders stellen: Er is een reden waarom ATi vaak niet op Linux systemen wordt gebruikt. Wel een verschil

[roy-t]

EfBe schreef op vrijdag 16 mei 2008 @ 10:30:
[...]

De ARB (en ik deel die mening) is van mening dat de acceptatie van OpenGL op windows voor een groot deel is tegengewerkt door MS dmv het niet updaten van hun opengl32.dll, waardoor het lastiger wordt om opengl te programmeren op windows dan Dx. Het leek alsof jij van mening bent dat het aan OpenGL zelf ligt dat de acceptatie van OpenGL op windows niet zo groot is.


[...]

Geen idee, ik denk het eerlijk gezegd niet (nvidia was dacht ik de 1e).

Wat let videokaart fabrikanten om in hun drivers een nieuwere versie van opengl32.dll mee te leveren? Of games zelf om die mee te leveren?

*Krom voorbeeldje*: MS update ook de "PhysX" dll files niet, en toch krijg je daar telkens nieuwere versie van

[Laurens-R]

EfBe schreef op vrijdag 16 mei 2008 @ 10:30:
Geen idee, ik denk het eerlijk gezegd niet (nvidia was dacht ik de 1e).

Shaders is een begrip die al zo oud is als de weg naar rome. Het stamt al uit de tijd van de eerste 3D animatie experimenten. In 3D land is een shader eigenlijk een oppervlakte/materiaal beschrijving... Dus hoe reageert deze op licht? Hoe ziet de texture er uit? Hoe wordt het object gedeformeerd, of hoe wordt het licht gedeformeerd op het moment dat dit door het object schijnt?

Nvidia en ATI hebben echter de eerste stappen genomen om dit alles in realtime te doen binnen de consumenten markt.

[.oisyn]

roy-t schreef op vrijdag 16 mei 2008 @ 18:01:
[...]


Wat let videokaart fabrikanten om in hun drivers een nieuwere versie van opengl32.dll mee te leveren? Of games zelf om die mee te leveren?

Omdat daar ook custom windows code in staat (de wgl* functies), die dan gerepliceerd moet worden in de custom dlls maar waar de hardware vendors uiteraard geen rechten van hebben.

Maar zoals ik al zei, je kan gewoon linken met een library die alle extensies voor jou uitzoekt en direct die functies beschikbaar maakt, zonder dat je moeilijk hoeft te doen met allerlei typedefs en functiepointers.

EvilB2k schreef op vrijdag 16 mei 2008 @ 18:04:

Shaders is een begrip die al zo oud is als de weg naar rome. Het stamt al uit de tijd van de eerste 3D animatie experimenten. In 3D land is een shader eigenlijk een oppervlakte/materiaal beschrijving... Dus hoe reageert deze op licht? Hoe ziet de texture er uit? Hoe wordt het object gedeformeerd, of hoe wordt het licht gedeformeerd op het moment dat dit door het object schijnt?

Duh . Met "shaders" bedoelde ik de vertex en pixel shader programma's die uitgevoerd worden door de videokaart, wat tov de fixed function pipeline, die nogal lineair en gelimiteerd was, een hele vooruitgang was. Ook die dingen heten shaders, en ik had het dus niet over de algemene wiskundige benadering van bepaalde shading

[ Voor 38% gewijzigd door .oisyn op 16-05-2008 18:22 ]

[coretx]

Ik denk dat het in deze discussie eerlijker is om dx10.n te vergelijken met OpenGL 3.0>

[LauPro]

Historisch gezien is elke interface binnen de IT industie maar beperkt houdbaar. Het is mooi als een interface backwards compatible is bijvoorbeeld maar meestal zorgt het voor nieuwe problemen. Ik 'geloof' dus bijvoorbeeld niet tussen goed/slecht bij OpenGL en D3D, maar ik prefereer OpenGL wel omdat het gewoon *meer* platformonafhankelijker is. En van alle personal computers met 3d-toepassingen is het PC-platform wel het meest gebruikt.

Bij OpenGL/D3D is het nog zeker pikant dat het een zware hardware based interface is. Over 20 jaar is je Geforce 9800 helemaal niets meer waard en waarschijnlijk stuk en heb je dus ook niets meer aan software die geschreven is op OGL3/D3D10.

Net zoals je nu met veel pijn en moeite via emulators de games van 20 jaar geleden kan draaien.

Een voorbeeld van een veel duurzamere interface is denk ik QT. Dit is pc-platform onafhankelijk (Win32/64,linux,bsd,darwin etc) maar is wel een extra abstractielaag (en dus overhead).

Uiteindelijk moet je dus kijken hoe lang je je spel wil gebruiken. Voor de meeste spellen zal het 2-3 jaar zijn en dan is het geen probleem om met de dan actuele 3D-interface te programmeren.

[Stukfruit]

EfBe schreef op donderdag 15 mei 2008 @ 22:00:
Het gevolg is dus dat iedere OpenGL programmeur met lijsten met function pointers en typedefs zit om die extensions aan te spreken. Maar zo'n ramp is dat nou ook weer niet, want veelal is dat 1 keer oplossen en dan is het eigenlijk gelijk aan een api callen.

Ik durf je daar wel op tegen te spreken eigenlijk. Al een aantal maanden ben ik bezig met een redelijk geavanceerd programma om 3d modellen mee te maken, en ik vind het werkelijk een ramp.

Op zich heb je gelijk en is het niet zo moeilijk om de extensies aan te spreken. Zeker niet als je een spelletje maakt en het maar 1x hoeft te doen. Maar wanneer je meerdere contexts tegelijkertijd gebruikt, en ervoor moet zorgen dat de functies van de extensies samen met de bijbehorende context gebruikt worden, dan wordt het al snel een heel geregel met overbodig gezeur om de boel op de juiste manier aan de praat te houden. Heerlijke manier ook om meer zinloze bugs mee te introduceren.

Tuurlijk, je kan kant-en-klare oplossingen als glew gebruiken, maar dat levert verschrikkelijk smerige code op, waarbij je variabelen als "GLEW_MX" moet definieeren om een andere variant van die bibliotheek te bouwen, en daarna met GLEWContext's en een berg macro-shit aan de slag moet om het aan het werk te krijgen.

[The Flying Dutchman]

Een redelijke kick, maar volgens mij wel een interessant onderwerp en dus reageer ik er toch nog even op.

Stukfruit schreef op zaterdag 17 mei 2008 @ 10:21:
Tuurlijk, je kan kant-en-klare oplossingen als glew gebruiken, maar dat levert verschrikkelijk smerige code op, waarbij je variabelen als "GLEW_MX" moet definieeren om een andere variant van die bibliotheek te bouwen, en daarna met GLEWContext's en een berg macro-shit aan de slag moet om het aan het werk te krijgen.

Dit probleem herken ik persoonlijk niet. Toegegeven ik ben een (in mijn eigen ogen) beginnend OpenGL programmeur (heb de Superbible door gewerkt, daarnaast heb ik een paar redelijk geavanceerde gpgpu programma's geschreven waarvan één OpenGL/GLSL om vortex detection te doen en de ander OpenGL/Cg die fluid simulation deed. Daarnaast ben ik bezig geweest met een eigen 3d bestandsformaat, met exporter vanuit Blender en een OpenGL viewer), maar ik vind Glew fijn werken. Het enige wat je doet is een functie aanroepen om te checken of OpenGL 2.0 ondersteunt wordt en glew initialiseren. Ik doe niets met variabelen definieren of macro's gebruiken en het werkt prima.

Met DirectX heb ik geen enkele ervaring, ik programmeer alleen onder Linux dus dan kom je toch uit bij OpenGL. Wat ik vooral jammer vind is dat OpenGL 3.0 nog steeds niet het levenslicht heeft gezien. Deze nieuwe API zou al een jaar geleden tot standaard verheven zijn, maar is nog steeds niet verschenen en het is angstvallig stil. Misschien dat er over een aantal weken op Siggraph 2008 iets naar buiten komt, laten we het hopen. Voor zover ik weet zou OpenGL 3.0 een schonere en consistentere api op moeten leveren, waardoor het programmeren in OpenGL wat eenvoudiger wordt.

Overigens zijn games lang niet het enige meer waarvoor je een 3d api nodig hebt. Vooral in de wetenschappelijke wereld wordt voornamelijk OpenGL gebruikt (voor bijvoorbeeld visualisatie van grote hoeveelheden data of voor gpgpu).

Ik kan me overigens goed voorstellen dat game ontwikkelaars DirectX gebruiken vanwege de ondersteuning die je erbij krijgt, de (waarschijnlijk iets) betere drivers en omdat 95% van de games nu eenmaal onder Windows draait of op een console. Afgezien van het feit dat OpenGL 3.0 nu al veel te lang op zich laat wachten, denk ik dat de opzet van OpenGL best goed zou kunnen werken. Nieuwe functies in hardware kan direct ondersteunt worden via een extensie en de extensies die door de grote hardware fabrikanten ondersteunt worden en die door de developpers veel gebruikt worden kunnen in een volgende standaard tot de verplichte kost behoren. Dus werkt het juist andersom als bij DirectX: de hardware bepaald de standaard, hoewel je door het systeem van de extensies niet tegengehouden wordt om de nieuwste hardware te gebruiken als de nieuwe functies nog niet in de standaard zitten.

Ik hoop dat OpenGL met versie 3.0 weer eens flink van zich laat horen en dat er weer wat meer beweging komt in 3d api land. Zelf blijf ik voorlopig in ieder geval OpenGL programmeren, met als redenen dat ik onder Linux werk (en dat ik het eventueel naar Windows kan porten als ik dat zou willen), dat ik er al bekend mee ben en omdat ik een beetje een idealist ben .

Overigens net even op de Siggraph pagina gekeken, dit zal ik met veel belangstelling volgen (hopelijk lukt dat een beetje via internet):
http://www.khronos.org/ne...08_los_angeles_california

Khronos BOFS & BOF Socials

Get the inside scoop on OpenGL from the ARB and leading OpenGL companies:

* OpenGL 3.0 Specification Overview
* OpenGL hardware and driver plans - AMD, Intel, NVIDIA
* Developer's perspective on OpenGL 3.0
* The new Khronos Compute Working Group and how that affects OpenGL
* and more...

[epic007]

The Flying Dutchman schreef op donderdag 24 juli 2008 @ 12:06:
Overigens zijn games lang niet het enige meer waarvoor je een 3d api nodig hebt. Vooral in de wetenschappelijke wereld wordt voornamelijk OpenGL gebruikt (voor bijvoorbeeld visualisatie van grote hoeveelheden data of voor gpgpu).

Volgens mij zijn 3d api's in eerste instantie niet voor games ontwikkeld maar voor ontwerpers (CAD, auto ontwerp etc) en wetenschappelijke doeleinden.

Direct3D (DirectX in het algemeen) is volgens mij wel in de eerste plaats voor games ontwikkeld (Niet dat er geen andere applicaties mee gemaakt kunnen worden).

OpenGL dient nog steeds het eerste doel, en is nog steeds de main api voor veel 3D ontwerp programma's (denk aan 3ds MAX, maya, autocad, solidworks etc).

Een pluspuntje voor OpenGL vind ik dat het netwerk transparant is, op unix met X-Window. (vroeger op een SGI server software gedraaid waarvan de output inclusief OpenGL op een client draaide).

[roy-t]

epic007 schreef op dinsdag 29 juli 2008 @ 13:34:
[...]
Een pluspuntje voor OpenGL vind ik dat het netwerk transparant is, op unix met X-Window. (vroeger op een SGI server software gedraaid waarvan de output inclusief OpenGL op een client draaide).

Nu ben ik wel benieuwd. Wat bedoel je met netwerk transparant?

[epic007]

Onder unix (linux) kan je standaard remote applicaties naar je lokale display redirecten.

Zo werkten wij (ergens in het jaar 2000) met een duur 3d ontwerp pakket waarvoor we maar 1 licentie hadden. Ieder werkte achter een SGI werkstation, en de applicatie werd gewoon 4 keer opgestart op onze server. De display (+ OpenGL output) werd lokaal zichtbaar, zo konden we met zn vieren van een licentie gebruik maken.

Ik weet niet of dit onder linux ook out of the box werkt maar dat zou wel moeten.

http://en.wikipedia.org/wiki/GLX

[The Flying Dutchman]

Ik hoor vandaag dat OpenGL 3.0 over 10 dagen zal worden aangekondigt tijdens Siggraph 08 (waar ik al eerder naar refereerde). Verder hoorde ik dat OpenGL 3.0 niet gewoon OpenGL 2.1 met een nieuwe API wordt, maar dat DirectX 10 hardware vereist is om versie 3 van OpenGL te kunnen draaien. Dus toch nieuwe features in OpenGL, in tegenstelling tot wat eerst de bedoeling was.

Ik ben in ieder geval erg benieuwd naar de ontwikkelingen en ik hoop zo snel mogelijk ook zelf lekker aan de slag te kunnen om te kijken hoe het zich verhoudt tot versie 2.1.

[.oisyn]

Blij om te horen dat ook OpenGL ervoor kiest om backwards compatibility de deur uit te doen. Op een bepaald punt heb je dat gewoon nodig.

[Cyphax]

Maar zonder backwards compatibiliteit kan ik dus bijv. een spel gemaakt met OpenGL 3 niet op een <Dx10 kaart spelen? Ik vraag me af of ontwikkelaars dat niet een beetje te beperkend vinden. DirectX10-spellen draaien wel op DirectX<10-compatible hardware.

[.oisyn]

Cyphax schreef op donderdag 31 juli 2008 @ 12:19:
Maar zonder backwards compatibiliteit kan ik dus bijv. een spel gemaakt met OpenGL 3 niet op een <Dx10 kaart spelen?

Waar

DirectX10-spellen draaien wel op DirectX<10-compatible hardware.

Pertinent onwaar.

[Verwijderd]

Ik denk dat de backwards compatibility nog wel terugkomt later. Dan zal je wat features moeten missen die niet (performant genoeg) ge-emuleerd kunnen worden. Backwards compatibility is te belangrijk om achterwege te laten. OGL is niet alleen voor de high-end games, maar ook voor de "gewone" 3D. Vista's effecten zijn niet voor niets in DX9 geschreven. En je wilt niet op een oude unmaintained API door blijven werken slechts omdat je ook hardware wilt aanspreken die nog niet over de nieuwste technologiën beschikt.

[.oisyn]

Verwijderd schreef op donderdag 31 juli 2008 @ 12:41:
Ik denk dat de backwards compatibility nog wel terugkomt later. Dan zal je wat features moeten missen die niet (performant genoeg) ge-emuleerd kunnen worden.

Het hele idee van D3D10 was juist om een vaste featureset te creëren die gegarandeerd door de hardware ondersteund wordt, zodat je als programmeur niet allerlei dingen hoeft te checken en N codepaden hoeft te schrijven.

Backwards compatibility is te belangrijk om achterwege te laten. OGL is niet alleen voor de high-end games, maar ook voor de "gewone" 3D. [..] En je wilt niet op een oude unmaintained API door blijven werken slechts omdat je ook hardware wilt aanspreken die nog niet over de nieuwste technologiën beschikt.

Als je dat wilt dan kun je gewoon gebruik blijven maken van OpenGL 2.1, die middels extensions de meeste moderne features ook wel ondersteunt. Waarom zou je willen upgraden naar 3.0 als je niet per definitie van al die features gebruik kunt maken omdat je oudere hardware target?

Vista's effecten zijn niet voor niets in DX9 geschreven.

Precies het punt dat wat ik hierboven zeg bewijst: ze hebben D3D9 gebruikt omdat het ook op oudere hardware moet werken. Aero requiret geen D3D10 hardware, dus is er geen reden om D3D10 te gebruiken. Het "nadeel" (maar tevens ook weer meteen een voordeel) is dat D3D geen extension systeem heeft - in D3D9 zul je dus nooit D3D10 features aan kunnen spreken. OpenGL heeft hier geen "last" van, en in dat opzicht is een oudere OpenGL versie dus bruikbaarder dan een oudere D3D versie.

[Cyphax]

.oisyn schreef op donderdag 31 juli 2008 @ 12:20:
Pertinent onwaar.

Hoe hebben ze het precies gedaan? Nieuwe spellen werken met zowel DirectX10 als 9? Dat is dan in de engine gewoon zo geprogrammeerd? Dat zouden ze in dat geval met OpenGL wellicht ook kunnen doen.

[Verwijderd]

Cyphax schreef op donderdag 31 juli 2008 @ 13:25:
[...]

Hoe hebben ze het precies gedaan? Nieuwe spellen werken met zowel DirectX10 als 9? Dat is dan in de engine gewoon zo geprogrammeerd? Dat zouden ze in dat geval met OpenGL wellicht ook kunnen doen.

Ja, dat zouden ze kunnen doen, maar wat heb je dan aan OGL3? Het idee van OGL3 is dat de API opgeruimd is, en dat er wat fouten uitgehaald zijn. Als je ook nog een OGL2.1 codepath moet schrijven valt het hele voordeel van een "mooie" API weg, aangezien je toch nog de oude moet gebruiken. En voor de hardware-features hoef je het niet te doen, zoals .oisyn zegt: die zijn immers toch beschikbaar via extensies.

[Cyphax]

Verwijderd schreef op donderdag 31 juli 2008 @ 13:31:
Ja, dat zouden ze kunnen doen, maar wat heb je dan aan OGL3?

Je hoeft niet OGL2 altijd te blijven ondersteunen natuurlijk, het lijkt me dan alleen tijdelijk interessant. Handig is het niet, maar ik kan me voorstellen dat ze op gegeven moment hebben gedacht "en nu gaan we het veel netter doen" ten koste van backwards compatibility. Dat is ook iets wat Microsoft achtervolgt met Windows.

[mOrPhie]

Cyphax: bedenk ook dat de release-cycle van een major opengl wat langer duurt dan die van een major directx versie. OpenGL 3 is misschien wel voor de komende 5 tot 8 jaar (wellicht langer!) bedoeld. Zo'n stap is dus wellicht nu beperkend, maar voor het grootste gedeelte van z'n lifecycle niet, omdat wij ook weer nieuwe hardware blijven kopen. Het zal dus wat langer duren, maar tegen die tijd dat ontwikkelaars het dus commercieel interessant vinden om opengl 3 te gaan gebruiken (omdat de hardware meer aanwezig is), heb je wel een opengl die al een tijdje in het wild getest is.

[Cyphax]

Dat is ook een van de redenen waardoor ik mij kan voorstellen dat ze backwards compatibility hebben laten vallen. Ik denk zelfs dat ze daar een goede keuze mee gemaakt hebben. Het is verleidelijk om backwards compatible te zijn maar als de kwaliteit van je api daaronder lijdt zou ik deze keuze zelf ook gemaakt hebben denk ik.

Ik maak me meer druk om het feit dat OpenGL in de gamesindustrie naar mijn idee te weinig gebruikt wordt. Het is bijna allemaal DirectX en ik vind het jammer dat ik om spellen te kunnen spelen bijna word gedwongen Windows aan te schaffen. Juist omdat het met OpenGL icm iets als SDL ook multiplatform te maken is..

[ Voor 32% gewijzigd door Cyphax op 31-07-2008 14:01 ]

[.oisyn]

Dat je wordt gedwongen om Windows aan te schaffen heeft niets te maken met de gebruikte API, maar alles met afzetmarkt. Het is commercieel gewoon oninteressant om games voor andere PC platformen dan Windows te maken. Je draait oorzaak en gevolg dan ook een beetje om: het is niet zo dat games niet op andere platforms uitkomen omdat ze D3D gebruiken - het is juist zo dat het cross-platform voordeel van OpenGL oninteressant is omdat ze toch al niet voor andere platforms gaan ontwikkelen.

Daarnaast is het wijzigen van de API calls in een fatsoenlijk opgezette renderer wel het minste werk bij het porten van een game.

[Cyphax]

.oisyn schreef op donderdag 31 juli 2008 @ 14:14:
Dat je wordt gedwongen om Windows aan te schaffen heeft niets te maken met de gebruikte API, maar alles met afzetmarkt. Het is commercieel gewoon oninteressant om games voor andere PC platformen dan Windows te maken.

Want het kost veel meer geld om een game in OpenGL te doen dan in Direct3D? Als de commercie zo'n belangrijke factor is, wat is dan commercieel gezien het voordeel van DirectX?

Je draait oorzaak en gevolg dan ook een beetje om

Probleem: ik heb thuis een Linuxmachine. Besteld bij Dell, kwam met Ubuntu voorgeïnstalleerd. Ik kan er geen spelletje op draaien.
Oorzaak: spelletje is gemaakt met een Api die alleen is gemaakt voor Windows, door Microsoft.

Jij zegt: probleem == ik had maar Windows moeten kopen, of begrijp ik je verkeerd? Is het dan echt zo moeilijk om je afhankelijkheid van één besturingssysteem te laten varen? Jij weet ervan: waarom kiezen jullie ervoor om TR te maken obv DirectX? (gevaarlijke aanname: ik weet niet of dat ook echt zo is, ik doe even alsof ) Is het de effectieve marketing van Microsoft, of bieden ze zulke goede tools waarmee OpenGL + SDL (bijv) gewoonweg inferieur is?

[Verwijderd]

.oisyn schreef op donderdag 31 juli 2008 @ 14:14:
Dat je wordt gedwongen om Windows aan te schaffen heeft niets te maken met de gebruikte API, maar alles met afzetmarkt. Het is commercieel gewoon oninteressant om games voor andere PC platformen dan Windows te maken. Je draait oorzaak en gevolg dan ook een beetje om: het is niet zo dat games niet op andere platforms uitkomen omdat ze D3D gebruiken - het is juist zo dat het cross-platform voordeel van OpenGL oninteressant is omdat ze toch al niet voor andere platforms gaan ontwikkelen.

Daarnaast is het wijzigen van de API calls in een fatsoenlijk opgezette renderer wel het minste werk bij het porten van een game.

Volgens mij is porten sowieso nooit zoveel werk. Je zit nog steeds op dezelfde hardware (als we het tenminste over Unix/Mac cross-platform hebben). De enige reden dat games niet voor de minderheids-platformen uitkomen, is omdat je dan extra support moet leveren op platforms die bijna geen geld opleveren. Ook het testen is opeens een stuk meer werk geworden. De problemen worden niet zozeer meer, maar het test-oppervlak wordt wel verdrievoudigd.

[.oisyn]

Cyphax schreef op donderdag 31 juli 2008 @ 14:31:
[...]

Want het kost veel meer geld om een game in OpenGL te doen dan in Direct3D? Als de commercie zo'n belangrijke factor is, wat is dan commercieel gezien het voordeel van DirectX?

Van oudsher betere support, documentatie en development tools, met het gevolg dat er nu veel meer ervaring in d3d is dan in OpenGL. Dus ja, OpenGL kost in de meeste gevallen meer geld. Bovendien doe je nu net alsof bij het gebruik van OpenGL je game met een druk op de compileerknop ook ineens op linux draait en je game dus verkoopbaar is voor linux

Probleem: ik heb thuis een Linuxmachine. Besteld bij Dell, kwam met Ubuntu voorgeïnstalleerd. Ik kan er geen spelletje op draaien.
Oorzaak: spelletje is gemaakt met een Api die alleen is gemaakt voor Windows, door Microsoft.

Jij zegt: probleem == ik had maar Windows moeten kopen, of begrijp ik je verkeerd?

Ja, je begrijpt me verkeerd. Het "probleem" is dat linux voor gamedevelopers niet interessant is, en daarom zie je geen games voor linux. Dat ze vervolgens geen OpenGL gebruiken is deels een symptoom van dat probleem, en niet andersom. Laat ik het zo stellen: als alle developers plotseling ineens OpenGL gingen gebruiken omdat dat een betere API is oid, zul je nog altijd niet veel meer linux games zien dan nu het geval is.

Is het dan echt zo moeilijk om je afhankelijkheid van één besturingssysteem te laten varen? Jij weet ervan: waarom kiezen jullie ervoor om TR te maken obv DirectX? (gevaarlijke aanname: ik weet niet of dat ook echt zo is, ik doe even alsof ) Is het de effectieve marketing van Microsoft, of bieden ze zulke goede tools waarmee OpenGL + SDL (bijv) gewoonweg inferieur is?

Last time I checked, dat laatste, mede door onze opgebouwde kennis van D3D.

Verwijderd schreef op donderdag 31 juli 2008 @ 14:39:
[...]

Volgens mij is porten sowieso nooit zoveel werk. Je zit nog steeds op dezelfde hardware (als we het tenminste over Unix/Mac cross-platform hebben). De enige reden dat games niet voor de minderheids-platformen uitkomen, is omdat je dan extra support moet leveren op platforms die bijna geen geld opleveren. Ook het testen is opeens een stuk meer werk geworden. De problemen worden niet zozeer meer, maar het test-oppervlak wordt wel verdrievoudigd.

Dat is idd vrijwel het grootste probleem. De return-of-investment is voor linux over het algemeen veel te laag. Een iets kleiner probleem op de Mac, waardoor je relatief meer Mac games ziet dan linux games (maar nog steeds met aantallen die in het niet vallen bij Windows)

[ Voor 4% gewijzigd door .oisyn op 31-07-2008 14:54 ]

[Verwijderd]

Cyphax schreef op donderdag 31 juli 2008 @ 14:31:
Jij zegt: probleem == ik had maar Windows moeten kopen, of begrijp ik je verkeerd? Is het dan echt zo moeilijk om je afhankelijkheid van één besturingssysteem te laten varen? Jij weet ervan: waarom kiezen jullie ervoor om TR te maken obv DirectX? (gevaarlijke aanname: ik weet niet of dat ook echt zo is, ik doe even alsof ) Is het de effectieve marketing van Microsoft, of bieden ze zulke goede tools waarmee OpenGL + SDL (bijv) gewoonweg inferieur is?

SDL is niet zoveel. Als je echt aan het werk gaat neem je gespecialiseerde libraries. Van DirectX wordt ook eigenlijk alleen maar Direct3D gebruikt. Voor geluid wordt veelal OpenAL gebruikt. Voor physics meestal Havok of PhysX. Filmpjes worden doorgaans gedaan met Bink Video. Dan heb je de middleware wel zo'n beetje gehad denk ik. De rest is de (zelfgemaakte of gekochte) engine.

Kwalitatief zijn Direct3D 9 en OpenGL 2.1 vergelijkbaar. Er is er "gewoon" eentje standaard geworden. Waarom gebruikt iedereen Photoshop, terwijl Corel Photo Paint net zo goed werkt? Mensen werken gewoon liefst met dezelfde tools.

[Cyphax]

.oisyn schreef op donderdag 31 juli 2008 @ 14:49:
Van oudsher betere support, documentatie en development tools, met het gevolg dat er nu veel meer ervaring in d3d is dan in OpenGL. Dus ja, OpenGL kost in de meeste gevallen meer geld.

Bovendien doe je nu net alsof bij het gebruik van OpenGL je game met een druk op de compileerknop ook ineens op linux draait en je game dus verkoopbaar is voor linux

Ik snap ook wel dat het ingewikkelder ligt dan dat natuurlijk, maar het lijkt mij makkelijker te doen dan bij d3d. Zo knettermoeilijk zal het niet zijn toch, als id het kan, en epic?

Ja, je begrijpt me verkeerd. Het "probleem" is dat linux voor gamedevelopers niet interessant is, en daarom zie je geen games voor linux. Dat ze vervolgens geen OpenGL gebruiken is deels een symptoom van dat probleem, en niet andersom. Laat ik het zo stellen: als alle developers plotseling ineens OpenGL gingen gebruiken omdat dat een betere API is oid, zul je nog altijd niet veel meer linux games zien dan nu het geval is.

Zoals ik het nu zie is het probleem vooral dat Microsoft voor ontwikkelaars een beter product biedt. Ik heb dat al wel vaker gelezen, dus dat is niet bepaald een schokkende ontdekking, maar dat is wellicht oorzaak #1.

Dat is idd vrijwel het grootste probleem. De return-of-investment is voor linux over het algemeen veel te laag. Een iets kleiner probleem op de Mac, waardoor je relatief meer Mac games ziet dan linux games (maar nog steeds met aantallen die in het niet vallen bij Windows)

Nu wordt het marktaandeel van Linux heeeeel langzaam een klein beetje groter minder klein maar een belangrijke reden daarvoor is dat alles alleen voor Windows verschijnt. Ik kan het verder niemand kwalijk nemen, ik vind het gewoon jammer, want het resultaat is gewoon dat ik per sé Windows op mijn PC moet installeren om een spelletje te kunnen spelen. Nu is het gelukkig minder zwart/wit dan dat, tegenwoordig is zelfs CoD4 al goed te draaien onder Wine: die kan steeds meer en meer dus het probleem wordt voorlopig steeds kleiner en da's een aardige troost. Ik heb ook geluk dat de games die ikzelf het liefst speel (met name Diablo2) het heel goed doen met Wine.

Verwijderd schreef op donderdag 31 juli 2008 @ 14:50:
Van DirectX wordt ook eigenlijk alleen maar Direct3D gebruikt. Voor geluid wordt veelal OpenAL gebruikt. Voor physics meestal Havok of PhysX. Filmpjes worden doorgaans gedaan met Bink Video. Dan heb je de middleware wel zo'n beetje gehad denk ik. De rest is de (zelfgemaakte of gekochte) engine.

Dit is me dan wel weer nieuws. Tenminste, ik zie Bink heel vaak terug, en vroeger was er nog Miles (of dat nog gebruikt wordt weet ik niet, maargoed, komt de hetzelfde ontwikkelaar als Bink dus het zou me nieteens verbazen) maar ik zou denken dat de libs van Dx wat meer gebruikt worden.

Kwalitatief zijn Direct3D 9 en OpenGL 2.1 vergelijkbaar. Er is er "gewoon" eentje standaard geworden. Waarom gebruikt iedereen Photoshop, terwijl Corel Photo Paint net zo goed werkt? Mensen werken gewoon liefst met dezelfde tools.

Dat snap ik wel. Nu is er wel een verschil dat ik belangrijk vind: ik kan afbeeldingen die jij maakt bekijken, of je ze nu maakt met Photoshop of met Photo Paint. Je slaat ze op volgens een standaardformaat en het werkt. Ik mis dat in de gamesindustrie. Ik ben zelf voor het gebruik van platformonafhankelijke oplossingen, mits in redelijkheid mogelijk.

[ Voor 21% gewijzigd door Cyphax op 31-07-2008 15:16 ]

[.oisyn]

Cyphax schreef op donderdag 31 juli 2008 @ 15:12:
Zoals ik het nu zie is het probleem vooral dat Microsoft voor ontwikkelaars een beter product biedt. Ik heb dat al wel vaker gelezen, dus dat is niet bepaald een schokkende ontdekking, maar dat is wellicht oorzaak #1.

De oorzaak van dat je weinig OpenGL games ziet dan, ja. Niet de oorzaak van dat je weinig linux-games ziet.

Ik ben het verder met je eens dat het een kip-ei probleem is. Weinig mensen gebruiken linux omdat veel games niet onder linux werken, en weinig mensen maken games voor linux omdat er zo weinig mensen linux gebruiken. Ik kan niet anders zeggen dan: tough luck. Je kan ook gewoon een console kopen. Een PS3 bijvoorbeeld. Kun je ook linux op installeren

[ Voor 29% gewijzigd door .oisyn op 31-07-2008 15:52 ]

[Cyphax]

.oisyn schreef op donderdag 31 juli 2008 @ 15:50:
De oorzaak van dat je weinig OpenGL games ziet dan, ja. Niet de oorzaak van dat je weinig linux-games ziet.

Ik wil graag meer zoals UT2004 (geen idee of UT3 eigenlijk al werkt en zo nee, of dat nog gaat komen), native onder Linux! Gelukkig heeft Valve aangegeven Source te poorten naar. Ondanks dat Source-based spellen al goed draaien via Wine, toch een goed teken. En Ubuntu doet het ook goed, er zit wel een duidelijk stijgende lijn in. Marktaandeel is nog steeds verwaarloosbaar, maar dat hoeft niet zo te blijven. Het aantal PC-gebruikers dat ook gamed is gelukkig niet 100% waardoor de kip-ei-situatie niet helemaal 50/50 is.

Ik ben het verder met je eens dat het een kip-ei probleem is. Weinig mensen gebruiken linux omdat veel games niet onder linux werken, en weinig mensen maken games voor linux omdat er zo weinig mensen linux gebruiken. Ik kan niet anders zeggen dan: tough luck. Je kan ook gewoon een console kopen. Een PS3 bijvoorbeeld. Kun je ook linux op installeren

Ik heb genoeg consoles (waarvan de nieuwste dan wel een N64 is , maar ik geef niet zoveel om veel games en ik speel ook liefst spellen die voorheen altijd op de PC uitkwamen. Ik spaar ze dan weer wel ).

[coretx]

[quote].oisyn schreef op donderdag 31 juli 2008 @ 15:50:
[...]

De oorzaak van dat je weinig OpenGL games ziet dan, ja. Niet de oorzaak van dat je weinig linux-games ziet.

Ik ben het verder met je eens dat het een kip-ei probleem is. Weinig mensen gebruiken linux omdat veel games niet onder linux werken, en weinig mensen maken games voor linux omdat er zo weinig mensen linux gebruiken. Ik kan niet anders zeggen dan: tough luck. Je kan ook gewoon een console kopen. Een PS3 bijvoorbeeld. Kun je ook linux op installeren
[/quote]

Om die reden heb ik hem gekocht, sluit ik hem aan.... Geen RSX Toegang !
Jaar later, blit-blit exploit, - happy! - 2 maanden er na een firmware update die het onmogelijk maakt!

[The Flying Dutchman]

Nou, ik ben benieuwd wat er tijdens Siggraph over OpenGL 3 bekend gemaakt wordt... John Carmack heeft gezegd dat OpenGL 3 niet backward compatibility laat varen...

Deze quote komt van de Khronos message boards:

http://www.enemyterritory...con2008_et.tv_keynote.mp3

2hr 12min 15sec into it, audience member asks about the current state of OpenGL, Carmack replies:

"Yeah, so that's a little bit sad, the way that whole situation has gone. I understand the way it all happened and I can't be too upset about it, but there was a move going to modernize the OpenGL API. It really has a lot of cruft on it right now. I'm quite frank in saying that the DX9+ class Microsoft APIs are a lot better thought out and more consistent than the current state of OpenGL, which has selectors and all these extensions and things that just aren't really clean and nice, and there was a move to go ahead and bring it up to par... [inaudible, loud squeaking door] some directions were perhaps mis-steps, but some things were looking pretty good on there. But, as I understand, what happened was some of the companies on the ARB made the justifiable statement that the major codebases for CAD developers, the 10 million line codebases, the 20 years of ancient history, they're never going to convert to a radically new API. Making a new OpenGL that's not remotely backwards compatible just isn't going to fly, isn't worth doing. And, I disagree with that stance, but not enough to make a scene about it. I do think that there is a need for a non-Microsoft, open, cross platform API that's modern-- we can still do everything we need to with the current OpenGL, it's just kind of a mess. That's not the argument you want to be making. You want to say 'We're using this because it's clean and elegant, and it's better than the alternative,' and that's not really the case..."

He goes on to talk about the benefit of extensions which current OpenGL has over D3D in terms of experimenting with cutting edge hardware. He also talks briefly about OpenGL ES.

Oftewel: volgens Carmack zal OpenGL 3.0 niet de nieuwe mooie opgeschoonde api zijn zoals game developers graag zouden willen, maar blijft backwards compatibility voor CAD developers.

[.oisyn]

Crud. Oh well, their loss.

[The Flying Dutchman]

Ik denk dat Khronos flink commentaar gaat krijgen van de OpenGL community als ze nu, na een jaar helemaal niets van zich te laten horen, terwijl OpenGL 3.0 vorig jaar herfst al het levenslicht zou zien, niet de vernieuwende api is die men verwacht.

Overigens is er ook al meer dan een jaar geen OpenGL pipeline newsletter geweest. De OpenGL gebruikers zullen hier beslist niet blij mee zijn... nouja, nog maar een paar dagen afwachten wat er nou echt gaat gebeuren.

[The Flying Dutchman]

Uitgelekte specificaties:
http://opengl.org/registry/doc/glspec30.20080811.pdf


Nog niet gekeken, maar wat ik ervan heb begrepen is het niet veel meer dan OpenGL 2.2.
Zie voor meer:

http://www.opengl.org/dis...t&Number=229374&fpart=154
en
http://www.gamedev.net/co...topic.asp?topic_id=504547

Ook de specificaties van GLSL 1.3 zijn bekend:
http://www.opengl.org/reg...LangSpec.Full.1.30.08.pdf

[ Voor 33% gewijzigd door The Flying Dutchman op 11-08-2008 17:04 ]

[Verwijderd]

Hmm, blijkbaar hebben ze er genoeg van bij de ARB. Ik zou zeggen, laat OGL maar varen en port D3D naar Unix met de hulp van Codeweavers. Als de ARB zelf geen API meer kan verbeteren, dan volgen we Microsoft wel gewoon.

[Shammah]

Ik denk dat ik maar ga overstappen naar DirectX dan. Ik ben nog nieuwe in OpenGL, en ik denk dat het beter is om nu naar Dx te gaan voordat ik vastgeroest zit aan OpenGL, want het schijnt niet best te zijn

[The Flying Dutchman]

De community is furieus over deze nieuwe versie. Het deprication model geeft echter hoop, vrijwel alle fixed pipeline functionaliteit is depricated en zal met een volgende versie niet meer aanwezig zijn (zie hiervoor de specificatie, appendix E). Door profielen te gebruiken kun je bijvoorbeeld kiezen voor het forward-compatible profiel, dat geen gebruik maakt van depricated functies.

Ook is de object georienteerde api nog niet van de baan, er wordt aan gewerkt volgens Khronos leden die gereageerd hebben in een topic op opengl.org. De community heeft echter totaal geen vertrouwen meer in Khronos, nu ze na een jaar niets van zich te laten horen een OpenGL api uitbrengen die niet is wat ze beloofd hebben. Het vertrouwen is helemaal weg en de enige manier waarop dit teruggewonnen kan worden door Khronos is het snel uitbrengen van een geupdate spec (versie 3.1) die alle depricated code eruit gooit. Ook is het nog even afwachten welke info er de komende dagen op Siggraph 2008 bekend wordt.

Ik blijf voorlopig nog wel even bij OpenGL, al is het alleen maar omdat het cross-platform is. Ik hoop dat er zo snel mogelijk drivers beschikbaar komen, dan kan ik gaan ontwikkelen (uiteraard zal ik dan het forward-compatible profiel gaan gebruiken). Verder is het te hopen dat Khronos snel met meer updates komt, want ik had ook gehoopt op een mooie, moderne en schone api om in te ontwikkelen.

[Cyphax]

Het klinkt een klein beetje als X11 waar mensen het op gegeven moment ook helemaal mee gehad hebben en een fork hebben gemaakt.
Dit is niet zo mooi, tijd om echt actie te ondernemen? Of gewoon OpenGL 2.2 blijven gebruiken?

[The Flying Dutchman]

Ik denk dat ontwikkelaars die de optie hebben om DirectX te gebruiken vrij masaal zullen overstappen (als ze dat niet al gedaan hadden). Voor anderen die geen keuze hebben (linux, mac), zij zullen wel blijven. Je kunt OpenGL niet zomaar even forken oid. Een api heeft driver support nodig en anders heb je er helemaal niets aan. Dus zoiets zie ik niet zomaar gebeuren.

Wel kun je reacties lezen op de fora van mensen die een software rasterizer voor Larabee willen gaan schrijven (en die dus hopen dat graphics fabrikanten allemaal richting een Larabee achtige structuur gaan). Maar een rasterizer schrijven is ook geen kattepis en het is nog maar de vraag of Ati en nVidia wel die kant op gaan (nVidia heeft niet eens een x86 licentie en dus kán nVidia dat niet eens).

Daarnaast zal het laatste woord hierover niet gesproken zijn, sowieso verwacht ik nog meer nieuws de komende dagen van Siggraph 2008, over de toekomstplannen voor OpenGL van Khronos. Voor de duidelijkheid, OpenGL 3.0 is een redelijk complete api (alleen geometry shaders moeten via extensies benaderd worden) waarmee je prachtige applicaties kunt bouwen. Het gaat alleen niet zo gemakkelijk als met DirectX en veel hangt af van driver support (en of de hardware fabrikanten de geometry shader extensie in hun drivers zullen opnemen).

[Cyphax]

Het gaat me niet zozeer om het technische aspect, ik geloof wel dat je met OpenGL genoeg kan, maar meer de onvrede die het oplevert bij developers die nu OpenGL laten voor wat het is hierom, en de negatieve marketing die daarbij komt kijken.

[.oisyn]

The Flying Dutchman schreef op dinsdag 12 augustus 2008 @ 13:26:
Wel kun je reacties lezen op de fora van mensen die een software rasterizer voor Larabee willen gaan schrijven (en die dus hopen dat graphics fabrikanten allemaal richting een Larabee achtige structuur gaan). Maar een rasterizer schrijven is ook geen kattepis en het is nog maar de vraag of Ati en nVidia wel die kant op gaan (nVidia heeft niet eens een x86 licentie en dus kán nVidia dat niet eens).

Het hoeft natuurlijk ook niet een x86 te zijn om te "software rasterizen". SM 4.0 is al dermate uitgebreid dat je het bijna general purpose cpu's kunt noemen, en de daadwerkelijke hardware is niet gelimiteerd aan wat je met grafische API's ermee kunt bereiken (zie bijvoorbeeld CUDA). Het zal voor nVidia niet heel lastig zijn om hun shader hardware nog meer open te gooien zodat je er gewoon een rasterizer mee kunt maken (dus zelf triangle setup en interpolation e.d. doen).

[The Flying Dutchman]

Cyphax schreef op dinsdag 12 augustus 2008 @ 13:45:
Het gaat me niet zozeer om het technische aspect, ik geloof wel dat je met OpenGL genoeg kan, maar meer de onvrede die het oplevert bij developers die nu OpenGL laten voor wat het is hierom, en de negatieve marketing die daarbij komt kijken.

Het levert zeker onvrede op, maar een hoop ontwikkelaars hebben gewoon geen keuze. Ze moeten wel OpenGL gebruiken (omdat ze bijvoorbeeld voor Linux of voor de Mac ontwikkelen). Daarnaast maakt OpenGL 3.0 wel DirectX 10 functies beschikbaar voor Windows XP. Dit kan natuurlijk ook nog een reden zijn om OpenGL te ontwikkelen. Khronos vraagt nu wel om feedback, maar velen vinden dat ze dit in januari hadden moeten doen, toen de beslissing werd genomen om eerst nieuwe functionaliteit toe te voegen, in plaats van het herschrijven van de api, niet nu OpenGL 3 gereleased is.

Dus het levert inderdaad nogal wat onvrede op, ook komt het de publiciteit niet ten goede. Echter denk ik dat die publiciteit er niet heel erg veel toe doet. Developers zijn zelf heel goed in staat om te beoordelen of een api goed bruikbaar is of niet, goeie publiciteit of niet.

.oisyn schreef op dinsdag 12 augustus 2008 @ 13:46:
[...]

Het hoeft natuurlijk ook niet een x86 te zijn om te "software rasterizen". SM 4.0 is al dermate uitgebreid dat je het bijna general purpose cpu's kunt noemen, en de daadwerkelijke hardware is niet gelimiteerd aan wat je met grafische API's ermee kunt bereiken (zie bijvoorbeeld CUDA). Het zal voor nVidia niet heel lastig zijn om hun shader hardware nog meer open te gooien zodat je er gewoon een rasterizer mee kunt maken (dus zelf triangle setup en interpolation e.d. doen).

Daar heb je natuurlijk helemaal gelijk in, maar het zou waarschijnlijk eenvoudiger zijn als je gewoon standaard x86 c++ code voor alle platformen, zonder tussenkomst van Cuda iod zou kunnen schrijven.

[ Voor 24% gewijzigd door The Flying Dutchman op 12-08-2008 13:57 ]

[Cyphax]

The Flying Dutchman schreef op dinsdag 12 augustus 2008 @ 13:55:
Dus het levert inderdaad nogal wat onvrede op, ook komt het de publiciteit niet ten goede. Echter denk ik dat die publiciteit er niet heel erg veel toe doet. Developers zijn zelf heel goed in staat om te beoordelen of een api goed bruikbaar is of niet, goeie publiciteit of niet.

Dat hoop ik dan maar. Ik weet niet of ontwikkelaars zelf die keuze maken, of dat managers die keuze maken voor ze en of die managers in dat geval vatbaarder zijn voor bijv. marketing vanuit Microsoft + het feit dat Microsoft met Dx gewoon een goed product biedt en OpenGL nu niet echt een stap zet die dat hun concurrentiepositie versterkt? Maargoed, ik weet het ook niet, ik vrees er alleen een beetje voor.

[D-Raven]

Ze hadden nooit de weg van de minste weerstand moeten volgen. In plaats van het luisteren naar het gezwam over de CAD codebase hadden ze moeten kijken naar wat het beste voor de toekomst van OpenGL is. En dat is duidelijk niet wat ze momenteel doen.
Als ze gewoon door waren gegaan met wat ze beloofd hadden wat waren de gevolgen dan geweest? Dat de CAD codebase niet mee zou updaten? Nou boeiend hoor

Ik weet niet of de CAD codebase de grootste gebruiker is van OpenGL maar ik kan het me moeilijk voorstellen. Als dat wel zo is dan zou er nog iets voor te zeggen kunnen zijn. Maar dan nog...

[The Flying Dutchman]

Op de gamedev en opengl forums is iemand die roept dat het niet de CAD developers zijn die de nieuwe api tegengehouden hebben. Maar dat een Khronos member die een groot belang heeft in mobiele apparaten (Apple? Nokia? Ik weet niet of ieder member van Khronos iets te zeggen heeft over OpenGL, vast niet, maar Apple in ieder geval wel) graag wil dat OpenGL ES en OpenGL 3.0 meer op elkaar gaan lijken (OpenGL 3.0 zonder alle depricated functies schijnt vrij veel op OpenGL ES te lijken). Ik neem aan, zodat er meer applicaties beschikbaar zullen komen voor mobiele apparaten.

edit:
Die persoon doelde dus op AMD. Nou, dat lijkt me wat sterk eerlijk gezegd en wat ver gezocht.

[ Voor 8% gewijzigd door The Flying Dutchman op 13-08-2008 10:24 ]

[The Flying Dutchman]

OpenGL 3.1 binnen 6 maanden?
http://www.theregister.co.uk/2008/08/13/opengl_firestorm/
(het blijft the register natuurlijk, maar ik geloof wel dat Khronos in ieder geval binnen een jaar met een update komt, wie weet zelfs binnen 6 maanden)

Als je een algemene indruk wilt krijgen van de sfeer op de opengl forums, maar geen zin hebt om dat ellenlange topic door te lezen kun je ook bovenstaande artikel even lezen, dat geeft een goede indruk.

Toevoeging
Na het twee dagen de boel een beetje te laten bezinken kan ik wel de voordelen van OpenGL 3.0 inzien. Ja, het is ontzettend jammer dat de moderne api er niet is, maar de voordelen die er wel zijn:

• Door het deprication model en het kiezen van een forward-compatible profiel is het nu eenvoudiger om te zien wat 'the fast path' is (welke code moet je kiezen om goede performance te krijgen).
• Doordat veel nieuwe features in de core zijn opgenomen zal het gemakkelijker worden om nieuwe technieken te gebruiken in OpenGL. Je bent niet meer zo afhankelijk van allerlei extensies die door verschillende hardware fabrikanten op verschillende manieren geimplementeerd zijn.

Voorwaarden waaraan nog niet voldaan is om deze positieve punten geldig te maken zijn:

• Goede driver support van zowel AMD als nVidia en liefst ook Intel (maar dat laatste kun je waarschijnlijk vergeten).
• Maak een spec beschikbaar waarin alle depricated functies verwijderd zijn, zodat het eenvoudiger wordt om de spec te lezen en in het forward-compatible profiel te programmeren.

Minpunten:

• Geometry shaders zitten nog niet in de core, maar moeten via een extensie benaderd worden. In de opengl forums is men ervan overtuigd dat AMD dit niet zal ondersteunen. We moeten maar afwachten.

Als Khronos binnen 6 tot 12 maanden OpenGL 3.1 kan uitbrengen waarin de depricated functies inderdaad verdwenen zijn en waarin nog wat meer nieuwe functies in de core opgenomen zijn, dan is er een redelijk schone api waarin de nieuwste technieken standaard ondersteunt worden. Het enige grote minpunt dat dan nog overblijft, is dat de api nog steeds relatief ouderwets is. Dat laatste kan ik op zich wel mee leven.

[ Voor 66% gewijzigd door The Flying Dutchman op 13-08-2008 13:13 ]

[Verwijderd]

The Flying Dutchman schreef op woensdag 13 augustus 2008 @ 12:57:
Voorwaarden waaraan nog niet voldaan is om deze positieve punten geldig te maken zijn:
[list]
• Goede driver support van zowel AMD als nVidia en liefst ook Intel (maar dat laatste kun je waarschijnlijk vergeten).

Say what? Intel is juist onwijs bezig met hun videodrivers. Ze zijn de enige die met X.org samenwerken, en de enige die gewoon een opensource driver uitbrengen. Ik denk juist dat Intel heel snel zal zijn met OGL3.0-support.

Als OpenGL3.1 trouwens echt binnen 6 maanden komt, dan heeft het niet zoveel zin voor de hardwarebouwers om OGL 3.0 drivers uit te brengen. Men kan gewoon werken aan het forward-compatible gedeelte van de driver, en dan over 6 maanden de wijzigingen implementeren, en binnen een maand erna een 3.1 driver releasen.

[.oisyn]

Na meerdere posts van je te hebben gelezen moet ik dit toch even kwijt

The Flying Dutchman schreef op woensdag 13 augustus 2008 @ 12:57:
deprication

Het is deprecation

[Cyphax]

The Flying Dutchman schreef op woensdag 13 augustus 2008 @ 12:57:
OpenGL 3.1 binnen 6 maanden?

Zou mooi zijn, maar de grootste gemaakte fout is een api beloven, dan na flink uitstel iets anders dan beloofd opleveren. Als ze die beslissing gemaakt hadden en dat gelijk naar buiten hadden gecommuniceerd, dan was het niet zo'n teleurstelling geweest.
Maargoed, van fouten kun je leren, hopelijk doen ze dat daar ook.

[The Flying Dutchman]

.oisyn schreef op woensdag 13 augustus 2008 @ 14:08:
Na meerdere posts van je te hebben gelezen moet ik dit toch even kwijt

[...]

Het is deprecation

Goed punt, zal daar eens op letten.

Verwijderd schreef op woensdag 13 augustus 2008 @ 13:52:
[...]

Say what? Intel is juist onwijs bezig met hun videodrivers. Ze zijn de enige die met X.org samenwerken, en de enige die gewoon een opensource driver uitbrengen. Ik denk juist dat Intel heel snel zal zijn met OGL3.0-support.

Eerlijk gezegd heb ik zelf geen ervaring met Intel drivers, maar overal waar ik lees klagen mensen steen en been over de slechte support van Intel op OpenGL vlak. Overigens: voordat DirectX functies goed en wel geimplementeerd waren in Intel drivers ging ook nogal een tijd overheen toch?

Cyphax schreef op woensdag 13 augustus 2008 @ 14:13:
[...]

Zou mooi zijn, maar de grootste gemaakte fout is een api beloven, dan na flink uitstel iets anders dan beloofd opleveren. Als ze die beslissing gemaakt hadden en dat gelijk naar buiten hadden gecommuniceerd, dan was het niet zo'n teleurstelling geweest.
Maargoed, van fouten kun je leren, hopelijk doen ze dat daar ook.

Daar heb je helemaal gelijk in en dat zal de community niet snel vergeten. Voor een deel zal het ondertussen zelfs al wel te laat zijn (die zijn overgestapt naar DirectX).

[Stukfruit]

The Flying Dutchman schreef op donderdag 24 juli 2008 @ 12:06:
Dit probleem herken ik persoonlijk niet. Toegegeven ik ben een (in mijn eigen ogen) beginnend OpenGL programmeur (heb de Superbible door gewerkt, daarnaast heb ik een paar redelijk geavanceerde gpgpu programma's geschreven waarvan één OpenGL/GLSL om vortex detection te doen en de ander OpenGL/Cg die fluid simulation deed. Daarnaast ben ik bezig geweest met een eigen 3d bestandsformaat, met exporter vanuit Blender en een OpenGL viewer), maar ik vind Glew fijn werken. Het enige wat je doet is een functie aanroepen om te checken of OpenGL 2.0 ondersteunt wordt en glew initialiseren. Ik doe niets met variabelen definieren of macro's gebruiken en het werkt prima.

Zoals ik al aangaf, als je gewoon een spel(letje) oid maakt heb je er inderdaad geen last van omdat je dan meestal maar een enkel venster hebt

The Flying Dutchman schreef op woensdag 13 augustus 2008 @ 19:21:
Daar heb je helemaal gelijk in en dat zal de community niet snel vergeten. Voor een deel zal het ondertussen zelfs al wel te laat zijn (die zijn overgestapt naar DirectX).

Dat is het inderdaad. Ik ben dan niet de belangrijkste "klant", maar iedere (amateur/pro)ontwikkelaar die OpenGL verlaat is er een.

Laten ze eerst hun zooitje maar eens op orde krijgen. Hoe Khronos met de gebruikers van hun zwaar verouderde API, die door de honderden extensies met dunne draadjes aan elkaar hangt, is omgegaan is gewoon schandalig.

[PrisonerOfPain]

Verwijderd schreef op woensdag 13 augustus 2008 @ 13:52:
[...]

Say what? Intel is juist onwijs bezig met hun videodrivers. Ze zijn de enige die met X.org samenwerken, en de enige die gewoon een opensource driver uitbrengen. Ik denk juist dat Intel heel snel zal zijn met OGL3.0-support.

In mijn ervaring is de opengl ondersteuning van Intel inderdaad ronduit bagger; er word maar een handje van de ARB_ extensies ondersteund (er worden überhaupt maar weinig extensies ondersteund), de performance is slecht en de shader limieten onacceptabel. Daarbij moet dan wel gezegd worden dat ik niet weet of dat dit niet ook het geval is onder DirectX.

[MOmax]

Leesvoer "Autodesk Inventor OpenGL to DirectX Evolution"

Bestaande URL verwijst naar een PDF met een vijf pagina's lang antwoord (!) op een forumvraag over OpenGL/DirectX ondersteuning van Autodesk Inventor. Inventor is een 3D CAD-programma dat zowel gebruik kan maken van OpenGL als DirectX bibliotheken (en is daarmee redelijk uniek - de meeste CAD programma's gebruiken OpenGL om historische redenen).

Uit het artikel:

At Autodesk, we could not agree more with this effort and we have been a major supporter of the position that Microsoft has taken for Direct3D as the Windows platform graphics HW API. We have tried for over 10 years to work with graphics HW vendors to achieve this sort of definition and specification with OpenGL but have failed, primarily because OpenGL by definition is designed to allow for “differentiation” so the products from every graphics HW vendor and of each generation of graphics HW can arrive at a different answer in terms of what you see on your screen. While this may be ideal for games and encouraging you to purchase specific graphics HW to have the best experience with a game, this is completely opposite to the requirements for high precision CAD applications and it is highly ironic that OpenGL is considered a “professional” graphics API given the complete lack of any enforcement of rigorous conformance and accuracy specifications. In fact, every major CAD product at Autodesk relies on a SW graphics pipeline for QA of the product because OpenGL HW will not meet the rigor required for QA of professional CAD products.

Autodesk pleit sterk voor het gebruik van DirectX boven OpenGL in het geval van hun CAD-oplossingen om drie redenen:
- het debuggen van grafische fouten is veel eenvoudiger (omdat WHQL certificatie betrouwbaar is, zijn door gebruikers gemelde fouten altijd te herleiden op fouten in de Autodesk source. In het geval van OpenGL kan het zowel een fout zijn van Autodesk programmeurs als van OpenGL programmeurs. Nu al hanteert Autodesk 44 OpenGL workarounds om deze bugs van OpenGL te omzeilen).
- gebruikers van DirectX programmatuur hoeven geen dure gecertificeerde Quadro c.q. FireGL kaarten te kopen (scheelt ettelijke 100-den euris per werkplek)
- OpenGL 2.1/3.0 is verouderde technologie tov DirectX9/10. Vooral omdat OpenGL in veel te grote mate backward compatible wenst te zijn.

Edit: typo's

[roy-t]

MOmax schreef op donderdag 04 september 2008 @ 14:47:
Leesvoer "Autodesk Inventor OpenGL to DirectX Evolution"

Bestaande URl verwijst naar een PDF met een vijf pagina's lang antwoord (!) op een forumvraag over OpenGL/DirectX ondersteuning van Autodesk Inventor. Inventor is een 3D CAD-programma dat zowel gebruik Kan maken van OpenGL als DirectX bibliotheken (en is daarmee redelijk uniek - de meeste CAD programma's gebruiken OpenGL om historische redenen).

Uit het artikel:

[...]


Autodesk pleit sterk voor het gebruik van DirectX boven OpenGL in het geval van hun CAD-oplossingen om drie redenen:
- het debuggen van grafische fouten is veel eenvoudiger (omdat WHQL certificatie betrouwbaar is, zijn door gebruikers gemelde fouten altijd te herleiden op fouten in de Autodesk source in het geval van OpenGL kan zowel een fout zijn van Autodesk programmeurs als van OpenGL programmeurs - nu al hanteert Autodesk 44 OpenGL workarounds om deze bugs van OpenGL te omzeilen).
- gebruikers van DirectX programmatuur hoeven geen dure gecertificeerde Quadro c.q. FireGL kaarten te kopen (scheelt ettelijke 100-den euris per werkplek)
- OpenGL 2.1/3.0 is verouderde technologie tov DirectX9/10. Vooral om OpenGL in veel te grote mate backward compatible wenst te zijn.

Toch interessant dat een vermoedelijke voorstander van weinig vernieuwing in OpenGL nu juist hardstikke hard plijt voor de MS/DX aanpak. Ze hebben imho ook gelijk op al hun punten. Voor professioneel werk moet alles er overal exact het zelfde uitzien zelfs bij andere hardware.

Opvallend dat er fixes nodig zijn op OpenGL te gebruiken in cat, ik vraag me af hoeveel in DirectX?

[_js_]

roy-t schreef op donderdag 04 september 2008 @ 15:42:
[...]


Toch interessant dat een vermoedelijke voorstander van weinig vernieuwing in OpenGL nu juist hartstikke hard pleit voor de MS/DX aanpak. Ze hebben imho ook gelijk op al hun punten. Voor professioneel werk moet alles er overal exact hetzelfde uitzien, zelfs bij andere hardware.

Opvallend dat er fixes nodig zijn op OpenGL te gebruiken in cat, ik vraag me af hoeveel in DirectX?

Geen volgens het artikel. Ze zijn een keer een fout in een driver tegengekomen, die hebben ze aan Microsoft gemeld, en die zorgt er nu voor dat er bij WHQL op gecontroleerd wordt.

[.oisyn]

Wat niet wil zeggen dat er geen fouten inzitten. Een fix is er ook niet direct, dus je zult je software wel shippen met een aantal workarounds. Maar DirectX updates zijn er wel veel meer dan OpenGL updates, en je hebt er een soepele organisator achter zitten.

[roy-t]

.oisyn schreef op donderdag 04 september 2008 @ 20:43:
Wat niet wil zeggen dat er geen fouten inzitten. Een fix is er ook niet direct, dus je zult je software wel shippen met een aantal workarounds. Maar DirectX updates zijn er wel veel meer dan OpenGL updates, en je hebt er een soepele organisator achter zitten.

Het blijft toch knap hoe MS dit toch altijd voor elkaar krijgt, MS is een ontzettend groot bedrijf, maar zoals jij (als kenner ivm je vele werkt met DX) aangeeft is Microsoft erg soepel en snel.

Iets wat normaal juist bij OpenSource geplaatst wordt (wat ziw OpenGL ook is).

Ik ben trouwens erg benieuwd of OpenGL 3 toch opgepakt gaat worden of dat het nu over is voor OpenGL.

Verder vraag ik me af of Intel's larrabee mogelijk OpenGL helemaal gaat ondersteunen. Dit zou een opkikker kunnen zijn voor OpenGL.

[Stukfruit]

Alleen een aantal implementaties van OpenGL zijn Open Source vziw. Die van SGI en MesaGL.

De specs daarentegen...

Er is volgens mij maar een mogelijkheid om uit deze shit te komen en dat is dat alle vendors hun specs vrijgeven, zodat er een echte Open Source API kan komen die de boel aanstuurt, net zoals bv. de Linux kernel voor de normale processors.

Maar ik geloof dat pinguins eerder zullen leren vliegen dan dat ooit zal gebeuren.

[roy-t]

Stukfruit schreef op woensdag 10 september 2008 @ 18:46:
Alleen een aantal implementaties van OpenGL zijn Open Source vziw. Die van SGI en MesaGL.

De specs daarentegen...

Er is volgens mij maar een mogelijkheid om uit deze shit te komen en dat is dat alle vendors hun specs vrijgeven, zodat er een echte Open Source API kan komen die de boel aanstuurt, net zoals bv. de Linux kernel voor de normale processors.

Maar ik geloof dat pinguins eerder zullen leren vliegen dan dat ooit zal gebeuren.

Misschien dat vanuit de Linux kernel er een nieuwe Open-OpenGL beweging komt omdat zij niet over kunnen stappen op DirectX (tenzij MS dat vrij geeft, maar dat zie ik niet zomaar gebeuren) en omdat ze misschien niet al te blij zijn met OpenGL zoals het er nu voor staat. Misschien dat het vanuit de WindowManager hoek komt omdat zij ook steeds meer eisen van een videokaart.

[roy-t]

http://www.tomshardware.com/reviews/opengl-directx,2019.html

Interessant artikel op tomshardware over DirectX11 en OpenGL3

(en een beetje sensatie dat OpenGL3 verliest enzo)

Verder zitten er wel erg coole features in DX11. Zoals interfaces en classes voor SM5

But with Direct3Ddirect3d 11, it’s now possible to make your code much more legible by using a derived interface and classes:

Light myLight; Material myMaterial; Render() myMaterial.render (); myLight.shade ();

Light and Material are interfaces, and the code is contained in the derived classes OmniLight and SpotLight, PlasticMaterial and MetalMaterial. So the code is all in a single place, which makes bug correction easier. At the same time, legibility doesn’t suffer thanks to the organization of the code, which resembles the concept of virtual functions in object-oriented languages. This feature will be welcomed by programmers, but won’t have any real impact for gamers.

Ook is de maximale texture size nu een stuk groter (van 4kx4k naar 16kx16k), Maar of dat al nuttig is.

[ Voor 72% gewijzigd door roy-t op 18-09-2008 20:56 ]

[.oisyn]

Leuk artikel .

Thanks to tessellation, it becomes possible to do without the normal map and implement a level of detail directly on the GPU, allowing the use of very detailed models (several million polygons instead of 10,000 or so with current games)—at least in theory. In practice, tessellation raises some problems that have kept the technique from taking off so far. Can Direct3D 11 and compatible cards avoid these pitfalls and come up with a functional version? It’s too early to say, but in any event not everybody is convinced

Nee, duh. Bezier patches zijn leuk voor curved surfaces, niet voor ogenschijnlijk ongeordende height maps zoals steen oid. Normal maps zijn een goedkope manier om detail aan te brengen in een materiaal zonder daar relatief dure geometrie voor te gebruiken. Met bezier patches los je dat echt niet op. Het is eigenlijk net een beetje als de hype met dynamic lighting destijds. 't Is cool dat per pixel lighting ineens kan, maar voor het overall plaatje gebruik je nog altijd oude technieken om het beeld te verfijnen. Realtime global illumination is nog altijd vrij ondoenlijk, dus daar gebruik je gewoon gegenereerde light/shadow/ambient maps voor.

[Janoz]

(Realtime) 3d render engine schrijven is net als goochelen. Of je nu daadwerkelijk een duif uit het niets haalt, of dat je de illusie weet te wekken dat je deze uit het niets haalt maakt voor het publiek niet uit.

[Jogai]

OpenGL is dood:
http://www.tojiart.com/OpenGL/

Is het niet eens tijd voor een nieuwe variant met de volgende eigenschappen:
- open
- mooier / beter / sneller
- makkelijk te gebruiken dan DX/OGL

[Stukfruit]

Ach ja, dromen kan altijd

Er is trouwens nog wel een initiatief dat bekend staat als Gallium3D, maar naast de afschrikwekkende naam lijkt dat meer een wrapper rond bestaande API's te zijn lees je verder wat hieronder gezegd wordt. Geen idee wat ze daar verder mee willen doen maar ik geef het weinig kans.

Tot nu toe ben ik iig erg blij met m'n overstap naar D3D. Het is lang niet zo vreselijk meer als het ooit was en op veel punten een stuk beter geworden dan OGL. Ik mis eigenlijk alleen de mogelijkheid om snel debugdingetjes te kunnen renderen met alleen een globale kleur, maar goed.. je kan niet alles hebben, of misschien moet ik wel gewoon wat beter de documentatie lezen

Het is alleen even wennen met al die interfaces.

[ Voor 3% gewijzigd door Stukfruit op 24-09-2008 19:11 ]

[roy-t]

Jogai schreef op woensdag 24 september 2008 @ 16:34:
OpenGL is dood:
http://www.tojiart.com/OpenGL/

Is het niet eens tijd voor een nieuwe variant met de volgende eigenschappen:
- open
- mooier / beter / sneller
- makkelijk te gebruiken dan DX/OGL

(Managed) DirectX is al heel makkelijk te gebruiken vind ik .

Ohwell ik hoop dat er een nieuwe sterke standaard komt voor 3D onder linux e.d. Een soort OO, OS D3D

[Verwijderd]

Gallium3D is een onderdeel van de - hevig in ontwikkeling zijnde - Mesa / X.org / (opensource) GPU drivers verzameling. Het is geen nieuwe API, maar een nieuw drivermodel. Dat is niet zozeer een technisch verschil, maar het geeft aan hoe low-level het is.

Deze ontwikkelingen zouden overigens best weleens voor een flinke performanceboost kunnen zorgen op de Unix-platformen.

Ik blijf voorlopig wel met OGL prutsen. Ik kan ook moeilijk anders, tenzij iemand zo gek is om Direct3D op Gallium3D te implementeren. En alle nadelen van OGL ten spijt, het blijft vertrouwd.

[Verwijderd]

OpenGL ook, dus dat scheelt

spam is niet toegestaan

[ Voor 71% gewijzigd door moto-moi op 25-09-2008 09:09 ]

[beany]

Jogai schreef op woensdag 24 september 2008 @ 16:34:
OpenGL is dood:
http://www.tojiart.com/OpenGL/

Is het niet eens tijd voor een nieuwe variant met de volgende eigenschappen:
- open
- mooier / beter / sneller
- makkelijk te gebruiken dan DX/OGL

Wikipedia: Larrabee (GPU)

Of het makkelijker zal zijn, geen idee. Maar ik las in een interview dat het rechtstreeks programmeren in Larrabee mogelijk zou zijn, buiten DX en OGL om. Dit zou enorme voordelen met zich meebrengen. Weet alleen niet meer waar ik het heb gelezen, kan geen linkje plaatsen. Zal nog ff zoeken.

[Jogai]

Ja omdat dat gewoon met x86 technologie kan. Maar een echte Graphic Language is wel iets anders.
Utopie:
Nieuwe open taal wordt ontwikkeld met bovenstaande eisen. Het wordt goed opgepakt door gameproducenten (omdat het makkelijker en beter is). Er word goede ondersteuning voor gemaakt door de vga fabrikanten. Er worden open drivers ontwikkeld (goede 3d prestaties op linux).