DirectX vs OpenGL [Archiv]

tokugawa

2008-01-23, 00:54:17

danach ganz klar opengl wegen der plattformunabhängigkeit! ;)

Für Anfänger ist das absolut nichts. Damit schießt man sich nur in den Fuß.

Die sogenannte Plattformunabhängigkeit bei OpenGL bedeutet Land der Schmerzen. Großes Land.

Nur naive Leute glauben noch an das Märchen von "Write once, compile multiple times" bezüglich OpenGL-Plattformunabhängigkeit (das war sowieso nie gegeben da OpenGL immer einen plattformabhängigen Layer besaß, nämlich GLX, WGL usw.).

Derzeit splittet sich OpenGL-Plattform"unabhängigkeit" nämlich sogar auf einer Plattform (z.B. Windows) auf in ATI und NVIDIA für die man nicht selten separate Pfade programmieren muß, wenn man tatsächlich State-of-the-Art-Zeugs einsetzt. ID Software verwendet ja gern OpenGL - und die programmieren ja auch immer separate Pfade. "Separate Render-Pfade" sind das genaue Gegenteil von "Plattformunabhängigkeit".

Deswegen:
- Für Anfänger ist Plattformabhängigkeit wurscht, daher zieht das Argument nicht zugunsten OpenGL
- Für Fortgeschrittene und Profis ist OpenGL-Plattformunabhängigkeit mit extrem viel Aufwand verbunden. Also auch nicht grad ein Argument.

Es ist nicht selten sogar weniger Aufwand, "native" APIs (etwa DirectX für Windows und Xbox360, NintendoWare für Wii, usw.) zu verwenden und die Plattformunabhängigkeit in der eigenen Engine zu realisieren, als OpenGL zu verwenden und zu glauben damit hätte man die Plattformabhängigkeit abgedeckt.

Anstatt OpenGL-Eigenheiten in den einzelnen Treibern und Implementationen mühsamst zu entdecken (die meistens nicht mal dokumentiert sind - ich hab schon ein zwei Bugs gefunden in ATI und NVIDIA-OpenGL-Treibern die ich scheinbar als erster auf der Welt gefunden hab - oder zumindest die bis dato noch unbekannt waren), ist es nicht selten klüger gleich eine gut dokumentierte "native" API für die jeweilige Plattform einzusetzen.

Für Anfänger würd ich OpenGL aufgrund des Immediate-Mode empfehlen. Allerdings verleitet der zu einem Denken in der Grafikprogrammierung das heutzutage nicht mehr modern ist.

Wenn jemand wirklich lernen will wie moderne Grafik-APIs funktionieren, und das mit guter Dokumentation, würde ich wie die Coda und Neomi Direct3D empfehlen.

Zumal da die Tools unschlagbar sind:
- die Direct3D Debug Runtime sagt dir genau was du falsch machst. Bei OpenGL kriegst du in der Regel höchstens sowas wie "INVALID PARAMETER" zurück, was einem nicht wirklich weiterhilft
- theoretisch kannst du Shader debuggen (d.h. durchsteppen, Werte anschauen, Breakpoints setzen); das hab ich allerdings nie verwendet da man dafür in den Software-Rasterizer schalten muß
- wenn man auf NVIDIA entwickelt kann man NvPerfHUD verwenden, das wirklich, und das kann ich nur absolut betonen, absolut ERSTKLASSIG ist. Was ich damit schon an Bugs entdeckt bzw. gelöst habe (und das Tool ist eigentlich gar nicht zur Bugsuche da, sondern zur Performanceanalyse), ist schier unglaublich
- HLSL ist um einiges komfortabler als GLSL (man könnte allerdings auch Cg verwenden, um GLSL auszuweichen unter OpenGL)

Tesseract

2008-01-23, 01:20:32

Aus Prinzip OpenGL klingt mehr nach einer emotionalen Entscheidung gegen Microsoft

in gewisser weise ja. hab ich auch nicht bestritten.

die platformunabhängigkeit hab ich auch deswegen angeführt, weil einem das z.B. die möglichkeit gibt das ganze unter linux zu machen wenn man will.

@tokugawa: wo ist das problem im rahmen eines hobby-projektes z.B. mit hilfe von GLUT relativ schnell und einfach plattformübergreifenden code zu schreiben?
ich seh da jetzt ehrlich gesagt nicht das problem, dass du da versuchst so breit zu treten.

Coda

2008-01-23, 01:57:04

wenn man an sowas mit "aber das ist doch so viel einfacher..." ran geht kannst du gleich ein bereits vorhandenes spiel modden.
Blödsinn. Man hat so schon genug zu tun. Da brauchst dir nicht auch noch OpenGL aufhalsen. Platformunabhängig ist bei OpenGL eh nur das absolute Basisfeatureset und dann hat man noch zig Probleme mit den Treibern weil es keine Runtime gibt.

Und ich spreche aus Erfahrung.

Expandable

2008-01-23, 07:48:46

HLSL ist um einiges komfortabler als GLSL (man könnte allerdings auch Cg verwenden, um GLSL auszuweichen unter OpenGL)

Äh... finde ich interessant. Könntest du das vielleicht gegründen? Oder geht's dir nur um das Effect Framework? Rein syntaktisch finde ich GLSL irgendwie schöner (was natürlich nicht wirklich wichtig ist, aber immerhin). Von der Funktionalität her nehmen sich GLSL und HLSL doch sowieso nix, oder?

Shink

2008-01-23, 08:22:41

Hmm... Fertige Spielengine (Blitz 3D, Ogre o.ä.)? Dann bekommt man auch Plattformunabhängigkeit geschenkt.

Wer kommt denn drauf dass ein Einsteiger seine Direct3D-Engine so gut hinbekommt wie irgendeine OpenSource-Community?

tombman

2008-01-23, 08:29:20

Leute, die Anfrage könnts doch sowieso gleich wieder vergessen.
Wer meint es denn bitte ernst coder zu werden, und fragt in einem Forum nach was besser ist?

Sorry, aber für mich hört sich das so an, als wenn klein Maxi fragt, ob er jetzt lieber einen Diesel- oder Benzinmotor erfinden soll...

Shink

2008-01-23, 14:07:13

Sehe ich anders; irgendwann fängt jeder mal an. Dass er dann noch keine persönlichen Vorlieben hat ist aber natürlich doch etwas seltsam.

rotalever

2008-01-23, 14:30:04

Für Anfänger würd ich OpenGL aufgrund des Immediate-Mode empfehlen. Allerdings verleitet der zu einem Denken in der Grafikprogrammierung das heutzutage nicht mehr modern ist.
Was ist eigentlich genau der Immediate-Mode? Ich kenne das Wort irgendwie nicht.. Wikipedia sagt mir dazu nur ein bisschen.

Expandable

2008-01-23, 15:17:25

Was ist eigentlich genau der Immediate-Mode? Ich kenne das Wort irgendwie nicht.. Wikipedia sagt mir dazu nur ein bisschen.

glBegin(GL_TRIANGLES);
glVertex3f(x1, y1, z1);
glVertex3f(x2, y2, z2);
glVertex3f(x3, y3, z3);
glEnd();

Damit kannst Du ein Dreieck zeichnen (mit den xi, yi und zi geeignet). Unter D3D und OpenGL 3.0 musst Du erst ein VertexBuffer Object anlegen (also die Koordinaten ein einen zusammenhängenden Speicherbereich schreiben, diesen an die Grafikkarte übergeben) und dann diesen Zeichnen lassen.

Läuft im Endeffekt auf's gleiche raus, ist allerdings teilweise wesentlich performanter, dafür aber auch komplizierter. Frustriert Anfänger, weil ihr Code nicht funktioniert, oder weil sie viel Copy&Paste machen und somit den Code nicht verstehen.

Coda

2008-01-23, 15:36:11

Äh... finde ich interessant. Könntest du das vielleicht gegründen? Oder geht's dir nur um das Effect Framework? Rein syntaktisch finde ich GLSL irgendwie schöner (was natürlich nicht wirklich wichtig ist, aber immerhin). Von der Funktionalität her nehmen sich GLSL und HLSL doch sowieso nix, oder?
GLSL ist syntaktisch ganz sicher nicht schöner. Allein das man alles explizit casten muss ist äußerst nervig.

Gast

2008-01-23, 15:55:59

GLSL ist syntaktisch ganz sicher nicht schöner. Allein das man alles explizit casten muss ist äußerst nervig. Zumindest bei ATi, bei NVIDIA nicht 8-)

Coda

2008-01-23, 16:04:45

Was dann aber auch kein GLSL mehr ist ;)

rotalever

2008-01-23, 16:21:05

Damit kannst Du ein Dreieck zeichnen (mit den xi, yi und zi geeignet). Unter D3D und OpenGL 3.0 musst Du erst ein VertexBuffer Object anlegen (also die Koordinaten ein einen zusammenhängenden Speicherbereich schreiben, diesen an die Grafikkarte übergeben) und dann diesen Zeichnen lassen.

Achso, macht man ja in OpenGL teilweise auch.

Coda

2008-01-23, 16:39:57

Das macht man nicht nur "teilweise", sondern jedes Programm das was auf sich hält tut das. Immediate Mode ist unglaublich lahm.

Expandable

2008-01-23, 16:50:08

Achso, macht man ja in OpenGL teilweise auch.

VertexBuffer-Objects? Ja klar, die sollte man aus Performancegründen auch in OpenGL verwenden, auch, wenn es noch andere Möglichkeiten gibt. Aber aus diesem Grund gibt's glVertex und Konsorten in der nächsten OpenGL-Version AFAIK nicht mehr.

GLSL ist syntaktisch ganz sicher nicht schöner. Allein das man alles explizit casten muss ist äußerst nervig.

Hmm. Findest du? Ich meine, ich hab zwar 'ne nVidia-Karte, und bekomm deswegen vielleicht nicht alle Fälle mit, aber ich finde, explizites Casten erhöht die Übersichtlichkeit. Und mvpMatrix * gl_Vertex ist auch schöner als mul(mvpMatrix, input.Pos). Aber egal, darum geht's wohl nicht.

rotalever

2008-01-23, 19:29:35

Das macht man nicht nur "teilweise", sondern jedes Programm das was auf sich hält tut das. Immediate Mode ist unglaublich lahm.
Hmm generell hast du da natürlich recht. Ist zwar OT, aber egal: Letztens wollte ich etwas mit Python machen, wo für jeden Frame die kompletten Vertex-Daten, so 500 Stück, neu übertragen, bzw. aktualisiert werden müssen. Da war das aus irgendeinem Grund mit dem einfachen glVertex2f schneller. Ich denke mal, das lag aber eher am Python. Wollte das halt nur nicht zu stark verallgemeinern.
In C/C++ merkt man jedoch einen gewaltigen Unterschied, so Faktor 10 oder so.

Coda

2008-01-23, 19:31:20

Hast du einen dynamischen oder statischen Vertexbuffer verwendet? Double-Buffering?

rotalever

2008-01-23, 20:07:59

Hast du einen dynamischen oder statischen Vertexbuffer verwendet? Double-Buffering?
Double-Buffering. Hmm. da fällt mir allerdings ein, dass ich es erst mit Vertexarrays versucht hatte, und da das langsamer war als glvertex hatte ich nicht mehr weiterprobiert. Ich denke mal wenn Vertexarrays (in diesem Fall) langsamer waren, dann wären das auch Vertexbuffer gewesen. Das Problem lag glaube ich eher an der Programmiersprache, da da irgendwelche Arrays etc. konvertiert werden mussten.
Ist ja eigentlich auch egal. Geht ja vermutlich um eine Sprache wie C oder C++, wo das kein Problem ist.

Coda

2008-01-23, 22:16:19

Man muss auch VBOs benützen, sonst ist die Performance auch nicht viel besser.

tokugawa

2008-01-24, 00:09:29

@tokugawa: wo ist das problem im rahmen eines hobby-projektes z.B. mit hilfe von GLUT relativ schnell und einfach plattformübergreifenden code zu schreiben?
ich seh da jetzt ehrlich gesagt nicht das problem, dass du da versuchst so breit zu treten.

Ich schon, weil ich bei meinen "Hobbyprojekten" auch State-of-the-Art-Effekte einsetzen möchte. Da kommt man um FBOs nicht herum.

Und FBOs sind zwar mittlerweile schon etwas besser, aber immer noch ganz großer Krampf.

Äh... finde ich interessant. Könntest du das vielleicht gegründen? Oder geht's dir nur um das Effect Framework? Rein syntaktisch finde ich GLSL irgendwie schöner (was natürlich nicht wirklich wichtig ist, aber immerhin).

Das mit "schöner" ist wohl Geschmackssache (ich finde reinen C Code z.B. nicht schön).

Aber GLSL ist deutlich strenger, unterstützt keine implicit type conversions (selbst bei absolut logischen Konversionen), d.h. man muß sehr viele Dinge typecasten, die eigentlich nicht nötig wären logisch gesehen. Das tut den Code schon ziemlich unlesbar machen.

Mal abgesehen davon dass NVIDIA (bei der Standardeinstellung) einen viel laxeren GLSL-Compiler hat (der dafür aber auch bequemer zu benutzen ist), allerdings dadurch die Kompatibilität der GLSL-Shader auf ATI-Karten dann leidet.

Also ganz große Diskrepanzen in vielen Gebieten. "Einfach" ist die Portabilität von OpenGL definitiv nicht, wenn man sich nicht auf das Grundsätzliche (OpenGL <= 1.2) beschränken möchte.

Von der Funktionalität her nehmen sich GLSL und HLSL doch sowieso nix, oder?

Da nicht, nein.

Leute, die Anfrage könnts doch sowieso gleich wieder vergessen.
Wer meint es denn bitte ernst coder zu werden, und fragt in einem Forum nach was besser ist?

Du hast zwar nicht ganz unrecht, aber viele Entwickler (auch professionelle; ich z.B.) sind in Foren verbunden. Da ist es auch ok wenn Anfänger dann entsprechende Anfängerfragen stellen.

Was ist eigentlich genau der Immediate-Mode? Ich kenne das Wort irgendwie nicht.. Wikipedia sagt mir dazu nur ein bisschen.

Der Immediate-Mode ist das Konstrukt wo man Geometrie in OpenGL per-Vertex zur Graka schickt, über die glBegin/glEnd-Mechanik.

Im Gegensatz zu Vertex-Arrays/Vertexbuffern/Display-Lists.

Hmm. Findest du? Ich meine, ich hab zwar 'ne nVidia-Karte, und bekomm deswegen vielleicht nicht alle Fälle mit, aber ich finde, explizites Casten erhöht die Übersichtlichkeit. Und mvpMatrix * gl_Vertex ist auch schöner als mul(mvpMatrix, input.Pos). Aber egal, darum geht's wohl nicht.

Explizites Casten für total unnötige Dinge (die "eh klar" sind) kann doch nicht die Übersichtlichkeit erhöhen? Das macht den ganzen Code nur mit unwichtigen Dingen "cluttered".

Gut lesbarer Code sollte die grundlegende Funktionalität, also den Algorithmus, möglichst wenig obfuscaten. Für alles explizit casten zu müssen ist auch eine Form von Obfuscation, weil das versteckt den eigentlichen Algorithmus unter einem Schwall an Code.

Double-Buffering. Hmm. da fällt mir allerdings ein, dass ich es erst mit Vertexarrays versucht hatte, und da das langsamer war als glvertex hatte ich nicht mehr weiterprobiert. Ich denke mal wenn Vertexarrays (in diesem Fall) langsamer waren, dann wären das auch Vertexbuffer gewesen. Das Problem lag glaube ich eher an der Programmiersprache, da da irgendwelche Arrays etc. konvertiert werden mussten.

Dann hast du was fundamental falsch gemacht. Ich lese das allerdings häufig (bin/war Tutor/Studienassistent auf der Uni für Lehrveranstaltungen/Laborübungen im Bereich Realtime-Rendering), das kommt häufig vor, z.B. wenn man unnötig in jedem Frame den Vertexbuffer komplett neu erstellt und die Daten unnötigerweise komplett wieder zur Grafikkarte schickt.

Ist ja eigentlich auch egal. Geht ja vermutlich um eine Sprache wie C oder C++, wo das kein Problem ist.

Das hat mit der Programmiersprache nicht wirklich was zu tun.

Der Sinn, und auch der Grund, warum logischerweise Vertexbuffer schneller sein müssen ist ja, da man bei Vertexbuffern die Vertexdaten gesammelt zur Grafikkarte schickt, und diese dann vom Treiber verwaltet werden (meistens in schnellerem Speicher, etwa direkt auf der Graka, oder im AGP-Speicher), und man eben nicht in jedem Frame für jeden Vertex einen API-Call hat und den damit verbundenen Overhead.

Eher sollten in einer "langsameren" Sprache als C/C++ sogar Vertexbuffer noch mehr bringen, da dort der API-Call-Overhead noch größer ist.

Chris Lux

2008-01-24, 06:13:46

GLSL ist syntaktisch ganz sicher nicht schöner. Allein das man alles explizit casten muss ist äußerst nervig.
das fand ich am anfang auch. mittlerweile ist das nicht so schlimm, vor allem, wenn man sich den generierten assembler code ausgeben lässt. jede typkonvertierung kostet und man muss das somit explizit in kauf nehmen. syntaktisch nicht schön aber nicht schlimm IMO.

Zumindest bei ATi, bei NVIDIA nicht 8-)
das ist seit einer weile schon nicht mehr wahr.

Und FBOs sind zwar mittlerweile schon etwas besser, aber immer noch ganz großer Krampf.

Aber GLSL ist deutlich strenger, unterstützt keine implicit type conversions (selbst bei absolut logischen Konversionen), d.h. man muß sehr viele Dinge typecasten, die eigentlich nicht nötig wären logisch gesehen. Das tut den Code schon ziemlich unlesbar machen.

Mal abgesehen davon dass NVIDIA (bei der Standardeinstellung) einen viel laxeren GLSL-Compiler hat (der dafür aber auch bequemer zu benutzen ist), allerdings dadurch die Kompatibilität der GLSL-Shader auf ATI-Karten dann leidet.

Also ganz große Diskrepanzen in vielen Gebieten. "Einfach" ist die Portabilität von OpenGL definitiv nicht, wenn man sich nicht auf das Grundsätzliche (OpenGL <= 1.2) beschränken möchte.
also was glsl portabilität angeht ist derzeit ganz klar ATi als schuldiger zu nennen, der nvidia compiler ist mittlerweile strikt und funktioniert wie es die specs erwarten lassen.

zu der frage ob d3d oder opengl. klar bietet das dx sdk viel mehr, weshalb ich die argumente von coda und toku klar unterstützem muss. ABER das argument opengl sei kaum portabler ist echt totaler blödsinn. wie ich es schon in einem anderen thread gesagt habe ist das einfach nicht so, man benutzt heute fbos, vbos, shader (grundlegend). diese sachen funktionieren bis auf kleinere platformunterschiede (zwischen ati und nvidia) wie erwartet. die kleinen probleme muss man keinesfalls mit getrennten renderpfaden lösen und das macht zu 100% auch kein carmack heute mehr so (von der xbox und ps3 mal abgesehen). zu doom3 zeiten ging es um ganze hardwaregenerationen, für die er getrennte pfade programmierte. für viele mag linux und apple kein argument sein, aber das ist was für mich platformunabhängigkeit hauptsächlich bedeutet.

Shink

2008-01-24, 10:38:48

Also der "Mist", den ich als Anfänger bisher in OpenGL (übrigens unter Java) produziert hab war protabel. Lag wohl an meinen geringen Ansprüchen und daran, dass ich mich an Tutorials hielt (http://nehe.gamedev.net/)

Heute ärger ich mich aber wie gesagt trotzdem darüber dass ich meine Spiele nicht gleich mit einer fertigen Game-Engine gemacht hab - schließlich baut man sich so etwas ohnehin früher oder später selbst zusammen. Das mag zwar lehrreich sein aber heute würd ich mich mehr freuen, wenn die Spiele ausgefeilter wären anstatt dass ich die 125.000ste 0815-GameEngine gebastelt hab, bei der ich sicher alle Fehler machte die es so gibt.
Naja, dafür erlaub ich alternativ den Betrieb ohne 3D-Unterstützung und vielleicht später mal auf Handys (was ja so gut wie keine Designeinschränkungen mit sich brachte...)

rotalever

2008-01-24, 14:27:55

Dann hast du was fundamental falsch gemacht. Ich lese das allerdings häufig (bin/war Tutor/Studienassistent auf der Uni für Lehrveranstaltungen/Laborübungen im Bereich Realtime-Rendering), das kommt häufig vor, z.B. wenn man unnötig in jedem Frame den Vertexbuffer komplett neu erstellt und die Daten unnötigerweise komplett wieder zur Grafikkarte schickt.

Naja, ich muss halt die Daten wirklich komplett neu rüberschicken, weil sie sich eben für jeden Frame ändern (keine simplen Matrix-Transformationen etc.). VBO hatte ich ja wie gesagt gar nicht erst probiert, sondern nur Vertex Arrays. War ein Fehler von mir das jetzt hier reinzuposten.

Das hat mit der Programmiersprache nicht wirklich was zu tun.
Eher sollten in einer "langsameren" Sprache als C/C++ sogar Vertexbuffer noch mehr bringen, da dort der API-Call-Overhead noch größer ist.
Tja, hat mich auch gewundert. Ich dachte eben auch das Vertex-Arrays schneller sind. Das Problem ist halt bei Python, dass da ja im Endeffekt die C Library OpenGL irgendwie reingewrappt wird und da weiß ich halt nicht, was der dann genau macht, wenn ich dem ne Liste mit Daten übergebe. Ich denke da muss ich noch ein wenig rumexperimentieren. Aber das ist ja auch eigentlich Offtopic.

tokugawa

2008-01-24, 18:18:56

zu der frage ob d3d oder opengl. klar bietet das dx sdk viel mehr, weshalb ich die argumente von coda und toku klar unterstützem muss. ABER das argument opengl sei kaum portabler ist echt totaler blödsinn. wie ich es schon in einem anderen thread gesagt habe ist das einfach nicht so, man benutzt heute fbos, vbos, shader (grundlegend). diese sachen funktionieren bis auf kleinere platformunterschiede (zwischen ati und nvidia) wie erwartet.

Wie gesagt: FBOs sind heut immer noch zach. Probier mal HDR-Rendering, bzw mach mal State-of-the-Art-Zeugs mit FBOs.

Die "kleineren Plattformunterschiede" sind leider genau das, was unsere Argumente eben kein Blödsinn sein lässt. Wenn du mal mein Posting durchliest, steht dort das Wort "dokumentiert".

Größere Unterschiede, die gut dokumentiert sind, sind in der Regel einfacher zu bewältigen als kleine undokumentierte Diskrepanzen, die man erst mühsam suchen muß. Dies ist leider unter OpenGL der Fall.

Also ist das was wir gesagt haben definitiv kein Blödsinn. Und ich halte mich für durchaus erfahren in diesen Dingen, bzw. kenn ich Leute die noch mehr Erfahrung mit OpenGL haben als ich und auch dauernd meinen dass Rendertargets in DirectX einfach funktionieren, während man in OpenGL viele kleine Problemchen hat.

Übrigens: du behauptest es funktioniert auf ATI und NVIDIA ohne Probleme. Frage an dich: besitzt du sowohl eine ATI als auch eine NVIDIA-Maschine, um diese Behauptung auch wirklich selbst untermauern zu können?

Chris Lux

2008-01-24, 21:17:39

Wie gesagt: FBOs sind heut immer noch zach. Probier mal HDR-Rendering, bzw mach mal State-of-the-Art-Zeugs mit FBOs.
ich mache state of the art sachen mit OpenGL, FBOs, VBOs und shader sind da täglich brot... dazu muss ich sagen: mach mal state of the art zeug mit OpenGL auf ATi ;)

Übrigens: du behauptest es funktioniert auf ATI und NVIDIA ohne Probleme. Frage an dich: besitzt du sowohl eine ATI als auch eine NVIDIA-Maschine, um diese Behauptung auch wirklich selbst untermauern zu können?
jap habe ich. ich ATi ist derzeit aber keine zielplattform, weil sie einfach derzeit den OpenGL support nicht haben. laut meinen informationen wird sich das aber spätestens mit OpenGL 3 ändern. prinzipiell war es aber nie ein problem meine sachen auf ATi hardware zum laufen zu bewegen.

das geht leider wieder am thema vorbei, ich habe ja gesagt, dass für anfänger sicher directx eine gute alternative ist. aber persönlich halte ich gl immer noch für das schönere, wobei wir da wieder bei persönlichen und politischen gründen wären.

Expandable

2008-01-24, 21:37:06

aber persönlich halte ich gl immer noch für das schönere, wobei wir da wieder bei persönlichen und politischen gründen wären.

Geht mir auch so.

Ich hatte mal spaßeshalber begonnen, meine Engine in OpenGL und D3D9 zu implementieren, was ich dann irgendwann aus Zeitgründen wieder aufgegeben habe. Der OpenGL-Code ist einfach viel übersichtlicher und besser lesbar (natürlich rein subjektiv). Interessant war auch, dass OpenGL sowohl unter XP als auch unter Vista 10-20% schneller war (auf nVidia-Hardware, ATi nicht getestet), was aber auch an meiner nicht ganz so dollen Kentniss von D3D9 liegen könnte ;)

tokugawa

2008-01-24, 22:06:19

Naja, wie gesagt, politische Gründe lass ich mal nicht gelten, über stupide Grundressentiments gegen Microsoft muß man, wenn man eine professionelle Einstellung hat, drüberstehen find ich.

Aber derzeit spricht die Waage ganz einfach für DirectX. Es gibt für OpenGL ganz einfach nicht so tolle Tools wie NVPerfHUD oder die Debug Runtime. Das sind ganz ganz essentielle Dinge.

Und, meine Herren! "OpenGL ist super portierbar! Außer auf ATI, da isses orsch" widerspricht doch dem Portierbarkeits-Kredo, oder? Genau das meinte ich ja. Niemand garantiert dass die OpenGL-Features die ich nutze auch wirklich so einfach überall funktionieren - man muß immer testen und irgendwie anpassen.

Und manchmal ist da - aufgrund fehlender Dokumentation für die Eigenheiten und Bugs jeder einzelne OpenGL-Implementation (und ja, ich lese die GPU-Programming-Guides und was es sonst noch gibt) - ist es oft einfach "leichter", Direct3D für eine Plattform und die jeweils passende (das kann dann auch durchaus OpenGL sein) für eine andere Plattform zu verwenden. Also quasi eine gewisse Abstraktion in der Engine zu haben.

Coda

2008-01-24, 22:32:33

Allein schon ohne PIX würde ich manchmal verzweifeln.

Expandable

2008-01-24, 22:42:34

Allein schon ohne PIX würde ich manchmal verzweifeln.

Ich habe mit PIX noch nicht so viel gearbeitet - aber was kann es, was der gDEBugger und glslDevil nicht können?

Coda

2008-01-24, 22:47:19

Hm glslDevil kannte ich noch nicht... Dann wohl nichts. Wobei PIX auch sonst mächtiger ist als geDEBugger (hab vor Weihnachten mal mit ihm gearbeitet).

Aber gut zu wissen, dass es jetzt auch nen Shader-Debugger für GLSL gibt. Das war nämlich echt schlecht.

PatkIllA

2008-01-24, 23:01:58

Allein schon ohne PIX würde ich manchmal verzweifeln.
Wobei mir das bei fast jedem komplizierteren Shader abstürzt. Oder geht das nicht mit XNA?

tokugawa

2008-01-25, 00:28:48

Ich habe mit PIX noch nicht so viel gearbeitet - aber was kann es, was der gDEBugger und glslDevil nicht können?

Schon mal mit NVPerfHud gearbeitet?

Gast

2008-01-25, 07:59:28

Naja, wie gesagt, politische Gründe lass ich mal nicht gelten, über stupide Grundressentiments gegen Microsoft muß man, wenn man eine professionelle Einstellung hat, drüberstehen find ich. Polit. Gründe sind schon wichtig und da wäre mir zeitweise auch mehr Sensibilität wünschenswert; wenn man den Kram, den man heute bastelt, morgen verkaufen muß, soll man gerne Dx nehmen. Wenn man diesen Zwängen aber nicht unterliegt, dann finde ich es immer lohnenswert die Sachen anders zu machen. Die Technik ist ja bloß Mittel zum Zweck und alles was einem sonstwie Spaß macht oder wichtig ist, hat da eben Vorrang.

Chris Lux

2008-01-25, 09:10:58

Aber derzeit spricht die Waage ganz einfach für DirectX. Es gibt für OpenGL ganz einfach nicht so tolle Tools wie NVPerfHUD oder die Debug Runtime. Das sind ganz ganz essentielle Dinge.
jap, die tool situation ist nicht schoen. aber von nvidia haben wir informationen, dass es zumindest die cli tools bald auch fuer OpenGL und GLSL geben soll (aber wie lange versprechen die das schon). die shaderperf sachen haengen jedoch generell in der letzten generation fest (g70 max. derzeit).

Und, meine Herren! "OpenGL ist super portierbar! Außer auf ATI, da isses orsch" widerspricht doch dem Portierbarkeits-Kredo, oder? Genau das meinte ich ja. Niemand garantiert dass die OpenGL-Features die ich nutze auch wirklich so einfach überall funktionieren - man muß immer testen und irgendwie anpassen.
wie gesagt meine/unsere sachen laufen prinzipiell auf ATi, aber deren OpenGL treiber sind derzeit noch extrem schlecht. aber das soll sich wie angedeutet schon bald aendern (der AMD einfluss in der prof. schiene wird langsam bemerkbar).

UND:
Naja, wie gesagt, politische Gründe lass ich mal nicht gelten, über stupide Grundressentiments gegen Microsoft muß man, wenn man eine professionelle Einstellung hat, drüberstehen find ich.
;) meine entwicklungsplattform ist XP x64. weil die entwicklungstools für mein empfinden unschlagbar sind. aber mein code ist eben portabel auf linux (und grundsätzlich auch macOSX).

Quaker

2008-01-25, 10:01:37

Shink

2008-01-25, 11:21:55

Das hat wohl eher mit der Philosophie zu tun: Wer sich auf der Microsoft DirectX&Compiler&Betriebssystem&Registry-Schiene ausruht muss sich weniger überlegen als die OpenGL-Cross-Plattform-Leute (und deshalb nimmt man ja OpenGL her, ob nun berechtigt oder nicht) - die können nur den größten gemeinsamen Teiler der Betriebssystemumgebungen verwenden und an dem ändert sich dann auch nicht ständig etwas.

Gast

2008-01-25, 12:32:02

Also an alle Entwickler, ich will wieder mehr OpenGL Games sehen!Vielleicht wird OpenGL 3.0/3.1 ja wieder einige Entwickler zurückholen, wünschenswert wäre es. Dazu scheint sich aktuell jeder im Umfeld Macs zu kaufen und da wird der Markt für Spiele in Zukunft auch höher. Dazu der Einfluß von AMD auf ATi Linuxtreiber ist bestimmt auch nicht schlecht für OGL.

Simon

2008-01-25, 12:41:35

Vielleicht wird OpenGL 3.0/3.1 ja wieder einige Entwickler zurückholen, wünschenswert wäre es.
Jep =)

Dazu scheint sich aktuell jeder im Umfeld Macs zu kaufen und da wird der Markt für Spiele in Zukunft auch höher.
Na das wird eine Weile dauern... (http://www.heise.de/newsticker/meldung/91012)

Coda

2008-01-25, 15:18:29

Aus Spielersicht finde ich es ziemlich schade dass fast überall DirextX gepusht wird, aber wird wohl leider die Zukunft sein.
Was mir an OpenGL Programme immer wieder auffällt, ist dass es meistens sehr "sauber" programmiert ist und kaum Bugs enthällt, ev. ist es ja Zufall - aber dann waren es in den letzten 15 Jahre ziemlich viele Zufälle.
Das hat ganz sicher nichts mit der Grafik-API zu tun.

Das hat wohl eher mit der Philosophie zu tun: Wer sich auf der Microsoft DirectX&Compiler&Betriebssystem&Registry-Schiene ausruht muss sich weniger überlegen als die OpenGL-Cross-Plattform-Leute (und deshalb nimmt man ja OpenGL her, ob nun berechtigt oder nicht) - die können nur den größten gemeinsamen Teiler der Betriebssystemumgebungen verwenden und an dem ändert sich dann auch nicht ständig etwas.
Und was hat das genau mit Logikbugs oder Abstürzen zu tun? Nichts!

jap, die tool situation ist nicht schoen. aber von nvidia haben wir informationen, dass es zumindest die cli tools bald auch fuer OpenGL und GLSL geben soll (aber wie lange versprechen die das schon). die shaderperf sachen haengen jedoch generell in der letzten generation fest (g70 max. derzeit).
Bei ATi nicht. Du kannst die beim GPU ShaderAnalyzer sogar direktes R3xx-R6xx-Assembly anzeigen lassen.

Expandable

2008-01-25, 16:01:56

Und was hat das genau mit Logikbugs oder Abstürzen zu tun? Nichts!

Ich sehe da aber auch einen gewissen Zusammenhang: Wer bereit ist, einen OpenGL-Renderer vernünftig zu implementieren, wird auch eher auf die Qualität des restlichen Produkts achten.

Oder aber, es liegt daran, dass die meisten OpenGL-basierten Spiele auf id-Engines basieren, die wiederum generell einen sehr hohen Qualitätsstandard haben.

Chris Lux

2008-01-25, 17:54:12

Bei ATi nicht. Du kannst die beim GPU ShaderAnalyzer sogar direktes R3xx-R6xx-Assembly anzeigen lassen.
Schoen zu wissen. Bei nVidia komme ich auch an die assemblies ran, schon komisch was der compiler da manchmal zusammenbastelt...

Coda

2008-01-25, 18:00:41

Ich sehe da aber auch einen gewissen Zusammenhang: Wer bereit ist, einen OpenGL-Renderer vernünftig zu implementieren, wird auch eher auf die Qualität des restlichen Produkts achten.
So ein Humbug. Sorry, aber das ist einfach lächerlich. Wer gescheite Software schreiben kann und will macht das egal was er für eine API verwendet.

Oder aber, es liegt daran, dass die meisten OpenGL-basierten Spiele auf id-Engines basieren, die wiederum generell einen sehr hohen Qualitätsstandard haben.
Natürlich liegt der Eindruck daran.

Monger

2008-01-25, 18:38:29

Ich sehe da aber auch einen gewissen Zusammenhang: Wer bereit ist, einen OpenGL-Renderer vernünftig zu implementieren, wird auch eher auf die Qualität des restlichen Produkts achten.

Ich denke, andersrum wird ein Schuh draus: wer den Luxus hat, sich alle Zeit der Welt für ein Produkt lassen zu können, hat möglicherweise auch den Luxus einfach aus Prinzip heraus OpenGL zu nutzen.

Wer außer ID Software und die paar Lizenznehmer setzt denn überhaupt noch in der Windows Welt auf OpenGL?
Wenn ich Gedanken mal so die Studios durchgehe die ich kenne, kann ich mich an keine OpenGL-only Titel erinnern. Selbst die Titel die beides anbieten, sind äußerst dünn gesäht. Natürlich erkennt man sowas ja auch nicht wenn es nicht gerade dran steht.

tokugawa

2008-01-27, 02:03:50

wie gesagt meine/unsere sachen laufen prinzipiell auf ATi, aber deren OpenGL treiber sind derzeit noch extrem schlecht.

Wir bewegen uns im Kreis. Mein Argument, warum die Portabilität von OpenGL in vielen Fällen Utopie ist, bezog sich genau darauf, dass eben die Treiberqualität total unterschiedlich ist, und das direkt auf die API einen Einfluß hat (was eine bestimmte OpenGL-Implementation hergibt).

Bei DirectX hat man das in viel kleinerem Ausmaß, die API selbst bleibt von Treiber-"Ungenauigkeiten" unberührt.

Mit anderen Worten: du stimmst mir ja eh zu, wenn du auch einsiehst dass die ATI-OpenGL-Treiberqualität ziemlich mies ist; genau das ist der Grund warum die Portabilität eigentlich großteils ein Papierfeature von OpenGL ist.

aber das soll sich wie angedeutet schon bald aendern (der AMD einfluss in der prof. schiene wird langsam bemerkbar).

Gut zu wissen.

Aus Spielersicht finde ich es ziemlich schade dass fast überall DirextX gepusht wird, aber wird wohl leider die Zukunft sein.
Was mir an OpenGL Programme immer wieder auffällt, ist dass es meistens sehr "sauber" programmiert ist und kaum Bugs enthällt, ev. ist es ja Zufall - aber dann waren es in den letzten 15 Jahre ziemlich viele Zufälle.

Das halte ich für eine Wahrnehmungstäuschung. Ich hab eher das Gegenteil im Kopf.

Mal abgesehen davon ist es logisch dass eine API die so viel mehr verwendet wird, dadurch auch absolut eine höhere Anzahl an "buggy" Spielen hat.

Und zweitens liegt der "Buggy"-Teil ja nicht zwingend am Grafikteil. Game-Logik-Bugs sind nur schwer über die Grafik-API zu erklären, nicht? Ich würde an deiner Stelle aufhören alle Bugs über einen Kamm zu scheren, da gibt's verschiedene Arten.

Aber was noch schöner ist, ist dass die Programme über Jahre hinweg immer laufen.

Auch das ist Schwachsinn. Kenn genügend Beispiele, wo alte Spiele maßgeschneidert auf damalige OpenGL-Implementationen hingeschnitten wurden (und somit auch auf deren Bugs), und jetzt nicht mehr laufen oder fehlerhaft laufen, da mittlerweile die Bugs in den OpenGL-Implementationen von ATI und NVIDIA gefixt wurden.

Das ist ja die perverse Situation bei OpenGL: oft muß man "um einen Bug" herumarbeiten; und wenn dieser Bug dann endlich von den Treiberentwicklern gefixt ist, funktioniert möglicherweise der Workaround auch nicht mehr.

Ich habe noch so einige DirecX 6 Games, die ich eigentlich immer noch spielen möchte, aber sie auf neuen Systeme nicht mehr zum laufen kriege und Patches von den Entwickler kommen bei 8- 10 Jahre alten Games auch nicht mehr...

Und du bist dir zu 100% sicher, dass dies an DirectX liegt, und nicht am restlichen Code des Spiels? Die Grafik-API innerhalb eines Spiels ist nämlich eher die Minderheit.

Inkompatibel kann eine Software durch komplett andere Dinge werden, die total unabhängig von DirectX sind.

Also an alle Entwickler, ich will wieder mehr OpenGL Games sehen!

Wie gesagt, ist alles eine ziemlich unlogische Argumentationslinie, die du nochmal überdenken solltest.

Ich sehe da aber auch einen gewissen Zusammenhang: Wer bereit ist, einen OpenGL-Renderer vernünftig zu implementieren, wird auch eher auf die Qualität des restlichen Produkts achten.

Ist trotzdem ein logischer Trugschluß, da hier der Umkehrschluß ("wer DirectX verwendet ist automatisch unsauberer" folgert sich nicht automatisch aus "wer OpenGL sauber implementiert, achtet auf Qualität") verwendet wird, der einfach nicht stimmt.

Ich glaube die Tools, die in DirectX den Entwicklern zur Verfügung stehen, beeinflussen eher direkt die Qualität des Produkts.

Ihr solltet euch mal das NVIDIA-Video zu NVPerfHUD anschauen (auf developer.nvidia.com oder auch auf Youtube). Das ist echt ein fantastisches Tool, das man gesehen haben muß; und ja, ich bin wirklich begeistert davon, weil ich dadurch schon etliche Bugs sehr komfortabel ausfindig hab machen können. Ich glaube die meisten hier wissen gar nicht wie mühsam Bugsuche sein kann (aber Hauptsache über Bugs meckern), und ein so komfortables und mächtiges Tool wie NVPerfHUD kann man hier gar nicht in Gold aufwiegen.

Oder aber, es liegt daran, dass die meisten OpenGL-basierten Spiele auf id-Engines basieren, die wiederum generell einen sehr hohen Qualitätsstandard haben.

Das wird's eher sein.

Ich denke, andersrum wird ein Schuh draus: wer den Luxus hat, sich alle Zeit der Welt für ein Produkt lassen zu können, hat möglicherweise auch den Luxus einfach aus Prinzip heraus OpenGL zu nutzen.

Das glaub ich auch. Wer alle Zeit der Welt hat, kann sich auch Zeit lassen bis ein Treiberhersteller eine fehlerhaft implementierte OpenGL-Spezifikation fixt.

Wer außer ID Software und die paar Lizenznehmer setzt denn überhaupt noch in der Windows Welt auf OpenGL?

In der Echtzeitgrafikforschung wird's nach wie vor recht gern verwendet, obwohl ich auch schon ein paar Forscher kenne, die mittlerweile Direct3D 10 verwenden.

Quaker

2008-01-27, 02:37:11

Das halte ich für eine Wahrnehmungstäuschung. Ich hab eher das Gegenteil im Kopf.

Mal abgesehen davon ist es logisch dass eine API die so viel mehr verwendet wird, dadurch auch absolut eine höhere Anzahl an "buggy" Spielen hat.

Und zweitens liegt der "Buggy"-Teil ja nicht zwingend am Grafikteil. Game-Logik-Bugs sind nur schwer über die Grafik-API zu erklären, nicht? Ich würde an deiner Stelle aufhören alle Bugs über einen Kamm zu scheren, da gibt's verschiedene Arten.
Quake 1, Quake 2, Quake 3, Quake 4, Doom 3, Prey, RTCW alles OpenGL und quasi Bugfrei - auf jeden Fall nichts was massiv stören würde und läuft alles auch Heute noch... sogar Doom 1 und Doom 2 läuft noch problemlos, seit man es auf OpenGL umgeschrieben hat.
Was für Gegenteiliges hast Du denn im Kopf?

Auch das ist Schwachsinn. Kenn genügend Beispiele, wo alte Spiele maßgeschneidert auf damalige OpenGL-Implementationen hingeschnitten wurden (und somit auch auf deren Bugs), und jetzt nicht mehr laufen oder fehlerhaft laufen, da mittlerweile die Bugs in den OpenGL-Implementationen von ATI und NVIDIA gefixt wurden.

Das ist ja die perverse Situation bei OpenGL: oft muß man "um einen Bug" herumarbeiten; und wenn dieser Bug dann endlich von den Treiberentwicklern gefixt ist, funktioniert möglicherweise der Workaround auch nicht mehr.
Dann sag mir welches OpenGL Game Heute nicht mehr auf einem aktuellen System läuft...

Und du bist dir zu 100% sicher, dass dies an DirectX liegt, und nicht am restlichen Code des Spiels? Die Grafik-API innerhalb eines Spiels ist nämlich eher die Minderheit.

Inkompatibel kann eine Software durch komplett andere Dinge werden, die total unabhängig von DirectX sind.
Wie soll ich da sicher sein?
Es sind einfach die DirectX Games die nicht mehr laufen - irgendwas muss ja dahinterstecken...

Wie gesagt, ist alles eine ziemlich unlogische Argumentationslinie, die du nochmal überdenken solltest.
Wenn ich an die oben erwähnten Games zurück denke ist für mich der Fall klar...
Ausserdem ist man, wie schon erwähnt wurde, mit der Plattform nicht so eingeschränkt wie bei DirectX, das müsste doch für die Entwickler auch ne Motivation sein.

Aber da Du ja Entwickler bist kannst Du ja ev. noch genauer erklären warum das mit DirectX so problematisch ist...

tokugawa

2008-01-27, 04:05:39

Quake 1, Quake 2, Quake 3, Quake 4, Doom 3, Prey, RTCW alles OpenGL und quasi Bugfrei - auf jeden Fall nichts was massiv stören würde und läuft alles auch Heute noch... sogar Doom 1 und Doom 2 läuft noch problemlos, seit man es auf OpenGL umgeschrieben hat.
Was für Gegenteiliges hast Du denn im Kopf?

Dann sag mir welches OpenGL Game Heute nicht mehr auf einem aktuellen System läuft...

Ich hab bei Quake 3 und Doom 3 durchaus Probleme gehabt, je nach Treiber.

Wie gesagt, "aktuelles System" ist bei OpenGL ein sehr unscharfer Begriff. Das kommt's sehr auf die Treiberversion an.

Wie soll ich da sicher sein?

Wenn man nicht sicher ist, keine so definitiven Aussagen machen. Ganz einfach.

Es sind einfach die DirectX Games die nicht mehr laufen - irgendwas muss ja dahinterstecken...

Mit derselben Argumentation wurde damals behauptet dass die Erde eine Scheibe ist, und allerhand anderer Unsinn. Die Argumentation "es sind immer die XYZ, bei denen ABC auftritt" wurde schon für allerlei Unheil und Vorurteile (auch gegen Menschen und Menschengruppen) verwendet.

Reine Beobachtung, und Kausalität sehen wo nur Konzidenz, maximal Korrelation ist.

Wenn ich an die oben erwähnten Games zurück denke ist für mich der Fall klar...

Du denkst also auch, dass die Erde eine Scheibe ist?

So klar ist hier nichts, das sollte dir hier klar sein. Hier muß man rational argumentieren und nicht nach Beobachtungen mutmaßen.

Ausserdem ist man, wie schon erwähnt wurde, mit der Plattform nicht so eingeschränkt wie bei DirectX, das müsste doch für die Entwickler auch ne Motivation sein.

Wieso sollte das eine Motivation sein? Und wieso "mit der Plattform", also Einzahl?

Motivation wär's wenn Plattformunabhängigkeit in OpenGL tatsächlich ohne Kopfschmerzen funktionieren täte. Das tut's nicht. Insofern ist es eher demotivierend.

Aber da Du ja Entwickler bist kannst Du ja ev. noch genauer erklären warum das mit DirectX so problematisch ist...

Ich hab schon einiges genau erklärt, warum OpenGL problematischer ist als DirectX zum derzeitigen Zeitpunkt.

Genau deswegen halte ich ja deine Beobachtungen für reinen Zufall. Weil ich's eben besser weiß.

Chris Lux

2008-01-27, 10:42:45

Bei DirectX hat man das in viel kleinerem Ausmaß, die API selbst bleibt von Treiber-"Ungenauigkeiten" unberührt.
im grunde ist es bei D3D ganz genauso. hat ein treiber probleme muss an diesen umhergearbeitet werden. die API ist auch bei OpenGL unberuehrt.

Mit anderen Worten: du stimmst mir ja eh zu, wenn du auch einsiehst dass die ATI-OpenGL-Treiberqualität ziemlich mies ist; genau das ist der Grund warum die Portabilität eigentlich großteils ein Papierfeature von OpenGL ist.
das problem ist eher das, dass es derzeit keine grossen OpenGL spieletitel gibt, die ATi zwingen ihre OpenGL treiber in griff zu bekommen. immer wenn eine neue id engine erschien waren sie gezwungen zu handeln. aber wie gesagt in der prof. welt tut sich gerade was und ich denke das schwappt auf jeden fall auch auf die consumer schiene ueber.

zu D3D10 in der forschung: ja, in der computergraphic forschung mag das sicher derzeit eine alternative sein (in geringerem ausmass IMO). schaut man aber etwas weiter kommen sachen, die mit D3D einfach nicht funktionieren, bspw. synchronisation mehrerer geraete, quad buffer stereo...

ich werde demnaechst auch mal einen kleinen teilaspect von mir auf D3D10 portieren, aber im grunde bleibt alles auf OpenGL, weil wir die system portierbarkeit und speziellen features einfach brauchen. OpenGL ist auch fuer mich nur ein werkzeug, wuerde es eines geben, mit dem ich meine arbeit besser machen koennte, muesste ich neu abwaegen. derzeit ist es aber keine frage.

Coda

2008-01-27, 17:08:43

im grunde ist es bei D3D ganz genauso. hat ein treiber probleme muss an diesen umhergearbeitet werden. die API ist auch bei OpenGL unberuehrt.
Bei D3D ist aber noch die Runtime davor, das heißt eine Fehlerquelle ist schonmal ausgeschlossen, zudem gibt's Regression-Tests wegen WHQL.

Chris Lux

2008-01-27, 17:49:48

Bei D3D ist aber noch die Runtime davor, das heißt eine Fehlerquelle ist schonmal ausgeschlossen, zudem gibt's Regression-Tests wegen WHQL.
naja es gibt ja eigentlich auch bei OpenGL konformanztests, aber die werden scheinbar nicht so konsequent gemacht. ich wuerde bei gl auch sowas wie ein siegel fuer treiber einfuehren (also jede neue treiberversion), welches aussagt ob der treiber standardkonform ist oder nicht.

Coda

2008-01-27, 18:12:14

Chris Lux

2008-01-27, 19:02:18

Natürlich. Aber wer hätte die Macht dazu? Microsoft will das sicher nicht machen. Außerdem fehlt OpenGL dafür eine offizielle Software-Referenzimplementierung (Mesa könnte man evtl. dafür nehmen).

Und dann bitte die Tests auch gleich publik machen, damit es jeder nachvollziehen kann.
Khronos koennte das machen, natuerlich nicht so zwingend wie MS fuer DX. aber selbst auf freiwilligenbasis kann das funktionieren, wenn ein IHV das als marketing punkt entdeckt. somit wuerde die OpenGL implementierungsqualitaet oeffentlich sichtbar, vielleicht mit einer treiber datenbank auf der offiziellen OpenGL seite. sowas hatte ich mal im offiziellen forum vorgeschlagen, aber leider gab es keinerlei feedback.

tokugawa

2008-01-27, 19:08:03

im grunde ist es bei D3D ganz genauso. hat ein treiber probleme muss an diesen umhergearbeitet werden. die API ist auch bei OpenGL unberuehrt.

Du verstehst nicht ganz. Bei OpenGL hab ich bei FBOs durchaus schon mal "gegen die Spec" implementieren müssen weil's nur dann funktioniert hat.

Sowas hab ich - bei allen Treiberproblemen - bei DirectX noch nie machen müssen.

das problem ist eher das, dass es derzeit keine grossen OpenGL spieletitel gibt, die ATi zwingen ihre OpenGL treiber in griff zu bekommen. immer wenn eine neue id engine erschien waren sie gezwungen zu handeln.

Hat aber nie was geholfen.

aber wie gesagt in der prof. welt tut sich gerade was und ich denke das schwappt auf jeden fall auch auf die consumer schiene ueber.

Wobei ich den Begriff "Professionelle Welt" sehr diskriminierend finde. Als ob andere "Welten", die hauptsächlich auf Consumer-Hardware zielen (dazu zählt auch die Echtzeitgrafikforschung und die Spieleindustrie) nicht "professionell" wären.

zu D3D10 in der forschung: ja, in der computergraphic forschung mag das sicher derzeit eine alternative sein (in geringerem ausmass IMO).

So gering ist das nicht. Ich kenne aktuelle Papers die gerade zur SIGGRAPH (letzte Woche war Paperdeadline) eingereicht wurden, die derzeit nur mit Direct3D10 gehen, da OpenGL 3.0 nicht auf die Reihe kommt.

schaut man aber etwas weiter kommen sachen,

Ich tät an deiner Stelle mal auch etwas "weiter" schauen. Sag, wirfst du mir hier grad vor einen beschränkten Horizont zu haben?

die mit D3D einfach nicht funktionieren, bspw. synchronisation mehrerer geraete, quad buffer stereo...

Stereo geht auch unter Direct3D, indirekt über MultiHead, aber doch. Ist halt nicht quadbuffered, aber du hast denselben Effekt.

Zumindest lässt sich damit die Quadro FX 5700 in unserem Seminarraum ansteuern damit (an der zwei Beamer hängen für ein Stereo-Setup).

OpenGL ist auch fuer mich nur ein werkzeug, wuerde es eines geben, mit dem ich meine arbeit besser machen koennte, muesste ich neu abwaegen. derzeit ist es aber keine frage.

Natürlich, wenn du es für das bessere Werkzeug hälst, dann benutz es halt.

Chris Lux

2008-01-27, 19:31:30

Wobei ich den Begriff "Professionelle Welt" sehr diskriminierend finde. Als ob andere "Welten", die hauptsächlich auf Consumer-Hardware zielen (dazu zählt auch die Echtzeitgrafikforschung und die Spieleindustrie) nicht "professionell" wären.
es gibt nunmal die zwei schienen, die sich auch so nennen: consumer und professional. mehr sollte das nicht heissen! diese sparten haben halt auch verschiedene anforderungen. so spielt bisher halt D3D in der professionellen sogut wie keine rolle und umgekehrt ist es halt heute auch genau umgekehrt.

So gering ist das nicht. Ich kenne aktuelle Papers die gerade zur SIGGRAPH (letzte Woche war Paperdeadline) eingereicht wurden, die derzeit nur mit Direct3D10 gehen, da OpenGL 3.0 nicht auf die Reihe kommt.
beispiel, was mit gl (ausser custom resolves) nicht geht? und wenn du kein reviewer bist woher willst du wissen, was alles an papers submitted wurde (eigene publikationen ausgenommen)?

Ich tät an deiner Stelle mal auch etwas "weiter" schauen. Sag, wirfst du mir hier grad vor einen beschränkten Horizont zu haben?
kann es sein, dass du ein wenig geltungssuechtig und auf unsinnige diskussionen aus bist?

Stereo geht auch unter Direct3D, indirekt über MultiHead, aber doch. Ist halt nicht quadbuffered, aber du hast denselben Effekt.
Zumindest lässt sich damit die Quadro FX 5700 in unserem Seminarraum ansteuern damit (an der zwei Beamer hängen für ein Stereo-Setup).
ich rede von quadbuffer stereo und du kommst mit multi-head. das kann ich auch mit ner alten TNT2 machen...