Die Marktmacht von DirectX [Archiv]

Fruli-Tier

2006-08-07, 11:44:55

Nun, DirectX ist ja, bezogen auf die angesprochene MediaPlayer-freie Windows Version, kein "Produkt", mit dem der Kunde aktiv zu tun hat. Es ist eine Schnittstelle, wie die Windows API und mittlerweile .NET auch. Und ich bin mir ziemlich sicher, dass einige Microsoft Tools, die von Windows benötigt werden, auch schon auf DirectX aufsetzen und diese "Runtime" daher im Betriebssystem vorhanden sein muss.

Der Benutzer merkt davon ja nichts, und Entwicklern steht es doch frei, mit ihrer bevorzugten Grafik API zu arbeiten. Ich persönlich sehe daran nichts Verwerfliches, heiße es sogar gut, zumal die Pflege von DirectX zuverlässig von statten geht.

Dass Microsoft Version 10 für Vista reservieren möchte ist aus Marketingsicht verständlich, ob sie damit Erfolg haben, steht woanders. Dazu muss Vista, neben einer schicken, aber Leistungshungrigen Oberfläche, erst einmal beweisen, dass es ein gutes OS ist und einen Kauf verdient. Bevor sich da nichts tut, denke ich, werden alle cleveren Entwicklerstudios weiterhin auf DX9 setzen, oder es zumindest als Alternativ-Pfad in ihre Engines einpflegen. Den Verlust der XP Gemeinde kann sich keiner leisten, und die informierten User stehen Vista, bzgl. dem DRM Kram und der bisher gebotenen Leistung, so kann ich mir gut vorstellen, eher kritisch gegenüber.

Aber wie gesagt, den Entwicklern steht es frei, der Endkunde kann mit DirectX nichts direkt anfangen - vielleicht kennt er es als Werbeschlagwort durch Spielevertrieben - und damit sehe ich kein rechtliches Problem - welches mir die Diskussion um MediaPlayer und Browser jedoch auch vorenthalten.

Monger

2006-08-07, 11:47:52

Irgendwie ist das grotesk: sobald ein Produkt mal gut und erfolgreich ist, werden Stimmen laut die nach Regulierung rufen! :D

Um den Wettbewerb zu verzerren, müsste ja irgendjemand geschädigt werden. Aber wer soll das sein? OpenGL ist ja eine Open Source Schnittstelle. Jedem steht es frei, sie zu nutzen oder eben nicht. Den Endkunden kann es egal sein, denn eine Schnittstelle ist nur eine Spezifikation. Was den Endkunden interessieren muss ist, wer diese Schnittstelle erfüllt - nämlich die Grafikkartenhersteller mit ihren Treibern.

Wenn man sich also beschweren wollte (was nur schallendes Gelächter ernten würde), dann bei den Spiele-Entwicklern, weil sie aktuelle Hardwarefunktionen nutzen, und die Grafikkartenhersteller, weil sie ihre Grafikkarten weiterentwickeln.

Ein neues Auto erfordert auch teilweise neue Reifen, neue Werkzeuge oder sogar eine andere Benzinsorte. Ich habe noch von keinem Kartellverfahren gehört, weil Benzin gegenüber Diesel den höheren Marktanteil hat...

Fruli-Tier

2006-08-07, 12:05:55

Irgendwie ist das grotesk: sobald ein Produkt mal gut und erfolgreich ist, werden Stimmen laut die nach Regulierung rufen! :D

Um den Wettbewerb zu verzerren, müsste ja irgendjemand geschädigt werden. Aber wer soll das sein? OpenGL ist ja eine Open Source Schnittstelle. Jedem steht es frei, sie zu nutzen oder eben nicht. Den Endkunden kann es egal sein, denn eine Schnittstelle ist nur eine Spezifikation. Was den Endkunden interessieren muss ist, wer diese Schnittstelle erfüllt - nämlich die Grafikkartenhersteller mit ihren Treibern.Meine Worte.
Ein neues Auto erfordert auch teilweise neue Reifen, neue Werkzeuge oder sogar eine andere Benzinsorte. Ich habe noch von keinem Kartellverfahren gehört, weil Benzin gegenüber Diesel den höheren Marktanteil hat...Sollten noch und von nicht vertauscht gehören?
Wie dem auch sei, beim Benzin herrscht doch Produktdifferenzierung, es gibt also verschiedene Versionen. Benzin für die Minimalisten, Super für den Mainstream und Super Plus für die Freaks. Übertrage das auf Windows und die geforderten Regulierungen bzgl. WMP und IE ;)

sry ;(

Monger

2006-08-07, 12:17:34

Meine Worte.
Sollten noch und von nicht vertauscht gehören?

OT:
Ähm... ich glaube nicht. :|

Man könnte den Satz auch verkürzen auf "Ich habe noch nie ... gehört."
Ich finde, "Ich habe nie noch ... gehört." klingt irgendwie bizarr...

Avalox@Gast

2006-08-07, 15:57:12

Irgendwie ist das grotesk: sobald ein Produkt mal gut und erfolgreich ist, werden Stimmen laut die nach Regulierung rufen! :D

DirectX hat ja einen enormen Nachteil. Die Plattformabhängigkeit ist sehr hoch. Der PC steht heute nicht mehr so absolut im Spielefokus. Um nun Entwicklungen und damit auch Portierungen günstig zu gestallten werden Middleware Lösungen eingesetzt. Man mag sich heute noch vielleicht bei PC Umsetzungen Mühe (Zeit für Anpassungen) geben, aber letztendlich wird sich die Mühe im selben Maß reduzieren, wie der Markt eventuell zurückgeht.
Damit sind neue Features in DX zwar schön, aber letztendlich nur so gut, wie diese Funktionen auch von einer verbreiteten Middleware unterstützt werden. Die zentrale Frage ist doch die, wie werden die Spiele von Morgen erstellt? Die Richtung ist ganz klar, die Kostenersparnis geht über alles. Nicht der mit den meisten Funktionen gewinnt, es ist der der die günstigsten Entwicklungsmöglichkeiten bietet. MS bietet doch schon längst Lösungen und ist damit im Wettbewerb. Das mag der eigentlich interessante Markt sein.

Monger

2006-08-07, 16:32:11

Um nun Entwicklungen und damit auch Portierungen günstig zu gestallten werden Middleware Lösungen eingesetzt.

Mal ne ganz dämliche Frage: HABEN Konsolen überhaupt sowas wie ne Middleware?
Ich war bis jetzt der Meinung, dass die sich ziemlich unmittelbar auf den Treiber draufhocken.

Ich hatte auch Demirug so im Kopf, dass eine Portierung sogar unter den Konsolen kein bißchen leichter kommt als zum PC.

Mr. Lolman

2006-08-07, 16:38:15

Hätte man damals mehr 3dfx Karten gekauft, anstatt welche von NV, hätte sich DX wohl nicht so schnell durchsetzen können. ;)

BlackBirdSR

2006-08-07, 16:47:30

Hätte man damals mehr 3dfx Karten gekauft, anstatt welche von NV, hätte sich DX wohl nicht so schnell durchsetzen können. ;)

Und?
Ich finde das hat keinerlei Relevanz zum Thema.

Rückwirkend würde ich mich nicht trauen einen Kommentar abzugeben, ob es nun besser oder schlechter war, dass Direct3D damals so früh gekommen ist.

ShadowXX

2006-08-07, 16:49:41

Mal ne ganz dämliche Frage: HABEN Konsolen überhaupt sowas wie ne Middleware?
Ich war bis jetzt der Meinung, dass die sich ziemlich unmittelbar auf den Treiber draufhocken.

Ich hatte auch Demirug so im Kopf, dass eine Portierung sogar unter den Konsolen kein bißchen leichter kommt als zum PC.
Ja, auch auf Konsolen gibts zuhauf Middleware.

Die Renderware-Engine ist da ein gutes Beispiel......angepasst zwischen den verschiedenen Plattformen muss da natürlich noch trotzdem.

Gast

2006-08-07, 17:22:48

Hätte man damals mehr 3dfx Karten gekauft, anstatt welche von NV, hätte sich DX wohl nicht so schnell durchsetzen können. ;)
Gott sei dank ist es nicht so gekommen... Glide ist total fürn Arsch aus heutiger Sicht.

tokugawa

2006-08-07, 19:24:43

DirectX hat ja einen enormen Nachteil. Die Plattformabhängigkeit ist sehr hoch. Der PC steht heute nicht mehr so absolut im Spielefokus. Um nun Entwicklungen und damit auch Portierungen günstig zu gestallten werden Middleware Lösungen eingesetzt. Man mag sich heute noch vielleicht bei PC Umsetzungen Mühe (Zeit für Anpassungen) geben, aber letztendlich wird sich die Mühe im selben Maß reduzieren, wie der Markt eventuell zurückgeht.
Damit sind neue Features in DX zwar schön, aber letztendlich nur so gut, wie diese Funktionen auch von einer verbreiteten Middleware unterstützt werden. Die zentrale Frage ist doch die, wie werden die Spiele von Morgen erstellt? Die Richtung ist ganz klar, die Kostenersparnis geht über alles. Nicht der mit den meisten Funktionen gewinnt, es ist der der die günstigsten Entwicklungsmöglichkeiten bietet. MS bietet doch schon längst Lösungen und ist damit im Wettbewerb. Das mag der eigentlich interessante Markt sein.

Die meisten Konsolen selber haben APIs, die ebenfalls ziemlich plattformabhängig ist.

Und von der Plattformunabhängigkeit von OpenGL bleibt in Summe in der Praxis auch nicht viel übrig, wenn man High-End-Features nutzen will.

Mal ne ganz dämliche Frage: HABEN Konsolen überhaupt sowas wie ne Middleware?
Ich war bis jetzt der Meinung, dass die sich ziemlich unmittelbar auf den Treiber draufhocken.

Gibt wohl alle Varianten, aber gewisse Engines wie RenderWare oder Shark3D (die Engine die Dreamfall benutzt) gibt's ja auch für Konsolen.

Wenn man auch normale Third-Party-Libraries als Middleware ansieht, gibt's da außerdem noch viel mehr für verschiedene Einsatzzwecke.

Gott sei dank ist es nicht so gekommen... Glide ist total fürn Arsch aus heutiger Sicht.

Naja, Glide hätte sich ja auch mit weiterentwickelt.

Aber stimmt schon, dass Glide NUR auf 3dfx-Karten lief, sprach schon dagegen.

Zum Thema:
Bezüglich der Marktmacht bin ich ziemlich gleichgültig, allerdings stört mich bei DirectX in letzter Zeit auch einiges:
- DirectX9 ist am Ende angelangt, es wird nur mehr Direct3D 10 geben - ich hätt aber gern ein paar Features im DX9-Standard drin, wie etwa Render-to-Vertexbuffer (welches ATI in einem unglaublich häßlichen Hack unter DirectX unterstützt, und dann auch nur als Behelfsausrede dafür, dass sie kein Vertex-Texture-Fetch bieten)
- Trotz dass es im eigentlichen DirectX9 schon lang keine Neuigkeiten mehr gab, gibt's trotzdem laufend neue SDK-Versionen mit neuen D3DX-Versionen, das ist auch ziemlich lästig (vor allem ist die Anzahl der d3dx_??.dll-Dateien mittlerweile wohl bei über 30 angelangt).

Avalox

2006-08-07, 19:52:55

Die meisten Konsolen selber haben APIs, die ebenfalls ziemlich plattformabhängig ist.

Und von der Plattformunabhängigkeit von OpenGL bleibt in Summe in der Praxis auch nicht viel übrig, wenn man High-End-Features nutzen will.

Natürlich ist das so. Das ist ja das Problem. Deshalb werden ja Middleware Lösungen lizenziert und eingesetzt.
Funktionalitäten beschränken sich auf Schnittmengen an Funktionen der verschiedenen Plattformen + Anpassung an individuelle Funktionalitäten, letzteres wird immer weniger Zeit zugemessen, wenn die Verkaufszahlen auf dieser Plattform rückläufig sind.
Deshalb ist es keine Frage, was was bietet. Sondern besteht auch eine realistischen Chance, dass jemand bereit ist den Aufwand zu treiben und zu unterstützen.

Wie ShadowXX schon geschrieben hat ist der Markt der Middleware Lösungen (+ den dazu passenden Entwicklungswerkzeugen) unübersehbar. Ob Gamebryo oder RenderWare, ob GameCoda oder ISACT, ob Speed Tree oder Havoc ... Alle versprechen immer nur eines, nämlich Spiele billiger zu entwickeln.
Natürlich ist auch MS mit dabei. Microsoft XNA (http://www.microsoft.com/xna/)

Es sind letztendlich diese Middleware Lösungen welche entscheiden, wass man wirklich auf dem Bildschirm sieht (hört, interagiert). Nicht die Features einer Grafikkarte oder die Leistungsfähigkeit einer API. Diese Zeiten sind vorbei.

Gast

2006-08-07, 19:58:51

Hätte man damals mehr 3dfx Karten gekauft, anstatt welche von NV, hätte sich DX wohl nicht so schnell durchsetzen können. ;)

toll, auch wenn ich 3dfx-karten mochte, aber eine IHV-abhängige proprietäre schnittstelle kann ja nicht das ziel sein.

Avalox

2006-08-07, 20:12:30

toll, auch wenn ich 3dfx-karten mochte, aber eine IHV-abhängige proprietäre schnittstelle kann ja nicht das ziel sein.

Ja, dass ist eine wirklich interessante Frage. Hätten wir heute eine bessere Grafik, oder eine schlechtere Grafik, wenn sich 3dfx durchgesetzt hätte?
Vielleicht weniger Features, aber sicherlich die Vorhandenen besser präsentiert.

Ich denke eines lässt sich bedenkenlos behaupten. Im Schnitt hätte bestimmt jeder, trotz teurerer Karten weniger bezahlt untern Strich.
Ich bin wahrlich kein Monopol Verfechter, aber das wäre es ja auch nicht gewesen.
Und noch was kann man bedenkenlos behaupten, der Grafikwettlauf hat für eine riesige Blase an Features geführt, die zur Lebenszeiten der einführenden Grafikkarte nie benutzt wurden. Das gab es vorher in der Form auch nicht.

Quasar

2006-08-07, 20:23:35

Hätte man damals mehr 3dfx Karten gekauft, anstatt welche von NV, hätte sich DX wohl nicht so schnell durchsetzen können. ;)
Das ist ein hochinteressantes Thema – für einen eigenen Thread.

DirectX macht sich das selbe Prinzip wie Google zu Nutze. Erst einmal schön alles sammeln, kostenlos anbieten um die User anzufixen und wenn man irgendwann "die Kraft" [(tm) He-Man and the Masters of the Universe] hat, kann man erstmal die Konkurrenz rausdrängen und später sich alles fein versilbern lassen. Dann ist es für Kartellrecht usw. viel zu spät, um noch marktregulierend eingreifen zu können. Allein, weil's dann keinen Markt gibt.

Gast

2006-08-07, 20:41:58

Hmmm, schwieriges Thema. Ich finde aber nicht, daß DirectX das Problem ist sondern eher die Unfähigkeit der Konkurrenz. Die befindet sich irgendwie in einem Dornrösschenschlaf. Man bekommt nix auf die Beine während Microsoft hier einfach vorbeizieht und ein Rundum-Paket präsentiert. Kartellamt schön und gut aber Microsoft ausbremsen weil Konkurrenz nichts auf die Reihe bekommt? Ich weiss nicht ob das so gut wäre. Ich meine, als DirectX noch Crap war, benutzte es auch niemand. Erst mit DirectX7 kam es so richtig auf.

MfG
Die pfiese Priesterin

Gast

2006-08-07, 20:46:40

tokugawa

2006-08-07, 20:53:13

hab ich das richtig verstanden:

je nach middleware lösung wird eine engine für openglide bzw direct3d entwickelt? und der spiele entwickler wählt natürlich die middleware die die günstigste entwicklung verspricht und ist damit dann an openglide/direct3d gebunden?

"OpenGlide" gibts nicht, OpenGL und Glide sind zwei verschiedene Dinge.

Und nein, gute Engines (nennen wir's jetzt mal Engine und nicht Middleware) haben einen abstrakten Renderer, der es erlaubt, die darzustellenden Szenen in verschiedenen APIs "auszugeben".

Da die Entwicklung einer solchen API-Unabhängigkeit ziemlich aufwändig ist, ist es für manche Entwickler günstiger, eine fertige Engine zu lizensieren. So kommt man auch schneller ans echte Spiel.

Es gibt natürlich auch Engines die an eine API gebunden ist, aber das wären dann eher die billigeren.

Jede technisch höherstehende Engine hat selbst ein API (API heißt ja nur Anwendungs-Programmierschnittstelle), mit dem man programmieren kann. Wie diese API dann am Backend dann die Grafikbefehle ausführt (d.h. mit welcher API), kann man transparent verstecken.

Somit gibt es Engines, die entweder von vornherein auf Multi-Grafik-API (OpenGL/DirectX) ausgelegt sind, oder Engines, die eine fest definierte Schnittstelle haben, und um ein Spiel für OpenGL oder DirectX oder irgendeine Konsole lauffähig zu kriegen erfordert einfach ein Neukompilieren mit der entsprechenden Library.

Möglichkeiten gibt's viele. Letztendlich ist eine Engine auch nur die Zwischenschicht (Middleware eben) zwischen Spiel und Grafik-API.

Monger

2006-08-08, 08:21:42

Okay, ich hab da wohl was falsch verstanden, also nochmal:

gibt es DirectX bzw. OpenGL überhaupt für Konsolen? Ich dachte, mal ganz abgesehen von der ersten XBox hätten sich da ohnehin alle selbst ganz eigene APIs gebastelt ?!?

Demirug

2006-08-08, 09:19:22

Die XBox360 API ist wie schon bei der ersten Version stark an DX und Win32 angelehnt. Es gab wohl wenn man den Gerüchten glauben darf auch eine OpenGL Version für die XBox1.

Ebenso spricht man hinter vorgehaltener Hand von einer OpenGL Version für die PS2. Diese soll allerdings nicht sehr performant sein.

Die PS3 nutzt OpenGL ES mit Extensions.

Gamecube scheint soweit ich das beurteilen kann an OpenGL angelehnt zu sein und von Entwicklern hört man das der Nachfolger von der programmierung ähnlich ist.

Im Prinzip ist die API aber sowieso nicht das Problem da man wenn man die Grundlagen verstanden hat schnell von einer zu anderen wechseln kann. Das Problem sind die Eigenheiten der dahinter liegenden Hardware.

Gast

2006-08-09, 14:59:38

Ebenso spricht man hinter vorgehaltener Hand von einer OpenGL Version für die PS2. Diese soll allerdings nicht sehr performant sein.

Die habe ich selbst gesehen. Das sie so langsam war lag wohl daran, dass sie die vector units nur teilweise benutzte. diese sind AFAIK von einander abhaengig, so dass nur eine benutzt wurde.

tiltec

2006-08-09, 15:39:29

Microsoft hat ja Windows benutzt, um DirectX durchzusetzen, ähnlich wie beim Internet Explorer und dem Windows Media Player.
Im Grunde ist das nicht allzu verwerflich, da so nunmal unserere Wirtschaft funktioniert.

Der einzigste meiner Meinung nach existente Konkurrent, OpenGL, ist technisch ungefähr genauso weit. Obwohl es natürlich seine Leistungsfähigkeit nicht so unter Beweis stellen muss wie DX, kann keiner behaupten, dass die Doom 3-Engine wirklich schlecht ausschaut.

Teilweise hat es sogar Vorteile, ich habe heute einen Test über Quad-SLI bei Computerbase gelesen, bei dem (bis auf F.E.A.R und Serious Sam 2) nur die OpenGL-Spiele die 4WayAFR-Modus unterstützen.
Somit waren diese als einzigste deutlich schneller als bei normalem SLI.

Um auf den allgemeinen Teil zurückzukommen:
Meiner Meinung nach ist die Fokussierung auf DirectX einer der Hauptgründe, warum sich Linux nicht besser durchsetzt. Denn das Argument ist ja immer, dass nur so wenige Spiele laufen...allerdings kann dieses Argument auch vorgeschoben sein.

Naja, so schnell wird sich an der DX-Vormachtstellung nichts ändern. Nur eine kleine Softwareschmiede namens id Software leistet Widerstand ;)

tt

Tigerchen

2006-08-09, 15:45:19

Hätte man damals mehr 3dfx Karten gekauft, anstatt welche von NV, hätte sich DX wohl nicht so schnell durchsetzen können. ;)

Das war doch noch schlimmer. Die saßen ja eifersüchtig auf Glide wie das Huhn auf dem Ei. Als Creative einen Wrapper entwickelte wurde Creative denn auch prompt verklagt.

Ja, dass ist eine wirklich interessante Frage. Hätten wir heute eine bessere Grafik, oder eine schlechtere Grafik, wenn sich 3dfx durchgesetzt hätte?
Vielleicht weniger Features, aber sicherlich die Vorhandenen besser präsentiert.

Ich denke eines lässt sich bedenkenlos behaupten. Im Schnitt hätte bestimmt jeder, trotz teurerer Karten weniger bezahlt untern Strich.
Ich bin wahrlich kein Monopol Verfechter, aber das wäre es ja auch nicht gewesen.
Und noch was kann man bedenkenlos behaupten, der Grafikwettlauf hat für eine riesige Blase an Features geführt, die zur Lebenszeiten der einführenden Grafikkarte nie benutzt wurden. Das gab es vorher in der Form auch nicht.

Dafür schaffte 3dfx es nicht geplante Features auch mal in Hardware zu gießen und auf den Markt zu bringen. John Carmack hat sich ja mal zu dem Thema geäußert.

Armaq

2006-08-09, 17:14:06

Da ich ja Wirtschaftsjuristerei studiere möchte ich dazu 2 Dinge anmerken.

Erstens ist es auch volkswirtschaftlicher Sicht sinnvoll, da man bei bestimmten Strukturen Monopole gut gebrauchen kann, um Kapital zu schonen.
Meist gilt das für Netzstrukturen. In diesem Fall handelt es sich um ein Imformationsnetz, dass ein wenig vereinheitlicht, für bessere Leitung sorgt als ein Wirrwarr.

Man stelle sich das ähnlich vor wie ein Wassernetz, nur das wir jetzt keinen Standard für die Anschlüsse haben. Bei keinem kommt es so richtig an und unterwegs wird eine Menge verschwendet. Nur werden solche Monopole meist staatlich gestützt. In unserem Fall ist MS der Staat. ;)

Falls man es juristisch als Monopol ausmacht, kann es aus volkswirtschftlicher Sicht dennoch sinnvoll sein, dieses Monopol bestehen zu lassen. Meiner Meinung nach ist es das auch, denn ohne DX wären wir, vor allem gegenüber Konsolen, chancenlos auf dem Spielemarkt - als Konsumenten wohlgemerkt.
Die Entwicklungskosten würden jedes sprengen.

Noch eines zum Schluss: Des Monopols größter Feind ist der Fortschritt. Also keep workin. :cool:

:D Zweitens: Ich denke, wenn handelt es sich um ein Angebotsoligopol, aber ein echtes Monopol kann man auf dem PC-Sektor nicht ausmachen, da dies nur ein kleiner Teil ist. DX zwingt keinen zu Microsoft zu gehen, höchstens die Spieler. Diese aber stellen nicht den gesamten Markt dar.

tiltec

2006-08-10, 01:34:46

@Armaq:

Kann es sein, dass du hier Monopole und Standards etwas durcheinandermischt?
Das ist zwar schon möglich, da es im Grunde genommen das gleiche ist, wenn man es abstrahiert.

Einen großen Unterschied gibt es aber doch: Monopole kommen aus der Wirtschaft, während Standards meistens auf staatlicher Ebene oder von einer Organisation geschaffen werden.
Heißt auch: Monopole entwickeln sich sozusagen "von alleine", während Standards geplant werden. Und durch diese Planung gibt es auch einen gewissen Grad an Kompatibilität, die bei Monopolen erst nachträglich geschaffen werden muss.

Wenn es einen Standard gibt, dann muss dieser aber auch wirklich gut durchdacht sein. Und hier hakt es meiner Ansicht nach am meisten, viel mehr als bei der Durchsetzung des Standards.

OpenGL ist ja so etwas wie ein Standard, während DirectX sich mehr wie ein Monopol entwickelt hat. Dabei will ich gar nicht werten, es ist nur von der Entwicklung her so. Mittlerweile ist DirectX auch ein Standard, was ich daran festmache, dass sich Microsoft mit dem GPU-Herstellern absprechen muss, was daran geändert wird.

Von daher ist der Unterschied zwischen OpenGL und DirectX auf nicht-technischer Ebene gar nicht so groß. Trotzdem wäre etwas mehr plattformunabhängigkeit für DirectX sehr zu begrüßen...

tt

Demirug

2006-08-10, 01:53:40

OpenGL ist ja so etwas wie ein Standard, während DirectX sich mehr wie ein Monopol entwickelt hat. Dabei will ich gar nicht werten, es ist nur von der Entwicklung her so. Mittlerweile ist DirectX auch ein Standard, was ich daran festmache, dass sich Microsoft mit dem GPU-Herstellern absprechen muss, was daran geändert wird.

Microsoft spricht sich schon immer mit den Herstellern ab. Diese Gespräche finden natürlich nicht in der öffentlichkeit staat.

Von daher ist der Unterschied zwischen OpenGL und DirectX auf nicht-technischer Ebene gar nicht so groß. Trotzdem wäre etwas mehr plattformunabhängigkeit für DirectX sehr zu begrüßen...

tt

Es gibt doch DirectX Implementierungen für Linux und MacOS X.

Zauberer

2006-08-10, 02:31:25

Der einzigste meiner Meinung nach existente Konkurrent, OpenGL, ist technisch ungefähr genauso weit.

Ne viel weiter, OpenGL rulz!
Weil so kann man Spiele für Windows, Linux, MacOS, Solaris usw. ohne viel Aufwand rausbringen, wenn man schlau genug ist!
Verstehe ich nicht, damit könnte man Reich werden.
Spiele die auf jedem System laufen.
Bei den Konsolen (PS2, NGC, XBOX, usw.) machen das doch alle die immer an's Geld denken, warum nicht für PCs?
Quake und Doom 3 für Linux sind ein Beispiel.

Teilweise hat es sogar Vorteile, ich habe heute einen Test über Quad-SLI bei Computerbase gelesen, bei dem (bis auf F.E.A.R und Serious Sam 2) nur die OpenGL-Spiele die 4WayAFR-Modus unterstützen.

Ja stimmt, OpenGL ist einfach flexibler.
Die Leute die ein OpenGL Spiel mit eigener Engine rausbringen sind einfach schlauer.
Bei Serious Sam: The First Encounter war OpenGL auch schneller als D3D!

Naja, so schnell wird sich an der DX-Vormachtstellung nichts ändern. Nur eine kleine Softwareschmiede namens id Software leistet Widerstand ;)

Also die von ID tragen die Nase so was von hoch, die denken die sind besser als der Rest der Welt.

EA z.B. tun zwar nach außen auch so, als wären sie die Besten, aber alle wissen bei EA, dass EA ein hirnloser großer Riese ist.
Nur die lassen sich von Deppen nichts anmerken. ;D

ID denkt bestimmt auch intern, dass sie die Besten sind.
Ok, die Texturen von "Doom 3 Engine" basierenden Spielen ist so was von...:mad:
Aber ok, Bumpmapung und Schatten sind schon sehr gut.
Schlimmer ist eigentlich die nicht vorhandenen Rundungen. :mad:
Mögen die Männer von ID keine Rundungen? :D

Aber ne, ich liebe ID, weil sie gegen M$ und D3D kämpfen.
Ihr wisst ja Konkurrenz muss immer da sein, sonst hätten wir bestimmt noch niemals PS 3.0 usw. (sorry das ich nicht technisch Versierter werde ;)), weil ohne Konkurrenz wird alles träge.
Damals hatte OpenGL eine bessere Lobby dank der über Jahre guten "Quake III Engine".
Darum hat auch MS viel in D3D investiert.
Vista ist der nächste Schritt, bin mal gespannt ob OpenGL auch von Vista profitieren kann?

Ganon

2006-08-10, 08:11:51

Es gibt doch DirectX Implementierungen für Linux und MacOS X.

Öhm, nunja. Wie man es jetzt auslegt.

Einen Wrapper auf OpenGL würde ich jetzt nicht "Implementierung" nennen. Erst wenn Treiber die API direkt kapieren und das native Grafiksystem (X11, Quartz) direkt DirectX versteht, dann würde ich davon sprechen.

tokugawa

2006-08-10, 10:10:21

Von daher ist der Unterschied zwischen OpenGL und DirectX auf nicht-technischer Ebene gar nicht so groß. Trotzdem wäre etwas mehr plattformunabhängigkeit für DirectX sehr zu begrüßen...

Etwas mehr Plattformunabhängigkeit für OpenGL wär auch sehr zu begrüßen... so problemlos portabel wie OpenGL immer dargestellt wird, ist es nicht.

Ne viel weiter, OpenGL rulz!
Weil so kann man Spiele für Windows, Linux, MacOS, Solaris usw. ohne viel Aufwand rausbringen, wenn man schlau genug ist!

Ohne viel Aufwand? Schon mal versucht eine OpenGL-basierte Engine zu schreiben die auf allen diesen Systemen läuft und State-of-the-Art-Features wie FBOs oder PBOs verwendet?

Verstehe ich nicht, damit könnte man Reich werden.
Spiele die auf jedem System laufen.
Bei den Konsolen (PS2, NGC, XBOX, usw.) machen das doch alle die immer an's Geld denken, warum nicht für PCs?

Denk mal nach, jene Spiele die für alle Konsolen-Plattformen rauskommen, kommen oft auch für PC mit DirectX raus (Splinter Cell, Prince of Persia, usw.). Das hat mit der API nichts zu tun sondern mit der Engine, die verschiedene APIs ansprechen kann.

Demirug

2006-08-10, 10:13:20

Öhm, nunja. Wie man es jetzt auslegt.

Einen Wrapper auf OpenGL würde ich jetzt nicht "Implementierung" nennen. Erst wenn Treiber die API direkt kapieren und das native Grafiksystem (X11, Quartz) direkt DirectX versteht, dann würde ich davon sprechen.

Dafür müßte aber die jeweiligen Kernel Entwickler über ihren Schatten springen. Oder als zweit beste Lösung die IHVs etwas Passendes anbieten. Allerdings ist API Wrapping zum Erreichen von Kompatibilität ja selbst innerhalb eines Betriebssystem nichts Ungewöhnliches.

Demirug

2006-08-10, 10:20:34

Ne viel weiter, OpenGL rulz!
Weil so kann man Spiele für Windows, Linux, MacOS, Solaris usw. ohne viel Aufwand rausbringen, wenn man schlau genug ist!
Verstehe ich nicht, damit könnte man Reich werden.
Spiele die auf jedem System laufen.
Bei den Konsolen (PS2, NGC, XBOX, usw.) machen das doch alle die immer an's Geld denken, warum nicht für PCs?

Man muß nur die Anzahl der Systeme vergleichen. PC mit Linux oder MacOS Systeme sind im Vergleich zu der Anzahl der Konsolen und PCs mit Windows einfach so gering das sich eine Portierung nicht lohnt. Ein gutes Beispiel dafür ist ja bekanntermaßen Loki. Aus dem Grund versucht TransGaming ja gerade einen anderen Weg in dem sie versprechen das Windows Spiele ohne Änderungen am Sourcecode unter MacOS laufen. Um die Hemmschwelle noch weiter zu senken verlangen sie nur Lizenzgebühren für die dadurch zusätzlich verkaufen Versionen.

Armaq

2006-08-10, 10:21:35

@Armaq:

Kann es sein, dass du hier Monopole und Standards etwas durcheinandermischt?
Das ist zwar schon möglich, da es im Grunde genommen das gleiche ist, wenn man es abstrahiert.

tt

Nein.
Denk an das frühe Telefon- und Wassernetz. Staatlich.

Monopole entstehen auch nicht immer einfach von alleine. Man kann sie mit Gesetzen fördern und sogar bedingen - bei dem Aufbau von Netzen ist das meist gewünscht, da ansonsten jeder "sein" Netz baut und damit Unmengen an Kapital vernichtet wird.

Wie gesagt, die Marktmacht von DirectX beschränkt sich auf das Spielen am PC. Ansonsten gibt es genug andere Alternativen.
Für Spieler existieren ebenso Alternativen. Ergo gibt es keine monopolistische Stellung. Microsoft kann den Spielemarkt weder in Menge, noch in Preis diktieren. Bei PC-Betriebssystemen sieht das anders aus.

tiltec

2006-08-10, 11:28:17

Microsoft spricht sich schon immer mit den Herstellern ab. Diese Gespräche finden natürlich nicht in der öffentlichkeit staat.
Das ist mir schon klar, dass die Gespräche nicht in der Öffentlichkeit stattfinden.
Aber im Vergleich zu früher sind die Hardwarehersteller stärker in den Prozess eingebunden, meine ich.

Es gibt doch DirectX Implementierungen für Linux und MacOS X.
Das war mir noch nicht bekannt. Geht das soweit, dass ich ein DirectX-Spiel auf Linux spielen könnte?
Fehlt es da an der Ausgereiftheit der Implementierungen, dass so etwas nicht verbreitet ist oder braucht man da noch andere Dinge?

tt

tiltec

2006-08-10, 11:33:00

Etwas mehr Plattformunabhängigkeit für OpenGL wär auch sehr zu begrüßen... so problemlos portabel wie OpenGL immer dargestellt wird, ist es nicht.

Die Liste der unterstützten Plattformen ist schon recht lange:
http://de.wikipedia.org/wiki/OpenGL#Unterst.C3.BCtzte_Plattformen

Wo hakt es denn deiner Meinung nach bei der Portierung? Etwa am Grafiktreiber?

tt

tiltec

2006-08-10, 11:49:05

Monopole entstehen auch nicht immer einfach von alleine. Man kann sie mit Gesetzen fördern und sogar bedingen - bei dem Aufbau von Netzen ist das meist gewünscht, da ansonsten jeder "sein" Netz baut und damit Unmengen an Kapital vernichtet wird.

Wenn ein Monopol staatlich gefördert wird, dann darf der Staat meistens mitreden. Die Frage bei Netzen ist, ob man nicht eher von Standards sprechen sollte, solange der Staat mitreden darf.
Bei dem Beispiel mit der Wasserversorgung stimme ich dir zu, dass ein Monopol (oder eben Standard) ökonomisch förderlich ist. Jedoch gibt es meiner Meinung nach in diesem Bereich wenig Möglichkeit für Innovationen, ganz im Gegensatz zum PC-Grafiksektor.

Wie gesagt, die Marktmacht von DirectX beschränkt sich auf das Spielen am PC. Ansonsten gibt es genug andere Alternativen.
Für Spieler existieren ebenso Alternativen. Ergo gibt es keine monopolistische Stellung. Microsoft kann den Spielemarkt weder in Menge, noch in Preis diktieren. Bei PC-Betriebssystemen sieht das anders aus.

Nur auf Spiele beschränkt es sich nicht. Jedes Video wird unter Windows über einen DirectShow-Filter abgespielt, der auch Teil von DX ist. Außerdem gibt es ja noch die ganzen anderen "Direct"-Sachen, wie DirectSound usw.

Und auch Spiele alleine sind nicht so unwichtig. Wie man aus der Vergangenheit der PC-Entwicklung gesehen hat, hat die Spiele-Industrie die Entwicklung sehr beschleunigt. Und Microsoft kann durchaus lenken, indem sie durch DirectX-Features vorschreibt, die unterstützt werden müssen.
Stell dir mal eine Grafikkarte vor, die DirectX nicht vollständig unterstützt. Nahezu unverkäuflich. Auch wenn sie OpenGL perfekt kann.

Weil OpenGL im Spielemarkt eben unwichtig ist, kaum jemand wird nur Quake spielen ;)
Und das macht eben ein Monopol aus. Es gibt ja auch Linux als Konkurrenz, aber trotzdem hat Microsoft mit Windows im Desktopbereich ein Monopol.

tt

Simon

2006-08-10, 12:06:29

Das war mir noch nicht bekannt. Geht das soweit, dass ich ein DirectX-Spiel auf Linux spielen könnte?
Ja, einige wenige Sachen laufen mit (mehr oder weniger) Einschränkungen ;(
Das meiste geht jedoch nicht, schon gar nicht, wenns kein Blockbuster wie WoW ist...
Vielleicht meint ja auch Demirug andere Programme als Cedega und Wine?

Fehlt es da an der Ausgereiftheit der Implementierungen, dass so etwas nicht verbreitet ist oder braucht man da noch andere Dinge?
Siehe oben. Das ganze ist nicht wirklich ausgereift. Dazu kommen miese Treiber bestimmter Hersteller (nein, nicht nur ATI!) :mad:

tokugawa

2006-08-10, 21:07:18

Die Liste der unterstützten Plattformen ist schon recht lange:
http://de.wikipedia.org/wiki/OpenGL#Unterst.C3.BCtzte_Plattformen

Ist mir bekannt, hat nichts mit dem zu tun was ich geschrieben hab.

Wo hakt es denn deiner Meinung nach bei der Portierung? Etwa am Grafiktreiber?

Ja, darauf könnte man es reduzieren. Wenn man's genau betrachtet gibt's einige Hürden:
- OpenGL hat einen OS-abhängigen Layer (WGL, GLX, usw). Der einzige wirklich breit verfügbare und mittlerweile stabile Render-to-Texture-Mechanismus ist in diesem Layer implementiert (PBuffer). Das macht die Sache schon mal für Render-to-Texture-Effekte nicht leicht.
- FBOs, die PBuffer ablösen sollen, werden anscheinend nicht rückportabel (also auf GeForce 4 und drunter) unterstützt. Folglich muß man, wenn man GeForce 4 und drunter unterstützen will, Renderpfade schreiben. Gut, hier kann man einhaken dass es langsam Zeit wird, auf DirectX9-Tech-Level zu setzen
- FBOs selbst sind nur EXT. Die Implementationen seitens ATI und NVIDIA sind teilweise buggy, weichen teilweise voneinander ab, und sind sowieso nicht auf allen Betriebssystemen verfügbar. Weiters scheint ATI nicht ARB_texture_float zu unterstützen, sondern nur ATI_texture_float. Wieder eine Ungereimtheit, die die Portabilität killt.
- Jetzt kommen wir zu den Treibern an sich: die sind sogar vom selben Hersteller für verschiedene Plattformen von unterschiedlicher Qualität, und reagieren teilweise anders. Das macht portieren ebenfalls zu einer ziemlich aufwändigen Angelegenheit. Der Testaufwand quadriert sich quasi bezüglich Engine-Features und Plattformen (jedes neue Feature bedingt ein durchtesten auf allen Plattformen).

Das sind nur einige Probleme die in der Praxis einfach auftreten mit OpenGL. Das ist natürlich kein prinzipielles Problem von OpenGL, aber halt eines das (pragmatisch gesehen) leider in der Realität die Portabilität sehr aufwändig macht.

Jedenfalls geht das klassische "Einmal schreiben, und für jede Plattform kompilieren" schon mal auf jeden Fall nicht, wenn man State-of-the-Art-Features verwenden will. Das geht sowieso prinzipiell schon nicht, da es ja den OS-abhängigen Layer gibt, außer man verwendet Libraries die einem diese Arbeit abnehmen (SDL, GLUT), aber dann hat man dieses unglaublich häßliche Textmodus-Fenster im Hintergrund (das man irgendwie killen kann, ich weiß, aber das ist auch nur ein Hack).

Außerdem muß man bedenken dass es nicht nur OS-Plattformen gibt deren Eigenheiten man beachten muß, sondern auch GPU-Plattformen. Wenn man z.B. ATI- und NVIDIA-Karten unterstützt, und sagen wir 3 OS-Plattformen (Windows, MacOS X, Linux), dann hat man schon mal 6 (2 mal 3) Testkonfigurationen, die sich jeweils anders verhalten können. Wenn man jeweils ATI und NVIDIA in verschiedene GPU-Generationen aufsplittet, wird die Testmatrix noch größer und und und.

Deswegen ist es selbst bei OpenGL wesentlich angenehmer, wenn man 1 oder maximal 2 Plattformen direkt unterstützt.

Landmann

2006-08-11, 11:08:33

Die PS3 nutzt OpenGL ES mit Extensions.
Die PS3 _kann_ ueber OpenGL ES programmiert werden, bietet allerdings auch eine eigene API (zum Glueck). OpenGL ES wird eigentlich nur fuer rapid-Prototyping empfohlen...

tiltec

2006-08-11, 12:18:51

@tokugawa

Öha, so genau kenne ich mich da nicht aus, ich habe das bisher immer recht oberflächlich betrachtet.
Aber vielen Dank für die ausführliche Beschreibung des Problems. :cool:

Mir scheint, dass das Problem der mangelhaften Portabilität darin liegt, dass alles zu stark ineinander verzahnt ist. So ähnlich wie bei DOS, als noch jedes Textverarbeitungsprogramm seinen eigenen Druckertreiber mitbringen musste, damit alles funktioniert. Auf Windows-Ebene gibt es dafür relativ universelle Treiber-Schnittstellen, wo theoretisch jede Textverarbeitung mit jedem Drucker sprechen kann, hauptsache, der Druckertreiber für Windows funktioniert.:tongue:

Und so etwas fehlt mir eigentlich im Grafikmarkt. DirectX bietet für Windows in etwa ein universelles Interface, ist aber im Gegensatz zu anderen Interfaces schon sehr spezialisiert. Deswegen ist es so schwer portabel.
Zu OpenGL hast du ja schon viel geschrieben, soweit ich das erkennen kann, sind das ähnliche Probleme.

Trotzdem ist vielleicht die bisherige Lösung besser. Denn eine universellere Struktur führt immer zu mehr Ebenen und damit wird die Grafik langsamer.
Auch wenn so eine Art Java für Grafikkarten toll wäre, wären die Spiele, die auf dieser Runtime aufbauen würde, sehr langsam. :mad:

Hier noch relativ OT: :biggrin:
Dieses Prinzip zieht sich durch die gesamt Natur.
Beim Menschen gibt es auch verschiedene Möglichkeiten, auf die Umwelt zu reagieren. Einmal die Reflexe - schnell, da wenige Ebenen; dann die Instinke - auch noch relativ schnell, aber schon etwas mehr Ebenen; sobald aber etwas über unserer Großhirnrinde läuft, wirds richtig langsam - weil eben so viele Ebenen beteiligt sind. Dafür gibt es aber auch mehr Möglichkeiten.
(Kennt ihr Geist & Gehirn auf BR alpha? Hat zwar wenig mit Technik zu tun, trotzdem sehr empfehlenswert...)

tt

tokugawa

2006-08-11, 19:10:59

Naja sowas wie eine Art "Java für Grafik" wären dann die Engines, bzw. die Middleware. Das ist dann die Softwareebene die die eigentliche Anwendung (Game) verbindet mit der Grafik-API (OpenGL oder DirectX) und dazwischensitzt. Die Anwendung (das Game) sieht nur die Schnittstelle der Engine, und wie die Engine diese Dinge dann umsetzt in OpenGL oder DirectX, ist der Engine überlassen.

Und richtig langsam ist das ja dann nicht (Java ist ja auch nur dann "langsam", wenn es interpretiert wird, hat man in der Virtual Machine Just-In-Time-Compiling dann ist auch Java nicht mehr wesentlich langsamer ist als eine "nativ kompilierende" Sprache).

Avalox

2006-08-11, 21:11:56

@tokugawa

Mir scheint, dass das Problem der mangelhaften Portabilität darin liegt, dass alles zu stark ineinander verzahnt ist.
tt

Sehe dir doch mal Folie 6 der PowerPoint Datei mit den Entwicklungstools-/Middleware Lösungen an.

http://www.microsoft.com/downloads/details.aspx?FamilyID=80af86b1-9dc6-4894-87b4-47de83396a0e&DisplayLang=en

Gast

2006-08-11, 22:11:35

Die PS3 _kann_ ueber OpenGL ES programmiert werden, bietet allerdings auch eine eigene API (zum Glueck). OpenGL ES wird eigentlich nur fuer rapid-Prototyping empfohlen...
Quelle? Das PS3 OpenGL ES ist de-facto eine eigene API die auf den RSX zugeschnitten ist.

Register-Level wird das Ding sicher keiner mehr programmieren.

Gast

2006-08-11, 22:14:51

Weiters scheint ATI nicht ARB_texture_float zu unterstützen, sondern nur ATI_texture_float. Wieder eine Ungereimtheit, die die Portabilität killt.

Leider logisch, weil ARB_texture_float Mip-Mapping verlangt was die R5xx-TMUs bei float Texturen nicht können.

da.phreak

2006-08-12, 09:42:39

Falls man es juristisch als Monopol ausmacht, kann es aus volkswirtschftlicher Sicht dennoch sinnvoll sein, dieses Monopol bestehen zu lassen.

Erstmal danke für den fachlich fundierten Beitrag. Bin leider in dieser Hinsicht Laie, möchte aber trotzdem meinen Senf dazugeben: In der Regel spricht doch nichts dagegen, Monopole bestehen zu lassen, diese sind auch nicht Rechtswidrig oder etwas in der Richtung. Zum Problem wird's doch erst wenn ein Monopol benutzt wird, um in einem anderen Markt ein zweites aufzubauen. Erst dann wird - wenn ich es richtig verstehe - von staatlicher Seite interveniert. Z. B. konnte Microsoft wunderbar Netscape aus dem Markt drängen, indem es den Internet Explorer als Standardkomponente von Windows mitliefert. Hier wurde das Monopol bei Betriebssytemen benutzt, um ein Monopol bei Browsern aufzubauen.

Ob man in diesem Fall DirectX als zweiten Markt interpretieren möchte ist fraglich. Die praktischen Auswirkungen als Linux-User bekomme ich zu spüren, es gibt schlicht sehr wenige Spiele, bzw. nur über umständliche Lösungen (DirectX-OpenGL-Wrapper), die nicht immer funktioniert. Ich persönlich bin froh, daß ID software OpenGL unterstützt. Ich denke nur so sind die Grafikkartenhersteller gezwungen, auch dieses in guter Qualität anzubieten.

Für mich halte ich es so, daß ich nichts spiele, was unter Linux nicht läuft. Windows zu booten ist mir zu umständlich.

Gast

2006-08-12, 12:41:50

Quelle?
k.A.
Das PS3 OpenGL ES ist de-facto eine eigene API die auf den RSX zugeschnitten ist.
Leider fehlen ein paar gute Dinge dabei, z.B. direkter Pushbuffer-Zugriff, direkte Speichermanipulation, usw.
Persoenlich glaube ich, OpenGL ES wurde von Sony nur gewaehlt, um sagen zu koennen: Schaut her, das Ding entspricht einem neuen Industrie-Standard.
Lustigerweise ist die "andere" API viel naeher an DirectX als OpenGL (ES) (um mal auf das Thema zurueck zu kommen).
Register-Level wird das Ding sicher keiner mehr programmieren.
Quelle ? ;) Ich will es nicht, aber es gibt Leute, die freuen sich wirklich , wenn sie eine Register-Doku dazu in den Haenden halten koennten.

Landmann

2006-08-12, 12:58:10

Eines ist doch auch klar, "Standards" lohnen sich vor allem dort, wo die HW sich rapide veraendern kann. Ein PC zum Beispiel.
Fuer Konsolen halte ich das eher fuer unpraktisch, wenn man sich dort an PC Standards orientieren will. Es ist kein Problem, fuer eine wirklich _feste_ Hardwarebasis eigene Standards zu definieren, welche diese Platform auch gut ausnutzen koennen.
Zumindest was Konsolen angeht, sind in meinen Augen die Grafikueberfliegertitel (nach 1-2 Jahren auf dem Markt) diejenigen, die die HW bis zur letzten Ecke ausnutzen, und das geht mit einer API, die einen moeglichst grossen Standard ueber -zig Platformen bieten will, einfach nicht.

Edit:
Bin eine Quelle schuldig geblieben: Google nach "PS3 libgcm" ...

tokugawa

2006-08-12, 16:50:05

Leider logisch, weil ARB_texture_float Mip-Mapping verlangt was die R5xx-TMUs bei float Texturen nicht können.

Weiß ich, aber genau das kreide ich ATI an: dass denen in Hardware die Features für ARB_texture_float fehlen.

Eines ist doch auch klar, "Standards" lohnen sich vor allem dort, wo die HW sich rapide veraendern kann. Ein PC zum Beispiel.
Fuer Konsolen halte ich das eher fuer unpraktisch, wenn man sich dort an PC Standards orientieren will. Es ist kein Problem, fuer eine wirklich _feste_ Hardwarebasis eigene Standards zu definieren, welche diese Platform auch gut ausnutzen koennen.
Zumindest was Konsolen angeht, sind in meinen Augen die Grafikueberfliegertitel (nach 1-2 Jahren auf dem Markt) diejenigen, die die HW bis zur letzten Ecke ausnutzen, und das geht mit einer API, die einen moeglichst grossen Standard ueber -zig Platformen bieten will, einfach nicht.

Naja, prinzipiell hast du schon recht, allerdings sind ja Konsolen heutzutage auch nicht so viel anders von deren Grafiksystemen her. Standards sind ja nicht dazu da, komplett verschiedene Sachen zu gruppieren, sondern immer "ähnliche Sachen die einen hohen Deckungsbereich haben". Insofern kann man mit einer übergreifenden API, die halt einen bestimmten Techlevel abdeckt, auch die Hardware ausreizen.

Armaq

2006-08-13, 10:41:28

Nur auf Spiele beschränkt es sich nicht. Jedes Video wird unter Windows über einen DirectShow-Filter abgespielt, der auch Teil von DX ist. Außerdem gibt es ja noch die ganzen anderen "Direct"-Sachen, wie DirectSound usw.

Und auch Spiele alleine sind nicht so unwichtig. Wie man aus der Vergangenheit der PC-Entwicklung gesehen hat, hat die Spiele-Industrie die Entwicklung sehr beschleunigt. Und Microsoft kann durchaus lenken, indem sie durch DirectX-Features vorschreibt, die unterstützt werden müssen.
Stell dir mal eine Grafikkarte vor, die DirectX nicht vollständig unterstützt. Nahezu unverkäuflich. Auch wenn sie OpenGL perfekt kann.

Weil OpenGL im Spielemarkt eben unwichtig ist, kaum jemand wird nur Quake spielen ;)
Und das macht eben ein Monopol aus. Es gibt ja auch Linux als Konkurrenz, aber trotzdem hat Microsoft mit Windows im Desktopbereich ein Monopol.

tt

Monopole werden als solche erkannt, wenn sie in der Lage sind Preis und/oder Menge zu diktieren. Microsoft kann weder Preis noch Menge der angebotenen Spielesoftware diktieren, ansonsten gäbe es nur Microsoft Games. Du hast als Hersteller die Möglichkeit von OpenGL - wenn MS bei DX dicht macht.
Es würden Herrscharen zu OpenGL wechseln, wenn MS ein härteres Diktat fahren würde!

Des Weiteren besteht die Möglichkeit für Spieler, auf Konsolen auszuweichen. MS kann dem Zocker nichts diktieren.

Auch Grafikkartenhersteller sind dem Diktat von MS nicht unterworfen. MS möchte diese mit DX an sich binden, hier könnte in Zukunft ein Problem entstehen, wenn MS die fortschrittlichste Grafik auf D3D möglich macht und es dann ausnutzt. Dies sehe ich als Gefahr bei DX/D3D.

Erstmal danke für den fachlich fundierten Beitrag. Bin leider in dieser Hinsicht Laie, möchte aber trotzdem meinen Senf dazugeben: In der Regel spricht doch nichts dagegen, Monopole bestehen zu lassen, diese sind auch nicht Rechtswidrig oder etwas in der Richtung. Zum Problem wird's doch erst wenn ein Monopol benutzt wird, um in einem anderen Markt ein zweites aufzubauen. Erst dann wird - wenn ich es richtig verstehe - von staatlicher Seite interveniert. Z. B. konnte Microsoft wunderbar Netscape aus dem Markt drängen, indem es den Internet Explorer als Standardkomponente von Windows mitliefert. Hier wurde das Monopol bei Betriebssytemen benutzt, um ein Monopol bei Browsern aufzubauen.

Ob man in diesem Fall DirectX als zweiten Markt interpretieren möchte ist fraglich. Die praktischen Auswirkungen als Linux-User bekomme ich zu spüren, es gibt schlicht sehr wenige Spiele, bzw. nur über umständliche Lösungen (DirectX-OpenGL-Wrapper), die nicht immer funktioniert. Ich persönlich bin froh, daß ID software OpenGL unterstützt. Ich denke nur so sind die Grafikkartenhersteller gezwungen, auch dieses in guter Qualität anzubieten.

Für mich halte ich es so, daß ich nichts spiele, was unter Linux nicht läuft. Windows zu booten ist mir zu umständlich.
Monopole bzw. starke Wettbewerbsvorteile zu nutzen, um eine andere Sparte zu pushen ist de facto rechtswidrig. Monopole an sich können aber schon ins Visier der Kartellbehörden geraten, wenn sie nur ihren Markt diktieren. Du musst dazu nicht in andere Bereiche eindringen.
Wie oben erwähnt bindet MS die Spielehersteller durch DX. Das kann in Zukunft zu Problemen führen die weitreichender sind, als das von dir angesprochene Problem der fehlenden Linuxportierung.
Da ATI und NV absolut führend in der Herstellung von Grafikkarten sind und eng mit MS kooperieren, kann es dazu kommen, dass irgendwann ein Vorsprung herausgearbeitet wird, der für andere so nicht einzuholen ist und MS dann die XBOX promotet, oder hohe Lizenzgebühren verlangt etc...

Vanilla

2006-08-13, 11:35:19

tokugawa

2006-08-13, 18:02:50

Ich habe letztlich gelesen dass das nächste Spiel von id-Software nicht mehr auf der Doom3-Engine basiert, sondern das eine neue entwickelt wird. Glaubt ihr das diese auch wieder auf OpenGL basiert?
Ich hoffe es ja denn rein subjektiv betrachtet, fand ich die Doom3 Grafik sehr schön anzusehn.

Ob ein Spiel hübsch ist oder nicht, hängt eigentlich überhaupt nicht von der API ab, und auch nicht primär von der Engine, sondern zum Großteil an fähigen Artists, die schönen Content produzieren.

Ich könnte mir schon denken dass zumindest die PC-Version des nächsten id-Projekts auch OpenGL unterstützt (im Endeffekt ist das ja nicht wirklich eine wichtige Frage, da die Architektur der Engine wohl auch austauschbare Renderer unterstützt).

Allgemein finde ich es gut wenn es noch etwas Konkurenz zu DirectX gibt - mehr Vielfalt schadet bestimmt nicht.

Im Gegensatz zu den meisten Leuten seh ich OpenGL nicht unbedingt als direkte Konkurrenz zu DirectX, sondern mehr als "zwei Dinge die ähnliche Dinge machen aber für verschiedene Aufgaben konzipiert sind - und halt auch einen kleinen Deckungsbereich haben".

Noch ne Zweite Frage: DirectX wird ja von Microsoft weiterentwikelt und mit neuen Features erweitert. Aber wer macht das eigentlich für OpenGL???

OpenGL wurde bis vor kurzem von einem Konsortium von verschiedenen Firmen (das Architecture Review Board, oder ARB) kontrolliert und spezifiziert. Dieses ratifiziert Extensions und die Core-Funktionen. Bei OpenGL haben die einzelnen GPU-Hersteller (sogenannte Vendors) aber auch das Recht, vom Standard abweichende, eigene Extensions (sogenannte "Vendor-Extensions") hinzuzufügen.

Dadurch gibt's bei OpenGL die Situation dass Features von Grafikkarten immer ziemlich gleich benutzbar sind für Entwickler, aber zuerst eben über Vendor-Extensions (d.h. nicht allgemein für alle GPUs benutzbar - also mit eingeschränkter Portabilität bezüglich GPUs). Bis diese in den Standard kommen (d.h. vom ARB ratifiziert werden) dauerte es meist sehr sehr lange, da das ARB ein ziemlich träges Instrument war.

Bei der letzten Siggraph ist die Kontrolle über den OpenGL-Standard allerdings an die Khronos-Group gegangen, die auch bisher einige offene Standards (OpenGL ES, Collada) als bestimmender Körper übernommen hat. Natürlich in der Hoffnung, dass der träge Entscheidungsprozeß des ARB der Vergangenheit angehört, und so OpenGL neuen Standards angepasst werden kann.

Vanilla

2006-08-13, 22:01:35

Simon

2006-08-13, 22:06:38

Gast

2006-08-14, 02:25:13

Diese Stimmen haben dann aber leider keine Ahnung über die bisherigen Prozesse bei OpenGL. Die Mühlen des ARBs waren dafür bekannt sehr langsam zu mahlen. In wie weit sich das jetzt ändern wird muß sich zeigen.
Nachdem da endlich auch der letzte Depp begriffen hat, daß MS im ARB nur den Maulwurf-Job gemacht, dürfte es nun brauchbar vorwärts gehen.

tokugawa

2006-08-14, 06:10:46

Erst einmal Danke für die umfassenden Informationen! Allerdings kann ich nicht verstehn weshalb id-Software eine neue Engine entwickelt wenn es doch angeblich nur marginale Auswirkungen auf die Grafikkqualität hat. Das musst du vieleicht noch etwas erläutern :|

Ein guter Artist kann aus einer schlechten Engine noch einiges rausholen, aber eine noch so gute Engine kann schlechtes Artwork nicht mehr retten. Mir ging's nur darum dass eine Engine ein Stück Technik ist, das was man sieht aber maßgeblich von den Artists abhängt.

Die Engine gibt den Artists/Designern nur die Möglichkeit, etwas Schönes zu vollbringen.

Warum man dann neue Engines entwickelt? Klar: weil immer wieder neue Technologien kommen, die den Artists ermöglicht, noch Schöneres aus der Engine zu holen (ob dieses Potential genutzt wird oder nicht, hängt eben auch wiederum von den Artists ab).

Ich schrieb ja "hängt nicht primär von der Engine ab": also nicht primär, aber sekundär schon.

Deswegen sag ich auch immer dass eine Engine mehr ist als die Effekte, die sie kann und die Performance, die sie liefert: wichtig sind auch eine gute Toolchain, gute Art/Asset-Tools, und Wartbarkeit (damit man die Engine auch um neue Effekte und Features erweitern kann/modifizieren kann). Auch in diesen Bereich kann man immer etwas besser machen.

Außerdem fangen ja neue Engines nicht wirklich von Null an: das Know-How aus den vorigen Engines fließt mit ein, und ein erheblicher Teil des Codes wird auch übernommen (oder refaktorisiert).

D.h. jede Engine von id-Software ist Teil einer einer gewissen Evolution an Engines.

sth

2006-08-14, 07:38:12

Diese Stimmen haben dann aber leider keine Ahnung über die bisherigen Prozesse bei OpenGL. Die Mühlen des ARBs waren dafür bekannt sehr langsam zu mahlen. In wie weit sich das jetzt ändern wird muß sich zeigen.
OpenGL hat viel verschenkt als das ARB es nicht geschafft hat, einen Standard für die erste Shader-Generation zu entwickeln.

Ne viel weiter, OpenGL rulz!
Weil so kann man Spiele für Windows, Linux, MacOS, Solaris usw. ohne viel Aufwand rausbringen, wenn man schlau genug ist!
Verstehe ich nicht, damit könnte man Reich werden.
Ich bin der letzte der gegen platformübergreifende Entwicklung ist aber du stellt dir das jetzt wirklich etwas zu einfach vor. Sowohl den Aufwand als auch die Absatzchancen betreffend.

Jetzt kommen wir zu den Treibern an sich: die sind sogar vom selben Hersteller für verschiedene Plattformen von unterschiedlicher Qualität
Das ist genau der Punkt. Hier kommen in der Praxis die meisten Probleme her, selbst wenn man nicht alle Cutting-Edge-Features ausreizt (und woran eben die meisten Leute nicht denken, wenn sie nach Cross-Platform-Support rufen).

Bei nVidia ist es noch relativ einfach, da der Linux-Treiber sich relativ ähnlich wie der Windows-Treiber verhält (habe leider noch keine Mac-Testplatform mit nVidia Hardware zum Vergleich, von daher kann ich darüber keine Aussage treffen - wobei ich schon gehört habe, dass sie früher nicht so der Hit gewesen sein sollen).

Bei ATI hingegen habe ich das Gefühl, dass sie zwischen den Platformen wesentlich weniger shared code haben als sie immer angeben (genauergesagt weiß ich, dass es früher sogar komplett getrennte Treiber-Teams waren und sie erst letztes Jahr angefangen haben, etwas daran zu ändern). Einen Hinweis auf Code-Sharing zwischen den Treiber-Teams habe ich inzwischen jedoch gefunden: Die geänderte Display-Erkennung ab Catalyst 5.7 war kurze Zeit später auch im Linux-Treiber zu finden (was bedeutet, dass ich auf meinem Notebook jetzt auf beiden Systemen keine neueren Treiber mehr verwenden kann, weil das interne TFT nicht mehr erkannt wird ;) ).

... aber was das effektiv für die Praxis bedeutet ist eben, dass man 3 Systeme mit sich teilweise komplett unterschiedlich verhaltenden Treibern an der Backe hat. Da man als Entwickler meist primär auf einer Platform entwickelt und dort dann natürlich auch die meisten Tests macht kann es schnell ziemlich aufwändig werden, die anderen OS/Graka Kombinationen im Auge zu behalten.

da es ja den OS-abhängigen Layer gibt, außer man verwendet Libraries die einem diese Arbeit abnehmen (SDL, GLUT), aber dann hat man dieses unglaublich häßliche Textmodus-Fenster im Hintergrund (das man irgendwie killen kann, ich weiß, aber das ist auch nur ein Hack).
Hmm... mit SDL gibt's da eigentlich keine Probleme:
Unter Windows kann man beim Übersetzen von SDL einstellen ob stdout/err automatisch in Dateien geloggt werden sollen (was ich aber eher nervig finde). Ob das Konsolenfenster aufgeht oder nicht hat aber eigentlich nichts mit SDL direkt zu tun. Bei MinGW kann man das Konsolenfenster generell mittels -mwindows unterbinden. Unter MSVC weiß ich es nicht auswendig (zu lange nichts mehr damit gemacht).

Unter Linux wird von selbst kein Terminalfenster aufgehen.
Unter MacOSX ist SDL nicht von X11 abhängig, von daher wird auch nicht das Terminal-Fenster aus dem X11-Autostart aufgehen.

Wie's mit GLUT aussieht weiß ich leider nicht.

Monger

2006-08-14, 08:09:46

Naja sowas wie eine Art "Java für Grafik" wären dann die Engines, bzw. die Middleware. Das ist dann die Softwareebene die die eigentliche Anwendung (Game) verbindet mit der Grafik-API (OpenGL oder DirectX) und dazwischensitzt. Die Anwendung (das Game) sieht nur die Schnittstelle der Engine, und wie die Engine diese Dinge dann umsetzt in OpenGL oder DirectX, ist der Engine überlassen.

Wenn ich das richtig verstanden habe, ist WinFX genau das. Man fordert von oben her bestimmte Fensterelemente an. Wie die gerendert werden, ist die Sache von WinFX.
Aber natürlich ist das eine Sache die nur für Vista funktioniert, mit Portabilität ist da nix. Wieso sollte man auch eine frisch entwickelte Techologie gleich an die Konkurrenz verteilen?

tokugawa

2006-08-14, 09:10:45

Wenn ich das richtig verstanden habe, ist WinFX genau das. Man fordert von oben her bestimmte Fensterelemente an. Wie die gerendert werden, ist die Sache von WinFX.
Aber natürlich ist das eine Sache die nur für Vista funktioniert, mit Portabilität ist da nix. Wieso sollte man auch eine frisch entwickelte Techologie gleich an die Konkurrenz verteilen?

Ich dachte eigentlich eher dass WinFX die "Nachfolge-API" (im weitesten Sinn) von Win32 ist.

Zumindest nach einem MSDN-Video das ich mal gesehen hab.

Also keine Spiele-Engine eigentlich, sondern eben eine andere Middleware (oder API).

Im Endeffekt sind "API", "Middleware", "Engine", "Framework" eigentlich alle ziemlich verwandte Arten von "Software, die zwischen zwei Ebenen liegt".