OpenGL vs. DirectX

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.

Gerade noch gesehen 'Metro Last Light' und Co.

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.

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.

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.

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.

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

.NET mit wpf habe ich verwendet.

Hmmm, dann handelt es sich wohl um "Managed DirectX", wenn man wpf 
einsetzt

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

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.