OpenGL bzw. DirectX [Archiv]

Archiv verlassen und diese Seite im Standarddesign anzeigen : OpenGL bzw. DirectX

Karümel

2001-12-25, 10:44:23

Ich wußte nicht genau in welches der Foren diese Thema gehört, falls das hier nicht reinpasst, tschuldigung.

Könnte mir bitte jemand mal genauer OpenGL und DirectX erklären. Ich weiß eigentlich kaum was genaueres über diese beiden Sachen. Das einzige was ich "weiß" sind das das beides Programmierschnittstellen sind. DirectX kommt von Mircosoft, bei OpenGL weiß ich das nicht mal.

Und wie "beeinflussen" die sich gegenseitig. Wenn man z.B. OpenGL Games spielt wie RtCW, brauch man doch trotzdem eine aktuelle Version von DirectX auf dem Rechner, wieso? Sound, Eingabegeräte?

Andre

2001-12-25, 13:26:32

Na da freu ich mich schonmal auf die Antworten von nggalai, Xmas und aths :)

aths

2001-12-25, 18:07:33

Um die Grafik in Windows direkt ansprechen zu können, braucht man DirectX. Dabei ist es erst mal egal, ob die Grafikberechnungen auch von DirectX oder von OpenGL gemacht werden.

Glide ist etwas anderes, da direkt an eine propritäre Hardware gebunden.

OpenGL bietet alle möglichen Bibliotheken, was Grafikrendering betrifft. Die Initialisierung des Bildschirmes erfordert ein paar Windows-Systemaufrufe. Hier kommt DX ins Spiel. Xmas wird hier sicher konkreter werden können.

DirectX ist eine monolithische, an Windows gebundene und damit propritäre Schnittstelle. Vorteilhaft ist, dass fast alle Effekte auch in Software implementiert sind. So konnte ich mir Enviromental Bump Mapping dank DX8 SDK auch auf einer Voodoo ansehen - das Bild hat allerdings mein Athlon, und nicht der VSA-100 berechnet. Kurz, wenn ich eine Anwendung für DX7 schreiben würde, weiss ich von vorn herein, welche Features ich nutzen kann.

Nachteilig an D3D ist die CPU-lastigkeit. Die Instruktionen passieren auch bei OpenGL in der Regel mehrere Layer, ehe endlich die Hardware-Register der Grafikkarte angesprochen werden. Bei D3D ist der Verwaltungs-Aufwand besonders groß.

OpenGL bietet an sich, je nach Version, nur eine relativ kleine Anzahl an Features. Dann gibt es etliche standardisierte Extensionen. Man kann ihr Vorhandensein abfragen und sie dann ggf. nutzen. 3dfx, ATI und nVidia haben noch jeweils eigene Extensionen hinzu gefügt, die dann theoretisch hardwarespezifisch sind (grundsätzlich aber von anderen Herstellern übernommen werden können.)

Man kann die Grafik mit OpenGL machen, aber Input und Sound mit DirectX, wie du schon geschrieben hast.

Quasar

2001-12-25, 22:01:28

es heißt "proprietäre".... ;)

P.S.: Gibt es einen gravierenden Unterschied zwischen Environment Mapped Bump Mapping und Environmental Bump Mapping?
Oder ist das eine nur der Matrox-Ausdruck und das andere der offz. DX-Sprachgebrauch, i.e. Microsoft-Ausdruck?

Ceiser Söze

2001-12-25, 23:41:30

Enviroment Mapped Bump Mapping und Enviromental Bump Mapping ist genau das Gleiche (und kommt übrigens ursprünglich von Bitboys :D ).

nggalai

2001-12-26, 09:12:05

Ich habe aths' Posting im Allgemeinen nichts mehr zu ergänzen ...

Hmm ...

OK, das hier nochmals anders ausgedrückt:

DirectX ist, wie aths schon erwähnte, eine Microsoft-proprietäre Programmierschnittstelle, von Microsoft entwickelt und fertig verteilt, i.e. SDK, Binaries etc werden von Microsoft vertrieben. OpenGL andererseits gibt's nicht nur für die meisten Betriebssysteme, sondern ist eigentlich nicht mal eine "fertige" Schnittstelle: OpenGL ist "nur" die Spezifikation, nach welcher Programmierer (Treiber, OS, etc) die Schnittstelle implementieren sollen.

Soviel mal von mir, bin noch müde und sollte zu Morgen essen ... :)

ta,
.rb

GloomY

2001-12-26, 16:26:03

GL ist ursprünglich doch mal von SGI entwickelt worden, dann wurde es aber Open, also öffentlich, so daß auch andere Hardwarehersteller kompatible Treiber schreiben konnten.

So viel ich weiß, gab's auch mal einen Versuch von Microsoft und SGI eine gemeinsame Grafikschnittstelle zu schaffen (Name leider entfallen). Das ist aber mangels Interesse von M$ wieder abgeblasen worden...

Thowe

2001-12-26, 17:40:48

Project Fahrenheit

Xmas

2001-12-26, 19:58:39

Originally posted by aths
OpenGL bietet alle möglichen Bibliotheken, was Grafikrendering betrifft. Die Initialisierung des Bildschirmes erfordert ein paar Windows-Systemaufrufe. Hier kommt DX ins Spiel. Xmas wird hier sicher konkreter werden können.
Hehe. Man braucht kein DX, um OpenGL-Programme ablaufen zu lassen. Die Initialisierung erfolgt über Windows- bzw. WGL-Befehle. Der Eindruck dass für schnelle Grafik und den "Direktzugriff" auf die Hardware DirectX nötig sei, stammt noch aus den Anfangstagen von Win95, das zunächst noch ohne OpenGL-Unterstützung ausgeliefert wurde. Und GDI erlaubt keinen "Direktzugriff".
Mit dem kommenden OpenGL 2.0 wird die Basisfunktionalität enorm erweitert, weil es endlich eine einheitliche, C-ähnliche Shader-Sprache geben wird.

Die einzige Art, in der sich OpenGL und DirectX "beeinflussen", ist dass OpenGL und DirectGraphics (D3D + DDraw) sich gegenseitig aussschließen.

Razor

2001-12-26, 23:48:48

Nur das eben OpenGL 'nur' für die Visualisierung zuständig ist und zu einem Spiel ja noch 'ne Menge mehr gehört...
;-)

Insofern wird bei heutigen OpenGL-Spielen natürlich i.d.R. auch DirectX benötigt, um eben die unterschiedlichen Eingabe-Geräte zu nutzen und auch die Multiplayer-Funktionalität (Netzwerk-Basis) zu integrieren. Aber klar, wie Xmas ja schon schrieb, schließen sich D3D (als Teil von DirectX, welches u.a. ja noch DirectSound, DirectPlay etc. enthält) und OpenGL aus. Natürlich ist es auch möglich, beides in einem Game zu nutzen, nur eben nicht gleichzeitig (macht i.d.R. aber keinen Sinn ;-).

In diesem Sinne

Razor

KiBa

2001-12-27, 00:38:46

Originally posted by aths
Um die Grafik in Windows direkt ansprechen zu können, braucht man DirectX. Dabei ist es erst mal egal, ob die Grafikberechnungen auch von DirectX oder von OpenGL gemacht werden.

Falsch, die eigentliche OpenGL-Implementation kommt schon seit längerem nur noch von den Grafikchips-Entwicklern, WindowsXP z.B. hat gar keine Unterstützung mehr für Hardwarebeschleunigtes Opengl.
Somit liegt es am Treiberentwickler, ob DirectX mit benutzt wird oder nicht.

OpenGL bietet alle möglichen Bibliotheken, was Grafikrendering betrifft. Die Initialisierung des Bildschirmes erfordert ein paar Windows-Systemaufrufe. Hier kommt DX ins Spiel. Xmas wird hier sicher konkreter werden können.

Siehe oben, man braucht nur die Windows-API und nicht DX für OpenGL, das kann natürlich von Implemantation zu Implementation verschieden sein.

DirectX ist eine monolithische, an Windows gebundene und damit propritäre Schnittstelle.

Was verstehst du unter monolithisch? WindowsXP hat wie alle moderenen Betriebssysteme keinen monolithischen Kernel mehr, da wird wohl die DX-API nicht noch monolithisch sein. Falls du die fehlende Möglichkeit meinst, Extensions einzubauen, geb ich dir recht...

Vorteilhaft ist, dass fast alle Effekte auch in Software implementiert sind. So konnte ich mir Enviromental Bump Mapping dank DX8 SDK auch auf einer Voodoo ansehen - das Bild hat allerdings mein Athlon, und nicht der VSA-100 berechnet. Kurz, wenn ich eine Anwendung für DX7 schreiben würde, weiss ich von vorn herein, welche Features ich nutzen kann.

Seit DX8 gibt es keinen Software-Renderer mehr. Nur noch den Referenz-Rasterizer, der aber extrem genau und langsam arbeitet, als Bildqualitätsreferenz sozusagen. Damit können Programmierer ohne spezielle Hardware schon die neuesten Features ausprobieren.

Nachteilig an D3D ist die CPU-lastigkeit. Die Instruktionen passieren auch bei OpenGL in der Regel mehrere Layer, ehe endlich die Hardware-Register der Grafikkarte angesprochen werden. Bei D3D ist der Verwaltungs-Aufwand besonders groß.

Falsch, es kommt auch hier wieder auf die spezielle Implementation an. Meistens ist D3D bedeutend schneller als OGL, eine leere Szene zu rendern geht bei Nvidia-Karten z.B. fast doppelt so schnell. Auch bei Polygon-Tests liegt D3D vorn. Das liegt am Exklusiv-Modus, den D3D im Fullscreen bekommt. Bei Füllraten-limitierenden Anwendungen sind dann beide APIs wieder gleich schnell.

OpenGL bietet an sich, je nach Version, nur eine relativ kleine Anzahl an Features. Dann gibt es etliche standardisierte Extensionen. Man kann ihr Vorhandensein abfragen und sie dann ggf. nutzen. 3dfx, ATI und nVidia haben noch jeweils eigene Extensionen hinzu gefügt, die dann theoretisch hardwarespezifisch sind (grundsätzlich aber von anderen Herstellern übernommen werden können.)

IMO wird OpenGL viel zu langsam standardisiert, die ganzen Herstellerspezifischen Extensions machen das ganze irgendwie propritär. (richtig geschrieben?) OpenGL hat dafür den Vorteil, dass immer die neuesten Features unterstützt werden, allerdings läuft das ganze dann nur auf entsprechender Hardware.
Es sind halt beides sehr unterschiedliche Ansätze einer Grafik-API, beide mit Vor- und Nachteilen. Wer für mehrere Betriebssysteme programmieren will, kommt halt um OpenGL nicht herum. IMO muss es von OpenGL aber viel öfter neue Versionen geben, damit diese API im Spielesektor nicht untergeht, besonders angesichts dessen, dass sich Microsoft nun deutlich davon distanziert!

Xmas

2001-12-27, 02:10:59

KiBa, mein Posting hast du aber gelesen, oder? ;)
OpenGL 2.0 wird hoffentlich vieles, was bei OpenGL in letzter Zeit schiefgelaufen ist, wieder bereinigen. Der Entwurf von 3DLabs ist vielversprechend.

aths

2001-12-27, 14:24:54

Kiba,

ich habe zugegebenermaßen einiges vereinfacht dargestellt. Was auch daran liegt, dass mir die programmtechnischen Interna nicht sehr geläufig sind. Statt ständig "Falsch" zu schreiben hätte eine Bemerkung ausgereicht, dass die Darstellung ungenau ist.

Zur Geschwindigkeit: Lt. 3dcenter News ist RtCW in Linux je nach Lage deutlich schneller. Immerhin handelt es sich um ein OpenGL-Spiel.

Andre

2001-12-27, 15:18:48

Originally posted by aths
Kiba,

ich habe zugegebenermaßen einiges vereinfacht dargestellt. Was auch daran liegt, dass mir die programmtechnischen Interna nicht sehr geläufig sind. Statt ständig "Falsch" zu schreiben hätte eine Bemerkung ausgereicht, dass die Darstellung ungenau ist.

aths,

sorry, aber da muss ich jetzt mal einhaken.
Warum darf er nicht sagen, dass es falsch ist, wenn es doch eben falsch ist ?
Warum soll er "ungenau formuliert" sagen, wenn es nunmal nicht stimmt ?
Soviel Kritik musst auch Du mal vertragen, da Kiba auch nicht einfach falsch sagte, sondern dies auch begründete.
Kiba kann ja nicht wissen, dass Du vielleicht das Richtige meintest und auch das Richtige weisst, es aber falsch ausgedrückt hast.

Ich sag auch niemanden, der behauptet, dass 1+1 = 4 ist, dass das "ungenau formuliert" sei.

aths

2001-12-28, 14:21:34

Andre,

Kiba darf sagen, was er will. Ich schrieb nicht, er dürfe nicht, sondern das und das hätte ausgereicht. Gerade die beiden Stellen, wo seine Einleitung "Falsch," war, halte ich für eine Frage der (präziseren) Formulierung. So falsch ist das jedenfalls in meinen Augen nicht. Eine positive Kritik hätte die Lust gefördert, das zu begründen, was ich mir ja nun ersparte.

Andre

2001-12-28, 14:43:35

Wenn Du Dich so leicht aus der Bahn werfen lässt...

aths

2001-12-28, 14:49:14

:-D Ich bin sensibler, als einige glauben :-D

so, genug gespammt... für heute

Andre

2001-12-28, 14:57:48

aths,

nur noch eine klitze-kleine Anmerkung:

"was ich mir ja nun ersparte."

Dieses Satzende verwirrt mich.
Wie kannst Du Dir in der Gegenwart (ja nun) etwas ersparen, was Du Dir schon erspart hast (ersparte -> Vergangenheitsform) ?

"was ich mir ja nun erspare", wäre aus meiner Sicht die richtige Formulierung.

KiBa

2001-12-28, 16:19:19

@aths
Ich habe 2x "Falsch" geschrieben, und beide Absätze auf die ich mich bezog waren auch schlichtweg falsch. Anstatt Gegenargumente zu bringen, fängst du eine Meta-Diskussion an (die ich hier weiterführe, man vegebe mir ;) ). Bitte beziehe dich auf diese zwei Absätze und sage mir, warum mein "Falsch" hier unangebracht ist, und hör auf, anderen Diskutierstil zu kritisieren, wenn du es nicht besser kannst.

aths

2001-12-28, 17:49:57

Andre,

ich ersparte es mir bereits in der Vergangenheit. Nämlich da, wo ich an Kibas Ausdruck herum mäkelte.

Kiba, (steht das wirklich für Kirsch-Banane?)

ich habe keine Lust auf große Diskussionen um Kleinigkeiten. Aber wenn du willst... "Um die Grafik in Windows direkt ansprechen zu können, braucht man DirectX. Dabei ist es erst mal egal, ob die Grafikberechnungen auch von DirectX oder von OpenGL gemacht werden."

Der erste Satz ist ungenau bis falsch. Natürlich spricht man auch mit OpenGL die Grafik direkt an. Man braucht für die Inititalisierung Zugriff auf Windows-Bibliotheken. Diese vermutete ich in DirectX, das mag falsch sein. Wenn beides auf XP nicht zutrifft, kann das sein -> ich habe kein XP und habe auch nicht vor, es zu haben.

"Nachteilig an D3D ist die CPU-lastigkeit. Die Instruktionen passieren auch bei OpenGL in der Regel mehrere Layer, ehe endlich die Hardware-Register der Grafikkarte angesprochen werden. Bei D3D ist der Verwaltungs-Aufwand besonders groß."

Du führst nun einige synthetische Beispiele an. Da führe ich nun als Beispiel an, dass DX-Spiele in der Regel stärker mit der CPU skalieren, als OpenGL-Titel. Des weiteren denke ich, dass DX wegen der allgemeinen Verwendbarkeit mindestens einen zusätzlichen Layer braucht.

Wenn ich DX als monolithisch bezeichne, so hatte ich dabei nicht den Aufbau eines monolithischen OS im Kopf, was du aber mit ins Spiel gebracht hast. Mit monolithisch meine ich in sich abgeschlossen und definiert, ohne erweiterbar zu sein. Es steht genau fest, was DX2, 3, 5, 6, 7 oder 8 kann. Es herrscht keine Molurarität, so dass man zusätzliche Komponenten mitbringen könnte.

Ich schrieb: "Vorteilhaft ist, dass fast alle Effekte auch in Software implementiert sind." und da machst du Unterschiede zwischen Referenz-Rasterizer und Software-Renderer. Wir sind uns vermutlich darin einig, dass beides in SW implementiert ist. Mehr sagte ich da auch nicht.

KiBa

2001-12-28, 19:34:34

Originally posted by aths
Kiba, (steht das wirklich für Kirsch-Banane?)

Nein... ;)

Man braucht für die Inititalisierung Zugriff auf Windows-Bibliotheken. Diese vermutete ich in DirectX, das mag falsch sein. Wenn beides auf XP nicht zutrifft, kann das sein -> ich habe kein XP und habe auch nicht vor, es zu haben.

Sie sind soweit ich weiß in allen Windowsversionen nicht in DirectX sondern in der WinAPI enthalten. Sorry, wenn dich das "Falsch" geärgert hat, aber genau das war es... ;)

Du führst nun einige synthetische Beispiele an. Da führe ich nun als Beispiel an, dass DX-Spiele in der Regel stärker mit der CPU skalieren, als OpenGL-Titel. Des weiteren denke ich, dass DX wegen der allgemeinen Verwendbarkeit mindestens einen zusätzlichen Layer braucht.

Sowas wie eine HAL (Hardware Abstractiion Layer) gibt es sicherlich auch in OpenGL Implementationen. D3D ist vor allem wegen des direkten Zugriffs auf die Hardware etwas schneller als OpenGL, wo die Treiberprogrammierer immer etwas tricksen müssen. Da musst du dich dann aber wohl bei MS beschweren.

Wenn ich DX als monolithisch bezeichne, so hatte ich dabei nicht den Aufbau eines monolithischen OS im Kopf, was du aber mit ins Spiel gebracht hast. Mit monolithisch meine ich in sich abgeschlossen und definiert, ohne erweiterbar zu sein. Es steht genau fest, was DX2, 3, 5, 6, 7 oder 8 kann. Es herrscht keine Molurarität, so dass man zusätzliche Komponenten mitbringen könnte.

Da gebe ich dir Recht!

Ich schrieb: "Vorteilhaft ist, dass fast alle Effekte auch in Software implementiert sind." und da machst du Unterschiede zwischen Referenz-Rasterizer und Software-Renderer. Wir sind uns vermutlich darin einig, dass beides in SW implementiert ist. Mehr sagte ich da auch nicht.

Ich habe mit keinem Wort deine Aussage für falsch erklärt, sondern nur ergänzt. Zum Ausdruck bringen wollte ich nur, dass der eigentliche Software-Renderer seit DX8 fehlt und das der Ref-Rasterizer nur für Programmierer gedacht ist.

Andre

2001-12-28, 19:57:02

Originally posted by aths
Andre,

ich ersparte es mir bereits in der Vergangenheit. Nämlich da, wo ich an Kibas Ausdruck herum mäkelte.

Aha,

trotzdem kannst Du Dir etwas nicht ersparen, was Du Dir bereits in der Vergangenheit erspart hast.
Folglich müsste das Satzende dann "was ich mir dann ersparte" oder "was ich mir aufgrund KiBa´s Äußerung ersparte" lauten.

OK, genug über formale Dinge geplaudert. ;)

2002-01-03, 02:46:57

So, dann geb ich mal meinen Senf dazu:

http://www.tommti-systems.com/main-Dateien/reviews/opengldirectx/openglvsdirectx.html

D3D vs. OpenGL -> Thema Geschwindigkeit

D3D ist etwa 5% langsamer, liegt einfach am Modell der Aufrufe.... OpenGL hat da den Vorteil, direkt die Extensionen der Hersteller verwenden zu können. Viel direkter gehts nicht. Bei beiden API's spielt der Grafiktreiber eine entscheidende Rolle, was den Speed angeht.

@KiBa
"...
Sowas wie eine HAL (Hardware Abstractiion Layer) gibt es sicherlich auch in OpenGL Implementationen. D3D ist vor allem wegen des direkten Zugriffs auf die Hardware etwas schneller als OpenGL, wo die Treiberprogrammierer immer etwas tricksen müssen. Da musst du dich dann aber wohl bei MS beschweren.
..."

Jede Hardware-API ist im Grunde ein HAL (mwhr oder weniger ist mit HAL auch nicht gemeint), da ja keiner in Maschinensprache programmieren möchte....
D3D greift auch nicht direkter als OpenGL auf die Hardware zu.

Gutes Beispiel Serious Sam - ein paar Effekte abschalten, welch unter D3D nicht so schnell machbar waren wie unter OpenGL und es gibt kaum noch Unterschiede.

Gruß
Thomas

2002-01-03, 02:53:03

...ups

KiBa

2002-01-03, 10:36:06

D3D ist etwa 5% langsamer, liegt einfach am Modell der Aufrufe.... OpenGL hat da den Vorteil, direkt die Extensionen der Hersteller verwenden zu können. Viel direkter gehts nicht. Bei beiden API's spielt der Grafiktreiber eine entscheidende Rolle, was den Speed angeht.

Da habe ich andere Erfahrungen beim programmieren gemacht. D3D war bei einfachen Szenen sehr viel schneller als OpenGL, je komplexer es wurde, umso mehr näherten sich die beiden APIs an. Und das trotz Verwendung von propietären Extensions wie z.b. "Vertex Array Range" von Nvidia.
Und das UT bei diesem Artikel als Referenz genommen wurde, ist lachhaft. UT ist massiv CPU-abhängig, und die D3D und OpenGL Renderer kann man nur als Beta bezeichnen.

Jede Hardware-API ist im Grunde ein HAL (mwhr oder weniger ist mit HAL auch nicht gemeint), da ja keiner in Maschinensprache programmieren möchte....
D3D greift auch nicht direkter als OpenGL auf die Hardware zu.

Das stimmt wie du es gesagt hast, allerdings bekommen D3D-Programme im Vollbild im Gegensatz zu OpenGL einen Exklusiv-Modus von Windows, wodurch andere Windows-Programme fast keine Rechenzeit bekommen. Das erklärt die besseren Ergebnisse von D3D bei einfachen Szenen.

Gutes Beispiel Serious Sam - ein paar Effekte abschalten, welch unter D3D nicht so schnell machbar waren wie unter OpenGL und es gibt kaum noch Unterschiede.

Ich glaube nicht, dass man anhand von einem Spiel mit 2 Renderern unterscheiden sollte. Ich denke, Serious Sam ist in erster Linie auf OpenGL hin optimiert, IMO wurde mit Sicherheit mehr Zeit der Programmierung damit verbracht. Der D3D Modus kam vielleicht hinzu, wegen Treiberproblemen unter OpenGL bei einigen Grafikkarten.
Nascar4 z.B. läuft unter D3D ca 5-10% schneller als unter OGL auf meiner GTS in 1152x864x32. Das wäre mein Gegenbeispiel...

nggalai

2002-01-04, 18:49:59

Zum Thema "OpenGL und DirectX" war gestern was passendes im DXDEV-Newsletter drin, was ich hier mal kommentarlos posten möchte (E-Mail-Adressen hab' ich gelöscht):

From: Mark Collins
Subject: DIrect3D And OpenGL?

No, this isn't a comparison, but...

I'm writing a lil' OpenGL app (with no DirectX code yet), but for some
reason, the following error is appearing in the debug output:

===
Direct3D8: (ERROR) :No attached clipper
===

So I did a lil' investigating after turning up the debug level. Every call to
ChoosePixelFormat(), SetPixelFormat(), wglCreateContext() and
wglMakeCurrent() create new DirectDraw surfaces, but only ChoosePixelFormat()
frees up any drivers created after it was called, and only 1 driver is
destroyed when the application quits.

I'm also getting lots of exceptions being reported while all the DirectX
stuff is going on (in GDI32.DLL, 0xC0000005: Access Violation).

Anyone else get this? Is this normal? Is it a plot by Microsoft to trick
DirectX-hating OpenGL-luvin coders into using the things which they despise
with more passion than a purple fruit? Find out next wekk on Batman...

===
Mark 'Nurgle' Collins
Lead Author - Linux Game Programming (Premiere Press)
Author - Advanced AI Game Development (WordWare)

***

Date: Thu, 3 Jan 2002 10:54:47 -0500
From: Ron Fosner
Subject: Re: DIrect3D And OpenGL?

You have a 3D board, no? Sounds like you've discovered that this particular
board manufacturer has an OpenGL wrapper around their Direct3D/Draw driver.
Not a bad thing, but certainly not entirely pleasing. I too have run into
bugs like this. It's best to send some sample code to the card companies and
let them fix it. First make sure that your code runs in software mode, and
fails in hardware with the latest drivers.

The Access Violations are GDI calling into the (probably) OpenGL API and
discovering that the function pointers are null, then this generates an
exception that's being caught, the interface is loaded, and the program goes
on it's merry way. It's been this way since Win NT 3.5 IIRC

***

Date: Thu, 3 Jan 2002 20:07:42 +0000
From: Mark Collins
Subject: Re: DIrect3D And OpenGL?

On Thursday 03 January 2002 5:45 pm, you wrote:
> It's maybe one of the older Matrox cards, which had OGL -> D3D wrappers. That
> GDI thing is well known and is supposed to be ignored, guaranteed to be
> safe.
>
> Tim

It's an S3 ProSavage. The OpenGL drivers are the MIcrosoft ones that ships
with Windows 98 (according to SysInfo, anyway), so I guess it's using
software atm.

Nurgleta,
.rb

2002-01-04, 19:02:44

Es ging in diesem Artikel nich vorwiegend um Geschwindigkeitsunterschiede. Das sollte mein "D3D vs. OpenGL -> Thema Geschwindigkeit" nicht ausdrücken, sondern nur, dass ich dazu jetzt was schreiben wollte.

Eben weil UT sehr CPU abhängig ist, sollte möglichst wenig Zeit in der API / den Treibern verschwendet werden. Da ich von D3D & OpenGL jeweils die letzten BETA Dll's einsetzte, kann es durchaus sein, das die Programmierer bei Epic unfähig sind, kann aber auch sein, dass OpenGL bei richtiger Verwendung ein wenig schneller ist.

Exclusiv-Modus: Gibt es bei DirectDraw, DirectInput, DirectSound

Seit DX8 verwendet man kein DirectDraw mehr um in den Fullscreen-Modus zu schalten (zumindest nicht bei 3D-Applikationen). CreateDevice erledigt dies nun, dort gibt es kein exclusiv mehr.
Man kann übrigens auch mit DirectDraw in den Fullscreen-Modus schalten und dann mit OpenGL darauf zugreifen.

Serious Sam:

Die API - OpenGL / DirectX machen nur recht wenig bei einer komplexen 3D-Engine aus. Sicher ist Serious Sam nur mit OpenGL entwickelt worden, jedoch zeigt die erweiterung auf DX8, dass es auch dort recht gut läuft. Die Geschwindigkeitsunterschiede der API's sind also recht klein, wenn man ein paar Regeln(der jeweiligen API) beachtet.

KiBa

2002-01-05, 01:24:05

"CreateDevice erledigt dies nun, dort gibt es kein exclusiv mehr"

Da steht im DX8.1 SDK aber was anderes, der exklusiv-Modus ist default bei Fullscreen.

2002-01-05, 02:26:10

Kannst Du mir zeigen wo?

P.S. Exklusiv regelt nur den Zugriff auf die jeweilige Schnittstelle. Deswegen ergeben sich aber kaum/keinerlei Performancegewinne, da die Priorität nicht steigt.

Thomas

Unregistered

2002-01-21, 22:56:29

Also. Wieso ist Q3 denn so schnell mit OpenGL und z.B. Homeworld zeigt auch keinen unterschied zwischen D3D und OpenGL in der performance. Nur das OpenGL ein schoeneres shading hat.

Ich denke es ist im wesentlichen davon abhänig ob man fuer die OpenGL API oder D3D API geschrieben hat. Ich glaube nicht, das man beim Design darauf keinen wert legen muss. Unreal z.B. hat es nicht so richtige geschaft einen vernuenfigen OpenGL Treiber zu bauen. Das kann mit dem Design zusammen haengen. Jede API fordert ihr spezielles Design.

Wahrscheinlich wurden sehr haeufig D3D benchmarks auf OpenGL umgesetzt. Aber, sind auch OpenGL benchmarks auf D3D umgesetzt worden? Ich habe von keinen gehoert.

tikiman

2002-01-23, 01:10:51

Also mein persönlicher Eindruck ist ja, daß OpenGL-Games für gewöhnlich deutlich besser performen als D3D-Games. Mir fällt jedenfalls auf Anhieb keine D3D-Engine ein, die performance-technisch auch nur annähernd an die Q3A-Engine herankäme. Oder kommt das dann eher durch Carmack´s Programmier-Künste und nicht direkt durch die API an sich?

Major

2002-03-09, 10:09:29

mich würde auch mal interessieren warum Carmack immer auf Opengl setzt, denn wenn DX sogar schneller ist wäre es doch quatsch bei OpenGL zu bleiben.
Und die Plattformunabhängigkeit ist doch bei Spielen nicht sehr wichtig, ich mein wieviele Spiele verkauft man als Linux oder Mac Version?

Xmas

2002-03-09, 15:24:02

Carmack ist einer, der es sich erlauben kann, auch aus "politischen" Gründen bei OpenGL zu bleiben. Außerdem spielt er gerne mit neuen Technologien rum, und da kommt die Extension-Struktur von OpenGL gerade recht.

2002-03-09, 17:48:12

Ganz Deiner Meinung Xmas. OpenGL hat eindeutig weniger Overhead(gerade bei Verwendung von mehreren Herstellerextensions), was vorallem an den Extensions liegt, die recht gut auf die jeweilige GPU abgestimmt sind. Die Treiberentwicklung scheint auch einfacher zu sein, da der OpenGL-Teil ja recht klare Trennungen mittels der Extensions vornimmt. Ohnen die Herstellerextensions bietet OpenGL 1.3 ja nur geringe Möglichkeiten, wenn man mal alle Features einer R200 / GF3/4 betrachtet. Die neuen OpenGL 2.0 Doc's sehen jedenfalls sehr vielversprechend aus, da würde ich auf jedenfall OpenGL 2.0 vor DX9 bevorzugen. Hoffentlich raufen sich die Hersteller zusammen und drücken OpenGL 2.0 möglichst schnell durch. Platformunabhängigkeit ist auf jeden Fall ein wichtiger Vorteil(bei Spielen sicher weniger als bei anderen Anwendungnen), meiner Meinung nach.

Thomas

Xmas

2002-03-09, 18:31:11

OpenGL mit DX9 zu vergleichen, ist aber auch nicht ganz fair. DX9-Hardware ist ja schon in weit fortgeschrittener Entwicklung, was sich von OGL 2.0 Hardware wohl kaum sagen lässt. Bis dahin könnte D3D schon einen Schritt weiter sein.

2002-03-09, 18:36:37

Okay, nehmen wir DX10 ;) - irgend ne Ahnung, wie es mit der zeitlichen Abfolge bei OpenGL aussieht? Kommt erst noch 1.4, oder gleich 2.0? Und wann....

Thomas

zeckensack

2002-03-10, 17:49:32

Oh gottogott!

1) DirectX greift nicht 'direkter' auf die Hardware zu. Das Gegentum ist der Fall. DirectX hat zwei Schichten zwischen Anwendung und HW, M$' DirectX-Schicht>Treiber->Hardware. OpenGL-Treiber - die ja immer vom Grakahersteller kommen - setzen direkt auf der Hardware auf, genauso wie die GDI-Treibers und der hardwarespezifische Teil von DirectX. Ihr könnt euch sicher vorstellen, daß wenn irgendwer weiß, wie man den Chip direkt programmiert, dann isses der Hersteller, nicht Microsnot.

2) OpenGL benutzt DirectX nicht. Wenn der Treiberschreiber sich dazu entschliessen sollte, DX-Zeugs zum Moduswechsel und zur Speicherreservierung zu benutzen, bitteschön. An dem Punkt kostet das leistungsmässig nichts und er kann es sich sparen, den gleichen Schrott dreimal (GDI, DX, OpenGL) zu programmieren. GDI-Treibers sehen Reservierung von AGP on Onboardspeicher nicht vor, daher nimmt man halt die DirectX-Schicht, wo alles schon drin ist. Die allermeisten Grakatreiber nehmen das auch her, wenn man einfach nur die Desktopauflösung ändert.

3) OpenGL braucht nicht unbedingt mehr Versionen. Die ständigen Versionssprünge von Direct3D sind lediglich der Beweis, daß es aufgrund seiner Architektur nicht erweiterbar ist und daher nicht mit der Hardwareentwicklung schritthalten kann, deshalb muß es im Jahresturnus weggeschmissen und neu gemacht werden. In OpenGL kann jeder Chiphersteller nach Belieben Funktionen einfügen, wann immer es grad paßt.

4) Der von Microsoft vorgegebene Funktionsumfang der Versionen, garantiert nicht, daß ein DirectX#soundso Spiel auf jeder Hardware läuft. Pixel Shader, irgendjemand??? DirectX7 hat gerade mal mit OpenGL 1.1 gleichgezogen, bis dahin ließ sich alles was fehlte, in Software emulieren. Allerdings, die ganzen Operationen, die sich mit einzelnen Pixeln befassen - und nicht mit ganzen Dreiecken - kann keine Sau auf der ganzen Welt in Software machen. Es sei denn, man verzichtet ganz auf Hardwareverschnellerung. Beweis dafür: 3DMark2k1, nature demo, pixel shader test, EMBM, Dot3 etc pp. Geht nicht ohne hardwareseitige Unterstützung. Spätestens ab DX8 macht es also auch keinen Sinn mehr, auf den OpenGL extensions rumzuhacken. Wenn man für DX8 programmiert, muß man auch nachprüfen, ob die Hardware das unterstützt, was man haben will.

5) Geschwindigkeit. Theoretisch gleich mit minimalem Vorteil für OpenGL. Hängt von der Treiberqualität ab. Man kann natürlich immer Szenarien konstruieren, wo das eine oder andere gewinnt. OpenGL hat viel weniger Overhead als Direct3D, wenn man also immer nur den Bildschirm blau ausmalt und zählt, wie oft man das pro Sekunde machen kann, dann gewinnt OpenGL. In der Praxis spielt das aber keine Rolle, je komplexer die Szenerie wird, desto mehr hängt's von der Hardware ab.

6) Funktionalität. Identisch. Direct3D hat in den Kindertagen (ie bis inklusive Version 7) praktisch alles von OpenGL geklaut. OpenGL kann sich schneller und in kleineren Schritten weiterentwickeln, macht aber nix bei der 'Geschwindigkeit' mit der Softwarehersteller neue Funktionen benutzen. Direct3D hat Vorteile bei der Ressourcenverwaltung (zB Geometrie direkt aufm Graka-RAM speichern), weils eben nur auf x86&Windows laufen muss, OpenGL auch aufm Gameboy Advance :D . Die Chiphersteller schmeissen aber alles was der Chip zu bieten hat früher oder später als extension nach, gibts dann halt nur aufm PC.

Boah.
Bevor jemand fragt, ich programmiere ganz fürchterlich viel in OpenGL, wer's nicht glaubt, kann ja mal auf dem OpenGL board (http://www.opengl.org/discussion_boards/cgi_directory/forumdisplay.cgi?action=topics&forum=OpenGL+coding:+advanced&number=3&DaysPrune=20&LastLogin=) nach mir Ausschau halten.

Hallali!

Xmas

2002-03-10, 23:13:13

zeckensack, alles schön und gut was du da schreibst, aber ich glaube nicht dass diese "Klarstellung" in dieser Form an diesem Punkt noch nötig war...

Thowe

2002-03-10, 23:15:32

Originally posted by Xmas
zeckensack, alles schön und gut was du da schreibst, aber ich glaube nicht dass diese "Klarstellung" in dieser Form an diesem Punkt noch nötig war...

... aber nichts desto trotz informativ.

Xmas

2002-03-10, 23:22:11

Stimmt auch wieder ;)

zeckensack

2002-03-11, 04:55:23

Ok, sorry für das ganze Gelaber, man muß doch als Newbie erstmal auf die Pauke haun, gell !? :D

Originally posted by Xmas
OpenGL mit DX9 zu vergleichen, ist aber auch nicht ganz fair. DX9-Hardware ist ja schon in weit fortgeschrittener Entwicklung, was sich von OGL 2.0 Hardware wohl kaum sagen lässt. Bis dahin könnte D3D schon einen Schritt weiter sein.

Halt ich eigentlich für ausgeschlossen. Wenn's tatsächlich ein Hardwarehersteller schafft, nen Chip und den passenden Treiber für GL2 zu basteln, dann ist eh alles aus. Dann ist in der Praxis pro Vertex und pro Pixel alles erlaubt, was sich ein Programmierer überhaupt ausdenken kann. Da kann MS noch so viele Spezialfeatures einbauen, solange man die Operation in C - so sieht die Sprache für Vertex/Pixel shader in GL2 nämlich aus - erfassen kann, spielt GL2 denn Igel und sagt 'bin schon da!'. DX muss dann früher oder später nachziehen und das gleiche anbieten.

Man bedenke an dieser Stelle, daß GL 1.0 aus anno dunnemals '91 schon Hardware T&L, trilinear gefilterte Texturen, Kanten-AA, blending, theoretisch unbegrenzte/beliebige Farbtiefen und wasweisichnichalles unterstützt hat. Die specs sind immer sehr sehr weit gefaßt sodaß Chiphersteller sich einfach nur aussuchen müssen, was davon sie denn jetzt in Hardware machen wollen.

Ich hab ehrlich gesagt nicht viel Übersicht, was in DX9 alles auftauchen soll aber DX8 wäre gegen GL2 der reinste Kinderkram - wenn die Hersteller das umsetzen können. Ich will nicht übermässig an DX rummäkeln, funktioniert ja eigentlich doch ganz gut, aber die Leute hinter den OpenGL specs arbeiten halt immer mit etwas mehr Weitsicht. Stichwort: passt auch in fünf Jahren noch.

Xmas

2002-03-11, 07:57:55

Jaja, die Tücke der Formulierung. Der "Schritt weiter" bezog sich auf DX9, nicht auf OpenGL. Man sollte also OpenGL 2.0 nicht mit DX9, sondern dem Nachfolger, sei es nun DX9.1 oder 10, vergleichen.

Frank

2002-03-11, 13:03:18

Originally posted by Andre
Ich sag auch niemanden, der behauptet, dass 1+1 = 4 ist, dass das "ungenau formuliert" sei.

:|
wobei das wirklich ungenau formuliert wäre... :eyes:

Wuzel

2002-03-25, 19:00:30

Sun Gl, Sun GL , Sun GL -> vergesst alles andere ;)

zeckensack

2002-03-29, 14:56:43

Originally posted by Wuzel
Sun Gl, Sun GL , Sun GL -> vergesst alles andere ;)

Höä? Meinste das hier (http://www.fortunecity.com/greenfield/bypass/394/sungl.htm)? Sieht lecker aus, aber was hat das mit Grafik zu tun? ???

Oder meinste IrisGL? Das ist OpenGL. Oder was?

Erleuchte uns, Meister! :karate:

Wuzel

2002-03-29, 15:54:55

Naja, die 'günstigste' Art in den Genuss von Sun Gl zu kommen bietet das hier : http://www.sun.de/Homepage/aktuell/2002/Blade2000/index.html

Aber generell muss man in der Preisklasse die einen guten Golf entspricht rechnen ;)

Daher auch der Smilie :)

nggalai

2002-03-29, 16:12:09

Danke für den Link, Wuzel. Allerdings konnte ich da unter der Blade 2000 und allen unterstützten Grafikkarten nur das hier finden:

"Operating System and API Requirements Solaris[tm] 8 Operating Environment (10/01) or later
Sun OpenGL® for Solaris version 1.2.3 API or later"

Von SunGL konnte ich gar nichts finden. Meinst Du OpenGL kompiliert für Solaris, i.e. "Sun OpenGL®"?

Hast Du vielleicht einen genaueren Link?

Dank dir,
-Sascha.rb

Edit: Typos.rb

zeckensack

2002-03-29, 16:42:35

Originally posted by Wuzel
Naja, die 'günstigste' Art in den Genuss von Sun Gl zu kommen bietet das hier : http://www.sun.de/Homepage/aktuell/2002/Blade2000/index.html

Aber generell muss man in der Preisklasse die einen guten Golf entspricht rechnen ;)

Daher auch der Smilie :)

Da ist die hier (http://www.sun.de/Produkte/Hardware/Workstations/Grafikkarten/XVR1000/index.html) drin. OpenGL, sonst nix, halt nur ne fette Hardware dazu =)

/edit
1.375 Pfund, 70Watt :o

Wuzel

2002-03-31, 04:39:38

Originally posted by nggalai
Danke für den Link, Wuzel. Allerdings konnte ich da unter der Blade 2000 und allen unterstützten Grafikkarten nur das hier finden:

"Operating System and API Requirements Solaris[tm] 8 Operating Environment (10/01) or later
Sun OpenGL® for Solaris version 1.2.3 API or later"

Von SunGL konnte ich gar nichts finden. Meinst Du OpenGL kompiliert für Solaris, i.e. "Sun OpenGL®"?

Hast Du vielleicht einen genaueren Link?

Dank dir,
-Sascha.rb

Edit: Typos.rb

Job, ist eine Art speziel angepasstes, modifiziertes Open GL, die Leistung ist möderisch.
Generell ist bei Sun nicht viel über technologien zu erfahren, entweder Buch oder Konferenz, ist schon nen geschlossener Haufen irgendwo.

zeckensack

2002-04-22, 14:53:53

edit: Das kommt aus dem 3DLabs-Thread im Speku-Forum. Ich wollte das da nicht Offtopic weiterführen.
/edit
Originally posted by grakaman
[Dadurch bietet es auch den Chipherstellern die grösseren Chancen, mal ordentlich auf den Putz zu hauen und richtig große Entwicklungssprünge zu machen.]

---------> muahahahahhahahahahahahahah

klar, deswegen hat intel auch schon n 256bit cpu draussen und windows kann diese ausnutzen...

Aha. Was hat das mit Grafikchips zu tun? Was hat das mit Windows zu tun?
Darf ich dich mal erinnern, daß wir innerhalb der 32bit CPU-Generation und 32bit Windosen von grottenlahmen reinen 2D-ISA-Grakas über Voodoos und Savage4s mittlerweile bei NV25 und R200 angekommen sind!? Dito unter Linux, MacOS und was auch immer!?
// die dx zyklen kommen den chipentwicklern viel mehr entgegen. wenn ich ogl2 unterstützen würde, was vielleicht mehr features etc. erlaubt, müsste meine hardware das auch unterstützen, und so das man sie auch nutzen kann.wenn ich dx8 unterstützen würde, was vielleicht mehr features etc. erlaubt, müsste meine hardware das auch unterstützen, und so das man sie auch nutzen kann. :P
[/B]damit würde man wohl dann auch eine ewigkeit erst mal hinkommen und neuentwicklungen wären sinnlos -------> demzufolge wird das auch nie geschehen. [/B]
Wie wärs denn mit Geschwindigkeitsverbesserungen?
Thema Shader: DX8 setzt eine Maximallänge für einen Shader voraus, GL2 nicht. Das ist dann Aufgabe der Treiber, einen zu komplexen Pixel-Shader mit Multipass auszuführen. Es ist auch Aufgabe der Treiber, einen zu komplexen Vertex-Shader in Software auszuführen. GL2 ist hier für die Applikation transparent, den Programmierer interessiert es einen Scheiß, wie viele Instruktionen der Chip auf einen Rutsch ausführen kann. Trotzdem kann ein höher entwickelter Chip komplexere Dinge besser und schneller machen. Und die Programmierer werden sich hüten, Monster-Shader auf zu kleiner Hardware laufen zu lassen, genauso wie man eben keine 1.4er Pixel Shader auf einer Geforce laufen lässt.
GL2 erlaubt übrigens auch Abfragen darüber, ob der gerade geladene Shader per Emulation oder Multipass läuft, das Programm kann in solchen Fällen dann auch wieder ein Stück zurückschalten. Das einzige, was hier entfällt, ist die blöde künstliche Beschränkung von DX8/DX8.1, die darauf zurückzuführen ist, daß Direct3D eben keine hardwareunabhängige, zukunftssichere API ist.

Direct3D 7.0 ist eine NV-Schnittstelle.
Direct3D 8.0 ist eine NV-Schnittstelle.
Direct3D 8.1 ist eine NV-Schnittstelle mit ATI-Erweiterungen.
Sowas wird untergehen, genauso wie Glide untergegangen ist.

StefanV

2002-04-22, 16:24:32

War es nicht so, daß OGL die Funktionen, die die GraKa nicht kann emuliert hat??

2002-04-22, 16:31:57

Originally posted by Stefan Payne
War es nicht so, daß OGL die Funktionen, die die GraKa nicht kann emuliert hat??

AFAIK nein, emuliert wird da nichts, aber fuer jede der recht zahlreichen OGL Funktionen muss ein Fallback zur Verfuegung stehen.
Denn ein OGL ICD muss mit allen Funktionsaufrufen des API umgehen koennen.

Falls ich da Mist rede, bitte verbessern;)

Exxtreme

2002-04-22, 16:39:37

Originally posted by ow

AFAIK nein, emuliert wird da nichts, aber fuer jede der recht zahlreichen OGL Funktionen muss ein Fallback zur Verfuegung stehen.
Denn ein OGL ICD muss mit allen Funktionsaufrufen des API umgehen koennen.

Falls ich da Mist rede, bitte verbessern;)
Also so wie ich es mitgekriegt habe wird in OGL jede Funktion, die der GraKa-Chip nicht kann, in Software gemacht um immer die vorgesehenen Resultate zu erhalten. Sollte also die GraKa kein PixelShader können, dann muss der Prozzi ran.

Gruß
Alex

zeckensack

2002-04-22, 16:53:05

Der Treiber muß die in der jeweiligen OpenGL-Version enthaltenen Features alle unterstützen. Wie sie unterstützt werden, ist dabei egal.

zB kann man auf einer Geforce2MX unter OpenGL 3D-Texturen benutzen, dann geht's aber ab ins Software-Rendering und wird grottenlahm. Die MX kann das nicht in Hardware, der Treiber muß das aber anbieten, weil er sich als Version 1.3 ausgibt. Die 1.3er-Spec fordert nunmal Unterstützung von 3D-Texturen.

Bei Extensions kann man davon ausgehen, daß alles angebotene HW-beschleunigt ist, oder zumindest ausreichend schnell, weil noch einigermaßen in Software zu lösen.
Wieder das MX-Beispiel: Es ist wg Abwärtskompatibilität gefordert, daß alle neuen Features seit OpenGL 1.0 als Extensions angeboten werden. Der MX-Treiber verschweigt aber seine Unterstützung für EXT_texture_3d, weil's eben von der Performance nicht vernünftig nutzbar ist.
ATI's OpenGL-Treiber für die Radeon in der Version 1.3.xxxx exportiert dagegen ordnungsgemäß EXT_texture_3d, weil die Chips es in HW können, obwohl durch die Versionsnummer schon klar ist, daß man es benutzen kann.
btw: NV's Verhalten in diesem Punkt ist IMO völlig richtig.

Was vom Treiber nicht als Extension angeboten wird, geht dagegen überhaupt nicht.
Bsp: Der Radeon 1-Treiber bietet mir weder ATI_fragment_shader (überhaupt nicht emulierbar), noch EXT_vertex_shader (durchaus emulierbar) an. Das muß der Programmierer dann zu Fuß lösen.

NV's neuere Treiber dagegen bieten auch auf MXen NV_vertex_program1_1 als Extension an. Das läuft dann in Software.

Wie man sieht, beides wird gemacht und ein Regelverstoß ist es auch nicht.

zeckensack

2002-04-22, 17:02:06

Originally posted by Exxtreme
Also so wie ich es mitgekriegt habe wird in OGL jede Funktion, die der GraKa-Chip nicht kann, in Software gemacht um immer die vorgesehenen Resultate zu erhalten. Sollte also die GraKa kein PixelShader können, dann muss der Prozzi ran.

Gruß
Alex Nicht ganz (siehe letztes Posting). Die 'aktuelle' Version 1.3 kennt keine VS/PS. Die kommen erst durch Extensions ins Spiel. Wenn keine PS-Extension vorhanden ist, dann geht es mit OpenGL-Bordmitteln überhaupt nicht. Also vergleichbar mit den PS-Tests im 3DMurks, entweder sie laufen, oder sie laufen nicht. Emuliation ist - im Gegensatz zu VS - auch nicht sinnvoll zu machen.

grakaman

2002-04-22, 17:30:08

TROTZDEM, DIRECT3D KOMMT DEN CHIPHERSTELLERN VIEL BESSER......
es kann ja sein, dass ogl2 besser ist, mehr features bietet etc.
nur, wenn ich das als chiphersteller integrieren würde, dann müsste ich entweder alle features in hw integrieren oder aber nicht. wenn nicht, ist es keine richtige konkurrenz zu d3d, da mir softemulationen herzlich wenig nützen. wenn ja würde es heissen, dass es der absolute superchip wäre und man in den nächsten jahren keine neue hw brauchen würde --------> DAS IST UNREALISTISCH
deswegen führte ich auch das bsp. mit intel an. man hätte schon längst einen viel leistungsfähigeren, neu designten chip rausbringen können (zb. 256bit), aber macht man ja logischerweise noch nicht. lieber immer neuere refreshes von bestehendem, das sichert den umsatz auf lange sicht. und genau das garantiert d3d. da es eh absolut unwahrscheinlich ist, dass irgend ein hersteller mit ner graka rauskommt, die alles kann, gibt man mit d3d immer gewisse richtlinien fest.

mfg grakaman

Meta

2002-04-22, 20:19:49

@Zeckensack

du hast recht ich meinte tatsächlich nicht die Leistung von DX (ich Vollkoffer) sondern die Features.

Is schon wahr, würden wirklich viele auf OpenGL umspringen wär das ein größerer Entwicklungssprung als von DX 8 auf 9. Das hast du ganz recht. *vollzustimm*
Nur, zwei Sachen musst du unbedingt mit einbeziehen.

1. Microsoft ist ein großer Spielehersteller und wird wohl immer DX nutzen ergo viele viele Spiele, also wird es nie ganz verschwinden.
2. Viele Spielehersteller entwickeln zur Zeit für die Xbox bzw. paralell auch zur XBox und die benutzt halt DX und aus dem Grund werden sie dann im PC-Spiel sich nicht die große Arbeit antun auf OpenGL umzuschwenken, da is es einfacher DX zu nehmen.

Für alle anderen die das nicht Zutrifft hoff ich, dass sie OpenGL sehr bald voll oder viel ausnützen, wär mir nur recht, ist nämlich klar die bessere Schnittstelle, über das brauchen wir eigentlich gar nicht reden...

So, nichts für ungut Zeckensack, alles verziehen *bisteinguterJunge* :))

Euer Meta

zeckensack

2002-04-22, 21:27:19

Originally posted by Meta
So, nichts für ungut Zeckensack, alles verziehen *bisteinguterJunge* :))

Euer Meta Dankechön =)

StefanV

2002-04-22, 21:57:49

Hm, soll die XBOX nicht auch OGL können??

Thowe

2002-04-22, 22:24:58

Warum sollte MS das wollen? Die Konsole soll ja gerade DX als Standard propagandieren.

Birdman

2002-04-22, 22:48:03

na ja, wenn MS Doom3 auf der Xbox will, muss es wohl in OGL gehen...glaube kaum dass jc noch nen DX output reinhaut.

zeckensack

2002-04-22, 23:04:18

Originally posted by Thowe
Warum sollte MS das wollen? Die Konsole soll ja gerade DX als Standard propagandieren.
*zustimm*
Siehe auch diese lustige Diskussion (http://www.opengl.org/discussion_boards/ubb/Forum3/HTML/005849.html)

StefanV

2002-04-22, 23:26:37

Originally posted by Thowe
Warum sollte MS das wollen? Die Konsole soll ja gerade DX als Standard propagandieren.

Die Konsole ist ein PC.
Sie hat eine Festplatte.
Das OS ist ein abgespecktes W2k.

WARUM sollte nicht ein Hersteller OGL auf CD packen??

Quasar

2002-04-22, 23:38:28

Weil sie sonst vielleicht eine groooooße Menge Kohle an MS zahlen müssten, weil sie gegen Lizenzbestimmungen verstossen haben?

Ganon

2002-04-23, 14:17:55

Die XBOX ist eh ein vollflopp! Einige Entwickler springen eh schon ab! Also was soll die Disskusion ob sie OpenGL kann?:D;)

grakaman

2002-04-23, 14:20:54

[Warum sollte MS das wollen? Die Konsole soll ja gerade DX als Standard propagandieren.]

egal wäre es trotzdem, weil man nur eine hw hat. und genau deswegen machts eigentlich keinen sinn, ob ich nun ogl,dx oder direkt auf hw programmiere (ausser, dass letzteres vielleicht estwas schneller ist).
und sinnvoll benutzen kann ich eh nur die effekte, die es in hw gibt.

Unregistered

2002-04-23, 16:46:54

zeckensack du hast da im 3dlabs chip thread sowas schöne geschrieben dass opengl 2.0 ein befreiungsschlag wird. ABer da sag ich dir eines, bis ein Spiel wirklcih alle features unterstützt ist direct x 12 draussen und kann genau das gleiche.

Eine spielfirma kann es sich doch nicht leisten ein spiel ausschlieslich auf opengl2.0 zu entwicklen. wer soll denn das spiel dann spielen???? Opengl2.0 wird mit der ausnützung der technik/möglichkeiten genau das gleich prob haben wie direct x

und wenn du das ganze jetz tnoch hochrechnest. sagen wir opengl2.0 kommt end 2002 raus dann kann ich mit spielen frühestens 2004 rechnen. Das Problem ist und bleibt die Entwickler kommen nicht mit der Entwickliung der Grakas nach das ändert sich doch mit ogl 2.0 nicht. Udn die spiele müssen ja auch imemr auf 80% der hardware laufen das ist doch das grösste Prob an der Sache...

zeckensack

2002-04-23, 17:47:11

Originally posted by Unregistered
zeckensack du hast da im 3dlabs chip thread sowas schöne geschrieben dass opengl 2.0 ein befreiungsschlag wird. ABer da sag ich dir eines, bis ein Spiel wirklcih alle features unterstützt ist direct x 12 draussen und kann genau das gleiche.

Eine spielfirma kann es sich doch nicht leisten ein spiel ausschlieslich auf opengl2.0 zu entwicklen. wer soll denn das spiel dann spielen???? Opengl2.0 wird mit der ausnützung der technik/möglichkeiten genau das gleich prob haben wie direct x

und wenn du das ganze jetz tnoch hochrechnest. sagen wir opengl2.0 kommt end 2002 raus dann kann ich mit spielen frühestens 2004 rechnen. Das Problem ist und bleibt die Entwickler kommen nicht mit der Entwickliung der Grakas nach das ändert sich doch mit ogl 2.0 nicht. Udn die spiele müssen ja auch imemr auf 80% der hardware laufen das ist doch das grösste Prob an der Sache...

Das schöne an den OpenGL-Vorschlägen zu Shadern ist ja gerade, daß die Sprache viel zu mächtig und überdimensioniert für heutige HW ist.
Die Sprache ist schlicht und ergreifend C mit kleineren Einschränkungen, man kann theoretisch 'ne ganze Textverarbeitung inklusive Rechtschreibprüfung auf einem Pixel-Shader laufen lassen (Hinweis: minimal übertrieben).

Das mag sich wahnsinnig anhören. Und unmöglich in einen Chip zu packen. Man kann aber sehr wohl in dieser Shader-Sprache auch ganz klitzekleine Programme schreiben, die dann auch auf 'ner Geforce3 laufen. Oder, wenn NVidia etwas daran arbeitet, auch etwas grössere, es ist dann Aufgabe des Treibers, das 'zu große' Programm in verdauliche Häppchen aufzuteilen. Und so ist aus richtig. Was interessiert's den Programmierer, wie genau die Hardware zu programmieren ist? Er will doch nur wissen, ob sein Programm ausreichend schnell läuft.
BTW, auch banale Multitexturing-Sachen lassen sich in dieser Sprache programmieren und sollten - cleveren Treiber vorausgesetzt - völlig unverändert auch auf 'ner TNT2 laufen. Die Eleganz liegt hier in der Vereinheitlichung der Programmierschnittstelle.

Wenn wir mal in die Zukunft schauen, sagen wir mal der NV30 kann mit seinem Pixel Shader 5x tollere Sachen, als die Geforce 3. ATI's R300 kann wieder ganz andere Sachen. SiS schmeißt dieses Jahr einen PS-fähigen Chip in's Rennen, genau wie Trident. Was der Matrox-Chip können soll, weiß auch noch keine Sau. Dann evtl noch Kyro 3 und Bitboyz. Unter Direct3D regnet's dann PS1.5, PS1.6, PS2.0, PS2.1,PS2.2 usw. Die GL2-Shader-Sprache ist von vornherein so weit gefaßt, daß sie nicht mehr erweitert werden muß.

Für die Devs ist es glaube ich wesentlich bequemer, eine einzige Sprache zu benutzen (die sie eh' schon kennen, weil extrem ähnlich zu C) und einfach die Programmlänge je nach Fähigkeiten des Chips zu variieren, als wie bei D3D jedes mal von vorn anzufangen. Die DX8-Shader sind quasi Assembler, fürderdings unterscheiden sich PS1.1-1.3 und PS1.4 grundlegend. Hier muß man sich tatsächlich auf jeden neuen Chip einarbeiten. GL2.0 verspricht hier, die Verantwortung für die Anpassung auf den speziellen Chip den Treiberentwicklern zu überlassen. Die kennen ihre Hardware ja auch am besten.

DirectX rennt der Hardware immer nur hinterher, OpenGL ist da eben flexibler. Man sollte nicht davon ausgehen, daß Hardware von OpenGL2.0 irgendwie 'überfordert' wäre.

Beispiel: NVidia's erste Geforce-Demos (zB Grove) waren für OpenGL. Man wollte hier die T&L-Einheit demonstrieren. DirectX7 war noch nicht fertig. Zum Glück sah schon OpenGL1.0 aus anno dunnemals '91 Unterstützung für HW-T&L vor. Diese Fähigkeit lag bis ca '95 vollständig brach, dann kamen die ersten Profikarten mit T&L-Coprozzi.

Es hat sich hier also wirklich als günstig erwiesen, die Spec 'zu weit' zu fassen. Dadurch musste man mit dem Aufkommen eines neuen wichtigen Features (HW-T&L) nicht wieder alles umschmeissen und von vorn anfangen. Genauso wird's auch aussehen, wenn die Chips immer komplexer werden. Der 'Feature-Overkill' der vorgeschlagenen Shading Language wird sich sofort auszahlen, da man alles neue durch simple Erweiterung des Programms - im Gegensatz zum Wechsel auf eine neue API - sofort nutzen kann.

Puuh, ich glaube, ich sollte mal ein Buch schreiben :biggrin:

Unregistered

2002-04-23, 23:50:42

jo das hört sich alles sehr schlüssig an, vor allem in der Theorie. In der Praxis ist dies sicher schwieriger umzusetzen, denn ich denke so einfach ist das mit dem anpassen der Effekte nicht.

Gehen wir mal noch einen Schritt weiter. Zur Zeit gibt es wohl 2-3 beherrschende Graka engines. Unreal, Quake 3 und die Lithtech engine.
Zwei von denen basieren auf direct x und eine auf opengl(worauf die nächste engine von john carmack doom3 , auch drauf laufen wird)

So das heisst es werden mindestens noch 3-4 Jahre lang Spiele auf Direct X entwickelt werden und solange wird es immer weiterentwickelt werden und wo die Entwicklung dann hingeht können wir nicht voraussagen. Desweitern hat Microsoft noch ne Konsole namens XBOX und die dürfen wir hier nicht vergessen. Hier wird soweit ich weis ausschliesslich auf Direct X produziert und smit dürfte die umsetzung prinzipiell einen geringen Aufwand betragen.

Zu den anderen Konsolen: soweit ich weis benutzt doch keiner der jetzigen Konsolen OpenGl oder bin ich da falsch informiert?? Drum ist dies auch kein Standbein für openGl und wird in naher Zukunft auch sicher keines werden.

Grundsätlich bin ich der Meinung dass die beiden apis sich den Markt aufteilen werden und dass dabei direct x den grösseren Anteil haben wird.

Und dass Direct X der Hardware hinterrennt sehe ich auch nicht so. Sie kommen wohl eher zeitgleich raus, Ok atm mit dx 9 hängt sie hinterher was aber sicher eher am unwillen von MS liegt und an sonst nichts.

Unregistered

2002-04-24, 15:06:17

Originally posted by zeckensack
[B]

Für die Devs ist es glaube ich wesentlich bequemer, eine einzige Sprache zu benutzen (die sie eh' schon kennen, weil extrem ähnlich zu C) und einfach die Programmlänge je nach Fähigkeiten des Chips zu variieren, als wie bei D3D jedes mal von vorn anzufangen. Die DX8-Shader sind quasi Assembler, fürderdings unterscheiden sich PS1.1-1.3 und PS1.4 grundlegend. Hier muß man sich tatsächlich auf jeden neuen Chip einarbeiten. GL2.0 verspricht hier, die Verantwortung für die Anpassung auf den speziellen Chip den Treiberentwicklern zu überlassen. Die kennen ihre Hardware ja auch am besten.

Prinzipiell hast du recht, eine High Level Shader Sprache zu haben, ist eine schöne Sache. ABER:

1. Muß auch innerhalb dieser High Level Sprache Optimierungen und Spezialversionen für jeden Chip gemacht werden, weil ich nun wirklich nicht Pixel Ligthing mit 8 Lichtquellen auf ner GF3 laufen lassen will. Diese Problematik spricht ja schon eher für den DX Ansatz, der einem mehr Kontrolle und wesentlich mehr Performancegarantien gibt. Bei OpenGL weiß ich, das jeder Shader laufen würde auf jeder Karte mit OpenGL 2 Treiber. Schön, und Max und Maya und was weiß ich werden sich bestimmt drüber freuen. Als Spieleentwickler muß man trotzdem bei jedem Hersteller in die Docs gucken und Informationen sammeln, wie jeder einzelne Shader auf welcher Karte denn nun wirklich umgesetzt wird. Da sind doch die DX Garantien irgendwie einfacher, oder? Man schaut nach, welchen Pixel Shader Level ne Karte unterstützt und kann loslegen.

2. Moderne Engines sind eh darauf ausgelegt, viele verschiedene Shaderfallbacks zu unterstützen, halt je nach Grafikkarte. Solange sich die Einbindung des Shaders ins Gesamtsystem nicht ändert, stören die verschiedenen PS Versionen nicht wirklich. Der Lernaufwand von PS1.1 auf PS1.4 dürfte für nen guten Gfxcoder bei wenigen Tagen liegen.

Die Gründe, warum die ganzen DX8 Features sich nicht so schnell in Spielen durchsetzen, liegen eher woanders und zwar im Contentbereich. Die Fähigkeiten einer aktuellen Unrealengine auszunutzen kostet im Grafikbereich so viel, daß sich gerade mittlere Publisher sehr wohl überlegen müssen, bei diesem Grafikniveau mitzuziehen.

Pitchfork

HOT

2002-04-24, 15:40:19

DX8 hat mehrere Probleme, die durch die Shader verursacht werden. Es ist einfach für die meisten Firmen zu Zeitaufwändig auf Assembler zu proggen. Da kannst du noch so gute Coder ransetzen, es dauert schlicht und ergreifend länger, als wenn du klassiche C Implementation auf DX7 Basis benutzt. Und in dem Umfang, den unsere bisherige Hardware Pixel- und vor allem Vertexshaderunterstützung beherrscht, lohnt es sich schlichtweg nicht die Mühe zu investieren. Du hast sicherlich auch gelesen, dass sich viele Entwickler darüber beschwert haben, dass Shader schlichtweg nicht weit genug gehen, vor allem von den Entwicklern, die damit gearbeitet haben.
JC sieht die Sache ganz anders, der sagt sich nämlich einfach: wenn ich in DX8 schon den Assembler auspacken muss, dann kann ich auch gleich OpenGL mit den Extensions der einzelnen relevanten Hersteller nutzen, um bestmögliche Resultate zu erzielen, das ging aus meherern Forumposts von ihm hervor.
Es ist einfach absolut überfällig, dass eine einheitliche Shadersprache kommt, um Shader überhaupt auf breiter Basis nutzbar zu machen. OpenGL 2.0 bringt hier deshalb unglaubliche Erleichterungen, da sich der Spieleentwickler sich nicht mehr wirklich die Gedanken über spezifische Hardware machen muss und darum geht es im Endeffekt doch.
Spieleschmieden müssen sich zig Jahre vorher Gedanken machen, wie die Hardware später mal aussehen wird und welche Schnittstellen hier relevant sind. OpenGL 2.0 kommt hier grade recht, da die Branche kurzzeitig an Perspektivenlosigkeit krankte und immer mehr über Konsolen - only Title nachgedacht wird. OpenGL 2.0 gibt dem PC als Spieleplattform seine grösste Berechtigung zurück die M$ zugunsten der XBox immer mehr zurückdrängt: Flexibilität!!! OpenGL 2.0 gibt dem PC eine Grössere Flexibilität denn je, da sich das Ganze auchnoch Plattformübergreifend einsetzen lässt!

zeckensack

2002-04-24, 16:03:10

Originally posted by Unregistered
Gehen wir mal noch einen Schritt weiter. Zur Zeit gibt es wohl 2-3 beherrschende Graka engines. Unreal, Quake 3 und die Lithtech engine.
Zwei von denen basieren auf direct x und eine auf opengl(worauf die nächste engine von john carmack doom3 , auch drauf laufen wird)
Dazu kann ich noch anmerken, daß Tim Sweeney (Chefprogrammierer der Unreal-Technologie) sehr wohl an OpenGL interessiert zu sein scheint und mit dem ARB im Diskurs steht.
Auf Seite 22 dieser GDC-Präsentation (http://www.3dlabs.com/support/developer/ogl2/presentations/OGL2_GDC2002.pdf) wird ausdrücklich sein Name genannt. Er hatte einen Vorschlag für weitere Flexibilisierung von Offscreen-Puffern gemacht, und offensichtlich spielt das ARB da mit.
In diesem etwas älteren Progress Update (http://www.opengl.org/developers/about/arb/notes/3Dlabs_OGL2_Status_Dec11.pdf) taucht Epic Games (wieder Unreal) auf Seite 3 als 'Contributor' auf.

@all:
Zum Thema Konsolen:
Konsolen profitieren nicht von flexiblen APIs. Die Hardware ist konstant und muß mit möglichst wenig Abstraktion angesprochen werden. Wenn ich auf konstanter Hardware eine Hochsprache kompiliere, dann weiß ich doch vorher schon, was dabei herauskommt, bzw es kommt immer das gleiche dabei heraus. Die shading language aus GL2 ist hier überhaupt nicht nötig. DX8 macht auf der XBox durchaus Sinn, wobei ich mir nichtmal sicher bin, wie weit die Ähnlichkeiten zum DX8 auf PCs überhaupt reichen.

Wie der Cube programmiert wird, das weiß ich nicht.
Und die PS2 ist wahrscheinlich für jegliche Art von abstrahierender Programmierschnittstelle zu 'komisch' aufgebaut.

Ganon

2002-04-24, 16:57:43

Nochmal zu den Konsolen!

GameCube:

Man kann auf dem GC in OpenGL Proggen! Unterstützt wird es! Nur halt kommt man damit nicht sehr weit da der GC nicht viel mit nem PC zu tun hat!

C++ liegt dem GC am besten!

PS2:

Soweit ich weiß geht hier auch OpenGL! Nur gilt hier das selbe wei beim GC! Hardware ist einfach zu weit vom PC entfernt! Die Idealssprache kenn ich hier nicht!

XBOX:

Dem Floppprodukt (In Japan verkauft sich momentan die PSX besser als die XBOX) müsste eigendlich alles passen!

Unregistered

2002-04-24, 19:37:31

Ich denke wir lassen uns überraschen wo uns das ganze hinführt.

Wir spielen wollen eh nur die besten Ergebnisse.
allerdings denke ich dass sich MS die Kritik sicher zu herzen nimmt, auch mit der kommenden "Bedrohung" OGL 2.0.

PS: ich hab es mit Absicht bedrohung genannt, allerdings aus sich von MS

Karümel

2002-05-28, 16:47:34

Ich habe mal eben ne Frage zu OpenGL.
Bei Direct X heißt ja immer: Bald kommen die ersten DX 7, DX 8, DX 9 Grafikkarten auf den Markt. Bei OpenGL sind die jetzt bei Version 1.2 oder 1.3 (nicht hauen ich weiß es nicht genau), aber ich habe noch nie gelesen das irgendwo stand das z.B. "Bald kommen die ersten OpenGL 1.3 Grafikkarten raus" Das einzige was ich gelesen habe war das der P10 der erste Chip ist der OpenGL 2.0 unterstützt (damit ist doch das abwärtskompatibele 2.0 gemeint?). Habe ich das immer nur "überlesen" oder wurde das nie groß bei den Einser Versionen "gehypt" Oder ist die aktuelle OpenGL Vesrion schon recht lange auf dem Markt.

Da fällt mir noch was ein Hardware TL, ist ja DX erst bei Version 7 vorhanden, aber wie sit das bei OpenGl? Ich habe mal gelsen das es schon Befehle für HwTL in der Quake 1 Engine gibt, sprich schon lange bevor es überhaupt die passenden Karten gab. Wurde das durch OpenGl schon unterstützt oder ist der HwTL Support der Engine zuzuschreiben?

Und noch ne Frage: Auf welcher OpenGL Version läuft eigentlich Q3A bzw. DOOM III?

2002-05-28, 16:57:32

Karuemel:

OGL wird IMO deshalb weniger gehypt als DX, weil's nicht von MS ist. Wirklich gute Produkte muss man nicht 'gut'hypen.

OGL unterstuetzt seit der allerersten Version (1.0, 1992) HW T&L, Version 1.1 ist von 1995, der 1.2 Standard wurde 1998 verabschiedet, derzeit sind wir bei OGL1.3 (ich weiss leider nicht seit wann).

OGL ist anders als DX aufgebaut, so dass man auch nicht von OGL-Version-Spielen spricht.

Alles was derzeitige OGL Spiele (Q3 u.a.) brauchen ist OGL1.1.

Demirug

2002-05-28, 17:00:46

Bin zwar nicht der absolute OpenGL Experte aber da es nicht um API-Details geht kann ich dir hier wohl weiterhelfen.

Der Primäre Unterschied zwichen OpenGL und DirectX liegt darin das wenn eine Karte OpenGL 1.x unterstützt muss sie es komplet unterstützen. Bei DirectX dagegen gibt es für fast alle Features eine Capsflag welches aussaget ob die Karte das Feature unterstützt oder nicht.

Die OpenGl API ist dagegen nicht so Hardwarenah und kann viele Features einer Karte nicht direkt abbilden. Deshalb haben die einzelen Chiphersteller unabhängig eigene Extensions zur Basis-API hinzugefügt. Diese sind leider meistens nicht kompatibel. Aufgrund dieser grundsätzlich anderen Strucktur gibt es auch viel seltener eine neue OpenGL API Version als eine DirectX Version.

Was nun das Hardware T&L angeht so wird das aufgrund der OpenGL Struktur automatisch genutzt wenn der Chip dazu fähig ist (läst sich in den OpenGL Treiber aber meistens auch abschalten).

Welche OpenGL Version DOOM III genau nutzt weis ich jetzt auch nicht. Ist aber im Prinzip fast egal da dort aus Performancen gründen fast ausschliesslich die herstellerspezifischen Extensions benutzt werden.

Karümel

2002-05-28, 18:47:13

Originally posted by Demirug

Der Primäre Unterschied zwichen OpenGL und DirectX liegt darin das wenn eine Karte OpenGL 1.x unterstützt muss sie es komplet unterstützen. Bei DirectX dagegen gibt es für fast alle Features eine Capsflag welches aussaget ob die Karte das Feature unterstützt oder nicht.

Ist das ader Grund dafür das es erst ein OpenGl 2.0 abwärtskompatiebel und dann ein nichtabärtskompatiebeles OpenGl 2.0 gibt. Oder wird das noch andere Gründe haben

Xmas

2002-05-28, 21:04:51

Die Änderungen zwischen den einzelnen OGL-Versionen bestehen eigentlich fast nur darin, dass jeweils einige häufig genutzte Extensions (mit kleineren Änderungen) zum Standard-Funktionsumfang hinzugenommen wurden. Insofern bot eine neue OGL-Version im Gegensatz zu einer neuen DX-Version nie etwas wirklich neues, denn die Extensions existierten ja alle schon vorher.

Originally posted by Karümel
Ist das ader Grund dafür das es erst ein OpenGl 2.0 abwärtskompatiebel und dann ein nichtabärtskompatiebeles OpenGl 2.0 gibt.
Davon wüsste ich nichts. Es gibt lediglich zwei Herangehensweisen an OpenGL 2.0: Einmal im Kern OGL1.3-Funktionen zu nutzen und OGL2.0-Funktionen als Erweiterung anzusehen. Und einmal die OGL1.3-Funktionen links liegen zu lassen und nur noch OGL2.0-Funktionen zu verwenden ("Pure OpenGL 2.0"). Lezteres macht in naher Zukunft noch kaum Sinn, weil die Hardware dazu kaum verbreitet sein wird.

Demirug

2002-05-28, 21:16:56

Und bis dann OpenGL 2.0 endlich zum standard erhoben wird ist es schon wieder überholt (aufgrund der aktuellen Forschungen ist es ja jetzt schon wieder überholt). Dann fängt wieder jeder Hersteller an seine eigenen Extensions einzubauen und wir haben die gleiche blöde Situation wie jetzt auch.

zeckensack

2002-05-28, 21:26:52

Originally posted by Xmas
Davon wüsste ich nichts. Es gibt lediglich zwei Herangehensweisen an OpenGL 2.0: Einmal im Kern OGL1.3-Funktionen zu nutzen und OGL2.0-Funktionen als Erweiterung anzusehen. Und einmal die OGL1.3-Funktionen links liegen zu lassen und nur noch OGL2.0-Funktionen zu verwenden ("Pure OpenGL 2.0"). Lezteres macht in naher Zukunft noch kaum Sinn, weil die Hardware dazu kaum verbreitet sein wird. GL2 verspricht doch zuallererst ein vereinheitlichtes Programmiermodell. Sofern ein brauchbarer Treiber vorliegt, kann man in den OpenGL2 Shader-Sprachen auch simples Multitexturingzeugs programmieren, was dann auch auf einer Savage 4 laufen würde. Und wenn's mal etwas flexibler sein darf, braucht man wenigstens keine Extensions mehr zu nehmen (NV_texture_env_combine4 vs ATIX_texture_env_combine3 :kotz: ).

Die Meßlatte für die Hardware, um OpenGL2 unterstützen zu 'dürfen' ist relativ gering angesetzt ;)

Xmas

2002-05-28, 21:33:27

Originally posted by zeckensack
Die Meßlatte für die Hardware, um OpenGL2 unterstützen zu 'dürfen' ist relativ gering angesetzt ;)
Schon klar, aber meinst du du bekommst für ne Savage4 noch OpenGL 2.0 Treiber? ;)

Demirug

2002-05-28, 21:36:35

Originally posted by Xmas

Schon klar, aber meinst du du bekommst für ne Savage4 noch OpenGL 2.0 Treiber? ;)

Ich denke mal eher nicht. 3dLabs gibt in irgendeinen der Spec Dokumente an das sich ein OpenGL 2.0 Treiber erst ab DX 9 GraKa lohnt.

zeckensack

2002-05-28, 21:39:42

Originally posted by Xmas

Schon klar, aber meinst du du bekommst für ne Savage4 noch OpenGL 2.0 Treiber? ;) Nein, das glaube ich natürlich nicht ;)

edit: Aber beim TNT2 und den ganzen Geforces könnte ich's mir durchaus vorstellen =)

Demirug

2002-05-28, 21:51:03

Originally posted by zeckensack
Nein, das glaube ich natürlich nicht ;)

edit: Aber beim TNT2 und den ganzen Geforces könnte ich's mir durchaus vorstellen =)

Geforce3/4 vielleicht aber bei einer TNT2 habe ich doch erhebliche zweifel. Da bekommst du ja nur die einfachsten Fragment shader zum laufen.

BTW. Ich sehe schon die ersten Extension für OpenGL 2.0 aufziehen. Es wird keine Tessllation und auch kein Displacement Mapping unterstützt.

zeckensack

2002-05-29, 06:46:16

Originally posted by Demirug

Geforce3/4 vielleicht aber bei einer TNT2 habe ich doch erhebliche zweifel. Da bekommst du ja nur die einfachsten Fragment shader zum laufen.

BTW. Ich sehe schon die ersten Extension für OpenGL 2.0 aufziehen. Es wird keine Tessllation und auch kein Displacement Mapping unterstützt. Was DM angeht, die Spec ist ja noch nicht final. Man müßte lediglich Texturzugriffe im Vertex Shader erlauben, schon hätte man DM.

Desweiteren gibt's in GL ja auch noch 'Surface Evaluators' für HOS ala NVIDIA, schwupps hätte man auch das Problem mit dem adaptiven LOD gelöst. Da müßte dann auch nicht viel geändert werden. Bin jetzt nicht mehr auf dem neuesten Stand, aber N-Patches sind möglicherweise auch schon vorgesehen ???

Demirug

2002-05-29, 09:08:08

Originally posted by zeckensack
Was DM angeht, die Spec ist ja noch nicht final. Man müßte lediglich Texturzugriffe im Vertex Shader erlauben, schon hätte man DM.

Desweiteren gibt's in GL ja auch noch 'Surface Evaluators' für HOS ala NVIDIA, schwupps hätte man auch das Problem mit dem adaptiven LOD gelöst. Da müßte dann auch nicht viel geändert werden. Bin jetzt nicht mehr auf dem neuesten Stand, aber N-Patches sind möglicherweise auch schon vorgesehen ???

Man schein aber nicht sehr gewillt zu sein das einzuplanen

9.2 Why no tessellation?
Tessellation is one area we would like to add to OpenGL and make programmable at the same
time. Unfortunately this is an area of active research by the graphics community and there is no
consensus as to what the tessellation primitives should be, or how to tessellate them. A
programmable tessellation architecture ought to make the 'what and how' less relevant, but we
would still need to define some canonical operations and features and at this point in time it is not
obvious (to us) what these are.
We are very conscious that OpenGL 2.0 needs to be delivered in a timely manner and do not want
to delay it, or add in poorly formulated ideas or API constructs.
9.3 Why no displacement mapping?
Displacement mapping is a technique we would like OpenGL 2.0 to support, but it is really a
tessellation technique and we have already outlined our position on that. Useful displacement
mapping can be done on triangle meshes whereby each triangle is subdivided 'in the plane' and
displaced, but even at this level there are issues of adaptive or fixed tessellation, controlling the
level of tessellation, ensuring no cracks appear between the edges of input triangles, etc.. We are
still looking for a suitable mechanism to allow the application to use a multi-pass technique
combining texture sampling and coarse geometry to generate the displaced surface, but it does not
look like we will have something in time.

Und was die N-Patches angeht so ist mir das ziemlich egal. Ich bin sowieso kein Freund davon da die praxsis Tauglichkeit gegen null läuft. Aber das hatten wir ja schon.

Alles in allem geht mir OpenGL 2.0 aber gerade im Bereich der Schader nicht weit genung. So wie das im Moment aussieht wird OpenGL 2.0 von DX 10 wohl technologisch wieder übertrumpft.

aths

2002-05-31, 00:14:35

Demirug,

von dir hört man gelegentlich diffuse Andeutungen was DX10 betrifft. Könntest du konkret werden oder Quellen nennen?

Demirug

2002-05-31, 10:53:39

Originally posted by aths
Demirug,

von dir hört man gelegentlich diffuse Andeutungen was DX10 betrifft. Könntest du konkret werden oder Quellen nennen?

Ich hab hier http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=20479&pagenumber=4 auf Wunsch von Xmas schon etwas dazu geschrieben.

Edit: War nicht der Wunsch von zeckensack. Mit ihm hatte ich dann noch eine diskussion darüber.

Fragman

2002-05-31, 12:14:46

bin sowieso mal gespannt, wie matrox die probs von dm, die hier aufgezaehlt wurden, loesen wird. viele stehen dm kritisch gegenueber, was die weite verbreitung erstmal hemmen duerfte. wird der r300 dm bieten, was ist mit dem nv30?

Demirug

2002-05-31, 16:05:14

Originally posted by Fragman
bin sowieso mal gespannt, wie matrox die probs von dm, die hier aufgezaehlt wurden, loesen wird. viele stehen dm kritisch gegenueber, was die weite verbreitung erstmal hemmen duerfte. wird der r300 dm bieten, was ist mit dem nv30?

Wlche probs mit dm meinst du den genau?

was den r300 und nv30 angeht werden wir wohl bis zur chipvorstellung warten müssen.

zeckensack

2002-05-31, 16:15:43

Originally posted by Fragman
bin sowieso mal gespannt, wie matrox die probs von dm, die hier aufgezaehlt wurden, loesen wird. viele stehen dm kritisch gegenueber, was die weite verbreitung erstmal hemmen duerfte. wird der r300 dm bieten, was ist mit dem nv30? DM sollte eigentlich recht problemlos sein, zumal man direkt darauf hinarbeiten muß, um es überhaupt sinnvoll zu nutzen.

N-Patches (aka TruForm) sind da wesentlich problematischer, davon hat Demirug mich mittlerweile überzeugen können :)

Karümel

2002-07-06, 10:37:04

Mir sind wieder ein paar Fragen eingefallen.

Also die meißten Spiele/Engines laufen ja unter D3D, weitaus geringer ist der Anteil der OpenGl Spiele/Engines. Hat dieses einen besonderen Grund? Ist evtl. die Programierung für D3D einfacher oder was für Gründe könnte es sonst noch geben.
Die meißten Spiele sind ja nur für D3D oder OpenGl, es gibt aber auch Spiele die unter beiden „Schnittstellen“ laufen, wie z.B. UT oder NWN (habe ich jedenfalls gelesen), weswegen dieser Aufwand?
Ist das eigentlich viel „Arbeit“ das unter beiden Sache zum laufen zu bekommen? Und was für einen „Nutzen“ kann das sonst noch haben. Wenn das Game/Engine nicht nur unter Windows laufen soll sondern auch auf Mac oder Linux, reicht da nicht OpenGl alleine??

Falls die Fragen jetzt allzu blööd/hohl etc. sind bitte ich um Verzeihung. Denn ich kenn mich in diesen Sachen garnicht aus.

Exxtreme

2002-07-06, 10:47:56

Originally posted by Karümel
Mir sind wieder ein paar Fragen eingefallen.

Also die meißten Spiele/Engines laufen ja unter D3D, weitaus geringer ist der Anteil der OpenGl Spiele/Engines. Hat dieses einen besonderen Grund? Ist evtl. die Programierung für D3D einfacher oder was für Gründe könnte es sonst noch geben.

Also ich denke mal, daß D3D etwas leichter zu supporten ist da man keine zig Extensions usw. berücksichtigen muss. Ich finde trotzdem OpenGL besser da die Games IMHO viel runder laufen, kein Mouselag haben usw.

Gruß
Alex

Demirug

2002-07-06, 14:39:09

Originally posted by Karümel
Also die meißten Spiele/Engines laufen ja unter D3D, weitaus geringer ist der Anteil der OpenGl Spiele/Engines. Hat dieses einen besonderen Grund? Ist evtl. die Programierung für D3D einfacher oder was für Gründe könnte es sonst noch geben.

Das hat ja Exxtreme ja schon beantwortet. Wobei ich den Mouselag jetzt nicht auf DX aleine schieben würde.

Die meißten Spiele sind ja nur für D3D oder OpenGl, es gibt aber auch Spiele die unter beiden „Schnittstellen“ laufen, wie z.B. UT oder NWN (habe ich jedenfalls gelesen), weswegen dieser Aufwand?

Die meisten dieser Spiele bauen auf kommerzielen Lizenzengines auf. Diese sind von grund auf daraus ausgelegt mehr als eine Zielplatform (PC, MAC, Konsolen) zu unterstützen. Da man diese Enginen dann mehrfach lizenziert ist der Aufwand zu vertreten.

Ist das eigentlich viel „Arbeit“ das unter beiden Sache zum laufen zu bekommen? Und was für einen „Nutzen“ kann das sonst noch haben. Wenn das Game/Engine nicht nur unter Windows laufen soll sondern auch auf Mac oder Linux, reicht da nicht OpenGl alleine??

Der Arbeitsaufwand für einen Engine stuffe ich wie folgt ein:

DX only 0.6-0.7
OpenGL only 0.9-1.1
DX und OpenGL 1.4-1.6

Lizenziert man eine Engine ist die Wahl damit ja schon gefallen. Bei einer Selbstentwicklung stellt sich allerdings immer die Frage ob sich der mehraufwand für OpenGL lohnt. In der Regel nicht da die Umsätze die man mit Linux und Mac machen kann nicht wirklich gross sind. Sobald die Verfügbarkeit von OpenGL 2.0 sichergestellt ist muss man die Lage neu überdenken.

Falls die Fragen jetzt allzu blööd/hohl etc. sind bitte ich um Verzeihung. Denn ich kenn mich in diesen Sachen garnicht aus.

Es gib keine dumme oder blöde Frage.