Guten Morgen. Ich bin vor etwa drei Jahren komplett auf Linux umgestiegen und hatte bis heute keine Veranlassung, diese Entscheidung rückgängig zu machen. Ende letzten Jahres habe ich dann festgestellt, dass auch der letzte Grund Windows hochfahren zu müssen, mittlerweile weggefallen ist, nämlich Spiele. Da ich nicht so viel spiele, habe ich erst in den letzten Tagen festgestellt, dass es sogar richtige Blockbuster-Games in die Linux-Welt geschafft haben. Als ich dann einmal meine Suchmaschine angeworfen habe, war ich ehrlich gesagt etwas platt, da auf nicht wenigen Seiten darauf hingewiesen wurde, dass OpenGL ganz oder in Teilen sogar perfomanter oder effizienter als sein proprietäres Gegenstück von Microsoft sein soll. Angesichts der bevorstehenden Veröffentlichung von DirectX 12 habe ich mir dann die Frage gestellt, ob und wie sich das Thema OpenGL in Verbindung mit großen Spieletiteln für Linux entwickeln wird. Da es bei der Programmierung beider Softwareschnittstellen scheinbar -ich bin Laie- eine Art Gleichstand zu geben scheint, stellt sich mir die Frage, ob OpenGL in der Lage sein wird, die Microsoft Vorherrschaft im Spielesegment durchbrechen zu können. Ich stelle die Frage deshalb im Bereich Programmierung, da mich insbesondere die Meinung derjenigen interessiert, die mit der einen oder anderen Schnittstelle programmieren -müssen-.
Matthias schrieb: > Da ich nicht so viel spiele, habe ich erst in den letzten Tagen > festgestellt, dass es sogar richtige Blockbuster-Games in die Linux-Welt > geschafft haben. Naja. Sind immer noch sehr wenige. Menschen die aktuelle Spiele auf dem PC spielen wollen, kommen imho um Windows immer noch nicht herum. Hast du da ein paar Beispiele für "Blockbuster-Games"? :) Würde mich ernsthaft interessieren. > Da es bei der Programmierung beider Softwareschnittstellen scheinbar > -ich bin Laie- eine Art Gleichstand zu geben scheint, stellt sich mir > die Frage, ob OpenGL in der Lage sein wird, die Microsoft Vorherrschaft > im Spielesegment durchbrechen zu können. Ich weiß garnicht, ob Microsoft hier die Vorherrschaft hat. AFAIK nutzen die meisten Spielekonsolen OpenGL. Ich behaupte mal, dass es nicht an der Grafik-API liegt, dass moderne Spiele selten für Linux verkauft werden. Es wird einfach an dem immer noch sehr kleinen Markt liegen. Der Mehraufwand für ein Linuxprodukt rechnet sich wahrscheinlich lange noch nicht für Spieleentwickler. Die neuste Unreal-Version erlaubt allerdings das Crosscompilen unter Windows für Linux. Linux wird wohl von Epic auch als eine "gleichberechtigte" Zielplattform bezeichnet, der Markt scheint also durchaus zu wachsen. Allerdings funktioniert deren Toolchain immer noch nur mittelmäßig unter Linux.
> Hast du da ein paar Beispiele für "Blockbuster-Games"? :)
Wie gesagt, ich bin Gelegenheitsspieler, insofern muss ich meine Aussage
etwas relativieren, was die neuesten der neuen Games angeht.
Ich habe gerade einmal nachgesehen und auf den ersten Blick fiel mir zum
Beispiel 'Bioshock INFINITE' auf. Zugegeben, ein älterer Titel, aber ein
Blockbuster.
Oder 'Outlast', ebenfalls für Linux verfügbar. War zwar ein Indi-Game,
wurde dann aber zum Blockbuster.
Matthias schrieb: > Angesichts der bevorstehenden Veröffentlichung von DirectX 12 habe ich > mir dann die Frage gestellt, ob und wie sich das Thema OpenGL in > Verbindung mit großen Spieletiteln für Linux entwickeln wird. Bei den 3D-APIs gibt es gerade einen großen Umbruch. Sowohl DirectX, als auch OpenGL werden von Grund auf neu designt. Bei DirectX wird's nachher wohl immer noch gleich heißen, bei OpenGL gibt's dann einen neuen Namen: Vulkan. Diese APIs sind etwas mehr low-level, was direktere Kontrolle ermöglicht und den Overhead reduziert. Das ganze wurde vermutlich ausgelöst durch eine von AMD ganz neu entwickelte API namens Mantle. Die hat in der Praxis gezeigt, daß sich dadurch einiges an Performance rausholen läßt. > Da es bei der Programmierung beider Softwareschnittstellen scheinbar > -ich bin Laie- eine Art Gleichstand zu geben scheint, stellt sich mir > die Frage, ob OpenGL in der Lage sein wird, die Microsoft Vorherrschaft > im Spielesegment durchbrechen zu können. So groß scheint mir diese Vorherrschaft nicht zu sein. Der Markt für Spielekonsolen und Tablets scheint größer zu sein als der für PC-Spiele, und DirectX gibt's ausschließlich bei Microsoft, während es OpenGL bzw. OpenGL/ES praktisch überall gibt. lamotaz schrieb: > Die neuste Unreal-Version erlaubt allerdings das Crosscompilen unter > Windows für Linux. Linux wird wohl von Epic auch als eine > "gleichberechtigte" Zielplattform bezeichnet, der Markt scheint also > durchaus zu wachsen. Vielleicht auch als Reaktion auf Valve, die Linux als zentrale Zielplattform etablieren wollen. Auf der Steambox genannten Spielkonsolle soll mit SteamOS ein Linux-basiertes Betriebssystem laufen. Die Spiele laufen dann auf jedem Linux-PC, da die Steambox auch nichts anderes ist. Die Steam-Software gibt's auch schon länger für Linux, und man kann dort für jedes Spiel direkt sehen, ob es für Linux verfügbar ist. Man kann sogar direkt eine Kategorie "SteamOS + Linux" anwählen, wo nur Linux-Spiele angezeigt werden.
:
Bearbeitet durch User
Rolf Magnus schrieb: >Die Steam-Software gibt's auch schon länger für >Linux, und man kann dort für jedes Spiel direkt sehen, ob es für Linux >verfügbar ist. Man kann sogar direkt eine Kategorie "SteamOS + Linux" >anwählen, wo nur Linux-Spiele angezeigt werden. Das war in meinem Fall der Stein des Anstoßes. Ich habe mir Steam für Linux installiert und dann festgestellt, dass ich Titel, welche ich mal für Windows gekauft habe, jetzt plötzlich auch über Linux spielen konnte. OpenGL betreffend, habe ich noch ein Argument dagegen gefunden, welches mich ehrlich gesagt überrascht hat, weil ich immer davon ausgegangen bin, dass eine nicht proprietäre Lösung dieser Größenordnung keine Defizite in Sachen Dokumentation hat. >DirectX, because it has a cleaner API and better documentation, is easier >to learn. More developers using DirectX = more DirectX games = better >driver support. http://www.extremetech.com/gaming/133824-valve-opengl-is-faster-than-directx-even-on-windows
Mooooooooment. OpenGL ist eine Renderer-API. Damit kannst du der Grafikkarte sagen, wo Polygone liegen und wie sie die rendern soll. Ein wenig mehr ist noch dabei aber das ist die Grundidee. Zu Computergrafik gehört noch eine Menge mehr, die einerseits auf dem Prozessor aber auch viel auf der Grafikkarte gerechnet werden (Shader z.B.). Zu einem Computerspiel gehört dann nochmal eine große Menge mehr. Sound (auch da muss viel gerechnet werden), Physik, Pathfinding, Input Handling um nur mal ein paar wenige zu nennen. DirectX ist eine sehr viel größere API als OpenGL. Man kann damit auch plump Polygone in die GPU pumpen, aber es unterstützt auch Grafik auf einer höheren Ebene (z.B. direkt Laden und Anzeigen von Model-Files), Sound, Windows Management, Input Management usw. Engines sind dann zusammen mit Middleware das Gesamtpaket. Sie stellen auch Tools für Physikberechnung, Pathfinding, Postprocessing usw. bereit. Wenn eine Engine nun auf DirectX aufsetzt, muss sie wesentlich weniger selbst implementieren als bei OpenGL. Sie könnte vielleicht einen Hauch schneller sein, wenn sie alles selbst implementiert, aber oft kann man sich als Entwickler den Aufwand einfach nicht leisten. Deswegen ist OpenGL nur weil es ein bisschen schneller und Platformübergreifend ist leider nicht immer besser als OpenGL. Zu Konsolen und Mobil: Obwohl Bestrebungen da sind, das richtige OpenGL aufs Handy zu bringen (Tegra K1), läuft meistens nur OpenGL-ES. Das ist sehr abgespeckt. Beispiel: Mit OpenGL-ES können sich Lichtquellen nicht bewegen (Dynamic Lighting). Will man das trotzdem um z.B. mit einer Taschenlampe durch die Gegend gehen zu können, muss man tricksen (Texturen stellenweise aufhellen und abdunkeln, Lichtkegel per Polygone reinbasteln, kA wie das genau geht). Auf den Spielekonsolen läuft eigentlich kein richtiges OpenGL. Die Xbox360 hatte etwas ganz eigenes, die PS3 eine API die sehr nah an OpenGL war, die PSP ebenfalls. Bei der PS4 bin ich mir nicht sicher, die Xbox One hat eine API die wie DirectX funktioniert (oder ist es DirectX?). Das ist aber jeweils immer nur die Schicht, die sehr High-Level mäßig anzusprechen ist. Normalerweise setzen die Konsolen-Engines scheinbar auf eine andere, zusätzlich vorhandene API auf, die praktisch direkt der Grafiktreiber zur Verfügung stellt. So können sachen wie der Embedded DRAM genutzt werden und das Ganze wird besser optimiert. Gerade weil die aktuelle Konsolengeneration Hardwaremäßig echt lächerlich ist werden diese APIs noch viel wichtiger sein.
Matthias schrieb: > Als ich dann einmal meine Suchmaschine angeworfen habe, war ich ehrlich > gesagt etwas platt, da auf nicht wenigen Seiten darauf hingewiesen > wurde, dass OpenGL ganz oder in Teilen sogar perfomanter oder > effizienter als sein proprietäres Gegenstück von Microsoft sein soll. die Frage ist welche Versionen miteinander verglichen wurden. Aktuell Optimieren die OpenGL und DirektX Entwickler gerade ihre APIs und auch mehre Kerne sinnvoll auszulasten und die Anzahl der Funktionsaufrufe zu verringern. Ich denke nicht das es dabei einen klaren Sieger gibt.
Matthias schrieb: > OpenGL betreffend, habe ich noch ein Argument dagegen gefunden, welches > mich ehrlich gesagt überrascht hat, weil ich immer davon ausgegangen > bin, dass eine nicht proprietäre Lösung dieser Größenordnung keine > Defizite in Sachen Dokumentation hat. > >>DirectX, because it has a cleaner API and better documentation, is easier >>to learn. More developers using DirectX = more DirectX games = better >>driver support. Das glaube ich ehrlich gesagt nicht. Es ist allerdings so, daß Microsoft DirectX unter Windows pusht während OpenGL zwar meines Wissens nicht aktiv behindert wird, aber auch nichts getan wird, um es zu unterstützen. Das machen alles die Grafikkartenhersteller selbst. OpenGL ist für die zu wichtig, um es nicht auch unter Windows zu unterstüzen. Guest schrieb: > OpenGL ist eine Renderer-API. Damit kannst du der Grafikkarte sagen, wo > Polygone liegen und wie sie die rendern soll. Ein wenig mehr ist noch > dabei aber das ist die Grundidee. Zu Computergrafik gehört noch eine > Menge mehr, die einerseits auf dem Prozessor aber auch viel auf der > Grafikkarte gerechnet werden (Shader z.B.). Seit OpenGL 2.0 ist Shader-Support ein fest eingebautes Feature. OpenGL enthält eine eigene Shader-Sprache und API-Funktionen, um Shader zu laden und zu nutzen. Seit OpenGL 3.0 ist das sogar der Kern von OpenGL, und die klassische "fixed-functionality pipeline" gibt es nicht mehr bzw. nur noch als optionales "compatibility profile". > Wenn eine Engine nun auf DirectX aufsetzt, muss sie wesentlich > weniger selbst implementieren als bei OpenGL. Man kann OpenGL nicht mit DirectX als ganzem vergleichen, sondern nur mit Direct3D (zumindest hieß der Teil mal so, aber mit der Microsoftschen Umbenenneritis heißt's bestimmt inzwischen anders). > Beispiel: Mit OpenGL-ES können sich Lichtquellen nicht bewegen (Dynamic > Lighting). Wie kommst du darauf?
Rolf Magnus schrieb: > Guest schrieb: >> OpenGL ist eine Renderer-API. Damit kannst du der Grafikkarte sagen, wo >> Polygone liegen und wie sie die rendern soll. Ein wenig mehr ist noch >> dabei aber das ist die Grundidee. Zu Computergrafik gehört noch eine >> Menge mehr, die einerseits auf dem Prozessor aber auch viel auf der >> Grafikkarte gerechnet werden (Shader z.B.). > > Seit OpenGL 2.0 ist Shader-Support ein fest eingebautes Feature. OpenGL > enthält eine eigene Shader-Sprache und API-Funktionen, um Shader zu > laden und zu nutzen. Seit OpenGL 3.0 ist das sogar der Kern von OpenGL, > und die klassische "fixed-functionality pipeline" gibt es nicht mehr > bzw. nur noch als optionales "compatibility profile". War ja nur ein Beispiel, denk dir halt ein besseres aus wenn du eines kennst ;) Rolf Magnus schrieb: > Man kann OpenGL nicht mit DirectX als ganzem vergleichen, sondern nur > mit Direct3D (zumindest hieß der Teil mal so, aber mit der > Microsoftschen Umbenenneritis heißt's bestimmt inzwischen anders). Genau das wollte ich damit sagen. Rolf Magnus schrieb: >> Beispiel: Mit OpenGL-ES können sich Lichtquellen nicht bewegen (Dynamic >> Lighting). > > Wie kommst du darauf? Zumindest die Unreal Engine 4 kann das unter OpenGL-ES nicht. Ich denke wenn es so einfach wäre, hätten sie es ja eingebaut. Ansonsten auch hier, wenn du ein besseres Beispiel kennst freue ich mich schon darauf, es zu lesen ;)
lamotaz schrieb: > Es wird einfach an dem immer noch sehr kleinen Markt liegen. Der > Mehraufwand für ein Linuxprodukt rechnet sich wahrscheinlich lange noch > nicht für Spieleentwickler. Was ich aber noch nicht ganz auf die Reihe bekomme ist der Umstand, dass sich OpenGL prinzipiell für Windows, als auch für Linux eignet. Was genau meinst Du also mit Mehraufwand? So wie ich das sehe, könnte man mit OpenGL viel mehr Käufer, bei gleichem Arbeitsaufwand erreichen. Ausgenommen den Umstand, das man von DirectX auf OpenGL umsteigen und sich entsprechend einarbeiten müsste. Soweit ich das gerade über die Suchmaschine gesehen habe, unterstützen die großen GraKa-Hersteller OpenGL, genauso wie DirectX, also kann es daran auch nicht liegen. Oder meintest Du mit Mehraufwand die betriebssymstemspezifischen Installer-Routinen der eigentlichen fertigen Programme? Was ich mir aber auch nicht als das Problem vorstellen kann.
Matthias schrieb: > Oder meintest Du mit Mehraufwand die betriebssymstemspezifischen > Installer-Routinen der eigentlichen fertigen Programme? > Was ich mir aber auch nicht als das Problem vorstellen kann. Ja denn Installer sind das einzige Betriebssystemabhaengige. Wenn doch nur jemand die Files von Word in ein deb Archiv packen wuerde...
Guest schrieb: > Ja denn Installer sind das einzige Betriebssystemabhaengige. Wenn doch > nur jemand die Files von Word in ein deb Archiv packen wuerde... Moment mal. OpenGL ist plattformunabhängig. Wenn ich das richtig verstehe, greift OpenGL natürlich auch auf plattformspezifische Systembibliotheken zurück. Aber plattformunabhängig heißt für mich, dass es eine Abstraktionsbene gibt, auf der ein Programmierer sich nicht darum kümmern muss. Ergo müsste es bei OpenGL eine einheitliche Programmierschnittstelle geben.
C ist das beste Beispiel. Sicher, die plattformspezifische Implementierung ist natürlich unterschiedlich, aber der Code ist einheitlich und lässt sich sowohl unter Linux, als auch unter Windows kompilieren.
Matthias schrieb: > Ergo müsste es bei OpenGL eine einheitliche Programmierschnittstelle > geben. Bei OpenGL schon. Mit OpenGL kannst du allerdings nichtmal ein Fenster erstellen, ergo deine tollen Grafikinhalte auf den Bildschirm bringen. Du kannst auch keinen Input einlesen, also Maus oder Tastatur. Du kannst auch keinen Sound ausgeben. Du kannst mit OpenGL nicht mal ein File aufmachen um dann ein Modell oder Texturen einzulesen. Oder Systemkonfigurationen einlesen (z.B. aus der Registry). Und vermutlich das größte Problem für die Publisher: du kannst damit keinen Kopierschutz einbauen. All diese Dinge sind Betriebssystemabhängig. Manche davon (File aufmachen) sind in der Standardlib der Programmiersprache (z.B. in C), andere nicht.
Guest schrieb: > Rolf Magnus schrieb: >> Man kann OpenGL nicht mit DirectX als ganzem vergleichen, sondern nur >> mit Direct3D (zumindest hieß der Teil mal so, aber mit der >> Microsoftschen Umbenenneritis heißt's bestimmt inzwischen anders). > > Genau das wollte ich damit sagen. Das heißt aber nicht, daß eine Game-Engine alles andere komplett selbst machen muß. Es gibt ja auch noch andere Libs wie SDL, die es auch praktisch überall gibt und die viele der Aufgaben übernehmen, die OpenGL nicht macht.
Rolf Magnus schrieb: > Guest schrieb: > Rolf Magnus schrieb: > Man kann OpenGL nicht mit DirectX als ganzem vergleichen, sondern nur > mit Direct3D (zumindest hieß der Teil mal so, aber mit der > Microsoftschen Umbenenneritis heißt's bestimmt inzwischen anders). > > Genau das wollte ich damit sagen. > > Das heißt aber nicht, daß eine Game-Engine alles andere komplett selbst > machen muß. Es gibt ja auch noch andere Libs wie SDL, die es auch > praktisch überall gibt und die viele der Aufgaben übernehmen, die OpenGL > nicht macht. Aber darum geht es doch garnicht. Natuerlich KANN man Game Engines Plattformuebergreifend machen. Aber unter Umstaenden ist das eben mehr Arbeit als einfach nur DirectX zu nutzen.
Ich! Jedes mal neu. Dabei kann man aus so vielen Fehlern lernen. Aber beim nächsten versuch wird sie sicher perfekt!
Guest schrieb: > Aber darum geht es doch garnicht. Natuerlich KANN man Game Engines > Plattformuebergreifend machen. Aber unter Umstaenden ist das eben mehr > Arbeit als einfach nur DirectX zu nutzen. Mein Punkt war, daß es nicht nur für den 3D-Teil von DirectX Alternativen gibt, sondern auch für den Rest. Wenn man die nutzt, hat man auch nicht großartig mehr Arbeit als mit DirectX, hat aber ein Spiel, das sich viel leichter auf verschiedene Plattformen portieren läßt. Wenn alles voll auf DirectX ausgerichtet ist, hat man dageben einen erheblichen Aufwand damit, es dann nachher auf nicht-Windows-Plattformen zu portieren.
Guest schrieb: > Aber darum geht es doch garnicht. Natuerlich KANN man Game Engines > Plattformuebergreifend machen. Aber unter Umstaenden ist das eben mehr > Arbeit als einfach nur DirectX zu nutzen. Komisch, genau das habe ich vor Deinem netten Post bezüglich der Word-Files und Deb-Pakete auch geschrieben. Und den Zusatzaufwand betreffend, sich hier einzuarbeiten zu müssen, habe ich auch angesprochen. Ich darf noch einmal die Frage bezüglich des Mehraufwandes aufwerfen. Angenommen man würde sich statt DirectX zu benutzen, in OpenGL und die zusätzlichen Schnittstellen, wie beispielsweise OpenAL für Sound einarbeiten, dann gäbe es aus meiner Sicht nur Vorteile. Lt. Wikipedia die Folgenden - Client-Server-Modell - Draw-Aufrufe sind unter bestimmten Umständen leistungsfähiger als in Direct3D[7] - plattformunabhängig - von Herstellern selbst erweiterbar - es gibt eine Vielzahl an Extensions für neue, noch nicht vom Standard unterstützte Funktionen die verfügbaren Features sind von der GPU bzw. deren Treiber abhängig – und nicht vom Betriebssystem [8] Und zuletzt den von mir genannte, welcher sich aus der Plattformunabhängigkeit ergibt, nämlich der eines erweiterten Kundenkreises.
War halt die alte Microsoft Strategie. Eigene Standards setzen, die nur mit den eigenen Produkten halbwegs rund funktionieren. Der Mehraufwand - Microsoft hat dafür gesorgt, dass Hardware, Betriebssystem, Visual-C, und DirectX auf Anhieb zusammenpassen. Die Entwickler konnten sofort loslegen. Mussten sich keine Gedanken machen, welche Libraries zusammenarbeiten. Ist doch das nervigste Problem bei Linux; Das Spiel will noch ein /dev/dsp, aber Ubuntu hat es deaktiviert. Hat sich doch gewaltig geändert. Microsoft will mit seinem Standard den Vertrieb von Spielen kontrollieren - Valve portiert seine Windows-Spiele auf Linux - andere Entwickler legen ihre Spiele auch plattformunabhängig an. Dumm gelaufen.
Noch einer schrieb: > Hat sich doch gewaltig geändert. Microsoft will mit seinem Standard den > Vertrieb von Spielen kontrollieren - Valve portiert seine Windows-Spiele > auf Linux - andere Entwickler legen ihre Spiele auch plattformunabhängig > an. Dumm gelaufen. es gibt aber auch Nachteile vom "Standards". Was ist wenn man Funktionen anbietet will die es dort einfach nicht gibt? Dann ist es für MS halt einfacher sich vom Standard zu entfernen.
Noch einer schrieb: > Valve portiert seine Windows-Spiele > auf Linux - andere Entwickler legen ihre Spiele auch plattformunabhängig > an. Dumm gelaufen. Mein urspruenglicher Gedanke bei der Sache war der Vergleich zwischen Windows und Linux. Am Anfang hat man logischerweise einen erhöhten Einarbeitungsaufwand, was aber vielmehr damit zusammenhängt, dass man unter Linux so ziemlich alles machen kann, was man möchte. Und so auch natürlich auch beim Wechsel der Gaming Engine. Die Intention meines Eingangspostes bezog sich genau auf das 'Dumm gelaufen'. Vor ein paar Jahren noch völlig undenkbar und gestern sehe ich, dass es mal eben Bioshock Infinte für Linux gibt und das die freie Grafik-Engine keines Wegs schlechter als die proprietäre Lösung ist. Letzteres habe ich immer angenommen, weil man als früherer Windows User voll auf DirectX eingenordet wird und gar nicht auf die Idee kommt, sich nach OpenGL umzusehen. Ich habe immer gedacht, dass OpenGL im Vergleich zu DirectX so eine Art Hobby-Standard ist. Jetzt denke ich, dass Microsoft auf mittlere Sicht ein großes Problem haben wird.
Noch einer schrieb:
> Valve portiert seine Windows-Spiele
Plant Valve alle seine über Steam vertriebenen Titel zu portieren???
Würde bedeuten, dass ich demnächst Crysis 3 auf Linux spielen kann, denn
das gibt es aktuell unter Steam, aber noch ausschliesslich in der
Windows Variante.
Hallo Matthias schrieb: > Ich habe immer gedacht, dass OpenGL im Vergleich zu DirectX so eine Art > Hobby-Standard ist. Da hast Du genau in die falsche Richtung gedacht. DirectX wurde für die vielen "einfachen" PC-Spieler von MS entwickelt. OpenGL gab es im professionellen Umfeld schon vorher und wird dort auch heute noch überwiegend eingesetzt. Auch wenn der PC unter Windows laufen sollte bringen die entsprechenden Treiberpakete für die Grafikkarten im professionellen Bereich auch immer die OpenGL-Treiber mit. Gruß Gerd
gekufi schrieb: > Hallo > > Matthias schrieb: >> Ich habe immer gedacht, dass OpenGL im Vergleich zu DirectX so eine Art >> Hobby-Standard ist. > > Da hast Du genau in die falsche Richtung gedacht. DirectX wurde für die > vielen "einfachen" PC-Spieler von MS entwickelt. > OpenGL gab es im professionellen Umfeld schon vorher und wird dort auch > heute noch überwiegend eingesetzt. Richtig. OpenGL ist ursprünglich von Silicon Graphics entwickelt worden für Visualisierung und Modellierung im technischen/wissenschaftlichen Bereich, also professionelle 3D-Grafik. Direct3D kam erst ein paar Jahre später und war voll auf Spiele ausgerichtet. OpenGL hatte, was die Features betrifft, gegenüber Direct3D auch einen großen Vorsprung. Die Zielsetzungen waren aber auch sehr unterschiedlich. Bei OpenGL gab es eine Liste von Features, die jede Impelementation unterstützen musste. Das hat es für die Programmierer einfacher gemacht, weil die Features immer zu Verfügung standen. Wenn die Hardware ein Feature nicht unterstütze, musste der Treiber die Funktionalität in Software implementieren. Das hatte den Nachteil, dass die Entwicklung der Treiber aufwändiger war und daß es recht langsam werden konnte, wenn man Features nutze, die nicht in der Hardware verfügbar waren. Bei DirectX dagegen wurden immer nur die Funktionalitäten, die auch tatsächlich in Hardware verfügbar waren, auch angeboten. Vorteil: Man konnte nicht versehentlich was langsames machen. Nachteil: Man mußte für jede Grafikkarte erst umständliche Tests und Verzweigungen einbauen, um sich an die Unterschiede anzupassen, und DirectX konnte auch immer nur das, was es schon in Hardware gab. Deshalb mußte sich DirectX am Anfang sehr schnell weiterentwickeln, wärend OpenGL kaum was brauchte, weil es lange Zeit fast alle Features neuerer Grafikkarten schon unterstützt hat. So wie ich das sehe, sind beide inzwischen aber auf eine gemeinsame Mitte zusammengelaufen. Matthias schrieb: > Noch einer schrieb: > >> Valve portiert seine Windows-Spiele > > Plant Valve alle seine über Steam vertriebenen Titel zu portieren??? Ich glaube nicht, daß sie alle existierenden Spiele portieren wollen. Das ist schließlich Aufwand und kostet Geld, das man dann damit erstmal wieder reinholen muß. Aber zukünftige Spiele werden vermutlich vermehrt auch für Linux rauskommen. > Würde bedeuten, dass ich demnächst Crysis 3 auf Linux spielen kann, denn > das gibt es aktuell unter Steam, aber noch ausschliesslich in der > Windows Variante. Crysis 3 ist aber nicht von Valve, sondern von Crytek. Ob die auch Interesse daran haben, irgendwelche Spiele nach Linux zu portieren, weiß ich nicht.
Valve hat doch schon quasi all ihre Titel portiert. Soo viele haben die ja nicht.
Aber der Dreh- und Angelpunkt ist doch, dass sich die Programmierer von Feld-, Wald- und Wiesenspielen nur noch selten mit DirectX oder OpenGL abgeben, sondern eine fertige Engine wählen - und mit deren Bugs und Einschränkungen leben. Wenn es auf mehreren Plattformen laufen soll wird halt eine für mehreren Plattformen erhältliche Engine verwendete. Dann lebt man zusätzlich mit den Einschränkungen der jeweiligen Plattformportierung. Was hinter der Engine werkelt ist den Programmierern dabei fast egal. Unity 5 lauft zum Beispiel angeblich auf 20 Plattformen. Davon muss man den Marketingaufschlag und obskure Plattformen abziehen. Es bleiben trotzdem viele kommerziell interessante. Warum also ein Game auf eine Plattform beschränken?
Erinnert sich noch jemand an Quake unter Linux? Da gab es ein Dutzend Varianten. Carmack hatte die Engines modular angelegt und hunderte von Freiwilligen schrieben unterschiedliche Low-Level Routinen. Wenn man Glück hatte, funktionierte zumindest eine davon auf der eigenen Distribution. Heutzutage sorgen die Distributionen dafür, dass Steam läuft. Wenn eine Engine das selbe wie Steam benutzt, läuft sie auf jeder Linux Distribution. Microsoft stellte sicher: Wenn die Engine DirectX benutzt, wird sie auf jedem Windows laufen. Eine Engine, die SDL + OpenGL benutzt, lief ja nicht auf jedem Linux. Das gibt es ja erst seit ein paar Jahren.
Mir mal ausgefallen, dass man unter OpenGL VSync-synchronisiert Frames zeichnen kann. Mit .NET scheint dies nicht zu gehen. Oder verwechsel ich jetzt .NET mit DirectX ? Harry
WPF bei aktivierter Hardwarebeschleunigung updated eigentlich möglichst passend zum vsync. Bei Tearing mit WPF ist vermutlich irgendwo "ungünstiger" Code, der irgendwie den Render-Thread ausbremst - oder der Grafikkartentreiber ist scheiße - oder irgendwas sorgt dafür das die Hardwarebeschleunigung nicht verwendet wird.
Rage von Id war das letzte große für windows auf opengl basierende spiel. Ausnahmslos alles andere wird mit directx entwickelt... überlegt mal warum?! Gruß J
jonasbiensack schrieb: > Ausnahmslos alles andere wird mit directx entwickelt... ... unter Windows. Das ist aber nicht die einzige Spieleplattform. Auf der Playstation gibt's kein DirectX. > überlegt mal warum?! Ich weiß es ehrlich gesagt nicht. Frag ich mich seit Jahren.
Rolf Magnus schrieb: >> überlegt mal warum?! > > Ich weiß es ehrlich gesagt nicht. Frag ich mich seit Jahren. Es sind vermutlich nur Marketinggründe.
war es nicht lange so, dass OpenGL "optimiert" Grafikkarten nur im Profibereich gab, und OpenGL auf homeuser-"spielekarten" zwar funktionierte, aber grottenlangsam, und man sich erst "illegal" die "profi"firmware aufspielen musste.. wohl auch einer der gründe warum "früher" niemand OpenGL spiele geschrieben hat..
Ganz im Gegenteil. Im Vergleich zu den Spielen sind 3D CAD Oberflächen recht harmlos. Da sind auch unterschiedliche Anforderungen. Z.B. will man bei professioneller CAD-Software die Beleuchtung exakt durchrechnen, Spiele tricksen da mit einer vorausberechneten Lightmap. Ist eher so, dass Spiele-Karte und -Treiber zusätzliche Funktionen für flüssig wirkende Tricksereien brauchen.
Noch einer schrieb: > Im Vergleich zu den Spielen sind 3D CAD Oberflächen recht harmlos. Da > sind auch unterschiedliche Anforderungen. Ja. Die Profikarten waren früher meist mit bestimmten Features ausgestattet, die Spiele nicht brauchten und waren dafür teils sogar langsamer als die Spielekarten. Das ist heute glaub ich durchaus noch immer so. So haben die Profikarten z.B. die Möglichkeit, die Bildausgabe von mehreren (auch in verschiedenen Rechnern steckenden) Karten miteinander oder auch mit einer externen Taktquelle zu synchronisieren (Framelock, Genlock). Oder die Karte hat z.B. eine erhöhte Performance bei double precision, die bei Spielen kaum genutzt wird, aber für Simulationen und wissenschaftliche Berechnungen notwendig ist. Dafür ist die Karte insgesamt langsamer. > Z.B. will man bei professioneller CAD-Software die Beleuchtung exakt > durchrechnen, Spiele tricksen da mit einer vorausberechneten Lightmap. Die Beleuchtung ist auch bei Spielen heute recht komplex, aber getrickst wird dort überall. Bei Spielen gilt eben das Motto, daß es nicht pyhsikalisch perfekt sein muss, sondern nur möglichst gut aussehen soll, ohne dabei zu langsam zu werden.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.