[C# / OpenGL] Een goed begin met coderen.

[xTmPizzaMan]

Ik heb al veel GoT forums doorgelezen over de onderwerpen OpenGL en DirectX en C# programeren, maar ik komer nog steeds niet uit. Er is iets wat ontbreekt in de uitleg. Ik heb inmiddels al gekozen voor een programeer taal en tussen DirectX en OpenGL gekozen. Het is OpenGL geworden. Mijn uiteindelijke doel is om een simpel spelletje te maken (2d of 1d). Ik was er ooit 3 jaar geleden mee begonnen en het ging behoorlijk goed met leren. Maar ik zag dat ik niet voldoende kennis en tijd had. Nu heb ik alle tijd en kan aan het leren. Ik beheers de C# code al aardig dus dat hoeft geen probleem te worden. Na uren op het internet te zoeken naar turtorials over de topic OpenGl en C# kon ik amper handige sites vinden. Ik vraag bij deze daarom jullie hulp.

Mijn vragen zijn:
- Heb ik alles om met opengl te programeren (zo niet waar kan ik het downloaden en misschien nog een linkje met de uitleg hoe je het moet instaleren.).
- Is er een site die me uitlegt hoe ik een begin maak met het coderen in OpenGL?

Mijn platform en software zijn:
- Microsoft Visual C# 2005 express Beta
- .NET Framework SDK 2.0
- Windows XP platform.

Verder heb ik geen andere SDK's of software gedownload.

[.oisyn]

Ik weet dat je de keuze al hebt gemaakt, maar als je C# gebruikt, waarom dan een native API als OpenGL die je niet zo out-of-the-box kunt aanspreken vanuit een managed omgeving? Je bent dan afhankelijk van 3rd party vendors die de interface van OpenGL in .Net toegankelijk moeten maken. Waarom dan niet gewoon managed DirectX, dat wél out-of-the-box werkt in .Net?

(Waar is je keuze tussen OpenGL en DirectX überhaupt op gebaseerd? Want zelfs in C++ zou ik DirectX aanraden wegens betere documentatie en toegankelijkheid)

[ Voor 19% gewijzigd door .oisyn op 10-08-2005 17:49 ]

[Ansur]

Ik denk dat je, wegens je taalkeuze, beter met DirectX begint. Hier zal je voldoende informatie over vinden op het net (tutorials, code examples) tov. OpenGL en C#.

Alhoewel OpenGL voor C# bestaat, is OpenGL toch meer voor C++ bedoeld. Enkel met een wrapper vind je het voor C#

[martennis]

ik heb vorig jaar (min of meer per ongeluk) een boek besteld dat aandacht besteedt aan games programmeren (in windows) in C++.

het boek heet Games Programmeren in 24 Uur

OpenGL of DirectX zijn hierin niet aan de orde, maar het is wel een leuk/goed boek om zonder DirectX of OpenGL een begin te maken in het maken van 2d-games.

Ik heb het boek zelf nog niet doorgenomen, omdat ik had verwacht dat het boek voor Java zou zijn. Pech voor mij dus; maar volgend jaar heb ik meer tijd etc om me te kunnen verdiepen in de wereld van C++.

[Woy]

xTmPizzaMan schreef op woensdag 10 augustus 2005 @ 17:39:
simpel spelletje te maken (2d of 1d).

offtopic:
Hoe zie jij een 1d spelletje voor je

[xTmPizzaMan]

rwb schreef op woensdag 10 augustus 2005 @ 18:27:
[...]

offtopic:
Hoe zie jij een 1d spelletje voor je

rofl foutje

Maar goed, ik heb vroeger ook met C++ gewerkt , ik zou ook zonder problemen over kunnen stappen naar C++.


Mijn keuze is gebaseerd op een paar artiekelen die ik heb gelezen (die op deze forums en op gamedev.net ) waar in stond dat DirectX te langdradig was om te configureren en om je eerste beeldje op het beeldscherm te laten verschijnen.
Dit leek me neit erg maar daarom concludeerde ik dat OpenGL een makkelijkere manier was om mee te beginnen. Eigenlijk wil ik gewoon de basis van het grafisch programeren leren voor leuke 3d / 2d applets of andere dingen.

raden jullie me aan om naar C++ over te stappen? en zo ja, wat is dan het gemakkelijkste om te leren DirectX of OpenGL?

[ Voor 3% gewijzigd door xTmPizzaMan op 10-08-2005 19:09 ]

[whoami]

Ik zie hier nergens staan dat er aangeraden wordt om het in C++ te doen. Volgens mij maakt dat helemaal niet zoveel uit.

Er wordt wel aangeraden om DirectX te gebruiken ipv OpenGL, omdat dit makkelijker te gebruiken is binnen C#

[xTmPizzaMan]

Mijn vraag was meer of ik beter van programeertaal kon wisselen (OpenGl en C++ ) of ik C# kan behouden en DirectX.

Ik ben er namelijk heel erg lang uit de C wereld geweest en ben vooral bezig geweest met PHP, java. Dus ik heb geen enkel idee wat me eigenlijk nu nog te wachten stond.

[Janoz]

Een goed OpenGL startpunt met voorbeeldcode (in meerdere talen) is http://nehe.gamedev.net

[Woy]

Je kan best C# gebruiken als je een simpel 3d/2d spel wil maken. Managed Directx is volgens mij ook redelijk goed gedocumenteerd en anders kan je altijd nog terug vallen op de c++ documentatie aangezien het erg veel op elkaar lijkt op wat geheugen toestanden na.

Voor grote/zware spellen is c++ waarschijnlijk wel meer geschikt aangezien je veel meer controle over je systeem hebt. Maar zeker als je gewoon een simpel spelletje wilt maken kan je best uit de voeten met C# en Managed DirextX

[xTmPizzaMan]

dank je wel ik ga gewoon met C# beginnen en DirectX.

Heb ik hiervoor de DirectX SKD nodig?
en kan ik dan gewoon beginnen?

[JayVee]

Janoz schreef op woensdag 10 augustus 2005 @ 19:19:
Een goed OpenGL startpunt met voorbeeldcode (in meerdere talen) is http://nehe.gamedev.net

Deze heb ik ook gebruikt. Hoef je je ook geen zorgen te maken over het openen van een window.

[Woy]

Je hebt idd wel de DirectX SDK nodig met de managed extensions

[Hydra]

rwb schreef op woensdag 10 augustus 2005 @ 19:55:
Je kan best C# gebruiken als je een simpel 3d/2d spel wil maken. Managed Directx is volgens mij ook redelijk goed gedocumenteerd en anders kan je altijd nog terug vallen op de c++ documentatie aangezien het erg veel op elkaar lijkt op wat geheugen toestanden na.

Ik heb ook het e.e.a. in Managed DirectX gedaan, en het is geen enkel probleem daar mee te beginnen. Je moet misschien iets meer setup doen, maar dat hoeft ook maar een keer.

Ik heb ook wat zitten knutselen met C# en OpenGL, maar IMHO was het grootste nadeel van de OpenGL wrappers voor .Net dat het gewoon 1 op 1 wrappers waren, niks OO dus, en dat vond ik nogal vervelend programmeren.

[Verwijderd]

Let er wel op als je je programma wilt testen op een andere pc, je de managed directX extensions ook op die pc moet installeren (niet de SDK dus).
Die zitten niet standaard in de .NET redistributable. Niet dat het veel moeite kost (paar keer klikken en je bent klaar).

[.oisyn]

Op flipcode was onlangs een OpenGL vs D3D thread waar wel goede argumenten instaan voor en tegen beide API's.

Bottom line is IMHO dat D3D betere documentatie en betere tools heeft, en dat setup echt niet lastiger is dan in OpenGL. Het enige wat het mist is een immediate mode (OpenGL's glVertes() & co), maar dat is makkelijk zelf te implementeren. OpenGL heeft echter geen manieren om direct textures en meshes te laden van disk, en vertex en matrix classes, en dat soort dingen, en daar verkijken veel mensen zich op

[Zoijar]

.oisyn schreef op donderdag 11 augustus 2005 @ 12:41:
Op flipcode was onlangs een OpenGL vs D3D thread waar wel goede argumenten instaan voor en tegen beide API's.

Bottom line is IMHO dat D3D betere documentatie en betere tools heeft, en dat setup echt niet lastiger is dan in OpenGL. Het enige wat het mist is een immediate mode (OpenGL's glVertes() & co), maar dat is makkelijk zelf te implementeren. OpenGL heeft echter geen manieren om direct textures en meshes te laden van disk, en vertex en matrix classes, en dat soort dingen, en daar verkijken veel mensen zich op

Daarentegen heeft opengl wel weer een build in shading language. Verder zijn extensions geen probleem met 'glew'. Als je per se matrix en vector classes etc wilt, gebruik er dan Blitz++ bij En als je software in unix omgevingen moet draaien is opengl een must. Ook is er best wel veel documentatie. De standaard boeken, de extensions guide, glsl boek, en zelfs nog de opengl specificatie zelf voor de details. Maar ik denk ook dat het ongeveer dezelfde moelijkheidsgraad heeft als directx... niet veel verschil eigenlijk, zo vaak schrijf je nou ook weer geen render code.

[.oisyn]

Zoijar schreef op donderdag 11 augustus 2005 @ 13:30:
[...]

Daarentegen heeft opengl wel weer een build in shading language.

DX ook

Verder zijn extensions geen probleem met 'glew'. Als je per se matrix en vector classes etc wilt, gebruik er dan Blitz++ bij

Euh ja, ik had het dus over out-of-the-box. Als je het over 3rd party tools gaat hebben kun je natuurlijk ook net zo goed meteen een 3d engine gebruiken ipv een 3d api . En het is ook wel een nadeel om al dat soort dingen er zelf bij te moeten zoeken, het wordt zo'n onsamenhangend geheel.

En als je software in unix omgevingen moet draaien is opengl een must.

Uiteraard, maar daar gaat het hier niet over

Ook is er best wel veel documentatie. [boeken]

Boeken zijn leuk leermateriaal maar geen goed referentiemateriaal. Ik prefereer API documentatie in electronische vorm waar je makkelijk in kunt zoeken, dat snap je zelf natuurlijk ook wel

en zelfs nog de opengl specificatie zelf voor de details.

Volgens mij bespreekt die niet de vendor-specific extensions, en daar zijn er nogal veel van.

[ Voor 6% gewijzigd door .oisyn op 11-08-2005 13:38 ]

[Zoijar]

.oisyn schreef op donderdag 11 augustus 2005 @ 13:36:
[...]
DX ook

Bij directx moet je toch appart je shaders compilen etc. En daarna nog al je variabelen en constanten zetten met API calls? Bij GLSL compiled en linked je opengl driver het lokaal voor jouw kaart (zoals bij cg) en is de opengl state beschikbaar binnen shaders. Je hoeft dus niet eerst allemaal variabelen te zetten, maar je hebt gewoon gl_Lights[n], gl_ModelViewMatrix, gl_Normal, gl_Position, etc. ter beschikking.

Euh ja, ik had het dus over out-of-the-box. Als je het over 3rd party tools gaat hebben kun je natuurlijk ook net zo goed meteen een 3d engine gebruiken ipv een 3d api . En het is ook wel een nadeel om al dat soort dingen er zelf bij te moeten zoeken, het wordt zo'n onsamenhangend geheel.

Ja ok, directx is idd een beter geheel. Je kan een boek over directx programmeren pakken, en dan heb je alles. Dat is wel erg handig.

Uiteraard, maar daar gaat het hier niet over

Nou, het lijkt me wel een belangrijk iets voor je keuze tussen de twee. Voor mij bv is dat de rede om opengl te gebruiken, anders zou ik misschien ook wel op directx overstappen.

Boeken zijn leuk leermateriaal maar geen goed referentiemateriaal. Ik prefereer API documentatie in electronische vorm waar je makkelijk in kunt zoeken, dat snap je zelf natuurlijk ook wel

Dat heb je toch ook vollop beschikbaar? MSDN heeft zelfs een opengl API reference. Verder heb je de 2.0 specificatie van zowel opengl als glsl, daar staat _alles_ tot op detail in.

Volgens mij bespreekt die niet de vendor-specific extensions, en daar zijn er nogal veel van.

Ok. Als je echt specifiek iets wilt, dan zal je even moeten googlen. Hoe doet directx dat dan? Als je een kaart specifieke feature wilt gebruiken? (wat sowieso vaak niet slim is) Als ik accelerated fixed functionality convolutions wil doen bv? (die extensions zijn nu toch overbodig met GLSL, je kan het makkelijker even zelf schrijven. Je kan toch niet fixed en programmable functionaliteit door elkaar gebruiken; dus dan moet je het wel zelf schrijven)

Ik heb het idee dat directX gewoon beter is voor games etc. en opengl beter voor scientific apps. Ik zie een CT scanner console eerder opengl draaien, en een game eerder directx (ik zie een xbox geen opengl draaien). Tegenwoordig zijn beiden volgens mij ongeveer hetzelfde, alleen hebben ze een andere doelgroep.

[ Voor 5% gewijzigd door Zoijar op 11-08-2005 14:35 ]

[.oisyn]

Zoijar schreef op donderdag 11 augustus 2005 @ 14:32:
Bij directx moet je toch appart je shaders compilen etc. En daarna nog al je variabelen en constanten zetten met API calls?

Niet als je het via een ID3DFxFile (oid) doet, maar shaders horen imho gewoonweg niet zelf statechanges te doen, dat past gewoon niet in een optimale rendering pipeline. Daarnaast zet je die states over het algemeen op meshniveau, niet op shaderniveau

Bij GLSL compiled en linked je opengl driver het lokaal voor jouw kaart (zoals bij cg) en is de opengl state beschikbaar binnen shaders. Je hoeft dus niet eerst allemaal variabelen te zetten, maar je hebt gewoon gl_Lights[n], gl_ModelViewMatrix, gl_Normal, gl_Position, etc. ter beschikking.

Ons systeem automatiseerd dat ook, maar ik kan hier wel voordelen in zien ja (ook nadelen overigens, je hebt namelijk geen controle meer over alle constante registers die je tot je beschikking hebt).

Nou, het lijkt me wel een belangrijk iets voor je keuze tussen de twee. Voor mij bv is dat de rede om opengl te gebruiken, anders zou ik misschien ook wel op directx overstappen.

Agreed, maar ik bedoelde dat dat in de draad die ik aanhaalde er niet toe doet (gamedevelopment voor unix is een _erg_ kleine markt en over het algemeen totaal niet interessant), en hier ook niet aangezien de topicstarter overduidelijk onder windows werkt

Dat heb je toch ook vollop beschikbaar? MSDN heeft zelfs een opengl API reference.

1.1 ja, heb je geen zak aan

Verder heb je de 2.0 specificatie van zowel opengl als glsl, daar staat _alles_ tot op detail in.

Ah ok, dat wist ik niet. Althans, ik wist wel dat het in 2.0 een stuk beter geregeld was. Nu nog wachten op de implementatie

Ok. Als je echt specifiek iets wilt, dan zal je even moeten googlen. Hoe doet directx dat dan? Als je een kaart specifieke feature wilt gebruiken? (wat sowieso vaak niet slim is)

Alle features worden exposed door DirectX zelf, er bestaan dus geen "kaart-specifieke" features, alleen features die niet ondersteund worden door bepaalde videokaarten. En waarom zou je die niet moeten gebruiken? Het idee is dat je alternatieve code-paths hebt, en dus niet blindly maar alle features gebruikt

(ik zie een xbox geen opengl draaien).

Da's natuurlijk gewoon een kwestie van een implementatie schrijven (er bestaal wel 3rd party implementaties geloof ik, ook voor de PS2). Wij gebruiken voor onze xbox engine ook geen Direct3D maar spreken direct de hardware aan.

[Zoijar]

.oisyn schreef op donderdag 11 augustus 2005 @ 14:50:
Ons systeem automatiseerd dat ook, maar ik kan hier wel voordelen in zien ja (ook nadelen overigens, je hebt namelijk geen controle meer over alle constante registers die je tot je beschikking hebt).

Dat is waar, ik had het zelf ook al geautomatiseerd voor cg. Ik denk dat iedereen dat doet Maar daarom is het wel handig als het standaard is. Mensen lijken graag iets te willen dat erg op renderman lijkt, en GLSL komt engiszins in de buurt (hoewel ik shader code nog steeds erg primitief vind, maar daar zal wel verandering in komen nog)

Agreed, maar ik bedoelde dat dat in de draad die ik aanhaalde er niet toe doet (gamedevelopment voor unix is een _erg_ kleine markt en over het algemeen totaal niet interessant), en hier ook niet aangezien de topicstarter overduidelijk onder windows werkt

Hehe, ok

Ah ok, dat wist ik niet. Althans, ik wist wel dat het in 2.0 een stuk beter geregeld was. Nu nog wachten op de implementatie

Nvidia heeft sinds kort een werkende 2.0 driver. Het heeft (even) geduurd, maar dan heb je ook wat...

Alle features worden exposed door DirectX zelf, er bestaan dus geen "kaart-specifieke" features, alleen features die niet ondersteund worden door bepaalde videokaarten. En waarom zou je die niet moeten gebruiken? Het idee is dat je alternatieve code-paths hebt, en dus niet blindly maar alle features gebruikt

Da's natuurlijk gewoon een kwestie van een implementatie schrijven (er bestaal wel 3rd party implementaties geloof ik, ook voor de PS2). Wij gebruiken voor onze xbox engine ook geen Direct3D maar spreken direct de hardware aan.

Ah ok. Ik ben niet zo heel erg thuis in directx etc. Ik heb nog steeds nachtmerries van de directx 6 tijd... maar het schijnt nu allemaal een stuk beter geregeld te zijn. Misschien toch eens mee experimenteren. Ik heb overigens niks tegen dx hoor, maar ik vond dat opengl 2.0 toch even genoemd moest worden. Zeker vanwege GLSL.

[.oisyn]

Ik heb nog steeds nachtmerries van de directx 6 tijd...

Eens, ik ben ook pas overgestapt toen versie 8 uitkwam, daarvoor was het idd een pain met z'n execution buffers e.d. en bleef ik liever bij het oh zoveel simpele opengl