Entwickler-Ecke
Multimedia / Grafik - Spieleprogrammierung - OpenGL, DirectX - Tipps?
Jetro - So 09.03.03 17:16
Titel: Spieleprogrammierung - OpenGL, DirectX - Tipps?
Hallo, ich interessiere mich für die Spiele- /Grafikprogrammierung mit DirectX bzw. OpenGL. DelphiX lass ich da jetzt mal raus, da ich schon sehr oft gelesen habe, das es zwar am Anfang Erfolge gibt, man dann aber schnell an Grenzen stößt. Da es aber wie es aussieht im Internet nur grundlegende Tutorials gibt (vor allem zu OGL, zu DirectX direkt habe ich noch nix gefunden), frage ich mal hier.
Was ist besser zum anfangen? OGL oder DX? (Habe gelesen, das OGL am Anfang einfacher zu erlernen ist, DX aber dann im Endeffekt die günstigere Wahl ist)
Wie fange ich an? Gibt es lesenswerte Bücher über diese Themen (auch Englisch)? Oder kennt jemand gute Websites mit Informationen oder guten Tutorials?
[EDIT]
Also hauptsächlich interessieren mich erstmal die Fragen: Wie erstelle ich Objekte mit OGL oder DX, wie kann ich diese (oder die Kamera drumrum) bewegen. Wie binde ich Grafiken/Texturen ein. Wie realisiert man Kollisionsabfragen etc.
Am besten dafür ware natürlich ein Beispielprojekt mit Erklärungen oder kommentierter SourceCode.
[/Edit]
Ja, das wären für's erste meine Fragen :) und ich würde mich über Antworten freuen :)
Ciao :)
Raphael O. - So 09.03.03 19:09
also erst mal stimmt es nicht, dass mit directx mehr möglich ist als mit OGL... siehe dazu Doom 3 ;)
wenn du gute Tuts zu OGL von Anfang an suchst dann geh mal auf
[url]
http://www.delphigl.com[/url](deutsch,sehr gut, mit Forum)
[url]nehe.gamedev.net[/url](englisch, umfangreicher,nicht nur auf Delphi ausgelegt...)
Wenn man sich bei OGL etwas reinhängt, dann gibts da auch schnell Erfolge ;)
DaRkFiRe - So 09.03.03 19:45
Also ich bevorzuge persönlich auch eher OpenGL - da brauch man sich nicht um GUIDs und alles so'n Dreck zu kümmern. DirectX is mir zu schwammig - ich kenne DirectX-Programmierung, da gab's noch Execute-Buffers - man kann zwar froh sein, dass es sie nich mehr gibt, aber D3D kann ich trotzdem (als Programmierer UND Spieler) immer noch nicht leiden...
OregonGhost - So 09.03.03 22:05
| Zitat: |
also erst mal stimmt es nicht, dass mit directx mehr möglich ist als mit OGL...
siehe dazu Doom 3
|
Mit Standard-OpenGL (ohne Extensions) ist Doom 3 sicherlich nicht lauffähig. Davon abgesehen ist weder die HLSL noch die neuere Shaderversion im Standard enthalten. Und ehrlich gesagt, Unreal II sieht genauso aus wie Doom 3 ist aber Direct3D ;c)
(tut mir leid, musste mich als D3D-Verfechter mal zu Wort melden, jetzt aber etwas sachlicher:)
Der wesentliche Unterschied zwischen OpenGL und Direct3D ist, dass ersteres prozedural, letzteres objektorientiert ist, und dass in Direct3D viele Dinge vereinfacht sind, wenn man eine objektorientierte Programmiersprache verwendet (z.B. Matrizen, Vektoren), aber auch sonst (Texturen, Meshes, Effect Files, Textausgabe (2D & 3D) etc.).
Dass OpenGL einfacher zu erlernen ist ist Quatsch, das war zu Zeiten von Direct3D 7 so. Man muss am Anfang in D3D nur ein klein wenig mehr Code schreiben, dank des Komforts sowie D3DX rentiert sich das aber schon, wenn man etwas machen will, was über das Rendern eines Würfels hinausgeht.
Aya - So 09.03.03 22:09
| OregonGhost hat folgendes geschrieben: |
| Zitat: | also erst mal stimmt es nicht, dass mit directx mehr möglich ist als mit OGL...
siehe dazu Doom 3
|
Mit Standard-OpenGL (ohne Extensions) ist Doom 3 sicherlich nicht lauffähig. Davon abgesehen ist weder die HLSL noch die neuere Shaderversion im Standard enthalten. Und ehrlich gesagt, Unreal II sieht genauso aus wie Doom 3 ist aber Direct3D ;c)
(tut mir leid, musste mich als D3D-Verfechter mal zu Wort melden, jetzt aber etwas sachlicher:) |
Mit Standard OpenGL, sicherlich... ja... :)
Aber dann nimm bitte als gegensatz dazu auch Standardt DX, und da währen wir bei Version 1.0, welche du wohl nich wirklich verfechten willst, oder? *grinst fies*
Aber ich würde auch OpenGL empfehlen... Ist aber wohl sowieso fast egal, im endeffekt bekommt man denk ich mal mit beidem alles gleich hin.. *g*
Aber der absolute Vorteil von OGL ist einfach, das es System unabhängig ist. Wohingegen was mit DX gemachtest nur unter Windows läuft ;)
Au'revoir,
Aya
Raphael O. - So 09.03.03 22:15
Ich habe auch nicht behauptet, dass OpenGL besser wäre...
Ich meinte lediglich, dass man mit OpenGL auch alles machen kann, was man auch mit DirectX machen kann...
manches sicherlich umständlicher, aber manches auch einfacher...
ich kenne DirectX nicht wirklich (wie man da programmiert), aber bei OpenGL ist das mit den MAtrizen und Vektoren auch nicht sonderlich schwer...
Und wer schon Delphi proggt der sollte dann auch noch bei dieser Wahl OpenGL nehmen, da DirectX doch immer noch von Microsoft forciert wird usw.
OpenGL kann allerdings immer mithalten, obwohl es in Computerzeitalter schon UrAlt ist, während DirectX alle 2 Wochen (;)) eine neue Version braucht, die dem "Uralten" OpenGL aber trotzdem nicht überlegen ist...
Und bald kommt OpenGL 2 und dann ist die Entscheidung ja wohl eh klar *ggg*
Jetro - So 09.03.03 22:39
Na dann, erstmal anke an alle Schreiberlinge :) Ich werde mich mal noch weiter umhören und gucken ob ich vielleicht ein Buch oder so finde :)
Ciao
OregonGhost - So 09.03.03 23:54
@Aya: Standard = ohne Extensions, also Direct3D 9.0 (inkl. D3DX) vs. OpenGL 1.4 (inkl. GLU)
Übrigens zweifeln selbst einige ARB-Mitglieder, ob OpenGL 2.0 Direct3D 8 (!) übertreffen kann, von Direct3D 9 zu schweigen, aber das nur nebenbei. Im Allgemeinen kann man natürlich mit beiden APIs fast alles machen, aber den Technologietrend gibt im Moment klar Direct3D an. Den Geschmack der meisten Programmierer auch.
Was ich mit Matrizen meinte, ist, dass man unter OpenGL immer 16 floats bekommt, die die Matrix definieren und man Funktionen zu deren Multiplikation etc. aufrufen muss, während man unter Direct3D eine D3DXMATRIX bekommt, die man zum Beispiel direkt multiplizieren kann, dasselbe gilt für Vektoren. Folgendes Beispiel zeigt das ganz gut, in D3D kann man wie mit floats zum Beispiel rechnen:
Quelltext
1:
2:
3:
| D3DXMATRIX Translationsmatrix, RotationsmatrixX, RotationsmatrixY, RotationsmatrixZ, Skalierungsmatrix;
D3DXMATRIX Ansichtsmatrix = Translationsmatrix * RotationsmatrixX * RotationsmatrixY * RotationsmatrixZ * Skalierungsmatrix;
pDevice->SetTransform(D3DTS_VIEW, &Ansichtsmatrix); |
In OpenGL muss man hingegen eine Funktionskolonne hinschreiben, gerade wegen der man eigentlich auf objektorientierte Programmierung umgestiegen ist:
Quelltext
1:
2:
3:
4:
5:
6:
7:
| float Translationsmatrix[16], RotationsmatrixX[16], RotationsmatrixY[16], RotationsmatrixZ[16], Skalierungsmatrix[16];
glMatrixMode(GL_MODELVIEW);
glLoadMatrixf(Translationsmatrix);
glMultMatrixf(RotationsmatrixX);
glMultMatrixf(RotationsmatrixY);
glMultMatrixf(RotationsmatrixZ);
glMultMatrixf(Skalierungsmatrix); |
Macht mehr als doppelt so viele Zeilen für OpenGL.
Selbst das ist natürlich Geschmackssache. Doom 3 wird nur in OpenGL geschrieben, weil John Carmack Direct3D nicht mag. Aber er mag auch objektorientierte Programmierung nicht so gerne. Dafür sind die id-Engines auch so ziemlich die einzigen kommerziell erfolgreichen OpenGL-Produkte (in diesem Punkt bitte ich um Verbesserung, also um weitere kommerziell erfolgreiche OpenGL-Produkte, weil ich kenne keine (c; ).
Was ich mit meinem Posting sagen wollte, ist, dass man sich nicht von vornerein auf eine API festlegen sollte, weil alle sagen, die ist leichter, vor allem solche, die die andere überhaupt nicht ausprobiert haben. Man sollte sich einfach ein paar Quellcodes zu beiden APIs anschauen (gamedev.net) und selbst urteilen, am besten die Grundlagen von beiden erlernen. Umsteigen ist sowieso problemlos möglich (man kann auch prima mit OpenGL anfangen und auf Direct3D umsteigen und umgekehrt), weil die beiden APIs nahezu dieselbe Funktionalität auf ähnliche Weise, nur mit unterschiedlichen Paradigmen zur Verfügung stellen. Zum Beispiel legt man in OpenGL viele Einstellungen mit Extrafunktionen fest (glEnable, glStencilFunc, glAlphaFunc etc.), während man in Direct3D eigentlich immer IDirect3DDevice9::SetRenderState oder ähnliches aufruft, aber mit einem entsprechenden Parameter (D3DRS_STENCILFUNC, D3DRS_ALPHAFUNC etc.), womit der Quellcode sich sogar ähnlich liest.
Viel einfacher ist für Einsteiger sowieso keine der APIs, aber wer zum Beispiel die Routinen zum Texturladen selber schreibt und das einfacher findet als D3DXCreateTextureFromFile aufzurufen, der weiß wohl was er tut ;c)
Ach ja, eins noch zur Systemunabhängigkeit von OpenGL: Hier hat Microsoft ein wenig gepfuscht, denn ohne Extrabibliotheken wie GLUT oder QT ist ein Windows-Open-GL-Programm nicht auf anderen Betriebssystemen lauffähig, da allein schon die Initialisierung einen HDC erfordert. Das ist dasselbe wie mit Standard-Windows-Anwendungen, denn auch diese kann man nicht ohne weiteres unter anderen Betriebssystemen verwenden.
Aber eigentlich ging die Frage ja um Tutoriale etc.
gamedev.net, Gamasutra.com und flipcode.com sind die Standardanlaufstellen für OpenGL, Direct3D und auch alles andere bezüglich Spieleentwicklung (nicht nur -programmierung).
Aya - Mo 10.03.03 00:07
| OregonGhost hat folgendes geschrieben: |
| In OpenGL muss man hingegen eine Funktionskolonne hinschreiben, gerade wegen der man eigentlich auf objektorientierte Programmierung umgestiegen ist |
Na ja, genau für solche sachen schreib ich mir in der Regel einfach eigene Funktionn :)
Aber stimmt schon, jeder wird was anderes sagen, denn die einen sind OGL Fanatiker, die anderen D3D'ler... *g*
Au'revoir,
Aya~
OregonGhost - Mo 10.03.03 00:23
| Aya hat folgendes geschrieben: |
| Aber stimmt schon, jeder wird was anderes sagen, denn die einen sind OGL Fanatiker, die anderen D3D'ler... *g* |
Eben, eben. Und eben darum sollte man Neulinge ja auch sich ihre eigene Meinung bilden lassen - übrigens ist mir aufgefallen, dass die meisten Delphianer mit OpenGL programmieren, die meisten C++ler hingegen mit Direct3D - vielleicht dieselbe Glaubensfrage wie Delphi gegen C++, auch wenn dieser Vergleich ebenso hinkt, wie wenn man OpenGL mit DirectX (und nicht mit Direct3D) vergleicht ;c)
Aya - Mo 10.03.03 00:26
Eine sache is mir noch eingefallen, nämlich ein sehr entscheidender und sehr großer vorteil von D3D.. :)
Es gibt massenhaft Dokus, Referenzen, Beispiele etc du D3D... bei OGL zwar auch viel, aber beiweitem nicht soviel wie für D3D.. :)
Nen bekannter von mir, der an nem ziemlich bekannten Spiel mitgeprogt hat, meinte als ich fragte warum es in C++/D3D geproggt wurde, das es einfach leichter sei dort infos und referenzen zu finden.. :)
Au'revoir,
Aya
OregonGhost - Mo 10.03.03 11:50
| Aya hat folgendes geschrieben: |
Es gibt massenhaft Dokus, Referenzen, Beispiele etc du D3D... bei OGL zwar auch viel, aber beiweitem nicht soviel wie für D3D..
|
Tja, und auch wenn Microsoft manchmal Dinge (wie zum Beispiel OS-Interna (c; ) nicht dokumentiert, das ist einer der Gründe, weshalb ich nicht mehr zum Kreis der Microsoft-Hasser gehöre wie früher und Visual Studio verwende ;c)
OpenGL ist wie viele typische Multiplattform-Bibliotheken aus der *nix-Szene wie QT, SDL und Co - an sich leistungsfähig, weil von fähigen Programmierern entwickelt, aber eine umfangreiche Dokumentation wie das DirectX SDK mag keiner von denen schreiben ;c)
Dass es unabhängig davon noch sehr viele Dokumentationen, Tutorials etc. gibt, liegt wahrscheinlich daran, dass es VC++-Benutzern (und das sind nunmal die meisten Programmierer) sehr einfach gemacht wird, DirectX zu verwenden, im Gegensatz zu Delphi (schätzungsweise weil es Borland vor allem um das A in RAD geht).
Ich frage mich, warum fragen eigentlich oftmals Neulinge, ob sie C++ oder Delphi nehmen sollen, ziehen dabei aber Java gar nicht in Betracht, obwohl Java doch von so vielen Leuten als tolle Sprache gelobt wird, die auch für High-Performance-Anwendungen wie Spiele geeignet sei (was meiner Meinung nach übrigens nicht stimmt, weil die wenigen Vorteile von Java in der Spieleprogrammierung kaum greifen und nur Performance kosten)... Auf der anderen Seite haben aber viele Neulinge das Vorurteil, C++ sei schrecklich kompliziert... Naja, wie dem auch sei, bin mal gespannt, wofür Jetro sich entscheidet - übrigens noch ein Buchtipp:
"Computerspiele - Design und Programmierung" von Peter Dobrovka u.a., mitp-Verlag, 38€
Da steht quasi ALLES zur Spieleentwicklung drin, inklusive einem großen Kapitel zur Programmierung, sowie Extrakapitel, in denen OpenGL und Direct3D erklärt werden. Da kann man sie auch sehr gut vergleichen, weil in beiden Fällen nach der Funktionalität und nicht nach den Eigenarten der API sortiert wurde.
Phobeus - Di 11.03.03 16:33
Also... nun muss ich mich als radikaler OpenGLer nochmal einhacken. Was das Beispiel mit dem Code für die Rotation angeht, muss ich sagen, dass es der total falsche Weg ist, daher ist dein OpenGL-Code auch länger. Du brauchst nicht überall irgendwelche Matrizen in OGL erzeugen und Multiplizieren (Du kannst es), aber ein
glLoadIdentity,
# Cam
glTranslatef(0,5,0);
glRotatef(90,0,1,0);
schafft es um ein Objekt zu positionieren und zu rotieren ohne eine einzige Variable oder ewig lange Multiplikationen zu verwenden. Würden wir dann noch den gesamten Code und das Init vergleichen, wäre der DX-Code locker doppelt so lang. Was Hilfsfunktionen angeht, wird jede fähige Programmier sich schnell selbst etwas dafür zu schreiben, anstatt stundenlang in der SDK nach Hilfe zu suchen.
Ich selbst habe über drei Jahre DirectX und davon ca. 1 Jahr Direct3D eingesetzt und weiß, wovon ich rede. Das Wirrwarr ist so groß, dass man nur erahnen kann, wofür was ist und ohne SDK aufgeschmissen ist. Mal eben schnell etwas aus dem Hemd schüttel ist nicht leicht in Direct3D, auch wenn es sicherlich mehr Funktionen gibt und für Objektorientierte Programmierer einleuchtender ist (was ca. 1 % der Progger ausmachen würde... ist hart, aber die Wahrheit).
Das es keine SDK gäbe für OpenGL ist ne böses Gerücht... sowohl Blue- als auch Redbook sollten einen mehr als soldiden Start bieten. Ja, es handelt sich dabei um Texte und keine kurzen Beschreibungen (dafür gibt es z.b. die PSDK-Doku Abschnitt OpenGL). Mehr ist OpenGL nicht und damit bereits genauso Leistungsfähig wie Direct3D ... und wer wert auf Shader legt, der sollte erstmal die Grund-API lernen und da ist OpenGL IMAO leichter, weil ein dynamisches Array und der VertexBuffer so manchen Progger bereits das Genick gebrochen hat, dann lieber ne Array nehmen und einfach an eine Funktion übergeben.
Auch das es mehr Src für Direct3D geht kann ich nicht bestätigen. Gerade im Delphi-Bereich leider Mangelware, während OpenGL von vielen Seiten unterstützt wird.
Letztendlich ist es eine Geschmacksfrage, die jeder für sich selbst treffen sollte. Wie immer gilt, nicht die CPU, nicht der RAM, nicht die Grafikkarte, nicht der Compiler, sondern die Leistung des Proggers ist entscheiden.
Just my six cents
Jetro - Di 11.03.03 16:58
Heho, bloss nochmal zur Info an alle Schreiberlinge [DANKE!]. Ich werde mir jetzt zu BEIDEN Sachen mal ein paar Tuts ausprobieren etc. und DANACH entscheiden was ich dann erstmal vertiefen will :)
Mal gucken :)
Ciao :)
Achja: Weitere URLs wären sehr schön :)
TheBlackRave - Di 11.03.03 16:59
Also ich sag jetzt nichts genau zu den Fragen usw.!
Aber ich selber kann nur empfehlen C++/DirectX zu benutzen.
Delphi ist für DirectX/OpenGl noch nicht reif genug.
Raphael O. - Di 11.03.03 21:39
| TheBlackRave hat folgendes geschrieben: |
| Delphi ist für DirectX/OpenGl noch nicht reif genug. |
WO hast du denn das schon wieder her??? :evil:
mimi - Di 11.03.03 23:26
@TheBlackRave
wüsste ich auch gerne mal.
also mit delph kannst du sowol prima mit DX als auch mit OpenGl arbeiten, ich weiß nicht womit besser(warscheinlich gleichgut....)
Phobeus - Mi 12.03.03 10:18
@TheBlackRave: Der einzige der nicht reif ist, bist Du... :lol: ansonsten würdest Du solche Statements einfach lassen. Nutze Delphi seit Jahren und habe keinerlei Probleme damit... könntest Du deinen Standpunkte bitte ein wenig detaillierter Erötern, bin sehr gespannt auf eine gute Argumentation, vielleicht überzeugst mich ja von deiner Meinung :twisted:
@Jetro: Für OpenGL gehe mal auf unsere Seite druff und dann unter Links, dass sollte genug Stoff bieten für die nächsten Jahre :wink:
Blasterboy - Mi 12.03.03 10:27
Es sind zwar die meisten Spiele in C mit Direct X und/oder OpenGl geschrieben JEDOCH heißt das nicht das Delphi das nicht kann! Das komm meist davon, dass die Spieleentwickler meist C und Direct X gelernt haben, und noch nichts (bzw. kaum) von Delphi und OpenGL programmierung wussten, da (glaube ich) die Direct X und OpenGL portirung nach Delphi erst vor einiger Zeit geschehen ist. OpenGL und Direct X sind beides gut programmierbare Grafikschnittstellen welche für Delphi UND C gleichgut zurecht gefertigt wurden. (Aber ich persönlich neig doch n bissl mehr zu OpenGL :roll: )
Cu
Blaster
OregonGhost - Mi 12.03.03 13:41
@Blasterboy: Die meisten Spiele sind in C++ und nicht in C geschrieben. Ich bitte diesen Unterschied zu beachten, denn ein Vergleich von C mit Delphi (genauer Object Pascal) ist so ähnlich wie einen kleinen Flitzer mit einer Großraumlimousine zu vergleichen.
@Phobeus:
Siehst du, schon prallen Welten aufeinander.
Zwei Dinge zu glRotatef:
1.
| Microsoft OpenGL Implementation hat folgendes geschrieben: |
The glRotate function computes a matrix [...]
The current matrix (see glMatrixMode) is multiplied by this rotation matrix [...]
|
Das heißt, jeder Aufruf von glRotatef errechnet die Matrix komplett neu (mithilfe von sin/cos). Wenn du die Matrix speicherst, geht's also schneller.
2. Wenn du diese Methode verwendest, kommst du leicht zum Gimbal-Lock-Problem. Die Umgehung des Problems durch Quaternionen wird langsamer, weil aus der Quaternion bereits direkt die Matrix berechnet wird.
Das heißt, glRotatef ist einfacher, aber unter Umständen langsamer bzw. ungenauer. Das spricht nicht direkt gegen die Verwendung von glRotatef, aber für die Matrixmethode.
| Phobeus hat folgendes geschrieben: |
| Was Hilfsfunktionen angeht, wird jede fähige Programmier sich schnell selbst etwas dafür zu schreiben, anstatt stundenlang in der SDK nach Hilfe zu suchen. |
Wer lesen und schreiben kann ist klar im Vorteil (Achtung, Sarkasmus). Ich habe jedenfalls noch nie länger als ein, zwei Minuten suchen müssen - in der Zeit hätte zumindest ich die gesuchten Funktionen jedenfalls nicht fehlerfrei selbst geschrieben. Auf der anderen Seite kann ich mir dann auch eine schnelle Kapselung für die Matrixmethode schreiben.
Wie dem auch sei, daran sieht man es: Du hast lange Zeit Direct3D und OpenGL verwendet, genau wie ich. Trotzdem bin ich Direct3D-Fan und du OpenGL-Fan. Letztendlich entscheidet also nur persönlicher Geschmack.
Aber dass die objektorientierten Programmierer nur etwa 1% ausmachen ist mir neu.
Noch was zu Delphi / C++:
Zum einen kann man nur Object Pascal mit C++ vergleichen, zum anderen sind diese tatsächlich gleichgut für Spieleprogrammierung geeignet. Auch hier entscheidet wiederum die persönliche Präferenz bzw. die Zielplattform. Desweiteren ist die Sprache C++ wesentlich umfangreicher und dennoch deutlich einfacher zu schreiben (ich meine weniger tippen), und wenn man damit etwas anfangen kann, ist sie deutlich mächtiger als Object Pascal. Wenn man die coolen Features wie Überladene Operatoren, Templates, Mehrfachvererbung etc. aber nicht brauchst, ist Object Pascal vielleicht die bessere Wahl, weil man dort auch noch Delphi zur Verfügung hat.
mimi - Mi 12.03.03 17:12
viele meinen ja das man mit delphi KEINE spiele schreiben kann, aber das ist falsch......
Phobeus - Mi 12.03.03 23:08
@glRotate: Das ist technisch nicht einwanfrei. Es wird nicht jedesmal neu berechnet, es wird schlicht und ergreifend dazu multipliziert, anders geht es bei D3D auch nicht von statten. Gerade um dein Problem zu umgehen, gibt es die Stacks bei OpenGL, die es bei Direct3D nicht gibt... deshalb ist gerade bei hierachischen Systemen und unkomplexen Szenen OpenGL eindeutig vorne... bei komplexen, ja gut... da müssenj beide auf das gleiche System zurück greifen.
@OOP: Erfahrungsgemäß gibt es kaum einen Programmierer der OOP richtig einsetzt, die meisten führen mehr oder minder eine Vergewaltigung dieser Technik durch und nutzen Objekte als unverseller Variablen und Funktions-Kontainer ;) Kann sein, dass ich im falschen Bereich tätig bin, aber oftmals bekomme ich mehr das lachen, wenn ich den Code von angeblichen OOP zu sehen bekomme (und ich schließe meinen da nichtmal aus :twisted: )
Um noch einen draufzusetzen bei der Geschmacksfragte zwischen D3D und OpenGL ... 8) *fackel.such.für.flächenbrand* "Wer unterstützt MS bei seinem TCPA-Plan? OpenGL oder Direct3D" :twisted: :wink:
Ce ;)
mimi - Do 13.03.03 00:28
also man sollten sich für sein problem das beste herraussuchen, für das eine ist OpenGl besser für das andren DirecX beide haben vor und nachteile meines wissens....
Phobeus - Do 13.03.03 00:42
Ich würde sogar einen Schritt weitergehen und behaupten, dass beide Sprachen keine Vor- oder Nachteile haben. Nehmen wir ne Hähnchen, steckt der eine es im Topf, der andere aufm Grill, der andere in die Pfanne... satt werden alle drei, gesünder wird nichts sein und die Grundsubstanz ist auch die gleiche... Geschmacksfrage eben ^__-
OregonGhost - Do 13.03.03 11:58
| Zitat: |
"Wer unterstützt MS bei seinem TCPA-Plan? OpenGL oder Direct3D" |
Ehrlich gesagt, mir ist Palladium, wie es momentan offenbar geplant ist (Koexistenz von TCPA- und Nicht-TCPA-Anwendungen, letztere dürfen nur auf Sicherheitsfunktionen nicht zugreifen) wesentlich lieber als die von Intel initiierte Version (Bei Start einer Nicht-TCPA-Anwendung stürzen alle TCPA-Anwendungen ab) - davon abgesehen ist Microsoft ausnahmsweise mal nicht die treibende Kraft hinter TCPA. Aber ich gehöre sowieso nicht zum Club der notorischen Microsoft-Hasser ;c)
Der Vergleich mit dem Hähnchen bringt's aber relativ gut auf den Punkt, sowohl für DirectX / OpenGL als auch für die Sprachen und Betriebssysteme.
Übrigens GIBT es Matrix-Stacks bei Direct3D (ID3DXMatrixStack), der sogar so ähnlich wie das System in OpenGL funktioniert - das ist also kein Grund, D3D nicht zu verwenden ;c)
Und für Hierarchien gibt es die SkinnedMesh-Unterstützung, auch wenn die vielleicht nicht der Weisheit letzter Schluss ist.
Von wegen OOP:
"Nur C++ zu benutzen heißt nicht automatisch, objektorientiert zu programmieren."
Natürlich gibt es viele armselige Programmierer, aber dann ist es schwierig, die Grenze zu definieren. Bin ich OOPler, wenn ich Polymorphismus verwende (genauer: ausnutze)? Bin ich kein OOPler, weil ich anstatt mir einen Kopierkonstruktor für eine struct zu schreiben, memcpy() verwende? Jetzt mal abgesehen davon, dass ein Kopierkonstruktor automatisch erzeugt wird, auch wenn der nicht kategorisch das beste Ergebnis liefert. Bin ich kein OOPler, wenn ich direkt auf public member zugreife, anstatt Set/Get-Funktionen dafür zu schreiben?
Ich verwende lieber sprintf als den string-Typ, weil's schneller geht und vor allem mit Resourcen-Strings einfacher zu verwenden ist. Ich schreibe nur Set/Get-Funktionen, wenn ich es unbedingt für nötig halte, wenn's geht kann man natürlich die Member dennoch nicht von außen verwenden. Ich verwende die prozedurale Windows-API, weil es keine objektorientierte Windows-API gibt. Und trotzdem behaupte ich (und ich hoffe du würdest über meinen Code nicht lachen (C; ), dass ich objektorientiert programmiere.
Aber ob das alles Jetro bei seinen Entscheidungen hilft? ;c)
mimi - Do 13.03.03 15:12
| OregonGhost hat folgendes geschrieben: |
davon abgesehen ist Microsoft ausnahmsweise mal nicht die treibende Kraft hinter TCPA
|
wer ist denn die treibende Kraft von TCPA ?
also ich würde sagen, das er sich über beide themen informieren sollte(also per google im internet nach infos suchen) und dann entscheidet er sich. Wir können ja nicht sagen, du solltes das nehmen, weil ......
Moderiert von 
Marc: Quote-Tag korrigiert.
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2026 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!